wine-devel May 2006

151 participants
288 discussions

RE: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSX + stack fudging -- x86 only

by Nick Burns

Here is the patch thus far -- It is not clean or anything... (cvs -q diff - straight from my tree) --I think this patch will work and allow you to run specific ogl and d3d apps (with enough stack fudging see below) --Here is an example of the stack fudging --Since this is too hard to add to all entry points... I did not bother doing it en mass (only for functions that were causing crashes for demos -- waiting for gcc goodness) void WINAPI SomeApiEntryPoint() { //begin stack alignment asm("pushl 0(%ebp)");//save ebp` asm("movl %esp, 0(%ebp)");//hope that 0(%ebp) is not used in function //save esp -- ebp -> esp -> ebp` asm("subl %ebp, %esp");//calc n asm("addl %esp, %esp");//n*2 asm("addl %ebp, %esp");//n*2+esp asm("subl $0x10, %esp");//pad out stack asm("andl $0xFFFFFFF0, %esp");//align the stack //end stack alignment ... //body ... //begin stack restore asm("movl 0(%ebp), %esp");//restore esp -- ebp -> esp -> ebp` asm("popl 0(%ebp)");//restore ebp` + esp //end stack restore return; } WEEEEEEEEE so fun - Nick

18 years

Re: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSX + stack fudging -- x86 only

by Chris Niederauer

I didn't work on this patch, but I can add some answers to Mike's questions... On Sun, 30 Apr 2006 05:32:49 -0700, Mike Hearn wrote: > On Sat, 29 Apr 2006 14:46:33 -0700, Nick Burns wrote: >> OpenGL dynamic loading >> -- Mac OSX does not need to dlsym every ogl entry point -- it >> handles >> that for you... > > Hmm, well so do Windows and Linux ;) I think it's done that way > because > some of the GL functions are introduced in later versions of OpenGL > so we > need to test for them at runtime. We can at least avoid any direct dlsym references on the Mac and simply use the glXGetProcAddress procedure. Also, for anything that is added to the OpenGL stack post 10.4.4 or whatever the first intel version of OS X was, it could avoid a huge amount of glXGetProcAddress's for the included opengl calls like glBegin, etc. Was there more to this you wanted to add, Nick? >> Stack fudging >> -- mac requires 16 byte aligned stack windows does not >> -- this leads to illegal instructions (aligned wrongly) > > This is an Intel Mac right?! Intel chips have never required > alignment as > far as I know, though it can help performance. This is not a requirement by the processor, per se, but by the OS X ABI. When a windows function attempts to call into an OS X function, the ABI must be properly set up in order to work with the OS X ABI compliant code. 16 byte alignment is one requirement of OS X's ABI: <http://developer.apple.com/documentation/DeveloperTools/Conceptual/ LowLevelABI/Articles/IA32.html> >> GLX Root Window >> -- Wine uses the fact that a root window exists in x11 in many >> places... >> -- But no one wants to run the x11 root window on their mac >> (what the >> b&w checkerz are ugly?) > > What stops you fixing the Mac X server to, well, not suck? I don't > see why > you need to hack Wine to fix this. On systems that already have roots like the Window Server on OS X and the GDI root on Windows, your system then looks like Linux. This works fine and all, but it makes it so that Mac OS X and Windows apps don't show up side by side with the linux apps. In the end, I'm sure it would be most desirable to avoid X11 on the Mac completely because it's an optional install (albeit easily installable after the fact) and it just doesn't have an OS X feel to it, which is what people would desire who are running OS X. Chris

18 years

dependencies on freetype and fontforge

by Robert Lunnon

Is it really necessary to have hard dependencies on both freetype and fontforge, configure returns a fail if either of these is missing ? I can live with a dependency on freetype since Sun supplies this lib but I'd rather not depend on fontforge, which might not be installed on a target system Bob

18 years

SoC idea: run MDAC conformance test suite against MS's MDAC

by Dan Kegel

I just added the following idea to http://wiki.winehq.org/SummerOfCode : Run the MDAC conformance test suite against Microsoft's MDAC, and file bugs / write test cases in C / fix anything it finds. (See http://msdn.microsoft.com/library/en-us/oledb/htm/oledbctconformance_test_s…, http://msdn.microsoft.com/data/mdac/ ) (This isn't a new idea; see http://www.winehq.org/pipermail/wine-devel/2005-December/043783.html) This would help folks trying to run little database apps who can't/don't want to migrate to MySQL or the like. (And I promise you, there are a bazillion folks who just want to be able to run some product's installer and just use it without trying to redirect its data source to MySQL...) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

18 years

SoC idea: run Mauve regression tests against Sun's JRE

by Dan Kegel

I just added the following idea to http://wiki.winehq.org/SummerOfCode : Run the Mauve Java test suite against Sun's Windows JRE, and file bugs / write test cases in C / fix anything it finds. (See http://sourceware.org/mauve/, http://appdb.winehq.org/appview.php?versionId=3054 ) And make it easy for other people to run these tests, too. The Mauve regression test suite would be incredibly useful as a regression test for Wine. And the many win32 apps that now depend on Java and can't just use Linux's jvm would benefit greatly, too. Oh, I so want this to happen... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

18 years

About irp framework for safedisc support

by Vijay Kiran Kamuju

Hi, I would like to know about what is required for the irp framework to be implemented for wine. I just want to put enough information so that it might be possible for someone or even me to pick-up this issue. May be this might be ready for the next years Google SOC. ;) Thanks, Vijay

18 years

Start Programs reg entry

by Tom Spear (Dustin Booker, Dustin Navea)

A while back there was a bug reported because certain installers looked in the registry for the path to the programs menu, and when they couldnt find it, they would abort the install. http://bugs.winehq.org/show_bug.cgi?id=2765 The bug was closed once a patch was committed.. Seems that now, wineprefixcreate has the same issue, and since we are using that to setup the wine environment instead of wine itself, it is causing the same problem. This should be trivial, but it is annoying having to manually add something that should be in the registry by default anyways.. I reopened the bug for now since it is an issue again and people were posting to it. Tom

18 years

server: Retrieve the groups for a token from the server

by Dan Kegel

James Hawkins wrote: On 4/26/06, Robert Shearman <rob at codeweavers.com> wrote: > ChangeLog: > Retrieve the groups for a token using a server call instead of hard > coding them. > > Before this patch, we simulated administrator's privileges in the > TokenGroups case, but we're no longer recognized as admins. I think it's a bug. The following mystery kludge "fixes" it for me: --- a/dlls/ntdll/nt.c +++ b/dlls/ntdll/nt.c @@ -203,7 +203,7 @@ NTSTATUS WINAPI NtQueryInformationToken( switch (tokeninfoclass) { case TokenGroups: - len = sizeof(TOKEN_GROUPS); + len = sizeof(TOKEN_GROUPS) + 400; /* WAG */ break; case TokenOwner: len = sizeof(TOKEN_OWNER) + sizeof(SID); i.e. you have code in there to retry a badly guessed size, but it doesn't handle all cases. That patch seems to be a missing 'break' at the end of case TokenGroup at line 320 of nt.c or so, too, but I dunno if that's an error. (If it's intended, a comment might be good.) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

18 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2006