Feedback requested for Mac OSX x86 stack patch

[Nick Burns]

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

>From: "Nick Burns" <adger44 at hotmail.com>
>To: wine-devel at winehq.org, julliard at winehq.org
>Subject: Re: Feedback requested for Mac OSX x86 stack patch
>Date: Tue, 06 Jun 2006 18:49:54 -0700
>
>>From: Alexandre Julliard <julliard at winehq.org>
>>Date: Tue, 06 Jun 2006 21:20:51 +0200
>>
>>"Nick Burns" <adger44 at hotmail.com> 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 
>language
>
>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 winehq.org
>
>- Nick
>

- Nick (again)