On Mon, 23 Apr 2007 15:33:53 -0400, Thomas Kühne <thomas-dloop@kuehne.cn> wrote:
> The attached program might help:
> 1) use extern(Windows) in your sources
> 2) compile
> 3) dmd_wine_fixer <your_object_file>
> 4) link
>> Thomas
I was thinking of doing something like this. Thanks, you beat me to it.
I have yet to test it because I might have to run it across dozens of files.

Chris Miller wrote:
> On Mon, 23 Apr 2007 15:33:53 -0400, Thomas Kühne <thomas-dloop@kuehne.cn> wrote:
> >> The attached program might help:
>> 1) use extern(Windows) in your sources
>> 2) compile
>> 3) dmd_wine_fixer <your_object_file>
>> 4) link
>>>> Thomas
> > I was thinking of doing something like this. Thanks, you beat me to it.
> > I have yet to test it because I might have to run it across dozens of files.
The attached version should be more useful to you because it doesn't change the infamous _d_throw@4.
(Has anybody ever succeeded in setting a break point at _d_throw@4 in GDB without looking up the address first?)
Thomas

Chris Miller wrote:
> On Mon, 23 Apr 2007 17:02:29 -0400, Anders Bergh <anders@andersman.org> wrote:
> >> __attribute__((__stdcall__)) does nothing in gcc on Linux. Windows and
>> Linux do not share the same ABI, so gcc doesn't care about that
>> attribute on non-Windows OS's as far as I know.
>>> > It's doing something here, on 32 bits. I tested it by marking a function definition as stdcall but not its prototype; it linked but did odd things before segfaulting. Matching both without stdcall or both with stdcall made it work as normal.
> > However, I did notice with 64 bits, gcc will ignore the stdcall attribute.
gcc info says:
`stdcall'
On the Intel 386, the `stdcall' attribute causes the compiler to
assume that the called function will pop off the stack space used
to pass arguments, unless it takes a variable number of arguments.