Feedback requested for Mac OSX x86 stack patch
adger44 at hotmail.com
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 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
>(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
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 (...)
>>julliard at winehq.org
- Nick (again)
More information about the wine-devel