June 2001 - Wine-Devel - list.winehq.org

Re: Readconsole, was libreadline for winedbg

by eric pouech

> investigating further, I found that winedbg uses ReadConsole to get what the > debug-user typed in, however ReadConsole by far doesn't behave as > expected, namely to give back the VT100 codes for what the user typed in. At > present arrow key presses are never delivered to winedbg well I tested it on NT2000, and arrows are not given back to the app using ReadConsole. So, it's winedbg which is at fault and should use ReadConsoleInput instead, but it would mean that the line editing should be heavily revisited to switch from a VT100 to a input_record style of input... a nicer fix would be to implement the ENABLE_LINE_INPUT mode for the console (so that the line edition would be done in the Wine code). we would lost the emacs-like keys usage (unless we had a Wine specific ENABLE_EMACS_LINE_INPUT mode to the console) > and if winedbg runs > on the staring console, input is only delivered to winedbg after the user > entered "Enter". yes. this is because, when the console is allocated on a current term, stdin is not set to raw mode. here again, it means another rewrite (the underlying stdin must be set to raw (at least resetting ICANON), and all the line editing logic must be taken care of by wine (including echoing the input characters) so, not to restart the discussion, but the libreadline inclusion (if any) would be more appropriate in the wine core code rather than in winedbg :-( A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

June 23, 2001

Re: wine/ dlls/x11drv/winpos.c windows/x11drv/event.c

by Guy L. Albertelli

With the patch "Don't rely on X to expose windows covered by a sibling, do it manually. (6/21)" installed, it seems that most (possibly all) of the painting problems have been fixed. Great job!! There are two other outstanding problems remaining: 1. With ControlSpy (REBAR.EXE), WinRAR, and IE4 and native controls (commctrl, comctl32): The 01/03/15 cvs, when the mouse moves over the gripper, the cursor changes to linked left & right arrows. When the left button is pressed, the cursor is changed to a small double gripper with left & right arrows. The selected band can then be dragged. At the 01/06/01 cvs, the cursor is not changed either before the left button push or after. However the selected band can still be dragged. With the current cvs (01/06/22), the cursor is changed to the linked left & right arrows, but the area where the change occurs is much smaller. The cursor goes back to the normal arrow after the left button is pressed. The selected band can then be dragged, but is less responsive that the other two cases by about 50%. 2. This is with -managed mode and both examples involve the X-window being minimized (current cvs 6/22): With IE4 and native controls (commctrl, comctl32), when typing in the address box and "enter" is hit, the Xwindow is minimized and the data is processed. With our code, the enter is ignored. With WinRAR and native controls (commctrl, comctl32), selecting the settings dialog and replying OK results in the main window being mimimized. Selecting cancel (or other dialog boxes) do not cause mimimization. Guy

June 23, 2001

ChooseFont dialog problems.

by kenon＠go2.pl

Hello, I'm trying to make choosefont dialog working. (I'm not sending this patch to wine-patches because it is incomplete ,and I rather need some ideas ) First hunk of the patch allows changing font colors in 16-bit apps , and it seems to work properly. Second and third hunk affects both 16 and 32 bit apps ,and my intention is to fix CF_INITTOLOGFONTSTRUCT style handling. It almost works ,but code in dlls/commdlg/fontdlg.c is very cryptic (was it based on original Micro$oft code ? :-) ) . Should it be wrtitten from beginning :-( ? Trying to patch this file resemble hard patchwork :-) or else I spent too little time on trying to understand the file. Maciek --- /home/mkalisz/wine/dlls/commdlg/fontdlg.c Tue Jun 19 05:34:07 2001 +++ dlls/commdlg/fontdlg.c Sat Jun 23 01:27:57 2001 @@ -220,6 +220,7 @@ } lpChFont->lpTemplateName=lpTemplateName; + lpChFont->rgbColors=cf32a.rgbColors; font16 = MapSL(lpChFont->lpLogFont); font16->lfHeight = cf32a.lpLogFont->lfHeight; @@ -782,7 +783,7 @@ j=SendDlgItemMessageA(hDlg, cmb3, CB_GETCOUNT, 0, 0); for (i=0;i<j;i++) { - if (lpxx->lfHeight==(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) + if (lpxx->lfHeight==-(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) SendDlgItemMessageA(hDlg,cmb3,CB_SETCURSEL,i,0); } } @@ -1000,6 +1001,7 @@ return TRUE; } } + break; case chx1: case chx2: case cmb2:

June 23, 2001

Re: Initializing Dosvm for direct port access

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > What about checking if Dosvm.GetTimer is initialized and if it isn't > initialized do give back the dummy value? At least the spde doesn't seem to > care... How does the app behave under NT? Or with -winver nt40? -- Alexandre Julliard julliard(a)winehq.com

June 23, 2001

Re: PATCH: MSDOS VGA mode

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I think we managed to get monkey island to start by fixing that keyboard > code. However, because of that annoying wineserver assertion failure, no > DOS apps like this run with my code anymore, so I can't check. Unless you > want to fix the wineserver assertion at server/console.c line 194, so > CONSOLE_make_complex can run in one thread while another winedos thread > keeps waiting for input? Did you try to simply remove the assert? I think the way the select is done now, it should actually work fine, and the assert should no longer be necessary. -- Alexandre Julliard julliard(a)winehq.com

June 23, 2001

word wrapping in ListViews

by Bill Medland

Does anyone know where the word-wrapping occurs in CListView objects? In the MFC code or lower down? One of the issues we face with our app is that on Windows when icons are displayed in a CListView and the label is significantly wider than the icon then I note that the label is written on two lines whereas under Wine it is displayed truncated on a single line. I am trying to figure out where the fault is. Does anyone know? Bill

June 22, 2001

Re: PATCH: MSDOS VGA mode

by Ove Kaaven

On Fri, 22 Jun 2001, Marcus Meissner wrote: > Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn > doing inb(0x60) and the +io debugging giving back the correct scancode > (0x1c on press and 0x9c on release). After reading the scancode, however, it determintes that it was not a cursor key, so it passes it on to the DOS int9 handler for default processing there. Then it expects the keypress to appear in the BIOS keyboard buffer. (You might have seen that if you also ran --debugmsg +int) I think we managed to get monkey island to start by fixing that keyboard code. However, because of that annoying wineserver assertion failure, no DOS apps like this run with my code anymore, so I can't check. Unless you want to fix the wineserver assertion at server/console.c line 194, so CONSOLE_make_complex can run in one thread while another winedos thread keeps waiting for input? Hmm, but it looks like I may already have rewritten the interrupt separation for int9 enough, maybe I could submit that patch independently of the new DOS event loop (if you don't need the high performance the new event handling sustains)?

June 22, 2001

Re: PATCH: MSDOS VGA mode

by Marcus Meissner

On Sun, Jun 17, 2001 at 11:14:15PM +0200, Ove Kaaven wrote: > > On Sun, 17 Jun 2001, Marcus Meissner wrote: > > > However, Monkey Island does not appear to get <return> presses. I see > > in 60 returning scancode 0x1c (and 0x9c on release), but it never triggers > > any reaction :( > > Yes, the relevant code in msdos/int09.c is stiff #if 0-ed out in the Wine > CVS. I think I have some stuff fixing it lying around in my old Wine tree, > but it was rejected in its first form, so it might need a rewrite. > But the vm86 restructure is probably more important... Hmm. Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn doing inb(0x60) and the +io debugging giving back the correct scancode (0x1c on press and 0x9c on release). It however does not react on it :/ Ciao, Marcus

June 22, 2001

Re: server:truncated to 32768

by Adriaan Moors

David Hagood wrote: > With a fresh build of last night's CVS pull, when I attempt to run > Delorme's AAA MapNGo V4.0, I get the following error condition: > > server:truncated to 32768 > server:truncated to 32768 > > At this point the main window of the application is up. However, if I > try to do anything non-trivial with the app, it coughs up this error: > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 1 (X_CreateWindow) > Serial number of failed request: 1663 > Current serial number in output stream: 1668 maybe this is related to my problem? i get a similar error with programs that create a tray icon (but even notepad gives probs when i open help..about) (see post "problem in create_icon_window ...") regards adriaan -- But let me tell you, the slim lazy Homer you knew is dead. Now I'm a big fat dynamo. -- Homer Simpson (in "King-Size Homer")

June 21, 2001

Re: Initializing Dosvm for direct port access

by Uwe Bonnes

>>>>> "Ove" == Ove Kaaven <ovehk(a)ping.uio.no> writes: Ove> On Thu, 21 Jun 2001, Uwe Bonnes wrote: >> Hallo Ove, >> >> is something like appended patch right to get direct port access >> working for a win95 program? At least my dongle protected program >> (spde) doesn't crash any more and recognizes the license. Ove> I meant to reply sooner or later... it doesn't seem right to me to Ove> load the entire DOS subsystem for reading out the timer. Direct Ove> port access is probably not allowed for win32 apps under NT anyway? Ove> Perhaps there should be a fallback there for when the DOS subsystem Ove> is not loaded? Then again, I'm not sure how it's supposed to Ove> work... it probably can't hook the timer interrupt or set the timer Ove> rate or anything without upsetting the OS? What about checking if Dosvm.GetTimer is initialized and if it isn't initialized do give back the dummy value? At least the spde doesn't seem to care... @@ -291,7 +303,7 @@ else { dummy_ctr -= 1 + (int)(10.0 * rand() / (RAND_MAX + 1.0)); - if (chan == 0) /* System timer counter divisor */ + if ((chan == 0) && (Dosvm.GetTimer))/* System timer counter divisor */ { /* FIXME: Dosvm.GetTimer() returns quite rigid values */ tempval = dummy_ctr + (WORD)Dosvm.GetTimer(); @@ -450,8 +470,9 @@ case 0: /* latch timer */ tmr_8253[chan].latched = TRUE; dummy_ctr -= 1 + (int)(10.0 * rand() / (RAND_MAX + 1.0)); - if (chan == 0) /* System timer divisor */ - tmr_8253[chan].latch = dummy_ctr + (WORD)Dosvm.GetTimer(); + if ((chan == 0) && (Dosvm.GetTimer))/* System timer divisor */ + tmr_8253[chan].latch = dummy_ctr + + (Dosvm.GetTimer)?(WORD)Dosvm.GetTimer():0; else { /* FIXME: intelligent hardware timer emulation needed */ -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 21, 2001