Has MFC a separate library?-VBForums
Results 1 to 4 of 4

Thread: Has MFC a separate library?

  1. #1

    Thread Starter
    Lively Member Mahdi Jazini's Avatar
    Join Date
    Feb 2014
    Location
    Iran / Tehran
    Posts
    86

    Lightbulb Has MFC a separate library?

    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

  2. #2
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,107

    Re: Has MFC a separate library?

    Quote Originally Posted by Mehdi Jazini View Post
    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?
    C++ can use C++ decorated Entrypoints to call "Class-Methods" - but it can also call normal "flat-APIs"
    (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:
    Code:
    #include <stdio.h>
    
    int main(){
      printf("Hello, World\n");
    
      return GetTickCount(); // use a Symbol from kernel32.dll
    }
    PrintOut at the console:
    Code:
    Hello, World
    
    ----------------------------------------------------------------------------------------------------
    main() returned: 137564427
    Whilst the above works without specifying -lkernel32 at the commandline explicitely,
    (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
    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();
    }
    PrintOut at the console:
    Code:
    Hello, World
    
    ----------------------------------------------------------------------------------------------------
    main() returned: 1969598
    So that's with regards to *.h files, which contain the "full description" of the function-symbols and
    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
    Last edited by Schmidt; Nov 26th, 2014 at 11:41 AM.

  3. #3
    Hyperactive Member 2kaud's Avatar
    Join Date
    May 2014
    Location
    England
    Posts
    392

    Re: Has MFC a separate library?

    This linking usually also needs support by an accompanying *.h-file,
    .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).
    All advice is offered in good faith only. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/

    C++17 Compiler: Microsoft VS2017 (15.4.1)

  4. #4
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,107

    Re: Has MFC a separate library?

    Quote Originally Posted by 2kaud View Post
    .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.
    Well, I might have been a bit lazy in my formulation - but when you leave the thing in context
    with the paragraph I wrote before:
    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.
    period... (in the sense of a 'pause')...

    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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.