March 2001 - Wine-devel - list.winehq.org

Re: Perl/Wine extension for perusal
by Niki Spahiev 06 Mar '01

06 Mar '01

Hello, Two small suggestions: 1. python has very good WIN32 bindings and also generic DLL interface CALLDLL. 2. VNC has alpha of macro recorder which can be used for interactive tests. Regards, Niki Spahiev

1 0

Re: RFC: client side implementation of async I/O
by Alexandre Julliard 06 Mar '01

06 Mar '01

Michael McCormack <mccormac(a)aals27.alcatel.com.au> writes: > This patch moves responsibility for asynchronous I/O to the client process. > i'm posting it to wine-devel because i want to know what other developers here > think about the technique i've used to make this work... Your approach is not going to work with the latest changes I made to the server. The good news is that the changes I'm making are in part to allow making server calls in signal handlers, so when this works you should be able to use SIGIO to do async IO. > i think this implementation is more efficient, as it makes fewer server calls > and duplicates fewer file descriptors, while maintaining correctness. It's not clear to me that it is more efficient; it seems it will do a lot more work on every single server call if an async IO is pending. Of course the only way to tell is to run benchmarks. -- Alexandre Julliard julliard(a)winehq.com

3 2

TCP/IP networking and registry keys
by Alan Chandler 06 Mar '01

06 Mar '01

I spent most of the weekend trying to get Grand Prix Legends GPL to work. I achieved my first goal of getting it to run in server mode. One of the things I needed to get the game to do, was to recognise that there where some interfaces it could talk TCP/IP out of. It took me some time to realise that under windows it was doing this by looking for the key [System\\CurrentControlSet\\Services\\Class\\NetTrans] and was then enumerating the keys under it to establish an IP address ie the following [System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000] "IPAddress"="10.0.10.100" The thought occurred to me that maybe the tool the builds the registry during wine install could actually create these keys - since it is essentially a key part of the system (and other similar keys are also built in the same way). I don't think I have the skills to do it myself yet. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

3 2

Wine Press
by Eric Pouech 05 Mar '01

05 Mar '01

http://linux.cnet.com/linux/0-2136864-7-4961586.html worth the reading, even if Wine gets the lowest ranking my reading of it is that Wine is not yet a product (compared to the two others). I definitively think we should focus more on a release target. It of course means that we have to make choices (do not include some functionnalities), spend pretty much more time on testing... but that's the way to go if we want to have Wine 1.0 around on of these days A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

3 2

Re: RESUBMIT: afm
by Gavriel State 05 Mar '01

05 Mar '01

Back in Febuary, Marcus Meissner wrote: > > Changelog: > fixed one NULL ptr problem > added loading of .afm files from several common locations > (ghostscript, a2ps, enscript, (teTeX), X11) > > Index: afm.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/afm.c,v > retrieving revision 1.4 > diff -u -r1.4 afm.c > --- afm.c 2001/01/02 20:30:16 1.4 > +++ afm.c 2001/02/03 18:50:42 > BOOL PSDRV_GetFontMetrics(void) > { > int idx = 0; > char key[256]; > char value[256]; > + char *path; > + DIR *dir; > + > + /* some packages with afm files in that directory */ > + PSDRV_ReadAFMDir("/usr/share/ghostscript/fonts/"); > + PSDRV_ReadAFMDir("/usr/share/a2ps/afm/"); > + PSDRV_ReadAFMDir("/usr/share/enscript/"); > + PSDRV_ReadAFMDir("/usr/X11R6/lib/X11/fonts/Type1/"); We just did an integration with WineHQ, and this code has started to grate on me (mostly because of the fact that the AFM parser spits out a bunch of error messages while trying to parse my AFM files. Rather than hardcoding the paths into the code, could we do this instead: while (PROFILE_EnumWineIniString( "afmdirs", idx++, key, sizeof(key), value, sizeof(value))) PSDRV_ReadAFMDir(value); This has the added benefit of allowing the user to specify only those AFM directories that their rasterizer knows about too. With the above, I get a whole bunch of printer fonts listed as available in wine that I can't actually print if Ghostscript isn't configured to find the font files. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

[RESEND] Re: faster 8bpp to 24 bit depth conversion in SetImageBits_8
by Vedran Rodic 04 Mar '01

04 Mar '01

On Sun, Mar 04, 2001 at 01:51:16PM +0100, Ove Kaaven wrote: > > > Since this is a 32-bit move (movl), you should use %%eax, not %%ax. The > assembler doesn't complain about this now, but technically it should, and > might someday. > > Since you're converting to 32bpp, not 16bpp, you should multiply "left" by > 4, not by 2, or strange things may happen in some apps. Thanks. Fixed patch attached. I did change left multiplicator from 2 to 4 in my earlier patches, but I forgot to include it in my final patch being 3 AM and so... I'll try to be more careful next time. Vedran

1 1

Re: for loop fixes
by Francois Gouget 04 Mar '01

04 Mar '01

On Sat, 3 Mar 2001, Andreas Mohr wrote: [...] > - changed all terminating ";" of isolated for loops to " ;" to indicate the > loop's isolation. IMHO, for such loops the following would be much clearer: <init_expression>; while (<test_condition>) { <update_expression>; } (ok, you can also put '{' on the next line) > Please do the same for these for loops in the future. ??? > Somebody might want to write a Wine coding guidelines article... $ wg . -E 'for *$' | grep -E '$ *; *$'` | wc -l 96 (wg is my recursive source grep script) Maybe we should ask people to put the for and the instruction it applies to on separate lines. Combined with the suggestion above this would make it easier to check for this kind of bug. > P.S.: I just *knew* that at least one other for loop in Wine would be wrong, > too ;-) Yep, I should have done that myself (if you find a generic bug, always check for other similar bugs). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

4 4

RFC: client side implementation of async I/O
by Michael McCormack 04 Mar '01

04 Mar '01

Hi all, This patch moves responsibility for asynchronous I/O to the client process. i'm posting it to wine-devel because i want to know what other developers here think about the technique i've used to make this work... i've relaxed some of the assumptions wineserver makes about client processes. i think this implementation is more efficient, as it makes fewer server calls and duplicates fewer file descriptors, while maintaining correctness. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+8232) 667 0425 (h) (+8211) 430 0425 (m)

1 0

Re: Add explicit WM_CLOSE processing in the edit control
by Alexandre Julliard 03 Mar '01

03 Mar '01

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Since handler of WM_CLOSE in DefWindowProc calls DestroyWindow, > which eventually sends WM_DESTROY, EDITSTATE gets destroyed before > call to EDIT_UnlockBuffer in the end of processing of WM_CLOSE, > therefore EDIT_UnlockBuffer gets confused. This is not specific to WM_CLOSE, it can happen with other messages too; any time we transfer control back to the application the window can be destroyed. I think it would be better to either unlock the buffer before calling DefWindowProc, or make EDIT_UnlockBuffer cope with a destroyed window. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: erase bkgnd on page scroller control
by Alexandre Julliard 03 Mar '01

03 Mar '01

Susan Farley <susan(a)codeweavers.com> writes: > @@ -720,7 +721,8 @@ > PAGER_INFO *infoPtr; > DWORD dwStyle = GetWindowLongA (hwnd, GWL_STYLE); > > - dwStyle |= WS_CLIPCHILDREN; > + /* background color of the child should be the same as the pager */ > + dwStyle &= ~WS_CLIPCHILDREN; Shouldn't we simply leave WS_CLIPCHILDREN alone and use whatever the app specified when creating the window, instead of forcing it one way or another? -- Alexandre Julliard julliard(a)winehq.com

1 0