- Wine-devel - list.winehq.org

Implementing SHAppBarMessage
by Drew Ogle 27 Feb '02

27 Feb '02

Hi, we were talking on #winehq about implementing SHAppBarMessage while not horridly important , implementing it properly could take a good bit of work. The problem is thus; when an application registers a hWnd and gets the system to allocate it a certain space, when other windows mazimize, they don't maximize over the appbar ( point in case -- ICQ ) this would then take some work in wineserver. For corectness' sake we would want to make these changes, but they could also introduce bugs. Sidenote: someone told me that Eric is working on SHAppBarMessage, is this correct? --Dante

2 1

Regression testing
by Rick Romero 27 Feb '02

27 Feb '02

Hi all, I've been trying to track down the source of my Visual Foxpro "Left click in a window, and 'freeze'" error, and with the help of Lawson Whitney, I *think* I've managed to narrow it down to the patch that causes it. If I checkout wine from cvs, then do a cvs update -D "2001-06-19" I get a 'working' wine. If I update to 06-20, wine doesn't work. There are a few patches that were committed on the 19th, but one appears to mostly likely have been the culprit: Log message: Moved hardware message queue handling to the server. Patch: http://cvs.winehq.com/patch.py?id=992978202334525382146239 First, I suppose I should apply each patch for that day, just to be sure, but I'm guessing/hoping someone else knows if that large 'move' caused some problems or not (so I can avoid spending that time). Second, is there anything I can do to help narrow this down further? I see there are a couple WM_LBUTTONDOWN things that I could trace, but I'm not sure that's the best place to start.. In short, what should I do now? :) Thanks, Rick

1 0

Traditional Chinese (CP950) not displaying in WINE
by Anthony Fok 27 Feb '02

27 Feb '02

Hello all, We are experimenting some problems with displaying and inputting Chinese characters in WINE (January 2002 or newer). For example, most Chinese characters show up as squares, and it seems that WINE doesn't accept Chinese input via XCIN (an input method server using the XIM protocol). Did we misconfigured something? Or is this a known problem in WINE? Any pointers would be appreciated. Thanks! Cheers, Anthony -- Anthony Fok Tung-Ling ThizLinux Laboratory <anthony(a)thizlinux.com> http://www.thizlinux.com/ Debian Chinese Project <foka(a)debian.org> http://www.debian.org/intl/zh/ Come visit Our Lady of Victory Camp! http://www.olvc.ab.ca/

3 5

new Bug in OLE
by mehmet yasar 27 Feb '02

27 Feb '02

Microsoft Visual Studio 6 is crashing when opening an existing projet, with current CVS version of Wine (Wine20020122 was OK). Comparing both, I have found the change that triggers the crash. It is function StgOpenStorage in OLE32/storage32.c, line 5595 : hr = StorageImpl_Construct( newStorage, hFile, pwcsName, NULL, grfMode, TRUE, - FALSE); + !(Fad.nFileSizeHigh || Fad.nFileSizeLow) /* FALSE */ ); TRACE shows that Fad.nFileSizeHigh = Fad.nFileSizeLow = 0; As you can see in TRACE the crash occurs in StorageImpl_WriteBigBloc. I suppose Wine is trying to write to a readonly opened file ? (because file is opened with GENERIC_READ) I hope this will help finding a fix. Mehmet YASAR -------------------- BackTRACE Unhandled exception: page fault on write access to 0x419d0000 in 32-bit code (0x402a6db4). In 32-bit mode. 0x402a6db4 (NTDLL.DLL.memcpy+0x34 in libc.so.6): movl %eax,0x0(%edi) Backtrace: =>0 0x402a6db4 (NTDLL.DLL.memcpy+0x34 in libc.so.6) (ebp=405d5e34) 1 0x40899438 (StorageImpl_SaveFileHeader+0x188(This=0x403f3440) [storage32.c:3084] in libole32.so) (ebp=405d6058) 2 0x408986d0 (StorageImpl_Construct+0x170(This=0x403f3440, hFile=0xd4, pwcsName=0x405d6414, pLkbyt=0x0, openFlags=0x10, fileBased=0x1, fileCreate=0x1) [storage32.c:2265] in libole32.so) (ebp=405d6180) 3 0x4089bc7e (StgOpenStorage+0x21e(pwcsName=0x405d6414, pstgPriority=0x0, grfMode=0x10, snbExclude=0x0, reserved=0x0, ppstgOpen=0x405d6488) [storage32.c:5595] in libole32.so) (ebp=405d63f4) 4 0x5009c4b2 (DEVSHL.DLL.4593+0x111 in D:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=405d6464) -------------------- debugmsg +ole,+storage,+file trace:file:CreateFileA D:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\mfcclwz.dll GENERIC_READ F ILE_SHARE_READ OPEN_EXISTING trace:file:ReadFile 212 0x405d61ec 511 0x405d5ed4 (nil) trace:file:ReadFile 212 0x405d61ec 511 0x405d5ed4 (nil) trace:storage:StgOpenStorage (L"Y:\\wine\\testDC\\testdc.opt", (nil), 10, (nil), 0, 0x405d6488) trace:file:CreateFileA Y:\wine\testDC\testdc.opt GENERIC_READ OPEN_EXISTING trace:storage:BIGBLOCKFILE_FileInit file len 49664 trace:storage:BIGBLOCKFILE_MapPage mapped page 0 to 0x419d0000 trace:storage:StorageImpl_WriteBigBlock memcpy (0x419d0000 0x405d5e4c 512 ) wine: Unhandled exception, starting debugger... --------------------

1 0

Re: ImageList fixes
by daveh-wine＠cadlink.com 27 Feb '02

27 Feb '02

From: mstefani(a)redhat.de >> The hotspot handling in imagelist is broken. This fix partially >repairs it. >... and breaks it too. With your patch the hotspot handling in It was a crude attempt to differentiate between the subtle difference in meaning of the hotspot passed in to BeginDrag and that passed in to SetDragCursorImage. The BeginDrag hotspot sets the position of the image wrt the current mouse position and also sets the hotspot there. Subsequently calling SetDragCursorImage does not physically move the image, but changes the mouse messages to reflect the offset. We probably need to do more substantial logic and track both hotspots independantly to achieve better Windows emulation. The bHSPending can be removed as it was only there to prevent the image moving as a result of a call to SetDragCursorImage after BeginDrag with different hotspots. If this breaks my application too much I'll do a more thorough fix and test more widely. Dave Hawkes

1 0

Re: ImageList fixes
by Michael Stefaniuc 26 Feb '02

26 Feb '02

Hello, sorry to replay so late but I didn't had the time to test your patch before. On Fri, Feb 22, 2002 at 08:39:39PM -0500, Dave Hawkes wrote: > The hotspot handling in imagelist is broken. This fix partially repairs it. ... and breaks it too. With your patch the hotspot handling in FreeSolitaire is broken. The attached patch reverts a small portion of your patch and fixes the recursion. For what do you need bHSPending? With the recursion removed it's pretty useless. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Native DDE problems
by List vmn 26 Feb '02

26 Feb '02

Erich!!!! Very Cool! Thanks for your prompt answer. Please send me the patch. I will surely test it! Just one question on your answer, my two apps are called DISP.EXE and PDV.EXE Is one of them 16 and the other 32 bit ? If I recompile both of them to 32 bit or 16 bit, should DDE work? I can also try that. Frankly, I didn´t even know that one was 16 and the other 32 bit. Miguel Feitosa At 21:11 26/2/2002 +0100, you wrote: > > The http://www.winehq.com/News/status.html states that the implementation > > of the serial/parallel port > > is 90% complete but that DDE is still being implemented by Eric Pouech and > > not functional. >the status page is now a bit outdated >DDE (and DDEML) now kinda work >however, some 16 bit support is still missing in DDE (and DDEML), hence >your >problems as the trace shows >as of today : >- two 32 bit apps should be able to communicate through DDE >- two 16 bit apps should be able to communicate through DDE >- however, a 16 bit and a 32 bit app will not be able to communicate > >I have a yet unfinished patch here that should (partly) take care of >that >if you have the wine source and are ready to do some testing, I can >provide >you the patch to see if it helps in your situation > >as DDEML is a pure 16 bit DLL (the 32 bit DDEML implementation is part >of >USER32), it's very unlikely that native DDEML will work in wine >so, sticking to builtin USER/USER32/DDEML is the only viable solution >(even >if it's not completly done yet) > >A+

2 1

Artilcle - loading Windows DLL's under Linux
by Nick Temple 26 Feb '02

26 Feb '02

Hello All -- I am working on an article about how to load Windows DLL's under Linux. This system is for stand-alone Linux applications that only need to use some of the logic in a single Windows DLL, not a full WINE implementation. The code has been "borrowed" and tweaked from the avifile distribution (which is GPL'd), originally borrowed from WINE (BSD license), and will be re-released under the GPL or LGPL once the article is published. I have found the following names in the headers of the various files I'm using: Eric Youndale & Erik Bos Martin von Löwis Marcus Meissner Thomas Sandford Robert J. Amstadt Alexandre Julliard I plan to give credit either at the end of the article or in a sidebar. I would also like to put in a "blurb" about the WINE and avifile projects in the article (or sidebar) as well. Is there a standard blurb I can use? Also, I want to make sure that the appropriate people / organizations get credit. I am willing to accept comments on the completed version before publication to make sure I'm not stepping on any toes, please contact me directly if you are interested. Thanks in advance for the feedback, Nick

7 6

wineserver request size
by Eric Pouech 26 Feb '02

26 Feb '02

how to handle large wineserver request structure ? I've been working on adding the dwFillAttribute handling to CreateProcess (and passing between parent and child) while I was at it, I also added all the other fields (window geometry, console title/size...) at the end the two requests used in the process (new_process and init_process) are larger than the fixed request_max_size structure (80 bytes would be needed) so, what's the preferred way of handling this: 1) bump the request_max_size to the needed size (but all requests will be penalized about it) 2) remove the request_max_size (therefore aligning the size of the request on the one of the biggest available) 3) try to compress the structure fields (most of the data are 32 bits, whereas they would fit in 16 bit fields) 4) store the data above the 64 bytes into the variable part of the message (but that would break the current structure scheme) A+

3 2

Native DDE problems
by List vmn 26 Feb '02

26 Feb '02

Hi! I started using wine (wine-20020122 compiled from source tarball) a couple of weeks ago to run a store-point-of-sale application. The idea is to port this windows application to linux. Before porting, we decided to check if the app could be emulated on linux with wine or recompiled with winelib. This is also necessary to run proprietary windows DLLs from third parties such as credit card companies that bind the application to specific hardware. The software uses a lot of external hardware such as printers, barcode scanners, special keyboards etc. These hws usually communicate through the serial port. Another important feature of the software is the use of DDE - Dynamic Data Exchange from the windows API. The application is broken into at least two executables that communicate through DDE. The http://www.winehq.com/News/status.html states that the implementation of the serial/parallel port is 90% complete but that DDE is still being implemented by Eric Pouech and not functional. After reviewing the manuals and spending a few days on trial runs, I decided to try and bring in the native DDEML.DLL and see if the exe´s would communicate. QUESTION: Should this native windows library work under wine, has anybody tried this? When I tried running the software with the native DDE engine (from Win98), I get DDE errors and a warning saying that DDE is not functional yet. This is expected as reported by the status.html page. When I tried running the software with a setup that only the DDEML.DLL was native, the program crashed with an exception. I tried running the program with several debug channels but couldn´t detect the problem. The only thing learned was that the program seemed to be crashing inside USER.DLL builtin code. I then tried several different native/builtin setups using mainly the following DLLs: Native DLLs DDEML.DLL OLE32.DLL COMCTL*.DLL COMDLG*.DLL SHELL.DLL SHELL32.DLL I even tried bringing in USER and USER32. Some of these setups were documented not to work and didn´t. Everytime I got a setup that seemed to work, the software would crash with basically an exception or page fault. I then decided to use winedbg. I was able to get a stack trace of the software at the time of the exception. It is at the end of this email. I also put a complete run of winedbg --debugmsg +msg 'c:\sw\store.exe' in http://admin.vmn.com.br/wine/out.txt From the trace it seemed that USER builtin in code was not yet finished and handling correctly DDE messages or had a messaging bug related to DDE or not. I read the functions in c code from the trace and couldn´t see any obvious problems. They seemed complete and finished. QUESTION: Is the builtin USER.DLL complete? QUESTION: Should it interact correctly with DDEML.DLL? If DDEML.DLL and USER.DLL were communicating through COM then they should interact correctly but since DDE is a protocol dating back to win3.1, probably older than OLE and COM, maybe they don´t. I have thought of reworking the original software to use SOCKETS but this is quite a lot of work. I am new to wine so I may be missing something obvious. Thanks in advance for any help. Miguel Feitosa TRACE First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). In 32-bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>130 params = GlobalLock(hMem); Wine-dbg>1142 if (!UnpackDDElParam( info->msg, info->lparam, &uiLo, &uiHi )) Wine-dbg>1587 return post_dde_message( dest_tid, &data, info ); Wine-dbg>1995 return put_message_in_queue( dest_tid, &info, NULL ); Wine-dbg>89 return PostMessageW( hwnd, msg32, wparam32, lparam ); Wine-dbg>1052 return proc( Wine-dbg>

2 1