January 2003 - Wine-Devel - list.winehq.org

Whither fnt2bdf?

by Dan Kegel

What happened to fnt2bdf? It was removed as of http://cvs.winehq.com/cvsweb/wine/tools/Makefile.in.diff?r1=1.20&r2=1.21 but the comment for 1.21 doesn't seem to mention this removal http://cvs.winehq.com/cvsweb/wine/tools/Makefile.in Might this be a mistake? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: more HEAP_strdupAtoW removals.

by Matthew Davison

On Thu, 2003-01-23 at 01:36, Dmitry Timoshkov wrote: > "Matthew Davison" <m.davison(a)virgin.net> wrote: > > > Changelog > > Remove some more calls to HEAP_strdupWtoA > > First of all, thanks for doing this! > > > @@ -554,7 +555,11 @@ > > lpwstr = NULL; > > for(i=0; i<dwNumServiceArgs; i++) > > - lpwstr[i]=HEAP_strdupAtoW(GetProcessHeap(), 0, lpServiceArgVectors[i]); > > + { > > + RtlCreateUnicodeStringFromAsciiz (&usBuffer,lpServiceArgVectors[i]); > > + lpwstr[i]=usBuffer.Buffer; > > + RtlFreeUnicodeString(&usBuffer); > > + } > > Of course this is a typo and last RtlFreeUnicodeString should be removed. yeah, damn, i thought id got that one. > > > @@ -760,24 +774,26 @@ > > BOOL WINAPI OpenPrinterA(LPSTR lpPrinterName,HANDLE *phPrinter, > > LPPRINTER_DEFAULTSA pDefault) > > { > > - LPWSTR lpPrinterNameW = HEAP_strdupAtoW(GetProcessHeap(),0,lpPrinterName); > > + UNICODE_STRING lpPrinterNameW; > > + UNICODE_STRING usBuffer; > > + RtlCreateUnicodeStringFromAsciiz(&lpPrinterNameW,lpPrinterName); > > PRINTER_DEFAULTSW DefaultW, *pDefaultW = NULL; > > BOOL ret; > Are you sure that mixed data declarations/function call will be accepted > by any C compiler out there? I doubt that even gcc will accept this. well, im pretty sure gcc takes this, but ill change it anyway. thanks. -- Matthew Davison <m.davison(a)virgin.net>

Jan. 23, 2003

Re: Wine kernel acceleration module?

by Dan Kegel

Gavriel State wrote: > Another key factor in favour of the ShmServer is that we've got > a working prototype available right now that runs several real-world > apps. 8-) That's a real advantage: it works, right now! All those who prefer another approach, put your code where your mouth is :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: Installshield 6 crash: ole trouble

by Dan Kegel

Marcus Meissner wrote: >>>>"Error Number: 0x80040706 >>>>Description: Object reference not set >>>>Setup will now terminate." >>> >>>I have seen this on and off, but I thought I fixed it. >> >>Interestingly, under wine20020605, I am able to complete >>the installation program. Thus we seem to have a regression. >>Which would be more helpful: me tracking down which patch >>caused the regression, or me sending some more knowledgeable >>person a minimal test case? > > Hmm, I think binary search for the broken patch would be easier. I was afraid you'd say that :-) Will do. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: PATCH: Adds my name to the AUTHORS list

by Tom Wickline

Vincent Béron wrote: > Looking at the revision history for AUTHORS, the file is updated from > the Changelog once in a while by Alexandre. The last time was for > release 20020904. > > I'd say let him continue to do it a couple times per year, rather than > right away. You won't be forgotten :) I agree........ Tom > > Vincent

Jan. 23, 2003

Re: Wine kernel acceleration module?

by Gavriel State

Francois Gouget wrote: > > But of course that's true only if the kernel module has a bug. > With the shared memory server any Windows application can crash all the > others (but not the machine). > > To sum up, here's a table of what crashes based on the source of the > bug: > > | Current | Kernel | Shm > ------------------+---------------+----------------+-------------------- > Bug in the server | Wine | Machine | Wine > ------------------+---------------+----------------+-------------------- > Bug in a Windows | Process | Process | Wine > application | | | > > > So you're better of with the kernel module if the bug is in the > application, and you're better of with shm if the bug is in the server. > Then it's a matter of which one is more likely. It's also a good > argument for having the option to keep using the current server so that > you can make the trade-off between speed and stability yourself. The ShmServer is designed with that in mind. The server code has been moved into a shared library, and the wineserver process still exists in the ShmServer model. While it's not actually available in the current code, it would be trivial to restrict access to the shm area to specific trusted processes and force other processes to go through the normal wineserver route. Additionally, the ShmServer is designed so that the actual shared memory area can be write-locked until a server call is made. Thus it becomes very difficult, though not completely impossible, for an individual process to scribble over the server memory by accident. So the bottom right entry in your table should perhaps be changed to read '99% Process / 1% Wine' What it does *not* prevent is a deliberately malicious app scribbling over server memory - certainly a problem, but for many uses of Wine, not a significant one. Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-) Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. gav(a)transgaming.com http://www.transgaming.com/ Let the games begin

Jan. 23, 2003

Re: Installshield 6 crash: ole trouble

by Marcus Meissner

On Wed, Jan 22, 2003 at 01:50:36PM -0800, Dan Kegel wrote: > Marcus Meissner wrote: > >>>>IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real > >>>>windows to wine's system directory. > > > >I will add a large message suggesting that. > > Thanks. (I'm also looking forward to the possibility of > wine having its own stdole32.tlb soon.) > > >>It looks like there's a Heisenbug here. If I run without > >>logging, I get a window titled "Unhandled Exception", > >>with contents > >>"Error Number: 0x80040706 > >>Description: Object reference not set > >>Setup will now terminate." > > > > > >I have seen this on and off, but I thought I fixed it. > > Interestingly, under wine20020605, I am able to complete > the installation program. Thus we seem to have a regression. > Which would be more helpful: me tracking down which patch > caused the regression, or me sending some more knowledgeable > person a minimal test case? Hmm, I think binary search for the broken patch would be easier. Ciao, Marcus

Jan. 23, 2003

Re: [Fwd: dead keys treatment using XmbLookupString]

by Mauro Carvalho Chehab

Rikki, May be... Wine uses the idea to map keys into vkeys and then mapping back to keys... If something goes wrong on this proccess, it could produce strange results... I can give you some new ideas, but as far as I never seen an Icelandic keyboard, and of course don't have one to hack, you have to try some hacking by yourself. I advice you to try (on this order): 1) May be your keyboard layout is not like a pure QWERTY keyboard. On Brasilian keyboards, we have 49 "main" keys instead of 48. So, I had to include this new key on the layout, generating the 'main_key_scan_abnt_qwerty' and the corresponding 'main_key_vkey_abnt_qwerty' tables, mapping the virtual key VK_OEM_8 to the new key (c cedilla), after ASFGHJKL. You can see these on the current Wine-CVS code. Please notice that the routines that maps keys to vkeys espects to receive some specific VK_OEM_<n> codes for some keys, like '\' (mapped as VK_OEM_7) on X11DRV_InitKeyboard. In fact, the only available VK I found was VK_OEM_8. 2) on ToUnicode (with my patch applyied), what is the return of ret=XmbLookupString? Please notice that, if the return is zero, it will use the Xlib function 'MultiByteToWideChar' after running a code to map the dead keys. Maybe the KEYBOARD_MapDeadKeysym is not treating your dead_circumflex keycode correctly. 3) For brazilian keyboards I need only to change XLookupString to XmbLookupString on KEYBOARD_ToUnicode function, in order to use XKB treatment instead of Xlib, but there are some other points where that function is used. Looking at a glance, I haven't found any reason to change, but you can try to understand better the other calls. I hope these comments can help you. Mauro. Richard Allen wrote: >On Mon, Jan 13, 2003 at 12:07:10PM -0200, Mauro Carvalho Chehab wrote: > >I've been studying this quite a bit. With this patch, I've verifyed that >some of the dead keys work, and some not. If I change the IS keymap >so Im using dead_circumflex instead of dead_acute, then dead (accented) >characters do work, but obviously not the right ones. >This leads me to think that dead_acute characters are handled differently >by wine than dead_circumflex characters are. > >Mauro, do you think I could be on to something here ? > > > > > >>Rikki, >> >> As far as I know, wine keyboard.c uses XFree86 Keymap table to >>compare your key definitions with their internal geometry. After that, >>it maps every scan code to a virtual key. The virtual key is mapped >>back to a scan code and to an unicode symbol by ToUnicode function. >>During this proccess, it uses part of the original xfree mapping. >> On the original ToUnicode function, it uses the function >>XLookupString (a Xlib function) to map scan code->symbol. This function >>is capable to work with latin characters, but it doesn't implement dead >>keys translation on the current XFree86 implementations. In the past, >>there was some Xlib hacking that changes this behavor (X11 R5 >>implementations). The new standard (X11 R6) creates the xkb extensions, >>that provides new functions to treat locale imput data (XmbLookupString, >>Xutf8LookupString and XwcLookupString). What it does is to use XFree86 >>locale settings to make this map. >> The dead key treatment is defined on /usr/X11R6/lib/X11/locale. >> The geometry of their keyboards, used by xkb, are on >>/usr/X11R6/lib/X11/xkb (RedHat) or /etc/X11/xkb (Mandrake). The file >>symbols/is, for example, contains some icelandic definitions. >> From your answer, I would try to fix the XFree86 keyboard mapping on >>symbols/is. I guess that this will solve both XFree and Wine (patched). >> >> > > >

Jan. 23, 2003

Re: A strange problem with xmpeg

by Waldeck Schutzer

I have more data on item (2). I traced back the problem to be in Main_DirectDraw_CreateSurface. The application (or even wine itself) had requested a surface with flags DDSCAPS_VIDEOMEMORY and DDSCAPS_OVERLAY set. These are apparently not supported and, instead of failing, that function assumes the creation of an offscreen surface instead. However, it seems the other parameters (including surface BPP) were not adequately set, which causes wine to crash later on in DDRAW_width_bpp_to_pitch. I'd like to include the backtrace and other debug stuff here but I don't know how to copy and paste from winedbg window. Since this seems to be an implementation issue, I will make no attempt to fixing it. For the time being, I'll just keep the hack I told you before. Best, Waldeck

Jan. 23, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Dan Kegel

Duane Clark wrote: > I ran the app under WinNT and Wine, and compared the messages generated > using SPY++. There are non-client (border) and background fill messages > missing. So then it becomes a matter of figuring out where they should > be generated. Maybe I'll try that on my bad app, thanks for pointing out the obvious! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003