RE: .def files for stdcall functions

RE: .def files for stdcall functions

[Stephan Mueller]

I believe that the most recent MSVC (5.0) supports __int64, a 64-bit
integer type.
stephan();

> -----Original Message-----
> From:	dahms@ifk20.mach.uni-karlsruhe.de
> [SMTP:dahms@ifk20.mach.uni-karlsruhe.de]
> Sent:	Wednesday, September 17, 1997 5:17 PM
> To:	gnu-win32@cygnus.com
> Cc:	dahms@ifk20.mach.uni-karlsruhe.de
> Subject:	Re: .def files for stdcall functions
> 
> Hi Jeff, you wrote:
> 
> : From:	MX%"jeffdbREMOVETHIS@netzone.com" 17-SEP-1997
> 15:16:41.32
> [My mailer doesn't allow to edit this address when replying]
> 
> : ptr=4
> : int=4
> : char=4 (unless you do something weird with
> __attribute__((__aligned__)) )
> : short = 4              "
> : long = 8
> : long long = 16 (I think)
> : float = ?
> 
> Where are these numbers from? Not from sizeof(), I suppose...
> IIRC, long=4, long long=8.
> Life would have been a lot easier, if MS had made NT 64bit-clean in
> the
> first place instead of inventing a lot of new 32bit-only APIs.
> Especially since NT runs on Alpha, and DECunix (formerly OSF/1) showed
> up
> a lot of buggy programs. I'd like to try Linux on Alpha 8-)
> BTW, MSVC doesn't understand "long long" (not sure if it is 4.0 or
> 4.2).
> 
> 
> Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
> -
> For help on using this list (especially unsubscribing), send a message
> to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: .def files for stdcall functions

[dahms]

Hi Jeff, you wrote:

: From:	MX%"jeffdbREMOVETHIS@netzone.com" 17-SEP-1997 15:16:41.32
[My mailer doesn't allow to edit this address when replying]

: ptr=4
: int=4
: char=4 (unless you do something weird with __attribute__((__aligned__)) )
: short = 4              "
: long = 8
: long long = 16 (I think)
: float = ?

Where are these numbers from? Not from sizeof(), I suppose...
IIRC, long=4, long long=8.
Life would have been a lot easier, if MS had made NT 64bit-clean in the
first place instead of inventing a lot of new 32bit-only APIs.
Especially since NT runs on Alpha, and DECunix (formerly OSF/1) showed up
a lot of buggy programs. I'd like to try Linux on Alpha 8-)
BTW, MSVC doesn't understand "long long" (not sure if it is 4.0 or 4.2).


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: .def files for stdcall functions

[marcus]

Colin Peters wrote:
> My beef with all this is: why does GCC do it this way at all? What purpose
> does the @NN serve? ....

Gunther Ebert replies:
[ a pretty reasonable argument for @NNN being useful, and]
>In fact, MSVC mangles _stdcall names in the same manner as Cygnus gcc does.

I suspect that this is the real reason that gcc does it this way...

marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: .def files for stdcall functions (was: linking problems with the minimalist version)

[Colin Peters]

Lachlan Roche[SMTP:lr-gnu@www.wwi.com.au] wrote:
>I have been trying to use opengl with the minimalist version of gcc-win32.
>
>I am using SGI GL for windows, and Mark Kilgard's glut32.dll
>
>I created my link liraries link:
>impdef opengl.dll > opengl.def
>dlltool --dllname opengl.dll --def opengl.def --output-lib libopengl.a -v
>
>There were no func@NN type symbols in the .def files
>
>when linking a trivial test program, I get many errors of the form:
>gltest.o(.text+0x24):gltest.c: undefined reference to `glBegin@4'
>
>Every function I use from libglut.a libglu.a or libopengl.a gives the same
>link error.
>
>What am I doing wrong? (Something trivial, no doubt)

The problem is not something you are doing wrong, as such, nor is it linked
to Mingw32 really. The problem is that impdef does not generate (and cannot
as far as I can figure out) .def files with that all important @NN suffix
on stdcall (or PASCAL or WINAPI) functions.

If impdef did generate the 'right' function names (e.g. "glBegin@4") then
you could generate your import library using the -k option to dlltool and
everything would work.

Unfortunately there is no way, that I can see, to automatically determine
this information (what number goes after the @) from the contents of a
DLL. You must parse the header file! (Please correct me if I'm wrong...
I'd love to be wrong about this.)

(NOTE for those unfamiliar with the way GNU-Win32 does stdcall functions,
it puts an @ followed by the number of bytes taken up on the stack by the
arguments onto the end of the function name. This has nothing to do with
the syntax used in .def files to define ordinals.)

In short, there is no easy way around this problem except to add all those
@NNs by hand after looking at the header file. Argh! You could, of course,
also write a program which attempted to call all the OpenGL functions, and
then copy the numbers off the "undefined reference" linker errors.

My beef with all this is: why does GCC do it this way at all? What purpose
does the @NN serve? After all, GCC knows how to generate the correct
function call given a prototype, it *generates* the @NN, so it doesn't
need it to know what to do. I don't think any other compilers add on @NN
to the names of WINAPI functions like this. Why doesn't GCC just use the
plain function name and call it with PASCAL calling convention? Someone
please enlighten me.

Sorry about the rant...

Colin.

-- Colin Peters - Saga Univ. Dept. of Information Science
-- colin@bird.fu.is.saga-u.ac.jp - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: .def files for stdcall functions

[root]

Mr colin peters writes:
> 
> The problem is not something you are doing wrong, as such, nor is it linked
> to Mingw32 really. The problem is that impdef does not generate (and cannot
> as far as I can figure out) .def files with that all important @NN suffix
> on stdcall (or PASCAL or WINAPI) functions.

You are right here. From the dll, there is no way to know the number of
parameters passed.
> 
> 
> Unfortunately there is no way, that I can see, to automatically determine
> this information (what number goes after the @) from the contents of a
> DLL. You must parse the header file! (Please correct me if I'm wrong...
> I'd love to be wrong about this.)

There is a way:
In the lcc-win32 package, you have that nice utility 'pedump'. If you have
the import *library* (the .lib that goes with the dll) you are *saved*!!!
Do the following:

1) pedump /A mylib.lib >ww
2) Edit that file 'ww'

  You will see at the beginning of the file a list of all functions exported
  from the library WITH THE DECORATED NAMES!, i.e. functionfoo@16 for instance.
  You will have to edit that file to suit the needs of the ascii file that 
  dlltool swallows, but this is no big deal... just a matter of erasing
  unnecessary stuff.

I have specially modified pedump so that it will dump .libs, with this 
objective in mind.
 
> 
> My beef with all this is: why does GCC do it this way at all? What purpose
> does the @NN serve? After all, GCC knows how to generate the correct
> function call given a prototype, it *generates* the @NN, so it doesn't
> need it to know what to do. I don't think any other compilers add on @NN
> to the names of WINAPI functions like this. Why doesn't GCC just use the
> plain function name and call it with PASCAL calling convention? Someone
> please enlighten me.

The _stdcall calling convention means that the called function cleans up the
stack. Since the compiler knows the number of arguments the rationale behind
this is that a call to a _stdcall function would fail to link.
For instance:
	extern _stdcall GetActiveWindow(void)
and then a call of
	hwnd = GetActiveWindow();
should generate an assembly of
	call _GetActiveWindow@0
and a wrong call like
	hwnd = GetActiveWindow(HWND_DESKTOP);
should generate an assembly of
	call	_GetActiveWindow@4

Since _GetActiveWindow@4 doesn't exist, the link would fail. 

But much more important, this convention FORCES you to use the standard 
header files, since if they are NOT used, the link will fail. 
The problem is, if you do not use the header files, the compiler will 
generate a NORMAL c call:

For instance:
Without header files
	C code:    IsWindowEnabled(hwnd);
      ASM code:    push  hwnd
                   call _IsWindowEnabled
                   add $4,%esp      <<<<<<<<<<<<<<<<<<<<<< adjust the stack
With header files:
	extern _stdcall IsWindowEnabled(HWND);
        C code:    IsWindowEnabled(hwnd);
      ASM code:    push hwnd
                   call _IsWindowEnabled@4
No stack cleanup is necessary.

If you have made a mistake and not included the header file, the consequence
is that the program will NOT LINK! You are saved from hours of debugging
trying to catch where the stack goes wild...
If gcc wouldn't follow this calling convention and generate the normal names,
gdb would get more usage, right, but what a pain in the *** !!!

I think that windows did it RIGHT here. Of course to say this is not politically
correct in this group... :-)  but is my opinion anyway!

Use pedump, and be saved.
It can be found at
http://www.remcomp.com/lcc-win32

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".