May 2006 - Wine-devel - list.winehq.org

RE: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSX + stack fudging -- x86 only
by Nick Burns 01 May '06

01 May '06

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

2 2

Re: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSX + stack fudging -- x86 only
by Chris Niederauer 01 May '06

01 May '06

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

3 5

dependencies on freetype and fontforge
by Robert Lunnon 01 May '06

01 May '06

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

2 3

SoC idea: run MDAC conformance test suite against MS's MDAC
by Dan Kegel 01 May '06

01 May '06

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

1 0

SoC idea: run Mauve regression tests against Sun's JRE
by Dan Kegel 01 May '06

01 May '06

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

1 0

About irp framework for safedisc support
by Vijay Kiran Kamuju 01 May '06

01 May '06

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

2 2

Start Programs reg entry
by Tom Spear (Dustin Booker, Dustin Navea) 01 May '06

01 May '06

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

2 1

server: Retrieve the groups for a token from the server
by Dan Kegel 01 May '06

01 May '06

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

1 0

Re: Summer of Code Project: DirectPlay
by Adam Luchjenbroers 01 May '06

01 May '06

> > What Windows version would you be interested in? At this point, I should probably mention that while I have a great interest in seeing DirectPlay working, I have relatively little time to work on it. I'm doing my investigations here and there, and if no-one picks up on this I'll probably work on it with what small amount of time I have free. So I'm touched by the offer, but you'd be better off offering that to someone who is more commited to the project. If however, you still want to offer me a valid Windows license, pretty much anything from 98 onwards should be fine (except NT4, and preferably not ME). -- "System Administators -- Postal workers of the computer industry" - Ricky

1 0