wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Finding cause of heap corruption
by Uwe Bonnes 23 May '02

23 May '02

Hallo, trying to run xilinx webpack, after some time a crash happens. I suspect a heap corruption and running with --debugmsg +heap I see quite early 133191 098347d0:Call kernel32.TlsGetValue(00000004) ret=6c371018 133192 trace:heap:RtlAllocateHeap (415d0000,00000002,00000018): returning 415e9068 133193 098347d0:Ret kernel32.TlsGetValue() retval=4037bdf0 ret=6c371018 133194 09830f78:Ret ntdll.RtlAllocateHeap() retval=415e9068 ret=41595068 133195 098347d0:Call user32.GetParent(00010022) ret=6c371331 133196 09830f78:Call ntdll.RtlAllocateHeap(415d0000,00000000,0000000e) ret=41595068 133197 098347d0:Ret user32.GetParent() retval=00000000 ret=6c371331 133198 trace:heap:RtlAllocateHeap (415d0000,00000002,00000018): returning 415e9088 133199 098347d0:Call user32.TranslateMessage(0040735c) ret=6c3711c7 133200 09830f78:Ret ntdll.RtlAllocateHeap() retval=415e9088 ret=41595068 133201 098347d0:Ret user32.TranslateMessage() retval=00000000 ret=6c3711c7 133202 098347d0:Call user32.DispatchMessageA(0040735c) ret=6c3711ce 133203 09830f78:Call ntdll.RtlAllocateHeap(415d0000,00000000,00000016) ret=41595068 133204 warn:heap:HEAP_ValidateInUseArena Heap 40d30000: invalid in-use arena magic for 40d30656 133205 Heap: 40d30000 "invalid in-use arena magic" is an indicator for a corrupy heap. Right? On each RtlAllocateHeap(), the heap is checked. As the call to RtlAllocateHeap() on line 133196 succeeds, the trashing must have happend between line 133201 and 133203. Right? Thnaks for any help. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 5

Re: err:clipping:CLIPPING_UpdateGCRegion DC is dirty. Please report this
by dschwarz＠bellatlantic.net 23 May '02

23 May '02

I'm currently running the Lotus Notes 5.0.7 client under the latest WINE (CVS build from 5/22/2002). Works well with no visual glitches that I can see, but I get this message repeated over and over: err:clipping:CLIPPING_UpdateGCRegion DC is dirty. Please report this So, I'm reporting it :-) Can someone tell me what additional information would be useful to debug this problem, and how I can provide it? Thanks, Dan Schwarz dschwarz(a)bellatlantic.net

1 0

SB EMU Patch question
by Dustin Navea 23 May '02

23 May '02

To the author of the SB EMU Patch, I was wondering if you could possibly resubmit the patch for inclusion against the current tree, the day that you last sent it in, I had a failure compiling, I guess due to some conflict from the patches committed that day, so if you could rework it to compile (and work, of course) against the current tree, I would love it, and several other people might too ;). -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Lotus SmartSuite (2000?)
by Dustin Navea 23 May '02

23 May '02

Just saw a post on TransGaming's web site that Lotus SmartSuite runs on WineX...although it took him 2 installs... He also said that installing the MS OLE update improved thimgs even more, so the OLE Update may be something to look into in trying to get it to work... I'm not sure it it was 2000 or Millenium 9.5, but he did say SmartSuite... -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

winhelp mapping
by Eric Pouech 23 May '02

23 May '02

this patch is an attempt to solve the issue of passing contextual information to winhlp32 it simply passes the data block required by the "WM_WINHELP" (in quotes, because it's a registered window message) thru the server, and reallocates it on the win32 size it's a bit ugly because of the registration stuff Alexandre, will you accept a patch of this kind (it still can be enhanced, like storing the message id) ? A+ Name: winhlp ChangeLog: implemented interprocess WM_WINHELP message passing License: X11 GenDate: 2002/05/21 19:51:19 UTC ModifiedFiles: dlls/user/message.c windows/winhelp.c AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/user/message.c,v retrieving revision 1.17 diff -u -u -r1.17 message.c --- dlls/user/message.c 26 Apr 2002 19:05:17 -0000 1.17 +++ dlls/user/message.c 19 May 2002 06:54:18 -0000 @@ -564,6 +564,18 @@ data->count = -1; return 0; } + if (message == RegisterWindowMessageA("WM_WINHELP")) + { + HGLOBAL16 hMem; + char* ptr; + hMem = LOWORD(lparam); + ptr = GlobalLock16(hMem); + push_data(data, ptr, *(WORD*)ptr); + GlobalUnlock16(hMem); + /* FIXME: it's likely that this memory block + * (and more important, the associated selector) will be leaked... */ + return 0; + } return 0; } @@ -803,6 +815,23 @@ return FALSE; default: + if (message == RegisterWindowMessageA("WM_WINHELP")) + { + HGLOBAL16 hMem; + WORD sz; + char* dst; + + if (size < sizeof(WORD)) return FALSE; + sz = *(WORD*)*buffer; + if (size != sz) return FALSE; + hMem = GlobalAlloc16(0,sz); + dst = GlobalLock16(hMem); + memcpy(dst, *buffer, sz); + GlobalUnlock16(hMem); + *lparam = hMem; + return TRUE; + } + return TRUE; /* message doesn't need any unpacking */ } @@ -1622,7 +1651,7 @@ SetLastError( ERROR_INVALID_THREAD_ID ); else SetLastError( RtlNtStatusToDosError(res) ); - } + } } SERVER_END_REQ; return !res; Index: windows/winhelp.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/windows/winhelp.c,v retrieving revision 1.22 diff -u -u -r1.22 winhelp.c --- windows/winhelp.c 10 Mar 2002 00:18:37 -0000 1.22 +++ windows/winhelp.c 19 May 2002 06:56:45 -0000 @@ -82,7 +82,6 @@ HGLOBAL16 hwh; int size,dsize,nlen; - if(!WM_WINHELP) { WM_WINHELP=RegisterWindowMessageA("WM_WINHELP"); @@ -103,7 +102,6 @@ } } - switch(wCommand) { case HELP_CONTEXT: @@ -152,7 +150,8 @@ } else lpwh->ofsData = 0; GlobalUnlock16(hwh); - return SendMessage16(hDest,WM_WINHELP,hWnd,hwh); + + return SendMessageA(hDest,WM_WINHELP,hWnd,hwh); }

4 3

tools/wineshelllink Full KDE3 Support-patch tomorrow
by Dustin Navea 23 May '02

23 May '02

Hey, received a note from Riszanyi Zsolt asking to implement use of $KDEHOME in wineshelllink. Well, I took a look at it, and started to do that, but then I realized that if we do that and they have 2 versions of KDE installed (i.e. Mandrake 8.2's way, KDE2 in /usr and KDE3 in /opt), the icons will only be in 1 of the 2 directories. So, instead I finished off my KDE3 support, and it will be submitted tomorrow, I have 1 minor change to make to it. -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

3 4

Recursion caused by call of GetProp in window procedure
by Andriy Palamarchuk 22 May '02

22 May '02

I'm researching bug 671: http://bugs.winehq.com/show_bug.cgi?id=671 The application crashes. It seems the problem occurs when GetPropA is called in a window procedure on WM_WINDOWPOSCHANGING message what causes generation of other WM_WINDOWPOSCHANGING message. The same code calls itself and finally blows the stack. See the bug for details. Does anybody know why the recursion occurs? Does GetPropA call generate WM_WINDOWPOSCHANGING message? The relay trace of the recursion. It is nicer formatted in the bug comments: Call user32.GetPropA(00010036,40e33086 "buddySupperClassWndProc") ret=40e1b396 Ret user32.GetPropA() retval=40ec0a9a ret=40e1b396 Call user32.CallWindowProcW(40ec0a9a,00010036,00000046,00000000,405b5f5c) ret=40e1b3fd Call window proc 0x488568 (hwnd=00010036,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=405b5f5c) Call kernel32.TlsGetValue(00000002) ret=004a7180 Ret kernel32.TlsGetValue() retval=403be080 ret=004a7180 Call kernel32.TlsGetValue(00000002) ret=004a7180 Ret kernel32.TlsGetValue() retval=403be080 ret=004a7180 Call kernel32.TlsGetValue(00000002) ret=004a7180 Ret kernel32.TlsGetValue() retval=403be080 ret=004a7180 Call ntdll.RtlEnterCriticalSection(00544c60) ret=004a6c89 Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=004a6c89 Call ntdll.RtlLeaveCriticalSection(00544c60) ret=004a6cad Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=004a6cad Call user32.CallWindowProcA(40ec0a16,00010036,00000046,00000000,405b5f5c) ret=00488d7b Call window proc 0x40e1b370 (hwnd=00010036,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=405b5f5c) Call user32.GetPropA(00010036,40e33086 "buddySupperClassWndProc") ret=40e1b396 Thanks, Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

The 'file' regression test fails on NT
by Francois Gouget 22 May '02

22 May '02

I tested the 'file' regression test on NT4 and XP and it fails on both. Here is where the error occurs: tests/file.c:236: Test failed: DeleteFile failed (5). tests/file.c:240: Test failed: couldn't create file "testfile.xxx" (err=5) tests/file.c:242: Test failed: _hwrite complains. [...] 5 means 'permission denied'. DeleteFile fails just after _lcreat(filename,1) creates a read-only file: H:\wine\wine\dlls\kernel>attrib testfile.xxx A R H:\wine\wine\dlls\kernel\testfile.xxx Because that file is marked read-only, DeleteFile fails to delete it, then causing the failure of all the other tests. I checked and the same happens on non-smb drives (c:\). I also checked that the exact same thing happens on Windows 98. So the test needs to be fixed. Jakob, can you do this? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

3 4

Re: Wineconsole (again)
by Andreas Mohr 22 May '02

22 May '02

On Mon, May 20, 2002 at 09:50:03PM +0200, Eric Pouech wrote: > this patch fixes a set of issues: > 1/ large fonts could be picked up if no decent registry content was > found > (thanks to Sylvain Petreolle and Andi Mohr for the bug reports) > 2/ better error messages in case of failure (even if I'm sure Andi will > not like them... feel free to be more verbose) Yep, true. (and I forgot to tell you before :-\) Why is the "missing font" message a WINE_WARN ? IMHO this should clearly be a WINE_ERR, as it's a user warning, it's not only of interest to developers. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

6 9

Want to help Wine project?
by Andriy Palamarchuk 22 May '02

22 May '02

This message is for those who wants to help Wine project but do not know where to start. We need contributors of a wide range of skills. The minimal requirements are: access to a computer with Linux (or other Unix-like system) where you can use Wine. We have a lot of tasks which are relatively easy to do. The fact that these tasks are easy does not mean they are not important. Examples of the easiest non-programming tasks available: * we *badly* need application owners. An application owner is a person who often uses some application and will help to make it work perfectly under Wine. Does anybody use Lotus Notes regulary under Wine? * confirm and research bugs in Wine Bugzilla http://bugs.winehq.com * Add a 'Debunking Wine Myths' web page http://bugs.winehq.com/show_bug.cgi?id=606 Examples of the easiest programming tasks available: * Help Wine hackers - document Wine debugging channels http://bugs.winehq.com/show_bug.cgi?id=638 * Improve RichEdit headers http://bugs.winehq.com/show_bug.cgi?id=330 Easy, aren't they? Do you need more choice? * file BUGS in the Wine source tree gives more information how you can help the project * bug 406 contains list of issues which is easy to fix. Don't be afraid to fix all the easy issues, so nothing will be left to others. We'll gladly add more! :-) http://bugs.winehq.com/showdependencytree.cgi?id=406 * suggest your help on wine-devel mailing list. Don't forget to mention your skills, experience and what you want to work on. If you want to know more - just ask. Have fun! Andriy Palamarchuk __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Cleanup code in winemaker wrapper broken?
by Martin Wilck 22 May '02

22 May '02

I finally start to get around my initialization problem. However I got crashes in the Test_wrapper routine generated by winemaker in the cleanup code. This winemaker-generated code: /* Cleanup and done */ FreeLibrary(hApp); if (hMFC!=NULL) { FreeLibrary(hMFC); } dlclose(appLibrary); must be commented out, and the app works as expected. Is it possible that the cleanup code in wine has changed? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

winemaker (fwd) (Re: Please comment - I'me stuck).
by lawson_whitney＠juno.com 22 May '02

22 May '02

Martin, I hope this will geve you enough to get on with. Maybe you have enough Perl to fix winemaker? If not you can hack Makefiles as I do. Lawson ---------- Forwarded message ---------- Date: Sat, 18 May 2002 23:23:42 -0400 (EDT) From: whit(a)giftie.alien.org To: Francois Gouget <fgouget(a)free.fr> Subject: winemaker Good day! It seems winemaker is a bit behind on imports. I checked that the latest cvs would still run my app, installed it, and my winelib app stopped working. I tried to rebuild it, failed, tried winemaker on it, failed, and spent the day learning how to hand-hack things. -idll puts an "include dll" in the .spec file, where winebuild doesn't want to see it, but I hacked -ldll (in this case, -lole32) into the winebuild line in the Makefile after $(WINE_DLL_PATH) and before -sym into the Makefile (in truth, I used EXE_IMPORTS, Makefile.in, Make.rules.in and autoconf, but you get the idea) and am no longer mute. This is not a complaint. Thank you again for winemaker, but if you hadn't noticed, maybe you would like to know. I guess you will fix it before I can work out how, but if not, would you prefer that I offer a patch to you first, or wine-patches? Regards, Lawson

1 0

Wine crash before initialization - is this faulty code ?
by Martin Wilck 22 May '02

22 May '02

Hi - I had a wine crash today that occurs before wine is properly initialized, and therefore was pretty nasty to debug. However I traced it down to the test program below. The test program is loaded as a winelib app (i.e. a dll). The program defines a global variable that is an instance of a class where the constructor calls InitalizeCriticalSection(). Interestingly, the call to RtlInitializeCriticalSection() completes successfully, but subsequently the program crashes and the stack is corrupted, so that I can't really see where the program is stuck. It seems that the dlopen() call in wine_dlopen() on Test.so never finishes, though. This seems to run fine on windows. Comments? Martin #include <winbase.h> #include <stdio.h> class cs_test; class cs_test { public: CRITICAL_SECTION crit; cs_test(); ~cs_test() {}; }; cs_test::cs_test() { memset ( &(this->crit), 0, sizeof (CRITICAL_SECTION) ); InitializeCriticalSection ( &(this->crit) ); }; // this statement causes the crash when called at DLL load time cs_test tst; int main() { return 0; } -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 3

Researching crash in bug 637
by Andriy Palamarchuk 22 May '02

22 May '02

I'm researching a crash, described in bug 637: http://bugs.winehq.com/show_bug.cgi?id=637 I can't understand why the application crashes. Can somebody give me a hint what is going on? It seems the app quietly draws some staff, then loads an error message (?) and crashes. Snippet of the relay trace is attached. Thanks, Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com 080706d8:Call user32.ReleaseDC(00000000,00000860) ret=00726451 080706d8:Call x11drv.SetDeviceClipping(403be750,00000bc6) ret=4085066d 080706d8:Ret x11drv.SetDeviceClipping() retval=00000000 ret=4085066d 080706d8:Call x11drv.SelectBrush(403be750,0000006e) ret=4085d70e 080706d8:Ret x11drv.SelectBrush() retval=0000006e ret=4085d70e 080706d8:Call x11drv.GetDeviceCaps(403be750,00000022) ret=408531e1 080706d8:Ret x11drv.GetDeviceCaps() retval=000079f7 ret=408531e1 080706d8:Call x11drv.SelectFont(403be750,000000a2) ret=4085d4a3 080706d8:Ret x11drv.SelectFont() retval=00000001 ret=4085d4a3 080706d8:Call x11drv.SelectPen(403be750,0000008a) ret=4085d736 080706d8:Ret x11drv.SelectPen() retval=0000008a ret=4085d736 080706d8:Call x11drv.SetBkColor(403be750,00ffffff) ret=40853262 080706d8:Ret x11drv.SetBkColor() retval=00ffffff ret=40853262 080706d8:Call x11drv.SetTextColor(403be750,00000000) ret=408532fa 080706d8:Ret x11drv.SetTextColor() retval=00000000 ret=408532fa 080706d8:trace:palette:GDISelectPalette16 0860 0092 080706d8:Ret user32.ReleaseDC() retval=00000001 ret=00726451 080706d8:Call kernel32.GetSystemInfo(405b692c) ret=00726271 080706d8:Ret kernel32.GetSystemInfo() retval=400be0b8 ret=00726271 080706d8:Call gdi32.CreatePalette(405b6960) ret=007264f7 080706d8:trace:palette:CreatePalette entries=16 080706d8:trace:palette:CreatePalette returning 10c6 080706d8:Ret gdi32.CreatePalette() retval=000010c6 ret=007264f7 080706d8:Call kernel32.FreeResource(008f3bd4) ret=0074a774 080706d8:Ret kernel32.FreeResource() retval=00000000 ret=0074a774 080706d8:Call kernel32.GetThreadLocale() ret=0064f1b4 080706d8:Ret kernel32.GetThreadLocale() retval=00000409 ret=0064f1b4 080706d8:Call kernel32.GetLocaleInfoA(00000409,0000100c,0087fa70,00000001) ret=0064f1ba 080706d8:trace:string:GetLocaleInfoA (lcid=0x409,lctype=0x100c,0x87fa70,1) 080706d8:trace:resource:RES_FindResource2 (40614000, 00000006, 00000101, 0409, W, PE) 080706d8:trace:resource:RES_LoadResource (40614000, 40659470, PE) 080706d8:trace:resource:LockResource (406417a0) 080706d8:trace:string:NLS_LoadStringExW strlen = 1 080706d8:trace:string:NLS_LoadStringExW L"6" loaded! 080706d8:trace:string:lstrcpynA (0x87fa70, "6", 1) 080706d8:Ret kernel32.GetLocaleInfoA() retval=00000001 ret=0064f1ba 080706d8:Call user32.LoadStringA(00400000,0000ff5e,405b6a1c,00000400) ret=0076068a 080706d8:trace:resource:LoadStringA instance = 400000, id = ff5e, buffer = 405b6a1c, length = 1024 080706d8:trace:resource:LoadStringW instance = 400000, id = ff5e, buffer = 403c42ac, length = 1024 080706d8:trace:resource:RES_FindResource2 (00400000, 00000006, 00000ff6, 0000, W, PE) 080706d8:trace:resource:RES_LoadResource (00400000, 008ed720, PE) 080706d8:trace:resource:LockResource (009000c8) 080706d8:trace:resource:LoadStringW strlen = 33 080706d8:trace:resource:LoadStringW L"'%s' is not a valid integer value" loaded ! 080706d8:trace:resource:LoadStringA "'%s' is not a valid integer value" loaded ! 080706d8:Ret user32.LoadStringA() retval=00000021 ret=0076068a 080706d8:Call kernel32.RaiseException(0eedfade,00000001,00000007,405b6dfc) ret=007569fe 080706d8:trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x400cb634 080706d8:trace:seh:EXC_RtlRaiseException info[0]=007569fe 080706d8:trace:seh:EXC_RtlRaiseException info[1]=41166354 080706d8:trace:seh:EXC_RtlRaiseException info[2]=4116632c 080706d8:trace:seh:EXC_RtlRaiseException info[3]=405b6e3c 080706d8:trace:seh:EXC_RtlRaiseException info[4]=00000000 080706d8:trace:seh:EXC_RtlRaiseException info[5]=405b6e4c 080706d8:trace:seh:EXC_RtlRaiseException info[6]=405b6e18 080706d8: queue_exception_event( first=1, record={context={flags=00010007,eax=405b6cd8,ebx=40100444,ecx=00000000,edx=0eedfade,esi=405b6e18,edi=405b6d08,ebp=405b6d34,eip=400cb6a4,esp=405b6cd8,eflags=00000246,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000021,dr1=0076068a,dr2=400ef8d2,dr3=00000000,dr6=00000004,dr7=000471c8,float={407c3c20,405b6a0c,00000000,72657375,4c2e3233,5364616f,6e697274,40004167,405b6b44,401171c8,fbad8001,401171c8,401171c8,401171c8,0075ecc6,0075d873,405b6e28,0075d8a0,405b69f8,00000021,405b6a1c,405b6e44,00000000,41166324,405b6e4c,0075dcf6,4116632c,405b6a1c}},rec={code=eedfade,flags=1,rec=(nil),addr=0x400cb634,params={7569fe,41166354,4116632c,405b6e3c,0,405b6e4c,405b6e18}} ) 080706d8: queue_exception_event() = 0 { handle=0 }

5 7

Re: unix app <-wine-> windows odbc driver (dll)
by Aaron 21 May '02

21 May '02

Hi- I have been reading, http://wine.codeweavers.com/docs/winelib-user/bindlls.shtml http://www.unixodbc.org/doc/wine.html in order to understand how to communicate with a windows odbc driver from linux. I have a working windows setup for connecting to a remote synergex database with ODBC drivers they provided. What I would like to do is be able to access the DSN provided by this ODBC driver via wine. The examples I've read seem to be the opposite of what I want to do. I have looked at dlls/odbc32/proxyodbc.c and it seems to hook unixodbc into wine as the Driver Manager. But I don't know what makes sense to put into the /etc/odbc.ini or /etc/odbcinst.ini or perhaps .wine/fake-windows/ODBC.INI .wine/fake-windows/ODBCINST.INI for the DSN provided from within wine. Is this possible. Has anybody done this before?

1 0

Re: SafeDisc-1
by Joerg Mayer 21 May '02

21 May '02

Alexandre, there were two files in this patch. Is there a specific reason, why they were not completely applied? It looks to me that only parts of the first file were applied. Thanks Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

3 2

Office 97 installation
by Raul Dias 21 May '02

21 May '02

Hi, Sorry if this has been discussed before but I could not find a searchable archieve of the list. For some time now Microsoft Office 97 installs almost perfect. However, in the end of the instalation it warns about vbe.dll could not regiter itself. Then the instalation ends with an error. Even with the error, everything is in place. The registries are correct (at least they seem to be). Word and Excel runs nicely. Everything in a windows/native dlls free environment. I found this document about the issue from Microsoft: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q162627 I check everything it says and everything seems to be correct. As more people have tryied Office 97/2000 with wine, this error might be already known. (I hope so) So, why does it happen? Is it a bug or something not implemented (or half implemented) in wine? Is this caused by some missing file/dll/registry entry ? Is this some ugly undocumented hack that office 97 installer does? btw, the version is Office 97 Pro in pt_BR. []'s Raul Dias

2 4

Re: Loadorder should check library name, not path
by Alexandre Julliard 21 May '02

21 May '02

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > at present, wine e.g. crashes if it finds user32.dll in the same directory > as the executable. To keep wine from using this DLL, the dos-path to that > dll has to be given explicit to the "-dll" argument, like > wine h:/tmp/programm.exe --dll h:\\tmp\\user32.dll=b > (e.g. with a user32.dll in h:/tmp/) > > I don't think we need that high granularity to select between builtin and > native dlls. Yes, there are cases where this is needed. Do you really have an app that comes with its own user32.dll? I don't see how this can work under Windows either. -- Alexandre Julliard julliard(a)winehq.com

2 6

Re: Behaviour of GetModuleFileName
by Warren_Baird＠cimmetry.com 21 May '02

21 May '02

> Builtin dlls don't have a full path because there is no associated > file that we could point to (at least as seen from Windows). If this > breaks your app it can be changed, but I'm not sure it will really fix > anything. What does the app do with the filename? To answer your last question first - the code gets the path of the current library, and then uses that path to find a set of plugins by finding all libraries matching a certain pattern in the same directory... A bit hackish, perhaps, but it works, as long as GetModuleFileName returns a full path... Isn't there a requirement that the wine libraries be in a directory that is mappable to a windows path? I thought I ran into problems when I had forgotten to add an entry to my wine config to include my wine libraries... If so, then there will always be a windows path for each dll... > You should not need to change the spec file at all. If you need a full > name you should prefix the name with the windows system directory at > load time. Well, the problem is that it's one of our libraries (compiled with winelib) that is causing the problem - and I have no idea where our libraries have been installed... I know I could force the users to set up an environment variable or something to point to the library directory, but this approach is much simpler, or would be if GetModuleFileName worked as it does on windows... Warren

1 0

Re: Behaviour of GetModuleFileName
by Alexandre Julliard 21 May '02

21 May '02

Warren_Baird(a)cimmetry.com writes: > Isn't there a requirement that the wine libraries be in a directory that is > mappable to a windows path? I thought I ran into problems when I had forgotten > to add an entry to my wine config to include my wine libraries... If so, then > there will always be a windows path for each dll... No, by default builtins are in /usr/local/lib/wine and there is no need to have a Windows drive for that, so you can't return a valid Windows path. Right now you need to have a drive for Winelib applications (which is probably the problem you had), but I'm working on fixing that too. > Well, the problem is that it's one of our libraries (compiled with winelib) that > is causing the problem - and I have no idea where our libraries have been > installed... I know I could force the users to set up an environment variable or > something to point to the library directory, but this approach is much simpler, > or would be if GetModuleFileName worked as it does on windows... If the library is not installed in the default path you'll need to set WINEDLLPATH for Wine to find it, so you could potentially use that from your app too. Not as simple as GetModuleFileName I admit. -- Alexandre Julliard julliard(a)winehq.com

1 0

winedbg problem
by Sylvain Petreolle 21 May '02

21 May '02

Hi all, I encounter this (funny one) : Wine-dbg>cont Cannot pass on last chance exception. You must use cont Wine-dbg> What could I do ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Again Part2 - Mingw Port 5-20-02
by Steven Edwards 21 May '02

21 May '02

Fails - I will need to retest comctl and comdlg because of the GetSysColorPen Changes. ole32.dll - (Mingw: missing -lntdll, needs msvcrt import do to _assert usage) dllwrap --add-stdcall-alias --def ole32.spec.def --implib ole32.a -o ole32.dll a ntimoniker.o bindctx.o clipboard.o compobj.o compositemoniker.o datacache.o defa ulthandler.o errorinfo.o filemoniker.o hglobalstream.o ifs.o itemmoniker.o marsh al.o memlockbytes.o moniker.o ole2.o ole2stubs.o ole2impl.o ole2nls.o ole32_main .o oleobj.o oleproxy.o rpc.o stg_bigblockfile.o stg_stream.o storage.o storage32 .o ole32.dll.dbg.o -L../../dlls -ladvapi32 -luser32 -lgdi32 -lrpcrt4 -lkern el32 -lntdll -lmsvcrt -L../../library -lwine -L../../ole -lwine_uuid -lm compobj.o(.text+0xd3e):compobj.c: undefined reference to `MapSL@4' compobj.o(.text+0xd48):compobj.c: undefined reference to `MapSL@4' compobj.o(.text+0xd53):compobj.c: undefined reference to `K32WOWCallback16Ex@20' compobj.o(.text+0xdaf):compobj.c: undefined reference to `MapSL@4' compobj.o(.text+0x15e1):compobj.c: undefined reference to `GetCurrentTask@0' ifs.o(.text+0x487):ifs.c: undefined reference to `MapLS@4' ifs.o(.text+0x529):ifs.c: undefined reference to `MapSL@4' ifs.o(.text+0x543):ifs.c: undefined reference to `MapLS@4' ifs.o(.text+0x551):ifs.c: undefined reference to `UnMapLS@4' ifs.o(.text+0x593):ifs.c: undefined reference to `MapSL@4' ifs.o(.text+0x5f1):ifs.c: undefined reference to `UnMapLS@4' ifs.o(.text+0x691):ifs.c: undefined reference to `MapSL@4' ifs.o(.text+0x910):ifs.c: undefined reference to `GetModuleHandle16@4' ifs.o(.text+0x946):ifs.c: undefined reference to `GetProcAddress16@8' ifs.o(.text+0x97f):ifs.c: undefined reference to `GetProcAddress16@8' ifs.o(.text+0x9bb):ifs.c: undefined reference to `GetProcAddress16@8' ifs.o(.text+0x9f7):ifs.c: undefined reference to `GetProcAddress16@8' ifs.o(.text+0xa33):ifs.c: undefined reference to `GetProcAddress16@8' ifs.o(.text+0xa6f):ifs.c: more undefined references to `GetProcAddress16@8' foll ow ifs.o(.text+0xb5a):ifs.c: undefined reference to `MapLS@4' ifs.o(.text+0xb7f):ifs.c: undefined reference to `MapLS@4' ole2.o(.text+0x1fe4):ole2.c: undefined reference to `LockResource16@4' ole2.o(.text+0x305a):ole2.c: undefined reference to `LoadLibrary16@4' ole2.o(.text+0x307f):ole2.c: undefined reference to `FreeLibrary16@4' ole2.o(.text+0x3093):ole2.c: undefined reference to `CreateMetaFile16@4' ole2.o(.text+0x30c9):ole2.c: undefined reference to `GlobalAlloc16@8' ole2.o(.text+0x30d9):ole2.c: undefined reference to `GlobalLock16@4' ole2.o(.text+0x3100):ole2.c: undefined reference to `CloseMetaFile16@4' storage.o(.text+0x2c51):storage.c: undefined reference to `UnMapLS@4' storage.o(.text+0x4431):storage.c: undefined reference to `GetModuleHandle16@4' storage.o(.text+0x4451):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x448b):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x44c7):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x4503):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x453f):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x457b):storage.c: more undefined references to `GetProcAddress1 6@8' follow storage.o(.text+0x4792):storage.c: undefined reference to `MapLS@4' storage.o(.text+0x4817):storage.c: undefined reference to `MapLS@4' storage.o(.text+0x4a6c):storage.c: undefined reference to `UnMapLS@4' storage.o(.text+0x4b63):storage.c: undefined reference to `MapLS@4' storage.o(.text+0x4fff):storage.c: undefined reference to `MapSL@4' storage.o(.text+0x53ff):storage.c: undefined reference to `MapSL@4' storage.o(.text+0x5723):storage.c: undefined reference to `MapSL@4' storage.o(.text+0x58fb):storage.c: undefined reference to `MapSL@4' storage.o(.text+0x5b81):storage.c: undefined reference to `GetModuleHandle16@4' storage.o(.text+0x5ba1):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x5bb7):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x5bcd):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x5be3):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x5bf9):storage.c: undefined reference to `GetProcAddress16@8' storage.o(.text+0x5c0f):storage.c: more undefined references to `GetProcAddress1 6@8' follow storage.o(.text+0x5d28):storage.c: undefined reference to `MapLS@4' storage.o(.text+0x5dc9):storage.c: undefined reference to `MapLS@4' storage.o(.text+0x5f43):storage.c: undefined reference to `MapSL@4' storage.o(.text+0x651f):storage.c: undefined reference to `MapSL@4' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [ole32.dll] Error 1 psapi.dll - (missing -lntdll import, missing kernel32 import) dllwrap --add-stdcall-alias --def psapi.spec.def --implib psapi.a -o psapi.dll p sapi_main.o psapi.dll.dbg.o -L../../dlls -lkernel32 -lntdll -L../../library -lwine -lm psapi_main.o(.text+0x300):psapi_main.c: undefined reference to `Process32First@8 psapi_main.o(.text+0x317):psapi_main.c: undefined reference to `Process32Next@8' psapi_main.o(.text+0x69c):psapi_main.c: undefined reference to `Module32First@8' psapi_main.o(.text+0x6b3):psapi_main.c: undefined reference to `Module32Next@8' psapi_main.o(.text+0x1254):psapi_main.c: undefined reference to `wine_server_cal l' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [psapi.dll] Error 1 shell32 - (missing -lshlwapi import + needs msvcrt import) dllwrap --add-stdcall-alias --def shell32.spec.def --implib shell32.a -o shell32 .dll brsfolder.o changenotify.o classes.o clipboard.o control.o dataobject.o deb ughlp.o dialogs.o enumidlist.o folders.o iconcache.o memorystream.o pidl.o shell 32_main.o shell.o shelllink.o shlmenu.o shellole.o shellord.o shellpath.o shells tring.o shellreg.o shlexec.o shlfileop.o shlfolder.o shlview.o shpolicy.o shv_bg _cmenu.o shv_item_cmenu.o systray.o shell32.dll.dbg.o -L../../dlls -lole32 -lshlwapi -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lmsvcrt -L../../lib rary -lwine -L../../ole -lwine_uuid -L../../unicode -lwine_unicode -lm iconcache.o(.text+0x5e3):iconcache.c: undefined reference to `PrivateExtractIcon sA@32' iconcache.o(.text+0x5fe):iconcache.c: undefined reference to `PrivateExtractIcon sA@32' iconcache.o(.text+0x116d):iconcache.c: undefined reference to `PrivateExtractIco nsA@32' iconcache.o(.text+0x119b):iconcache.c: undefined reference to `PrivateExtractIco nsA@32' iconcache.o(.text+0x11e7):iconcache.c: undefined reference to `PrivateExtractIco nsA@32' shell32_main.o(.text+0x31ce):shell32_main.c: more undefined references to `Priva teExtractIconsA@32' follow shell32_main.o(.text+0x363d):shell32_main.c: undefined reference to `GlobalLock1 6@4' shell32_main.o(.text+0x3654):shell32_main.c: undefined reference to `GlobalFree1 6@4' shell32_main.o(.text+0x3de7):shell32_main.c: undefined reference to `MapSL@4' shell32_main.o(.text+0x3e9d):shell32_main.c: undefined reference to `MapSL@4' shell32_main.o(.text+0x3ee2):shell32_main.c: undefined reference to `GlobalLock1 6@4' shell.o(.text+0x564):shell.c: undefined reference to `GlobalLock16@4' shell.o(.text+0x656):shell.c: undefined reference to `GlobalUnlock16@4' shell.o(.text+0x6d2):shell.c: undefined reference to `GlobalFree16@4' shell.o(.text+0x746):shell.c: undefined reference to `GlobalLock16@4' shell.o(.text+0x773):shell.c: undefined reference to `GlobalUnlock16@4' shell.o(.text+0x93c):shell.c: undefined reference to `GlobalAlloc16@8' shell.o(.text+0x94c):shell.c: undefined reference to `GlobalLock16@4' shell.o(.text+0x965):shell.c: undefined reference to `LoadLibrary16@4' shell.o(.text+0xa0a):shell.c: undefined reference to `GlobalFree16@4' shell.o(.text+0xa38):shell.c: undefined reference to `PrivateExtractIconsA@32' shell.o(.text+0xaa1):shell.c: undefined reference to `PrivateExtractIconsA@32' shell.o(.text+0xb0a):shell.c: undefined reference to `GlobalFree16@4' shell.o(.text+0xe5b):shell.c: undefined reference to `GetModuleFileName16@12' shell.o(.text+0x10f1):shell.c: undefined reference to `GetDOSEnvironment16@0' shell.o(.text+0x10ff):shell.c: undefined reference to `MapSL@4' shell.o(.text+0x11c7):shell.c: undefined reference to `GetDOSEnvironment16@0' shell.o(.text+0x11cf):shell.c: undefined reference to `MapSL@4' shell.o(.text+0x1591):shell.c: undefined reference to `CallNextHookEx16@16' shell.o(.text+0x169b):shell.c: undefined reference to `GetModuleHandle16@4' shell.o(.text+0x16ad):shell.c: undefined reference to `GetProcAddress16@8' shell.o(.text+0x16c2):shell.c: undefined reference to `SetWindowsHookEx16@16' shelllink.o(.text+0x71c3):shelllink.c: undefined reference to `wine_get_unix_fil e_name@12' shlexec.o(.text+0xf1e):shlexec.c: undefined reference to `WinExec16@8' shlexec.o(.text+0x1345):shlexec.c: undefined reference to `WinExec16@8' shlexec.o(.text+0x1591):shlexec.c: undefined reference to `WinExec16@8' shlexec.o(.text+0x1691):shlexec.c: undefined reference to `WinExec16@8' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [shell32.dll] Error 1 shlwapi.dll dllwrap --add-stdcall-alias --def shlwapi.spec.def --implib shlwapi.a -o shlwapi .dll ordinal.o path.o reg.o regstream.o shlwapi_main.o string.o url.o shlwa pi.dll.dbg.o -L../../dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -L../../library -lwine -L../../ole -lwine_uuid -L../../unicode -lwine_unicode -lm string.o(.text+0x1d2d):string.c: undefined reference to `wvsnprintfA@16' string.o(.text+0x1d61):string.c: undefined reference to `wvsnprintfW@16' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [shlwapi.dll] Error 1

2 3

Behaviour of GetModuleFileName
by Warren_Baird＠cimmetry.com 21 May '02

21 May '02

So it looks to me like GetModuleFileName is always returning *only* the filename of the module, not the full path. MSDN says: lpFilename [out] Pointer to a buffer that receives the path and file name of the specified module. And I've come across some windows code that relies on this behaviour.... I've come up with a somewhat messy patch to fix this by adding a call to dlinfo in the spec code generated by winebuild, but unfortunately there seems to be some code in wine that relies on GetModuleFileName returning only the filename. My current hack is to maintain two versions of winebuild - the one I use when building wine, and the one I use when building my code... Hardly elegant. I have two questions: 1. Would anyone object if I tried to fix wine to behave properly with GetModuleFileName returning the full path? I haven't dug into it yet, so I don't know how much effort will be required... Is there a reasons we have the current behaviour? 2. I've attached the patch I'm using at the bottom of this message - can anyone think of a cleaner way of doing this? Thanks! Warren ------------------------------------------------------------- --- spec32.c Thu Apr 11 11:53:35 2002 +++ spec32.c.full_path Thu Apr 11 11:51:53 2002 @@ -751,12 +751,28 @@ fprintf( outfile, "#endif /* defined(__GNUC__) */\n\n" ); fprintf( outfile, + "#include <dlfcn.h>\n" + "#include <link.h>\n" "void __wine_spec_%s_init(void)\n" "{\n" " extern void __wine_dll_register( const struct image_nt_headers *, const char * );\n" " extern void *__wine_dbg_register( char * const *, int );\n" - " __wine_dll_register( &nt_header, \"%s\" );\n", - DLLName, DLLFileName ); + " char buffer[4096];\n" + " Link_map *p;\n" + " if (dlinfo(RTLD_SELF,RTLD_DI_LINKMAP,&p)) {\n" + " strcpy(buffer,\"%s\");\n" + " } else {\n" + " strncpy(buffer,p->l_name,sizeof(buffer));\n" + " char *tag = strrchr(buffer,'/');\n" + " if (tag) {\n" + " tag +=1;\n" + " strcpy(tag,\"%s\");\n" + " }\n" + " \n" + " }\n" + "\n" + " __wine_dll_register( &nt_header, buffer );\n", + DLLName, DLLName, DLLFileName,DLLName ); if (nr_debug) fprintf( outfile, " debug_registration = __wine_dbg_register( debug_channels, %d );\n", nr_debug );

3 2

Re: Behaviour of GetModuleFileName
by Warren_Baird＠cimmetry.com 21 May '02

21 May '02

> Huh, and what about this ?? > > /*********************************************************************** > * GetModuleFileNameA (KERNEL32.@) > * GetModuleFileName32 (KERNEL.487) > * > * GetModuleFileNameA seems to *always* return the long path; > * it's only GetModuleFileName16 that decides between short/long path > * by checking if exe version >= 4.0. > * (SDK docu doesn't mention this) > */ > > So isn't this the case any more ? > If so, then it should of course be fixed. > But I'm wondering how it could have become broken then in the first place... > I thought that long/short paths in this context referred to whether the path was hashed to fit in 8.3 (short) or not (long)... I didn't think it had to do with whether the full path or only the filename was returned. > Hmm, or do you mean that only *builtin* modules return the file name only > and not the complete path ? > That'd definitely be a reason to fix something... If by 'builtin' you mean compiled with winelib (as opposed to native modules) - Then the answer is that I'm not sure - I"m working on Sparc-solaris, so I'm *only* dealing with winelib compiled modules. I don't know how it behaves with native modules... The issue is that an incorrect string is stored in the module header by the call to __wine_dll_register, so I guess it is likely that the problem only exists with winelib compiled libraries... > > 1. Would anyone object if I tried to fix wine to behave properly with > > GetModuleFileName returning the full path? I haven't dug into it yet, so I > > don't know how much effort will be required... Is there a reasons we have the > > current behaviour? > Just go ahead, I guess. Ok - I'll look into it a bit more and see how much effort it would be to fix wine to work with this... Thanks! Warren

1 0

RE: MS ACM MP3 decoder
by Eric Pouech 21 May '02

21 May '02

Of course, I don't claim X11 license over all the patch However, the Wine only part (the mpgl3.c file) is under an X11 license. The rest remains LGPL The ReWind tree will likely not include the LGPL code but propose configure options to add the mpglib A+ > > "Eric Pouech" <eric.pouech(a)wanadoo.fr> wrote: > > > > > this patch implements an ACM MP3 decoder (only, no coder) > > > it is based on the mpglib (which is now LGPL, and which is > > > included in the patch) > > > > If you base your code on the LGPL'ed code, you can't claim > > it has an X11 license. > > Of course he can, if Wine is just a user of mpglib, the > LGPL makes no claim on users only and even if it > did HIS code can still be under the X11 license. > > We have discussed this before and at the very least everybody seems > to agree on that unless the LGPL code depends on Wine everything is fine. > The mpglib obviously doesn't depend on Wine and that's it. > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel