Incomplete DEF Module Definition File example

[severach]

In the help file you show an example DEF file which includes these lines:

Code: [Select]


LIBRARY mydll.dll
EXPORTS
  myfunc2=myinternal2

I create an import file from that then dump it with %MSVC%\LINK /DUMP /ALL MYDLL.LIB /OUT:MYDLL.TMP and I see this:

Code: [Select]


  Version      : 0
  Machine      : 14C (x86)
  TimeDateStamp: 4533FE55 Mon Oct 16 16:49:09 2006
  SizeOfData   : 00000013
  DLL name     : mydll.dll
  Symbol name  : _myfunc2
  Type         : code
  Name type    : no prefix
  Hint         : 0
  Name         : myfunc2

myinternal2 is nowhere to be found. I would really like a DEF -> LIB tool that builds Microsoft LIBs which allow for user specifable aliases and DLL files as shown in the example which I can do with Borland, Watcom, and DMC. Optimal example:

Code: [Select]


; LIBRARY statement not permitted
EXPORTS _Name1InProgram@8=NTDLL._CompletelyDifferentNameInDLL1
EXPORTS _Name2InProgram@8=USER32._CompletelyDifferentNameInDLL2
EXPORTS _Name3InProgram=GDI32.@27

I don't wany any pesky librarian adding or removing decorations either.

All Microsoft Module Definition File tools ignore the right side most of the time so the Pelles help shouldn't list an example I want but can't have.

...

To answer my own question, LCC's buildlib tool can create Microsoft compatible libs with all of the above requirements: Multiple DLL's in the same LIB and any choice of aliases. LCC will produce the following import lib correctly but the Microsoft linker will only export to one of the aliases because the DLL names are dups.

Code: [Select]


MYDLLA.DLL
_DllFunc@36 = DllFuncAlias1
MYDLLB.DLL
_DllFunc@36 = DllFuncAlias2
MYDLLC.DLL
_DllFunc@36 = DllFuncAlias3


I was able to hack the import table in the exe to get the exports to map to the right DLL's.

[frankie]

PellesC actually doesn't support forwarded RVA exports.

(A forwarder RVA exports a definition from some other image, making it appear as if it were being exported by the current image. Thus, the symbol is simultaneously imported and exported).

[severach]

I don't get the meaning of a RVA export but I know that Pelles-C linker supports what I'm asking for. What I want is to eliminate the naming restrictions and name the export and the target anything I want to. Let's say I don't want to use _snprintf in the default library, I want to use the one in NTDLL instead so I write this code:

Code: [Select]


#include <stdio.h>
int __declspec(dllimport) __cdecl frobozz_snprintf(char *szDest,unsigned cchDest,char *szFormat,...);

int main(int argc,char *argv[]) {
  char str[64];
  frobozz_snprintf(str,sizeof(str),"Kingdom of Frobozz");
  printf("Result=%s\n",str);
  return 0;
}


I can map frobozz_snprintf to a snprintf of my choosing without some meddling librarian telling me what I should and shouldn't do:

Code: [Select]


#Compile with c:\WATCOM\binnt\wlib.exe -q -b -n -ic FROBOZZ-WC.LIB @FROBOZZ-WC.TXT
++_snprintf.NTDLL.._frobozz_snprintf


Microsoft tools require that the function be named _snprintf which conflicts with other DLL's and the default libraries. Why must I go to the "other brand" to accomplish something this simple?

The IMPORTS section in the DEF file was able to do this easily but support for IMPORTS only persists in DMC and just barely in BC.

What I want is for POLIB to add a switch "-LeaveMyExportsExactlyAsTheyAre" switch and let me produce libs just as it's specified in the help. Being Microsoft compatible is bad when what Microsoft does is wrong.

Here's the complete project so you can see how it works with no effort.

[frankie]

What you want is technically called a forwarded export (if you like you can consult the M$ PE spec @ http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx).
And as I told you in the previous post it is *not* actually supported in PellesC (not the librarian nor the linker supports it).
I already discussed about this issue with Pelle in an old post that has been removed on the new forum. Pelle said he doesn't see a practical use so this feature was not on the whish-list for now.
I think your post could be better suited on the feature-request section.

[severach]

>not the librarian
Right, a minor omissions covered by Watcom's librarian.

>nor the linker supports it
Wrong. Run the supplied Pelles-C project and watch it work. Clearly the Pelles linker does handle a forwarded export.

>Pelle said he doesn't see a practical use so this feature was not on the whish-list for now.

When there's no other way to do something, it's important. I more suspect that compiler writers don't like the subversive possibilites presented by the old IMPORTS section and fowarding exports. It's too easy to rip runtime libraries to shreds, aka, it's too easy to tell the compiler that you're the boss.