- Wine-Devel - list.winehq.org

Re: Add some padding in WINPROC_wrapper
by Mike McCormack Aug. 31, 2004

Aug. 31, 2004

Uwe Bonnes wrote: > Changelog > windows/winproc.c: WINPROC_wrapper > Add some padding between saved registers and the winproc > arguments. Some winprocs may trash the register area. > > As Mike Hearn suggested, adding some padding helped with my problem with > WebPACK_42wp30_full_installer.exe. I hope, I found the right way to add that > padding. It may work for one application, but it doesn't look like a propper fix. I'd suggest there's probably something else going on that's causing stack corruption. Mike

3 7

Re: wineserver epoll
by Alexandre Julliard Aug. 31, 2004

Aug. 31, 2004

Shachar Shemesh <wine-patches(a)shemesh.biz> writes: > After much talk, the patch seems ready for commit. Since there are many > systems with slightly older glibc that have the header but do not have > the implementation in glibc, or that have a stub implementation that is > guaranteed to fail, we are calling the kernel functions directly. This > also allows compiling on older systems than the code actually ships to. > > Accordingly, the autoconf checks for epoll_create in glibc were dropped. That's wrong; if the libc function exists you should use it, direct system calls should only be used as a fallback. And when using system calls you must not depend on the libc header, you have to define the structures yourself. -- Alexandre Julliard julliard(a)winehq.org

5 7

Debug Channels trashed
by Uwe Bonnes Aug. 31, 2004

Aug. 31, 2004

Hallo, I am trying to run the WebPACK_42wp30_full_installer.exe : http://direct.xilinx.com/direct/webpack/42wp3/\ : WebPACK_42wp30_full_installer.exe (a 110 MByte Download). Running it crashes quite early, while testing the debug channels: err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TrueType" err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TT" wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405ac2f0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xc0685566 in 32-bit code (0x40710c60). In 32 bit mode. 0x40710c60 WINPROC_CallWndProc [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) 232 if (TRACE_ON(relay)) 232 if (TRACE_ON(relay)) Wine-dbg>Backtrace: =>1 0x40710c60 WINPROC_CallWndProc+0x70(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32 (0x4067fb7c) 2 0x4071578d CallWindowProcA+0xed(func=0x4078656c, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fba0) 3 0x406eb083 DefDlgProcA+0x63(hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/defdlg.c:451] in user32 (0x4067fbd0) 4 0x40710437 WINPROC_wrapper+0x17 in user32 (0x4067fbf4) 5 0x40710c4c WINPROC_CallWndProc+0x5c(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:230] in user32 (0x4067fc30) 6 0x4071578d CallWindowProcA+0xed(func=0x406eb020, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fc54) 7 0x40725b8f call_window_proc+0x11f(lparam=0x0, unicode=0x0, same_thread=0x1) [/home/wine/wine/dlls/user/message.c:1461] in user32 (0x4067fcb8) 8 0x4072839e SendMessageTimeoutA+0x1be(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x4067fd3c) [/home/wine/wine/dlls/user/message.c:1968] in user32 (0x4067fd18) 9 0x40728425 SendMessageA+0x35(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0) [/home/wine/wine/dlls/user/message.c:2012] in user32 (0x4067fd44) 10 0x406efc5c DIALOG_CreateIndirect+0x107c(dlgProc=0x4012df, param=0x0, unicode=0x0, modal=0x1) [/home/wine/wine/dlls/user/../../windows/dialog.c:672] in user32 (0x4067fe54) 11 0x406f04be DialogBoxParamA+0x4e(hInst=0x400000, name=0x12c, owner=0x0, dlgProc=0x4012df, param=0x0) [/home/wine/wine/dlls/user/../../windows/dialog.c:821] in user32 (0x4067fe78) 12 0x0040184d (0x004137a2) It seems the location of the debug channels is picked up from the ebx register Wine-dbg>disass 0x40710c52 0x40710c52 WINPROC_CallWndProc [../windows/winproc.c:231] in user32: call 0x40707c70 WIN_RestoreWndsLock [/home/wine/wine/dlls/user/../../windows/user.c:183] in user32 0x40710c57 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: movl 0x190(%ebx),%eax 0x40710c5d WINPROC_CallWndProc [../windows/winproc.c:232] in user32: addl $24,%esp 0x40710c60 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) I wonder what can trash the testing of the debug channels. I ran with +heap to look for heap corruption, but couldn't find something. Uncommenting the offending code > if (TRACE_ON(relay)) > DPRINTF( "%04lx:Ret window proc %p (hwnd=%p,msg=%s,wp=%08x,lp=%08lx) retval=%08lx\n", > GetCurrentThreadId(), proc, hwnd, SPY_GetMsgName(msg, hwnd), wParam, lParam, retvalue ); makes the application proceed. Bye -- 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

Linux registry
by Robert van Herk Aug. 31, 2004

Aug. 31, 2004

Not knowing how much off topic this would be, I just thought I paste a link here: http://registry.sourceforge.net/ These people seem to be implementing a kinda Windows registry clone into Linux, but then secure, stable 'n' stuff... Since the many registry implementation discussions here, I thought, why not throw this into the discussion too? It might be worth to take a look here and perhaps think about using some of their stuff. Greetings, Robert van Herk

3 2

Re: SHAllocShared fixes
by Alexandre Julliard Aug. 30, 2004

Aug. 30, 2004

Francois Gouget <fgouget(a)free.fr> writes: > This actually calls for two more notes: > * This looks very much what one would get by calling the corresponding > functions in shlwapi (which seems much more complete). However in > shell32 there is talk of sending messages around (WM_USER+2) so maybe > it's the same concept but a different implementation? The WM_USER+2 thing is something a specific caller was doing, it's not part of the function itself. I think the shell32 functions should simply forward to the shlwapi ones. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mixing SHELL32.DLL and SHFOLDER.DLL
by Juan Lang Aug. 30, 2004

Aug. 30, 2004

Saulius wrote: > Lets try. I am not sure about many things: > > 1, whether is better to duplicate code > SHGetFolderPathW() or to try finding it by an > ordinal its value (the case for the older versions > of SHELL32.DLL) as it was stated by Juergen? What are you trying to accomplish? For example, it seems reasonable to assert that you must use the builtin shell32 and shfolder.dll in combination, or not at all, as Alexandre once suggested. Or, in order for Wine's shfolder.dll to succeed on older (native) versions of shell32.dll, it seems reasonable to have it call SHGetSpecialFolderPath* from SHGetFolderPath*, as MS' version does. In other words, why do you need the combination of native shell32 and builtin shfolder.dll? --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

3 6

Re: working together on stdole.tlb and a end to dcom9x
by Filip Navara Aug. 30, 2004

Aug. 30, 2004

Jacek Caban wrote: [snip] > I don't thik it Wine's bug. Applications don't depend on this stuff > and Wine's ref handling is correct. Of course that applications depend on this stuff. This is common code: LoadTypeLib("stdole.tlb", &ptlibStdOle); ptlibStdOle->GetTypeInfoOfGuid(IID_IUnknown, &ptinfoIUnknown)); ptlibStdOle->GetTypeInfoOfGuid(IID_IDispatch, &ptinfoIDispatch)); ptlibStdOle->Release(); Now with Wine the last Release will cause the typelib object to be destroyed and resulting that any later typeinfo references to typelib are invalid pointers. Regards, Filip

2 2

ScrollBars and Wine
by Diego 'Flameeyes' Pettenò Aug. 30, 2004

Aug. 30, 2004

Hi, Last tuesday I reported some problems with Ultima OnLine AutoPatch ( http://article.gmane.org/gmane.comp.emulators.wine.user/7046 ), with the last CVS and now I found some more information about the problem. Seems like this NULL Pointer (because I think it's this the problem, seeing the 0x00000000) is dereferenced everytime a scrollbar changes position or size (at least while it's painted). I had a similar problem trying to use Inside UO (program to find out data inside the UO files, wrote in Delphi) and everytime I moved a scrollbar I got an NULL Pointer Exception (but in that case it was handled by the Delphi's Exception Handler, so the program didn't closed). Similar problems have Dependency Walker and also native Regedit. Every time I have this: Backtrace: =>1 0x00000000 (0x00001396) 2 0x00000000 (0x00000000) 0x00000000: addb %al,0x0(%eax) as backtrace. With the CVS of two weeks ago at least Dependency Walker run fine without problems at all. -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

1 0

trouble debugging
by James Hawkins Aug. 30, 2004

Aug. 30, 2004

Hi, I'm having a real tough time debugging a program im trying to get to run called KLConfigWizard.exe. I had a problem earlier that was fixed by a tip from Rob. After trying a bunch of different native dll's that this program uses, I located the culprit dll (which is about as much as I seem to be able to do.) If I use native shlwapi then the crash doesnt happen. When i'm not using native shlwapi, the output I get is: [truiken(a)cmu-127081 Kazaa Lite K++]$ wine KLConfigWizard.exe Please use the registry key HKEY_CURRENT_CONFIG\Sotfware\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). In 32 bit mode. 0x00000000: addb %al,0x0(%eax) Wine-dbg>bt Backtrace: =>1 0x00000000 (0x00000000) Wine-dbg>q WineDbg terminated on pid 0x8 I do have the log of WINEDEBUG=trace+all, but the log file is ~243mb? I tried scanning through it looking for anything that would give me a clue, but it was hard to tell where any error was. It also doesnt help that the backtrace doesnt contain much of anything. Any ideas? -- James Hawkins

2 3

Re: CommonUnimpStub looping
by Juan Lang Aug. 30, 2004

Aug. 30, 2004

Mike wrote: > On Sun, 29 Aug 2004 09:23:31 -0700, Steven Edwards > wrote: > > I dont see how native loading of Advapi32 ever > > worked anyway. Its a case like ntdll, kernel32, > > user32 or gdi. Maybe the Win9x advapi32 can..... > > I thought native NT advapi just forwarded to ntdll? Yeah. It depends on a bunch of security APIs that aren't implemented in ntdll though. The win9x advapi32 used to sort of work under wine iirc. I forget at what point that stopped being the case, probably about the time the builtin one became useful. --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

1 0