April 25, 2007
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.
April 25, 2007
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


April 26, 2007
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.

1 2
Next ›   Last »