Re: Wine/Interix -- The pros and cons.
Hi, In short it wont work. In long see inline. On 3/24/06, Segin [EMAIL PROTECTED] wrote: 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) Wine should still load its builtin libs first. Your going to need to add some configure magic to detect interix/SFU and get it building. The last time I tried I ran in to conflicts with headers. It seems what Microsoft has for basic types in the POSIX headers does not match what windows has. 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. You can already test any of the pure Win32 Wine dlls if you do a mingw build. Trying to to a port is a good bit of work. A port to SFU has the same problems as a Cygwin port. Your going to have to implement support in ntdll and wineserver for get/setthreadcontext. For simple Win32 apps that can just be stubbed but then you have the harder task of implementing or working around the lack of send/recvmsg. I think there was a hack to emulate it for cygwin but I never got around to testing it so you might be able to come up with a creative solution that will work for both targets. My advice would be to get it working on cygwin first and then port to SFU. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Winetools - wine doors
On Sat, 2006-03-25 at 14:02 -0500, Segin wrote: Also note that most of Winetools prior usefullness was killed when we killed ~/.wine/config Now we rely on winereg? is that correct (I should know this ;) I've been making some steady progress today, managed to get CD auto detection working (from some freevo code) and I've added basic SAX parsing for package lists. I hope I can get a base shell working soon. I would love it if people would get involved, a few good coders can have SVN/trac access I'll work on opening up to the public soon. pygtk/pyxml/wine hackers/shell scripters very welcome. Some clarification i need is on how wine executes applications. AFAIK this is how it works. wine runs the wineserver and wine-pthread and when the application exits cleanly wineserver goes too, otherwise winedbg starts. I have code waiting for wine exit (similar to winetools) which currently works but I'd like to make sure i'm on the right track ;) I'd also like to know what is the best way to kill a wine process and when it should be killed (currently I'm waiting indefinitely for wine to exit, then waiting 5 minutes on the wineserver). When is the best time to use wineboot? What purpose does it serve, what can it break. Cheers, K,
stir stir stir
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#c114300669155836359 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
Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c
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,0400)
ret=0100503a
0009:Ret kernel32.QueryDosDeviceA() retval= ret=0100503a
0009:Call kernel32.QueryDosDeviceA(7fb0fe68 b:,7fb0f8c8,0400)
ret=0100503a
0009:Ret kernel32.QueryDosDeviceA() retval= ret=0100503a
0009:Call kernel32.QueryDosDeviceA(7fb0fe68 c:,7fb0f8c8,0400)
ret=0100503a
0009:Ret kernel32.QueryDosDeviceA() retval=000c 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= ret=01005069
0009:Call ntdll.strstr(7fb0f8c8 ..\\drive_c,01002630 ramdisk) ret=0100507d
0009:Ret ntdll.strstr() retval= ret=0100507d
0009:Call kernel32.QueryDosDeviceA(7fb0fe68 d:,7fb0f8c8,0400)
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.
12bdc95f62dc7adedca4b9f48262c4611a287b1b
diff --git a/programs/winecfg/drivedetect.c b/programs/winecfg/drivedetect.c
index 7c3cf3d..2b55ade 100644
--- a/programs/winecfg/drivedetect.c
+++ b/programs/winecfg/drivedetect.c
@@ -172,7 +172,7 @@ static void report_error(int code)
if (gui_mode)
MessageBox(NULL, No virtual drive C mapped\n\nTry running wineprefixcreate, , MB_OK | MB_ICONEXCLAMATION);
else
-fprintf(stderr, winecfg: no drive_c directory\n);
+fprintf(stderr, winecfg: no drive C mapped\n);
case NO_HOME:
if (gui_mode)
@@ -250,14 +250,14 @@ static void ensure_drive_c_is_mapped(voi
if (drives[2].in_use) return;
-len = snprintf(NULL, 0, %s/../drive_c, configdir);
+len = snprintf(NULL, 0, %s/../harddiskvolume1, configdir);
drive_c_dir = HeapAlloc(GetProcessHeap(), 0, len);
-snprintf(drive_c_dir, len, %s/../drive_c, configdir);
+snprintf(drive_c_dir, len, %s/../harddiskvolume1, configdir);
HeapFree(GetProcessHeap(), 0, drive_c_dir);
if (stat(drive_c_dir, buf) == 0)
{
-add_drive('C', ../drive_c, Virtual Windows Drive, 0, DRIVE_FIXED);
+add_drive('C', ../harddiskvolume1, Virtual Windows Drive, 0, DRIVE_FIXED);
}
else
{
diff --git a/programs/winecfg/driveui.c b/programs/winecfg/driveui.c
index ea80889..2dfc2a4 100644
--- a/programs/winecfg/driveui.c
+++ b/programs/winecfg/driveui.c
@@ -342,7 +342,7 @@ static void on_add_click(HWND dialog)
WINE_TRACE(allocating drive letter %c\n, new);
-if (new == 'C') add_drive(new, ../drive_c, System Drive, , DRIVE_FIXED);
+if (new == 'C') add_drive(new, ../harddiskvolume1, System Drive, , DRIVE_FIXED);
else add_drive(new, /, , , DRIVE_UNKNOWN);
fill_drives_list(dialog);
@@ -525,7 +525,7 @@ static void on_edit_changed(HWND dialog,
path = get_text(dialog, id);
HeapFree(GetProcessHeap(), 0, current_drive-unixpath);
-current_drive-unixpath = path ? path : strdupA(drive_c);
+current_drive-unixpath = path ? path : strdupA(harddiskvolume1);
WINE_TRACE(set path to %s\n, current_drive-unixpath);
diff --git a/tools/wineprefixcreate.in b/tools/wineprefixcreate.in
index 3effdb5..dcff18c 100644
--- a/tools/wineprefixcreate.in
+++ b/tools/wineprefixcreate.in
@@ -142,8 +142,8 @@ WINEPREFIX=`cd $WINEPREFIX pwd`
if [ ! -d $WINEPREFIX/dosdevices ]
then
mkdir $WINEPREFIX/dosdevices
-[ -d $WINEPREFIX/drive_c ] || mkdir $WINEPREFIX/drive_c
-ln -s ../drive_c $WINEPREFIX/dosdevices/c:
+[ -d $WINEPREFIX/harddiskvolume1 ] || mkdir $WINEPREFIX/harddiskvolume1
+ln -s ../harddiskvolume1 $WINEPREFIX/dosdevices/c:
ln -s / $WINEPREFIX/dosdevices/z:
fi
Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c
Hans Leidekker [EMAIL PROTECTED] writes: 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: QueryDosDevice needs to be fixed to return real device names instead of just reading the symlink. We can't require people to name their directories harddisk something. I'm working on it but it needs a bit more device infrastructure first. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Alexandre Julliard : server: Class and global atoms should not be local to a window station.
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 0x001a at address
0x6033e436 (thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on write access to 0x001a 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:0001 EBX:7f5e866c ECX: EDX:7fa0f704
ESI: EDI:7fa0fd18
Stack dump:
0x7fa0f790: 0001002a 7f5c580a 0001002a 0113
0x7fa0f7a0: 139c 7fca1cf9 7f5e866c
0x7fa0f7b0: 7fa0f7c0 7f5e866c 0001002a 7fa0fd18
0x7fa0f7c0: 7fa0f800 7f5c6490 6033e417 0001002a
0x7fa0f7d0: 0113 139c 7e270598
0x7fa0f7e0: 7fa0f9ac 7fa0f824 7f595f80 0113
0200: sel=1007 base=7fe6a000 limit=1fff 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=9873494ced8405113381266b4d99c2a9f3002cb1
Author: Alexandre Julliard [EMAIL PROTECTED]
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
Re: Page fault xmlspy 2006 wine .9.10
Eric Pouech wrote: Grant Lewis wrote: It's repeatable. I can launch the progam fine but when I click in certain parts of the gui I generate the page fault and the program dies. wine: Unhandled page fault on write access to 0x001f at address 0x7d62d6 (th read 0009), starting debugger... WineDbg starting on pid 0x8 First chance exception: page fault on read access to 0x in 32-bit code ( 0x7ffa7292). does the attached patch help ? A+ I'll try incorporating your patch into the gentoo ebuild and report back if it helped my situation. Gramt
Regression in wine made 2006/03/23
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
