(notes are at the top of the patch)
I would like some feedback on my stack fix patch
I do not know how it interacts with linux -- no access to a linux box This has been confirmed to fix numerous app issues (due to stack alignment)
I am starting to think it would be better to have these options configured at config time -- e.g. If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer
Any ideas/thoughts?
- Nick
"Nick Burns" adger44@hotmail.com writes:
(notes are at the top of the patch)
I would like some feedback on my stack fix patch
I do not know how it interacts with linux -- no access to a linux box This has been confirmed to fix numerous app issues (due to stack alignment)
I am starting to think it would be better to have these options configured at config time -- e.g. If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer
Any ideas/thoughts?
It looks OK, but it will clearly need some cleaning up. The msvcrt part should be done with function attributes too. The d3d8/d3d9 redefinitions are probably no longer necessary and should be removed. Also there are a number of functions that use __stdcall instead of WINAPI, these would need to be changed.
Thanks for the feedback... I look forward to windows apps not dieing a horrible death on Mac OSX
I was concerned about msvcrt not using the __stdcall/WINAPI for its functions (why is this?).
I am guessing the d3d8/d3d9 redefinitions should be removed?
Where can I find a list of (or affect the attribs of) windows callable functions. I thought WINAPI and WINAPIV were sufficent -- If they are not more functions will need to be 'fixed'.
From: Alexandre Julliard julliard@winehq.org Date: Mon, 05 Jun 2006 21:21:01 +0200
"Nick Burns" adger44@hotmail.com writes:
(notes are at the top of the patch)
I would like some feedback on my stack fix patch
I do not know how it interacts with linux -- no access to a linux box This has been confirmed to fix numerous app issues (due to stack
alignment)
I am starting to think it would be better to have these options configured at config time -- e.g. If Mac OSX x86 -- then use mstackrealign + force_align_arg_pointer
Any ideas/thoughts?
It looks OK, but it will clearly need some cleaning up. The msvcrt part should be done with function attributes too. The d3d8/d3d9 redefinitions are probably no longer necessary and should be removed. Also there are a number of functions that use __stdcall instead of WINAPI, these would need to be changed.
-- Alexandre Julliard julliard@winehq.org
- Nick
"Nick Burns" adger44@hotmail.com writes:
I was concerned about msvcrt not using the __stdcall/WINAPI for its functions (why is this?).
Most msvcrt functions use the cdecl calling convention, not stdcall.
Where can I find a list of (or affect the attribs of) windows callable functions. I thought WINAPI and WINAPIV were sufficent -- If they are not more functions will need to be 'fixed'.
They should be 99% sufficient, but of course the remaining 1% will be fun to chase down. There's no complete list, though maybe winapi_check could be used to verify these things, at least for functions exported from the spec files.
Ok so that makes more sense about MSVCRT -- but if it is using cdecl -- shouldnt that use WINAPIV? 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.
I have not used winapi_check before -- I can check that then.
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 (I dunno when I will have time to reform msvcrt for a full patch)
Date: Tue, 06 Jun 2006 12:14:47 +0200
"Nick Burns" adger44@hotmail.com writes:
I was concerned about msvcrt not using the __stdcall/WINAPI for its functions (why is this?).
Most msvcrt functions use the cdecl calling convention, not stdcall.
Where can I find a list of (or affect the attribs of) windows callable functions. I thought WINAPI and WINAPIV were sufficent -- If they are not more functions will need to be 'fixed'.
They should be 99% sufficient, but of course the remaining 1% will be fun to chase down. There's no complete list, though maybe winapi_check could be used to verify these things, at least for functions exported from the spec files.
-- Alexandre Julliard julliard@winehq.org
- Nick
"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.
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.
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.
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
Although I probably should not talk to myself (responding to my own email) Something did occur to me
From: "Nick Burns" adger44@hotmail.com To: wine-devel@winehq.org, julliard@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@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?
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@winehq.org
- Nick
- Nick (again)
"Nick Burns" adger44@hotmail.com writes:
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
That's probably the easiest, yes. It may well cover too many functions, but it's better to err in this direction. We'll still need to make sure all exported cdecl functions use __cdecl though.
From: Alexandre Julliard julliard@winehq.org Date: Wed, 07 Jun 2006 11:40:42 +0200
"Nick Burns" adger44@hotmail.com writes:
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
That's probably the easiest, yes. It may well cover too many functions, but it's better to err in this direction. We'll still need to make sure all exported cdecl functions use __cdecl though.
Ok I will reform my patch to be ... extra inclusive... I will modify cdecl and stdcall to use stack realignment I will not have any modifications to msvcrt (at least not yet) I will leave the redefinitions alone for the time being...
-- Alexandre Julliard julliard@winehq.org
- Nick
From: Alexandre Julliard julliard@winehq.org Date: Tue, 06 Jun 2006 12:14:47 +0200
"Nick Burns" adger44@hotmail.com writes:
I was concerned about msvcrt not using the __stdcall/WINAPI for its functions (why is this?).
Most msvcrt functions use the cdecl calling convention, not stdcall.
Ok makes sense... (I didnt notice the spec file before)
Where can I find a list of (or affect the attribs of) windows callable functions. I thought WINAPI and WINAPIV were sufficent -- If they are not more functions will need to be 'fixed'.
They should be 99% sufficient, but of course the remaining 1% will be fun to chase down. There's no complete list, though maybe winapi_check could be used to verify these things, at least for functions exported from the spec files.
I tried using winapi_check, winapi_test, winapi_... They all seemed to give me some odd perl errors (missing defs/funcs in config.pm that WERE there and were also in setup.pm) So... I stupidly went thru and made the relevant files work by copying and pasting the functions and changing def imports to setup.pm (what a pain that was -- as i dont know perl) I am guessing this should just WORK...
It seems like it would be a good idea to go thru the msvcrt functions and label the exports as WINAPIV (or __cdecl) -- im not sure what the desired convention is.
-- Alexandre Julliard julliard@winehq.org
- Nick
Nick Burns wrote:
I tried using winapi_check, winapi_test, winapi_... They all seemed to give me some odd perl errors (missing defs/funcs in config.pm that WERE there and were also in setup.pm) So... I stupidly went thru and made the relevant files work by copying and pasting the functions and changing def imports to setup.pm (what a pain that was -- as i dont know perl) I am guessing this should just WORK...
It seems like it would be a good idea to go thru the msvcrt functions and label the exports as WINAPIV (or __cdecl) -- im not sure what the desired convention is.
WINAPIV is purely for vararg functions and might not match the calling conventions of msvcrt on other platforms. You should label them with CDECL instead, as Alexandre suggested.
From: Robert Shearman rob@codeweavers.com Subject: Re: Feedback requested for Mac OSX x86 stack patch Date: Thu, 08 Jun 2006 10:29:11 +0100
Nick Burns wrote:
I tried using winapi_check, winapi_test, winapi_... They all seemed to give me some odd perl errors (missing defs/funcs in config.pm that WERE there and were also in setup.pm) So... I stupidly went thru and made the relevant files work by copying and pasting the functions and changing def imports to setup.pm (what a pain that was -- as i dont know perl) I am guessing this should just WORK...
It seems like it would be a good idea to go thru the msvcrt functions and label the exports as WINAPIV (or __cdecl) -- im not sure what the desired convention is.
WINAPIV is purely for vararg functions and might not match the calling conventions of msvcrt on other platforms. You should label them with CDECL instead, as Alexandre suggested.
Ok if thats the correct solution -- some one (either me or someone else) should patch msvcrt to have have its exported functions as CDECL (which I now believe means that its an EXTERNAL EXPORTED function) I do not want the force attrib on internal functions for no good reason... The patch as it stands is heavy handed.. and needs to be narrowed correctly -- __stdcall/__cdecl could be internal maybe sometimes?.
-- Rob Shearman
- Nick
-
Alexandre Julliard -
Nick Burns -
Robert Shearman