April 2006 - Wine-Devel - list.winehq.org

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

by Willie Sippel

Am Montag, 1. Mai 2006 01:10 schrieb Mike Hearn: > On 4/30/06, Chris Niederauer <ccn(a)ccntech.com> wrote: > > The stack is allocated at least 16 byte aligned up front. The issue > > comes later when a function call occurs to OS X ABI from Windows ABI > > and the stack offset may not be 16 byte aligned. > > OK. You could fix this in winebuild as well. > > > This is because the OS X X11 simply does not allow a root window without > > covering up the nice composited window server. > > Yes, that's what I meant ... just fix X11 on MacOS to not cover it up > but still have a root window. Lots of X programs assume there is a > root window and use it for communication, that's kind of a problem > that needs to get fixed anyway. > If Jesse Allen (or someone else) creates a DIB engine for this years SoC, shouldn't that make x11drv-replacements like a quartzdrv much easier to create? -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

April 30, 2006

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

by Mike Hearn

On 4/30/06, Chris Niederauer <ccn(a)ccntech.com> wrote: > The stack is allocated at least 16 byte aligned up front. The issue > comes later when a function call occurs to OS X ABI from Windows ABI > and the stack offset may not be 16 byte aligned. OK. You could fix this in winebuild as well. > This is because the OS X X11 simply does not allow a root window without > covering up the nice composited window server. Yes, that's what I meant ... just fix X11 on MacOS to not cover it up but still have a root window. Lots of X programs assume there is a root window and use it for communication, that's kind of a problem that needs to get fixed anyway. thanks -mike

April 30, 2006

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

by Chris Niederauer

>> This is not a requirement by the processor, per se, but by the OS X >> ABI. > > I see. What a peculiar ABI. Well you can't possibly fix it the way you > currently do, just force an aligned mmap for the stack when it's first > allocated. The stack is allocated at least 16 byte aligned up front. The issue comes later when a function call occurs to OS X ABI from Windows ABI and the stack offset may not be 16 byte aligned. It needs to be realigned at this point. There is supposedly an attribute feature in the newest gcc that will allow this to occur in a robust manner and work wonders for wine's purposes when it becomes available: <http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01073.html> >> 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. > > I don't understand. The root window doesn't have to be visible, as > long as it exists for accounting purposes. It looks like Nick makes a button that he deals for reference instead of a root window, to query opengl limits and whatnot. This is because the OS X X11 simply does not allow a root window without covering up the nice composited window server. It doesn't look nice and you can't see any OS X native windows while the rooted mode is active. What I do know is that it would be nice in the long run to let users run Wine without X11, but of course that means more work for the Mac side of things. Best, Chris

April 30, 2006

Re: sfd2ttf

by Troy Rollo

On Saturday 29 April 2006 00:54, Hans Leidekker wrote: > Are we tied to sfd files in any way? Is there maybe another ascii > based font format for which a small converter to/from ttf exists? Better perhaps would be something that represents in a human-readable text format the contents of the final TTF file, with a Wine internal tool written to compile that to TTF and another to convert the original TTF to that format. -- Troy Rollo - wine(a)troy.rollo.name

April 30, 2006

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

by Mike Hearn

On 4/30/06, Chris Niederauer <ccn(a)ccntech.com> wrote: > 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. Ah yes. We do this on Linux to avoid a hard OpenGL dependency, which not everybody will have. But you know users must have this on MacOS as the GUI is not optional. > This is not a requirement by the processor, per se, but by the OS X > ABI. I see. What a peculiar ABI. Well you can't possibly fix it the way you currently do, just force an aligned mmap for the stack when it's first allocated. > 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. I don't understand. The root window doesn't have to be visible, as long as it exists for accounting purposes.

April 30, 2006

Re: server: Retrieve the groups for a token from the server

by James Hawkins

On 4/26/06, Robert Shearman <rob(a)codeweavers.com> wrote: > ChangeLog: > Retrieve the groups for a token using a server call instead of hard > coding them. > Hey Rob, Before this patch, we simulated administrator's privileges in the TokenGroups case, but we're no longer recognized as admins. Any app that calls advpack.IsNtAdmin will fail if they check the result and requie admin privileges. Is there any way to add us to the admin group by default? -- James Hawkins

April 30, 2006

Re: dependencies on freetype and fontforge

by Robert Lunnon

On Monday 01 May 2006 02:38, Eric Pouech wrote: > Robert Lunnon wrote: > > 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 > > that's being worked on, but for the time being fontforge is needed to > rebuild the wine fonts. If you don't have it, then you may get some font > related issues. > > A+ By "Font related issues" per chance do you mean no menu text :-) Well, clearly I can't distribute this way so I'd better muck-in and help fix it, what needs to be done ? Bob

April 30, 2006

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

April 30, 2006

Re: shdocvw 2: Added [get|put]_Visible implementation.

by Jacek Caban

Dimi Paun wrote: > On Sun, 2006-04-30 at 14:51 +0200, Jacek Caban wrote: > >> I also have tests showing that we do exactly what we should. The same >> applies to a few of my other similar patches. >> > > This is not as obvious to people, it would be best if you could add > explicit comments in all such cases, to avoid confusion in the future. > BTW, I was about to send the exact same comments Robert sent :) > I'll send a patch with comments. I'd prefer to add tests as well, but it has to wait for the switch to MSHTML based WebBrowser implementation (BTW that seems to be really near). Jacek

April 30, 2006

RE: DDraw, wined3d (d3d8, d3d9) and OpenGL32 in Mac OSXx86 + stack fudging

by Nick Burns

Whow sorry about messing up the patch there guys... Serves me right for posting at 3am In the future ill be a better citizen -- sorry again - Nick

April 30, 2006