From: Robert Shearman <[EMAIL PROTECTED]>
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
con
From: Robert Shearman <[EMAIL PROTECTED]>
Subject: Re: Feedback requested for Mac OSX x86 stack patch -- #2
Date: Thu, 08 Jun 2006 10:36:31 +0100
Nick Burns wrote:
diff -u -p -r1.114 ChangeLog
--- ChangeLog 24 May 2006 18:09:06 - 1.114
+++ ChangeLog 8 Jun 2006 07:06:10
Nick Burns wrote:
diff -u -p -r1.114 ChangeLog
--- ChangeLog 24 May 2006 18:09:06 - 1.114
+++ ChangeLog 8 Jun 2006 07:06:10 -
@@ -1,3 +1,8 @@
+2006-06-08 Nick Burns <[EMAIL PROTECTED]>
+
+ * include/windef.h:
+ If on Mac OSX (x86) use force_align_arg_pointer to fix
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
Ok I have fixed up my Mac OSX stack patch a bit as per the feedback --
thanks much
This only patches windef.h
There still needs to be some solution for msvcrt AND any other api entry
points that are not denoted with __stdcall or __cdecl or WINAPI or
WINAPIV
This means that Morrowwind (use
From: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Tue, 06 Jun 2006 12:14:47 +0200
"Nick Burns" <[EMAIL PROTECTED]> 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
From: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2006 11:40:42 +0200
"Nick Burns" <[EMAIL PROTECTED]> 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 probl
"Nick Burns" <[EMAIL PROTECTED]> 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
function
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
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 callabl
"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.
> I did not see anything forcing a cdecl calling convention (other than
> the spec file). And I dunno how to modify th
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 c
"Nick Burns" <[EMAIL PROTECTED]> 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.
>
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 th
"Nick Burns" <[EMAIL PROTECTED]> 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 start
(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
16 matches
Mail list logo
