wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Wine Emulation: Swapping functions
by Alexandre Julliard 04 Sep '04

04 Sep '04

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Hi Alexandre, > > This patch allows to load a PE exe to memory. You may notice that > there is no "mass" byte swapping. The technics used here is a bit > developer here: > http://stegefin.free.fr/wine/ > You might prefer a more conventional way of doing the byte swapping, > in this case tell me. We might still need this approach since it could > efficient for sharing data accross the LE exe and the BE winelib. It doesn't seem very efficient to trap on every memory access... Besides, I don't see how this can possibly work, there is no guarantee that the compiler is going to generate accesses that always match the size of the requested type, memcpy() being the obvious example. I think you are going in the wrong direction with this; the right way IMO is to compile Wine for x86 and run the whole Wine+app under the CPU emulator. Otherwise you'll have to write wrappers for each of the 15,000 APIs. -- Alexandre Julliard julliard(a)winehq.org

7 21

problem in using Winelib
by gupta.lokesh＠philips.com 03 Sep '04

03 Sep '04

Hi, I have been trying to use Winelib to build a very trivial Windows Application on Unix just to test the working of winelib. But it does not work according to the documentation at all. Here are the problems I found: - When I run winemaker in my project root directory, it runs successfully but in the end does not produce any configure script as said in the documentation but produces directly a Makefile - The Makefile must be manually tweaked to put in the WINE include files path and the WINE libraries path. - After changing the generated Makefile, when I run it, I see thousands of warnings related to ignoring of __stdcall__ attribute in some of the windows header files, but the build goes through - The generated executable always has a .so extension which gives a feeling that it is a shared library rather than an executable - When I run the above generated file, it simply dumps core without any messages "Segmentation Fault" - When I try to run the above application through GDB to debug it, it crashes even before reaching main - When I try to run the above application through winedbg to debug it, it simply hangs, nothing happens after that. If such a basic thing does not work with Winelib, then I hope that something is wrong with the way I have understood things and in my process of trying to do this. Can somebody help ?? By the way, the same kind of setup also did not work on Linux/Intel and Linux/Athlon combinations as well. So there must be something very wrong in the way I am doing it. I imagine that the Winelib user's guide documentation is totally out of date, in which case could somebody please forward me a document which can produce working executables. Best Regards Lokesh

2 1

Re: listview
by Rein Klazes 03 Sep '04

03 Sep '04

On Thu, 2 Sep 2004 17:28:31 -0400, you wrote: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Handle WM_BUTTONDOWN operations before dragging test > Don't eat WM_LBUTTONUP message > > Index: dlls/comctl32/listview.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/listview.c,v > retrieving revision 1.393 > diff -u -r1.393 listview.c > --- dlls/comctl32/listview.c 25 Aug 2004 17:33:01 -0000 1.393 > +++ dlls/comctl32/listview.c 2 Sep 2004 21:21:32 -0000 > @@ -7927,6 +7927,7 @@ > else if (msg.message >= WM_LBUTTONDOWN && > msg.message <= WM_RBUTTONDBLCLK) > { > + DispatchMessageW(&msg); > break; > } This was discussed before. The problem here is that Windows/native comctl32 *does* eat the WM_LBUTTONUP message ending the mouse track. The reason why you miss the WM_LBUTTONUP message is that mouse tracking is started wrongly under Wine. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

RE: Protected message
by Mike 03 Sep '04

03 Sep '04

1 0

OLE Problem?
by Adriano Bonat 03 Sep '04

03 Sep '04

Hello, im trying to run a program, but appear this error message: Invoking /usr/lib/wine/wine.bin SVLGER.EXE ... fixme:ole:CoRegisterMessageFilter stub fixme:ole:GetRecordInfoFromGuids (0x40b8e0,2,12,0,0x40b8f0,0x4465e8),stub! fixme:ole:CoRegisterMessageFilter stub Wine exited with a successful status Im using Debian, and configured Wine with Winetools, the software that im trying to run is a ERP build with VB in Windows NT. Any appointment of the patch for this problem? Thanks in advance, -Adriano Bonat

1 0

cleanup w->a cross calls in crypt
by James Hawkins 03 Sep '04

03 Sep '04

Hi, I have checked this patch over and over, but I would appreciate it if you guys could make sure it is ready to be committed. I tried to break up the changes into as many patches as I could, but these last few functions depend on CRYPT_GetProvKeyName and CRYPT_GetTypeKeyName which had to be unicodified as well. The tests for these functions will be sent in the next patch. -- James Hawkins

2 5

Possible fun project/todo list item?
by Juan Lang 02 Sep '04

02 Sep '04

Another approach would be to rework wininet to use SSPI (implemented in secur32.dll), and to write an SSP for SSL and TLS. You could write one that uses NSS if you like, or another that uses OpenSSL or GnuTLS. Not sure how "fun" that would be though <g>. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

more debugger issues
by Chipzz 02 Sep '04

02 Sep '04

Hi all! As a saw a few updates to the debugger a couple of days ago, I decided to give the debugger another go. The problem with the stack trace is gone now, but now I get another problem when I attach to a running process, set a breakpoint and continue, the program crashes. When I in- stead don't set a breakpoint and continue, the program keeps running "fine": When setting the breakpoint: chipzz@Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>info process pid threads parent executable (all id:s are in hex) 00000008 4 00000000 'H:\.wine-clean\win\dotnet.inst\install.exe' Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>bt Backtrace: =>1 0x40107b4b __read+0x4b in libc.so.6 (0x40307c54) 2 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x40307cf8) 3 0x401ca9dc vm86_return_end+0xc55 in ntdll (0x40307d1c) 4 0x40067678 (0x423bcc4c) 5 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x423bccf0) 6 0x401cc4e6 NtWaitForMultipleObjects+0x66 in ntdll (0x423bcd18) 7 0x404e25a5 WaitForMultipleObjectsEx+0xb5 in kernel32 (0x423bce48) 8 0x40cd54cc X11DRV_MsgWaitForMultipleObjectsEx+0x5c in x11drv (0x423bcf80) 9 0x408d9294 MsgWaitForMultipleObjectsEx+0x134 in user32 (0x423bd128) 10 0x408d9351 MsgWaitForMultipleObjects+0x41 in user32 (0x423bd148) 11 0x4163b91a (0x40915980) 12 0x7d8920ec (0x83e58955) fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) 13 0x8000:0x0000 (0x11b7:0x0800) 14 0x8000:0x0800 (0x11b7:0x0000) Wine-dbg>break MessageBoxA err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file ole32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file oleaut32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file rpcrt4.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 53445352 in module msvcr80 fixme:dbghelp:symt_get_info Unsupported sym-tag SymTagPublicSymbol for get-type Many symbols with name 'MessageBoxA', choose the one you want (<cr> to abort): [1]: 0x408db030 MessageBoxA in user32 [2]: 0x40ad7760 MessageBoxA in shell32 [3]: 0x40107b00 __libc_read in libc.so.6 => 1 Breakpoint 1 at 0x408db030 MessageBoxA in user32 Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:11af GS:0000 EIP:4281009e ESP:423be038 EBP:423be0a4 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:77710800 EDX:00000000 ESI:00000000 EDI:000000a0 Stack dump: 0x423be038: 79655066 796fc52b 00000000 000000a0 0x423be048: 00000000 00000000 40340000 00000002 0x423be058: 00000034 404bec3f 00000007 423be084 0x423be068: 70a948ad 00000409 00000001 403b62f8 0x423be078: ffffffff 79670df4 ffffffff 423be0b8 0x423be088: 70a95755 00000001 354ae8a4 423be044 0235: sel=11af base=40306000 limit=00001fff 32-bit rw- Backtrace: =>1 0x4281009e (0x423be0a4) 2 0x796fc558 (0x423be0dc) 3 0x796fc705 (0x423be12c) 4 0x796fd494 (0x423be1d0) 5 0x00750073 (0x00690056) 6 0x00000000 (0x00000000) 0x4281009e: movl 0x40(%eax),%eax Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). ... etc. When not setting the breakpoint: chipzz@Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>c Also, ctrl-c doesn't work to stop the program being debugged. Wien version is wine CVS Aug 23. Any help is appreciated! kr, Chipzz AKA Jan Van Buggenhout PS: Please cc me as I'm not on the list. -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

2 3

WineHQ - Hosted by PayPal
by Tero Tamminen 02 Sep '04

02 Sep '04

Hi! Sorry if this is wrong list or something, but I saw this bug (if this is feature, not a bug, ignore this mail) in front page of WineHQ. Also with quick search with Google I didn't find this reported before. On the right side, there is "Hosted by" and empty link to codeweavers (<a href="http://www.codeweavers.com/"></a>). After that there is PayPal link. Because <a href="http://www.codeweavers.com/"></a> is empty, it seems that this site is hosted by PayPal (which should come after codeweavers, I think). This could be said more clearly I think, but if you go to the front page, you'll notice it. Anyway, have a nice day and so on... -- Tero Tamminen

5 5

Re: wine/ windows/painting.c dlls/user/painting.c
by Rein Klazes 02 Sep '04

02 Sep '04

On Wed, 25 Aug 2004 19:46:11 -0500, you wrote: > Log message: > GetUpdateRgn should clip the returned region to the client area. > Changed GetUpdateRect and ExcludeUpdateRgn to call GetUpdateRgn. > Moved these 3 functions to dlls/user/painting.c. This has the effect that a program that like agent does this: case WM_PAINT: if( GetUpdateRect(hWnd, ...) { hdc = BeginPaint(hWnd,...); } causes a lot of: err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 0x1002c! Is it not possible to restrict the update region to the client area in the first place? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 4

make crosstest link error
by Francois Gouget 02 Sep '04

02 Sep '04

Running make crosstest in dlls/mlang/tests I get: i586-mingw32msvc-gcc mlang.cross.o testlist.cross.o -o mlang_crosstest.exe -lole32 -lgdi32 -lkernel32 -lntdll -luuid mlang.cross.o(.text+0x469e): In function `func_mlang': /home/fgouget/wine/dlls/mlang/tests/mlang.c:618: undefined reference to `IID_IMultiLanguage2' mlang.cross.o(.text+0x46b5):/home/fgouget/wine/dlls/mlang/tests/mlang.c:618: undefined reference to `CLSID_CMultiLanguage' make: *** [mlang_crosstest.exe] Error 1 I have checked out the mingw-w32api-2.5-8hl.i586.rpm package from http://mirzam.it.vu.nl/mingw/ but unfortunately I still get the error. >From what I can see, these GUIDs should be defined in libole32.a. So I guess the mingw-w32api package is in for an update... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

2 2

Hidden message
by Mike 02 Sep '04

02 Sep '04

1 0

Re: stub AtlModuleUpdateRegistryFromResourceD [resend]
by Alexandre Julliard 01 Sep '04

01 Sep '04

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > +/*********************************************************************** > + * AtlUpdateRegistryFromResourceD [ATL71.@] (.NET) > + * > + */ > +HRESULT WINAPI AtlUpdateRegistryFromResourceD(HINSTANCE hInst, LPCOLESTR lpszRes, > + BOOL bRegister, /* struct _ATL_REGMAP_ENTRY* */ void* pMapEntries, /* IRegistrar* */ void* pReg) This is confusing, because AtlUpdateRegistryFromResourceD is not exported from atl.dll. You should either avoid that function completely, or create a new atl71.dll that exports it (but that doesn't seem really necessary at this point). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Binary relocatability part 1
by Alexandre Julliard 01 Sep '04

01 Sep '04

Mike Hearn <mike(a)navi.cx> writes: > +dnl This is used for binary relocatability > +if echo $libdir | grep '^\${exec_prefix}' >/dev/null; then > + RPATH="-Wl,-rpath,'\$\${ORIGIN}/..'`echo $libdir | sed 's/\${exec_prefix}//'`" > +fi This is still making assumptions about the contents of bindir and libdir. What you need is a generic way to find a relative path from any directory to any other. Also this needs to be done at make time, not in configure. -- Alexandre Julliard julliard(a)winehq.org

2 3

Wine and industrial communication like OPC
by Rickard Svensson 01 Sep '04

01 Sep '04

Hello! I have some questions about Wine and how/if it can be used with industrial communication like OPC (MicroSoft Com/DCom objects, DDE and more) My short question is: Can I use Wine to make OPC communication work on a Linux system. OPC "OLE for Process Control" A "general" standard for communication in industrial systems, that unfortunately is totally depending on Windows(DCOM) I work on a small company in Sweden who make industrial computers for the industry, and when we a few years ago had to choose operating system for our new model I got them to choose Linux. And almost everything is perfect, we have had a working product for almost a year now, and everything is good. But now our company needs to support OPC, this is a big problem that makes a lot of people in the company start saying things like WinCE or Win XP embedded. On www.opcfoundation.org ther are same companys how have made Unix OPC clients, but the license costs are hi. Ther is also OPC true XML that is now a real product, that looks promising. I'am in need to make/use same kind of OPC api(Wine DCom) for Linux, a api like that woode make many companys in the industrial computer intressted. Or as a backup I could have a Win program running in Wine on the Linux machine talking with the main app on the same computer and talking OPC to other machines that need that. I hope Wine and/or you can help me in this case. It would be a tragedy if we had to switch operating system just because of this. /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

3 3

Re: Add a test showing that GDI should not scale bitmap font metrics
by Huw D M Davies 01 Sep '04

01 Sep '04

On Wed, Sep 01, 2004 at 05:44:19PM +0900, Dmitry Timoshkov wrote: > Hello, > > I had a wild guess whether GDI actually scales or not metrics for > a bitmap font if a requested font size is not available and wrote > a test case for it. No, GDI *does not* scale bitmap font metrics. Well it does do integer scaling. So if you request System (whose normal size is 16) with 32 <= lfHeight < 48 you'll get a double sized font with all the metrics scaled by a factor of two. Wine doesn't do this yet. Your test shows that gdi doesn't do fractional scaling which is indeed correct. Huw. -- Huw Davies huw(a)codeweavers.com

2 3

Re: mixing SHELL32.DLL and SHFOLDER.DLL
by Juan Lang 01 Sep '04

01 Sep '04

Salius wrote: > I am sure shfolder.dll from win98se installation > calls GetProcAddress() to get the address of > SHGetFolderPathW @ shell32.dll. Moreover, my > shell32.dll doesn't export SHGetSpecialFolderPath* > by a name, also. Hm. I'm sorry, I wasn't clear enough. From MSDN on SHGetFolderPath: This function is a superset of SHGetSpecialFolderPath, included with earlier versions of the Shell. On systems preceeding those including Shell32.dll version 5.0 (Windows Millennium Edition (Windows Me) and Windows 2000), SHGetFolderPath was obtained through SHFolder.dll, distributed with Microsoft Internet Explorer 4.0 and later versions. SHFolder.dll always calls the current platform's version of this function. If that fails, it will try to simulate the appropriate behavior. So, I think your patch is a good first step, to use GetProcAddress rather than letting the linker do it. A next step would be, I think, to do what I suggested: if this fails, try to GetProcAddress for SHGetSpecialFolderPath, since this was available on older versions of shell32. You might have to search by ordinal if searching by name fails. So, I don't think my suggestion is that different from Juergen's, just that I suggest an implementation of "try to simulate the appropriate behavior" if the function is not in fact in shell32. --Juan _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

3 3

E-mail adress
by Davide Giannotti 31 Aug '04

31 Aug '04

I'm trying to fight spam like anybody else, and first thing is to remove mail adresses from every page on the internet. A google search on my adress shows only 2 pages where i compare, they both come frome wine archive: http://www.winehq.com/hypermail/wine-devel/2003.04.txt http://www.spinics.net/lists/wine/msg08863.html Is there a way to make them remove from there? Just a suggestion: i'm conscious that mail adress need to be post into such a mailing list, but wouldn't be good to keep a script running that alter them into something like 'myname {at} mydomain' ? Just a little sacrifice for everybody to help fighting spam. Think about.. pls... -- Davide Giannotti ITS Planet s.n.c davide.giannotti {at} itsplanet.com www.itsplanet.com

3 2

Re: Set last error values compatible with Win9x implementation of GetFileVersionInfoSize
by Uwe Bonnes 31 Aug '04

31 Aug '04

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> Hello, installer of Quicken depends on last error values set by Dmitry> GetFileVersionInfoSize and expects them to be set to something Dmitry> different than ERROR_RESOURCE_DATA_NOT_FOUND set on NT Dmitry> platforms. Dmitry> I hope that there is no need to introduce several code paths Dmitry> depending on the GetVersion return value. A test programm for our test suite will easily show (and document) that behaviour. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: KERNEL32: implement CallNamedPipe
by Dmitry Timoshkov 31 Aug '04

31 Aug '04

"Mike McCormack" <mike(a)codeweavers.com> wrote: > + r = WaitNamedPipeW( lpNamedPipeName, nTimeout ); > + if( !r ) > + return r; win2k kernel32 does not do WaitNamedPipeW. > + handle = CreateFileW( lpNamedPipeName, GENERIC_READ|GENERIC_WRITE, > + 0, NULL, OPEN_EXISTING, 0, NULL ); > + if( !handle ) > + return FALSE; CreateFileW returns INVALID_HANDLE_VALUE on failure, not 0. > + r = WriteFile( handle, lpOutput, dwOutputSize, &count, NULL ); > + if( r ) > + r = ReadFile( handle, lpInput, dwInputSize, lpBytesRead, NULL ); win2k kernel32 calls SetNamedPipeHandleState and TransactNamedPipe (not implemented in Wine) here. > + CloseHandle( handle ); > + > + return r; > } -- Dmitry.

1 0

Re: Add some padding in WINPROC_wrapper
by Mike McCormack 31 Aug '04

31 Aug '04

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 31 Aug '04

31 Aug '04

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 31 Aug '04

31 Aug '04

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 31 Aug '04

31 Aug '04

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 30 Aug '04

30 Aug '04

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

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