POLINK complains about module-definition file

[japheth]

Hello,

I'm trying to link a Win32 dll with POLINK and it complains (MS link does not):

- invalid syntax near 'HeapUnlock' in module-definition file 'dkrnl32.def'

the module definition file looks quite ok and there is nothing special around the "HeapUnlock" export.

What could make POLINK so angry? I checked the file with a hex editor, but there is nothing remarkable, all lines beginning with a space, then comes the export name, then a CR/LF pair. 'HeapUnlock' is about the 290. export in the .DEF file

------------------------------------
EXPORTS
 ...
 Heap32Next
 HeapAlloc
 HeapCompact
 HeapCreate
 HeapDestroy
 HeapFree
 HeapLock
 HeapReAlloc
 HeapSize
 HeapUnlock
 HeapValidate
 HeapWalk
 InitializeCriticalSection
 ...
------------------------------------

[Vortex]

Hi Japheth,

You must enquote all the exported names when you create a module definition file :

Code: [Select]

EXPORTS
...
"Heap32Next"
"HeapAlloc"
"HeapCompact"
"HeapCreate"

If you would like to create an import library with decorated names then you should use decorated names :

Code: [Select]

"_ExitProcess@4"

Attached is an example to build kernel32.lib from kernel32.def

[japheth]

Thanks Vortex. If I really have to add the stdcall suffix ("@xx") to each export (there are 390 in the dll) then I will try another linker.

[Vortex]

Japheth,

If you have an include file containing all the prototypes of your functions, you can convert it to a def file with my inc2lib tool :

Code: [Select]

inc2lib kernel32.inc -d

inc2lib converts include files to import libraries, the -d switch is used to convert inc files to def files.

In your include files, all the PROTO statements should be uppercase to do a successfull convertion.

http://www.vortex.masmcode.com/files/inc2lib14.zip

[japheth]

> If you have an include file containing all the prototypes of your functions,

No, I don't have one. But I have an import lib (created with MS link), and can therefore possibly use your lib2def tool.

[japheth]

Your lib2def tool works, some adjustments were needed because some exports had no names, but that was minor. Polink was able to link the dll without errors, but the export names in the binary now have the stdcall decorations, which makes it unusable. Is there a way to export stdcall functions without their decorations, as MS link does?

[Vortex]

Hi Japheth,

You can export the functions with the following normal syntax to avoid decoration

Code: [Select]

LIBRARY abc
EXPORTS
"Myfunction"
.
.

Notice that Polib will add a leading underscore to the names. Polib's /NOUND switch removes the underscore.

[japheth]

Hello Vortex,

> You must enquote all the exported names when you create a module definition file :

I made a simple test case and can tell that this is *not* true. POLINK also understands the - MS link compatible - syntax without quotes. It then doesn't require the decorations in the names and there is no need to use any special parameters or tools.

So there is just still the mystery why POLINK has problems with the name "HeapUnlock" in my first post.

BTW: I also noticed that POLINK now understands and correctly handles the NONAME parameter in .DEF files. Thanks Pelle!

I put the problem case on my site (size 70 kb):

http://
http://www.japheth.de/Download/testlink.zip


all what's to do is to unzip it, then run pomake or nmake

[Vortex]

I tried to build the DLL with MS link and this is what I got :

Code: [Select]

\masm32\bin\link /MAP /DLL DKRNL32.OBJ DKRNL32S.LIB /DEF:DKRNL32.DEF /OUT:DKRNL32.DLL
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

   Creating library DKRNL32.lib and object DKRNL32.exp
DKRNL32.exp : warning LNK4070: /OUT:KERNEL32.DLL directive in .EXP differs from output filename "DKRNL32.DLL"; ignoring directive


[japheth]

> I tried to build the DLL with MS link and this is what I got :

Is this a question?

In case it is, everything is fine with your build, the warning should be ignored. The name "KERNEL32" comes from a "LIBRARY KERNEL32" statement in the DEF file. This is unrelated to the problem.

[japheth]

Can you attach the original import library?

There is no original import library. The dll ist built just from a COFF object module and a static COFF library.

[Vortex]

I understand it. Sorry for my question, I deleted my previous post.

[frankie]

japheth,
the error that you have is not due to the HeapUnlock symbol, but to the previous "HeapSize" symbol that the linker confuses with the "HEAPSIZE" command. The missing heap dimension following the command triggers the syntax error. Enclosing the symbol in quotes solves the problem.
But in my test I have 360 undefined symbols! I thing because they are not existent in the library, or better they are in decorated form. So you should change:

Code: [Select]

_VxDCall0            @1  NONAME
to

Code: [Select]

_VxDCall0@4            @1  NONAME.

And the other exports as in the following example

Code: [Select]

HeapUnlock
to

Code: [Select]

HeapUnlock = _HeapUnlock@4

As Pelle says in the help:
A module-definition file for Pelles C is almost compatible with Microsoft LINK.

Close but no banana  :mrgreen:

[japheth]

Thanks frankie for this "HeapSize" hint.

Eventually I can at least build the dll with non-MS tools. But it'll be some work.

[frankie]

japheth you can also compile with the /Gn switch that removes decoration from exported symbols.
Probably much faster :wink: