July 2006 - Wine-Devel - list.winehq.org

[FreeBSD] locating wine at 0x20000000
by Tijl Coosemans Aug. 9, 2006

Aug. 9, 2006

Hello all, For the past week or so I've been getting to know Wine and trying to improve/fix the FreeBSD version. I've progressed somewhat since then, though there are still quite a few open issues. One of the problems on FreeBSD is that Wine is loaded at 0x7bf00000. FreeBSD's mmap preserves some space for the data segment (about 512Mb by default) and every future call to mmap with NULL for the addr argument maps memory after that. This is the reason that win98 mode doesn't work, since the shared heap at 0x80000000 isn't available and everything that gets dlopen'ed for instance is located beyond the 2G limit which some programs may not like. So I was thinking of moving Wine to 0x20000000. That would be the easiest solution by far, but, are there any potential problems with that?

2 7

wine_main_preload_info not found, cannot use first megabyte, *.exe don't work
by Pavel Roskin Aug. 2, 2006

Aug. 2, 2006

Hello! Something strange to happened my Wine installation recently. I'm getting following messages if I run any program from Wine: $ winemine wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report The programs still work fine after those for lines are printed. What's worse is that that Windows PE files don't work at all, including those that come with Wine: $ wine winhlp32.exe wine_main_preload_info not found wine: could not load L"C:\\windows\\winhlp32.exe": Module not found I'm using current Wine from git on Fedora Core development (future FC6) for x86_64, glibc-2.4.90, gcc-4.1.1, Linux 2.6.18-rc2 (actually, the current version from the wireless-2.6 branch). The CPU is Intel with EM64T. Wine is compiled with default settings for i386 by the i386 compatibility compiler and i386 compatibility libraries included in Fedora. I removed ~/.wine to start with a clean system. Since I keep updating the kernel and Wine almost every day and I upgraded from FC5 to Development recently, it's hard to say what's the exact reason. P.S. I have a 32-bit Ubuntu 6.04 installation on the same machine, so I used chroot to compile and run Wine under Ubuntu under the same 64-bit kernel. I also used linux32 to fool uname into thinking it's an i686 machine. The messages from ELF programs are gone, but PE files still fail: $ winemine $ wine winhlp32.exe wine: could not load L"C:\\windows\\winhlp32.exe": Module not found Moreover, if I run this Wine on Fedora, the results are the same - no more messages about wine_main_preload_info and setup_dos_mem. I guess it's a compile issue. Unfortunately, the difference between config.status in both builds is quite significant to pinpoint the reason. -- Regards, Pavel Roskin

3 10

Simple installer regression testing
by Dan Kegel Aug. 1, 2006

Aug. 1, 2006

It would be nice to have a simple way to verify that wine can still install apps properly. Ideally this test should run on either Windows or Wine unchanged, and should verify the checksum of all installed files. So I whipped up a demo of how to do this for winzip 10: http://kegel.com/wine/test-winzip100.tgz The archive contains a shell script winzip100.sh that downloads winzip, verifies its checksum, installs it, and verifies the checksum of all the files it should have installed. It's wine-specific, but just barely; with very little change it should work on cygwin, too. It requires you to install autoit first. Autoit is a popular windows scripting tool which is even somewhat open source, see http://www.autoitscript.com/forum/index.php?showtopic=8389, and in any case is free to use. Anyway, this is just a proof of concept. I'd like to expand this to handle a largish number of apps as time goes on. In particular, I'd like something like this to be in place and easy for anybody to run themselves before we do a 1.0 release. If you're wondering why I'm not using cxtest for this, it's because a) that only supports wine, not windows, and b) cxtest seems a bit harder to set up than this. Comments welcome... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 2

wine notepad.exe: Segmentation fault
by Molle Bestefich Aug. 1, 2006

Aug. 1, 2006

Been running 0.9.15 for a while without problems. Since a week ago (or so) when I updated to HEAD, all I get from Wine is this: wine-git # notepad Segmentation fault Nuking ~/.wine doesn't help: wine-git # rm -rf ~/.wine wine-git # notepad wine: creating configuration directory '/root/.wine'... /usr/local/bin/../lib/../bin/wineprefixcreate: line 171: 8574 Segmentation fault "${WINELOADER:-$bindir/wine}" rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf wine: wineprefixcreate failed while creating '/root/.wine'. GDB tells me a lot I don't quite understand: wine-git # gdb --quiet --args /usr/local/bin/wine-pthread /usr/local/bin/notepad.exe Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /usr/local/bin/wine-pthread /usr/local/bin/notepad.exe [Thread debugging using libthread_db enabled] [New Thread -1211160288 (LWP 9620)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211160288 (LWP 9620)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x7ffb0a40 in wine_server_call (req_ptr=0xbfe60d90) at server.c:321 #2 0x7ffb1bd4 in server_init_thread (unix_pid=9620, unix_tid=9620, entry_point=0x0) at server.c:937 #3 0x7ffb90b1 in thread_init () at thread.c:279 #4 0x7ff99cc6 in __wine_process_init () at loader.c:2365 #5 0xb7e417d6 in wine_init (argc=2, argv=0xbfe61464, error=0xbfe60fd0 "", error_size=1024) at loader.c:664 #6 0x7bf0117a in main (argc=2, argv=0xbfe61464) at main.c:58 (gdb) frame 1 #1 0x7ffb0a40 in wine_server_call (req_ptr=0xbfe34e10) at server.c:321 321 pthread_functions.sigprocmask( SIG_BLOCK, &block_set, &old_set ); (gdb) info locals req_ptr = (void *) 0xbfe34e10 old_set = {__val = {0 <repeats 11 times>, 3219344856, 2147308640, 3219344768, 3084813777, 2147158852, 9, 3219344800, 0, 0, 3219344792, 8, 0, 14, 0, 0, 3219344784, 3084988334, 3219344832, 16, 3219344856, 1}} (gdb) print block_set $1 = {__val = {268511747, 0 <repeats 31 times>}} (gdb) print /a block_set $2 = {__val = {0x10012a03, 0x0 <repeats 31 times>}} (gdb) print /a old_set $3 = {__val = {0x0 <repeats 11 times>, 0xbfe34dd8, 0x7ffd5460 <__wine_dbch___default+340>, 0xbfe34d80, 0xb7de85d1 <sendmsg+33>, 0x7ffb0b44 <wine_server_send_fd+148>, 0x9, 0xbfe34da0, 0x0, 0x0, 0xbfe34d98, 0x8, 0x0, 0xe, 0x0, 0x0, 0xbfe34d90, 0xb7e12fae <__wine_dbg_get_channel_flags+14>, 0xbfe34dc0, 0x10, 0xbfe34dd8, 0x1}} The only thing I can come up with that might cause a segfault in pthread_functions.sigprocmask() is a missing call to a pthread init function. I've grepped through the sources, but unfortunately I was unable to find any place where that is called (except for kthread.c, and I believe that modern systems all use pthread - right?), so I'm without clues. The only thing I can think of that might have happened (other than a Wine bug) is GCC or GLIBC being upgraded by 'emerge world'. GCC --version says "gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)", while ls /lib/libc* says "libc-2.3.6.so". Any suggestions (please!)?

5 6

Re: usp10: Remove a test that fails on Windows.
by Jeff Latimer Aug. 1, 2006

Aug. 1, 2006

Hans, the test does fail on windows but that is becuase it is checking gylphs that are different between the windows and wine (ie. while the unicode is the same the gylphs are different). I don't know how to overcome that issue. What is it is supposed to do is check that there is a consistent translation between unicode and glyphs. It works 19 times out of 20 on my 32 bit system. Obviously there is an inconsisency. Is there any advice on how to achieve the aim of the test? Jeff Hans Leidekker wrote: >This test fails on Alexandre's system and also fails on my Windows XP >system, so I propose to remove it. > > > -Hans > >Changelog > Remove a test that fails on Windows. > > >------------------------------------------------------------------------ > >001e954162666f1e4de46326c94c7ee357157793 >diff --git a/dlls/usp10/tests/usp10.c b/dlls/usp10/tests/usp10.c >index 2a3d9c4..14ed56c 100644 >--- a/dlls/usp10/tests/usp10.c >+++ b/dlls/usp10/tests/usp10.c >@@ -222,7 +222,6 @@ void test_ScriptGetCMap(unsigned short p > unsigned short pwOutGlyphs3[256]; > WCHAR TestItem1[6] = {'T', 'e', 's', 't', 'a', 0}; > DWORD dwFlags; >- int cnt; > > /* We need a valid HDC to drive a lot of Script functions which requires the following * > * to set up for the tests. */ >@@ -269,10 +268,7 @@ void test_ScriptGetCMap(unsigned short p > hr = ScriptGetCMap(hdc, &psc, TestItem1, cInChars, dwFlags, pwOutGlyphs3); > ok (hr == 0, "ScriptGetCMap should return 0 not (%08x)\n", (unsigned int) hr); > ok (psc != NULL, "psc should not be null and have SCRIPT_CACHE buffer address\n"); >- for (cnt=0; cnt < cChars && pwOutGlyphs[cnt] == pwOutGlyphs3[cnt]; cnt++) {} >- ok (cnt == cInChars, "Translation not correct. WCHAR %d - %04x != %04x\n", >- cnt, pwOutGlyphs[cnt], pwOutGlyphs3[cnt]); >- >+ > hr = ScriptFreeCache( &psc); > ok (!psc, "psc is not null after ScriptFreeCache\n"); > } > > >------------------------------------------------------------------------ > > > >

2 2

Tower of Goo regression (ddraw rewrite)
by Joseph Garvin July 31, 2006

July 31, 2006

The last version of wine I tried this game with was before the ddraw rewrite and it looked fine then. When you drag goo upwards, a text message appears telling you how many meters high your tower is -- this is now drawn upside down. You can get tower of goo for free here: http://www.experimentalgameplay.com/game.php?g=1 The sound also seems really messed up but before I was playing with it off so I don't know if that's a regression.

3 2

Re: Implement SetThreadPriority
by Detlef Riekenberg July 31, 2006

July 31, 2006

Chris Robinson wrote: > + // Use the minimum real-time priority possible for now (on Linux, > 1 for > + // SCHED_FIFO and 0 for SCHED_OTHER) I did not test the Patch, but C++ - Comments are not allowed in wine (not compatible with all compilers) It seems to be an updated Patch from Mike. IMHO, a note in the Mail to wine-patches would be nice. We really need a clean sound. Thanks. -- By By ... ... Detlef

1 0

please help with patch submission
by Damjan Jovanovic July 31, 2006

July 31, 2006

Hi I have a short patch that fixes serious bugs I've encountered in setupapi's SetupDiOpenClassRegKeyExW(). It's been mailed twice to wine-patches and is attached for reference. Is there anything wrong with it? Please comment. Thank you Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- wine-0.9.17-old/dlls/setupapi/devinst.c 2006-07-10 18:01:08.000000000 +0200 +++ wine-0.9.17/dlls/setupapi/devinst.c 2006-07-28 14:12:39.000000000 +0200 @@ -33,20 +33,21 @@ #include "winnls.h" #include "setupapi.h" #include "wine/debug.h" #include "wine/unicode.h" #include "ddk/cfgmgr32.h" #include "initguid.h" #include "winioctl.h" #include "rpc.h" #include "rpcdce.h" +#include "ddk/cfgmgr32.h" #include "setupapi_private.h" WINE_DEFAULT_DEBUG_CHANNEL(setupapi); /* Unicode constants */ static const WCHAR ClassGUID[] = {'C','l','a','s','s','G','U','I','D',0}; static const WCHAR Class[] = {'C','l','a','s','s',0}; static const WCHAR ClassInstall32[] = {'C','l','a','s','s','I','n','s','t','a','l','l','3','2',0}; static const WCHAR NoDisplayClass[] = {'N','o','D','i','s','p','l','a','y','C','l','a','s','s',0}; @@ -1314,20 +1315,21 @@ * SetupDiOpenClassRegKeyExW (SETUPAPI.@) */ HKEY WINAPI SetupDiOpenClassRegKeyExW( const GUID* ClassGuid, REGSAM samDesired, DWORD Flags, PCWSTR MachineName, PVOID Reserved) { LPWSTR lpGuidString; + WCHAR guidStringWithBraces[MAX_GUID_STRING_LEN]; HKEY hClassesKey; HKEY hClassKey; LPCWSTR lpKeyName; if (MachineName != NULL) { FIXME("Remote access not supported yet!\n"); return INVALID_HANDLE_VALUE; } @@ -1354,35 +1356,39 @@ { return INVALID_HANDLE_VALUE; } if (ClassGuid == NULL) return hClassesKey; if (UuidToStringW((UUID*)ClassGuid, &lpGuidString) != RPC_S_OK) { RegCloseKey(hClassesKey); - return FALSE; + return INVALID_HANDLE_VALUE; } + guidStringWithBraces[0] = (WCHAR) '{'; + CopyMemory(&guidStringWithBraces[1], lpGuidString, + (MAX_GUID_STRING_LEN - 3) * sizeof(WCHAR)); + guidStringWithBraces[1 + strlenW(lpGuidString)] = (WCHAR) '}'; + guidStringWithBraces[2 + strlenW(lpGuidString)] = 0; + RpcStringFreeW(&lpGuidString); if (RegOpenKeyExW(hClassesKey, - lpGuidString, + guidStringWithBraces, 0, KEY_ALL_ACCESS, &hClassKey)) { - RpcStringFreeW(&lpGuidString); RegCloseKey(hClassesKey); - return FALSE; + return INVALID_HANDLE_VALUE; } - RpcStringFreeW(&lpGuidString); RegCloseKey(hClassesKey); return hClassKey; } /*********************************************************************** * SetupDiOpenDeviceInterfaceW (SETUPAPI.@) */ BOOL WINAPI SetupDiOpenDeviceInterfaceW( HDEVINFO DeviceInfoSet,

2 3

Re: shdocvw: Added type library.
by Alexandre Julliard July 31, 2006

July 31, 2006

Jacek Caban <jacek(a)codeweavers.com> writes: > diff --git a/dlls/shdocvw/shdocvw.idl b/dlls/shdocvw/shdocvw.idl > new file mode 100644 > index 0000000..45b9111 > --- /dev/null > +++ b/dlls/shdocvw/shdocvw.idl You can't name the file shdocvw.idl, otherwise make will try to rebuild the existing shdocvw.h from it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: advapi32: add more helper functions
by Alexandre Julliard July 31, 2006

July 31, 2006

Robert Reif <reif(a)earthlink.net> writes: > /************************************************************ > + * ADVAPI_GetComputerNameW > + * > + * Gets the local computer name. > + */ > +LPCWSTR ADVAPI_GetComputerNameW() > +{ > + static WCHAR buf[MAX_COMPUTERNAME_LENGTH + 1]; > + DWORD dwSize = sizeof(buf); > + if (!GetComputerNameW(buf, &dwSize)) > + buf[0] = 0; > + return buf; You don't want to use a static buffer, that's not thread-safe. -- Alexandre Julliard julliard(a)winehq.org

1 0