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

Re: A question about winehq options

by Dimitrie O. Paun

On January 16, 2004 09:59 pm, Dimitrie O. Paun wrote: > Again, these are regedit-only options, no need to clutter winecfg. Of course, I was looking at the wrong part of the file when I wrote that. Here is the list of DSound options we decided to put into winecfg: [DSound] HardwareAcceleration DefaultPlayback DefaultCapture EmulDriver Please note that EmulDriver is also settable per app as well, but maybe we can ignore that as a first order approximation. For special apps that need overriding, regedit works just fine. -- Dimi.

Jan. 17, 2004

Re: winecfg: a patch to review

by Dimitrie O. Paun

On January 16, 2004 12:55 pm, Chris Morgan wrote: > I was planning to do the same to the x11 tabsheet but wasn't sure if people > actually needed to be able to specify these options per-app. Unless there > is a good reason, like there can be with dlls, global settings seem the > best for that tab. If people think this is necessary I'll take a look at > it ;-) Here is the exaustive list of per-app settings that we currently have in winecfg: [Version] Windows DOS [DllOverrides] <dllname1> <dllname2> ... [DSound] EmulDriver As you can see, there are only 4, we shouldn't complicate the UI too much for them... -- Dimi.

Jan. 17, 2004

Re: A question about winehq options

by Dimitrie O. Paun

On January 16, 2004 12:30 pm, Kirk Ruff wrote: > I am trying to work on a multimedia tab, unless someone else is > doing this already. I am wondering what options should go on this tab. A > select for the audio driver, wave mapper, and midi mapper is what I was > thinking so far. The wave/midi mapper seem to each only have 1 option so > what should I do for that? Is there any plan to add any more options to > these two? AFAIK, we've decided to not have these settings in winecfg. In general, we should be able to autodetect. If someone want additional tweaks, they can always use regedit. > The dsound options seem too obscure to be in winecfg, and I didn't > see any other obvious options to put on. Hopefully someone else hasn't > started on such a tab yet. Any help is appreciated. Again, these are regedit-only options, no need to clutter winecfg. -- Dimi.

Jan. 17, 2004

Re: Debugger doc pages

by Dimitrie O. Paun

On January 16, 2004 07:07 pm, Jason Edmeades wrote: > s it something about my machine but when I go to the online debugger > docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can > see absolutely nothing in the text boxes. I can highlight the text and > it appears to be in a minute font, and cut+paste into an editor shows me > the text is there, its just too small to be visible. It looks fine for me in Konqy, under Linux (RH9). -- Dimi.

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Frank.Schruefer＠t-online.de

> > Use tools/findfunc rather than grep to find Win32 functions in the Wine > tree. Cool, that saves me from creating crazy grep constructs. Thanks for the tip. Think I'll investigate the contents of the tools dir a bit further now ... -- Regards, Frank

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Frank.Schruefer＠t-online.de

Frank Schruefer wrote: > Hy Jason > > Really cool man! > I was following your posts here in real time and you almost found > solutions faster than > I could try them out, LOL! > > I can confirm that the screen switches and a picture shows up when using > full win-path > and the mouse acts weird. > Haven't tried commenting out anything yet. I'm trying to investigate > that GetCommandLine > thing. > So far I grep'd through the wine code but only found extern > GetCommandLineA decls. > Ok, that here is exactly the problem (dlls/kernel/environ.c), it's explained in the remark of the func: /*********************************************************************** * GetCommandLineA (KERNEL32.@) * * WARNING: there's a Windows incompatibility lurking here ! * Win32s always includes the full path of the program file, * whereas Windows NT only returns the full file path plus arguments * in case the program has been started with a full path. * Win9x seems to have inherited NT behaviour. * * Note that both Start Menu Execute and Explorer start programs with * fully specified quoted app file paths, which is why probably the only case * where you'll see single file names is in case of direct launch * via CreateProcess or WinExec. * * Perhaps we should take care of Win3.1 programs here (Win32s "feature"). * * References: MS KB article q102762.txt (special Win32s handling) */ LPSTR WINAPI GetCommandLineA(void) ... But now what to do? Low and behold I remembered that I once saw a wine config option ... and here is the part of the wine config that should influence the behaviour of the above func: [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31) ; "Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22" I tried to set 'Windows' to 'win98' and 'win2k', but that didn't make a difference, as expected when looking at the 'GetCommandLineA' source. I think the right thing would be to make 'GetCommandLineA' looking at the config how it should behave and decide in which style the value should be returned. But that there's no default setting in this version block makes me think maybe wine has a possibility to guess for which OS the executed prog was written and sets this config option automatically if not set in the config? Suggestions? -- Regards, Frank

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Vincent Béron

Le ven 16/01/2004 à 19:40, Frank Schruefer a écrit : > Hy Jason > > Really cool man! > I was following your posts here in real time and you almost found solutions faster than > I could try them out, LOL! > > I can confirm that the screen switches and a picture shows up when using full win-path > and the mouse acts weird. > Haven't tried commenting out anything yet. I'm trying to investigate that GetCommandLine > thing. > So far I grep'd through the wine code but only found extern GetCommandLineA decls. Use tools/findfunc rather than grep to find Win32 functions in the Wine tree. Vincent

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Frank.Schruefer＠t-online.de

Hy Jason Really cool man! I was following your posts here in real time and you almost found solutions faster than I could try them out, LOL! I can confirm that the screen switches and a picture shows up when using full win-path and the mouse acts weird. Haven't tried commenting out anything yet. I'm trying to investigate that GetCommandLine thing. So far I grep'd through the wine code but only found extern GetCommandLineA decls. -- Thanks a lot, Frank

Jan. 17, 2004

Debugger doc pages

by Jason Edmeades

Is it something about my machine but when I go to the online debugger docs, eg: http://www.winehq.com/site/docs/wine-devel/wine-debugger I can see absolutely nothing in the text boxes. I can highlight the text and it appears to be in a minute font, and cut+paste into an editor shows me the text is there, its just too small to be visible. I tried with mozilla and IE (both from a Windows machine). Jason

Jan. 17, 2004

Re: Need help debugging ... Ddraw issue

by Jason Edmeades

> > Note: > wine C:\\DK\\KEEPER95 gets things significantely further (flash > screen) before the next crash. > > Thats it for me on this problem, Sorry! > Jason > Bed? Whats that... I just couldnt resist. The next problem is ddraw surface fails swhen the main surface is destroyed and it has an attached palette. This is Lionels area and I really dont understand the code, but commenting out dlls\ddraw\dsurface\main.c, line 106 ie: if (This->palette) { /* Bug here: IDirectDrawPalette_Release(ICOM_INTERFACE(This->palette, IDirectDrawPalette));*/ This->palette = NULL; } Gets things working (There's probably a memory leak here too though). Then you have a weird mouse problem whereby the mouse will only go down and right BUT the game is up and running as far as the menu and you can go to eg the options panel etc. So to summarize Run DK1 with wine <fullpath>\KEEPER95 With the line above commented out Thats really it, Jason

Jan. 17, 2004

Re: DPA_Create/Search may be missing

by Rolf Kalbermatter

On Fri, 16 Jan 2004, Hans Leidekker wrote: >> Did you by any chance build the test with MinGW? >No, I compiled it with Microsoft Visual C++ 6.0. I made sure to get the >latest and complete Windows SDK too as the previous one I had was >missing 'shlwapi.h'. Well those DPA (and DSA) functions are a little bit messy. They have been exported from the DLL since the start only by ordinal except maybe with Windows XP. The original Windows 95 SDK contained them all in the import libs (but no headers with the definitions) then they disappeard entirely from the SDK and were only lately added again to the SDK documentation together with many other undocumented shell32 functions. The import libs however missed them until SDK of February 2003 and there some, namely at least DPA_Create and DPA_GetPtr are still missing, requiring an application to either load them dynamiclly by ordinal or creating a separate import lib for them at least if you want to use Visual C ;-). Wine being smarter of course creates the correct import libs for its own use based on the spec files. Rolf Kalbermatter

Jan. 16, 2004

Re: Partial MDI rewrite

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Merge the MDI and common window creation code. Change a way > MDI children are managed in MDIClient. > Add support for MDICREATESTRUCT A<->W conversions. > Add support for WM_MDIREFRESHMENU. The critical section thing worries me, especially since you are doing things that may require sending messages in there. I think you should use the normal USER lock when locking is really necessary; note that anything that is only accessed from the window procedure doesn't need locking at all. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2004

Re: Need help debugging ...

by Jason Edmeades

> The disassembly of the failure shows we have written to eax, and info > regs shows eax of 0x00. > dis 0x4e4a20 shows the routine where the return value is set up in > eax, and some debugging shows the initial problem is a path problem. > The routine parses the input path which inder windows is > c:\path\to\KEEPER95.exe and under wine is KEEPER95. It searches > backwards for the last backslash and returns a pointer to the > backslash or 0x00. If 0x00, the trap occurs... > > Now the question is where does the full path come from. > Hmmm. Following the path we are playing with back a bit, it is built up and looks extremely like the command line (Since if I add command line options, they are added as an array to where this comes from).. In fact, I can get back to an address where at the very first breakpoint the full path is in the place it will be eventually copied from. Now a simple test pgm: void main(int count, char *argv[]) { printf("Argv[0] = %s\n", argv[0]); } Shows that you only get the program name when run, so it leaves the question how the full path is supplied. With some experimentation with a GUI pgm I think I stumbled upon the / an answer: Bug#1 - GetCommandLine() returns a full path on Windows but no path on Wine Bug#2 (which will fix bug #1) - Wines PEB stores the short path not the full path Playing with windbg (then ctrl+E to load executable), the peb on windows shows the peb->CommandLine is the full path. I suspect this must be the bug then, but I cant see the app is accessing this, unless it goes to the PEB directly. eg: 0:000> !peb PEB at 7ffdf000 WindowTitle: 'C:\temp\wine\dk\test.exe' ImageFile: 'C:\temp\wine\dk\test.exe' CommandLine: 'C:\temp\wine\dk\test.exe ' However, changing anything to do with paths on wine is an art form to itself, so I will leave the fix to someone else! Note: wine C:\\DK\\KEEPER95 gets things significantely further (flash screen) before the next crash. Thats it for me on this problem, Sorry! Jason PS Anyone know if MSDEV has the ability to debug pgms under wine yet? PPS I really wish the winedbg had a memory dump routine (bytes + ascii)... is it possible with the cmd set available?

Jan. 16, 2004

Re: DPA_Create/Search may be missing

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry > points for DPA_Create and DPA_Search. So we need to link them > dynamically if we want the rest of the tests to run. What version of comctl32 is that? -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2004

Re: slight trouble running winetests under windows

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > I explored that possibility some time ago. Moving to dlls/ implies > using a spec file, because I don't think we want to use anything other > than a standard Makefile under dlls/, right? This puzzled me since > uuids are not functions and although spec syntax allows specification > of data entry points ('extern'), winebuild doesn't support importing > them. Using the standard Makefile will also give us a DSO which we > don't need. No, we wouldn't want to use a standard Makefile (note that we are not using one now in libs/ either, a static lib is special either way), so there's a bit of work involved to make this work right. I'll try to find the time to do it. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2004

Re: Implement LockWindowUpdate [take 3]

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > That went over my head I'm afraid. What do you mean by concerned? A DC would be concerned if it could have its visible region changed by the fact that the lock window is set, so this would be basically any DC used by the old and new lock windows and all their visible children. > Could you have told me this when I first submitted my patch? I feel it's > been a bit of a waste of time now - looking at the code it seems that > inter-process invalidation is not trivial thing. Pretty much nothing in the painting code is trivial I'm afraid... -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2004

Re: Need help debugging ...

by Jason Edmeades

Hope you dont mind, I was bored and its a small download (DK1). The disassembly of the failure shows we have written to eax, and info regs shows eax of 0x00. dis 0x4e4a20 shows the routine where the return value is set up in eax, and some debugging shows the initial problem is a path problem. The routine parses the input path which inder windows is c:\path\to\KEEPER95.exe and under wine is KEEPER95. It searches backwards for the last backslash and returns a pointer to the backslash or 0x00. If 0x00, the trap occurs... Now the question is where does the full path come from. Jason

Jan. 16, 2004

[Fwd: Bug#224498: A recipe of potential use to MS Office 97 aspiring users on Debian]

by Ove Kaaven

-----Videresendt melding----- From: Emmanuel Charpentier <charpent(a)bacbuc.dyndns.org> To: 224498(a)bugs.debian.org Cc: ovek(a)arcticnet.no Subject: Bug#224498: A recipe of potential use to MS Office 97 aspiring users on Debian Date: Mon, 12 Jan 2004 23:16:44 +0100 Dear Ove, dear Wine users and w(h)iners, First, a big "Thank you" to Ove : maintaining a Debian package is work, and maintaining a beast such as Wine is *hard* work. I feel very grateful to Debian maintainers, and to Ove. I have read the bug report about MS Office and the consecutive somewhat heated argument. While I won't delve in the "necessities" of using MS programs, I agree that there is not yet a free tool able to reach into .mdb databases sent by people you can't demand another format. (Yes, I'm aware of the .mdb tools. They crash on me any time I try to use them on a French .mdb ...). Ant that might be justification enough to try to get Wine working with that piece of s...oftware. The following recipe *might* help people not yet able to get rid of MS Office. Start by getting the latest (20031212) version of wine (that's in unstable for you, Debian users ...). This version seems to be a *vast* improvement over whatever I tried before (last time was summer '03, IIRC). You will need a working Windows 98 installation (for which, of course, you have a valid license...). But you'll have to start with a fresh no-windows installation. The simplest way I found is to rename any previous .wine/config file and .wine/fake-windows directory, then to call winsetup and to ask for the creation of a new config file without Windows installation. Starting from here, install from the MS cdrom : wine /cdrom/install.exe. This installation will copy a lot of files, then FAIL. That's not a problem. You'll then grab the following files from your working Windows installation: - stdole32.tlb (This one is the only one needed for Winword, Powerpoint and maybe Excel). - ole32.dll - vbajet32.dll (and maybe vba332.dll (that's not a typo), can't recall at the moment). - oleaut32.dll - msacnv30.dll - tzisolat.dll - (maybe) odbc.dll IIRC, all of this, except vba332.dll come from the \Windows\System directory of your native Win98 installation and go to .wine/fake_windows/Windows/System directory. In the .wine/config file, mark these libraries as "native,builtin" in the [DLLOverrides] section. Restart the installation of MS Office from the CD. This time, the installation should work (and be much faster than the first time around, since almost all file already exist). It will complaint that it cannot DDE-connect to the desktop (in order to create the shortcuts), but that's harmless : just hit "Ignore". The first launch of the applications may be painful : at first run, MS Office apps try to launch a "helpful" dialog box "presenting" the application, which have trouble communicating with the main program. I found that minimizing and restoring the main window may help. Don't ask me why. As far as my limited test can tell, Winword and Powerpoint work fine. With the relevant fonts in xfs and a correct CUPS setup, printing is automatic and gives very good results. MS Access still gives me guff : I have Cyrillic characters in place of Western accented characters, form creation dialog boxes have serious quirks (e. g. the "Properties" dialog box fights for focus with the "Save as" dialog box in Design mode), I had a crash trying to display an "outer join" view, etc ... But that is infinitely better that no MS Access at all ... I have now some hope of solving some of these hurdles. The SR1 and SR2 "service packs" can be installed with no problems. Hoping this helps, Emmanuel Charpentier PS : Ove, if you think this might be of interest elsewhere, and does not step too rudely on the (very) sensitive toes of DFSG and Social Contract, please feel free to forward to any relevant place, cut and paste or paraphrase at will ... PPS : Mandatory disclaimer : I found this by trial and error. I might be wrong. But that's my problem. Now, I won't accept *ANY* responsibility for the (mis-)use you may make of this information, either technical or legal. In other words, you're on your own : if this blows your system, drowns your basement, launches against you a thousand of ships full of angered Microsoft lawyers, shaves your cat or rapes your grandma (or vice-versa), that's *YOUR* problem, buddy, not mine.

Jan. 16, 2004

Re: Need help debugging ...

by Eric Pouech

> Eric, could you please submit that patch? Even if it's not correct, having > the debuggers out of action like this is causing big problems. I won't submit the patch as it today: - too hacky - not correct (we use the debugger thread environment, while we should use the debuggees environment. This shouldn't be too much an issue in most of the cases, except if you debug on a remote machine using the gdb proxy stuff) - there's an easy workaround with WINELOADER env variable the proper fix could be to: - add a mechanism while loading an image (from disk) to check it's the same one as the one of the debuggee - then, use that to test both wine-pthread and wine-kthread A+

Jan. 16, 2004

Debugger bugs.

by Frank.Schruefer＠t-online.de

Hy, I've stumbled over problems trying to debug RtlCreateUserThread. The error I get depends on how I'm stepping through the code but seems to be caused by the syscall __NR_rt_sigprocmask (int 0x80 with eax=175). The thread for which procmask should get set is created by TIME_MMTimeStart in winmm/time.c; Unfortunately I've no idea whether that's "normal" or how to fix ... If you want me to provide more info just tell me what you need to know. I got three versions (common trace of all three versions see below): ========= FIRST VERSION: Stepping over 'sigprocmask( SIG_BLOCK, &block_set, &old_set );' ============= ... (COMMON TRACE) ... Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> err:seh:setup_exception stack overflow 192 bytes in thread 000b eip 4023035b esp 405e0f40 stack 0x405e0000-0x406e0000 Invalid address for breakpoint 0, disabling it Invalid address for breakpoint 1, disabling it Invalid address for breakpoint 2, disabling it Invalid address for breakpoint 3, disabling it Process of pid=0000000a has terminated Wine-dbg> ====================================================================================================== ========= SECOND VERSION: Stepping over 'int 0x80' with eax=0xAF (=175) ============================== ... (COMMON TRACE) ... Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg>si 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc81 (wine_server_call+0x22 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc82 (wine_server_call+0x23 [server.c:244] in NTDLL.DLL): leal 0x5884(%ebx),%eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc88 (wine_server_call+0x29 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc89 (wine_server_call+0x2a [server.c:244] in NTDLL.DLL): pushl $0x0 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc8b (wine_server_call+0x2c [server.c:244] in NTDLL.DLL): call 0x40211788 (_init+0x46c in ntdll.dll.so) 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 0x40211788 (_init+0x46c in ntdll.dll.so): jmp *0x11c(%ebx) Wine-dbg> 0x400cdb10 (NTDLL.DLL.toupper+0x64a0 in libc.so.6): pushl %ebp Wine-dbg> 0x400cdb11 (NTDLL.DLL.toupper+0x64a1 in libc.so.6): movl %esp,%ebp Wine-dbg> 0x400cdb13 (NTDLL.DLL.toupper+0x64a3 in libc.so.6): subl $8,%esp Wine-dbg> 0x400cdb16 (NTDLL.DLL.toupper+0x64a6 in libc.so.6): movl %esi,0x0(%esp) Wine-dbg> 0x400cdb19 (NTDLL.DLL.toupper+0x64a9 in libc.so.6): movl $0x8,%esi Wine-dbg> 0x400cdb1e (NTDLL.DLL.toupper+0x64ae in libc.so.6): movl %edi,0x4(%esp) Wine-dbg> 0x400cdb22 (NTDLL.DLL.toupper+0x64b2 in libc.so.6): movl 0x8(%ebp),%edi Wine-dbg> 0x400cdb25 (NTDLL.DLL.toupper+0x64b5 in libc.so.6): movl 0xc(%ebp),%ecx Wine-dbg> 0x400cdb28 (NTDLL.DLL.toupper+0x64b8 in libc.so.6): movl 0x10(%ebp),%edx Wine-dbg> 0x400cdb2b (NTDLL.DLL.toupper+0x64bb in libc.so.6): xchgl %ebx,%edi Wine-dbg> 0x400cdb2d (NTDLL.DLL.toupper+0x64bd in libc.so.6): movl $0xaf,%eax Wine-dbg> 0x400cdb32 (NTDLL.DLL.toupper+0x64c2 in libc.so.6): int $0x80 Wine-dbg> fixme:seh:UnhandledExceptionFilter Unhandled error on debug event: 0 0x400cdb36 (NTDLL.DLL.toupper+0x64c6 in libc.so.6): cmpl $-4096,%eax Wine-dbg> ====================================================================================================== ========= THIRD VERSION: Stepping into 'int 0x80' with eax=0xAF (=175) =============================== ... (COMMON TRACE) ... Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg>si 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc81 (wine_server_call+0x22 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc82 (wine_server_call+0x23 [server.c:244] in NTDLL.DLL): leal 0x5884(%ebx),%eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc88 (wine_server_call+0x29 [server.c:244] in NTDLL.DLL): pushl %eax 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc89 (wine_server_call+0x2a [server.c:244] in NTDLL.DLL): pushl $0x0 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); 0x4024cc8b (wine_server_call+0x2c [server.c:244] in NTDLL.DLL): call 0x40211788 (_init+0x46c in ntdll.dll.so) 244 sigprocmask( SIG_BLOCK, &block_set, &old_set ); Wine-dbg> 0x40211788 (_init+0x46c in ntdll.dll.so): jmp *0x11c(%ebx) Wine-dbg> 0x400cdb10 (NTDLL.DLL.toupper+0x64a0 in libc.so.6): pushl %ebp Wine-dbg> 0x400cdb11 (NTDLL.DLL.toupper+0x64a1 in libc.so.6): movl %esp,%ebp Wine-dbg> 0x400cdb13 (NTDLL.DLL.toupper+0x64a3 in libc.so.6): subl $8,%esp Wine-dbg> 0x400cdb16 (NTDLL.DLL.toupper+0x64a6 in libc.so.6): movl %esi,0x0(%esp) Wine-dbg> 0x400cdb19 (NTDLL.DLL.toupper+0x64a9 in libc.so.6): movl $0x8,%esi Wine-dbg> 0x400cdb1e (NTDLL.DLL.toupper+0x64ae in libc.so.6): movl %edi,0x4(%esp) Wine-dbg> 0x400cdb22 (NTDLL.DLL.toupper+0x64b2 in libc.so.6): movl 0x8(%ebp),%edi Wine-dbg> 0x400cdb25 (NTDLL.DLL.toupper+0x64b5 in libc.so.6): movl 0xc(%ebp),%ecx Wine-dbg> 0x400cdb28 (NTDLL.DLL.toupper+0x64b8 in libc.so.6): movl 0x10(%ebp),%edx Wine-dbg> 0x400cdb2b (NTDLL.DLL.toupper+0x64bb in libc.so.6): xchgl %ebx,%edi Wine-dbg> 0x400cdb2d (NTDLL.DLL.toupper+0x64bd in libc.so.6): movl $0xaf,%eax Wine-dbg> 0x400cdb32 (NTDLL.DLL.toupper+0x64c2 in libc.so.6): int $0x80 Wine-dbg>ni err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 4024e090 esp 4001bc60 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b880 stack 0x405e0000-0x406e0000 err:seh:setup_exception nested exception on signal stack in thread 000f eip 400cdb35 esp 4001b4b4 stack 0x405e0000-0x406e0000 ... INFINITE LOOP, PATTERN NOW REPEATING UNTIL 'killall -9 wine-pthread' ... ====================================================================================================== ============================================ COMMON TRACE ============================================ merlin(a)Merlin:/my/hom/merlin/.wine/fake_windows/Program Files/Bullfrog/Keeper> winedbg KEEPER95.EXE fixme:console:SetConsoleCtrlHandler (0x40615b43,1) - no error checking or testing yet WineDbg starting on pid e Breakpoint 1 at 0x004f1ed0 Unable to add breakpoint, will check again any time a new DLL is loaded Loaded debug information from ELF '/usr/local/bin/wine-pthread' ((nil)) Breakpoint 2 at 0x4000dd60 (_end+0x2fef9d60) Loaded debug information from ELF '/usr/local/lib/libwine.so.1' (0x4003a000) No debug information in ELF '/lib/i686/libpthread.so.0' (0x40053000) No debug information in ELF '/lib/i686/libc.so.6' (0x400a4000) No debug information in ELF '/lib/libdl.so.2' (0x401d7000) No debug information in ELF '/lib/i686/libm.so.6' (0x401da000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' (0x401fe000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' (0x40274000) Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' (0x40480000) No debug information in 32bit DLL 'C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40220000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40780000) Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x406e0000) Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' (0x4076a000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40700000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x407e0000) Loaded debug information from ELF '/usr/local/lib/wine/winspool.drv.so' (0x4079c000) Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' (0x407c1000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x407b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40920000) Loaded debug information from ELF '/usr/local/lib/wine/winmm.dll.so' (0x40914000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\MSS32.DLL' (0x20000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40a20000) Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' (0x40988000) Loaded debug information from ELF '/usr/local/lib/wine/rpcrt4.dll.so' (0x40a04000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x409a0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\WSND7R.DLL' (0x10000000) No debug information in 32bit DLL 'C:\PROGRAM FILES\BULLFROG\KEEPER\SMACKW32.DLL' (0x40a4e000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DDRAW.DLL' (0x40a90000) Loaded debug information from ELF '/usr/local/lib/wine/ddraw.dll.so' (0x40a66000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40021000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40b08000) No debug information in ELF '/usr/X11R6/lib/libXrandr.so.2' (0x4001c000) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x40032000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40b1f000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40b2d000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\DPLAYX.DLL' (0x40c40000) Loaded debug information from ELF '/usr/local/lib/wine/dplayx.dll.so' (0x40c29000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IPHLPAPI.DLL' (0x40ca0000) Loaded debug information from ELF '/usr/local/lib/wine/wsock32.dll.so' (0x40ae8000) Loaded debug information from ELF '/usr/local/lib/wine/ws2_32.dll.so' (0x40c66000) Loaded debug information from ELF '/usr/local/lib/wine/iphlpapi.dll.so' (0x40c8e000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x40c70000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x40af0000) No debug information in ELF '/usr/lib/libfreetype.so.6' (0x40ccf000) No debug information in ELF '/usr/lib/libfontconfig.so.1' (0x40d25000) No debug information in ELF '/usr/lib/libexpat.so.0' (0x40d4d000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40d80000) Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40d6d000) No debug information in ELF '/usr/lib/tls/libGL.so.1' (0x40df6000) No debug information in ELF '/usr/lib/tls/libGLcore.so.1' (0x40e53000) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x413a8000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x4002a000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x40caf000) No debug information in ELF '/usr/lib/gconv/ISO8859-15.so' (0x405dd000) No debug information in ELF '/usr/lib/libcups.so.2' (0x41415000) No debug information in ELF '/usr/lib/libssl.so.0.9.7' (0x41432000) No debug information in ELF '/usr/lib/libcrypto.so.0.9.7' (0x41462000) No debug information in ELF '/lib/libnss_files.so.2' (0x41554000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x41410000) Loaded debug information from ELF '/usr/local/lib/wine/wineoss.drv.so' (0x413f5000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x41460000) Loaded debug information from ELF '/usr/local/lib/wine/msacm.drv.so' (0x41438000) Loaded debug information from ELF '/usr/local/lib/wine/msacm32.dll.so' (0x41450000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x41440000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41480000) Loaded debug information from ELF '/usr/local/lib/wine/midimap.drv.so' (0x41472000) In 32-bit mode. Wine-dbg>c Stopped on breakpoint 1 at 0x004f1ed0 (KEEPER95.EXE.EntryPoint in KEEPER95.EXE) Wine-dbg>b RtlCreateUserThread Many symbols with name 'RtlCreateUserThread', choose the one you want (<cr> to abort): [1]: 0x40596350 (RtlCreateUserThread in KERNEL32.DLL) [2]: 0x40252665 (RtlCreateUserThread [thread.c:208] in NTDLL.DLL) => 2 Breakpoint 3 at 0x40252665 (RtlCreateUserThread [thread.c:208] in NTDLL.DLL) Wine-dbg>c Stopped on breakpoint 3 at 0x40252665 (RtlCreateUserThread [thread.c:208] in NTDLL.DLL) 208 { Wine-dbg>s 209 struct startup_info *info = NULL; Wine-dbg> 210 HANDLE handle = 0; Wine-dbg> 211 TEB *teb = NULL; Wine-dbg> 212 DWORD tid = 0; Wine-dbg> 217 if (pipe( request_pipe ) == -1) return STATUS_TOO_MANY_OPENED_FILES; Wine-dbg> 218 fcntl( request_pipe[1], F_SETFD, 1 ); /* set close on exec flag */ Wine-dbg> 219 wine_server_send_fd( request_pipe[0] ); Wine-dbg> 267 vec.iov_base = (void *)&data; Wine-dbg> 268 vec.iov_len = sizeof(data); Wine-dbg> 270 msghdr.msg_name = NULL; Wine-dbg> 271 msghdr.msg_namelen = 0; Wine-dbg> 272 msghdr.msg_iov = &vec; Wine-dbg> 273 msghdr.msg_iovlen = 1; Wine-dbg> 279 cmsg.len = sizeof(cmsg); Wine-dbg> 280 cmsg.level = SOL_SOCKET; Wine-dbg> 281 cmsg.type = SCM_RIGHTS; Wine-dbg> 282 cmsg.fd = fd; Wine-dbg> 283 msghdr.msg_control = &cmsg; Wine-dbg> 284 msghdr.msg_controllen = sizeof(cmsg); Wine-dbg> 285 msghdr.msg_flags = 0; Wine-dbg> 288 data.tid = GetCurrentThreadId(); Wine-dbg> 289 data.fd = fd; Wine-dbg> 293 if ((ret = sendmsg( fd_socket, &msghdr, 0 )) == sizeof(data)) return; Wine-dbg> 299 } Wine-dbg> 221 SERVER_START_REQ( new_thread ) Wine-dbg> 223 req->suspend = suspended; Wine-dbg> 224 req->inherit = 0; /* FIXME */ Wine-dbg> 225 req->request_fd = request_pipe[0]; Wine-dbg> 226 if (!(status = wine_server_call( req ))) Wine-dbg> 241 struct __server_request_info * const req = req_ptr; Wine-dbg> (LAST 3 LINES REPEATED IN ABOVE VERSIONS TO MAKE CLEAR WHERE THEY START) ====================================================================================================== -- Frank

Jan. 16, 2004

Re: Need help debugging ...

by Frank.Schruefer＠t-online.de

> Good luck! Please don't be discouraged if you can't crack this one though, > both me and Lionel have looked at Dungeon Keeper (1 and 2) and couldn't > figure out why it doesn't work. Lionel has been a Wine hacker for 5+ years > now! If you can't get DK to work, or are finding it too > frustrating, perhaps move on to another program and see if it's any easier? Hehe, ok ... but I'm not giving up yet;) > > Unhandled vs first chance, hmm, how to explain this. Well in the debugger > you can trap *all* exceptions, even if the program itself may in turn > catch that exception and deal with it. So it's called a first-chance > because you the debugger get the first chance to deal with it. Unhandled > just means there was an exception and the program didn't do anything with > it, so it falls back to the debugger (in Windows you would see the crash > dialog). Notice how the numbers are the same, and the fault (writing to > null) is the same. Ok, I understand. >>2. How to compile debug information into the 32bit DLL's so I don't get >> 'No debug information in 32bit DLL' anymore and maybe some better info? >> I tried 'configure --enable-debug && make depend && make && su -c "make install"' to >> no avail. > > > They have debugging info in, but unfortunately there has been breakage in > the debugger recently which has not yet been fixed in CVS. This is very > bad :( EricP sent a patch here which works great for me and fixed all my > debugger problems, try looking in the archives for Jan and December > looking for it (it was sent to wine-devel not wine-patches iirc). > > For now try setting WINELOADER to the path to your actual wine binary > (wine-pthread) That works. > > No, they aren't called, they just happen to be the closest exported > symbols the debugger could find. In general the names given to you when > there are no debug symbols are useless. Look: > > 1 0x40501e3d (KERNEL32.DLL.SetThreadExecutionState+0x17fd in KERNEL2.DLL) > > see the +0x17fd here? That means the crash occurred in some code a long > way from the start of that function, who knows where without debug symbols > though. Ok. > IIRC keeper makes only one or two API calls before crashing, both of those > calls are trivial and succeed (setting a timer or something I think) so > it's more likely to be to do with the layout of an in memory struct or > something. Remember that the TEB is stored in %fs, if you see references > to that register. Yep. It's setting up a timer which in turn creates a thread as far as I understand until now. There's something like a stack overflow going on _maybe_. I've put a backtrace dumping to the start of RTLLeaveCriticalSection which shows more than >1024 stackframes being used near the occurance of the prob - it's showing a re- peating pattern, as does wine --debugmsg +relay,+seh. Here a little excerpt of the latter: ... ... ... 0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9 0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f 0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f 0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9 0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9 0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f 0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f 0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9 0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9 0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f 0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f 0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9 0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9 0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f 0013:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4094ae6f 0013:Call ntdll.RtlLeaveCriticalSection(403ac6a8) ret=4094afe9 0013:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4094afe9 0013:Call ntdll.RtlEnterCriticalSection(403ac6a8) ret=4094ae6f 0013:RUnhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x00406062). In 32-bit mode. 0x00406062 (KEEPER95.EXE..text+0x5062 in KEEPER95.EXE): movb $0x0,0x0(%eax) Wine-dbg>walk thread process tid prio 00000011 (D) C:\Program Files\Bullfrog\Keeper\KEEPER95.EXE 00000013 0 00000012 0 <== 00000008 00000009 0 Wine-dbg> I've set stack_reserve to 8MB min. That didn't make much of a difference. Unfortunitely I run across a bunch of debugger bugs (I think) following the creation of the timer thread, I decided to put these problems into another post though. I wanted to step to the point where the thread comes alive when the debugger left me at/near a syscall :( I think it has something to do with this thread cause the exception you get is always another depending on what you currently debug ... somehow asynchronous, as the above :) -- Thank you, Frank

Jan. 16, 2004

Re: More Vacation backlog

by Eric Pouech

> Yes, it's a temporary hack. Devices should be normal file handles. > Eric's file management patch is going to take care of that I believe. yes it does A+

Jan. 16, 2004

Re: winecfg: a patch to review

by Chris Morgan

I was planning to do the same to the x11 tabsheet but wasn't sure if people actually needed to be able to specify these options per-app. Unless there is a good reason, like there can be with dlls, global settings seem the best for that tab. If people think this is necessary I'll take a look at it ;-) Chris On Friday 16 January 2004 12:17 pm, Robert van Herk wrote: > Kirk Ruff wrote: > >On Thu, 2004-01-15 at 15:23, Dimitrie O. Paun wrote: > >>On Thu, 15 Jan 2004, Robert van Herk wrote: > >>>We (me and cmorgan) were thinking about dropping that tabsheet :-)... > >> > >>That's a good idea, the current UI for app-specific settings is terrible. > > > >I agree it is horrible, but I wanted to try to implement something. > >I also agree that that tab should be dropped and all handeled within > >1 tab. At least I didn't put a lot of effort in to this. If you guys > >have any up coming patches, any idea how long before you will be ready > >to send them in? > > I already sent in a patch for dll specific overrides... It isn't totally > finished though, since i forgot a few settings ;-). But anywayz, the > current library tab sheets allows you to override dlls per application. > > As for as I know, cmorgan is doing the same to the x11drv tab sheet. > > After these two are added, I guess the appsdefault tabsheet could be > dropped... > > I am not planning to start working on it again soon, since I have some > high-prio stuff to do first. I'll probably start with it again in 'bout > a month... > > If you feel like implementing features, pls talk to cmorgan in the > #winehq channel on freenode. He is there quite often and afaik currently > working on winecfg. > > Grtz, > > Robert

Jan. 16, 2004

A question about winehq options

by Kirk Ruff

I am trying to work on a multimedia tab, unless someone else is doing this already. I am wondering what options should go on this tab. A select for the audio driver, wave mapper, and midi mapper is what I was thinking so far. The wave/midi mapper seem to each only have 1 option so what should I do for that? Is there any plan to add any more options to these two? The dsound options seem too obscure to be in winecfg, and I didn't see any other obvious options to put on. Hopefully someone else hasn't started on such a tab yet. Any help is appreciated.

Jan. 16, 2004

Re: winecfg: a patch to review

by Robert van Herk

Kirk Ruff wrote: >On Thu, 2004-01-15 at 15:23, Dimitrie O. Paun wrote: > > >>On Thu, 15 Jan 2004, Robert van Herk wrote: >> >> >> >>>We (me and cmorgan) were thinking about dropping that tabsheet :-)... >>> >>> >>That's a good idea, the current UI for app-specific settings is terrible. >> >> > >I agree it is horrible, but I wanted to try to implement something. >I also agree that that tab should be dropped and all handeled within >1 tab. At least I didn't put a lot of effort in to this. If you guys >have any up coming patches, any idea how long before you will be ready >to send them in? > > I already sent in a patch for dll specific overrides... It isn't totally finished though, since i forgot a few settings ;-). But anywayz, the current library tab sheets allows you to override dlls per application. As for as I know, cmorgan is doing the same to the x11drv tab sheet. After these two are added, I guess the appsdefault tabsheet could be dropped... I am not planning to start working on it again soon, since I have some high-prio stuff to do first. I'll probably start with it again in 'bout a month... If you feel like implementing features, pls talk to cmorgan in the #winehq channel on freenode. He is there quite often and afaik currently working on winecfg. Grtz, Robert

Jan. 16, 2004