May 2002 - Wine-Devel - list.winehq.org

Re: Keyboard layout detection not working??

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9. According to keysymdef.h Hebrew keysyms are in the range 0xcdf - 0xcfa What says xev when you type hebrew characters? > They don't > pass the condition, and the function tries to convert them using > KEYBOARD_MapDeadKeysym, which obviously fails. My first idea was to > change this to: > if ((keysym < 0x1000) && (keysym != ' ')) > > But I then realized that this was probably just a missing 0, and was > meant to be: > if ((keysym < 0x8000) && (keysym != ' ')) And keysymdef.h confirms your suspicion. I think your fix is correct. > The second problem I encountered was that keymaps that had three letters > per key, but the third letter was wrong, received the same score (i.e. - > were not counted as mismatches) as keymaps that only had two letters. In > fact, if the X representation had only two letters, the three letter > keymaps were not penalized for trying to match a non-existing key. I > believe this is not the right behaviour, but as it does not block me at > the moment, I did not try to fix it. Probably keyboard detection code need some additional work. But since it works for (almost?) all, then it's fine to leave it as it is. -- Dmitry.

May 31, 2002

Re: Keyboard layout detection not working??

by Shachar Shemesh

Shachar Shemesh wrote: > Hi all, > > I am using Debian SID with KDE. In KDE, I defined two keyboard layouts > (US and IL). I tried to add Israeli keyboard detection using the > attached patch (layout.diff). When trying to test that patch, however, I > perform the following task: > > I type in the command as suggested in the docs (wine --debugmsg > +key,+keyboard >& key.log). Attached are two run attempts. key.log is > with the US keyboard selected, key2.log is with the Hebrew keyboard > selected. > Hi all, Further research revealed the problem, and here is a working patch. I would like to both draw your attention to the reasons, and point out one thing in this patch that requires attention. One of the reasons the previous patch did not work was that the X keymapping for Hebrew did all of the extra layout on the shifted characters. As a result, the first two characters of each key were the usual US keyboard, and therefor the US keyboard was matched. I did notice two things which were rather strange, and I believe were bugs. One of them, I fixed. The other I did not. The one fixed in this patch is on line 991 of dlls/x11drc/keyboard.c (inside the X11DRV_KEYBOARD_DetectLayout function), is says: /* Allow both one-byte and two-byte national keysyms */ if ((keysym < 0x800) && (keysym != ' ')) ckey[i] = keysym & 0xFF; else { ckey[i] = KEYBOARD_MapDeadKeysym(keysym); } The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9. They don't pass the condition, and the function tries to convert them using KEYBOARD_MapDeadKeysym, which obviously fails. My first idea was to change this to: if ((keysym < 0x1000) && (keysym != ' ')) But I then realized that this was probably just a missing 0, and was meant to be: if ((keysym < 0x8000) && (keysym != ' ')) That's the point where I give up (X is not my strongest side). Will anyone who knows how X uses the keyboard mappings have a look and find out which is the correct one? If 0x800 (the current) is the correct one, some code needs to be put in for languages (such as Hebrew) where the characters are above 0x800. The second problem I encountered was that keymaps that had three letters per key, but the third letter was wrong, received the same score (i.e. - were not counted as mismatches) as keymaps that only had two letters. In fact, if the X representation had only two letters, the three letter keymaps were not penalized for trying to match a non-existing key. I believe this is not the right behaviour, but as it does not block me at the moment, I did not try to fix it. Shachar Index: dlls/x11drv/keyboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v retrieving revision 1.1 diff -u -r1.1 keyboard.c --- dlls/x11drv/keyboard.c 30 Apr 2002 21:16:39 -0000 1.1 +++ dlls/x11drv/keyboard.c 31 May 2002 10:14:32 -0000 @@ -531,6 +531,15 @@ "zZ","xX","cC","vV","bB","nN","mM","öÖ","çÇ",".:" }; +/*** Israeli keyboard layout */ +static const char main_key_IL[MAIN_LEN][4] = +{ + "`~;","1!1","2(a)2","3#3","4$4","5%5","6^6","7&7","8*8","9(9","0)0","-_-","=+=", + "qQ/","wW'","eE÷","rRø","tTà","yYè","uUå","iIï","oOí","pPô","[{[","]}]", + "aAù","sSã","dDâ","fFë","gGò","hHé","jJç","kKì","lLê",";:ó","\'\",","\\|\\", + "zZæ","xXñ","cCá","vVä","bBð","nNî","mMö",",<ú",".>õ","/?." +}; + /*** VNC keyboard layout */ static const WORD main_key_scan_vnc[MAIN_LEN] = { @@ -600,6 +609,7 @@ {"Latin American keyboard layout", 28591, &main_key_LA, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Lithuanian (Baltic) keyboard layout", 28603, &main_key_LT_B, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Turkish keyboard layout", 28599, &main_key_TK, &main_key_scan_qwerty, &main_key_vkey_qwerty}, + {"Israeli keyboard layout", 28598, &main_key_IL, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"VNC keyboard layout", 28591, &main_key_vnc, &main_key_scan_vnc, &main_key_vkey_vnc}, {NULL, 0, NULL, NULL, NULL} /* sentinel */ @@ -989,7 +999,7 @@ for (i = 0; i < syms; i++) { keysym = TSXKeycodeToKeysym (display, keyc, i); /* Allow both one-byte and two-byte national keysyms */ - if ((keysym < 0x800) && (keysym != ' ')) + if ((keysym < 0x8000) && (keysym != ' ')) ckey[i] = keysym & 0xFF; else { ckey[i] = KEYBOARD_MapDeadKeysym(keysym);

May 31, 2002

fwait bug

by admiral coeyman

Developers, From what I've been reading on the subject, the best way of handling int 3d is to return successful. Any fpu emmulation that we'll do should not require the fwait. The problem is that I cannot find enough information on the subject to know what the successful return conditions for this interrupt are. On a system that detects an FPU, self-modifying code is used. The interrupts that emmulate the FPU functions are rewritten in the executable to use the machine code for the real FPU instructions. I'm not sure if that can be done with the current memory scheme since that is outside of my area. God Bless, --Robert 'Admiral' Coeyman -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

May 31, 2002

Re: [Bug 377] Changed - mIRC crashes while backspacing to erase entry

by Tony Lambregts

Sam'l Bassett wrote: >With: > > codeweavers-wine-20011108-5 > >and > > mIRC 5.91 > > Yep -- still has the problem > >On Thursday 30 May 2002 12:35 pm, wine-bugs(a)winehq.com wrote: > > >>http://bugs.winehq.com/show_bug.cgi?id=377 >> >> >> Why do you not post in bugzilla the link was given . The reports come from the people looking at your bug report in bugzilla, where you reported it in the first place. Thats where you should respond. Tony Lambregts.

May 31, 2002

Re: PATCH: win32/device.c -- addresses two warnings

by Marcus Meissner

On Thu, May 30, 2002 at 09:26:56AM +0200, Gerald Pfeifer wrote: > This addresses two compiler warnings seen on FreeBSD 4.5-RELEASE. > The first should appear on any non GNU/Linux-system, the second on > all systems. > > Gerald > > ChangeLog: > Move floppy_params into #ifdef linux. > Fix printf format in OpenVxDHandle(). > > Index: device.c > =================================================================== > RCS file: /home/wine/wine/win32/device.c,v > retrieving revision 1.63 > diff -u -3 -p -r1.63 device.c > --- device.c 25 May 2002 22:04:43 -0000 1.63 > +++ device.c 30 May 2002 07:24:18 -0000 > @@ -1187,12 +1187,6 @@ static const DWORD VWIN32_DriveTypeInfo[ > 0x4f24 /* 2.88 M */ > }; > > -static BYTE floppy_params[2][13] = > -{ > - { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 }, > - { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 } > -}; > - > /********************************************************************** > * VWIN32_ReadFloppyParams > * > @@ -1201,6 +1195,12 @@ static BYTE floppy_params[2][13] = > static VOID VWIN32_ReadFloppyParams(DIOC_REGISTERS *regs) > { > #ifdef linux > + static BYTE floppy_params[2][13] = > + { > + { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 }, > + { 0xaf, 0x02, 0x25, 0x02, 0x12, 0x1b, 0xff, 0x6c, 0xf6, 0x0f, 0x08 } > + }; > + I think this is not recommended C (and might fail on other compilers). Not that linux would have any other but gcc. Ciao, Marcus

May 30, 2002

Re:Please how do I post the following and get help? "VT_STREAMED_OBJECT out of MSMQ"

by Hans

I was looking at some of your postings recently and I thought that maybe you have come across the situation where you have tried to send a VT_STREAMED_OBJECT into (OleSaveToStream) a queue body and tried to retrieve it at a later time (OleLoadFromStream). I am struggling to work with this (I hope that the code is self explanatory): pMsgProps->aPropID[iter] = PROPID_M_BODY_TYPE; pMsgProps->aPropVar[iter].vt = VT_UI4; pMsgProps->aPropVar[iter].ulVal = VT_STREAMED_OBJECT; iter++; pMsgProps->aPropID[iter] = PROPID_M_BODY; pMsgProps->aPropVar[iter].vt = VT_VECTOR|VT_UI1; STATSTG stat; hResult = ptrStream0->Stat(&stat,STATFLAG_NONAME); pMsgProps->aPropVar[iter].caub.cElems = stat.cbSize.LowPart; pMsgProps->aPropVar[iter].caub.pElems = (unsigned char *)static_cast<void *>(ptrStream0); The above part seems to go through fine. But I cannot extract the information from the receiving end: IStream* ptrStream0 = reinterpret_cast<IStream*>(pMsgProps->aPropVar[3].caub.pElems); // the subscript 3 is where the message body is being extracted, also memory has been allocated as UCHAR in the ..pElems hResult = ptrStream0->Stat(&stat,STATFLAG_NONAME); // the above line of code gives you garbage values for both STATMSG.cbSize.(HighPart and LowPart) Do you think that you could help? Thanks. Hans

May 30, 2002

Re: Patch to fix bug_report.pl

by Eric Pouech

> <shameless plug for own problem> > http://bugs.winehq.com/show_bug.cgi?id=745 > </shameless plug for own problem> this should be fixed by now. remove the wineconsole entries from your registry files, and restart the wineconsole. A+

May 30, 2002

Re: User (developer ?) friendly execution trace

by Eric Pouech

> Much better would be an internal implementation.... > Some comments about ? this has already been discussed. there should be a patch floating around (but never committed to Wine because ugly, code bloat, intrusive...) to turn all debug channels on or off using a simple key stroke I've quickly hacked a solution based on winedbg by extending some existing commands: set + warn win => turn on warn on 'win' channel set + win => turn on warn/fixme/err/trace on 'win' channel (same with - to turn off) (form of command should still be improved..., but core of functionality is there) HTH A+ Name: dbg_chn ChangeLog: added ability to turn on/off debug channels License: X11 GenDate: 2002/05/30 18:01:13 UTC ModifiedFiles: debugger/dbg.y debugger/debugger.h debugger/info.c AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/dbg.y,v retrieving revision 1.55 diff -u -u -r1.55 dbg.y --- debugger/dbg.y 25 May 2002 21:18:34 -0000 1.55 +++ debugger/dbg.y 30 May 2002 17:57:11 -0000 @@ -173,7 +173,12 @@ | noprocess_state ; -set_command: tSET lval_addr '=' expr_value tEOL { DEBUG_WriteMemory(&$2,$4); DEBUG_FreeExprMem(); } +set_command: + tSET lval_addr '=' expr_value tEOL { DEBUG_WriteMemory(&$2,$4); DEBUG_FreeExprMem(); } + | tSET '+' tIDENTIFIER tEOL {DEBUG_DbgChannel(TRUE, NULL, $3);} + | tSET '-' tIDENTIFIER tEOL {DEBUG_DbgChannel(FALSE, NULL, $3);} + | tSET '+' tIDENTIFIER tIDENTIFIER tEOL {DEBUG_DbgChannel(TRUE, $3, $4);} + | tSET '-' tIDENTIFIER tIDENTIFIER tEOL {DEBUG_DbgChannel(FALSE, $3, $4);} ; pathname: Index: debugger/debugger.h =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/debugger.h,v retrieving revision 1.32 diff -u -u -r1.32 debugger.h --- debugger/debugger.h 25 May 2002 21:18:34 -0000 1.32 +++ debugger/debugger.h 30 May 2002 17:53:16 -0000 @@ -404,6 +404,7 @@ extern void DEBUG_InfoVirtual(void); extern void DEBUG_InfoWindow(HWND hWnd); extern void DEBUG_WalkWindows(HWND hWnd, int indent); +extern void DEBUG_DbgChannel(BOOL add, const char* chnl, const char* name); /* debugger/memory.c */ extern int DEBUG_ReadMemory( const DBG_VALUE* value ); Index: debugger/info.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/info.c,v retrieving revision 1.24 diff -u -u -r1.24 info.c --- debugger/info.c 25 May 2002 21:18:34 -0000 1.24 +++ debugger/info.c 30 May 2002 18:01:08 -0000 @@ -536,6 +536,63 @@ DEBUG_Printf(DBG_CHN_MESG, "No longer walking module references list\n"); } +struct dll_option_layout +{ + void* next; + void* prev; + char* const* channels; + int nb_channels; +}; + +void DEBUG_DbgChannel(BOOL add, const char* chnl, const char* name) +{ + DBG_VALUE dv; + DBG_ADDR ad; + struct dll_option_layout dol; + int i; + char* str; + unsigned char buffer[32]; + unsigned char mask; + int done = 0; + + if (!chnl) mask = 15; + else if (!strcmp(chnl, "fixme")) mask = 1; + else if (!strcmp(chnl, "err")) mask = 2; + else if (!strcmp(chnl, "warn")) mask = 4; + else if (!strcmp(chnl, "trace")) mask = 8; + else { DEBUG_Printf(DBG_CHN_MESG, "Unknown channel %s\n", chnl); return; } + + if (!DEBUG_GetSymbolValue("first_dll", -1, &dv, FALSE)) + { + DEBUG_Printf(DBG_CHN_MESG, "Can't get first_option symbol"); + return; + } + while (DEBUG_ToLinear(&dv.addr) && DEBUG_READ_MEM((void*)DEBUG_ToLinear(&dv.addr), &dol, sizeof(dol))) + { + for (i = 0; i < dol.nb_channels; i++) + { + ad.seg = 0; + ad.off = (unsigned long)(dol.channels + i); + if (DEBUG_READ_MEM((void*)DEBUG_ToLinear(&ad), &str, sizeof(str))) + { + ad.off = (unsigned long)str; + if (DEBUG_READ_MEM((void*)DEBUG_ToLinear(&ad), buffer, sizeof(buffer))) + { + if (!strcmp(buffer + 1, name)) + { + if (add) buffer[0] |= mask; else buffer[0] &= ~mask; + if (DEBUG_WRITE_MEM((void*)DEBUG_ToLinear(&ad), buffer, 1)) + done++; + } + } + } + } + dv.addr.off = (unsigned long)dol.next; + } + if (!done) DEBUG_Printf(DBG_CHN_MESG, "Unable to find debug channel %s\n", name); + else DEBUG_Printf(DBG_CHN_MESG, "Changed %d channel instances\n", done); +} + void DEBUG_InfoSegments(DWORD start, int length) { char flags[3];

May 30, 2002

Re: Patch to fix bug_report.pl

by Tony Lambregts

Andreas Mohr wrote: >On Thu, May 30, 2002 at 09:47:07AM -0600, Tony Lambregts wrote: > > >>The bug_report.pl script was broken by the removal of -managed command >>line option This patch fixes it. >> >> >That's all fine and dandy, but I think the real fix is to >a) nuke bug_report.pl >or >b) improve it *a lot* > >bug_report.pl is so darn old that the Wine version it had originally been >written for is *completely* different from what we're using today. > >Thus bug_report.pl should at least strip all "irrelevant" bug lines >(*CriticalSection, Interlocked*crement, Tls*, ...). >Furthermore it should really include many more debug lines (we're also tracing >wine internal dlls now sometimes !). >I'd suggest about 1500 lines of censored output, if not even more. >Otherwise you can just kiss the debug log goodbye in about 98.5% of all cases. > > > These are all good points. The reason for the patch in the first place is the following bug. http://bugs.winehq.com/show_bug.cgi?id=742 So the question is do we change the bug report to really address the problems with bug_report.pl or apply the patch and start a new bug report. I think that the ideal would be to apply the patch and change the bug report. You are right in that it really needs improving and it only is usefull in the event of a crash and that happens less often these days. I am more interested in getting the debuger to be more usefull. <grin> <shameless plug for own problem> http://bugs.winehq.com/show_bug.cgi?id=745 </shameless plug for own problem> Tony Lambregts

May 30, 2002

Re: Patch to fix bug_report.pl

by Andreas Mohr

On Thu, May 30, 2002 at 09:47:07AM -0600, Tony Lambregts wrote: > The bug_report.pl script was broken by the removal of -managed command > line option This patch fixes it. That's all fine and dandy, but I think the real fix is to a) nuke bug_report.pl or b) improve it *a lot* bug_report.pl is so darn old that the Wine version it had originally been written for is *completely* different from what we're using today. Thus bug_report.pl should at least strip all "irrelevant" bug lines (*CriticalSection, Interlocked*crement, Tls*, ...). Furthermore it should really include many more debug lines (we're also tracing wine internal dlls now sometimes !). I'd suggest about 1500 lines of censored output, if not even more. Otherwise you can just kiss the debug log goodbye in about 98.5% of all cases. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

May 30, 2002