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?
> 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.
> 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?
--
Alexandre Julliard
[EMAIL PROTECTED]
- Nick
