- Wine-Devel - list.winehq.org

Re: dutch keyboard support
by Dmitry Timoshkov Nov. 18, 2003

Nov. 18, 2003

"grant williamson" <traxtopel(a)fastmail.fm> wrote: > This patch offers better wine support for Dutch Keyboards. > Most IBM computers sold in the Netherlands have Dutch keyboards. Well, then it would be nice to see the patch generated against current CVS, since the code has changed a bit. > Can this be included please. Also, provide a reference to an actual X keyboard layout (setxkbmap xxx) and avoid phrasing like "contributed by xxx". Please. -- Dmitry.

2 2

Netmeeting under wine
by David Martinez Prado Nov. 18, 2003

Nov. 18, 2003

Hi all! i am, trying to run netmeeting under Wine. i installed wine with the default windows partition. Then, i execute netmeeting installer and crashed. i am working on RH7.2. Can anyone help me? thank you very much. _________________________________________________________________ Descárgate en tu teléfono los tonos y logos de las canciones y artistas de más éxito en MSN Móviles. http://www.msn.es/MSNMovil/

6 9

listview advice needed.
by Rein Klazes Nov. 18, 2003

Nov. 18, 2003

Hi, Agent 2.0 beta crashes on listview related code, and requires native comctl32 to run. Here is a cut from a +relay,+message,+listview trace: | trace:message:SPY_ExitMessage (0x1004b) L"{SysListView32}" message [1004] LVM_GETITEMCOUNT returned 00000000 | 0009:Ret user32.SendMessageA() retval=00000000 ret=005cad80 At this point the listview is newly created, headers column inserted etc. No items yet. | 0009:Call user32.SendMessageA(0001004b,00001007,00000000,406cf6f8) ret=005cc1b4 | trace:message:SPY_EnterMessage (0x1004b) L"{SysListView32}" message [1007] LVM_INSERTITEMA sent from self wp=00000000 lp=406cf6f8 | trace:message:SPY_DumpMem LVITEM [0000] 00000003 00000000 00000000 00000000 | trace:message:SPY_DumpMem LVITEM [0010] 00000000 42103914 00000018 ffffffff | trace:message:SPY_DumpMem LVITEM [0020] 61737365 005cc11f 406cf770 006b30b6 | trace:message:SPY_DumpMem LVITEM [0030] ffffffff The program inserts the first item. Valid fields are Text and Image. | trace:listview:LISTVIEW_WindowProc (uMsg=1007 wParam=0 lParam=406cf6f8) | trace:listview:LISTVIEW_InsertItemT (lpLVItem={iItem=0, iSubItem=0, pszText="application/octet-stream", cchTextMax=24, iImage=-1}, isW=0) | trace:listview:LISTVIEW_InsertItemT inserting at 0, sorted=1, count=0, iItem=0 | trace:listview:LISTVIEW_ShiftIndices Shifting 0u, 1 steps | trace:listview:set_main_item () | trace:listview:set_main_item oldState=0, newState=0 | trace:listview:set_main_item uChanged=0x3 | trace:listview:notify_listview (code=-102, plvnm=iItem=0, iSubItem=0, uNewState=0x0, uOldState=0x0, uChanged=0x0, ptAction=(0, 0), lParam=0 ) | trace:listview:notify_hdr (code=-102) | trace:message:SPY_EnterMessage (0x10049) L"{wxWindowClass}" message [004e] WM_NOTIFY sent from self wp=00001e68 lp=406cf148 | trace:message:SPY_DumpStructure NMHDR hwndFrom=0x1004b idFrom=0x00001e68 code=LVN_INSERTITEM<0xffffff9a>, extra=0x20 | trace:message:SPY_DumpMem NM extra [0000] 00000000 00000000 00000000 00000000 | trace:message:SPY_DumpMem NM extra [0010] 00000000 00000000 00000000 00000000 Still inside the LVM_ISERTITEMA message a WM_NOTIFY is sent. The programs message handler queries number of items: | 0009:Call user32.SendMessageA(0001004b,00001004,00000000,00000000) ret=005cad80 | trace:message:SPY_EnterMessage (0x1004b) L"{SysListView32}" message [1004] LVM_GETITEMCOUNT sent from self wp=00000000 lp=00000000 | trace:listview:LISTVIEW_WindowProc (uMsg=1004 wParam=0 lParam=0) | trace:message:SPY_ExitMessage (0x1004b) L"{SysListView32}" message [1004] LVM_GETITEMCOUNT returned 00000001 | 0009:Ret user32.SendMessageA() retval=00000001 ret=005cad80 there is one item. | 0009:Call user32.SendMessageA(0001004b,00001005,00000000,406cebe0) ret=005ca4cb | trace:message:SPY_EnterMessage (0x1004b) L"{SysListView32}" message [1005] LVM_GETITEMA sent from self wp=00000000 lp=406cebe0 | trace:message:SPY_DumpMem LVITEM [0000] 00000004 00000000 42100a50 406cf148 | trace:message:SPY_DumpMem LVITEM [0010] 406cf154 406ced10 407c1c09 005cad80 | trace:message:SPY_DumpMem LVITEM [0020] 0001004b 00001004 406ced10 005ccb9a | trace:message:SPY_DumpMem LVITEM [0030] 0001004b and request that lParam of that item. Note that iItem is zero but iSubItem is 0x42100a50, like all other fields it is filled with rubbish. (confirmed with dissassembly that only the mask and iItem fields are filled in) | trace:listview:LISTVIEW_WindowProc (uMsg=1005 wParam=0 lParam=406cebe0) | trace:listview:LISTVIEW_GetItemT (lpLVItem={iItem=0, iSubItem=1108347472, lParam=1004b}, isW=0) | trace:message:SPY_ExitMessage (0x1004b) L"{SysListView32}" message [1005] LVM_GETITEMA returned 00000001 | trace:message:SPY_DumpMem LVITEM [0000] 00000004 00000000 42100a50 406cf148 | trace:message:SPY_DumpMem LVITEM [0010] 406cf154 406ced10 407c1c09 005cad80 | trace:message:SPY_DumpMem LVITEM [0020] 0001004b 00001004 406ced10 005ccb9a | trace:message:SPY_DumpMem LVITEM [0030] 0001004b At return, the requested value of lParam is still rubbish, which is causing a crash somewhat later. | trace:message:SPY_ExitMessage (0x10049) L"{wxWindowClass}" message [004e] WM_NOTIFY returned 00000000 | trace:message:SPY_DumpStructure NMHDR hwndFrom=0x1004b idFrom=0x00001e68 code=LVN_INSERTITEM<0xffffff9a>, extra=0x20 | trace:message:SPY_DumpMem NM extra [0000] 00000000 00000000 00000000 00000000 | trace:message:SPY_DumpMem NM extra [0010] 00000000 00000000 00000000 00000000 | 0009:Ret user32.SendMessageW() retval=00000000 ret=40b49738 If I hack LISTVIEW_GetItemT() with a hack like: | | if (lpSubItem) | { | SUBITEM_INFO *lpSubItem = LISTVIEW_GetSubItemPtr(hdpaSubItems, lpLVItem->iSubItem); | pItemHdr = lpSubItem ? &lpSubItem->hdr : &callbackHdr; |+ if(!lpSubItem) lpLVItem->iSubItem = 0; | } the program proceeds (crashes much much later) . But this is probably not the correct way to check that an invalid subitem has been passed (for instance I don't understand the callbackHdr stuff above). Any suggestion what is the correct fix? Full log at www.xs4all.nl/~rklazes/temp/agent.log.bz2 Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 5

Freeze in Agent 2.0 beta.
by Rein Klazes Nov. 18, 2003

Nov. 18, 2003

Hi, When downloading headers form multiple groups Agent often locks up. The program does the following: -(Main). main thread creates a sub thread: | 0009:Call kernel32.CreateThread(00000000,00002000,006648e0,41ac6cb0,00000004,41ac6cb0) ret=006649c9 | 0009: *fd* 23 <- 41 | 0009: new_thread( suspend=1, inherit=0, request_fd=23 ) | 0009: new_thread() = 0 { tid=0021, handle=0xcc } | 0021: *fd* 27 <- 42 | 0021: *fd* 29 <- 45 | 0021: init_thread( unix_pid=4966, unix_tid=-1, teb=0x40319000, entry=0x404fa110, reply_fd=27, wait_fd=29 ) | 0021: init_thread() = 0 { pid=0008, tid=0021, boot=0, version=126 } | 0021: select( flags=8, cookie=0x4031ac78, timeout=1068729666.690492 (-0.000050), handles={} ) | 0021: select() = PENDING | 0009:Ret kernel32.CreateThread() retval=000000cc ret=006649c9 -(SUB). Sub thread updates some files and finishes with sending a WM_NULL message to the main thrad: | 0021:Call user32.PostMessageA(00010026,00000000,00000000,00000000) ret=0058d0d6 | 0021:Call kernel32.GetTickCount() ret=407924ca | 0021:Ret kernel32.GetTickCount() retval=000ab0db ret=407924ca | 0021: send_message( id=0009, type=6, flags=0, win=0x10026, msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=000ab0db, info=00000000, timeout=-1, callback=(nil), data={} ) | 0021: send_message() = 0 | 0021:Ret user32.PostMessageA() retval=00000001 ret=0058d0d6 -(SUB). Close the thread handle: | 0021:Call kernel32.CloseHandle(000000cc) ret=006648d0 | 0021: close_handle( handle=0xcc ) | 0021: close_handle() = 0 { fd=-1 } | 0021:Ret kernel32.CloseHandle() retval=00000001 ret=006648d0 -(SUB). terminates: | 0021:Call kernel32.ExitThread(00000000) ret=006648df | 0021: terminate_thread( handle=0xfffffffe, exit_code=0 ) | 0021: terminate_thread() = 0 { self=1, last=0 } [snip] | 0021:Ret PE DLL (proc=0x4079ad40,module=0x406f0000 L"user32.dll",reason=THREAD_DETACH,res=(nil)) retval=1 | 0021:Call PE DLL (proc=0x40cef0a0,module=0x40cb0000 L"x11drv.dll",reason=THREAD_DETACH,res=(nil)) | 0021:Ret PE DLL (proc=0x40cef0a0,module=0x40cb0000 L"x11drv.dll",reason=THREAD_DETACH,res=(nil)) retval=1 | 0021:Call PE DLL (proc=0x404c8980,module=0x40480000 L"kernel32.dll",reason=THREAD_DETACH,res=(nil)) | 0021:Ret PE DLL (proc=0x404c8980,module=0x40480000 L"kernel32.dll",reason=THREAD_DETACH,res=(nil)) retval=1 | 0021: *killed* exit_code=0 -(Main). In the meantime the main thread: - gets data from the server (winsok send and rcv) - writes to the file - processes queued messages until it is empty - then is wait on the handle of the subthread: | 0009:Call kernel32.WaitForSingleObject(000000cc,ffffffff) ret=004ed693 -(Main). which ends immedeately: | 0009: select( flags=4, cookie=0x406cf4e0, timeout=0, handles={0xcc} ) | 0009: select() = INVALID_HANDLE | 0009:Ret kernel32.WaitForSingleObject() retval=ffffffff ret=004ed693 -(Main). close the subthread handle. | 0009:Call kernel32.CloseHandle(000000cc) ret=004ed69c | 0009: close_handle( handle=0xcc ) | 0009: close_handle() = INVALID_HANDLE { fd=0 } | 0009:Ret kernel32.CloseHandle() retval=00000000 ret=004ed69c This may repeat a number of times but then without warning: -(SUB). terminates as usual: | 0023:Ret PE DLL (proc=0x4079ad40,module=0x406f0000 L"user32.dll",reason=THREAD_DETACH,res=(nil)) retval=1 | 0023:Call PE DLL (proc=0x40cef0a0,module=0x40cb0000 L"x11drv.dll",reason=THREAD_DETACH,res=(nil)) | 0023:Ret PE DLL (proc=0x40cef0a0,module=0x40cb0000 L"x11drv.dll",reason=THREAD_DETACH,res=(nil)) retval=1 | 0023:Call PE DLL (proc=0x404c8980,module=0x40480000 L"kernel32.dll",reason=THREAD_DETACH,res=(nil)) | 0023:Ret PE DLL (proc=0x404c8980,module=0x40480000 L"kernel32.dll",reason=THREAD_DETACH,res=(nil)) retval=1 | 0023: *killed* exit_code=0 -(Main). Finishes its message processing and the waits: | 0009:Call kernel32.WaitForSingleObject(000000cc,ffffffff) ret=004ed693 | 0009: select( flags=4, cookie=0x406cf4e0, timeout=0, handles={0xcc} ) | 0009: select() = PENDING And this wait never returns until explicitly killed: | 0009: *killed* exit_code=0 I looked at many of these sequences. In all of them the subthread finished well before the main thread executed its Wait. I was looking for timing differences between the processing of the two threads, checking whether and when the WM_NULL message gets processed. Nothing seems to stand out. Any suggestions how to debug this? A large cut from the +relay,+server trace is on http://www.xs4all.nl/~rklazes/temp/agserver.log.bz2 Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 4

Re: WineHQ: Update the Janitorial page
by Tom Nov. 18, 2003

Nov. 18, 2003

Dimitrie O Paun wrote > - <li> loader > - <li> loader/ne > - <li> memory > + <li class=committed> loader/ne > + <li class=committed> memory umm i'm lost here... - loader, but no committed on loader.. Tom

2 1

Can I turn off freetype at runtime
by Bill Medland Nov. 17, 2003

Nov. 17, 2003

Is it possible to turn off the freetype use at runtime, e.g. by changing something in the config file? Basically under SuSE several dialogs are drawing with 5 pixel text whereas under Windows they are about 9 pixel high (which I don't understand because I think that they should not exceed 8). Under RedHat they are 7 pixel which are at least readable. I hope that if I can turn off the freetype then on SuSE it will get the same font as on RedHat I tried setting an Alias but it didn't make any difference; it still used the same font instead of the alias -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

3 2

Re: listbox: ownerdraw fix
by Dimitrie O. Paun Nov. 17, 2003

Nov. 17, 2003

On November 17, 2003 07:33 am, Huw D M Davies wrote: > - LISTBOX_RepaintItem( hwnd, descr, i, ODA_SELECT ); > + if (!IS_OWNERDRAW(descr)) > + LISTBOX_RepaintItem( hwnd, descr, i, ODA_SELECT ); > + else > + LISTBOX_InvalidateItemRect(hwnd, descr, i); > + Why not simply invalidate rect always, even when not in owner draw? -- Dimi.

2 4

[Fwd: LinuxQuestions.org Members Choice nomination]
by Mike Hearn Nov. 17, 2003

Nov. 17, 2003

Hey, an award never hurts. -------- Original Message -------- Subject: LinuxQuestions.org Members Choice nomination Date: Sun, 16 Nov 2003 18:03:58 -0500 (EST) From: Jeremy <jeremy(a)linuxquestions.org> To: mike(a)theoretic.com CC: michael.hearn(a)durham.ac.uk Mike, Just wanted to let you know that wine was nominated for Windows on Linux App of the Year in the 2003 LinuxQuestions.org Members Choice Awards. http://www.linuxquestions.org/questions/showthread.php?s=&threadid=116387 --jeremy

1 0

wine-pthread hangs
by Jeremy Shaw Nov. 16, 2003

Nov. 16, 2003

Hello, I was trying to run wine-pthread, but it hangs immediately after startup -- I can't even hit cntl-c to exit. If I try to run it under gdb, it seg faults. A backtrace looks like: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 14857)] 0x40040fd9 in __errno_location () from /lib/libpthread.so.0 (gdb) bt #0 0x40040fd9 in __errno_location () from /lib/libpthread.so.0 #1 0x40515ae6 in DOSFS_ToDosFCBFormat () from /usr/lib/wine/kernel32.dll.so #2 0x40516223 in DOSFS_FindUnixName () from /usr/lib/wine/kernel32.dll.so #3 0x40516f21 in DOSFS_GetFullName () from /usr/lib/wine/kernel32.dll.so #4 0x4051e8c9 in CreateFileW () from /usr/lib/wine/kernel32.dll.so #5 0x4021c879 in RtlDoesFileExists_U () from /usr/lib/wine/ntdll.dll.so #6 0x4021cedf in RtlDosSearchPath_U () from /usr/lib/wine/ntdll.dll.so #7 0x40218862 in LdrGetProcedureAddress () from /usr/lib/wine/ntdll.dll.so #8 0x40218c1c in LdrGetProcedureAddress () from /usr/lib/wine/ntdll.dll.so #9 0x40216c80 in _aullrem () from /usr/lib/wine/ntdll.dll.so #10 0x402170d3 in _aullrem () from /usr/lib/wine/ntdll.dll.so #11 0x4021984b in LdrInitializeThunk () from /usr/lib/wine/ntdll.dll.so #12 0x405511e4 in SetThreadExecutionState () from /usr/lib/wine/kernel32.dll.so (gdb) I am using the latest wine from CVS (as of 5pm, 11/14/2003). Linux 2.4.22 libc6 2.3.2 Do I need to do something special to get this working? I am trying to use wine-pthread because I want to use the winejack driver. The winejack driver does not work correctly with wine-kthread, because in libjack, there is a call to pthread_create which never returns. According to usenet, this could happen because wine-kthread is not linked against libpthread explicitly. I tried adding an explicit -lpthread to wine-kthread, but this just cause wine-kthread to hang (similar to wine-pthread, but in a different location). I also tried running ./configure --enable-nptl and installing a version of libc with nptl support, but I think nptl requires features added in 2.5.x -- so this was probably just wishful thinking. Thanks! Jeremy Shaw.

4 9

Re: Localization to portguese - winecfg (with patch)
by Mike Hearn Nov. 16, 2003

Nov. 16, 2003

Well, I don't have any real problem with it, but as I said before it's pretty pointless IMHO. The GUI is going to start changing again when I next get time to work on it (unfortunately not anytime soon in the foreseeable future), so you'll have to update it all over again. What winecfg needs now is code rather than strings.... On Sat, 15 Nov 2003 15:43:18 -0300, Sir Marcelo Duarte scribed thus: > I updated the resources of winecfg. If Mike Hearn don't disagree with this. > > Changelog: > Marcelo Duarte <wine-devel(a)bol.com.br> > - Localization to portguese - winecfg.

2 1