Winelib Program with DLL problem

[Boaz Harrosh]

Kevin is right on all accounts. I can reproduce his problems here.
If I go to the foo.spec.c file produced by winebuild for the user 
application and manually change, at the big "import" structure, all the 
stdcall functions than it works. An example is do.

What was produced by winebuild:
<original foo.dll.spec.c>

static struct {
  struct {
    void        *OriginalFirstThunk;
    unsigned int TimeDateStamp;
    unsigned int ForwarderChain;
    const char  *Name;
    void        *FirstThunk;
  } imp[11];
  const char *data[109];
} imports = {
  {
   .....
    /* foo.dll */
    "\001\000fnFooC",
    "\002\000fnFooSTD",
    0,
    ....
</original foo.dll.spec.c>

change to :

<fixed foo.dll.spec.c>
   .....
    /* foo.dll */
    "\001\000fnFooC",
    "\002\000_fnFooSTD at 8",
    0,
    ....
</fixed foo.dll.spec.c>

than compilation and runtime succeeds.
So the fault is at winebuild (when doing the Import, since the .def file 
had it right) . Or is there a switch missing?

If I understood correctly the process that is done on windows. Than all 
the searching and converting of Names is done by the VC linker. Hence 
the fix should be done at winebuild.
In windows an: " int __stdcall fnFooSTD(long ,long) declaration linked 
against an import-lib of a DLL. Will look and successfully link both 
fnFooSTD (in-case a .DEF file was used in compilation of the DLL) or 
_fnFooSTD at 8. (Needless to say that an ordinal will replace a name if 
Flagged by the import-lib). winebuild successfully understood that an 
_fnFooSTD at 8 should make an fnFooSTD symbol for GCC (at the 
"asm(".data\n) section) but forgot to keep the real _fnFooSTD at 8 name for 
the import-table. Any one with a quick hand at the winebuild?

I have at hand the most simple dll compiled by VC6 (+sources) and the 
winelib app any one wants to have a look?
Please forgive me if this was already fixed since I have an old Wine (2 
month old)

Free Life
Boaz

Kevin Atkinson wrote:

>On Mon, 22 Dec 2003, Kevin Atkinson wrote:
>
>  
>
>>On Mon, 22 Dec 2003, Boaz Harrosh wrote:
>>
>>    
>>
>>>I have stdcall working fine here.
>>>
>>>  There is something wrong with your DLL the fact that "pexports" dumped 
>>>"_" before symbol names is a clue to those functions been exported as 
>>>cdecl. In stdcall (or PASCAL) no under-scored is perpended. (and you 
>>>should see the @number at end of names). check to see how this DLL was 
>>>compiled on windows (or wine). Was it compiled with a .DEF file?
>>>      
>>>
>>The DLL was compiled with Visual C++ without the .def file.  Um, if it is
>>cdecl why is the @ at the end of the names.  The DLL works just fine when
>>linked with a mingw compiled executable.
>>    
>>
>
>Also, when I make it cdecl there is NO underscore.
>
>  
>
>>Recombining the DLL with gcc is NOT an option.
>>
>>
>>    
>>
>
>  
>