August 2004 - Wine-Devel - list.winehq.org

Re: KERNEL: pull WINDIR and WINSYSDIR from config before using hardcoded defaults (possible fix for WWN #234, #235 c:\\windows is not accessible Error)

by Alex Villacís Lasso

Alex Villacís Lasso wrote: > Alexandre Julliard wrote: > >> Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: >> >> >> >>> Changelog: >>> * if windir or winsysdir environment vars are undefined, pull values >>> from config file before falling to hardcoded values >>> >> >> >> This of course defeats the whole purpose of the use of environment >> variables, which is to get rid of the config file. If the environment >> variables are not set it's because the user's config is wrong, they >> should be set in HKLM\System\CurrentControlSet\Control\SessionManager >> or (preferably) in HKCU\Environment. The code is supposed to migrate >> them automatically, but this may not always work if the registry >> already contains other values, in which case it needs to be fixed by >> hand. Going back to the config file is definitely not the right way. >> >> >> > Thanks for pointing me to misc/registry.c, it helped a LOT. > > Upon examination of the function convert_environment(), I realized the > following: the function > queries HKEY_CURRENT_USER/Environment with a call to NtCreateKey(). If > the call succeeds, > but the result is something other than REG_CREATED_NEW_KEY, the > function terminates in > the assumption that the environment was already migrated in a previous > invocation of Wine. > > The problem is, this assumption is false when the user has a Windows > partition for a Wine drive, > and the user has environment variables of his/her own in the registry. > For example, I am a cygwin user > and I have a Win2k registry with the variables VISUAL, CVS_RSH, and > CVSROOT already defined. > When the function sees that HKEY_CURRENT_USER/Environment already > exists (because it was > taken from the native Windows registry), it (incorrectly) skips the > migration of the config file variables. > > The obvious solution (implemented by this patch) is to remove the > assumption about > HKEY_CURRENT_USER/Environment being newly created, and instead test > for every value before > migrating. > > I hope this is definitely the right way. > > Changelog: > * Do not assume HKEY_CURRENT_USER/Environment exists ==> config file > was migrated. Instead test > for every key to migrate under HKEY_CURRENT_USER/Environment > > Alex Villacis Lasso > UPDATE: %Systemroot% should be migrated too, and this patch combines this and the previous fix. --- wine-20040813/misc/registry.c 2004-07-29 20:35:52.000000000 -0500 +++ wine-20040813-patch/misc/registry.c 2004-08-19 19:47:12.000000000 -0500 @@ -242,7 +242,7 @@ } /******************************************************************/ -/* WINDOWS 31 REGISTRY LOADER, supplied by Tor Sjøwall, tor(a)sn.no */ +/* WINDOWS 31 REGISTRY LOADER, supplied by Tor Sjwall, tor(a)sn.no */ /* reghack - windows 3.11 registry data format demo program. @@ -277,7 +277,7 @@ deduced from the reg.dat file by me. Mistakes may have been made. I claim no rights and give no guarantees for this program. - Tor Sjøwall, tor(a)sn.no + Tor Sjwall, tor(a)sn.no */ /* reg.dat header format */ @@ -1861,6 +1861,7 @@ static const WCHAR windowsW[] = {'w','i','n','d','o','w','s',0}; static const WCHAR systemW[] = {'s','y','s','t','e','m',0}; static const WCHAR windirW[] = {'w','i','n','d','i','r',0}; + static const WCHAR systemrootW[] = {'S','y','s','t','e','m','r','o','o','t',0}; static const WCHAR winsysdirW[] = {'w','i','n','s','y','s','d','i','r',0}; static const WCHAR envW[] = {'E','n','v','i','r','o','n','m','e','n','t',0}; static const WCHAR tempW[] = {'T','E','M','P',0}; @@ -1894,59 +1895,83 @@ NtClose( hkey_old ); return; } - if (disp != REG_CREATED_NEW_KEY) goto done; - /* convert TEMP */ + /* Test for existence of TEMP */ RtlInitUnicodeString( &nameW, tempW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) { - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - RtlInitUnicodeString( &nameW, tmpW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted temp dir to new entry HKCU\\Environment \"TEMP\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* convert TEMP */ + RtlInitUnicodeString( &nameW, tempW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + RtlInitUnicodeString( &nameW, tmpW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted temp dir to new entry HKCU\\Environment \"TEMP\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - /* convert PATH */ + /* Test for existence of PATH */ RtlInitUnicodeString( &nameW, pathW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) { - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted path dir to new entry HKCU\\Environment \"PATH\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* convert PATH */ + RtlInitUnicodeString( &nameW, pathW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted path dir to new entry HKCU\\Environment \"PATH\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - /* convert USERPROFILE */ - RtlInitUnicodeString( &nameW, profileW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) - { - RtlInitUnicodeString( &nameW, userprofileW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted profile dir to new entry HKCU\\Environment \"USERPROFILE\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* Test for existence of USERPROFILE */ + RtlInitUnicodeString( &nameW, userprofileW ); + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + /* convert USERPROFILE */ + RtlInitUnicodeString( &nameW, profileW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + RtlInitUnicodeString( &nameW, userprofileW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted profile dir to new entry HKCU\\Environment \"USERPROFILE\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - /* convert windir */ - RtlInitUnicodeString( &nameW, windowsW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) - { - RtlInitUnicodeString( &nameW, windirW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted windows dir to new entry HKCU\\Environment \"windir\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + /* Test for existence of windir */ + RtlInitUnicodeString( &nameW, windirW ); + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + /* convert windir */ + RtlInitUnicodeString( &nameW, windowsW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + RtlInitUnicodeString( &nameW, windirW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + RtlInitUnicodeString( &nameW, systemrootW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted windows dir to new entry HKCU\\Environment \"windir\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - - /* convert winsysdir */ - RtlInitUnicodeString( &nameW, systemW ); - if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) - { - RtlInitUnicodeString( &nameW, winsysdirW ); - NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); - MESSAGE( "Converted system dir to new entry HKCU\\Environment \"winsysdir\" = %s\n", - debugstr_w( (WCHAR*)info->Data ) ); + + /* Test for existence of winsysdir */ + RtlInitUnicodeString( &nameW, winsysdirW ); + if (NtQueryValueKey(hkey_env, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + /* convert winsysdir */ + RtlInitUnicodeString( &nameW, systemW ); + if (!NtQueryValueKey( hkey_old, &nameW, KeyValuePartialInformation, buffer, sizeof(buffer), &dummy )) + { + RtlInitUnicodeString( &nameW, winsysdirW ); + NtSetValueKey( hkey_env, &nameW, 0, info->Type, info->Data, info->DataLength ); + MESSAGE( "Converted system dir to new entry HKCU\\Environment \"winsysdir\" = %s\n", + debugstr_w( (WCHAR*)info->Data ) ); + } } - -done: NtClose( hkey_old ); NtClose( hkey_env ); }

Aug. 20, 2004

Re: poll vs. epoll

by Dan Kegel

Shachar wrote: > I noticed that in server/fd.c, the wineserver is using "poll" to select > between file descriptors. The application is going through this code > over 2000 times a second, with over 380 file descriptors each time. I am > wondering whether this can be the cause of the slowdown. > > One of the possible solutions to this would be to use epoll instead. > This, of course, would have to be backed by a configure check, as not > all systems for which wine is intended support epoll. Another, arguably > better, solution would be to use libevent for this purpose. Libevent has > the distinct advantage that it automatically chooses the best tool for > the job (epoll, poll, /dev/poll, or if all else fails, select). By all means, let's try epoll. FWIW, I wrote a wrapper layer that illustrates how to detect whether epoll etc. are available. I'm convinced that *runtime* detection is the only way to go. Compile time detection is insufficient. My code is at http://kegel.com/rn If you actually try to use it, let me know. I expect it might be useful mostly as a guide. It's edge-trigger oriented, but you can trivially add the flag (or remove the flag) needed to get level-triggered behavior again if you really need it. I highly recommend using edge-triggered behavior, though. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

Aug. 20, 2004

Re: Backtrace Dumps

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > So for this functionality you want a custom exception with a vectored > handler? A custom exception yes; there's no need for a vectored handler, the whole point is to use the normal mechanism so that the exception gets to the debugger. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Re: Info on debugging requested: trying to run "Hearts of Iron"

by Simon Kitching

On Thu, 2004-08-19 at 19:31, Andreas Mohr wrote: > Hi, > > On Thu, Aug 19, 2004 at 06:43:14PM +1200, Simon Kitching wrote: > > Backtrace: > > =>1 0x004191fb (0x406bfe94) > > 2 0x005af5b2 (0x406bff20) > All in app space, most likely. Not very useful, I'm afraid. Yes, I had leapt to the assumption that the exception was occurring within Wine code. I shouldn't have assumed that. > > And then is there a way to step through at the source rather than > > assembly level? > --> only if you have the game source ;-) If the address 0x004191fb is within wine, then presumably there will be some way to determine the source line within wine? And if it's in the game code, do people use c decompilers? Or is knowing x86 assembly code a requirement for debugging code that uses wine? > > Any suggestions on how to make progress on this issue are welcome. > If a relay trace doesn't help, then the next thing would be to disas > surrounding code at 0x004191fb and walk back the code flow to find out > where the NULL %ecx was coming from. I have some good news anyway. I still can't load the games I saved earlier. But I tried starting a new game, and can load/save happily. So the possibilities are: (a) that the problem was caused by a corrupt save-file being *created* when running with the debian wine release (Version: 0.0.20040615-1), and that now I am running with wine CVS HEAD, games are being saved properly. (b) that there is a bug in HoI, and that the saved game wouldn't have loaded on Windows anyway. I will test this theory soon by taking the save-game to a friend with a Windows copy and see what happens. It would be truly bad luck to strike an HoI bug the first time I try to run it under Wine, but stranger things have happened. (c) that the bug is wine-related, but only pops up sometimes. I can test this by playing a lot more games, and seeing if it happens again. So for now, I'm going to suspend the wine debugging, and do some more playing instead :-) Thanks for your help. Cheers, Simon

Aug. 20, 2004

Re: Backtrace Dumps

by Mike Hearn

On Wed, 18 Aug 2004 13:13:13 -0700, Alexandre Julliard wrote: > No, the backtrace should be done by the debugger. So for this functionality you want a custom exception with a vectored handler?

Aug. 19, 2004

Re: Info on debugging requested: trying to run "Hearts of Iron"

by Mike Hearn

> I ran "winedbg HoI.exe" and got exactly the same behaviour, though with > a bit more info: > <output> > First chance exception: page fault on read access to 0x00000006 in Normally means something like this: struct something *a = 0; a->some_member; (obvious I guess but I thought i'd say anyway). FWIW %ecx normally == this in C++ apps. So I'd say this was a vtable deref on a null object pointer. > 32-bit code (0x004191fb). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 > EIP:004191fb ESP:406bf4ec EBP:406bfe94 EFLAGS:00210206( - 00 - > RIP1) > EAX:48258e60 EBX:00000000 ECX:00000000 EDX:007e5f44 > ESI:418736c0 EDI:45ae16e3 > Stack dump: > 0x00000000: 00000000 00000000 00000000 00000000 > 0x00000010: 00000000 00000000 00000000 00000000 > 0x00000020: 00000000 00000000 00000000 00000000 > 0x00000030: 00000000 00000000 00000000 00000000 > 0x00000040: 00000000 00000000 00000000 00000000 > 0x00000050: 00000000 00000000 00000000 00000000 > 0x00000060: Yes well stack dumping is kinda broke by the recent debugger changes. > > Backtrace: > =>1 0x004191fb (0x406bfe94) > 2 0x005af5b2 (0x406bff20) I don't think this is Wine code. > 3 0x404ff9f2 start_process+0xf2(arg=0x0) [process.c:995] in kernel32 > (0x406bfff4) > 4 0x4002c151 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) > 0x004191fb: movl 0x6(%ecx),%ecx > Wine-dbg> > </output> > I also tried the "WINEDEBUG=+relay" option as recommended in the wine > docs. However after leaving the program running overnight, and having > generated 3 gigabytes of log output, the point where the bug occurs > hadn't been reached. I think that what's happening is that there is a > thread (0011) which is driven by timer ticks [probably doing GUI or > sound stuff], and that because HoI is running much more slowly under > +relay, that the thread doing the load-game work (0009) isn't actually > getting any CPU time at all. NB: the log was only 3GB because I used > grep to discard output about RtlEnterCriticalSection and > RtlLeaveCriticalSection. Without that, the log would be closer to 30GB! You can use RelayInclude/RelayExclude in the config file to eliminate those. > Any suggestions on how to make progress on this issue are welcome. > Pointers to documentation on debugging this sort of thing are very > welcome. It's tricky. For this sort of thing I'd normally work backwards from the disassembly but I'm not sure whether winedbg disassembly still works nicely with showing you API calls and such .... One thing would be to try and disable any sound threads by switching sound off in the game so you can get a +relay,+tid trace. thanks -mike

Aug. 19, 2004

Re: poll vs. epoll

by Mike Hearn

On Thu, 19 Aug 2004 22:16:36 +0300, Shachar Shemesh wrote: > One last question. What are the "users"? What constructs cause a new > file descriptor to be allocated in the wineserver? Every thread in every client has 3 fds: command, reply, wait. Other fds are allocated as well I think for things like open files, but I'm not sure of the details. I know that when I hit these sorts of problems it was due to the large number of threads blowing the fd limit (there were lots of sockets as well).

Aug. 19, 2004

Re: KERNEL: pull WINDIR and WINSYSDIR from config before using hardcoded defaults (possible fix for WWN #234, #235 c:\\windows is not accessible Error)

by Michael Stefaniuc

On Thu, Aug 19, 2004 at 03:54:40PM -0500, Alex Villacís Lasso wrote: > I hope this is definitely the right way. > > Changelog: > * Do not assume HKEY_CURRENT_USER/Environment exists ==> config file was > migrated. Instead test > for every key to migrate under HKEY_CURRENT_USER/Environment > > Alex Villacis Lasso > > --- wine-20040813/misc/registry.c 2004-07-29 20:35:52.000000000 -0500 > +++ wine-20040813-patch/misc/registry.c 2004-08-19 15:35:00.000000000 -0500 > @@ -242,7 +242,7 @@ > } > > /******************************************************************/ > -/* WINDOWS 31 REGISTRY LOADER, supplied by Tor Sj?wall, tor(a)sn.no */ > +/* WINDOWS 31 REGISTRY LOADER, supplied by Tor Sjwall, tor(a)sn.no */ > /* > reghack - windows 3.11 registry data format demo program. > > @@ -277,7 +277,7 @@ > deduced from the reg.dat file by me. Mistakes may > have been made. I claim no rights and give no guarantees for this program. > > - Tor Sj?wall, tor(a)sn.no > + Tor Sjwall, tor(a)sn.no Was this name change planned? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 19, 2004

Re: FontDlg fix

by Alexandre Julliard

Jacek Caban<jack(a)itma.pwr.wroc.pl> writes: > + if(chf16->lpTemplateName) > + { > + len1 = strlen(MapSL(chf16->lpTemplateName)); > + chf32w->lpTemplateName = malloc(len1 * sizeof(WCHAR)); > + MultiByteToWideChar(CP_ACP, 0, (LPSTR)MapSL(chf16->lpTemplateName), > + len1, (LPWSTR)chf32w->lpTemplateName, len1); > + } > + if(chf16->lpszStyle) > + { > + len2 = strlen(MapSL(chf16->lpszStyle)); > + chf32w->lpszStyle = malloc(len2 * sizeof(WCHAR)); > + MultiByteToWideChar(CP_ACP, 0, (LPSTR)MapSL(chf16->lpTemplateName), > + len2, chf32w->lpszStyle, len2); > + } These strings never get freed (and please use HeapAlloc instead of malloc). Also the length arguments are wrong, you can't use strlen() to determine the size of the Unicode string. There are similar problems at other places in your patch too. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2004

poll vs. epoll

by Shachar Shemesh

Hi all, I have a program (a server) that has a very large number of synchronization constructs. Even when everything is idle there, wineserver is taking 60% of the CPU, raising load average to 2.4. When load is applied, response time occasionally jumps from tenths of a second to two minutes. I noticed that in server/fd.c, the wineserver is using "poll" to select between file descriptors. The application is going through this code over 2000 times a second, with over 380 file descriptors each time. I am wondering whether this can be the cause of the slowdown. One of the possible solutions to this would be to use epoll instead. This, of course, would have to be backed by a configure check, as not all systems for which wine is intended support epoll. Another, arguably better, solution would be to use libevent for this purpose. Libevent has the distinct advantage that it automatically chooses the best tool for the job (epoll, poll, /dev/poll, or if all else fails, select). However, if there is another, independent use of poll, porting the semantics to libevent may prove non-trivial. So what does the forum think? One last question. What are the "users"? What constructs cause a new file descriptor to be allocated in the wineserver? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 19, 2004