Feedback requested for Mac OSX x86 stack patch

Nick Burns adger44 at
Tue Jun 6 20:59:34 CDT 2006

Although I probably should not talk to myself (responding to my own email)
Something did occur to me

>From: "Nick Burns" <adger44 at>
>To: wine-devel at, julliard at
>Subject: Re: Feedback requested for Mac OSX x86 stack patch
>Date: Tue, 06 Jun 2006 18:49:54 -0700
>>From: Alexandre Julliard <julliard at>
>>Date: Tue, 06 Jun 2006 21:20:51 +0200
>>"Nick Burns" <adger44 at> writes:
>> > Ok so that makes more sense about MSVCRT -- but if it is using cdecl --
>> > shouldnt that use WINAPIV?
>>CDECL would be more appropriate.
>Well is CDECL for windows callable functions?
>I was under the impression that WINAPI/WINAPIV were used for windows 
>callable functions...
>(Where I got that impression I do not know.) Is that wrong?

If __cdecl was overridden would that affect msvcrt?

>> > I did not see anything forcing a cdecl calling convention (other than
>> > the spec file). And I dunno how to modify the spec file to add in more
>> > attribs.
>>cdecl is the default, that's why it's not specified.
>Since they are windows callable functions should they and others like them 
>be denoted as such?
>Internal functions are different then those callable from windows.
>That difference does not have to be made... But it allows for a little 
>extra performance.

Are __stdcall or __cdecl used for any internal functions?

>> > So, should I finish this patch (e.g. catch every single callable
>> > function and put the attrib on it)
>> > Or, should I send the simple 99% patch first for WINAPI/WINAPIV
>> > (removing meaningless redefs) -- I would probably ignore msvcrt for
>> > the first patch
>>Eventually of course we have to catch every function, but redefining
>>WINAPI is already a good start.
>Hmm I am seeing a few problems in this area...
>I was looking at why those undefs/redefs exist... and they are used around 
>areas where APIENTRY/WINAPI/CALLBACK are potentially used (either 
>internally or externally -- mainly by OpenGL headers or function protos).
>This may need a different fix -- sadly the c preprocessor is a very limited 
>Any ideas in this realm?

What about overriding __cdecl and __stdcall?
Are there any internal functions that use those that should not?
That would get around the APIENTRY/WINAPI/CALLBACK problem with OpenGL

The main reason I overrode WINAPI and WINAPIV was because of my previously 
mentioned impression (...)

>>Alexandre Julliard
>>julliard at
>- Nick

- Nick (again)

More information about the wine-devel mailing list