Hi friends,

Finally, after solving some technical problems, here is my include file to MASM import library converter - inc2lib. This tools works like Hutch's inc2l tool, the difference is that inc2lib runs Polib / Pelle's librarian which creates considerably smaller import libraries.

Other features:

- Support of full pathname
- Wildcards like *.inc are O.K.

Inc2lib accepts only filenames with the .inc extension:

inc2lib incfilename.inc

You need Polib located in c:\masm32\bin. This path pointing to the librarian can be modified, have a look at the source code.

The librarian Polib:


Polink / Pelle's MS COFF linker and MS link accepts the import libs created by inc2lib.

The linker Polink :


Many thanks to:

Pelle who developped these nice coding tools.

Hutch for encouraging me to work on this project.
Posted on 2004-01-30 05:09:40 by Vortex
polink c ant link obj or lib from
GCC gnu compiler.
Posted on 2004-01-30 15:56:12 by vilik
Doesn't the mingw32 version of GCC produce ms-coff objects, or does it still use the GNU relocation format? As for libraries... if there's a gcc version that does produce ms-coff relocations, it would be trivial to write a tool that extract gcc-libs and creates ms-libs from them.

It shouldn't be too hard writing a tool that converts gcc-coff relocation data to ms-coff data btw. Iirc, the ms-coff format has NULL as the relocation data and depends on the linker to fixup the entire value, so you could just walk the COFF symbol table for the correct type of relocations, and zero out the data.
Posted on 2004-01-30 16:13:10 by f0dder
The gcc tool, does it produce import libs with decorated names? That's is important.
Posted on 2004-01-31 02:31:55 by Vortex
Posted on 2004-01-31 17:12:08 by minimoog
Thanks for the article, I will read it.
Posted on 2004-02-01 03:03:40 by Vortex
Here is the version 1.01 of inc2lib.

-Fixed bug with the include file parser code
Posted on 2004-03-07 14:08:39 by Vortex
Version 1.2 offers an optional switch to emit module definition files with decorated names.

inc2lib incfile.inc -d

With this -d option, you get only a module definition file, not the library.

Posted on 2005-08-27 07:12:08 by Vortex
Version 1.21
- Fixed bug with include files not terminating with CR+LF

Posted on 2005-09-05 12:54:12 by Vortex
Hi Vortex,

You guys can also take a look on the LibScanner we developed for RosAsm. The goal is not to build Libraries, but it can be used as such if you want to.

It dumps all 1st, 2nd and 3rd headers for all Coff lib files. (VC, LCC, Pelles, DevC,Intel Fortran X86/Itanium, Intel CPP x86/Itanium).

The implementations of the Coff LibScanner are currently under strong development. On the actual stage you will be able to fully dump the strucured form of the Coff Lib files on a structured organization, meaning that you can assemble the full structure of the lib file on your apps, or only use it to analyse or study itīs  functionality. The goal is to reuse the results of the libscanner to improve the disassemblement results on a system we developed called DIS - Data Identification System, a sort of digital DNA of compiler identification.

The actual development version of the LibScanner contains a full unmangled representation names of the used symbols inside a .lib file, and scanned about 1200 files without errors, and we are currently working on the parsing of the common Coff Object structures.

To Build the libraries for masm (With or without undecorated names) you may only have to do this:

Example: Kernel32.lib

a) Open Kerner32.lib on the menu Tools+LibScanner.

It will display the full contents of the 1st, 2nd and 3rd Image_Linker Headers (So, it will display the small names or long names, and will tel you either the library contains only ordinal values or not)

Note: To use the library you can do two things:

1 - Copy it and paste on notepad to you simply analyse or document the results as you wish.
2 - Or copy and paste on RosAsm source editor, and place the command "Main:" to it be able to assemble the whole file as it is, or paste the result in any of your file. I mean, the results of the libscanner are assembled, not matter if they are assembled as they are, not matter if you insert it onto your projects.
3 - The generated result is under the form of The real structures of the Lib file, only adapting it to RosAsm style, and displaying the real values of some members, instead having to use the bswaped versino, like in the PublicSymbols amount, for example.

The result is under the following form:


    Tag Data. The Magic String


    First Linker Header - Names Linker Member

; This is the IMAGE_ARCHIVE_MEMBER_HEADER Structure.

; Amount of Members on the file.

; Amount of Offsets of the Public Symbols.

; RosAsm Interpretation: 'KERNEL32.lstrlenW'

; Full Undecorated Name: _lstrlenW@4

b) Once you paste the code, locate the list of public symbls avaliable from the lib.

In case of kernel32.lib it contains only the 1st and 2nd Import Linker Headers, meaning that it donīt have any Objects with Long Names. So the exported functions are located at SymOffset and SymOffset2 structures arrays.

SymOffset1 are the pointers of Public Symbols located in different Object files. So you will may find some duplicated pointers, meaning that 02 or more Publci functinos are located in the same Object File.


That means Object 745 contains 02 pointers on the same lib (__imp___lclose@4, __lclose@4). It also means that Obj745 is the one related to the exported function _lclose.

SymOffset2 are the pointers to the public function in each of the Object files. So you wonīt find duplicatinos there. Like:

To see the contents of the Object 745, all you have to do is right click on the string Obj_000746 and you will be pointed to where the Object is, like:

; Coff File. Indice: 000745

; RosAsm Interpretation: 'KERNEL32._lclose'

; Full Undecorated Name: __lclose@4

c) Building the masm lib file.

To build the masm lib file you only need to copy the contents of SymOffset2 (because it is the list of objects and by consequence the public symbols existant), and clean it to fit the masm syntax .def file. Like:

Cleaning to


d) Since you already have the amount of parameters of each functin all you have to do is build your asm file upon it. Like:

.model flat,stdcall
_lclose proc param1:BYTE
_lclose endp

_lcreat proc param1:BYTE, param2:BYTE
_lcreat endp


e) Building the masm lib file with undecorated names. This is similar to the above way. Take for example the Mfc42.lib.

; RosAsm Interpretation: 'MFC42.?classCCachedDataPathProperty@CCachedDataPathProperty@@2UCRuntimeClass@@B'

; Full Undecorated Name: public: static struct CRuntimeClass const  CCachedDataPathProperty::classCCachedDataPathProperty

I donīt know how a .def file works nor how masm can deal with undecorated namings...but accordying to http://www.geocities.com/yongweiwu/stdcall.htm you can try forcing it, like:

= ?classCCachedDataPathProperty@CCachedDataPathProperty@@2UCRuntimeClass@@B

Or something like it, that Masm can accepet. I donīt use masm for a long time, so i donīt remember exactly how to use those commands to build it under masm. But the above is a good direction.

Best Regards,

Posted on 2005-09-07 13:20:33 by Beyond2000!
Hi Guga,

Thanks for your reply. Building undecorated libraries is easy, you have to use Pelle's librarian Polib :

polib /nound /out:kernel32.lib \windows\system32\kernel32.dll

The switch nound turns off the the leading underscore feature.
Building decorated libraries with Polib using a DEF file :

LIBRARY kernel32

polib /machine:ix86 /out:kernel32.lib /def:kernel32.def
Posted on 2005-09-07 13:47:56 by Vortex
One thing.

Vortex, or anyone else...Someone have any documents of the decorated names of compilers?

I mean, iīm trying to analyse how each compiler decorate the labels, insetad having to use the API.

I already have some ideas on how VC is diferent from Borland, but i couldnīt find any document teaching how the decorated names are used for, neither which symbols are for what. (Except for the unique @XX ate the end that represents the amount of parameters, and only if this symbols is used alone)

I just parsed all VC libraries displaying a full (and huge) list of decorated labels and theyr real meanings, but without the proper documentation, this work of identification whcih symbols is related to what will be really a pain to do.

The api undecorate the symbols, giving the C representation, what iīm trying to do is identify the way it works (Without an api), and build an asm representation to be used, specially when it concerns to classes, or OOP programming.

Best Regards,


Posted on 2005-09-07 13:49:24 by Beyond2000!
A very good document by Agner Fog :

Calling conventions
This is a report describing details about calling conventions, data representations, register usage and name mangling for many different C++ compilers for 16-bit, 32-bit and 64-bit x86-based systems, including DOS, Windows, Linux and FreeBSD.

Posted on 2005-09-07 14:15:17 by Vortex
Got it

Tks Vortex :)

Best Regards,

Posted on 2005-09-07 22:10:11 by Beyond2000!
Version 1.3
- Fixed bug with function prototype parameters other than DWORD which was not recognized by the previous versions.

Notice that the tool is still case-sensitive, all the PROTO statements should be uppercase.

Posted on 2005-10-29 05:50:28 by Vortex