Re: OpenGL as child windows
On 12/31/06, Chris Robinson [EMAIL PROTECTED] wrote: The topic of getting OpenGL to show and use more visuals/pixel formats than just the one the main window uses came up on IRC, and I was told to make a post here. One of the ideas was to create a child window of the main X window (which can be given a different visual) and have OpenGL use that for drawing. A simple test program I wrote (using X) seems to behave well. The child window stays relative to the parent, it remains fully connected (even with the wobbly effects of compositors like Beryl), and it can use a different visual. Since wgl is now a part of x11drv, it should be possible to make an X11 child window. Are there any problems with using this approach in Wine? AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches. Damjan
Re: OpenGL as child windows
Damjan Jovanovic [EMAIL PROTECTED] wrote: AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches. That was a purely technical decision to get rid of X windows for child Win32 windows, and has fixed numerous painting and z-order related problems. If you or somebody else are really interested to go backwards, show us the code which cleanly passes 'make test' in dlls/user32 and simultaneously solves the problem for OpenGL child windows. -- Dmitry.
Re: OpenGL as child windows
On Sunday 31 December 2006 00:12, you wrote: AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches. These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it).
Re: Looking for sound testers
On Thursday, December 28, 2006 10:04, Maarten Lankhorst wrote: Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten I've given this a spin with Icewind Dale, and while it does seem to remove the underrun issues (at least I don't see them spit out anymore), the sound still stutters and crackles just as much as before. - Neil
Re: OpenGL as child windows
On Sunday December 31 2006 08:12, Damjan Jovanovic wrote: On 12/31/06, Chris Robinson [EMAIL PROTECTED] wrote: The topic of getting OpenGL to show and use more visuals/pixel formats than just the one the main window uses came up on IRC, and I was told to make a post here. One of the ideas was to create a child window of the main X window (which can be given a different visual) and have OpenGL use that for drawing. A simple test program I wrote (using X) seems to behave well. The child window stays relative to the parent, it remains fully connected (even with the wobbly effects of compositors like Beryl), and it can use a different visual. Since wgl is now a part of x11drv, it should be possible to make an X11 child window. Are there any problems with using this approach in Wine? AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches. Why not? There is no harm to create X11 subwindows for OpenGL windows. Also this is only real and correct solution (without performance penalties) for this problem and this is how all Linux programs with OpenGL child windows works (GoogleEarth for Linux for example which has same interface as in its Windows version). At least I do not know any good solution of this problem without creating X11 subwindow.
Re: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION
Hi, On Sun, Dec 31, 2006 at 05:28:23PM +0800, Dmitry Timoshkov wrote: Hello, Running RedAlert demo spits a lot of FIXMEs about converting errno 29 (ESPIPE) to STATUS_UNSUCCESSFUL. In Linux /usr/include/asm/errno.h has a comment /* Illegal seek */ for ESPIPE, so STATUS_ILLEGAL_FUNCTION seems to be the best choice. Changelog: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION. The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't indicate at all that it's supposed to be pipe-related (however it's within the numeric range of many other pipe status codes!). So, given that this is mainly a pipe status code after all I'd say that's the best we can achieve right now. Of course, what really matters is what the receiving Win32 side *usually* expects after we encountered ESPIPE, and this might turn out to differ from your conversion ;). (is there any indication that RedAlert checks for a specific status code??) Andreas Mohr
Re: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION
Andreas Mohr [EMAIL PROTECTED] wrote: The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't indicate at all that it's supposed to be pipe-related (however it's within the numeric range of many other pipe status codes!). So, given that this is mainly a pipe status code after all I'd say that's the best we can achieve right now. I haven't found anything more close is the PSDK. Of course, what really matters is what the receiving Win32 side *usually* expects after we encountered ESPIPE, and this might turn out to differ from your conversion ;). (is there any indication that RedAlert checks for a specific status code??) Looks like that my change didn't actually affected RedAlert at all, at least it was still functioning in my limited test session. -- Dmitry.
Re: OpenGL as child windows
On Sunday 31 December 2006 00:12, you wrote: AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches. These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it). The subwindow would be created from within the opengl code (e.g. wglCreateContext / SetPixelFormat). That is where it happens on Windows too and on Windows OpenGL also uses some sort of overlay. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
appdb rating inflation
The appdb says Only applications which install and run flawlessly on an out-of-the-box Wine installation make it to the Platinum list But several platinum-rated apps seem to deserve a silver or bronze rating. For instance, Call to Duty, http://appdb.winehq.org/appview.php?iVersionId=3603 has all sorts of caveats: - Punkbuster enabled Multiplayer will not work - Sound out of sync. - Runs without crashes, but only if installed as root - requires whacky third-party Loki installer; real installer fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) - with alsa, the sound lags ~ 1 second behind the game if i choose oss i got the 166 sound files missing error And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, also has lots of complaints / caveats / complicated howto's. Should we impose some standards on appdb ratings? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Resend: user32: fix return value in DialogBoxParamA if no resourcecan be found + simple test (try 2)
Louis. Lenders [EMAIL PROTECTED] wrote: As Dmitry Timoshkov (thanks for that) the SetLastError was not necessary. Here's updated patch. Probably the problem is that you need also handle both FindResourceW and LoadResource failures the same way by returning -1, and change 'return -1;' later to 'return 0;' (for invalid parent) as MSDN suggests. All that needs to be tested as well. Also DialogBoxParamW needs to be fixed as well. Probably other dialaog APIs (like DialogBoxIndirectParamAorW) need a review regarding that. -- Dmitry.
Re: OpenGL as child windows
Dmitry Timoshkov wrote: Damjan Jovanovic [EMAIL PROTECTED] wrote: AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches. That was a purely technical decision to get rid of X windows for child Win32 windows, and has fixed numerous painting and z-order related problems. If you or somebody else are really interested to go backwards, show us the code which cleanly passes 'make test' in dlls/user32 and simultaneously solves the problem for OpenGL child windows. I'm not so sure that openGL windows behave the same way as GDI. Even native has lots of visual glitches with that. Some one said they act like an overlays - which might be true. In either case, what would stop us from at least considering this as a valid option limited to openGL only? Another BTW I have not seen a single test in user32 that involves openGL. Vitaliy
Re: appdb rating inflation
Dan Kegel wrote: The appdb says Only applications which install and run flawlessly on an out-of-the-box Wine installation make it to the Platinum list But several platinum-rated apps seem to deserve a silver or bronze rating. For instance, Call to Duty, http://appdb.winehq.org/appview.php?iVersionId=3603 has all sorts of caveats: - Punkbuster enabled Multiplayer will not work - Sound out of sync. - Runs without crashes, but only if installed as root - requires whacky third-party Loki installer; real installer fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) - with alsa, the sound lags ~ 1 second behind the game if i choose oss i got the 166 sound files missing error And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, also has lots of complaints / caveats / complicated howto's. Should we impose some standards on appdb ratings? - Dan Call of Duty didn't work at all last time I tried it but that was a while ago. Diablo 2 installs fine and works perfectly but it seems far too many rather dim people try and use it or make it out to seem like you have to do a lot to make it work. It works out of the box. Even the copy protection works. Works in Single player, works in Multiplayer, works on Battle.NET, even works with mods. So it is deserving of a platinum (I can't find a fault with it). The howto is just for laymen because lots of people that have no idea how to use Linux were likely trying to install it all the time a while back. Same issue we're seeing now with WoW in the IRC channel. Ex
Re: appdb rating inflation
On 12/31/06, Dan Kegel [EMAIL PROTECTED] wrote: The appdb says Only applications which install and run flawlessly on an out-of-the-box Wine installation make it to the Platinum list But several platinum-rated apps seem to deserve a silver or bronze rating. For instance, Call to Duty, http://appdb.winehq.org/appview.php?iVersionId=3603 has all sorts of caveats: - Punkbuster enabled Multiplayer will not work - Sound out of sync. - Runs without crashes, but only if installed as root - requires whacky third-party Loki installer; real installer fails on cd change (http://bugs.winehq.org/show_bug.cgi?id=6594) - with alsa, the sound lags ~ 1 second behind the game if i choose oss i got the 166 sound files missing error And Diablo II, http://appdb.winehq.org/appview.php?iVersionId=49, also has lots of complaints / caveats / complicated howto's. Should we impose some standards on appdb ratings? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv Any app with sound issues shouldn't be rated platinum since it isn't playable without issues. Dan, are you an appdb admin? If you are interested in becoming one you can change the maintainer ratings for apps that are are misrated. Maybe we aren't clear enough on this page: http://appdb.winehq.org/help/?sTopic=maintainer_ratings since we don't say anything about how well an application runs under the Platinum rating but we do under the Gold rating description. Chris
Re: OpenGL as child windows
These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it). Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation. Mark
Re: OpenGL as child windows
These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it). Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation. Mark That would indeed be a problem. You could perhaps force that part to share the child window though that would cause other issues again. I'm not sure what pixel formats MDI apps in general use but perhaps they might need specific pixelformats for instance ones with the cap 'PFD_GDI_SUPPORT' to allow gdi rendering. If that's the case we just hide the GDI support cap and add a pixelformat with that cap set. When that pixelformat is used the current opengl behavior could be used. (Assuming our glScissors code would work correctly, this would get MDI running) Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: OpenGL as child windows
On Sunday 31 December 2006 11:44, Mark Hatsell wrote: Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation. I suppose the OpenGL window would overlap the non-X11 child window. But such a thing does not work now, nor will it ever as long as OpenGL draws directly to the main window. But this would only be an issue when the actual OpenGL window area is overlapped by something from the same parent window (a seperate popup MessageBox, for example, would still work fine). And even in Windows, OpenGL windows have problems when overlapped with other child windows.
.SYS Drivers
Is there any way to interface between the hardware and windows .SYS and .VXD device drivers ? If it is possible, I would be interested in writing the interface. -- Andrew Oh, bother, said the Borg. We've assimilated Pooh.
winbench '96 (and '97)
After trying out Winbench '99 without too much success, (http://www.winehq.org/pipermail/wine-devel/2006-December/052818.html), I managed to buy a copy of Winbench '96 on ebay for $3 or so. It seems a little closer to running -- the things that stop it appear to be more garden variety problems, not whacky COM stuff. While there aren't any more copies on ebay, I discovered that searching http://froogle.com for winbench found three books that come with a copy of the tool: Using Windows 95 : Platinum Edition (0789707977) comes with Winbench '96 Optimizing Windows 95 Windows NT 4.0 ( 0789708418) comes with Winbench '97 Tom's Hardware Guide (0789716860) comes with an unspecified version, maybe '99 (which is downloadable anyway, so maybe that's not so interesting). I guess I'll pick up a copy of that one that comes with Winbench '97 just for completeness... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
