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

Re: wine_main_preload_info not found, cannot use first megabyte, *.exe don't work

by Mike McCormack

Pavel Roskin wrote: > I agree. My gdb cannot show variables in 32-bit binaries (or maybe it's > just something Wine specific), but it shows the line numbers. I traced > find_symbol() in preloader.c, and it seems like symtabend is 0, so that > the last loop is skipped and NULL is returned. This is also evidenced > by the lack of "Found" in the log I sent in the previous message. Perhaps you could try printing out some more debug information in the preloader's find_symbol() function? Can it see any symbols at all? Is it getting past line 795 ((!symtab) || (!strings))? > It's a x86_64 system, but I have the necessary packages for i386 > development. I don't have SELinux enabled. My system is also x86_64, and it works correctly. Mike

July 31, 2006

[FreeBSD] locating wine at 0x20000000

by Tijl Coosemans

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?

July 31, 2006

Re: please help with patch submission

by Neil Skrypuch

On Monday, July 31, 2006 06:37, Damjan Jovanovic wrote: > + WCHAR guidStringWithBraces[MAX_GUID_STRING_LEN]; You need MAX_GUID_STRING_LEN + 1 to store the null too, if I'm not mistaken. > + CopyMemory(&guidStringWithBraces[1], lpGuidString, > + (MAX_GUID_STRING_LEN - 3) * sizeof(WCHAR)); Why MAX_GUID_STRING_LEN - 3? Wouldn't that miss the last 3 characters? - Neil

July 31, 2006

Re: wine_main_preload_info not found, cannot use first megabyte, *.exe don't work

by Mike McCormack

Pavel Roskin wrote: > It is installed and it is run. If I replace wine-preloader with a > script that logs the arguments and runs the renamed wine-preloader, I > see it being called twice when an exe file with run with Wine. For > example: > > $ wine FarManager170.exe > wine_main_preload_info not found > wine_main_preload_info not found > wine: could not load L"Z:\\home\\proski\\dist\\windows\\FarManager170.exe": Invalid address OK, it seems to be that the preloader can't lookup the ELF symbol "wine_main_preload_info" in wine-pthread. That's bad, because the preloader is reserving memory, but has no way to let wine-pthread know which memory it reserved. Can you see that symbol exported from wine-pthread? mike(a)black:~/wine$ nm loader/wine-pthread | grep wine_main_preload_info 7bf023d8 B wine_main_preload_info Also, which version of gcc/ld are you using? For me: GNU ld version 2.17 Debian GNU/Linux gcc version 4.1.2 20060715 (prerelease) (Debian 4.1.1-9) Mike

July 31, 2006

Re: wine_main_preload_info not found, cannot use first megabyte, *.exe don't work

by David D. Hagood

I've been posting my findings on this very matter to wine-users - look for "cannot run under Fedora 6 tset 1". I have also found that, if you are running in an SELinux system, you cannot directly run a Windows program using binfmt_misc - the program must have the same security context labels set as the Wine executables do. And on my system, wine-pthread and wine-kthread both have the wine_main_preload_info symbol exported - only the actual "wine" executable lacks this. Directly running wine-pthread works for me for simple Windows programs, however installers don't work as the temporary executable created by the installer a) does not have the correct security tags and b) is passed directly to "wine" not wine-pthreads.

July 31, 2006

Re: usp10: Remove a test that fails on Windows.

by Jeff Latimer

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"); > } > > >------------------------------------------------------------------------ > > > >

July 31, 2006

Re: shdocvw: Added type library.

by Jacek Caban

Alexandre Julliard wrote: > 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. > We want to generate only a tlb file so make shouldn't have to rebuild an existing shdocvw.h. I'll send a patch with a changed file name. Thanks, Jacek

July 31, 2006

please help with patch submission

by Damjan Jovanovic

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,

July 31, 2006

Re: shdocvw: Added type library.

by Alexandre Julliard

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

July 31, 2006

Re: advapi32: add more helper functions

by Alexandre Julliard

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

July 31, 2006