About the lib files...

[felipe]

I can see the m32lib source code and the source code of the include files, but the source code of the lib files (like kernel32.lib) don't. So i want to know if this lib files are from microsoft or are just private property or what?... :icon_eek:

[fearless]

So essentially there are two types of libs. Ones for static libraries and ones for dynamic libraries.

The m32lib is a static library. All the source is available as well, but once the m32 library is compiled down to its .lib file, this can be included and linked statically into your project.

The other type of library is used for dynamic link libraries - .dll files. The functions and source are compiled into a .dll file and a seperate .lib file is created as well. This .lib file holds just the stubs - the basic information to point to the functions stored in the .dll files. If you link this type of library into your project you will need to ensure the associated .dll is present (in current folder, or windows\system32 or in the path) for access to the actual functions. Without access to the source code for these, you can still access the functions (if they are documented) and you have both the .dll and associated .lib file.

So the kernel32.lib is a stub, it just holds pointers to the actual functions which are stored in kernel32.dll. So the actual source is owned by MS, but a lot of the functions are documented: see MSDN for examples of these functions. Some functions of course are not documented, but some people have discovered them. The kernel32.lib file can be found in offical MS SDKs and can also be generated by other third party utilities.

To see the actual functions in these files you probably need a disassembler or debugger.

[felipe]

Thanks a lot fearless for that great explanation!  :icon14:

[jj2007]

This .lib file holds just the stubs - the basic information to point to the functions stored in the .dll files.

There is a third option: Load the functions directly from the .dll files. The behaviour of this method can be exactly like dynamic linking - see jinvoke below. Example attached.

Code Select Expand

include \Masm32\MasmBasic\Res\JBasic.inc
Init
  jinvoke MessageBox, 0, Chr$("This code was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format"), Chr$("Dual assembly:"), MB_OK
EndOfCode

[hutch--]

The option of using the 3 API functions LoadLibrary(), GetProcAddress() and FreeLibrary() has its advantages in that it is complete dynamic linking that can be used then discarded. Efficiency in terms of size is good, being able to test if the function is available is another and improving security against hacking when done properly make it a viable option.

[jj2007]

Efficiency in terms of size is good

Indeed - see attachment, 1536 bytes both for the 32- and the 64-bit version. And this in spite of the overhead for loading the addresses.

Speedwise, it's identical, in theory the DLL should be a tick faster because the static version has one jump more:
jmp near [<&user32.MessageBoxA>]

But afaik that is only relevant for GetTickCount- the only API function that is really fast

[Vortex]

Avoiding the jump table :

Code Select Expand

.386
.model flat,stdcall
option casemap:none

include \masm32\include\windows.inc

EXTERN _imp__ExitProcess@4:PTR pr1
ExitProcess equ <_imp__ExitProcess@4>

EXTERN _imp__MessageBoxA@16:PTR pr4
MessageBox equ <_imp__MessageBoxA@16>

includelib  \masm32\lib\kernel32.lib
includelib  \masm32\lib\user32.lib

.data

_message    db 'Hello world!',0
_title      db 'Hello',0

.code

start:

    invoke  MessageBox,0,ADDR _message,ADDR _title,MB_OK
    invoke  ExitProcess,0

END start

Disassembling the object module :

Code Select Expand


_text   SEGMENT DWORD PUBLIC 'CODE'

_start  PROC NEAR
        push    0
        push    offset _title
        push    offset _message
        push    0             
        call    dword ptr [__imp__MessageBoxA@16]
        push    0                               
        call    dword ptr [__imp__ExitProcess@4]
_start  ENDP

_text   ENDS

[jj2007]

 :t

[felipe]

-"MASM32 comes with its own runtime library written fully in assembler":
This refer to m32lib?

-"It builds its own IMPORT libraries for the Windows API functions":
This refer to files in lib folder?

"and supplies its own include files for a very large number of API functions."
-This are in the include folder of course.
:redface:

[fearless]

Runtime:

masm32\include\masm32rt.inc

    The MASM32 Runtime Library include file.

    Differing from most compilers, MASM does not contain any built in
    run time library so it is difficult for a programmer starting with
    MASM to to get any code up and running without having to learn a lot
    of extra information just to do basic things.
   
    This file simplifies entry into assembler programming by making the
    full capacity of the MASM32 library, macro system and include files
    available to programmers undertaking this quest.

    It specifies the normal conditions for building a 32 bit Windows
    program with the minimum processor type, memory model and the need
    for case sensitive capacity.

    The include files are declared in the correct order so that the
    windows.inc file is always first followed by static libraries and
    import libraries for Windows API functions.

    Where there is a corresponding library for either static or import
    libraries, it is included after the include files.

    NOTE : It is to the advantage of the programmer once they have their
    basic code up and running to properly understand the architecture
    of a MASM executable file so that they can construct their own
    projects to more accurately reflect their own application design.

Yes lib folder has the import libraries for most of the windows api functions
Yes includes folder for those .inc files relating to the corresponding .lib files (mostly) in addition to windows.inc etc

[felipe]

Thanks fearless. You are the best!  :icon14:

[felipe]

So essentially there are two types of libs. Ones for static libraries and ones for dynamic libraries.

The m32lib is a static library. All the source is available as well, but once the m32 library is compiled down to its .lib file, this can be included and linked statically into your project.

-"MASM32 comes with its own runtime library written fully in assembler":
This refer to m32lib?

Runtime:

masm32\include\masm32rt.inc

    The MASM32 Runtime Library include file.

    Differing from most compilers, MASM does not contain any built in
    run time library so it is difficult for a programmer starting with
    MASM to to get any code up and running without having to learn a lot
    of extra information just to do basic things.
   
    This file simplifies entry into assembler programming by making the
    full capacity of the MASM32 library, macro system and include files
    available to programmers undertaking this quest.

    It specifies the normal conditions for building a 32 bit Windows
    program with the minimum processor type, memory model and the need
    for case sensitive capacity.

    The include files are declared in the correct order so that the
    windows.inc file is always first followed by static libraries and
    import libraries for Windows API functions.

    Where there is a corresponding library for either static or import
    libraries, it is included after the include files.[/color]

Sorry for asking twice, i guess i forgot it after reading it... :redface: