Although I probably should not talk to myself (responding to my own email)
Something did occur to me
From: "Nick Burns" <[EMAIL PROTECTED]>
To: wine-devel@winehq.org, [EMAIL PROTECTED]
Subject: Re: Feedback requested for Mac OSX x86 stack patch
Date: Tue, 06 Jun 2006 18:49:54 -0700
From: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Tue, 06 Jun 2006 21:20:51 +0200
"Nick Burns" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
- Nick
- Nick (again)
