Printable View
Actually in Visual Basic when you use an API, it's something like this:
For Example:
Private Declare Sub RtlMoveMemory Lib "kernel32.dll" (Destination As Any, Source As Any, ByVal Length As Long)
It means you are using a function from the kernel32.dll file in system32 folder of the windows operating system
What about C++?
Does a MFC (Microsoft Foundation Class Library) application use kernel32.dll functions like the VB APIs? or it has a separate and inner library?
tnx
C++ can use C++ decorated Entrypoints to call "Class-Methods" - but it can also call normal "flat-APIs"Quote:
Originally Posted by Mehdi Jazini
(mostly using either __cdecl or __stdcall convention) against Entrypoints in Std-Dlls ...
(basically in the same way as the plain-C-language, in C-Style).
What VB does and supports with its Declare-Statements is "delayed-loading of Flat-entrypoints"
(calling LoadLibrary/GetProcAddress the first time it encounters a line of code which makes use
of the Function-Symbol you defined in your VB-Declare-Statement).
In C/C++ such delayed loading can be accomplished (on Windows per LoadLibrary/GetProcAddress,
on unix per dlopen/dlsym) as well - but it would have to be done "by hand" and is not "the norm".
Instead most C/C++ Apps rely on early loading/binding of the Dll-Entrypoints (the Function-Addresses),
using either *.lib-files (or *.a files) in conjunction with *.def-files in the linking-phase of the compilation-process.
This linking usually also needs support by an accompanying *.h-file, which describes not only
the Symbol-Name of the Function-Entrypoint in the external Binary, but also the full function-signature
(the type and amount of parameters the function in question expects).
So the content of these "Dll-Link-describing" *.h files is comparable with a block of VBs Declare-Statements -
both describe the exact (full) signatures (including params and types) of the external function-symbols (or -names).
And for almost all Windows-System-Dlls, such *.h Files are already predefined and exist in the appropriate
Include-Directories of the compiler-environment in question.
On Windows, all a C/C++ developer has to do at the C-source-level, to be able to make
calls to functions from kernel32 (and other "usual sytem-dlls") is to:
#include <windows.h>
(which indirectly ensures inclusion of most of the other basic dll *.h files of the system,
since *.h-files can have their own, nested include-statements ... -> windows.h is acting
as such a "root"-file).
Also the (for simpler C/C++ Console-Apps) used inclusion:
#include <stdio.h>
subsequently also inlcudes (at least here for my TinyCC-environment) at least winbase.h
(which contains most of the function-signatures for kernel32.dll)
since GetTickCount will already hand out a plausible return-value when doing:
kernel32-call:
PrintOut at the console:Code:#include <stdio.h>
int main(){
printf("Hello, World\n");
return GetTickCount(); // use a Symbol from kernel32.dll
}
Whilst the above works without specifying -lkernel32 at the commandline explicitely,Code:Hello, World
----------------------------------------------------------------------------------------------------
main() returned: 137564427
(since kernel32 is usually automatically included and linked)...
for the following call to succeed, I had to give already an explicit: -luser32 at the commandline
(in *addition* to the given extra-*.h-file inclusion of the following C-Code):
user32-call
PrintOut at the console:Code:#include <stdio.h>
#define WIN32_LEAN_AND_MEAN //<-- only include the bare minimum of the Win32-userland-API
#include <windows.h> //windows.h subsequently includes also winuser.h, which contains most of the user32.dll signatures
int main(){
printf("Hello, World\n");
return GetActiveWindow();
}
So that's with regards to *.h files, which contain the "full description" of the function-symbols andCode:Hello, World
----------------------------------------------------------------------------------------------------
main() returned: 1969598
their arguments + argument-types, a given C-compiler needs to know to prepare the correct
"function-jump-sequence" against the target-address of a given functions symbol-name.
What then remains for the Compiler (and Linker) is to provide (and bind) correct target-points
for those "function-jump-snippets" the compiler is about to prepare.
*.def files can help to ensure that final linking, over a simple contained text-list of those function-symbol-names,
since in the first lines of a *.def file the name of the dll-binary which contains those names is also described.
So, when those *.def Files are given on the compilers command-line, the circle is closed -
the *.h-File defined symbolnames will get mapped to those, found in a *.def-file - and since the *.def file
also describes which binary (which Dll-name) contains these symbols, the compiler/linker has all the infos it needs.
MS-compilers prefer precompiled *.lib files instead of *.def in the final linking-stage -
and those *.lib-files can then come in two versions - a *.lib-file which ensures only the
"bare bindings" to the "real Dll" - or a "fully static lib", which provides also the implementation
(which normally sits in the compiled Dll-File, which in this latter case is not needed).
The OpenSource-compilers have a different alternative to the MS-*.lib files - they use *.a extensions
for this kind of precompiled binding-files (*.a is also used for fully precompiled static libs).
Olaf
.h header files are used only in the compile phase to generate the intermediate obj files which are then used by the linker to generate the execution file (.exe on window system). The .h header files are not used in the link phase. The linker knows nothing about a particular language (eg c++) and will link intermediate obj created in different languages (eg fortran).Quote:
This linking usually also needs support by an accompanying *.h-file,
Well, I might have been a bit lazy in my formulation - but when you leave the thing in contextQuote:
Originally Posted by 2kaud
with the paragraph I wrote before:
period... (in the sense of a 'pause')...Quote:
Instead most C/C++ Apps rely on early loading/binding of the Dll-Entrypoints (the Function-Addresses),
using either *.lib-files (or *.a files) in conjunction with *.def-files in the linking-phase of the compilation-process.
Followed by:
"This linking usually also needs support by an accompanying *.h-file, ..."
Sorry - should perhaps have written:
"This linking-process usually also needs prior support by an accompanying *.h-file, ..."
(for the development and compile-phase of your very own "User" C-Project)...
Remember that the topic was about "VB-like usage of precompiled Dll-Binaries",
incorporating them into ones own C/C++ Project.
@ Mehdi
E.g. what you usually get from a closed source-Vendor, when you look at the
"commercial Driver-lib for a certain Video-Camera" or something, in the install-package:
In a Win-Directory:
.....\TheDriver.dll
.....\TheDriver.lib
.....\TheDriver.def (sometimes, not always - but easily generatable from a *.dll)
In a Linux-Directory:
.....\TheDriver.so
.....\TheDriver.a
accompanied by (usually universal for both platforms) a single *.h file for your C-Compilers
include Folder or the one of your own Project, which wants to integrate that Driver-Library:
.....\TheDriver.h
Usually accompanied by an \Examples\ folder which contains *.c-Files
So, sure - the *.h files are at the "coding-side" (dragged through the PreProcessor) -
the other filetypes are related to the linking-stage.
Olaf