wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

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@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 04 Mar '01

04 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 04 Mar '01

04 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

Re: ListView fix
by François Gouget 03 Mar '01

03 Mar '01

Ok, so now that I've got the patch out, there's a weird problem that I've been having with this piece of code. Apply the following on top of my previous patch and you'll get the weirdest traces: --- cut here --- Index: dlls/comctl32/listview.c =================================================================== RCS file: /home/cvs/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.99 diff -u -r1.99 listview.c --- dlls/comctl32/listview.c 2001/02/28 05:31:02 1.99 +++ dlls/comctl32/listview.c 2001/03/02 23:45:09 @@ -1542,10 +1545,22 @@ item.stateMask = LVIS_SELECTED; item.state = LVIS_SELECTED; + TRACE("nSelectionMark=%d nItem=%d nFirst=%d nLast=%d\n",infoPtr->nSelectionMark,nItem,nFirst,nLast); +#if 0 + i = nFirst; + while (i <= nLast) + { + TRACE("i=%d\n",i); + LISTVIEW_SetItemState(hwnd,i,&item); + i++; + } +#else for (i = nFirst; i <= nLast; i++); { + TRACE("i=%d\n",i); LISTVIEW_SetItemState(hwnd,i,&item); } +#endif LISTVIEW_SetItemFocus(hwnd, nItem); infoPtr->nSelectionMark = nItem; --- cut here --- Now if I click on item 3 I get the following trace: ... trace:listview:LISTVIEW_AddGroupSelection nSelectionMark=-1 nItem=3 nFirst=3 nLast=3 trace:listview:LISTVIEW_AddGroupSelection i=4 trace:listview:LISTVIEW_WindowProc hwnd=1908 uMsg=1006 wParam=0 lParam=405b6c30 trace:listview:LISTVIEW_AddSelectionRange Add range 4 - 4 ... Now, last I checked (i.e. a few minutes a go), 'for (i=3;i<=3;i++) printf("%d\n",i);' prints 3 and certainly not 4. Also, if I'm not mistaken this code is strictly equivalent to the while loop in the '#if 0' branch. Yet the while loop works fine but not the for loop. In a word this looks like a gcc bug to me! $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) How do we normally deal with those? -- François Gouget fgouget(a)codeweavers.com

2 1

WinMM/MMSystem & registry
by Eric Pouech 02 Mar '01

02 Mar '01

I'm currently investigating moving all multimedia setup into the registry as current WINMM/MMSYSTEM implementation is rather close to the WIN3.x/9x model, I started looking at their native implementation. The main goal is to use no longer the hard coded drivers name, but rather get them from the registry basically, it goes like this: /* * The Windows registry settings are as follows: * - the drivers are defined by sets, each set has an index * - the sets are loaded in the set index increasing order * - a set is divided by classes (wave, midi...), and several drivers can be * defined in each class * - the keys are spread into two locations: * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\MEDIA\%idx%\Drivers\%class%\%name% * where %idx% is the set index, * %class% is the class (midi, wave...) * %name% is the name of the device (which can be different from * the actual name of a the driver's filename (even if, * in lots of cases it's the same)) * these keys mainly describe what to load, and in which order * This key shall also contain some configuration options for the driver (if * needed...) * - each entry under the Services\Class has a corresponding entry in another part * of the registry * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaResources\%class%\%namen%<%idx%> * Under this location is stored information regarding how to load the * driver (like if it's enabled, PnP information...) */ there are some other keys (like the PnP devices enumeration) which use the index to refer to the driver implementing this under Wine is not too difficult. The hairy part is the configuration (setting up the keys in the registry) since the first step of the configuration (for this scheme) is to get the first unused index, this can be a bit tricky (especially when a registry exists, and has been copied from a native one) the possible solutions are: A/ implement this mechanism and provide an ad hoc tool for this purpose. The hard part is, in some cases, that the data to add to the registry have to be determined at installation time: the number of DSP available for the wave output, or the list of MIDI playback devices (synthesizer, midi out...) - current WineOSS implementation gets its name from the kernel -. A1/ create a specific (winelib) tool to take care of it A2/ make use of Windows installation capabilities (setup API) and provide a .INF file for each. I'm not quite sure that's feasible with the semantics of the API (mainly for the naming issue described above) B/ do not implement this mechanism B1/ provide a Wine specific easy set of keys B2/ same as above, but upon startup, Wine (or winmm/mmsystem) partially recreates the native keys as needed I'd rather go the A1 or B1. As of today, the only drawback of B1 is that some native DLLs (multimedia control panel, the midi mapper) will not work. I haven't (yet) run against a program using this poorly undocumented set of features (which, of course, will not work on Win2k with WDM in place). any comment is welcome. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

file descriptor problems
by Rein Klazes 02 Mar '01

02 Mar '01

Hi, With today's CVS I get problems with the Agent newsreader after 0.5 to 1 hour of use. Sometimes I get this: > wine client error:0x8063890: no fd received for handle 264 and the wine service tread has exited. In other cases the program shows a message box showing: cannor write <filename>. DOS error 4. and the program goes crazy. Dos error 4 means "too many files open", which seems related to the first message. Rein. -- Rein Klazes rklazes(a)casema.net

1 0

Protocol error
by Andreas Schultz 01 Mar '01

01 Mar '01

Hi, I'm getting repeatable error's with the latest CVS version: Protocol error:0x8066ae0: read : Resource temporarily unavailable The application that is causing is the Gunman Chronicles Dedicated Server. I tried to find out what is going on, but couldn't find anything usefull. Has anybody ales seen a similar behavior? Andreas -- -------------------- professional INTERNET services -------------------- EastLink GmbH Niederlassung Magdeburg voice: +49-180-5432060 Lorenzweg 42 fax: +49-371-4320626 D-39110 Magdeburg http://www.eastlink.de

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel