From: Alexandre Julliard julliard@winehq.org Date: Tue, 06 Jun 2006 21:20:51 +0200
"Nick Burns" adger44@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?
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 julliard@winehq.org
- Nick