Settings ProjectDLLPathSettings/en - Versionsgeschichte

Cg: /* DLL action Blocks and DLLs */

2021-12-07T08:59:51Z

DLL action Blocks and DLLs

← Nächstältere Version		Version vom 7. Dezember 2021, 08:59 Uhr
Zeile 10:		Zeile 10:
	And of course, the location and name of the DLL, in which the desired function is located.		And of course, the location and name of the DLL, in which the desired function is located.

	This ~~last item~~ can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.		This can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.

	For example, the Unix convention is to name them "<code>XXX.so</code>", whereas under Windows, they are named "<code>XXX.dll</code>". Sometimes DLLs have different names depending on the wordlength; so a library might be named "<code>XXX.dll</code>" on a 32bit system and "<code>XXX_64.dll</code>" on a 64bit system.		For example, the Unix convention is to name them "<code>XXX.so</code>", whereas under Windows, they are named "<code>XXX.dll</code>". Sometimes DLLs have different names depending on the wordlength; so a library might be named "<code>XXX.dll</code>" on a 32bit system and "<code>XXX_64.dll</code>" on a 64bit system.

Cg: /* DLL Basename Mapping */

2019-05-03T08:41:19Z

DLL Basename Mapping

← Nächstältere Version		Version vom 3. Mai 2019, 08:41 Uhr
Zeile 18:		Zeile 18:
	== DLL Basename Mapping ==		== DLL Basename Mapping ==

	If the basename of the Unix DLL is the same as the basename of the Windows DLL, your test suite using DLL action blocks should run unchanged on both systems.		If the basename (that is the name without path-prefix and filename-suffix) of the Unix DLL is the same as the basename of the Windows DLL, your test suite using DLL action blocks should run unchanged on both systems.

	However, if they are different, you need a mapping mechanism, which dynamically specifies a replacement name for a given DLL, and this replacement depends on the architecture (i.e. Linux vs. Windows32 vs. Windows64) or on the installation path in the machine on which you are executing expecco. Therefore, this mapping is kept in your personal preferences, not in the test suite (if required, you can use multiple such settings files and specify the one to use on the command line).		However, if they are different, you need a mapping mechanism, which dynamically specifies a replacement name for a given DLL, and this replacement depends on the architecture (i.e. Linux vs. Windows32 vs. Windows64) or on the installation path in the machine on which you are executing expecco. Therefore, this mapping is kept in your personal preferences, not in the test suite (if required, you can use multiple such settings files and specify the one to use on the command line).

Cg: /* DLL action Blocks and DLLs */

2019-05-03T08:39:58Z

DLL action Blocks and DLLs

← Nächstältere Version		Version vom 3. Mai 2019, 08:39 Uhr
Zeile 6:		Zeile 6:
	To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written.		To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written.
	However, you need to know the name of the function, the number and types of arguments and the return type.		However, you need to know the name of the function, the number and types of arguments and the return type.
	On ~~windows32~~ systems, you also need to know the call-convention (API-call or C-call).		On 32bit Windows systems, you also need to know the call-convention (API-call or C-call).

	And of course, the location and name of the DLL, in which the desired function is located.		And of course, the location and name of the DLL, in which the desired function is located.

	This last item can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.		This last item can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.
	For example, the Unix convention is to name them "<code>XXX.so</code>", whereas under Windows, they are named "<code>XXX.dll</code>".		For example, the Unix convention is to name them "<code>XXX.so</code>", whereas under Windows, they are named "<code>XXX.dll</code>". Sometimes DLLs have different names depending on the wordlength; so a library might be named "<code>XXX.dll</code>" on a 32bit system and "<code>XXX_64.dll</code>" on a 64bit system.

	== Default Suffixes ==		== Default Suffixes ==

Cg: /* DLL action Blocks and DLLs */

2019-05-03T08:37:19Z

DLL action Blocks and DLLs

← Nächstältere Version		Version vom 3. Mai 2019, 08:37 Uhr
Zeile 1:		Zeile 1:
	== DLL action Blocks and DLLs ==		== DLL action Blocks and DLLs ==

	The [[ElementaryBlock_Element/en#DLL-Calls \| DLL-call elementary blocks]] are used to call functions inside a DLL ("''Dynamic Link Library''"). In the Unix world, these are also called "''Shared ~~Library~~''" or "''Shared ~~Object~~''".		The [[ElementaryBlock_Element/en#DLL-Calls \| DLL-call elementary blocks]] are used to call functions inside a DLL ("''Dynamic Link Library''"). In the Unix world, these are also called "''Shared Libraries''" or "''Shared Objects''".

	DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).		DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).

Mawalch am 4. Januar 2018 um 18:29 Uhr

2018-01-04T18:29:25Z

← Nächstältere Version		Version vom 4. Januar 2018, 18:29 Uhr
Zeile 4:		Zeile 4:

	DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).		DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).
	To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written.		To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written.
	However, you need to know the name of the function, the number and types of arguments and the return type.		However, you need to know the name of the function, the number and types of arguments and the return type.
	On windows32 systems, you also need to know the call-convention (API-call or C-call).		On windows32 systems, you also need to know the call-convention (API-call or C-call).


	And of course, the location and name of the DLL, in which the desired function is located.		And of course, the location and name of the DLL, in which the desired function is located.
	This last item can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.		This last item can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.
Zeile 19:		Zeile 19:
	If the basename of the Unix DLL is the same as the basename of the Windows DLL, your test suite using DLL action blocks should run unchanged on both systems.		If the basename of the Unix DLL is the same as the basename of the Windows DLL, your test suite using DLL action blocks should run unchanged on both systems.

	However, if they are different, you need a mapping mechanism, which dynamically specifies a replacement name for a given DLL, and this replacement depends on the architecture (i.e. Linux vs. Windows32 vs. Windows64) or on the installation path in the machine on which you are executing expecco. Therefore, this mapping is kept in your personal preferences, not in the test suite (if ~~reqwuired~~, you can use multiple such settings files and specify the one to use on the command line).		However, if they are different, you need a mapping mechanism, which dynamically specifies a replacement name for a given DLL, and this replacement depends on the architecture (i.e. Linux vs. Windows32 vs. Windows64) or on the installation path in the machine on which you are executing expecco. Therefore, this mapping is kept in your personal preferences, not in the test suite (if required, you can use multiple such settings files and specify the one to use on the command line).

	The replacement given in the DLL name mapping can be either another basename, a basename-plus-suffix or a complete relative or absolute path to the target DLL.		The replacement given in the DLL name mapping can be either another basename, a basename-plus-suffix or a complete relative or absolute path to the target DLL.

Cg: /* DLL action Blocks and DLLs */

2016-12-21T11:27:01Z

DLL action Blocks and DLLs

← Nächstältere Version		Version vom 21. Dezember 2016, 11:27 Uhr
Zeile 1:		Zeile 1:
	== DLL action Blocks and DLLs ==		== DLL action Blocks and DLLs ==

	The DLL-call elementary blocks are used to call functions inside a DLL ("''Dynamic Link Library''"). In the Unix world, these are also called "''Shared Library''" or "''Shared Object''".		The [[ElementaryBlock_Element/en#DLL-Calls \| DLL-call elementary blocks]] are used to call functions inside a DLL ("''Dynamic Link Library''"). In the Unix world, these are also called "''Shared Library''" or "''Shared Object''".

	DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).		DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).

Cg: /* DLL Basename Mapping */

2016-12-21T11:25:18Z

DLL Basename Mapping

← Nächstältere Version		Version vom 21. Dezember 2016, 11:25 Uhr
Zeile 19:		Zeile 19:
	If the basename of the Unix DLL is the same as the basename of the Windows DLL, your test suite using DLL action blocks should run unchanged on both systems.		If the basename of the Unix DLL is the same as the basename of the Windows DLL, your test suite using DLL action blocks should run unchanged on both systems.

	However, if they are different, you need a mapping mechanism, which dynamically specifies a replacement name for a given DLL, and this replacement depends on the ~~machine on which you are executing expecco~~ (i.e. Linux vs. Windows32 vs. Windows64). Therefore, this mapping is kept in your personal preferences, not in the test suite.		However, if they are different, you need a mapping mechanism, which dynamically specifies a replacement name for a given DLL, and this replacement depends on the architecture (i.e. Linux vs. Windows32 vs. Windows64) or on the installation path in the machine on which you are executing expecco. Therefore, this mapping is kept in your personal preferences, not in the test suite (if reqwuired, you can use multiple such settings files and specify the one to use on the command line).

	The replacement given in the DLL name mapping can be either another basename, a basename-plus-suffix or a complete relative or absolute path to the target DLL.		The replacement given in the DLL name mapping can be either another basename, a basename-plus-suffix or a complete relative or absolute path to the target DLL.

Cg: /* Default Suffixes */

2016-12-21T11:22:34Z

Default Suffixes

← Nächstältere Version		Version vom 21. Dezember 2016, 11:22 Uhr
Zeile 13:		Zeile 13:

	== Default Suffixes ==		== Default Suffixes ==
	Expecco will itself add the appropriate suffix, if the name in the DLL-action definition has none. Therefore, for portability of your test suites between Windows and Linux (if ever desired), it ~~is highly recommended to~~ only specify the basename of the DLL in the action block.		Expecco will itself add the appropriate suffix, if the name in the DLL-action definition has none. Therefore, for portability of your test suites between Windows and Linux (if ever desired), you should only specify the basename of the DLL in the action block, and let expecco fill in the appropriate suffix.

	== DLL Basename Mapping ==		== DLL Basename Mapping ==

Cg: /* DLL action Blocks and DLLs */

2016-12-21T11:21:21Z

DLL action Blocks and DLLs

← Nächstältere Version		Version vom 21. Dezember 2016, 11:21 Uhr
Zeile 4:		Zeile 4:

	DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).		DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).
	To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written.		To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written.
	However, you need to know the name of the function, the number and types of arguments and the return type.		However, you need to know the name of the function, the number and types of arguments and the return type.
	On windows32 systems, you also need to know the call-convention (API-call or C-call).		On windows32 systems, you also need to know the call-convention (API-call or C-call).

Cg: /* DLL action Blocks and DLLs */

2016-12-21T11:21:07Z

DLL action Blocks and DLLs

← Nächstältere Version		Version vom 21. Dezember 2016, 11:21 Uhr
Zeile 3:		Zeile 3:
	The DLL-call elementary blocks are used to call functions inside a DLL ("''Dynamic Link Library''"). In the Unix world, these are also called "''Shared Library''" or "''Shared Object''".		The DLL-call elementary blocks are used to call functions inside a DLL ("''Dynamic Link Library''"). In the Unix world, these are also called "''Shared Library''" or "''Shared Object''".

	~~These~~ are files which contain compiled code, typically written in languages like C or C++. ~~To call a function from a DLL, you do~~ not ~~need~~ to ~~know, in which language a DLL's functions were originally written~~. ~~However, you need to know the name of the function, the number and types of arguments and the return type.~~		DLLs are files which contain compiled code, typically written in programming languages like C or C++ (but not required to be).
			To call a function from a DLL, you do not need to know, in which language a DLL's functions were originally written.
			However, you need to know the name of the function, the number and types of arguments and the return type.
			On windows32 systems, you also need to know the call-convention (API-call or C-call).

	And of course, the location and name of the DLL, in which the desired function is located.		And of course, the location and name of the DLL, in which the desired function is located.

	This last item can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.		This last item can become a problem, because both the suffixes and the basename of DLL's might be different between operating systems.
	For example, the Unix convention is to name them "<code>XXX.so</code>", whereas under Windows, they are named "<code>XXX.dll</code>".		For example, the Unix convention is to name them "<code>XXX.so</code>", whereas under Windows, they are named "<code>XXX.dll</code>".