March 2006 - Wine-devel - list.winehq.org

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 27 Mar '06

27 Mar '06

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. I don't want to cause unnecessary conflicts, so I _have_ written a test case, where Wine does a lot of application-visible things differently. Anyway, I've provided an improvement which only needs to do such things as a fallback on platforms, where the cause of the SIGTRAP cannot be determined easily. In my opinion, the solution is reasonable because if any application is really interested in the DR6 register (i.e. it is a debugger), it will clear the status register (DR6) anyway, since the processor never clears the bits and unless you clear them manually, the register gets pretty useless. I wonder why you haven't been bothered by the fact that the current implementation silently drops the TF bit, which is even worse! :O Petr Tesarik

2 2

Re: ntdll: Fix SIGTRAP handling
by Alexandre Julliard 27 Mar '06

27 Mar '06

Petr Tesarik <hat(a)tesarici.cz> writes: > 2. The x86 spec states that a single-step interrupt (INT 1) is > generated if the TF bit was set when the execution of the > instruction BEGAN. This means that if the instruction changes the > TF bit (e.g. popf), there is an INT 1, but the TF bit is not set > any more. The only way to check whether the interrupt was > generated because of the TF bit, is to check bit 15 in DR6. I don't see why you can't still check the TF bit, it will be set 99% of the time, and fetching the DR6 register is quite expensive. > The following patch fixes all of these issues. I'd really like to see test cases showing that Windows does things this way. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advpack: Add initial tests for RunSetupCommand
by Detlef Riekenberg 27 Mar '06

27 Mar '06

Am Donnerstag, den 23.03.2006, 23:12 -0600 schrieb James Hawkins: > * Add initial tests for RunSetupCommand. > dlls/advpack/tests/install.c | 106 ++++++++++++++++++++++++++++++++++++++++ Hi. Your tests used a fixed Path, resulting to failure on: - win95, win98 and winme (c:\windows\system) - NT3.51 (c:\winnt35\system32) - NT4 and w2k (c:\winnt\system32) - Every Installation, that use a non-default Installation-Directory - Every update of an NT < winxp (I don't know about the default Path in Versions > winxp) Your Patch is already in the tree, so expect many tests to fail. -- By By ... ... Detlef

1 0

FPU context in signal handlers
by Petr Tesarik 27 Mar '06

27 Mar '06

Hi, I've just submitted a patch that handles the FPU state in signal handlers. However, the FPU_sig() macro is only defined for Linux, so other architectures won't benefit from that patch. I doubt that i387 FPU state is left untouched by the kernel on other architectures, but I have no access to any such box (*BSD, BSDI, SCO, Apple), I cannot investigate into that, and the FPU handling is most likely broken on those architectures. This has become more serious now that winedbg tries to fetch (and restore!) the FPU state on the i386 architecture. I guess that architectures with (context)->uc_mcontext also define (context)->uc_mcontext.fpregs (SCO), but since I can't test it, I won't send such a patch to wine-patches. Is there anything I might do about it? Anybody wants to help? Petr

1 0

Regression in wine made 2006/03/23
by Pavel Troller 27 Mar '06

27 Mar '06

Hi! I would like to report a regression made by commits issued 2006/03/23 at the evening. Just now I don't have bisecting environment available, I've just made a simple CVS regression testing and found the above commit (it modifies multiple areas) guilty. The problem is that DC++ gui is totally screwed up now. It tries to render, but mostly unsuccessfully, it's full of garbage and doesn't display, what it should. It doesn't update when necessary. DC++ is simply unusable now. I should leave my testing machine now. I can try to pinpoint a particular patch responsible for this regression later in the evening today, or tomorrow. If anybody has an idea, what change could cause this, please let me know, it will be more easy for me. With regards, Pavel Troller

2 1

Wine/Interix -- The pros and cons.
by Segin 27 Mar '06

27 Mar '06

I was thinking about running Wine on Interix (the POSIX layer of Microsoft's Services for Unix). There are a few apparent unknows: Would Wine load the .dll.so's? Since Interix uses PE for it's native format (running on Windows, duh), Would Wine load the .dll.so's? Would it reject them being in PE format and having the 'POSIX Layer' attribute set, or could we hack on a patch to detect if Wine itself is running in said layer, and load them if it is? Would that even *work*? And how about detecting Winelib applications? It might get detected as a regular Windows app, and ... uh-oh... (let's just say it isn't pretty) There are several obvious pros: You can test Wine almost fully under Windows without mingling with Windows's native componets. This would allow for better and faster compatability tests. We could also see what "unknowns" exist in Interix -- Althought not nessessrarly useful to Wine developers itself, it could mean a whole new generation of applications which are half-Unix, half-Windows, if the right holes are found. I am sure this will spark a LOT of debate.

4 3

Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c
by Hans Leidekker 26 Mar '06

26 Mar '06

Any word on why this patch wasn't applied? There's a test marked todo_wine by Stefan Leichter that demonstrates this behaviour. And here's the relevant part of a relay log: 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "a:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "b:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "c:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=0000000c ret=0100503a 0009:Call ntdll._strlwr(7fb0f8c8 "..\\drive_c") ret=01005053 0009:Ret ntdll._strlwr() retval=7fb0f8c8 ret=01005053 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002638 "harddisk") ret=01005069 0009:Ret ntdll.strstr() retval=00000000 ret=01005069 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002630 "ramdisk") ret=0100507d 0009:Ret ntdll.strstr() retval=00000000 ret=0100507d 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "d:",7fb0f8c8,00000400) ret=0100503a ... I know this affects the IE7 and MSI 3.1 installer, but probably more. ------------------ I've seen installers from Microsoft call QueryDosDevice on the whole alphabet and search any returned object name for the substrings "harddisk" and "ramdisk". On Wine they normally won't find any and quit with the following error: "Unable to find a volume for file extraction" QueryDosDevice on Wine returns the filename pointed to by the drive link beneath the dosdevices directory. In a default Wine installation this is ../drive_c. So a simple fix for this problem is to use the a different name for that directory, for example the name used for the first harddisk in the NT object namespace: harddiskvolume1. -Hans Changelog Use directory harddiskvolume1 for mapping drive C instead of drive_c.

2 1

Re: Alexandre Julliard : server: Class and global atoms should not be local to a window station.
by Alasdair Sinclair 26 Mar '06

26 Mar '06

Hi This patch breaks firefox-1.5 on fedora core 4 (x86-64). err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 wine: Unhandled page fault on write access to 0x0000001a at address 0x6033e436 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x0000001a in 32-bit code (0x6033e436). fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\xpcom\build\xpcom_core.pdb' Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0063 EIP:6033e436 ESP:7fa0f790 EBP:7fa0f7c0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000001 EBX:7f5e866c ECX:00000000 EDX:7fa0f704 ESI:00000000 EDI:7fa0fd18 Stack dump: 0x7fa0f790: 0001002a 7f5c580a 0001002a 00000113 0x7fa0f7a0: 00000000 0000139c 7fca1cf9 7f5e866c 0x7fa0f7b0: 7fa0f7c0 7f5e866c 0001002a 7fa0fd18 0x7fa0f7c0: 7fa0f800 7f5c6490 6033e417 0001002a 0x7fa0f7d0: 00000113 00000000 0000139c 7e270598 0x7fa0f7e0: 7fa0f9ac 7fa0f824 7f595f80 00000113 0200: sel=1007 base=7fe6a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x6033e436 in xpcom_core (+0x2e436) (0x6033e436) 2 0x7f5c6490 WINPROC_CallWndProc+0x70(hwnd=<register not in topmost frame>, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dlls /user/winproc.c:418] in user32 (0x7f5c6490) 3 0x7f5cd2de CallWindowProcW+0x12e(func=0x7f624c34, hwnd=0x1002a, msg=0x113, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dll s/user/winproc.c:3095] in user32 (0x7f5cd2de) 4 0x7f5926ff DispatchMessageW+0xaf(msg=0x7fa0fd18) [/ppp/wine/wine-git/dlls/user/message.c:3001] in user32 (0x7f5926ff) fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\browser\app\firefox.pdb' 5 0x0051866b in firefox (+0x11866b) (0x0051866b) 6 0x007fd417 in firefox (+0x3fd417) (0x007fd417) 7 0x00401012 in firefox (+0x1012) (0x00401012) 8 0x7fc8a00c start_process+0xec(arg=0x0) [/ppp/wine/wine-git/dlls/kernel/process.c:845] in kernel32 (0x7fc8a00c) 9 0xf7fcc4f7 wine_switch_to_stack+0x17 in libwine.so.1 (0xf7fcc4f7) Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 9873494ced8405113381266b4d99c2a9f3002cb1 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9873494ced8405113381266… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Mar 22 22:13:40 2006 +0100 > > server: Class and global atoms should not be local to a window station. > > --- > > dlls/user/tests/winstation.c | 43 +++++++++++++++++++++++++++++++++++++++++- > server/atom.c | 27 ++++++++++++++++---------- > server/class.c | 24 ++++------------------- > 3 files changed, 62 insertions(+), 32 deletions(-) > > diff --git a/dlls/user/tests/winstation.c b/dlls/user/tests/winstation.c > index 4bc1941..a595718 100644 > --- a/dlls/user/tests/winstation.c > +++ b/dlls/user/tests/winstation.c

1 0

stir stir stir
by Mike Hearn 26 Mar '06

26 Mar '06

Deprived of patch-writing time lately I can do little more than cheer the team on. And of course, take pot-shots at our partners over the wall, the Windows team themselves ;) Hello there if you're reading this! In the comments of this anonymous MS employees blogs post (great reporting here huh) we can find this post by somebody who claims to be on an appcompat testing team: http://minimsft.blogspot.com/2006/03/vista-2007-fire-leadership-now.html#c1… in which the following totally astonishing claim is made: "Results: Client appcompat % hovering at <40% (GASP - INTERNAL INFO... better moderate this one out!!!!)" which is explained due to reduction of testing staff, loss of team morale and outsourcing of testing. Can it really be true that the Vista builds have such appallingly low application compatibility? Anybody who has access to Vista builds want to comment on this? Given they (now) have half a year to clean it up, does anybody want to take bets on what the score will be by the time it releases? I wonder what this number means (presumably that 40% of apps work perfectly out of the box), and I also wonder what our own appcompat score is. Wouldn't it be scary if Linux ends up more Windows compatible than Windows is! :) thanks -mike

1 0

Speed demon: Mozilla 1.7.12 and Wine.
by Segin 25 Mar '06

25 Mar '06

This is possibly the best news the Wine development team has recieved since getting Solitare to run on Wine in 1994: Wine and Mozilla are *faster* than IE on native Windows, on the same harware. I am not joking you. I used to have a Windows partition until it was corrupted recently, and my "personalized" Google homepage comes up in 2.31 seconds in IE. Note that Windows is running native (not a VM). Mozilla 1.7.12 in Wine pulls up the same page in under a second. I will continue to test. The only thing that is missing is Java support, and most of us can live without that. It's nice to know that we are mopping the floor with the World's Worst Webbrowser.

1 0