NO

Author Topic: Problems with DLL wizard  (Read 5971 times)

czerny

  • Guest
Problems with DLL wizard
« on: September 24, 2014, 10:00:07 AM »
I have created a dll project with the wizard (def file checked) and wrote a little test driver.

It doesn't work!

What is wrong?

laurro

  • Guest
Re: Problems with DLL wizard
« Reply #1 on: September 24, 2014, 01:14:52 PM »
Czerny working with dlls and def files is not really my thing, but, with try and error

Code: [Select]
LIBRARY "dlltest"
EXPORTS

;SampleFunction
;"_MyExportFunction@8"=SampleFunction;      ok
;_MyExportFunction@8=SampleFunction;        ok


;SampleFunction
;MyExportFunction=SampleFunction;           not ok
;"MyExportFunction"=SampleFunction;         not ok


;make an explicit decoration for SampleFunction()

_SampleFunction@8
;"_MyExportFunction@8"=_SampleFunction@8;   ok
_MyExportFunction@8=_SampleFunction@8;      ok


Now the real question is: who is she ? And please don't tell me she's you  ::)!

Laur

czerny

  • Guest
Re: Problems with DLL wizard
« Reply #2 on: September 24, 2014, 02:52:24 PM »
Czerny working with dlls and def files is not really my thing, but, with try and error
To change the def file is not the point. The def file is created by the wizard, so it sgould be ok.
don't tell me she's you  ::)!
why not?

laurro

  • Guest
Re: Problems with DLL wizard
« Reply #3 on: September 24, 2014, 05:13:05 PM »
No this is the point. Without decorations doesn't work, with, he works.
I even try with polib, the same result.
Code: [Select]
@echo off
set dir=%ProgramFiles%\PellesC\Bin
set PATH=%dir%;%PATH%
set arg=%1
echo.
echo.   %arg%
echo.
POLIB /DEF:%arg% /machine:x86 /OUT:%~n1.lib
pause
You need to drag and drop the def file in the batch if you try.

Maybe the wizard assume you will decorate latter the alias, the function
himself doesn't need to be decorated, maybe is just a mistake.
Any other opinions ?

why not?
Now i feel stupid !

Laur

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Problems with DLL wizard
« Reply #4 on: September 26, 2014, 06:40:43 PM »
The Def files interpretation in PellesC is
Quote
almost like MS
::)
This means that many things are different...
You can specify the plain function name if you want to export the symbol with its standard name, but you must specify the decorated name if you want to export it with a different name:
Code: [Select]
SampleFunction ;standard export, will create a decorated symbol export
"MyExportFunction"    = _SampleFunction@8 ;without stdcall decorations and underscore
The forward reference (export a symbol from a different dll with a different name) doesn't seem to work as specified in help file, but works including the alien library in the linker tab and exporting it:
Code: [Select]
;mybeep                = kernel32._Beep@8 ;This don't work ???
mybeep                = _Beep@8
More info can be found in the help file searching for the /DEF switch of polink.
I attach a modified project of your with some examples.

Anyway if you don't need to export functions and data with different names it's better to use the __declspec(dllexport) specifier.
Of course there is no way to link symbols without decoration unless you use the -Gm switch, in that case all functions (including stdcall and fastcall) are decorated as standard cdecl (only a prepending underscore). The problem you cannot link any other library because it will use same convention also for system functions.
« Last Edit: September 26, 2014, 06:59:19 PM by frankie »
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

czerny

  • Guest
Re: Problems with DLL wizard
« Reply #5 on: September 26, 2014, 09:44:42 PM »
Frankie: The original cause of my post was, to show, that something is wrong with the files, the wizard generats if one checks the 'def file' option. I could not find any way to access this dll without changing the def or the dll itself.

But there are furthermore a lot of questions with this dll thing!

Your def file defines 6 function names, but the dll exports only 5. Further, the exported functions of the export library are 5 too and they don't match with the dll names.

Code: [Select]
Microsoft (R) COFF Binary File Dumper Version 5.12.8078

Dump of file dlltest.dll

File Type: DLL

  Section contains the following exports for dlltest.dll

           0 characteristics
    5425B308 time date stamp Fri Sep 26 20:40:08 2014
        0.00 version
           1 ordinal base
           5 number of functions
           5 number of names

    ordinal hint RVA      name

          1    0 00001010 MyExportFunction
          2    1 00001010 SampleFunction
          3    2 00001010 _MyExportFunction@8
          4    3 00001010 _SampleFunction
          5    4 0000101E mybeep
-----------------------------------------------------------------------------------
Microsoft (R) COFF Binary File Dumper Version 5.12.8078

Dump of file dlltest.lib

File Type: LIBRARY

     Exports

       ordinal    name

                  MyExportFunction
                  _SampleFunction@8
                  _MyExportFunction@8
                  _SampleFunction
                  mybeep
-----------------------------------------------------------------------------------
PODUMP

Dump of dlltest.dll

File type: DLL

        Exported symbols for dlltest.dll

               0 characteristics
        5425B308 time date stamp (Fri Sep 26 20:40:08 2014)
            0.00 version
               1 ordinal base
               5 number of functions
               5 number of names

        ordinal  hint  address   name
              1     0  10001010  MyExportFunction
              2     1  10001010  SampleFunction
              3     2  10001010  _MyExportFunction@8
              4     3  10001010  _SampleFunction
              5     4  1000101E  mybeep
-----------------------------------------------------------------------------------
PODUMP
Dump of dlltest.lib

File type: LIB

      13 global symbols

     64C MyExportFunction
     728 _MyExportFunction@8
     798 _SampleFunction
     6BA _SampleFunction@8
     30A __IMPORT_DESCRIPTOR_dlltest
     4B8 __NULL_IMPORT_DESCRIPTOR
     64C __imp_MyExportFunction
     728 __imp__MyExportFunction@8
     798 __imp__SampleFunction
     6BA __imp__SampleFunction@8
     804 __imp_mybeep
     804 mybeep
     574 dlltest_NULL_THUNK_DATA

If I use only 1 entry in the def file:
Code: [Select]
LIBRARY "dlltest"
EXPORTS
SampleFunction
The entry in the dll  is 'SampleFunction' but in the export library '_SampleFunction@8'.

No difference with /Gn.

With /Gm switch:

The entry in the dll  is 'SampleFunction' but in the export library '_SampleFunction'.

If this all is ok, then please explain!
« Last Edit: September 26, 2014, 10:09:45 PM by czerny »

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Problems with DLL wizard
« Reply #6 on: September 28, 2014, 12:50:20 AM »
Frankie: The original cause of my post was, to show, that something is wrong with the files, the wizard generats if one checks the 'def file' option. I could not find any way to access this dll without changing the def or the dll itself.
Czerny I went too deep in the problem, to plainly answer to your original question: the wizard output cannot be linked directly because it creates a symbol without decorations.

The sample:
Code: [Select]
; TODO: Add your exports here!
"MyExportFunction"=_SampleFunction@8
Creates an undecorated symbol, 'MyExportFunction', that cannot be linked from 'C' environment (maybe it can from Fortran or Pascal unless they care for letters case). The wizard would just show that you can name the symbol the way you like. But, I agree with you, it doesn't show what the user is looking for: how to export and then link a symbol from a DLL...  :-\
Now consider that the DLL wizard is very old and not updated maybe from version 4.5. Probably originally it was clear that the preferred way to export a symbol is to use the '__declspec(dllexport)' that takes care to produce a symbol correctly decorated transparently to the user. Maybe the scopeof the generated DEF file would show a 'special' application.
The point is that you cannot link to undecorated symbols  ::), in C language is mandatory that the symbol name has a prepended underscore. If the function is a stdcall (an M$ extension because 'C' has only the cdecl), M$ standard also requires that to the symbol is appended an '@' sign followed by the decimal number of bytes used on the function call.
No difference with /Gn.
The compiler switch -Gn (n should mean 'normalize' ? ) just prepends the underscore so any type of call (cdecl, stdcall and fastcall) a cdecl or stdcall produce the same symbol name. This should be usefull to link with other compilers that doesn't perform full decoration.
With /Gm switch:
The entry in the dll  is 'SampleFunction' but in the export library '_SampleFunction'.
The compiler -Gm switch is something that I personally asked to Pelle  ;D because is usefull on some of my application made with mixed language ('C' and assembly) where I could define functions in assembler without any decoration and call them from 'C' modules (otherway I had to compute how many bytes were used in calls and add '@' and number of bytes to symbols. Very boring for fast programming  >:( ).

Now come to the real bugs I have found.

Your def file defines 6 function names, but the dll exports only 5.
First bug: is not possible to define an undecorated symbol that has the same name of the source symbol.
Code: [Select]
SampleFunction = _SampleFunction@8 ;without stdcall decorations and underscore
This DEF statement is ignored.  >:(
That's why you find only 5 symbols against 6 declarations.
Further, the exported functions of the export library are 5 too and they don't match with the dll names.
I don't understood what you mean. The exported symbols have the assigned names:
Code: [Select]
<Name you want> = <Internal name means fully decorated>
If I use only 1 entry in the def file:
Code: [Select]
LIBRARY "dlltest"
EXPORTS
SampleFunction
The entry in the dll  is 'SampleFunction' but in the export library '_SampleFunction@8'.
I have wrote it in my comments:
Code: [Select]
SampleFunction ;standard export, will create a decorated symbol export
If you specify only the plane name (the one used in the source code) the linker exports automagically the correct decorated name.

Then come the second bug: the forwarding symbols export (as explained in the help) doesn't seem to work.  >:(
With this techniqe is possible to create a symbol that exports a function from a different DLL. I would try to export the 'Beep' function from 'kernel32.dll' with a different name:
Code: [Select]
mybeep                = kernel32._Beep@8 ;This don't work
The address is not resolved when executable is loaded and program crashes!  >:(
Strangely it could work in this way:
Code: [Select]
mybeep                = _Beep@8

Anyway the use of DEF files shouldn't be the preferred way to export symbols. There are at least 4 ways to do it, and the use of a DEF file is convenient only when you need to change also DLL characteristics (see here).

If this all is ok, then please explain!
Please Czerny use some emoticons, I don't could understand if you are asking something or arguing with me...  :D
« Last Edit: September 28, 2014, 10:33:49 PM by frankie »
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 2115
Re: Problems with DLL wizard
« Reply #7 on: September 28, 2014, 11:35:37 AM »
From here.
Quote
Because the Visual C++ compiler uses name decoration for C++ functions, you must either use the decorated name as the entryname or internalname, or define the exported functions by using extern "C" in the source code. The compiler also decorates C functions that use the __stdcall calling convention with an underscore (_) prefix and a suffix composed of the at sign (@) followed by the number of bytes (in decimal) in the argument list.
So there is a problem with that Wizard.
« Last Edit: September 28, 2014, 12:11:25 PM by TimoVJL »
May the source be with you

czerny

  • Guest
Re: Problems with DLL wizard
« Reply #8 on: September 28, 2014, 01:13:44 PM »
Frankie: Could you please compact this all to a bug report?

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Problems with DLL wizard
« Reply #9 on: September 28, 2014, 10:02:45 PM »
So there is a problem with that Wizard.
Hi Timo  :D
No the wizard is not wrong, probably it shows a too much advanced as to export symbols as you like. In reality you can have written code to be called from a different language that don't use decorations, or use different once. If you have created a function to be called from pascal you don't need the prefix underscore. Pratically the wizard show how to export a function to be called from pascal.  ;)
Maybe the wizard could be updated, the sources should be available.

Moreover when I mentioned that the DEF works 'almost like M$' is not my opinion, but is what Pelle wote in the help file (look at the /DRF switch of polink).
Based on this maybe some of that I called bugs are specific to PellesC  :(
Per sure the forward reference using the form <dll name>.<Internal function name> seems to have problems.
I'll query a clarification on all this with a new thread in bug reports.
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

czerny

  • Guest
Re: Problems with DLL wizard
« Reply #10 on: September 29, 2014, 08:10:55 AM »
Pratically the wizard show how to export a function to be called from pascal.  ;)
We should differentiate between the part a def-file plays if the dll is created and the part if the export library is created. This has not be the same def-file unconditionally. The first one should produce a standard interface and the created dll should at least be usable by the same language/compiler which was used to create it.
Cobol, pascal or fortran programmers should be able to produce a convenient export library thereselfs.
So I too  would believe that there is a problem with that wizard.
Maybe the wizard could be updated, the sources should be available.
I can not find it!  :(

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 2115
Re: Problems with DLL wizard
« Reply #11 on: September 29, 2014, 09:30:06 AM »
So there is a problem with that Wizard.
Hi Timo  :D
No the wizard is not wrong, probably it shows a too much advanced as to export symbols as you like.
Maybe so, but for Win32 decoration is missing from def-file
It works for Win64
Code: [Select]
Building dllmain.obj.
Building TestDllDef1.dll.
POLINK: error: Unresolved external symbol 'SampleFunction'.
POLINK: fatal error: 1 unresolved external(s).
*** Error code: 1 ***
Done.
« Last Edit: September 29, 2014, 09:35:26 AM by TimoVJL »
May the source be with you

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Problems with DLL wizard
« Reply #12 on: September 29, 2014, 12:46:14 PM »
Timo I agree that there are some problems.
Czerny as I don't know where the sources can be, If I'll find it I'll let you know.
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide