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

GPG test - ignore
by Stefan Dösinger April 15, 2006

April 15, 2006

I wonder why the gpg signatures of the mails I send to wine-patches are wrong when I receive them back, but not wine-devel. Trying to send a mail with a small attachment to here to test. I appologise for the spam. Stefan

1 0

Re: advpack: Perform install initialization in install_init
by James Hawkins April 15, 2006

April 15, 2006

On 4/13/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Changelog: > * Add a structure to track the data for an install instance. > * Add install_init/release to perform install initialization. > Go ahead and trash all these advpack patches. There are a couple bugs, and some things I'm changing. I'll send the new patches next week. -- James Hawkins

1 0

re: Summer of Code Project: DirectPlay
by Dan Kegel April 15, 2006

April 15, 2006

Alex wrote: > This is a proposal for a Google Summer of Code Project. > > Improve Wine's DirectPlay implementation so that it can at least run a > simple demo app, and ideally end up enabling network play for a free > game demo. > A list of such demos is available here > http://wiki.winehq.org/DirectPlayGames I think Alex is suggesting a possible project idea -- he's not proposing to do it himself. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: Summer of Code Project: DirectPlay
by James Hawkins April 15, 2006

April 15, 2006

On 4/15/06, "Alexander N. Sørnes" <alex(a)thehandofagony.com> wrote: > This is a proposal for a Google Summer of Code Project. > > Improve Wine's DirectPlay implementation so that it can at least run a > simple demo app, and ideally end up enabling network play for a free > game demo. > A list of such demos is available here > http://wiki.winehq.org/DirectPlayGames > Do you mean this is a proposal for you to work on, or just throwing it out there as a suggestion? -- James Hawkins

1 0

Starcraft vs. fullscreen
by Molle Bestefich April 15, 2006

April 15, 2006

These lines could explain why Starcraft is unable to switch to fullscreen: err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 I seem to remember that BPP cannot be changed _at all_ with XRandR, is this correct? If it is, then the obvious thing to do is to leave BPP alone and just change to the correct resolution. What needs fixing here?

10 21

New SetThreadPriority patch
by Mike Hearn April 15, 2006

April 15, 2006

This one uses POSIX capabilities to drop all root privs except for CAP_SYS_NICE, therefore, this is reasonably secure. There is one catch. For some reason a suid root app cannot read /proc/self/exe so relocatability isn't used, and anyway it'd be insecure even if it could as you could hard link wineserver then trick it into loading a malicious library relative to $ORIGIN. I think I will investigate this a bit more, but perhaps later. For now this is fine for RPMs and packages etc, which install to /usr, as they can simply "chmod +s wineserver" and have apps with solid audio. thanks -mike

1 0

Re: Implement THREAD_PRIORITY_TIME_CRITICAL
by Aneurin Price April 15, 2006

April 15, 2006

Mike Hearn wrote: >> I'm not convinced this is true. At least some (maybe most or all) of >> the games showing this problem work just fine if true OSS (ie. not >> ALSA-emulated OSS) is used as the sound driver. WoW and StarCraft >> spring to mind immediately. Plus apparently they work in Cedega >> without needing to be root, though I have no first-hand experience of >> this. > > Maybe for you, but this problem seems to be related to all kinds of > things ... system speed, kernel scheduler, driver combinations, what > Wine is doing at the time etc. All I know is that this works great for > me, and no, rebuilding my kernel and going back to OSS is not really an > option :) > > Cedega, IIRC, either has some awful hacks or has the wineserver acquire > the privs, I don't remember which .... it'd be nice to find out. > > IMHO the best way would be for wineserver to be suid root and then drop > privs. It works everywhere and is simple. I really ought to remember to use reply-all for wine-devel. I've quoted my first post since I meant to send it to the list. Anyway, surely the `best' way would be for the kernel to support user-level `real-time' priorities like the ck kernels. Anybody know why they don't like the idea of that kind of thing? More on topic, does this simply change Wine's priority or does it act on a per-thread level? Most of the issues I've seen have been caused by the audio thread being starved by the others, and is often semi-solved by running Wine at nice 19, which seems counter-intuitive but appears to get around some sheduling problems (priority inversions spring to mind). This has the side effect of course that you have to make sure no other process is going to steal the cpu time from under you. Am I talking about the same issue as everyone else or have I got the wrong end of the stick?

10 36

Knights and merchants (valgrind)
by Joris Huizer April 15, 2006

April 15, 2006

Hello, As suggested earlier on the list, I ran this game with valgrind (at last I tried again with svn, which works better than trying to patch 3.1.1) There are a few problems: valgrind comes with loads of errors, but only indicates which file (*.so) the errors come from (so I need to compile wine with gdb debugger support, without optimisations, I guess?) More serious, it seems wine uses some feature currently not supported by valgrind: ----- x86toIR: unimplemented feature vex: the `impossible' happened: x86 segment override (SEG=CS) prefix vex storage: T total 1908936388 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==14207== at 0xB00170DB: (within /usr/local/lib/valgrind/x86-linux/memcheck) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==14207== at 0x480D03: ??? Thread 3: status = VgTs_WaitSys ==14207== at 0x200546A1: (within /lib/tls/libpthread-0.60.so) ==14207== by 0x202E81B7: (within /usr/local/lib/wine/ntdll.dll.so) Thread 4: status = VgTs_WaitSys ==14207== at 0x20129523: poll (in /lib/tls/libc-2.3.2.so) ==14207== by 0x23F252EF: (within /usr/local/lib/wine/wineoss.drv.so) Thread 5: status = VgTs_Runnable ==14207== at 0x2011D347: sched_yield (in /lib/tls/libc-2.3.2.so) ==14207== by 0x23F252EF: (within /usr/local/lib/wine/wineoss.drv.so) Thread 6: status = VgTs_Runnable ==14207== at 0x219840BE: (within /usr/local/lib/wine/winex11.drv.so) ==14207== by 0x23F252EF: (within /usr/local/lib/wine/wineoss.drv.so) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ----- is there a patch for this one? at least I will recompile wine with gdb debugger support and look at the errors valgrind comes with regards, Joris

1 0

Re: Dmitry Timoshkov : winspool: Add a test for GetPrinterDriver, make it pass under Wine.
by Detlef Riekenberg April 14, 2006

April 14, 2006

Am Freitag, den 14.04.2006, 12:46 -0500 schrieb Alexandre Julliard: > Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> > Date: Fri Apr 14 22:34:57 2006 +0900 > > winspool: Add a test for GetPrinterDriver, make it pass under Wine. Thanks for working on winspool.drv, but i'm Sorry that I had not enough Time to look at the Patch before the commit. - Version 0x0400 was correct for win9x-Drivers (4.00). Version 3 is for Usermode-Drivers on w2k and above. (Version 2 is Kernelmode-Driver for NT4.0 and w2k) (Version 1 is NT3.5x and Version 0 is NT 3.1) Our Registry-Location is for win9x only (OpenDriverReg) - One Terminating Zero is is not enough for REG_MULTI_SZ http://bugs.winehq.org/show_bug.cgi?id=3589 - Why was (PDRIVER_INFO_3W) changed to (PDRIVER_INFO_2W)? (PDRIVER_INFO_3W) is an extended Version of (PDRIVER_INFO_2W) - Not all Levels are supported on all Windows-Versions http://msdn.microsoft.com/library/en-us/gdi/prntspol_7xo2.asp - The tests are not alphabetical sorted after this commit - Why was SetLastError(0xdeadbeef) used, when there is SetLastError(MAGIC_DEAD) in the other tests - 11 Tests are now failing on win95, 11 Tests on win98, 9 Tests on winme and 8 Tests on NT3.51. For NT4.0 (level 4, 5 and 6 as well as the Version-Test will fail) and w2k (version will fail, when an NT4.0-Driver is used), i can not test the exact number of failures atm. What's the preferred way to fix this? My Idea: 1. Move the Test without any Changes 2. Fix the Tests 3. Fix the Implementation I know, that you want a fast fix for your commercial Application and winspool.drv is very ugly. I'm on the way to fix winspool.drv, but my Direction is going from the Bottom-Layer to the High-Level API. "struct printerenv_t" was created (as requested by Alexandre) to handle the the different Printing-Environments for win9x-Drivers (Windows 4.0) and NT-Drivers (Windows NT x86). My fix for OpenDriverReg already need an Extension here, but DeleteMonitor comes first. You can Read more Infos here: http://wiki.winehq.org/Printing -- By By ... ... Detlef

2 1

re: user: Fix disabled menu item behavior
by Dan Kegel April 14, 2006

April 14, 2006

Tommy Kho wrote: >This patch changes the behavior of selecting greyed out menu items via >accelerator key. Wine currently keeps the menu open; Windows closes the menu. > ... > else >+ { > pmt->hCurrentMenu = MENU_ShowSubPopup(pmt->hOwnerWnd, hMenu, TRUE, wFlags); >+ return -1; >+ } > >- return -1; >+ return -2; > } Err, isn't the return -2 at the bottom dead code now? That seems wrong... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1