public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* RE: .def files for stdcall functions
@ 1997-09-17 17:55 Stephan Mueller
  0 siblings, 0 replies; 4+ messages in thread
From: Stephan Mueller @ 1997-09-17 17:55 UTC (permalink / raw)
  To: 'dahms@ifk20.mach.uni-karlsruhe.de', gnu-win32

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: .def files for stdcall functions
@ 1997-09-17 17:00 dahms
  0 siblings, 0 replies; 4+ messages in thread
From: dahms @ 1997-09-17 17:00 UTC (permalink / raw)
  To: gnu-win32; +Cc: 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".

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: .def files for stdcall functions
@ 1997-09-15  7:35 marcus
  0 siblings, 0 replies; 4+ messages in thread
From: marcus @ 1997-09-15  7:35 UTC (permalink / raw)
  To: gnu-win32

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: .def files for stdcall functions
  1997-09-11 23:07 .def files for stdcall functions (was: linking problems with the minimalist version) Colin Peters
@ 1997-09-12  6:09 ` root
  0 siblings, 0 replies; 4+ messages in thread
From: root @ 1997-09-12  6:09 UTC (permalink / raw)
  To: Colin Peters; +Cc: gnu-win32

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1997-09-17 17:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-09-17 17:55 .def files for stdcall functions Stephan Mueller
  -- strict thread matches above, loose matches on Subject: below --
1997-09-17 17:00 dahms
1997-09-15  7:35 marcus
1997-09-11 23:07 .def files for stdcall functions (was: linking problems with the minimalist version) Colin Peters
1997-09-12  6:09 ` .def files for stdcall functions root

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).