- Wine-Devel - list.winehq.org

Serious Bug
by flyker Oct. 29, 2003

Oct. 29, 2003

The simple test crashes wine. And i think many other commands in constructor A() may crash wine. test.cpp: #include <windows.h> #include <stdio.h> class A { public: A(); }; A::A() { LoadLibrary("user32.dll"); // all ok user32.dll is present } A a; int WinMain(HINSTANCE hInst, HINSTANCE, LPSTR szCmdLine, int nCmdShow) { return 0; }

2 2

Help with shared library make files
by Boaz Harrosh Oct. 29, 2003

Oct. 29, 2003

I have the following setup mfctest/Makefile - Main make file mfctest.exe.so - is the wrapper for an mfc gui application mfctest.dll.so - is the mfc gui application (as generated by the msvc++ wizard and than winemaker) msvc/Makefile - make file for mfc & stuff missing from msvcrt.dll libmsvc.a - is all the cpp files archived by [ ar -rs $(ALL_OBJECT_FILES) ] libmsvc.so - same object files but linked with [ gcc --shared ] Now I link mfctest.dll.so with libmsvc.a. (-l) The spec.c I prepare by including all the object files of the msvc project since winebuild does not work with libraries. It all runs fine. Now I try to link with libmsvc.so ( exact same way as before with the -l option linux style, not as a DLL as usually done in wine ). At the beginning it would not link because of undefined symbols. ( before with the .a option not all files get pulled in by the linker). So I fix the undefined s. The spec.c file I have tried in to ways. 1) a libmsvc.spec.c for libmsvc.so and a small one for mfctest.dll.spec.c - and 2) A big mfctest.dll.spec.c that includes all objects same as above libmsvc.a . In both cases I had the same exact problem. It would not run. I get a SIGSEGV. On the (gdb) back-trace it is directly from "dlopen" (from BUILTIN32_dlopen) it SIGs 10 functions deep into dlopen. The last function that makes any sense is _dl_init in ld-linux.so.2 from than on I get un-logical symbols that should not be in the init path. Including undefined s like 0x00000094 (see complete back-trace below) the SIGSEGV itself is reported at "dllname" which is not a function but an array in dll.spec.c . So we can see that the debug info got totally screwed up. Big help!!! Any body got any ideas? Do you think I need to fix the start address of libmsvc.so some how? What is the command line option for that? The reason I need the libYYY.so option to work is because I have a big (1900 files) C++ project divided into 36 libraries. On the windows side it is dlls & static libs, all automatically exported by msvc++ (#define class class declspec(dllexport) ). Since we do not have a good C++ way for pure dlls in wine (yet) and the 1900 files on one gcc link will not work. ( truncated by the linker) .And I have more Applications in the future that use the same libraries. The .so option looks best. One more question: What do the gurus say? In theory, if I have a XXX.dll.so linked Linux style to libYYY.so both have calls into wine. what is best method (XXX.dll.so is only because of the wrapper no real exports here) A. XXX.dll.so has an XXX.spec.c && libYYY.so has a YYY.spec.c of its own each linked to their respective .spec.c . (Note that those are only imports since export symbols from libYYY.so are linked against - Linux style). B. one big XXX+YYY.spec.c linked against XXX.dll.so (very very slow, it looks like winebuild has an o(n^2) efficiency ) C. Both are good if no exports are made. (or exports only at the top lib) Thanks for any help or pointer. Please share past experience for good or for worse Free Life Boaz some info: <(gdb) backtrace> #0 0x40cb3a4d in dllname () from /home/wine/lib/wine/mfctest.dll.so #1 0x00000094 in ?? () #2 0x40ffec8e in std::basic_iostream<wchar_t, std::char_traits<wchar_t> >::~basic_iostream() () from /usr/lib/libstdc++.so.5 #3 0x40ffed0a in std::basic_iostream<wchar_t, std::char_traits<wchar_t> >::~basic_iostream() () from /usr/lib/libstdc++.so.5 #4 0x4104dbb7 in __cxa_dyn_string_eq () from /usr/lib/libstdc++.so.5 #5 0x40feea11 in std::collate<char>::id () from /usr/lib/libstdc++.so.5 #6 0x4000aa4c in _dl_init (main_map=0x3c02eaf0, argc=4, argv=0xbffff454, env=0xbffff468) at dl-init.c:68 #7 0x4030a51e in _dl_open () from /lib/i686/libc.so.6 #8 0x4000a828 in _dl_catch_error (objname=0x406d28e0, errstring=0x406d28e4, operate=0x4030a120 <_dl_open+432>, args=0x406d28e8) at dl-error.c:162 #9 0x40309fcf in _dl_open () from /lib/i686/libc.so.6 #10 0x40352f21 in dlopen () from /lib/libdl.so.2 #11 0x4000a828 in _dl_catch_error (objname=0x3c0017e0, errstring=0x3c0017e4, operate=0x40352ef0 <dlopen+80>, args=0x406d2a68) at dl-error.c:162 #12 0x40353294 in dlerror () from /lib/libdl.so.2 #13 0x40352ed3 in dlopen () from /lib/libdl.so.2 #14 0x40107abc in wine_dlopen (filename=0x3c02eaa0 "/home/wine/lib/wine/mfctest.dll.so", flag=2, error=0x406d2b08 " ¨<@´l\016(a)X,m(a)HÍ\a@", errorsize=256) at loader.c:577 #15 0x40107420 in dlopen_dll (name=0x406d2c2c "mfctest.dll", error=0x406d2b08 " ¨<@´l\016(a)X,m(a)HÍ\a@", errorsize=256, test_only=0) at loader.c:156 #16 0x4010795b in wine_dll_load (filename=0x406d2c2c "mfctest.dll", error=0x406d2b08 " ¨<@´l\016(a)X,m(a)HÍ\a@", errorsize=256) at loader.c:390 #17 0x4009b537 in BUILTIN32_dlopen (name=0x406d2c2c "mfctest.dll", handle=0x406d2c28) at ../../relay32/builtin32.c:63 #18 0x4009b94c in BUILTIN32_LoadLibraryExA (path=0x403ca710 "C:\\WINDOWS\\SYSTEM\\mfctest.dll", flags=0, pwm=0x406d2cc4) at ../../relay32/builtin32.c:171 #19 0x400b3c6d in load_dll (libname=0x403ca6f0 "mfctest.dll", flags=0, pwm=0x406d2cc4) at loader.c:1058 #20 0x400b3e34 in LdrLoadDll (path_name=0x0, flags=0, libname=0x406d2cfc, hModule=0x406d2cf8) at loader.c:1120 #21 0x4007e158 in LoadLibraryExA (libname=0x404b41a0 "mfctest.dll", hfile=0x0, flags=0) at ../../loader/module.c:655 #22 0x4007e28d in LoadLibraryA (libname=0x404b41a0 "mfctest.dll") at ../../loader/module.c:707 #23 0x404a3147 in WinMain (hInstance=0x404b0000, hPrevInstance=0x0, szCmdLine=0x403908f2 "", iCmdShow=1) at mfctest.exe_wrapper.c:127 #24 0x404b40ea in __wine_exe_main () at mfctest.exe.spec.c:140 #25 0x4009fced in start_process () at ../../scheduler/process.c:455 #26 0x400a402a in call_on_thread_stack (func=0x4009fb10) at ../../scheduler/sysdeps.c:113 </(gdb) backtrace> <(gdb) info sharedlibrary> >From To Syms Read Shared Object Library 0x40048000 0x400c6314 Yes /home/wine/lib/libntdll.dll.so 0x40105790 0x40107c14 Yes /home/wine/lib/libwine.so.1 0x4011cc80 0x4011f354 Yes /home/wine/lib/libwine_unicode.so.1 0x40212620 0x4030f328 Yes /lib/i686/libc.so.6 0x403334a0 0x4034abc4 Yes /lib/i686/libm.so.6 0x40352db0 0x40353d64 Yes /lib/libdl.so.2 0x40000a60 0x4000f49b Yes /lib/ld-linux.so.2 0x40382d10 0x4038b054 Yes /lib/libnss_files.so.2 0x404a3000 0x404b4184 Yes /home/wine/codeward/mfctest/mfctest.exe.so 0x406f3000 0x40732ef4 Yes /home/wine/lib/wine/kernel32.dll.so 0x407b6000 0x40848b14 Yes /home/wine/lib/wine/user32.dll.so 0x408cf000 0x40916c44 Yes /home/wine/lib/wine/gdi32.dll.so 0x40941000 0x4095e814 Yes /home/wine/lib/wine/advapi32.dll.so 0x40974000 0x4099def4 Yes /home/wine/lib/wine/msvcrt.dll.so 0x409b1850 0x409ee254 Yes /usr/lib/libfreetype.so.6 0x409f98e0 0x40a02194 Yes /lib/libz.so.1 0x40a13000 0x40a5e794 Yes /home/wine/lib/wine/x11drv.dll.so 0x404b8200 0x404bc8a4 Yes /usr/X11R6/lib/libSM.so.6 0x40a73540 0x40a81dd4 Yes /usr/X11R6/lib/libICE.so.6 0x40a89910 0x40a934a4 Yes /usr/X11R6/lib/libXext.so.6 0x40aa6380 0x40b17384 Yes /usr/X11R6/lib/libX11.so.6 0x40b99640 0x40bd91e4 Yes /usr/X11R6/lib/libGL.so.1 0x40beb110 0x40bf3c14 Yes /lib/i686/libpthread.so.0 0x40c39320 0x40c3e234 Yes /usr/X11R6/lib/libXcursor.so.1 0x40c41390 0x40c46324 Yes /usr/X11R6/lib/libXrender.so.1 0x40014860 0x40015794 Yes /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 0x40c74260 0x40c8ad84 Yes /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 0x400185f0 0x40018f54 Yes /usr/lib/gconv/ISO8859-1.so 0x40ca0000 0x40cb2074 Yes /home/wine/lib/wine/mfctest.dll.so 0x40dcf920 0x40f2f8e4 Yes /home/wine/lib/libmsvc.so 0x40ff1070 0x4104dbc4 Yes /usr/lib/libstdc++.so.5 0x4001b540 0x40020534 Yes /lib/libgcc_s.so.1 </(gdb) info sharedlibrary>

1 0

WineHQ: Corrected PATCH to fix IPersistFile::Load() and associated functions.
by Subhobroto Sinha Oct. 29, 2003

Oct. 29, 2003

Hello all I corrected my last patch after replacing everything C++ into C. This patch has been inlined as well as attached as a ZIP file, so suit yourself. All reports regaring this patch is to be sent to <subhobrotosinha at yahoo.com> with a proper subject prefixed by "IPersistFile patch" in the subject header. This patch fixes: (1) Stream_LoadString: Conflict of unicode strings being taken as LPSTR and AGAIN being converted to Unicode due to wrong value of SCF_UNICODE .(I have preprocessed out the original code. This should remain so until SCF_UNICODE value is corrected) (2) Stream_LoadLocation: Previously the GetPath() failed. It works great now. Now IPersistFile::Load() should work as intended. Try out McCormack's 'winemenubuilder' or my WineLib 'linkresolve' (NOT my C++ version) If the diff is not proper, etc, please alert me at the mentioned address PS: As I am not a member of 'wine-patches',can the moderator be kind enough... :=) I really want these functions to get fixed. That's all. Regards Subhobroto Sinha __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- wine-20031016/dlls/shell32/shelllink.c 2003-10-29 21:07:43.000000000 +0530 +++ Shikayat/dlls/shell32/shelllink.c 2003-10-29 20:39:56.000000000 +0530 @@ -401,9 +401,49 @@ return S_OK; } +static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr ) +{ + DWORD count=0; + USHORT len; + LPWSTR str=NULL; + HRESULT r; + /* + From Win98 upwards everything internally is maintained as unicode.(Atleast M$ says so) + Also, the value of SCF_UNICODE does NOT seem to be 0x1000, hence the bitwise '&' returns a false. + Until the correct value is found, we assume it Unicode. This should not break ANYTHING >Win95 for shortcuts + Anybody differing mail to <subhobrotosinha at yahoo.com>. + */ + TRACE("%p\n", stm); + + r = IStream_Read(stm, &len, sizeof(len), &count); + if(FAILED(r)||(count != sizeof(len))) return E_FAIL; + len *= sizeof(WCHAR); + + TRACE("reading %d\n", len); + str = HeapAlloc(GetProcessHeap(), 0, len+sizeof(WCHAR)); + if(!str) return E_OUTOFMEMORY; + + count = 0; + r = IStream_Read(stm, str, len, &count); + if( FAILED(r)||( count!=len) ) + { + HeapFree( GetProcessHeap(), 0, str ); + return E_FAIL; + } + + str[count/2]=0; + *pstr = str; + TRACE("read %s\n", debugstr_w(str)); + return S_OK; +} + +#if 0 static HRESULT Stream_LoadString( IStream* stm, BOOL unicode, LPWSTR *pstr ) { + /*This is the original function now redirected to the above till we find out correct 'SCF_UNICODE'. + Now it's assumed that the data's unicode. (This assumption failes iff the OS was <=Win95, so I don't think it will hurt anybody)*/ + DWORD count; USHORT len; LPVOID temp; @@ -454,6 +494,7 @@ return S_OK; } +#endif static HRESULT Stream_LoadLocation( IStream* stm ) { @@ -503,9 +544,10 @@ IStream* stm) { LINK_HEADER hdr; - ULONG dwBytesRead; + ULONG dwBytesRead=0; BOOL unicode; WCHAR sTemp[MAX_PATH]; + char szTemp[MAX_PATH]={0}; HRESULT r; _ICOM_THIS_From_IPersistStream(IShellLinkImpl, iface); @@ -515,7 +557,6 @@ if( !stm ) return STG_E_INVALIDPOINTER; - dwBytesRead = 0; r = IStream_Read(stm, &hdr, sizeof(hdr), &dwBytesRead); if( FAILED( r ) ) return r; @@ -533,6 +574,13 @@ if( FAILED( r ) ) return r; } + + SHGetPathFromIDListA(This->pPidl,szTemp); + This->sPath=HeapAlloc( GetProcessHeap(), 0,(strlen(szTemp)+1)*sizeof(WCHAR)); + dwBytesRead=(strlen(szTemp)+1);/*Just to hold the length of the string*/ + MultiByteToWideChar(CP_ACP,0,szTemp,dwBytesRead,This->sPath,dwBytesRead); + TRACE("%s\n",debugstr_w(This->sPath)); + This->wHotKey = hdr.wHotKey; This->iIcoNdx = hdr.nIcon; FileTimeToSystemTime (&hdr.Time1, &This->time1);

2 1

Re: French keyboard layout with Euro symbol
by RemiAssailly＠aol.com Oct. 29, 2003

Oct. 29, 2003

I sent a patch that looks like yours and it was simply refused ! I wasn't the fisrt...

4 10

Re: DINPUT device unacquire (mouse) fix
by Andreas Mohr Oct. 29, 2003

Oct. 29, 2003

Hi, On Tue, Oct 28, 2003 at 02:53:44AM +0200, Hannu Valtonen wrote: > License: LGPL > > I stumbled upon this when looking at fixing mouse support for Crimson > lands. According to MSDN DirectInputDevice Unacquire is allowed even for > devices which haven't been acquired yet. > > Changelog: > - SysMouseAImpl_Unacquire should return DI_NOEFFECT if the device is not > in an acquired state. Ah, thanks!! Maybe this is why some game (I believe it was UT) broke... Darn, why didn't I discover that when I stumbled on that place years ago? But don't you think keyboard and joystick might need the same code?? (keyboard has it as well, but with completely different code --> mess) This could probably be cleaned up. Andreas Mohr

2 2

WinE-Bug? InternetCrackUrl incorrectly sets dwUrlPathLength
by Jan Sporbeck Oct. 29, 2003

Oct. 29, 2003

Hi, During some application testing, we discovered that WinE does not correctly mimic the WinINet function InternetCrackUrl. The real WinAPI sets the dwUrlPathLength member of the URL_COMPONENTS structure to additionally hold the extra info of the given URL if the extra info is not requested as a separate component. Although this behaviour is not well documented by the Win SDK, it is for instance implemented on WinXP, Win2000 and WinME and therefore might be considered to be intended by Microsoft. The following lines of code demonstrate the problem: LPCTSTR lpszURL = _T("http://www.myserver.com/myscript.php?arg=1"); URL_COMPONENTS url; // call 1: crack out url path and extra info ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; url.dwExtraInfoLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // dwUrlPathLength is 13, holding "/myscript.php" // call 2: only crack out url path ::ZeroMemory(&url, sizeof(url)); url.dwStructSize = sizeof(url); url.dwHostNameLength = 1; url.dwUrlPathLength = 1; ::InternetCrackUrl(lpszURL, 0, 0, &url); // now, dwUrlPathLength should be 19, holding "/myscript.php?arg=1", // while WinE still sets it to 13 OK, it is of course no great deal to write code that correctly runs on real Win systems and on WinE (2-3 lines did it). But programers who rely on this behaviour will for example wonder why their applications don't transmit any HTTP GET parameters when they call HttpOpenRequest with lpszObjectName set to the URL path component returned by InternetCrackUrl... This applies to Wine 20031016, haven't found any recent report on this though. /jan.

1 0

Re: spec files - syntax and generation
by Jerry Jenkins Oct. 28, 2003

Oct. 28, 2003

Martin Tröster wrote: > How do I find out whether a function uses CDECL instead of STDCALL? I found the information (link lost unfortunately) that entries in the def file like testfunc1(a)0 are called via STDCALL, whereas in case of testfunc2 without any @ specifying the space is CDECL. Is this guess right? If not, how else do I find this out? The most safe one I have known is to disassemble it and look over the output. If the function have no parameters, you can declare it as either CDECL or STDCALL. Suppose it have some parameters and its type is CDECL, you can find: 1. "lret" in the function 2. it will be called in a way like pushl something1 pushl something2 call address of testfunc1(a)0 addl $8, %%esp and for a STDCALL, there are: 1. something that is similar to "lret $8" in the function 2. it will be called in a way like pushl something1 pushl something2 call address of testfunc1(a)0 > > Thanks again for any help! > > Cheers, > Martin

2 1

Re: spec files - syntax and generation
by Shachar Shemesh Oct. 28, 2003

Oct. 28, 2003

Martin Tröster wrote: >Hi, > >- Stdcall vs. cdecl >How do I find out whether a function uses CDECL instead of STDCALL? I found the information (link lost unfortunately) that entries in the def file like testfunc1(a)0 are called via STDCALL, whereas in case of testfunc2 without any @ specifying the space is CDECL. Is this guess right? If not, how else do I find this out? > > > STDCALL means PASCAL call format. This means two things, mostly. First - it means arguments are pushed on the stack left to right instead of right to left (no way you can pass printf style variable length arguments). The second is that it is the functions' responsibility, rather than the caller, to remove the arguments from the stack. With the C calling convention, if the caller places more arguments on the stack than the function expects, nothing bad will happen. The same caller (that presumably knows how much arguments there are on the stack) releases the stack. As the arguments are pushed right to left, the first argument is always in the same position in relation to the stack pointer when calling the function. This means that if the function expects three arguments, and the caller sends 4, noone will ever notice (assuming the first three are understood correctly, of course). With the Pascal calling convention, such a case is disastrous. As the arguments are cleared by the called function, if it thinks there is a different number or arguments on the stack than there really is, the function will return to the caller with the stack pointer in the wrong place. The program is most likely to crash the moment any further stack activity takes place. In order to avoid this problem, STDCALL functions mangle into the function's name a number indicating the number of bytes the arguments for the function take on the stack. This gives a certain assurance that a mismatch between caller and callee notion of what the arguments are will be translated into a linker failure, rather than inexplicable, seemingly random, runtime crashes. Warning: the following paragraph is pure guesswork. The long explanation was just a way to say that your idea that symbols that have the form of "name(a)number" are STDCALL symbols, while symobls that are pure name are CDECL, seems the only way to understand things. >Thanks again for any help! > >Cheers, >Martin > > Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

2 1

Re: spec files - syntax and generation
by Alexandre Julliard Oct. 28, 2003

Oct. 28, 2003

"Martin Tröster" <troymcclure(a)web.de> writes: > - Stack size and parameters in spec file: > The def files are, as far as I know, very similar to the spec files: > they contain the function name (either mangled or not mangled), as > well as (most of the time) the stack space - format: > functionname(a)stackspace. Is there anything wrong to translate an > entry for "char* testfunc(char* str, int var1, long var2, long* > ptr)" called "testfunc(a)16" into "@stdcall testfunc(ptr ptr ptr > ptr)", without caring for the type of parameters? More explicitely > asked, what use do I have from using str or long instead of ptr in > the spec file? All it does is allow you to get more readable output from the relay traces. If you don't care about that, using 'ptr' everywhere works just fine. > - Stdcall vs. cdecl > How do I find out whether a function uses CDECL instead of STDCALL? > I found the information (link lost unfortunately) that entries in > the def file like testfunc1(a)0 are called via STDCALL, whereas in > case of testfunc2 without any @ specifying the space is CDECL. Is > this guess right? If not, how else do I find this out? Yes this is correct, the stdcall functions are the ones decorated with @xxx. -- Alexandre Julliard julliard(a)winehq.com

1 0

Wine coredumps with Linux kernel 2.6.0-test9
by David D. Hagood Oct. 28, 2003

Oct. 28, 2003

I'm playing with 2.6.0-test9 under RH9.0, and Wine just coredumps when I run it. This is after a full rebuild of Wine, with a CVS pull of a couple of days ago. Since I've seen some other apps behaving weirdly this may be a compatibility issue with 2.6, but I thought I'd see if anybody else has seen this, and has any suggestions. I have updated glibc to the latest in Rawhide.

3 4