Pelles C forum

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
...
------------------------------------

Hi Japheth,

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

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

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

"_ExitProcess@4"

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

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.

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 :

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

> 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.

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?

Hi Japheth,

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

LIBRARY abc
EXPORTS
"Myfunction"
.
.

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

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://www.japheth.de/Download/testlink.zip

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

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

\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


> 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.

Quote from: "Vortex"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.

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

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:
_VxDCall0            @1  NONAME
to
_VxDCall0@4            @1  NONAME.

And the other exports as in the following example
HeapUnlock
to
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:

Thanks frankie for this "HeapSize" hint.

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

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

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

The modules are written in ASM, not in C.

I did some more research concerning the "decoration" issue. polink is not so dull as one may think at first glance. It is able to find the decorated form of exports in object modules given on the command line. It just doesn't find them if the module(s) containing the exported function(s) is/are located in a library. This is inconsistent of course and should be fixed.