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

Re: Optimize Critical Section Functions

by Michael Stefaniuc

Andreas Mohr wrote: > Hi, > > On Fri, Aug 20, 2004 at 04:50:36PM +0100, Robert Shearman wrote: > >>Index: wine/dlls/ntdll/critsection.c >>=================================================================== >>RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v >>retrieving revision 1.26 >>diff -u -p -r1.26 critsection.c >>--- wine/dlls/ntdll/critsection.c 17 Jun 2004 23:11:08 -0000 1.26 >>+++ wine/dlls/ntdll/critsection.c 20 Aug 2004 15:46:18 -0000 >>@@ -36,6 +36,14 @@ >> WINE_DEFAULT_DEBUG_CHANNEL(ntdll); >> WINE_DECLARE_DEBUG_CHANNEL(relay); >> >>+#ifdef __GNUC__ >>+# define likely(x) __builtin_expect(!!(x), 1) >>+# define unlikely(x) __builtin_expect(!!(x), 0) >>+#else >>+# define likely(x) !!(x) >>+# define unlikely(x) !!(x) >>+#endif >>+ > > > Umm, this should go into a global header file, right? > The theory being that it would be useful at many more performance critical > Wine places... > > But I have to admit that I don't know which header file this should be... Like in the Linux kernel (where this seems to come from) in compiler.h or something like that. 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. 20, 2004

Re: Backtrace Dumps

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > This isn't reliable though, what about apps that swallow all exceptions > with a try/except block? Ideally you want this sort of thing to just > work and not have to figure out why your backtrace is never happening. In that case you have to start the debugger first. Of course there will be cases where it won't work as well as you'd like, you'll have the same with the in-process solution, there are many cases where it won't work. And actually the debugger solution has more chances to work reliably since being in a separate process it interferes much less with the running application. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Re: Optimization for FindFile* (resend)

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Handle case of mask containing no wildcards so that it is possible to > avoid searching through hundreds of directory entries. I'm afraid this doesn't work, you need to take the file position in the directory into account, and also update it properly (which will probably defeat the optimization). -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Re: Optimize Critical Section Functions

by Andreas Mohr

Hi, On Fri, Aug 20, 2004 at 04:50:36PM +0100, Robert Shearman wrote: > Index: wine/dlls/ntdll/critsection.c > =================================================================== > RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v > retrieving revision 1.26 > diff -u -p -r1.26 critsection.c > --- wine/dlls/ntdll/critsection.c 17 Jun 2004 23:11:08 -0000 1.26 > +++ wine/dlls/ntdll/critsection.c 20 Aug 2004 15:46:18 -0000 > @@ -36,6 +36,14 @@ > WINE_DEFAULT_DEBUG_CHANNEL(ntdll); > WINE_DECLARE_DEBUG_CHANNEL(relay); > > +#ifdef __GNUC__ > +# define likely(x) __builtin_expect(!!(x), 1) > +# define unlikely(x) __builtin_expect(!!(x), 0) > +#else > +# define likely(x) !!(x) > +# define unlikely(x) !!(x) > +#endif > + Umm, this should go into a global header file, right? The theory being that it would be useful at many more performance critical Wine places... But I have to admit that I don't know which header file this should be... Andreas Mohr

Aug. 20, 2004

Re: Move include/async.h to include/wine/async.h

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Move include/async.h to include/wine/async.h Actually that file should be removed, we don't want to share internal data structures like that. It will require some restructuring of the async I/O support though. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Mike Hearn

On Tue, 17 Aug 2004 10:06:46 +0200, Andreas Mohr wrote: > Are we doing some big no-nos in the threading area here? > (or maybe it's just done the way it is because we cannot do it a > different, better way?) > > For the whole discussion, please see > http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html Well, apparently we don't use sched_yield, so the problem must lie somewhere else. Maybe Con can help us out here? Alexandre says he doesn't know what the issue is either and somebody needs to investigate. I guess we do need to concern ourselves over the details :)

Aug. 20, 2004

Re: Different X Displays and Wine

by Eric Frias

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > "Eric Frias" <efrias(a)syncad.com> writes: > > I'm curious how much work would be involved in fixing [multiple displays] > > correctly. > > Basically you need to change the window management code in the server > to support multiple window hierarchies, and create one hierarchy per > display; then you need to associate related things like clipboard or > window classes to the proper hierarchy. It basically boils down to > implementing the Windows concept of desktops and window stations. It's > not very hard, but it's still a bit of work. Thanks... I've looked into the windowing code a bit and I think it's not something I want to attempt right now -- I certainly don't know enough about the way Windows expects desktops and window stations to be set up, and I'm not sure my knowledge of X is up to the task either. It's not the quick fix I was hoping for, so I'll just be content with the workaround with the WINEPREFIX directories. Eric

Aug. 20, 2004

Re: poll vs. epoll

by Dan Kegel

Shachar Shemesh wrote: >> 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 > > Sure will have a look. cool! i >> 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. > > > I'm sure that edge trigger yields better performance. The problem, > however, what with all the potential races edge trigger introduces, and > the fact I'm not sufficiently familiar with the wineserver semantics, > that going edge trigger in a bug free way right now is beyond me. "potential race conditions" is the wrong way to think about it, really. Switching to edge triggered epoll from select() or poll() is always an interesting intellectual challenge; you're fundamentally switching to an idiom where the app has to remember more than it did before. Once you've done it a few times, it gets easier. If I have time, I'll have a look at the state machine inside wineserver and see how tricky it'd be. - 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

winetest results refused by server

by Robert Reif

The winetest server has been refusing to accept test results for a while now. Could someone look into it.

Aug. 20, 2004

Re: RE: Adventures in serial port.

by Pouech Eric DMI AEI CAEN

> I have tried the updates but to no avail. I have a test program that > appears to work well. However when that code is used in my project I still > lose some characters at the end of the message. The main difference is that > my project uses sockets, in another thread, to transfer the read/write data > to/from another application. Could the results from the socket calls be > messing with the ReadFile() results? I will make an example program that > includes sockets to see if I can verify this. does your program (the final one, not the test) use the same buffers and/or the same events in the two threads ? As most of the read/write structures are thread-dependent, I don't really see how two threads could thrash their data, except for some buffer overflow, hence my first question. A+

Aug. 20, 2004

Re: Backtrace Dumps

by Mike Hearn

On Thu, 2004-08-19 at 17:02 -0700, Alexandre Julliard wrote: > 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. This isn't reliable though, what about apps that swallow all exceptions with a try/except block? Ideally you want this sort of thing to just work and not have to figure out why your backtrace is never happening.

Aug. 20, 2004

make CryptSetProviderEx update the provider Name and TypeName to registry

by James Hawkins

Changelog * Call provider.dll's DllRegisterServer from CryptSetProviderEx to update the Name and TypeName values in the registry properly when setting the default provider -- James Hawkins

Aug. 20, 2004

RE: Adventures in serial port.

by Scott Snell

Hi Eric, I have tried the updates but to no avail. I have a test program that appears to work well. However when that code is used in my project I still lose some characters at the end of the message. The main difference is that my project uses sockets, in another thread, to transfer the read/write data to/from another application. Could the results from the socket calls be messing with the ReadFile() results? I will make an example program that includes sockets to see if I can verify this. regards, scott. > -----Original Message----- > From: Eric Pouech [SMTP:pouech-eric(a)wanadoo.fr] > Sent: Thursday, 19 August 2004 3:14 > To: Scott Snell > Subject: Re: Adventures in serial port. > > Scott Snell a écrit : > > Fantastic! Can you let me know when it is committed? > it is

Aug. 20, 2004

Re: poll vs. epoll

by Shachar Shemesh

Dan Kegel wrote: > 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 Sure will have a look. > 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. I'm sure that edge trigger yields better performance. The problem, however, what with all the potential races edge trigger introduces, and the fact I'm not sufficiently familiar with the wineserver semantics, that going edge trigger in a bug free way right now is beyond me. > - Dan > Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 20, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Alexander Yaworsky

I think that this is incorrect. If you let StartServiceCtrlDispatcher to continue with no error, you make calling program think that it is running under control of service control manager. When service program handles somehow any kind of its launching, the behaviour may be quite different. Also, under windows StartServiceControlDispatcher always fails if service program is started not with StartService (maybe we should add 15 seconds delay to exactly emulate versions earlier than XP? ;-))). Alexander

Aug. 20, 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 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