- Wine-Devel - list.winehq.org

RFC: client side implementation of async I/O
by Michael McCormack March 4, 2001

March 4, 2001

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 March 3, 2001

March 3, 2001

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 March 3, 2001

March 3, 2001

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 March 3, 2001

March 3, 2001

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 March 2, 2001

March 2, 2001

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 March 2, 2001

March 2, 2001

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 March 1, 2001

March 1, 2001

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

New execution behavior
by Duane Clark Feb. 28, 2001

Feb. 28, 2001

Howdy, Here is a symptom that has crept into the recent version of wine. Since I know how to make things work, this is just a post in case someone is interested. When I recently updated to the Feb 24 CVS version (from the Feb 4 version), I suddenly had the symptom that I could only run one program at a time. In other words, I ran the program schedit (one I use regularly), and it came up and worked fine. But when I then tried to also run symed, it would not come up, but instead gave: err:ntdll:RtlpWaitForCriticalSection Critical section 0x400f9ad0 wait timed out, retrying (60 sec) fs=022f Where the address 0x400f9ad0 is in: disas 0x400f9ad0 0x400f9ad0 (peb_lock [rtl.c]): addb %al,0x0(%eax) 0x400f9ad2 (peb_lock+0x2 [rtl.c]): addb %al,0x0(%eax) 0x400f9ad4 (peb_lock+0x4 [rtl.c]): 0x400f9ad6 (peb_lock+0x6 [rtl.c]): 0x400f9ad8 (peb_lock+0x8 [rtl.c]): addb %al,0x0(%eax) 0x400f9ada (peb_lock+0xa [rtl.c]): addb %al,0x0(%eax) 0x400f9adc (peb_lock+0xc [rtl.c]): addb %al,0x0(%eax) 0x400f9ade (peb_lock+0xe [rtl.c]): addb %al,0x0(%eax) 0x400f9ae0 (peb_lock+0x10 [rtl.c]): cmpb $0,%al 0x400f9ae2 (peb_lock+0x12 [rtl.c]): addb %al,0x0(%eax) Wine-dbg> Trying a couple other programs showed that this affected all of them. In particular, one that is more readily available, Wordview97. For example, I could run one instance of wordview, but not a second. This is running wine along with a Win98 installation. It turns out the for some obscure reason I had the DLLs exactly as in the sample config file, except that I had: "DefaultLoadOrder" = "builtin, native, so" Putting it the (presumably) right way fixed things (except a wordview font problem): "DefaultLoadOrder" = "native, builtin, so" Here is info on the the loading of DLLs. The only differences I see with native first is with ole32 being native instead of builtin, and that rpcrt4 gets loaded much later. Here is with "DefaultLoadOrder" = "native, builtin, so" trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\kernel32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\advapi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\gdi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\user32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\ole32.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\mso97v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\Program Files\WordView\wwint32v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shlwapi.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comctl32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shell32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\winspool.drv' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'krnl386.exe' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'system' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'wprocs' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'GDI.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\wineps.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'USER.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\x11drv.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'display' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comdlg32.dll' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'commdlg.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\rpcrt4.dll' : native And here is with "DefaultLoadOrder" = "builtin, native, so" trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\kernel32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\advapi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\gdi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\user32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\rpcrt4.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\ole32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\mso97v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\Program Files\WordView\wwint32v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shlwapi.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comctl32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shell32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\winspool.drv' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'krnl386.exe' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'system' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'wprocs' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'GDI.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\wineps.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'USER.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\x11drv.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'display' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comdlg32.dll' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'commdlg.dll' : builtin And here is a short message from Gerard, regarding a trace I had sent him. Both traces are from running Wordview, where the first one came up ok and the second crashed (the behavior changed when run with these debug messages enabled): Here is what your app (actually, probably rpcrt4 for Win9x) is doing : Call kernel32.193: CreateFileMappingA(ffffffff,00000000,00000004,00000000,00000400,7fbd4a7c "rpcrt4sharedmem") ret=7fb9177b fs=008f Ret kernel32.193: CreateFileMappingA() retval=00000048 ret=7fb9177b fs=008f Call kernel32.419: GetLastError() ret=7fb9178e fs=008f Ret kernel32.419: GetLastError() retval=00000000 ret=7fb9178e fs=008f Call kernel32.632: MapViewOfFile(00000048,00000002,00000000,00000000,00000000) ret=7fb917ac fs=008f Ret kernel32.632: MapViewOfFile() retval=40349000 ret=7fb917ac fs=008f Call kernel32.553: HeapCreate(04000000,00001000,00000000) ret=7fb95c0f fs=008f Ret kernel32.553: HeapCreate() retval=65430000 ret=7fb95c0f fs=008f Call kernel32.551: HeapAlloc(65430000,00000000,00000040) ret=7fb95bf9 fs=008f Ret kernel32.551: HeapAlloc() retval=6543009c ret=7fb95bf9 fs=008f So, we have created a shared memory area and allocated memory at 65430000 Now here is what the next process is doing : Call kernel32.193: CreateFileMappingA(ffffffff,00000000,00000004,00000000,00000400,7fbd4a7c "rpcrt4sharedmem") ret=7fb9177b fs=008f Ret kernel32.193: CreateFileMappingA() retval=00000048 ret=7fb9177b fs=008f Call kernel32.419: GetLastError() ret=7fb9178e fs=008f Ret kernel32.419: GetLastError() retval=000000b7 ret=7fb9178e fs=008f Call kernel32.632: MapViewOfFile(00000048,00000002,00000000,00000000,00000000) ret=7fb917ac fs=008f Ret kernel32.632: MapViewOfFile() retval=40349000 ret=7fb917ac fs=008f Call kernel32.380: GetCurrentProcessId() ret=7fb95d5b fs=008f Ret kernel32.380: GetCurrentProcessId() retval=0808e1b8 ret=7fb95d5b fs=008f Call user32.422: MessageBoxA(00000000,40474ae0 "Unhandled page fault on read access to 0x654300b0 We have opened the shared memory (this is working since GetLastError returns that the file already exists : 000000b7), and tried to access data at 0x654300b0. This is failing it seems (you could try to run with -debugmsg +seh to confirm that an exception is occuring there) Note that the second process has allocated *no memory* at this place; from where is coming this 654300b0 value ? I guess from the shared memory. Duane

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells Feb. 28, 2001

Feb. 28, 2001

I've got a lot of the wine support kernel module written now. Its system call latency seems to be down at near half that of Win2000 for mutexes, though there's no guarantee that my benchmark programs produce meaningful numbers. I've also got PE Image mapping done (with pages fixed up on demand and marked as discardable). So if anything, Wine might want to steal that if the module as a whole is not used. This bit requires virtually no changes to the kernel itself, just half a dozen or so extra symbols to be exported. The module image size stands currently at about 30K. Status: PART STATE ====================================== ========================== General object infrastructure done HANDLE infrastructure mostly done Waiting calls partly done Exception handling not done Win32 error handling not done, uses UNIX errno UNICODE handling ignored, all ASCII Security handling ignored Mutex objects done Semaphore objects done Event objects done File objects (synchronous access) mostly done File objects (asynchronous access) not done Shared memory objects mostly done Process objects slightly done Thread objects slightly done Registry objects not done NT Port objects not done NT Token objects not done W2K Job objects not done Net Communications not done userspace access library up to date strace mostly up to date Cheers, David

1 0

PostScript driver demand loading
by Ian Pilcher Feb. 27, 2001

Feb. 27, 2001

The attached patch removes the explicit load of the PostScript driver from MAIN_GdiInit. Instead, when a function calls DRIVER_FindDriver to get a drivers DC_FUNCTIONS, DRIVER_FindDriver will attempt to load a named driver if it hasn't already registered itself. This appears to work for printing from Lotus Notes. I'd appreciate some feedback from people using other applications, however. Also, any thoughts on the approach in general would be welcome. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010226cvs/graphics/driver.c Mon Nov 27 17:54:29 2000 +++ graphics/driver.c Tue Feb 27 18:34:08 2001 @@ -54,15 +54,25 @@ */ const DC_FUNCTIONS *DRIVER_FindDriver( LPCSTR name ) { - GRAPHICS_DRIVER *driver = firstDriver; + GRAPHICS_DRIVER *driver; + HINSTANCE hDriver; TRACE(": %s\n", name); - while (driver && name) - { + + if (!name) return genericDriver ? genericDriver->funcs : NULL; + + for (driver = firstDriver; driver; driver = driver->next) if (!strcasecmp( driver->name, name )) return driver->funcs; - driver = driver->next; - } - return genericDriver ? genericDriver->funcs : NULL; + + if (!(hDriver = LoadLibraryA (name))) return NULL; + + for (driver = firstDriver; driver; driver = driver->next) + if (!strcasecmp( driver->name, name )) return driver->funcs; + + if (!FreeLibrary (hDriver)) + WARN ("FreeLibrary failed with code %li\n", GetLastError ()); + + return NULL; } --- ../wine-20010226cvs/dlls/gdi/gdi_main.c Fri Jan 26 14:43:43 2001 +++ dlls/gdi/gdi_main.c Tue Feb 27 18:19:44 2001 @@ -24,9 +24,6 @@ /* Create the Win16 printer driver */ if (!WIN16DRV_Init()) return FALSE; - /* PSDRV initialization */ - if (!LoadLibraryA( "wineps" )) return FALSE; - return TRUE; }

1 0