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

New execution behavior

by Duane Clark

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

Feb. 28, 2001

Re: Speeding up wineserver syncronization objects with shared memory

by David Howells

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

Feb. 28, 2001

PostScript driver demand loading

by Ian Pilcher

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; }

Feb. 27, 2001

Re: winspool.drv initialization problem

by Huw D M Davies

On Mon, Feb 26, 2001 at 11:07:27PM +0600, Ian Pilcher wrote: > Any idea when Windows loads printer drivers? Usually on CreateDC/IC or OpenPrinter. Huw. -- Dr. Huw D M Davies | Clarendon Laboratory h.davies1(a)physics.ox.ac.uk | Parks Road Tel: +44 1865 272390 | Oxford OX1 3PU Fax: +44 1865 272400 | UK

Feb. 27, 2001

Re: winspool.drv initialization problem

by Ian Pilcher

Huw D M Davies wrote: > > > Any idea when Windows loads printer drivers? > > Usually on CreateDC/IC or OpenPrinter. > Well, since I can't whip out 400-line patches the way Alexandre can, I'll see if I can move the LoadLibrary call. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 27, 2001

Re: winspool.drv initialization problem

by Alexandre Julliard

Ian Pilcher <pilcher(a)concentric.net> writes: > I've gotten my modified version of the PostScript driver to load, but it > seems to causing/exposing another problem. > > WINPROC_GetPtr is being called befor WINPROC_Init during Wine > initialization. The call to WINPROC_GetPtr results from a call to > LoadLibraryExA ("COMCTL32.DLL" ...); here is the stack: Sounds like importing winspool.drv in wineps creates a circular load dependency (user32->gdi32->wineps->winspool->comctl32->user32). We could probably be a bit more clever about loading wineps only when really necessary; OTOH there is no reason for winspool.drv to require comctl32. Something like this should fix it (completely untested, so it's probably broken): Index: dlls/winspool/info.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/winspool/info.c,v retrieving revision 1.33 diff -u -r1.33 info.c --- dlls/winspool/info.c 2001/02/21 04:00:40 1.33 +++ dlls/winspool/info.c 2001/02/26 23:01:57 @@ -20,23 +20,12 @@ #include "wine/unicode.h" #include "debugtools.h" #include "heap.h" -#include "commctrl.h" #include "winnls.h" DEFAULT_DEBUG_CHANNEL(winspool); -typedef struct _OPENEDPRINTER -{ - LPWSTR lpsPrinterName; - HANDLE hPrinter; -} OPENEDPRINTER, *LPOPENEDPRINTER; - -/* The OpenedPrinter Table dynamic array */ -static HDPA pOpenedPrinterDPA = NULL; - -extern HDPA WINAPI (*WINSPOOL_DPA_CreateEx) (INT, HANDLE); -extern LPVOID WINAPI (*WINSPOOL_DPA_GetPtr) (const HDPA, INT); -extern INT WINAPI (*WINSPOOL_DPA_InsertPtr) (const HDPA, INT, LPVOID); +static LPWSTR *printer_array; +static int nb_printers; static DWORD WINAPI (*GDI_CallDeviceCapabilities16)( LPCSTR lpszDevice, LPCSTR lpszPort, WORD fwCapability, LPSTR lpszOutput, @@ -84,73 +73,42 @@ * WINSPOOL_GetOpenedPrinterEntry * Get the first place empty in the opened printer table */ -static LPOPENEDPRINTER WINSPOOL_GetOpenedPrinterEntry() +static HANDLE WINSPOOL_GetOpenedPrinterEntry( LPCWSTR name ) { int i; - LPOPENEDPRINTER pOpenedPrinter; - /* - * Create the opened printers' handle dynamic array. - */ - if (!pOpenedPrinterDPA) - { - pOpenedPrinterDPA = WINSPOOL_DPA_CreateEx(10, GetProcessHeap()); - for (i = 0; i < 10; i++) - { - pOpenedPrinter = HeapAlloc(GetProcessHeap(), - HEAP_ZERO_MEMORY, - sizeof(OPENEDPRINTER)); - pOpenedPrinter->hPrinter = -1; - WINSPOOL_DPA_InsertPtr(pOpenedPrinterDPA, i, pOpenedPrinter); - } - } + for (i = 0; i < nb_printers; i++) if (!printer_array[i]) break; - /* - * Search for a handle not yet allocated. - */ - for (i = 0; i < pOpenedPrinterDPA->nItemCount; i++) + if (i >= nb_printers) { - pOpenedPrinter = WINSPOOL_DPA_GetPtr(pOpenedPrinterDPA, i); - - if (pOpenedPrinter->hPrinter == -1) - { - pOpenedPrinter->hPrinter = i + 1; - return pOpenedPrinter; - } + LPWSTR *new_array = HeapReAlloc( GetProcessHeap(), 0, printer_array, + (nb_printers + 16) * sizeof(*new_array) ); + if (!new_array) return 0; + printer_array = new_array; + nb_printers += 16; } - /* - * Didn't find one, insert new element in the array. - */ - if (i == pOpenedPrinterDPA->nItemCount) + if ((printer_array[i] = HeapAlloc( GetProcessHeap(), 0, (strlenW(name)+1)*sizeof(WCHAR) ))) { - pOpenedPrinter = HeapAlloc(GetProcessHeap(), - HEAP_ZERO_MEMORY, - sizeof(OPENEDPRINTER)); - pOpenedPrinter->hPrinter = i + 1; - WINSPOOL_DPA_InsertPtr(pOpenedPrinterDPA, i, pOpenedPrinter); - return pOpenedPrinter; + strcpyW( printer_array[i], name ); + return (HANDLE)(i + 1); } - - return NULL; + return 0; } /****************************************************************** * WINSPOOL_GetOpenedPrinter * Get the pointer to the opened printer referred by the handle */ -static LPOPENEDPRINTER WINSPOOL_GetOpenedPrinter(int printerHandle) +static LPCWSTR WINSPOOL_GetOpenedPrinter(HANDLE printerHandle) { - LPOPENEDPRINTER pOpenedPrinter; - - if(!pOpenedPrinterDPA) return NULL; - if((printerHandle <=0) || - (printerHandle > (pOpenedPrinterDPA->nItemCount - 1))) + int idx = (int)printerHandle; + if ((idx <= 0) || (idx > nb_printers)) + { + SetLastError(ERROR_INVALID_HANDLE); return NULL; - - pOpenedPrinter = WINSPOOL_DPA_GetPtr(pOpenedPrinterDPA, printerHandle-1); - - return pOpenedPrinter; + } + return printer_array[idx - 1]; } /****************************************************************** @@ -159,21 +117,20 @@ */ static DWORD WINSPOOL_GetOpenedPrinterRegKey(HANDLE hPrinter, HKEY *phkey) { - LPOPENEDPRINTER lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); + LPCWSTR name = WINSPOOL_GetOpenedPrinter(hPrinter); DWORD ret; HKEY hkeyPrinters; - if(!lpOpenedPrinter) - return ERROR_INVALID_HANDLE; + if(!name) return ERROR_INVALID_HANDLE; if((ret = RegCreateKeyA(HKEY_LOCAL_MACHINE, Printers, &hkeyPrinters)) != ERROR_SUCCESS) return ret; - if(RegOpenKeyW(hkeyPrinters, lpOpenedPrinter->lpsPrinterName, phkey) - != ERROR_SUCCESS) { + if(RegOpenKeyW(hkeyPrinters, name, phkey) != ERROR_SUCCESS) + { ERR("Can't find opened printer %s in registry\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + debugstr_w(name)); RegCloseKey(hkeyPrinters); return ERROR_INVALID_PRINTER_NAME; /* ? */ } @@ -408,7 +365,6 @@ LPSTR pDeviceName, LPDEVMODEA pDevModeOutput, LPDEVMODEA pDevModeInput,DWORD fMode ) { - LPOPENEDPRINTER lpOpenedPrinter; LPSTR lpName = pDeviceName; LONG ret; @@ -417,13 +373,8 @@ ); if(!pDeviceName) { - LPWSTR lpNameW; - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return -1; - } - lpNameW = lpOpenedPrinter->lpsPrinterName; + LPCWSTR lpNameW = WINSPOOL_GetOpenedPrinter(hPrinter); + if(!lpNameW) return -1; lpName = HEAP_strdupWtoA(GetProcessHeap(),0,lpNameW); } @@ -512,7 +463,6 @@ BOOL WINAPI OpenPrinterW(LPWSTR lpPrinterName,HANDLE *phPrinter, LPPRINTER_DEFAULTSW pDefault) { - LPOPENEDPRINTER lpOpenedPrinter; HKEY hkeyPrinters, hkeyPrinter; if (!lpPrinterName) { @@ -545,21 +495,8 @@ if(!phPrinter) /* This seems to be what win95 does anyway */ return TRUE; - /* Get a place in the opened printer buffer*/ - lpOpenedPrinter = WINSPOOL_GetOpenedPrinterEntry(); - if(!lpOpenedPrinter) { - ERR("Can't allocate printer slot\n"); - SetLastError(ERROR_OUTOFMEMORY); - return FALSE; - } - - /* Get the name of the printer */ - lpOpenedPrinter->lpsPrinterName = HeapAlloc( GetProcessHeap(), 0, - (strlenW(lpPrinterName)+1)*sizeof(WCHAR) ); - strcpyW( lpOpenedPrinter->lpsPrinterName, lpPrinterName ); - /* Get the unique handle of the printer*/ - *phPrinter = lpOpenedPrinter->hPrinter; + *phPrinter = WINSPOOL_GetOpenedPrinterEntry( lpPrinterName ); if (pDefault != NULL) FIXME("Not handling pDefault\n"); @@ -915,23 +852,14 @@ */ BOOL WINAPI ClosePrinter(HANDLE hPrinter) { - LPOPENEDPRINTER lpOpenedPrinter; + int i = (int)hPrinter; TRACE("Handle %d\n", hPrinter); - - if (!pOpenedPrinterDPA) - return FALSE; - if ((hPrinter != -1) && (hPrinter < (pOpenedPrinterDPA->nItemCount - 1))) - { - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - HeapFree(GetProcessHeap(), 0, lpOpenedPrinter->lpsPrinterName); - lpOpenedPrinter->lpsPrinterName = NULL; - lpOpenedPrinter->hPrinter = -1; - - return TRUE; - } - return FALSE; + if ((i <= 0) || (i > nb_printers)) return FALSE; + HeapFree( GetProcessHeap(), 0, printer_array[i - 1] ); + printer_array[i - 1] = NULL; + return TRUE; } /***************************************************************************** @@ -957,15 +885,10 @@ */ BOOL WINAPI DeletePrinter(HANDLE hPrinter) { - LPWSTR lpNameW; + LPCWSTR lpNameW = WINSPOOL_GetOpenedPrinter(hPrinter); HKEY hkeyPrinters; - LPOPENEDPRINTER lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return FALSE; - } - lpNameW = lpOpenedPrinter->lpsPrinterName; + if(!lpNameW) return FALSE; if(RegOpenKeyA(HKEY_LOCAL_MACHINE, Printers, &hkeyPrinters) != ERROR_SUCCESS) { ERR("Can't open Printers key\n"); @@ -1410,7 +1333,7 @@ static BOOL WINSPOOL_GetPrinter(HANDLE hPrinter, DWORD Level, LPBYTE pPrinter, DWORD cbBuf, LPDWORD pcbNeeded, BOOL unicode) { - OPENEDPRINTER *lpOpenedPrinter; + LPCWSTR name; DWORD size, needed = 0; LPBYTE ptr = NULL; HKEY hkeyPrinter, hkeyPrinters; @@ -1418,20 +1341,16 @@ TRACE("(%d,%ld,%p,%ld,%p)\n",hPrinter,Level,pPrinter,cbBuf, pcbNeeded); - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return FALSE; - } + if (!(name = WINSPOOL_GetOpenedPrinter(hPrinter))) return FALSE; + if(RegCreateKeyA(HKEY_LOCAL_MACHINE, Printers, &hkeyPrinters) != ERROR_SUCCESS) { ERR("Can't create Printers key\n"); return FALSE; } - if(RegOpenKeyW(hkeyPrinters, lpOpenedPrinter->lpsPrinterName, &hkeyPrinter) - != ERROR_SUCCESS) { - ERR("Can't find opened printer %s in registry\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + if(RegOpenKeyW(hkeyPrinters, name, &hkeyPrinter) != ERROR_SUCCESS) + { + ERR("Can't find opened printer %s in registry\n", debugstr_w(name)); RegCloseKey(hkeyPrinters); SetLastError(ERROR_INVALID_PRINTER_NAME); /* ? */ return FALSE; @@ -1933,7 +1852,7 @@ DWORD cbBuf, LPDWORD pcbNeeded, BOOL unicode) { - OPENEDPRINTER *lpOpenedPrinter; + LPCWSTR name; WCHAR DriverName[100]; DWORD ret, type, size, needed = 0; LPBYTE ptr = NULL; @@ -1944,11 +1863,8 @@ ZeroMemory(pDriverInfo, cbBuf); - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return FALSE; - } + if (!(name = WINSPOOL_GetOpenedPrinter(hPrinter))) return FALSE; + if(Level < 1 || Level > 3) { SetLastError(ERROR_INVALID_LEVEL); return FALSE; @@ -1958,10 +1874,9 @@ ERR("Can't create Printers key\n"); return FALSE; } - if(RegOpenKeyW(hkeyPrinters, lpOpenedPrinter->lpsPrinterName, &hkeyPrinter) + if(RegOpenKeyW(hkeyPrinters, name, &hkeyPrinter) != ERROR_SUCCESS) { - ERR("Can't find opened printer %s in registry\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + ERR("Can't find opened printer %s in registry\n", debugstr_w(name)); RegCloseKey(hkeyPrinters); SetLastError(ERROR_INVALID_PRINTER_NAME); /* ? */ return FALSE; @@ -1972,8 +1887,7 @@ RegCloseKey(hkeyPrinter); RegCloseKey(hkeyPrinters); if(ret != ERROR_SUCCESS) { - ERR("Can't get DriverName for printer %s\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + ERR("Can't get DriverName for printer %s\n", debugstr_w(name)); return FALSE; } Index: dlls/winspool/wspool.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/winspool/wspool.c,v retrieving revision 1.3 diff -u -r1.3 wspool.c --- dlls/winspool/wspool.c 2001/02/12 03:51:05 1.3 +++ dlls/winspool/wspool.c 2001/02/26 23:01:57 @@ -5,15 +5,10 @@ * Copyright 1999 Thuy Nguyen */ -#include "commctrl.h" #include "debugtools.h" DEFAULT_DEBUG_CHANNEL(winspool); -HINSTANCE hcomctl32 = 0; -HDPA WINAPI (*WINSPOOL_DPA_CreateEx)(INT, HANDLE); -LPVOID WINAPI (*WINSPOOL_DPA_GetPtr)(const HDPA, INT); -INT WINAPI (*WINSPOOL_DPA_InsertPtr)(const HDPA, INT, LPVOID); /****************************************************************************** * WINSPOOL_EntryPoint @@ -28,16 +23,9 @@ switch (reason) { case DLL_PROCESS_ATTACH: - - hcomctl32 = LoadLibraryA("COMCTL32.DLL"); - - WINSPOOL_DPA_CreateEx = (void*)GetProcAddress(hcomctl32, (LPCSTR)340L); - WINSPOOL_DPA_GetPtr = (void*)GetProcAddress(hcomctl32, (LPCSTR)332L); - WINSPOOL_DPA_InsertPtr = (void*)GetProcAddress(hcomctl32, (LPCSTR)334L); break; case DLL_PROCESS_DETACH: - FreeLibrary(hcomctl32); break; } -- Alexandre Julliard julliard(a)winehq.com

Feb. 26, 2001

Re: winspool.drv initialization problem

by Eric Pouech

Ian Pilcher wrote: > > The saga continues! > > I've gotten my modified version of the PostScript driver to load, but it > seems to causing/exposing another problem. > > WINPROC_GetPtr is being called befor WINPROC_Init during Wine > initialization. The call to WINPROC_GetPtr results from a call to > LoadLibraryExA ("COMCTL32.DLL" ...); here is the stack: basically, before your patch you had: winspool.drv and wineps didn't depend on each others on startup, gdi/gdi32 loads wineps since you added a dep between wineps and winspool.drv, the later also gets called while loading wineps, still in the init of gdi/gdi32 however, the WINPROC_Init should be done in the init of user/user32 as user/user32 depends on gdi/gdi32, it's not called until gdi/gdi32 is initialized... you're stuck solutions may include using delay loading (which only defers when the DLL is actually loaded) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Would it be useful to create such a list, and maybe list > for each of the dlls in there, why there aren't separated yet? Here's a list of the undefined symbols that prevent separation of the remaining dlls (I didn't include user/gdi/kernel to avoid scaring people too much ;-) ./libddraw.so: undefined reference to `DIB_CreateDIBSection' ./libddraw.so: undefined reference to `DIB_GetDIBWidthBytes' ./libddraw.so: undefined reference to `PROFILE_GetWineIniBool' ./libddraw.so: undefined reference to `WIN_FindWndPtr' ./libddraw.so: undefined reference to `WIN_ReleaseWndPtr' ./libddraw.so: undefined reference to `X11DRV_WND_GetXWindow' ./libddraw.so: undefined reference to `display' ./libddraw.so: undefined reference to `root_window' ./libddraw.so: undefined reference to `visual' ./libopengl32.so: undefined reference to `DC_GetDCPtr' ./libopengl32.so: undefined reference to `GDI_ReleaseObj' ./libopengl32.so: undefined reference to `XFONT_GetFontObject' ./libopengl32.so: undefined reference to `display' ./libopengl32.so: undefined reference to `root_window' ./libopengl32.so: undefined reference to `visual' ./libdinput.so: undefined reference to `MOUSE_Enable' ./libdinput.so: undefined reference to `USER_Driver' ./libwinedos.so: undefined reference to `DOSMEM_Available' ./libwinedos.so: undefined reference to `DOSMEM_FreeBlock' ./libwinedos.so: undefined reference to `DOSMEM_GetBlock' ./libwinedos.so: undefined reference to `DOSMEM_Init' ./libwinedos.so: undefined reference to `DOSMEM_MapRealToLinear' ./libwinedos.so: undefined reference to `DOSMEM_wrap_seg' ./libwinedos.so: undefined reference to `EXC_RtlRaiseException' ./libwinedos.so: undefined reference to `FILE_GetUnixHandle' ./libwinedos.so: undefined reference to `INSTR_EmulateInstruction' ./libwinedos.so: undefined reference to `INT_GetRMHandler' ./libwinedos.so: undefined reference to `INT_Int09SendScan' ./libwinedos.so: undefined reference to `INT_Int33Message' ./libwinedos.so: undefined reference to `INT_RealModeInterrupt' ./libwinedos.so: undefined reference to `INT_SetRMHandler' ./libwinedos.so: undefined reference to `VGA_Clean' ./libwinedos.so: undefined reference to `_LeaveWin16Lock' ./libwinedos.so: undefined reference to `full_argv0' ./libwineps.so: undefined reference to `CloseJob16' ./libwineps.so: undefined reference to `DC_GetDCPtr' ./libwineps.so: undefined reference to `DIB_GetBitmapInfo' ./libwineps.so: undefined reference to `DIB_GetDIBWidthBytes' ./libwineps.so: undefined reference to `DRIVER_RegisterDriver' ./libwineps.so: undefined reference to `DRIVER_UnregisterDriver' ./libwineps.so: undefined reference to `DrvGetPrinterData16' ./libwineps.so: undefined reference to `DrvSetPrinterData16' ./libwineps.so: undefined reference to `GDI_GetObjPtr' ./libwineps.so: undefined reference to `GDI_ReleaseObj' ./libwineps.so: undefined reference to `OpenJob16' ./libwineps.so: undefined reference to `PROFILE_EnumWineIniString' ./libwineps.so: undefined reference to `PROFILE_GetWineIniString' ./libwineps.so: undefined reference to `SelectClipRgn16' ./libwineps.so: undefined reference to `WriteSpool16' ./libmcicda.drv.so: undefined reference to `CDROM_Close' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Stop' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetCDStatus' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Play' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetTracksInfo' ./libmcicda.drv.so: undefined reference to `CDROM_CloseDev' ./libmcicda.drv.so: undefined reference to `CDROM_OpenDev' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetSerial' ./libmcicda.drv.so: undefined reference to `CDROM_Open' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetNumberOfTracks' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Pause' ./libmcicda.drv.so: undefined reference to `CDROM_SetDoor' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Seek' ./libws2_32.so: undefined reference to `SERVICE_Delete' ./libws2_32.so: undefined reference to `SERVICE_AddObject' ./libws2_32.so: undefined reference to `FILE_GetUnixHandle' ./libx11drv.so: undefined reference to `BITMAP_Driver' ./libx11drv.so: undefined reference to `BITMAP_GetWidthBytes' ./libx11drv.so: undefined reference to `CLIPBOARD_DeleteRecord' ./libx11drv.so: undefined reference to `CLIPBOARD_EmptyCache' ./libx11drv.so: undefined reference to `CLIPBOARD_GetFormatName' ./libx11drv.so: undefined reference to `CLIPBOARD_IsPresent' ./libx11drv.so: undefined reference to `CLIPBOARD_LookupFormat' ./libx11drv.so: undefined reference to `CLIPBOARD_ReleaseOwner' ./libx11drv.so: undefined reference to `CLIPPING_IntersectVisRect' ./libx11drv.so: undefined reference to `COLOR_IsSolid' ./libx11drv.so: undefined reference to `COLOR_PaletteLookupExactIndex' ./libx11drv.so: undefined reference to `COLOR_PaletteLookupPixel' ./libx11drv.so: undefined reference to `COLOR_gapEnd' ./libx11drv.so: undefined reference to `COLOR_gapFilled' ./libx11drv.so: undefined reference to `COLOR_gapStart' ./libx11drv.so: undefined reference to `COLOR_max' ./libx11drv.so: undefined reference to `COLOR_sysPal' ./libx11drv.so: undefined reference to `COLOR_sysPalTemplate' ./libx11drv.so: undefined reference to `DCE_InvalidateDCE' ./libx11drv.so: undefined reference to `DC_GetDCPtr' ./libx11drv.so: undefined reference to `DC_InitDC' ./libx11drv.so: undefined reference to `DIB_BitmapInfoSize' ./libx11drv.so: undefined reference to `DIB_CreateDIBFromBitmap' ./libx11drv.so: undefined reference to `DIB_GetBitmapInfo' ./libx11drv.so: undefined reference to `DIB_GetDIBImageBytes' ./libx11drv.so: undefined reference to `DIB_GetDIBWidthBytes' ./libx11drv.so: undefined reference to `DRAG_QueryUpdate' ./libx11drv.so: undefined reference to `DRIVER_RegisterDriver' ./libx11drv.so: undefined reference to `DeleteObject16' ./libx11drv.so: undefined reference to `EVENT_Synchronize' ./libx11drv.so: undefined reference to `FILE_DupUnixHandle' ./libx11drv.so: undefined reference to `FONT_LogFontWTo16' ./libx11drv.so: undefined reference to `GDI_AllocObject' ./libx11drv.so: undefined reference to `GDI_GetObjPtr' ./libx11drv.so: undefined reference to `GDI_ReleaseObj' ./libx11drv.so: undefined reference to `GetClipboardData16' ./libx11drv.so: undefined reference to `InputKeyStateTable' ./libx11drv.so: undefined reference to `KEYBOARD_SendEvent' ./libx11drv.so: undefined reference to `NC_IconForWindow' ./libx11drv.so: undefined reference to `Options' ./libx11drv.so: undefined reference to `PALETTE_Driver' ./libx11drv.so: undefined reference to `PROFILE_GetStringItem' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniBool' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniInt' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniString' ./libx11drv.so: undefined reference to `PostMessage16' ./libx11drv.so: undefined reference to `REGION_LPTODP' ./libx11drv.so: undefined reference to `RestoreVisRgn16' ./libx11drv.so: undefined reference to `SELECTOR_AllocBlock' ./libx11drv.so: undefined reference to `SELECTOR_FreeBlock' ./libx11drv.so: undefined reference to `SERVICE_AddObject' ./libx11drv.so: undefined reference to `SERVICE_AddTimer' ./libx11drv.so: undefined reference to `SaveVisRgn16' ./libx11drv.so: undefined reference to `SelectClipRgn16' ./libx11drv.so: undefined reference to `SelectVisRgn16' ./libx11drv.so: undefined reference to `TWEAK_WineLook' ./libx11drv.so: undefined reference to `VIRTUAL_SetFaultHandler' ./libx11drv.so: undefined reference to `WIN_FindWndPtr' ./libx11drv.so: undefined reference to `WIN_GetDesktop' ./libx11drv.so: undefined reference to `WIN_InternalShowOwnedPopups' ./libx11drv.so: undefined reference to `WIN_LinkWindow' ./libx11drv.so: undefined reference to `WIN_LockWndPtr' ./libx11drv.so: undefined reference to `WIN_ReleaseDesktop' ./libx11drv.so: undefined reference to `WIN_ReleaseWndPtr' ./libx11drv.so: undefined reference to `WIN_RestoreWndsLock' ./libx11drv.so: undefined reference to `WIN_SuspendWndsLock' ./libx11drv.so: undefined reference to `WIN_UnlinkWindow' ./libx11drv.so: undefined reference to `WIN_UpdateWndPtr' ./libx11drv.so: undefined reference to `WIN_WindowNeedsWMBorder' ./libx11drv.so: undefined reference to `WND_Driver' ./libx11drv.so: undefined reference to `argv0' ./libx11drv.so: undefined reference to `get_config_dir' ./libx11drv.so: undefined reference to `pKeyStateTable' ./libttydrv.so: undefined reference to `BITMAP_Driver' ./libttydrv.so: undefined reference to `COLOR_gapEnd' ./libttydrv.so: undefined reference to `COLOR_gapStart' ./libttydrv.so: undefined reference to `COLOR_sysPal' ./libttydrv.so: undefined reference to `COLOR_sysPalTemplate' ./libttydrv.so: undefined reference to `DC_GetDCPtr' ./libttydrv.so: undefined reference to `DRIVER_FindDriver' ./libttydrv.so: undefined reference to `DRIVER_RegisterDriver' ./libttydrv.so: undefined reference to `GDI_GetObjPtr' ./libttydrv.so: undefined reference to `GDI_ReleaseObj' ./libttydrv.so: undefined reference to `PALETTE_Driver' ./libttydrv.so: undefined reference to `WND_Driver' -- Alexandre Julliard julliard(a)winehq.com

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Alexandre Julliard

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > So your concern is simply that if it's too simple to lock the mutex, then > you have an unacceptably high probability of a runaway process > accidentally locking the mutex, whereas you regard the probability of the > process accidentally calling AcquireMutex again (or executing the > protected control transfer on its own) as acceptably low. That seems > reasonable. No, that's not my concern. The probability of error doesn't matter at all, I don't mind if the process locks the mutex by accident. What must not be able to happen is that the process somehow corrupts the state as seen from the wineserver or other processes. That is, it doesn't matter if the process thinks it got the mutex when it didn't; but it must not be possible to make the wineserver see two processes holding the mutex, or some other inconsistent state. Any inconsistency must remain local to the process. > Yeah, but that doesn't seem fundamental --- the wineserver can always take > ownership of the mutex itself when it needs to do a complex atomic > operation. I'll let Gavriel work out the details :-). My point is that getting the details right is what is important; and if you are not interested in doing this, then there is no point in arguing any further. -- Alexandre Julliard julliard(a)winehq.com

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by Eric Pouech

> Better yet, how can we tell if a dll is separated? it's separated if it's Makefile.in doesn't contain the IMPORT directive hence, the list of yet to be separated DLLs is: erato:~/wine$ grep IMPORTS dlls/*/*.in dlls/ddraw/Makefile.in:IMPORTS = user32 x11drv gdi32 kernel32 dlls/dinput/Makefile.in:IMPORTS = user32 kernel32 ntdll dlls/gdi/Makefile.in:IMPORTS = kernel32 ntdll dlls/kernel/Makefile.in:IMPORTS = ntdll dlls/opengl32/Makefile.in:IMPORTS = x11drv kernel32 dlls/ttydrv/Makefile.in:IMPORTS = user32 gdi32 kernel32 ntdll dlls/user/Makefile.in:IMPORTS = gdi32 kernel32 ntdll dlls/winedos/Makefile.in:IMPORTS = user32 kernel32 ntdll dlls/wineps/Makefile.in:IMPORTS = user32 gdi32 kernel32 ntdll dlls/winsock/Makefile.in:IMPORTS = user32 kernel32 ntdll dlls/x11drv/Makefile.in:IMPORTS = user32 gdi32 kernel32 A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Alexandre Julliard wrote: > For a mutex the basic definition is obviously that you can never have > two threads holding the mutex at the same time, and that when it is > released some other thread has a chance at grabbing it. This has to be > true no matter what the process does, including corrupting memory or > crashing. ... but not including "process randomly decides to call AcquireMutex again", presumably. So your concern is simply that if it's too simple to lock the mutex, then you have an unacceptably high probability of a runaway process accidentally locking the mutex, whereas you regard the probability of the process accidentally calling AcquireMutex again (or executing the protected control transfer on its own) as acceptably low. That seems reasonable. You can vastly reduce the probability of accidental locking by changing the client_locked field to an int and requiring a specific magic number to be stored there to signal a taken lock. You can vary the magic number per mutex, and store it in your auxiliary per-mutex data structures XORed with some known constant, to ensure that the magic number is never stored anywhere in memory except for the lock field. But if "executes a protected control transfer" is your gold standard of an action that is so unlikely to happen by chance it must be the intended behaviour of the process, then of course no other solution will be acceptable. > You also need to make sure nothing a process does should be > able to crash/hang the wineserver or another process (except if they > fight over the same mutex of course), I think we're there. > and then there is the small > matter of respecting the Win32 semantics... Yeah, but that doesn't seem fundamental --- the wineserver can always take ownership of the mutex itself when it needs to do a complex atomic operation. I'll let Gavriel work out the details :-). Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

Feb. 26, 2001

Re: winspool.drv initialization problem

by Ian Pilcher

Alexandre Julliard wrote: > > Sounds like importing winspool.drv in wineps creates a circular load > dependency (user32->gdi32->wineps->winspool->comctl32->user32). We > could probably be a bit more clever about loading wineps only when > really necessary; OTOH there is no reason for winspool.drv to require > comctl32. Something like this should fix it (completely untested, so > it's probably broken): > It appears to work, based on my admittedly incomplete test -- starting Lotus Notes and printing a document. No more invalid heap error messages. Any idea when Windows loads printer drivers? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by Dimitrie O. Paun

From: "Ove Kaaven" <ovehk(a)ping.uio.no> > I'm not sure if wineps is completely dll-separated yet. BTW, do we have a list of dlls that are not yet dll-separated? (I know, if we had, you'd know about wineps...:) ) Better yet, how can we tell if a dll is separated? Would it be useful to create such a list, and maybe list for each of the dlls in there, why there aren't separated yet? -- Dimi.

Feb. 26, 2001

winspool.drv initialization problem

by Ian Pilcher

The saga continues! I've gotten my modified version of the PostScript driver to load, but it seems to causing/exposing another problem. WINPROC_GetPtr is being called befor WINPROC_Init during Wine initialization. The call to WINPROC_GetPtr results from a call to LoadLibraryExA ("COMCTL32.DLL" ...); here is the stack: #0 HEAP_GetPtr (heap=0) at heap.c:217 #1 0x40093514 in HeapValidate (heap=0, flags=0, block=0x408ffc67) at heap.c:1508 #2 0x4081c93f in WINPROC_GetPtr () from /usr/lib/wine/libuser32.so #3 0x4081cbaa in WINPROC_SetProc () from /usr/lib/wine/libuser32.so #4 0x407e280d in RegisterClassA () from /usr/lib/wine/libuser32.so #5 0x40900058 in ANIMATE_Register () from /usr/lib/wine/libcomctl32.so #6 0x40906412 in COMCTL32_LibMain () from /usr/lib/wine/libcomctl32.so #7 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #8 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #9 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #10 0x4007f364 in LoadLibraryExA () from /usr/lib/wine/libntdll.so #11 0x4007f916 in LoadLibraryA () from /usr/lib/wine/libntdll.so #12 0x40975772 in WINSPOOL_EntryPoint () from /usr/lib/wine/libwinspool.drv.so #13 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #14 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #15 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #16 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #17 0x4007f364 in LoadLibraryExA () from /usr/lib/wine/libntdll.so #18 0x4007f916 in LoadLibraryA () from /usr/lib/wine/libntdll.so #19 0x4087206b in MAIN_GdiInit () from /usr/lib/wine/libgdi32.so #20 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #21 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #22 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #23 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #24 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #25 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #26 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #27 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #28 0x400c758c in start_process () from /usr/lib/wine/libntdll.so #29 0x400caeed in SYSDEPS_DoCallOnStack () from /usr/lib/wine/libntdll.so #30 0x400caf97 in SYSDEPS_CallOnStack () from /usr/lib/wine/libntdll.so #31 0x400cb03a in SYSDEPS_SwitchToThreadStack () from /usr/lib/wine/libntdll.so #32 0x400c79d7 in PROCESS_InitWine () from /usr/lib/wine/libntdll.so #33 0x804b213 in main () #34 0x4027ff55 in __libc_start_main (main=0x804b1f8 <main>, argc=1, ubp_av=0xbffff9d4, init=0x8048728 <_init>, fini=0x804b25c <_fini>, rtld_fini=0x4000e3e4 <_dl_fini>, stack_end=0xbffff9cc) at ../sysdeps/generic/libc-start.c:129 This is way out of my depth! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by Ove Kaaven

On Sun, 25 Feb 2001, Ian Pilcher wrote: > I am trying to modify the Wine PostScript driver to use GetPrinterDataA > to read configuration information from the registry. I have added a > line that reads "import winspool.drv" to wineps.spec, and Wine builds > with no errors. When I try to run Wine, however, I get the following > error: > > BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: > /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA > > Ideas? I'm not sure if wineps is completely dll-separated yet. In any case, there is an IMPORTS = ... line in wineps/Makefile.in that should be added to.

Feb. 26, 2001

Re: Re: undefined symbol: GetPrinterDataA

by Eric Pouech

>wineps : > ># Generated automatically from Makefile.in by configure. >TOPSRCDIR = ../.. >TOPOBJDIR = ../.. >SRCDIR = . >MODULE = wineps >SOVERSION = 1.0 >ALTNAMES = wineps16 >IMPORTS = user32 gdi32 kernel32 ntdll in this case, just add winspool.drv to the IMPORT list in the Makefile.in, rerun configure, and it should work. (If Alexandre didn't convert the Makefile.in for dll separation, there should be some good reasons... like using non exported symbols... which would require much more work) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by gerard patel

At 08:30 PM 25/02/2001 +0600, you wrote: >I am trying to modify the Wine PostScript driver to use GetPrinterDataA >to read configuration information from the registry. I have added a >line that reads "import winspool.drv" to wineps.spec, and Wine builds >with no errors. When I try to run Wine, however, I get the following >error: > > BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: > /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Note the differences between the Makefile for common dialog (where this works) and the Makefile for wineps : commdlg : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = comdlg32 ALTNAMES = commdlg EXTRALIBS = $(LIBUUID) LDDLLFLAGS = -Wl,-Bsymbolic SYMBOLFILE = $(MODULE).tmp.o (...) wineps : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = wineps SOVERSION = 1.0 ALTNAMES = wineps16 IMPORTS = user32 gdi32 kernel32 ntdll C_SRCS = \ (...) I think that the mechanism is not working because dlls separation is not done for wineps ;-) Gerard

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by lawson_whitney＠juno.com

On Mon, 26 Feb 2001 lawson_whitney(a)juno.com wrote: > > > Hmmm, ... from "nm libwinspool.drv.so": > > 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryA > 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryW > 00012f58 D __wine_dllexport_winspool_GetPrinterA > 00012f58 D __wine_dllexport_winspool_GetPrinterDataA > 00012f58 D __wine_dllexport_winspool_GetPrinterDataExA > 00012f58 D __wine_dllexport_winspool_GetPrinterDataExW > 00012f58 D __wine_dllexport_winspool_GetPrinterDataW > > Try: > > import winspool > > instead of winspool.drv, and see if that helps. Just a guess. > Nope, that doesn't work. However, I can import winspool.drv to a winelib program, and GetPrinterDataA resolves to a stub in the spec.o file. Lawson | We apologize if this message has reached you in error. | Save the Planet, Save the Trees! Advertise via E mail. ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

Feb. 26, 2001

Re: various config files for various applications

by Eric Pouech

Martin Pilka wrote: > > Alexandre Julliard wrote: > > This is getting way too complex IMO. I think having everything in the > > .wine/config file is much more reasonable; most people don't need that > > many different configurations anyway. > > > > What we should do is take advantage of the new config file format to > > create a deeper configuration hierarchy. So for instance the default > > x11drv config is under the registry key Wine\Config\x11drv, but we > > could create subtrees like Wine\Config\AppDefaults\Solitaire\x11drv > > which would contain the Solitaire-specific config values. This is then > > very fast to lookup, just try AppDefaults\<current module> and if not > > found fall back to the current method. I don't think we need regular > > expressions at all. > > attached is the patch. i wasn't always sure i'm doing the things in the > right way, so you guys can have a look before i make the real submit. > > here are some explanations: > > 1) i think we shouldn't access the wine configuration directly through > registry, but use the PROFILE_ functions instead. in addition - now, > when we're trying to do some kind of redirection, it's absolutely > necessary. all the parts with direct access were rewritten. I don't think we need to export the PROFILE functions... just let the calling code check the keys under "<appname>/key" if it exists and then fallback to simply "key" if it doesn't > 3) i wasn't able to find out the name of windows application we're just > executing. that's why i added the win_app_exe_name variable into > misc/options.c. GetModuleFileName(NULL, buffer, sizeof(buffer)); should do... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by lawson_whitney＠juno.com

On Sun, 25 Feb 2001, Ian Pilcher wrote: > > If only it were that simple. I've rebuilt from scratch, with a clean > source tree. > Hmmm, ... from "nm libwinspool.drv.so": 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryA 00012f58 D __wine_dllexport_winspool_GetPrintProcessorDirectoryW 00012f58 D __wine_dllexport_winspool_GetPrinterA 00012f58 D __wine_dllexport_winspool_GetPrinterDataA 00012f58 D __wine_dllexport_winspool_GetPrinterDataExA 00012f58 D __wine_dllexport_winspool_GetPrinterDataExW 00012f58 D __wine_dllexport_winspool_GetPrinterDataW Try: import winspool instead of winspool.drv, and see if that helps. Just a guess. Lawson By the accident of what statisticians call birth... - Richard Fariña ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by Ian Pilcher

Eric Pouech wrote: > > in this case, just add winspool.drv to the IMPORT list in the > Makefile.in, rerun configure, and it should work. That did the trick. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Alexandre Julliard

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > Of course it has to be 100% reliable, but since you're dealing with > failing processes it's not 100% clear what 100% reliability is. Anyway, I > think 100% reliability is possible for any plausible definition. For a mutex the basic definition is obviously that you can never have two threads holding the mutex at the same time, and that when it is released some other thread has a chance at grabbing it. This has to be true no matter what the process does, including corrupting memory or crashing. You also need to make sure nothing a process does should be able to crash/hang the wineserver or another process (except if they fight over the same mutex of course), and then there is the small matter of respecting the Win32 semantics... Actually it is the last constraint that is the main problem. You can certainly provide some kind of mutexes using shared memory; but we don't need just 'some kind', we need Win32 mutexes. This means a mutex is identified by a handle that can be manipulated by CloseHandle or DuplicateHandle; it means you need to detect and handle abandoned mutexes; it means you must support WaitForMultipleObjects, including the 'all' case where you cannot grab the mutex unless all objects are signaled; all things that I didn't see in your implementation ;-) -- Alexandre Julliard julliard(a)winehq.com

Feb. 26, 2001

Re: undefined symbol: GetPrinterDataA

by lawson_whitney＠juno.com

On Sun, 25 Feb 2001, Ian Pilcher wrote: > I am trying to modify the Wine PostScript driver to use GetPrinterDataA > to read configuration information from the registry. I have added a > line that reads "import winspool.drv" to wineps.spec, and Wine builds > with no errors. When I try to run Wine, however, I get the following > error: > > BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: > /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA > > Ideas? > -- > ======================================================================== > Ian Pilcher pilcher(a)concentric.net > ======================================================================== I think maybe you have created a new dependency and need to run make depend again? If I understand the import mechanism, something (winebuild?) generates stubs for the functions you import and ties them in to the import mechanism, so they shouldn't be left hanging for ld.so to choke on. They should resolve to .spec.o. It looks to me as if the .spec didin't get rebuilt. Maybe a make clean and a make would do better and quicker for now than make depend. or rm wineps.spec.* *.o and try make again. Lawson All's well that ends. - Ben Franklin ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Alexandre Julliard wrote: > Imagine a process that does a SuspendThread() on one of its threads, > but makes sure by some kind of internal protocol that the thread is > never holding the mutex when it is suspended. This would work just > fine under Windows or under the wineserver, but would fail with the > shared memory approach. Actually, if you use a per-client shared memory block, then the wineserver can execute ownership changes itself, without any cooperation from the client, whenever the client does not actually have the mutex locked. Your problem goes away. > There is simply no point in implementing a mutex that works only 99% > of the time, no matter how fast it is. The synchronization objects > have to be 100% reliable, performance only comes next; and none of the > shared memory approaches I've seen so far are 100% reliable. Of course it has to be 100% reliable, but since you're dealing with failing processes it's not 100% clear what 100% reliability is. Anyway, I think 100% reliability is possible for any plausible definition. The following protocol looks good for the simpler one-thread-per-client-process case. It easily generalizes to the multiple threads per process case by treating each thread as a separate process, except then threads can stomp on their sibling threads' mutexes, but this is not new. (You could probably build an optimized version of the protocol for the multithread case, though.) // indices identify the client. Client i can only access variables // indexed by i, the wineserver can access all bool client_locked[N]; bool client_is_owner[N]; bool notify_wineserver_on_release[N]; // client Acquire(i) { retry: atomically { if (client_is_owner[i] && !client_locked[i]) { client_locked[i] = true; return; } } if (!client_is_owner[i]) { wineserver->GiveThisProcessOwnership(i); // blocking goto retry; } else if (client_locked[i]) { // fail; deadlocked } } Release(i) { int notify; atomically { notify = notify_wineserver_on_release[i]; client_locked = false; notify_wineserver_on_release[i] = false; } if (notify) { wineserver->NotifyUnlocked(); // nonblocking } } // wineserver int true_owner; bool requested_ownership[N]; GiveThisProcessOwnership(i) { if (true_owner != i) { bool granted; atomically { // take lock from owner if we can if (!client_locked[true_owner]) { client_is_owner[true_owner] = false; granted = true; } else { notify_wineserver_on_release[i] = true; granted = false; } } if (granted) { // give lock to the requester true_owner = i; atomically { if (client_locked[true_owner]) { // process is corrupt, it can't have the lock already } else { client_is_owner[true_owner] = true; } } ReplyToProcess(i); // nonblocking } else { // let the requester wait requested_ownership[i] = true; } } } NotifyUnlocked() { for (i = 0; i < N; i++) { if (requested_ownership[i]) break; } if (i == N) return; // no-one cares bool granted; atomically { // try to get lock from owner, as above if (!client_locked[true_owner]) { client_is_owner[true_owner] = false; granted = true; } else { notify_wineserver_on_release[true_owner] = true; granted = false; } } if (granted) { // give lock bool notify = false; true_owner = i; requested_ownership[i] = false; for (i = 0; i < N; i++) { if (requested_ownership[i]) notify = true; } atomically { if (client_locked[true_owner]) { // process is corrupt, it can't have the lock already } else { client_is_owner[true_owner] = true; notify_wineserver_on_release[true_owner] = notify; } } ReplyToProcess(i); // nonblocking } } Pack the client_locked and client_is_owner variables into a single word per client. Implement "atomically" with atomic compare-and-swap. There's no wineserver to client signalling (except for unblocking the client's blocking call). The wineserver never blocks. The wineserver never reads any values from client_is_owner or notify_wineserver_on_release. It only ever reads the client_locked value for the true_owner process. The only vulnerability that I can see is if a client process unlocks the mutex and then a unlucky stray write due to some bug subsequently writes 'true' to its client_locked field. Is that a significant increase in risk over the client simply hanging while it has the mutex locked? NB there may well be bugs in the above code. This kind of code is hard to get right. (Someone who knows how to drive a model checking tool could verify it without much difficulty, though.) If no-one needed fast mutexes it definitely wouldn't be worth doing. I'm advocating this just because a) someone does need them and b) I can't let the claim "it can't be done 100% safely this way" go unchallenged :-). Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Michael McCormack

Two things: 1. How about expiring client's unix file descriptors by having wineserver writing a single non-zero byte[*] to the server-communication socket when another client modifies the fd? The code to validate fds before use could then be reduced from a server call to a single nonwaiting poll on NtCurrentTeb()->reply_fd. 2. How about using pipes to implement critical sections? InitCriticalSection would create a pipe and write one byte, EnterCritical section would do a poll on the pipe, followed by a read of one byte, and leave critical section would write one byte back to the pipe. [*] wineserver would write a zero byte when it wished to restart a client after a server call, and the client would need to check this. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+82 11 430 0425)

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Michael McCormack

Two things: 1. How about expiring client's unix file descriptors by having wineserver writing a single non-zero byte[*] to the server-communication socket when another client modifies the fd? The code to validate fds before use could then be reduced from a server call to a single nonwaiting poll on NtCurrentTeb()->reply_fd. 2. How about using pipes to implement critical sections? InitCriticalSection would create a pipe and write one byte, EnterCritical section would do a poll on the pipe, followed by a read of one byte, and leave critical section would write one byte back to the pipe. [*] wineserver would write a zero byte when it wished to restart a client after a server call, and the client would need to check this. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+612) 9690 5305

Feb. 26, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Alexandre Julliard

Gavriel State <gav(a)transgaming.com> writes: > Even without that approach though, I don't think that the new failure mode > is really likely to be that big a deal. If process A owns a mutex that process > B wants, they quite likely have some functional interdependance which would be > disrupted as much by any generic hang in process A as by a hang followed by > a failure to release the mutex. Imagine a process that does a SuspendThread() on one of its threads, but makes sure by some kind of internal protocol that the thread is never holding the mutex when it is suspended. This would work just fine under Windows or under the wineserver, but would fail with the shared memory approach. There is simply no point in implementing a mutex that works only 99% of the time, no matter how fast it is. The synchronization objects have to be 100% reliable, performance only comes next; and none of the shared memory approaches I've seen so far are 100% reliable. In fact the original implementation of the kernel objects was based on shared memory and signals. A lot of time was spent trying to make this work right, but it was simply not possible without assuming that all processes will always follow the protocol correctly, which is clearly not something we can assume when running arbitrary Windows code. -- Alexandre Julliard julliard(a)winehq.com

Feb. 25, 2001

Re: undefined symbol: GetPrinterDataA

by Ian Pilcher

lawson_whitney(a)juno.com wrote: > > Try: > > import winspool > > instead of winspool.drv, and see if that helps. Just a guess. > Nope. winebuild complains that it "could not open .so file for winspool". I've uncovered a couple of additional facts which (I hope) may shed some light on the situation. I whipped up a quick Winelib program which calls GetPrinterDataA, and it runs just fine -- using a previous, working, Wine build. I tried commenting out the calls to GetPrinterDataA, and Wine now complains that OpenPrinterA is an undefined symbol. So the problem seems to affect multiple functions in winspool.drv, but it doesn't affect Winelib programs. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 25, 2001

Re: undefined symbol: GetPrinterDataA

by Ian Pilcher

lawson_whitney(a)juno.com wrote: > > I think maybe you have created a new dependency and need to run make > depend again? If I understand the import mechanism, something > (winebuild?) generates stubs for the functions you import and ties them > in to the import mechanism, so they shouldn't be left hanging for ld.so > to choke on. They should resolve to .spec.o. It looks to me as if the > .spec didin't get rebuilt. > If only it were that simple. I've rebuilt from scratch, with a clean source tree. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 25, 2001

Re: [PATCH] 16 bits print dialog

by Dmitry Timoshkov

"gerard patel" <gerard.patel(a)asi.fr> wrote: > As it's rather unlikely anyone will craft 16 bits specific resources now, I have > mapped the 32 bits resource into 16 bit ones > I did not test if 16 bits printing still works, but the print dialog box displays again > at least. > There is also a minor fix to cast the return value for the 16 bits hook to 16 bits. > > ChangeLog: > > * dlls/commdlg/printdlg.c > maps 32 bits resource for 16 bits print dialog. Gerard, your patch is fine, but I have one tiny comment: in Win32 hInstance and hModule are the same thing, unlike in Win16. So, instead of GetModuleHandleA("COMDLG32") you can safely use COMMDLG_hInstance32.

Feb. 25, 2001

undefined symbol: GetPrinterDataA

by Ian Pilcher

I am trying to modify the Wine PostScript driver to use GetPrinterDataA to read configuration information from the registry. I have added a line that reads "import winspool.drv" to wineps.spec, and Wine builds with no errors. When I try to run Wine, however, I get the following error: BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Ideas? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 25, 2001

Re: various config files for various applications

by Martin Pilka

Alexandre Julliard wrote: > This is getting way too complex IMO. I think having everything in the > .wine/config file is much more reasonable; most people don't need that > many different configurations anyway. > > What we should do is take advantage of the new config file format to > create a deeper configuration hierarchy. So for instance the default > x11drv config is under the registry key Wine\Config\x11drv, but we > could create subtrees like Wine\Config\AppDefaults\Solitaire\x11drv > which would contain the Solitaire-specific config values. This is then > very fast to lookup, just try AppDefaults\<current module> and if not > found fall back to the current method. I don't think we need regular > expressions at all. attached is the patch. i wasn't always sure i'm doing the things in the right way, so you guys can have a look before i make the real submit. here are some explanations: 1) i think we shouldn't access the wine configuration directly through registry, but use the PROFILE_ functions instead. in addition - now, when we're trying to do some kind of redirection, it's absolutely necessary. all the parts with direct access were rewritten. 2) in case of winaspi/winaspi16.c, dlls/shell32/shelllink.c and winmm/mci.c there weren't the PROFILE_ functions linked in, so i added them with "IMPORTS = ntdll" option in Makefile. i'm really not sure if it's a right way. 3) i wasn't able to find out the name of windows application we're just executing. that's why i added the win_app_exe_name variable into misc/options.c. the application specific profile is in Software\\Wine\\Wine\\Config\\AppProfile\\file_name.exe section. if some subsection is found (let's say x11drv), then that and only that subsection is used. if it's not found it just fall back to the current method. martin Index: wine/dlls/shell32/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/shell32/Makefile.in,v retrieving revision 1.41 diff -u -r1.41 Makefile.in --- wine/dlls/shell32/Makefile.in 2001/02/23 01:12:26 1.41 +++ wine/dlls/shell32/Makefile.in 2001/02/25 14:19:14 @@ -6,6 +6,8 @@ ALTNAMES = shell EXTRALIBS = $(LIBUUID) $(LIBUNICODE) +IMPORTS = ntdll + LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: wine/dlls/shell32/shelllink.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shelllink.c,v retrieving revision 1.33 diff -u -r1.33 shelllink.c --- wine/dlls/shell32/shelllink.c 2001/02/12 01:17:39 1.33 +++ wine/dlls/shell32/shelllink.c 2001/02/25 14:19:17 @@ -29,6 +29,7 @@ #include "pidl.h" #include "shell32_main.h" #include "shlguid.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(shell); @@ -522,7 +523,6 @@ char *path_name = NULL; char *work_dir = NULL; BOOL bDesktop; - HKEY hkey; _ICOM_THIS_From_IPersistFile(IShellLinkImpl, iface); @@ -538,13 +538,7 @@ /* check if ShellLinker configured */ buffer[0] = 0; - if (!RegOpenKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\Wine", - 0, KEY_ALL_ACCESS, &hkey )) - { - DWORD type, count = sizeof(buffer); - if (RegQueryValueExA( hkey, "ShellLinker", 0, &type, buffer, &count )) buffer[0] = 0; - RegCloseKey( hkey ); - } + PROFILE_GetWineIniString("wine","ShellLinker","",buffer,sizeof(buffer)); if (!*buffer) return NOERROR; shell_link_app = HEAP_strdupA( GetProcessHeap(), 0, buffer ); Index: wine/dlls/user/user_main.c =================================================================== RCS file: /home/wine/wine/dlls/user/user_main.c,v retrieving revision 1.14 diff -u -r1.14 user_main.c --- wine/dlls/user/user_main.c 2001/01/22 02:17:29 1.14 +++ wine/dlls/user/user_main.c 2001/02/25 14:19:18 @@ -23,6 +23,7 @@ #include "user.h" #include "win.h" #include "debugtools.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(graphics); @@ -40,20 +41,8 @@ static BOOL load_driver(void) { char buffer[MAX_PATH]; - HKEY hkey; - DWORD type, count; - if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\Wine", 0, NULL, - REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL )) - { - MESSAGE("load_driver: Cannot create config registry key\n" ); - return FALSE; - } - count = sizeof(buffer); - if (RegQueryValueExA( hkey, "GraphicsDriver", 0, &type, buffer, &count )) - strcpy( buffer, "x11drv" ); /* default value */ - RegCloseKey( hkey ); - + PROFILE_GetWineIniString("Wine","GraphicsDriver","x11drv",buffer,sizeof(buffer)); if (!(graphics_driver = LoadLibraryA( buffer ))) { MESSAGE( "Could not load graphics driver '%s'\n", buffer ); @@ -160,15 +149,8 @@ { static const char *OS = "Win3.1"; char buffer[80]; - HKEY hkey; - DWORD type, count = sizeof(buffer); - if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\Tweak.Layout", 0, NULL, - REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL )) - return; - if (RegQueryValueExA( hkey, "WineLook", 0, &type, buffer, &count )) - strcpy( buffer, "Win31" ); /* default value */ - RegCloseKey( hkey ); + PROFILE_GetWineIniString("Tweak.Layout","WineLook","Win31",buffer,sizeof(buffer)); /* WIN31_LOOK is default */ if (!strncasecmp( buffer, "Win95", 5 )) Index: wine/dlls/winaspi/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/winaspi/Makefile.in,v retrieving revision 1.11 diff -u -r1.11 Makefile.in --- wine/dlls/winaspi/Makefile.in 2000/11/30 01:17:55 1.11 +++ wine/dlls/winaspi/Makefile.in 2001/02/25 14:19:18 @@ -4,6 +4,7 @@ VPATH = @srcdir@ MODULE = wnaspi32 ALTNAMES = winaspi +IMPORTS = ntdll LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: wine/dlls/winaspi/winaspi16.c =================================================================== RCS file: /home/wine/wine/dlls/winaspi/winaspi16.c,v retrieving revision 1.25 diff -u -r1.25 winaspi16.c --- wine/dlls/winaspi/winaspi16.c 2000/12/13 20:20:14 1.25 +++ wine/dlls/winaspi/winaspi16.c 2001/02/25 14:19:20 @@ -19,6 +19,7 @@ #include "heap.h" #include "debugtools.h" #include "miscemu.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(aspi); @@ -43,7 +44,6 @@ static int ASPI_OpenDevice16(SRB_ExecSCSICmd16 *prb) { - HKEY hkey; int fd; char idstr[50]; char device_str[50]; @@ -63,17 +63,9 @@ } /* device wasn't cached, go ahead and open it */ - sprintf( idstr, "Software\\Wine\\Wine\\Config\\scsi c%1dt%1dd%1d", - prb->SRB_HaId, prb->SRB_Target, prb->SRB_Lun); + sprintf( idstr, "scsi c%1dt%1dd%1d", prb->SRB_HaId, prb->SRB_Target, prb->SRB_Lun); - device_str[0] = 0; - if (!RegOpenKeyExA( HKEY_LOCAL_MACHINE, idstr, 0, KEY_ALL_ACCESS, &hkey )) - { - DWORD type, count = sizeof(device_str); - if (RegQueryValueExA( hkey, "Device", 0, &type, device_str, &count )) device_str[0] = 0; - RegCloseKey( hkey ); - } - + PROFILE_GetWineIniString(idstr,"Device","",device_str,sizeof(device_str)); if (!device_str[0]) { TRACE("Trying to open unlisted scsi device %s\n", idstr); Index: wine/dlls/winmm/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/winmm/Makefile.in,v retrieving revision 1.19 diff -u -r1.19 Makefile.in --- wine/dlls/winmm/Makefile.in 2001/01/13 01:01:00 1.19 +++ wine/dlls/winmm/Makefile.in 2001/02/25 14:19:20 @@ -8,6 +8,8 @@ LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o +IMPORTS = ntdll + C_SRCS = \ driver.c \ joystick.c \ Index: wine/dlls/winmm/mci.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/mci.c,v retrieving revision 1.17 diff -u -r1.17 mci.c --- wine/dlls/winmm/mci.c 2001/01/28 23:11:27 1.17 +++ wine/dlls/winmm/mci.c 2001/02/25 14:19:25 @@ -19,6 +19,7 @@ #include "wine/winbase16.h" #include "debugtools.h" #include "winreg.h" +#include "options.h" DEFAULT_DEBUG_CHANNEL(mci); @@ -2601,10 +2602,6 @@ BOOL MULTIMEDIA_MciInit(void) { LPSTR ptr1, ptr2; - HKEY hWineConf; - HKEY hkey; - DWORD err; - DWORD type; DWORD count = 2048; MCI_InstalledCount = 0; @@ -2613,14 +2610,8 @@ if (!MCI_lpInstallNames) return FALSE; - /* FIXME: should do also some registry diving here ? */ - if (!(err = RegOpenKeyA(HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config", &hWineConf)) && - !(err = RegOpenKeyA(hWineConf, "options", &hkey))) { - err = RegQueryValueExA(hkey, "mci", 0, &type, MCI_lpInstallNames, &count); - RegCloseKey(hkey); - - } - if (!err) { + PROFILE_GetWineIniString("Options","mci","",MCI_lpInstallNames,count); + if (*MCI_lpInstallNames) { TRACE("Wine => '%s' \n", ptr1); while ((ptr2 = strchr(ptr1, ':')) != 0) { *ptr2++ = 0; @@ -2639,7 +2630,6 @@ MCI_InstalledCount++; } } - RegCloseKey(hWineConf); return TRUE; } Index: wine/dlls/x11drv/x11drv_main.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.29 diff -u -r1.29 x11drv_main.c --- wine/dlls/x11drv/x11drv_main.c 2001/02/14 00:27:35 1.29 +++ wine/dlls/x11drv/x11drv_main.c 2001/02/25 14:19:34 @@ -134,20 +134,10 @@ static void setup_options(void) { char buffer[256]; - HKEY hkey; - DWORD type, count; - if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\x11drv", 0, NULL, - REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL )) - { - ERR("Cannot create config registry key\n" ); - ExitProcess(1); - } - /* --display option */ - - count = sizeof(buffer); - if (!RegQueryValueExA( hkey, "display", 0, &type, buffer, &count )) + PROFILE_GetWineIniString("x11drv","display","",buffer,sizeof(buffer)); + if (*buffer) { if (Options.display) { @@ -168,7 +158,7 @@ MESSAGE( "%s: no display specified\n", argv0 ); ExitProcess(1); } - RegSetValueExA( hkey, "display", 0, REG_SZ, Options.display, strlen(Options.display)+1 ); + PROFILE_SetWineIniString("x11drv","display",Options.display); } /* check and set --managed and --desktop options in wine config file @@ -176,26 +166,20 @@ if ((!Options.managed) && (Options.desktopGeometry == NULL)) { - count = sizeof(buffer); - if (!RegQueryValueExA( hkey, "managed", 0, &type, buffer, &count )) - Options.managed = IS_OPTION_TRUE( buffer[0] ); - - count = sizeof(buffer); - if (!RegQueryValueExA( hkey, "Desktop", 0, &type, buffer, &count )) - /* Imperfect validation: If Desktop=N, then we don't turn on - ** the --desktop option. We should really validate for a correct - ** sizing entry */ - if (! IS_OPTION_FALSE(buffer[0])) - Options.desktopGeometry = strdup(buffer); + int bool; + + bool = PROFILE_GetWineIniBool("x11drv","managed",2); + if (bool != 2) Options.managed = bool; + + /* Imperfect validation: If Desktop=N, then we don't turn on + ** the --desktop option. We should really validate for a correct + ** sizing entry */ + PROFILE_GetWineIniString("x11drv","Desktop","",buffer,sizeof(buffer)); + if (!IS_OPTION_FALSE(*buffer)) Options.desktopGeometry = strdup(buffer); } - - if (Options.managed) - RegSetValueExA( hkey, "managed", 0, REG_SZ, "y", 2 ); - if (Options.desktopGeometry) - RegSetValueExA( hkey, "desktop", 0, REG_SZ, Options.desktopGeometry, strlen(Options.desktopGeometry)+1 ); - - RegCloseKey( hkey ); + if (Options.managed) PROFILE_SetWineIniString("x11drv","managed","y"); + if (Options.desktopGeometry) PROFILE_SetWineIniString("x11drv","desktop",Options.desktopGeometry); } Index: wine/files/profile.c =================================================================== RCS file: /home/wine/wine/files/profile.c,v retrieving revision 1.46 diff -u -r1.46 profile.c --- wine/files/profile.c 2001/01/22 19:27:06 1.46 +++ wine/files/profile.c 2001/02/25 14:19:36 @@ -62,9 +62,12 @@ #define CurProfile (MRUProfile[0]) -/* wine.ini config file registry root */ +/* wine config registry root */ static HKEY wine_profile_key; +/* app config registry root */ +static HKEY wine_app_profile_key; + #define PROFILE_MAX_LINE_LEN 1024 /* Wine profile name in $HOME directory; must begin with slash */ @@ -939,7 +942,7 @@ /*********************************************************************** * PROFILE_GetWineIniString * - * Get a config string from the wine.ini file. + * Get a config string from the registry */ int PROFILE_GetWineIniString( const char *section, const char *key_name, const char *def, char *buffer, int len ) @@ -948,7 +951,8 @@ HKEY hkey; DWORD err; - if (!(err = RegOpenKeyA( wine_profile_key, section, &hkey ))) + if (!(err = RegOpenKeyA( wine_app_profile_key, section, &hkey )) || + !(err = RegOpenKeyA( wine_profile_key, section, &hkey ))) { DWORD type; DWORD count = sizeof(tmp); @@ -960,6 +964,32 @@ return strlen(buffer); } +/*********************************************************************** + * PROFILE_SetWineIniString + * + * Set a config string to the registry + */ +BOOL PROFILE_SetWineIniString( const char *section, const char *key_name, const char *value) +{ + HKEY hkey; + + TRACE( "('%s','%s','%s')\n", section, key_name, value ); + + if (!(RegOpenKeyA( wine_app_profile_key, section, &hkey )) || + !(RegCreateKeyA( wine_profile_key, section, &hkey ))) { + if (RegSetValueExA( hkey, key_name, 0, REG_SZ, value, strlen(value)+1 )) { + TRACE("unable to set value.\n"); + RegCloseKey( hkey ); + return FALSE; + } + } else { + TRACE( "unable to open key.\n"); + return FALSE; + } + + RegCloseKey( hkey ); + return TRUE; +} /*********************************************************************** * PROFILE_EnumWineIniString @@ -1080,10 +1110,20 @@ return 0; } RegCloseKey( hKeySW ); + if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config", 0, NULL, REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &wine_profile_key, &disp )) { ERR("Cannot create config registry key\n" ); + return 0; + } + + strcpy( buffer, "AppProfile\\" ); + strncat( buffer, win_app_exe_name, MAX_PATHNAME_LEN-strlen(buffer) ); + if (RegCreateKeyExA( wine_profile_key, buffer, 0, NULL, + REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &wine_app_profile_key, NULL )) + { + ERR("Cannot create app config registry key\n" ); return 0; } Index: wine/include/options.h =================================================================== RCS file: /home/wine/wine/include/options.h,v retrieving revision 1.31 diff -u -r1.31 options.h --- wine/include/options.h 2001/01/10 23:56:59 1.31 +++ wine/include/options.h 2001/02/25 14:19:36 @@ -21,6 +21,7 @@ extern struct options Options; extern const char *argv0; extern const char *full_argv0; +extern const char *win_app_exe_name; /* name of the main windows executable */ extern unsigned int server_startticks; extern void OPTIONS_Usage(void) WINE_NORETURN; @@ -32,6 +33,8 @@ extern void PROFILE_UsageWineIni(void); extern int PROFILE_GetWineIniString( const char *section, const char *key_name, const char *def, char *buffer, int len ); +extern BOOL PROFILE_SetWineIniString( const char *section, const char *key_name, + const char *value); extern BOOL PROFILE_EnumWineIniString( const char *section, int index, char *name, int name_len, char *buffer, int len ); extern int PROFILE_GetWineIniInt( const char *section, const char *key_name, int def ); Index: wine/misc/options.c =================================================================== RCS file: /home/wine/wine/misc/options.c,v retrieving revision 1.24 diff -u -r1.24 options.c --- wine/misc/options.c 2001/02/12 03:47:11 1.24 +++ wine/misc/options.c 2001/02/25 14:19:36 @@ -36,8 +36,9 @@ FALSE /* Managed windows */ }; -const char *argv0; /* the original argv[0] */ -const char *full_argv0; /* the full path of argv[0] (if known) */ +const char *argv0; /* the original argv[0] */ +const char *full_argv0; /* the full path of argv[0] (if known) */ +const char *win_app_exe_name; /* name of the main windows executable */ static char *inherit_str; /* options to pass to child processes */ @@ -377,6 +378,7 @@ { char buffer[1024]; int i; + char *tmp; if (GetEnvironmentVariableA( "WINEOPTIONS", buffer, sizeof(buffer) ) && buffer[0]) inherit_options( buffer ); @@ -404,6 +406,12 @@ app_argv = argv; app_argc = 0; while (argv[app_argc]) app_argc++; + + /* store the win app executable name */ + tmp = argv[1] + strlen(argv[1]); + while ( (tmp > argv[1]) && (*tmp != '/') && (*tmp != '\\') ) tmp--; + if ( (*tmp == '/') || (*tmp == '\\') ) tmp++; + win_app_exe_name = strdup(tmp); }

Feb. 25, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Gavriel State

Ove Kaaven wrote: > > On Sat, 24 Feb 2001, Robert O'Callahan wrote: > > > Ove Kaaven wrote: > > > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > > > Then on some other thread in the same address space > > > > that serves wineserver requests: > > > > > > There's no such thread, and will never be such a thread (having the > > > wineserver calling into client threads is an inherently unstable > > > design). > > > > The wineserver need not depend on the client thread responding to its > > (asynchronous) messages. In this case, if the client ignores the > > messages, you get the same effect as if it never releases its mutex, > > which is not a new failure mode. > > Sure it is, if the process isn't holding the mutex. Your design lets a > process own the mutex without holding it. So if a process acquires it, > then releases it, does something else for 10 minutes and then hangs, and > some other process decides it should grab the mutex, then it should be > allowed to do so, since the original process isn't holding it. But it > can't... Rather than have a dedicated thread to maintain any such communication back and forth with the server, why not simply use a signal to the first thread in the process. The signal should execute regardless of whether or not the thread is hung, and if the mutex is 'owned' by the process, but not currently 'held', the signal handler releases the mutex, and marks it as no longer owned. Even without that approach though, I don't think that the new failure mode is really likely to be that big a deal. If process A owns a mutex that process B wants, they quite likely have some functional interdependance which would be disrupted as much by any generic hang in process A as by a hang followed by a failure to release the mutex. And besides, once the user kills the hung process, the server should be able to reclaim the shared mutex object anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

Feb. 25, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Joerg Mayer

Ove, On Sat, Feb 24, 2001 at 12:06:07PM +0100, Ove Kaaven wrote: > There's no such thread, and will never be such a thread (having the > wineserver calling into client threads is an inherently unstable design). I think I've read this before, when the topic was FindWindow. IIRC that thread never came to any conlusion/solution. Will the same happen to this topic too? If it looks like these problems could be solved by some sort of server calling into the client then why not do this until someone finds a better solution? On the other hand, if this mechanism doesn't work on a technical basis, that is something I can live with. "inherently unsable design" could be both: People simply not liking the idea of this and the corresponding design implications or it could be just another variant of "it won't work any better than the solution proposed so far". Which one is it? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Feb. 25, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Ove Kaaven wrote: > On Sat, 24 Feb 2001, Robert O'Callahan wrote: > > Ove Kaaven wrote: > > > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > > > Then on some other thread in the same address space > > > > that serves wineserver requests: > > > > > > There's no such thread, and will never be such a thread (having the > > > wineserver calling into client threads is an inherently unstable > > > design). > > > > The wineserver need not depend on the client thread responding to its > > (asynchronous) messages. In this case, if the client ignores the > > messages, you get the same effect as if it never releases its mutex, > > which is not a new failure mode. > > Sure it is, if the process isn't holding the mutex. Your design lets a > process own the mutex without holding it. So if a process acquires it, > then releases it, does something else for 10 minutes and then hangs, and > some other process decides it should grab the mutex, then it should be > allowed to do so, since the original process isn't holding it. But it > can't... I call that "not a new failure mode" because it's the same behavior as if the faulty client process had a bug that caused it to fail to release the mutex in the first place. If you want a more restricted fault model, you can limit the vulnerability window by having the client periodically poll for owned-but-unlocked mutexes and release them to the wineserver. > > Actually there is another design that doesn't need a per-client > > thread. Instead it uses a per-client memory block shared between the > > client and the wineserver. > > Alexandre already shot down the shared-memory solution, especially > disliking solutions that force the wineserver out of its single-threaded > model, like making it do locking and atomic operations for itself. You can do it all with non-blocking operations. The shared memory solution previously proposed had the disastrous property that a misbehaving client process could interfere with mutexes owned by other processes. It doesn't have to be that way if you use a separate shared memory block per client. This could be extended to other shared resources too. But I could believe that it is too complicated to be worth doing. Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

Feb. 24, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Ove Kaaven

On Sat, 24 Feb 2001, Robert O'Callahan wrote: > Ove Kaaven wrote: > > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > > Then on some other thread in the same address space > > > that serves wineserver requests: > > > > There's no such thread, and will never be such a thread (having the > > wineserver calling into client threads is an inherently unstable > > design). > > The wineserver need not depend on the client thread responding to its > (asynchronous) messages. In this case, if the client ignores the > messages, you get the same effect as if it never releases its mutex, > which is not a new failure mode. Sure it is, if the process isn't holding the mutex. Your design lets a process own the mutex without holding it. So if a process acquires it, then releases it, does something else for 10 minutes and then hangs, and some other process decides it should grab the mutex, then it should be allowed to do so, since the original process isn't holding it. But it can't... > Actually there is another design that doesn't need a per-client thread. > Instead it uses a per-client memory block shared between the client and > the wineserver. Alexandre already shot down the shared-memory solution, especially disliking solutions that force the wineserver out of its single-threaded model, like making it do locking and atomic operations for itself.

Feb. 24, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

Ove Kaaven wrote: > On Thu, 22 Feb 2001, Robert O'Callahan wrote: > > Then on some other thread in the same address space > > that serves wineserver requests: > > There's no such thread, and will never be such a thread (having the > wineserver calling into client threads is an inherently unstable > design). The wineserver need not depend on the client thread responding to its (asynchronous) messages. In this case, if the client ignores the messages, you get the same effect as if it never releases its mutex, which is not a new failure mode. Actually there is another design that doesn't need a per-client thread. Instead it uses a per-client memory block shared between the client and the wineserver. This memory block holds the lock associated with each mutex, and the wineserver itself does the actions that I previously ascribed to the client thread. (It's a bit tricky because the wineserver never wants to block on acquiring the lock in shared memory; you have to set some flag in the lock word, wait for the client process to send you a message that it's released its mutex lock, and then try again.) As long as the wineserver maintains its own record of who owns each mutex, it need not actually trust any of the contents of the shared memory blocks. Other than not requiring separate client threads, this design also requires fewer process context switches. In the non-contended case, acquiring a mutex previously held by another process would require only a switch to the wineserver and back. Sorry I'm not familiar with the Wine code and I don't have time to dig into it, but I just want to urge you not to give up on finding a safe, very efficient solution. Rob -- [Robert O'Callahan http://www.cs.cmu.edu/~roc 7th year CMU CS PhD student "Now when Joshua was near Jericho, he looked up and saw a man standing in front of him with a drawn sword in his hand. Joshua went up to him and asked, 'Are you for us or for our enemies?' 'Neither,' he replied, 'but as commander of the army of the LORD I have now come.'" - Joshua 5:13-14]

Feb. 24, 2001

Printer setup dialog enhancement

by Duane Clark

Howdy, Since the landscape/portrait icons were added to the printer setup dialog a couple weeks ago, here is a minor patch so that the landscape/portrait radio buttons cause an immediate change of the icon. Duane Index: dlls/commdlg/printdlg.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/printdlg.c,v retrieving revision 1.37 diff -u -r1.37 printdlg.c --- dlls/commdlg/printdlg.c 2001/02/12 19:42:08 1.37 +++ dlls/commdlg/printdlg.c 2001/02/24 19:52:37 @@ -940,12 +940,20 @@ case rad1: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_PORTRAIT; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hPortraitIcon)); + } break; case rad2: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_LANDSCAPE; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hLandscapeIcon)); + } break; case cmb1:

Feb. 24, 2001

Re: SHLocalAlloc

by Eric Pouech

"J.Brown (Ender/Amigo)" wrote: > > I've been trying to get the Windows ME version of internet > explorer/explorer to load successfully under Wine.. However, it runs into > an unimplemented SHLocalAlloc function in shell32. > > This appears to be an undocumented function, or I'm looking in the > wrong place... has anyone got a patch or API specs on it? I don't think we'll get specs on this one... from the name (and the associated funcs SHLocalFree and SHLocalReAlloc) this sounds like function to alloc (near) memory on shell32 data segment what you could do is: - implement a stub for those 3 functions. Alloc is likely to take one or two parameters (size of block for sure and maybe some flags)... - to guess the number of parameters, run your program with the debugger, set a breakpoint on this function, and then disas the calling frame, where you should be able to validate the number of parameters... - once this is done you can map the call to either allocation on the process heap (or create a specific shell32 heap, and go from here...) under Wine (as it is today), it wouldn't bring nothing using a shell heap (except the memory cleanup on DLL unloading...) while you're at it, Free and ReAlloc must be writte too (don't implement one without the others) last point, since there is no lock function, the returned value of Alloc is likely to be the linear address of the memory block... but, once again this is a wild guess... you're on your own to do the reverse engineering A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 24, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Ove Kaaven

On Thu, 22 Feb 2001, Robert O'Callahan wrote: > Then on some other thread in the same address space > that serves wineserver requests: There's no such thread, and will never be such a thread (having the wineserver calling into client threads is an inherently unstable design).

Feb. 24, 2001

SHLocalAlloc

by J.Brown (Ender/Amigo)

I've been trying to get the Windows ME version of internet explorer/explorer to load successfully under Wine.. However, it runs into an unimplemented SHLocalAlloc function in shell32. This appears to be an undocumented function, or I'm looking in the wrong place... has anyone got a patch or API specs on it? Regards, Ender _________________________ ______________________________ | James 'Ender' Brown | "Where are we going, and why | | http://www.enderboi.com | am I in this handbasket?!?" | +-------------------------+------------------------------+

Feb. 24, 2001

Re: huge library renaming ?

by admiral coeyman

Group, > > Sure Debian handles everything perfectly, and sure other distros do the > same, but this *will* fail at the user level somewhere e.g. if they > want to install the stuff themselves, and e.g. need to uninstall the mess > cleanly again. > (I know my newbies ;-) > The main problem we'll have is always going to be on the user end. We're trying to get windows applications ported, thus we have to make the porting as painless for windows programmers as we can. Wine must be set up in the way that is simplest for the end user. If we plan this out properly, then wine will make porting easier that the complexities of using wine. Otherwise, wine will not be used. Renaming the libraries is the simplest solution. Even placing them in a custom directory, the user must take action to avoid name conflicts. That's additional work on the user end which adds to the learning curve. Is it reasonable to expect the end user to use rpath? > > Thus I'd rather see this solved in the best way possible. > And this is not the current solution IMHO. > I concur. > > The libraries are not clearly identified as being win32 stuff or wine stuff. > And this is wrong IMHO, regardless of whether "we normally do this or that > to avoid problems like that". > Which also makes them hard to remove. I've removed one set of libraries to give me drive space for the next set. We risk becomming like 'other monopolies' if we expect other people to work around problems with wine. Name conflicts are not the user's problem--they are ours. I've worked with dll conflicts just like this with a pair of HP devices under windows. End users wouldn't put the time into finding conflicts that we put into tracking that down.... > > It will fail. Somewhere. Sometime. > And the less total the failure, the harder the source will be to find.... -Robert 'Admiral' Coeyman -- http://www.corner.net/admiral/ May you live as long as you wish and age but a single day. [Telnet to telnet.corner.net]

Feb. 24, 2001

Re: huge library renaming ?

by Andreas Mohr

On Fri, Feb 23, 2001 at 03:47:39PM +0100, Bernhard Rosenkraenzer wrote: > On Fri, 23 Feb 2001, Ove Kaaven wrote: > > > > AFAIR there have been several naming conflicts with other projects > > > (libole, ...), and people who need to remove a previous Wine install > > > from their system manually have a rather hard time... > > > > Any reason for doing this? > > I can't think of any... > > > > The Debian packages work perfectly, without any potential for conflict. > > They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into > > ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from > > /usr/lib (and Wine's own configure adds rpath stuff last time I looked) > > The Red Hat package does the same thing, but still I'd prefer renaming the > libraries for all the people who compile from source without knowing all > the details. > > You quickly get from "I'm a total newbie" to "I'm still a newbie, but I > know that basics and I've figured out I can install almost any program > from source by just typing "./configure --prefix=/usr; make install"!" > state. We shouldn't kill those users' normal libraries. [Yes, I know users > should in theory put all their stuff to /usr/local, but I haven't seen > many people who actually do] > > Either rename them, or make configure intelligent enough to do > /usr/lib/wine trickery automatically (if prefix=/usr) unless explicitly > told not to do it... Exactly. Renaming them is *much* cleaner. Sure Debian handles everything perfectly, and sure other distros do the same, but this *will* fail at the user level somewhere e.g. if they want to install the stuff themselves, and e.g. need to uninstall the mess cleanly again. (I know my newbies ;-) Thus I'd rather see this solved in the best way possible. And this is not the current solution IMHO. The libraries are not clearly identified as being win32 stuff or wine stuff. And this is wrong IMHO, regardless of whether "we normally do this or that to avoid problems like that". It will fail. Somewhere. Sometime. Andreas Mohr

Feb. 24, 2001

Re: ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'

by Gerald Pfeifer

On 23 Feb 2001, Alexandre Julliard wrote: >> Perhaps just some incomplete #ifdef ... #endif sequence? > Yep, here's a fix: > > Index: scheduler/pthread.c Yes, that fixes it. Thanks! Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Feb. 23, 2001

Re: ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'

by Alexandre Julliard

Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > I'm leaving for holidays very soon and have to proof-read some 60 exams > before that, so I won't be able to track this down, but perhaps one of > could fix the build failure seen on FreeBSD 4.2? > > Perhaps just some incomplete #ifdef ... #endif sequence? Yep, here's a fix: Index: scheduler/pthread.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/pthread.c,v retrieving revision 1.11 diff -u -r1.11 pthread.c --- scheduler/pthread.c 2001/02/23 01:37:05 1.11 +++ scheduler/pthread.c 2001/02/23 22:27:07 @@ -18,6 +18,13 @@ #include "winbase.h" #include "thread.h" +static int init_done; + +void PTHREAD_init_done(void) +{ + init_done = 1; +} + /* Currently this probably works only for glibc2, * which checks for the presence of double-underscore-prepended * pthread primitives, and use them if available. @@ -86,13 +93,6 @@ #define MAX_KEYS 16 /* libc6 doesn't use that many, but... */ #define P_OUTPUT(stuff) write(2,stuff,strlen(stuff)) - -static int init_done; - -void PTHREAD_init_done(void) -{ - init_done = 1; -} void __pthread_initialize(void) { -- Alexandre Julliard julliard(a)winehq.com

Feb. 23, 2001

./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'

by Gerald Pfeifer

I'm leaving for holidays very soon and have to proof-read some 60 exams before that, so I won't be able to track this down, but perhaps one of could fix the build failure seen on FreeBSD 4.2? Perhaps just some incomplete #ifdef ... #endif sequence? : rm -f libwine_unicode.so && ln -s unicode/libwine_unicode.so libwine_unicode.so rm -f libwine_uuid.a && ln -s ole/libwine_uuid.a libwine_uuid.a gmake[1]: Entering directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' LD_LIBRARY_PATH="../unicode:$LD_LIBRARY_PATH" ../tools/winebuild/winebuild -fPIC -L../dlls -o wine.spec.c -spec wine.spec /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wine.spec.o wine.spec.c /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o main.o main.c ld -r wine.spec.o main.o -o miscemu.o gmake[1]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' /usr/bin/gcc -o wine miscemu/miscemu.o -L./dlls -lntdll -L./library -lwine -L./unicode -lwine_unicode -lncurses -lxpg4 -lm -lutil ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done' gmake: *** [wine] Error 1 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Feb. 23, 2001

Re: huge library renaming ?

by Andreas Mohr

On Fri, Feb 23, 2001 at 01:29:29PM +0100, Marcus Meissner wrote: > On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote: > > Hello all, > > > > one thing that occurred to me: > > Shouldn't we rename *all* Wine libraries to libwineXXX ? > > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > > > If this is a good thing, then we should do this NOW, not when it's too late. > > > > The current drawbacks are just too much IMHO. > > Why not put them in /usr/lib/wine/ as suggested by the FHS? Hmm, yes that's one solution. However this doesn't solve naming conflicts, does it ? If we have libole and another project (was it gnumeric ?) uses the same name, then there really is nothing to our defense. If we choose to use libwine_xxx or something similar, then the other project looks pretty stupid if it somehow decides to choose the same name (which won't happen anyway). Putting the libraries in /usr/lib/wine instead seems to only solve the "easy uninstall" problem. Andreas Mohr

Feb. 23, 2001

Re: Perl/Wine extension for perusal

by Eric Pouech

Alexandre Julliard wrote: > > Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: > > > Do you really feel like a C compiler is less common than a perl binary > > under Windows ? I seriously doubt it... > > Anybody can install a perl binary on their machine, while nearly all > Windows compilers are commercial software... I know at least two free compilers... lcc and mingw to me the greatest obstable is to maintain the build environments for all the possible compilers (MSVC, Borland...) > > there's just one point that worries me. Let me explain how I ended up with > > XML. one thing I don't like is to have a "reference" file, but I don't > > know what it refers to. I think the test process should output both the result > > of the test (pure ASCII is fine) but also the environment of the test > > (Windows - if so version, even DLLs used... -, vs wine - which version, which > > DLLs are used, native vs builtin...) so that we could make usefull > > comparisons > > But none of this information is relevant for unit testing. The only > information that may be needed is the Windows version, and this only > for the few APIs that actually behave differently between > versions. And if you do your test scripts right you don't even need to > know about it. For instance, instead of doing something like: > > kernel32->MapViewOfFile(bad params); > print kernel32->GetLastError(); > > which would print different things on 95 and NT, you'd do: > > kernel32->MapViewOfFile(bad params); > $err = kernel32->GetLastError(); > if (kernel32->GetVersion() == win95) > { > print ($err == ERROR_INVALID_ADDRESS) ? "OK" : "failed: $err"; > } > else > { > print ($err == ERROR_INVALID_PARAMETER) ? "OK" : "failed: $err"; > } > > This way the script always prints the same thing no matter the Windows > version, and you can use a simple diff against a single reference file. this is utterly true for low level APIs (like kernel) however, testing a highler level API will depend on all the others DLL the tested DLL depends on... and here you may introduce some discrepencies... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 23, 2001

IBM Websphere Studio

by David.Goodenough＠dga.co.uk

Having got Java running properly under Wine 20010216, now I return to the application that caused me to start looking at Java, Websphere Studio. I managed to get it to install with a few non-fatal messages, and it starts. It is very slow, but my first interest is to get it to work. It uses ImmAssociateContext and ImmGetContext, but currently these are stubs, and so FixMe's happen. Is anyone working in this area, if so have they written non-stub versions of these functions, alternatively does anyone know where the HIMC should be stored, and how I get to it from a HWND and then I can code them up.

Feb. 23, 2001

huge library renaming ?

by Andreas Mohr

Hello all, one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ? AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time... Any reason for not doing this ? I can't think of any... If this is a good thing, then we should do this NOW, not when it's too late. The current drawbacks are just too much IMHO. Andreas Mohr

Feb. 23, 2001

Re: Perl/Wine extension for perusal

by Alexandre Julliard

Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: > Do you really feel like a C compiler is less common than a perl binary > under Windows ? I seriously doubt it... Anybody can install a perl binary on their machine, while nearly all Windows compilers are commercial software... > well, the stubs between perl and windows will not be exactly the same > anyway, so you'll anyway introduce code differences between the two > (not to speak about the perl interpreters which might have small differences > too). You'll need some serious testing to make sure that both interpreters behave the same way of course; but you only have to do this once, you can then share test scripts freely. If you have to compile them you'll never know if your foo.exe and your foo.so were compiled from the same source, since you cannot diff them to check. > In some other cases, it may also be interesting > to simply run existing programs (if they exist). This shouldn't part > of the whole test system, but if program exists then use it (of course > command based programs are much easier than UI ones...) That's a completely different test environment. The perl stuff is meant for unit testing (a single API at a time), and especially for catching regressions. Running whole applications is of course necessary too, but it's not the same usage nor the same goal. I don't want 'make test' to launch winword so that I can test it too. > where I want to end up to is that we'd need several tests environments > (perl to be one, pure C could be another one... - it's anyway needed to > test the Winelib part, and the associated tools..., command line programs > from shell scripts could be a third). > the driving idea would be that all of those test tools spit the same > type of outputs (they all belong to the first pass), so we can share > the analysis tools I don't see any need for that. The tests and the results are very different, and I don't see what you'll be able to share. The result of the unit test would be something like 'HeapFree does not set the correct last error code when called with pointer xxx'; the result of running an application will be 'winword crashes when I click on save'. It's a completely different approach to testing, both are necessary but not within the same environment IMO. > there's just one point that worries me. Let me explain how I ended up with > XML. one thing I don't like is to have a "reference" file, but I don't > know what it refers to. I think the test process should output both the result > of the test (pure ASCII is fine) but also the environment of the test > (Windows - if so version, even DLLs used... -, vs wine - which version, which > DLLs are used, native vs builtin...) so that we could make usefull > comparisons But none of this information is relevant for unit testing. The only information that may be needed is the Windows version, and this only for the few APIs that actually behave differently between versions. And if you do your test scripts right you don't even need to know about it. For instance, instead of doing something like: kernel32->MapViewOfFile(bad params); print kernel32->GetLastError(); which would print different things on 95 and NT, you'd do: kernel32->MapViewOfFile(bad params); $err = kernel32->GetLastError(); if (kernel32->GetVersion() == win95) { print ($err == ERROR_INVALID_ADDRESS) ? "OK" : "failed: $err"; } else { print ($err == ERROR_INVALID_PARAMETER) ? "OK" : "failed: $err"; } This way the script always prints the same thing no matter the Windows version, and you can use a simple diff against a single reference file. -- Alexandre Julliard julliard(a)winehq.com

Feb. 23, 2001

Re: Perl/Wine extension for perusal

by Eric Pouech

> > So, this imposes to have the test programs also (compile) and run under > > windows... This could even allow (from source code for example) to have > > 3 test caes : > > 1/ compiled and running under windows > > 2/ compiled under windows, but run with wine > > 3/ compiled as a winelib app > > The idea of using an interpreter like Perl is precisely that you don't > need to compile anything to run tests. I think this is important > because not everybody has a Windows compiler. Do you really feel like a C compiler is less common than a perl binary under Windows ? I seriously doubt it... > It also allows using the > exact same test script under Windows and Wine, so that you don't have > to worry whether your Windows binary exactly matches your Winelib > binary. well, the stubs between perl and windows will not be exactly the same anyway, so you'll anyway introduce code differences between the two (not to speak about the perl interpreters which might have small differences too). but let's try to open up this a bit. I don't think that perl only testing is sufficient (it can a very good test bed for some cases, but I won't cover any aspects). In some other cases, it may also be interesting to simply run existing programs (if they exist). This shouldn't part of the whole test system, but if program exists then use it (of course command based programs are much easier than UI ones...) where I want to end up to is that we'd need several tests environments (perl to be one, pure C could be another one... - it's anyway needed to test the Winelib part, and the associated tools..., command line programs from shell scripts could be a third). the driving idea would be that all of those test tools spit the same type of outputs (they all belong to the first pass), so we can share the analysis tools > > in order to help the pass 2 (and even produce all possible reports), I > > had in mind (but didn't give a good look at it) to let the test scripts > > produce an XML output. This would allow the test harness to spit out any > > information (like used DLLs native/builtin, version of those, version of > > windows (emulated by wine or native...), plus the output by itself > > analysis and report should be (partially) driven by some XSL/XSLT tools > > I don't think we need anything fancy like that. The output should be > simple ASCII that can be automatically compared with diff, and the > test is considered a failure if diff finds any difference against the > reference output. Everything should be automated as much as possible. there's just one point that worries me. Let me explain how I ended up with XML. one thing I don't like is to have a "reference" file, but I don't know what it refers to. I think the test process should output both the result of the test (pure ASCII is fine) but also the environment of the test (Windows - if so version, even DLLs used... -, vs wine - which version, which DLLs are used, native vs builtin...) so that we could make usefull comparisons XML is just the way to structure the metadata about the test, the output of the test per se could be pure ASCII A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 23, 2001

Re: huge library renaming ?

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > one thing that occurred to me: > Shouldn't we rename *all* Wine libraries to libwineXXX ? This was discussed already. The dlls will ultimately reside in /usr/lib/wine so there won't be any conflict; the libraries that have to be in /usr/lib already use the libwine prefix (libwine_unicode, libwine_tsx11 etc.) -- Alexandre Julliard julliard(a)winehq.com

Feb. 23, 2001

RE: huge library renaming ?

by Ove Kaaven

On Fri, 23 Feb 2001, Patrik Stridvall wrote: > Sure Wine uses (or can be made to use rpath), but I'm not sure we > want to require all Winelib applications to do the same. No, the configure script applies rpath to the winelib dlls. The wine binary itself doesn't use rpath by default. > It would IMHO be much better if a simple Winelib applications just > could add -lwin32_XXX and be done with it. Winelib apps should never link to the .so files using -lXXX. They should add "import XXX" to the main .spec file and let winelib handle the actual loading, but never link to the libs directly at the ELF level. At least that's Alexandre's plan...

Feb. 23, 2001

RE: huge library renaming ?

by Patrik Stridvall

> On Fri, 23 Feb 2001, Andreas Mohr wrote: > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > Any reason for doing this? > I can't think of any... > > The Debian packages work perfectly, without any potential for > conflict. > They install the dlls into /usr/lib/wine, do *not* put > /usr/lib/wine into > ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from > /usr/lib (and Wine's own configure adds rpath stuff last time > I looked) I think the discussion is more about what Winelib applications in general do (or should do) rather than what Wine (a very specific Winelib application) does. Sure Wine uses (or can be made to use rpath), but I'm not sure we want to require all Winelib applications to do the same. It would IMHO be much better if a simple Winelib applications just could add -lwin32_XXX and be done with it.

Feb. 23, 2001

Re: huge library renaming ?

by Bernhard Rosenkraenzer

On Fri, 23 Feb 2001, Ove Kaaven wrote: > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > Any reason for doing this? > I can't think of any... > > The Debian packages work perfectly, without any potential for conflict. > They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into > ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from > /usr/lib (and Wine's own configure adds rpath stuff last time I looked) The Red Hat package does the same thing, but still I'd prefer renaming the libraries for all the people who compile from source without knowing all the details. You quickly get from "I'm a total newbie" to "I'm still a newbie, but I know that basics and I've figured out I can install almost any program from source by just typing "./configure --prefix=/usr; make install"!" state. We shouldn't kill those users' normal libraries. [Yes, I know users should in theory put all their stuff to /usr/local, but I haven't seen many people who actually do] Either rename them, or make configure intelligent enough to do /usr/lib/wine trickery automatically (if prefix=/usr) unless explicitly told not to do it... LLaP bero

Feb. 23, 2001

Re: huge library renaming ?

by Ove Kaaven

On Fri, 23 Feb 2001, Andreas Mohr wrote: > AFAIR there have been several naming conflicts with other projects > (libole, ...), and people who need to remove a previous Wine install > from their system manually have a rather hard time... > > Any reason for not doing this ? > I can't think of any... Any reason for doing this? I can't think of any... The Debian packages work perfectly, without any potential for conflict. They install the dlls into /usr/lib/wine, do *not* put /usr/lib/wine into ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from /usr/lib (and Wine's own configure adds rpath stuff last time I looked)

Feb. 23, 2001

Re: huge library renaming ?

by Gerald Pfeifer

On Fri, 23 Feb 2001, Marcus Meissner wrote: > Why not put them in /usr/lib/wine/ as suggested by the FHS? That's what I've been doing for the FreeBSD port for ages. Welcome to the club! :-) Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Feb. 23, 2001

RE: huge library renaming ?

by Patrik Stridvall

> On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote: > > Hello all, > > > > one thing that occurred to me: > > Shouldn't we rename *all* Wine libraries to libwineXXX ? > > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > > > If this is a good thing, then we should do this NOW, not > when it's too late. I agree, if we do we must do it before Wine 1.0. > > The current drawbacks are just too much IMHO. > > Why not put them in /usr/lib/wine/ as suggested by the FHS? I second that. However I would suggest that we also put symbolic link to the corresponding files in /usr/lib following the suggested naming scheme libwineXXX or something similar. Other suggestions. 1. libwine_XXX 2. libwin32_XXX Personal think I would prefer the libwin32_XXX variant because in theory use could have other implementations of the Windows API than Wine and that is of no pariticular concern of the programmer eventhough of course it is for the administrator of the system. If a programmer wanted to use say Win32 filehandling functions he could, in theory, just link with libwin32_kernel32 and be done with it. Something (in our case Wine) provides it, but he doesn't care what. This is currently not possible IIRC but it might be in the future. Additionally is makes it possible to support both Win32 and Win64 on 64bit systems like Itanium by having libwin64_XXX. This would make it easier to properly link to the files in Winelib application. This means you can do gcc -o foo foo.c -lwin32_ole instead of doing gcc -o foo foo.c -I/usr/lib/wine -lole that might cause problems if libole.so exist in another path. Also not that this also makes it harder to link to the DLL:s that are not supposed to be use with Winelib by misstake, like the Win16 DLL:s since we can choose to not provide symbolic links to them.

Feb. 23, 2001

Re: huge library renaming ?

by Marcus Meissner

On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote: > Hello all, > > one thing that occurred to me: > Shouldn't we rename *all* Wine libraries to libwineXXX ? > > AFAIR there have been several naming conflicts with other projects > (libole, ...), and people who need to remove a previous Wine install > from their system manually have a rather hard time... > > Any reason for not doing this ? > I can't think of any... > > If this is a good thing, then we should do this NOW, not when it's too late. > > The current drawbacks are just too much IMHO. Why not put them in /usr/lib/wine/ as suggested by the FHS? Ciao, Marcus

Feb. 23, 2001

Re: page scroller improvements for IE4

by Guy L. Albertelli

The patch works great. Thanks a lot! Guy -----Original Message----- From: Susan Farley <susan(a)codeweavers.com> To: wine patches <wine-patches(a)winehq.com> Cc: Guy L. Albertelli <galberte(a)neo.lrun.com> Date: Thursday, February 22, 2001 1:33 PM Subject: page scroller improvements for IE4 >With this patch, the menu bar (which is the child of a pager >control) shows up on Internet Explorer 4. Thanks to Guy >Albertelli for pointing out that problem. There is still a >problem with the way it scrolls--I'll work on that next. > >Changelog: >* dlls/comctl32/pager.c > Horiz/Vert determination must be dynamic, as the style may >not be set upon creation; improved positioning and scrolling. > >* include/commctrl.h > Avoid alignment problems with NMPGSCROLL struct. > >Susan Farley ><susan(a)codeweavers.com>

Feb. 23, 2001

Notes and Java test on 20010216 drop

by David.Goodenough＠dga.co.uk

Well the situation with Notes has not changed much, except that I now get lots of err:psdrv:PSDRV_AFMGetCharMetrics: No whitespace found messages. I am unclear as to which files this is actually reading, but this is a new error and the metrics files have not changed. The Java problem I had with the last drop (the problem with Callout not being initialised) is still there, so obviously the fix that was generated and which fixes the problem has not made it into the CVS. The good news is that now Java works (if the patch is applied). Now the fonts display correctly. I am not sure what you have done guys, but it works a treat. Now for some more testing with some of the things I wanted to run but could not because of the Java support. Interestingly both the Sun and the IBM JREs now work, where last month with the fix the Sun one produced the wrong output but at least ran to completion, while the IBM one locked up somewhere. Now both run to completion properly.

Feb. 22, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

I was just reading WWN and saw this discussion. Here's a wacky idea that might or might not work. The basic idea is to grant ownership of each mutex to one Win32 process at a time. Let any thread grab the mutex quickly if it belongs to the process that owns the mutex. If its process does not own the mutex, then it must communicate with the wineserver and the wineserver must communicate with the owning process to transfer ownership of the mutex from the current owner to the requesting thread. Here's how to implement it. For each Win32 process, for each mutex that's been mapped into it using DuplicateHandle or whatever, allocate a standard shared-memory-based critical section, along with a weOwnIt flag that indicates whether we own the mutex or not. Processes that don't own the mutex leave their critical sections locked. Then implement the operations as follows: AcquireMutex { retry: TryToEnterCriticalSection(); // nonblocking if (failed) { if (!weOwnIt) { wineserver->GiveUsOwnership(); // blocking goto retry; } else { EnterCriticalSection(); // blocking } } } ReleaseMutex { LeaveCriticalSection(); } Then on some other thread in the same address space that serves wineserver requests: WineserverGrantsUsOwnership { weOwnIt = true; LeaveCriticalSection(); } WineserverWantsToTakeAwayOwnership { EnterCriticalSection(); weOwnIt = false; wineserver->WeHaveGivenUpOwnership(); } Because the ownership test in AcquireMutex can race, the server needs to ignore GiveUsOwnership requests for processes that already own the mutex. It seems like this will be efficient (a lot more efficient than a kernel call actually) unless the mutex is pingponging between processes, in which case you'll be eating lots of context switches anyway. In terms of safety, a correctly functioning process will never complete AcquireMutex unless the wineserver has granted it the mutex. A misbehaving process can hold the mutex indefinitely or incorrectly think it has the mutex, but of course that's true under any scheme. When the wineserver terminates a process, it can reassign mutex ownership. (So if a process is asked to give up the mutex but doesn't, the wineserver can time out, kill the process and grant the mutex to someone else). Rob

Feb. 22, 2001

Corel XaraX

by Alexander Kellett

Has anyone had any success with this program? The following message is the one causing the most grief ;) fixme:file:AreFileApisANSI (void): stub And Xara reports that the file does not exist / invalid filename... thanks, Alex

Feb. 22, 2001

Additional registry key for PS driver

by Ian Pilcher

Huw - Now that I've finally gotten EnumPrinterDataEx implemented, I'll redo my font mapping patch to use it. While I'm doing this, I'm thinking of adding another value, which I'm thinking of calling "SoftFonts". This would be a REG_MULTI_SZ, and it would simply be a list of fonts that the driver should use even if they're not listed in the PPD file. For now, we rely on the user to set up a filter which will embed those fonts into the print job (which is what I do with my TrueType fonts). Having the PostScript driver embed the fonts itself can go on the wish list. The value can go in the PrinterDriverData subkey, and the driver can read it with GetPrinterData. What do you think of this scheme? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 22, 2001

Re: Perl/Wine extension for perusal

by Francois Gouget

On 21 Feb 2001, Alexandre Julliard wrote: > Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: [...] > > So, this imposes to have the test programs also (compile) and run under > > windows... This could even allow (from source code for example) to have > > 3 test caes : > > 1/ compiled and running under windows > > 2/ compiled under windows, but run with wine > > 3/ compiled as a winelib app > > The idea of using an interpreter like Perl is precisely that you don't > need to compile anything to run tests. I think this is important > because not everybody has a Windows compiler. It also allows using the > exact same test script under Windows and Wine, so that you don't have > to worry whether your Windows binary exactly matches your Winelib > binary. The downside of interpreter-based tests are: - they won't test the Winelib headers or Winelib specific issues - I imagine that some of our potential test writers would be windows programmers (after all these tests would be nothing more than simple Windows applications). They would probably be more comfortable writing tests in C/C++. So I guess I would prefer C/C++ based regression tests but I'm not really opposed to interpreter based tests either. Let's get something rolling. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Feb. 21, 2001

Re: ms apps with muncher

by FT Rathore

Hi Thansk for the response. Point well taken. It could be a good starting point, but, one thing. Please lose the paperclip it annoys the heck out of me. hehe! On Wed, 21 Feb 2001, Josh Walker wrote: > By announcing my intentions I've seem to have struck a chord with some > people both here at work and on the mailing list (Not a bad chord, but > just enough to take notice) Allow me to explain my goals on project > muncher. It's a little more than "let's see how much we can make linux > look like windows" > > I understand that Windows is fairly buggy software with an ickey > unmalleable interface and a kernel that looks like spaghetti going through > a sieve. I also know that Linux is probably one of the most slickest > kernels ever created. Modular, scalible, added to the fact it been linked > to a filesystem based of one of oldest and best around, topped off with > the ablility to configure darn near anything, why would you want anything > else? > > The probelm is this. Most users don't care. Doing the math I've concluded > that the percent of users who don't give a hoot about anything that makes > linux a good OS is directly proportional to the percent of people using > something else. > > I take the example of my mother as the typical windows user. She is a very > nice person, as all mothers are, but really doesn't care that I can skin > gkrellm. > > "And that does what again?" > > "Does it run Quicken?" > > "Where's the paperclip?" > > I think you kind of get the idea here. > > People don't want things that are differnt, even though it's for the > better. Trust me, I have an ex-fiance and was forced to deal with that > same issue. The fact of the matter is if it looks like windows and walks > like windows, it's windows, at least as far as my mother is concerned. All > the behind the scenes linux stuff (which is far cooler as far as we are > concerned) will be an added bonus for both us and her. > > I also like make waves. Apple is theating legal action for people who just > make Aqua *themes* Imagine annoucing to the world that you have a version > of "windows" that is not only didn't come from Gates, but one that is > totaly free. If MS even tried to litagate it'll make napster look like a > circius show. MS is already been decalerd a monopoly. Now they are trying > to crush a venture to make a compatible system in some garage somewhere. > > Anyway enough ranting. I have an update. The PC I was using to create the > distro blew it's motherboard so it's on hold until I can pin down another > cheap PC to use as a test bed. It's cheaper just to get a new a new PC > than replace the board. I'd love to work on the do-hickeys here at work > with glade, but I'm under contarct that any I devlop on the clock is owned > by the company. > > -Joshua Walker > > On Tue, 20 Feb 2001, FT Rathore wrote: > > > Hi > > Is it just me or is it that you are trying hard to copy look of a badly > > written desktop. This way you are limiting yourself, think beyond POS > > windows desktop. Free your mind, come up with something better. > > FT > > > > >

Feb. 21, 2001

Re: Perl/Wine extension for perusal

by Alexandre Julliard

Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: > So, I had rather in mind to have a two passes approach > pass 1 : let the scripts run and output the results > pass 2 : analyze the results. This could be either comparing with a > manually edited reference case, or reference cases could be generated from > running the program under Win <put any version here>. Yes, that's the idea; the test script will output a bunch of results which can then be compared against a reference run generated under Windows. We probably also want a standard config file (or a few of them to handle version differences) to ensure the test environment is the same for everybody. > So, this imposes to have the test programs also (compile) and run under > windows... This could even allow (from source code for example) to have > 3 test caes : > 1/ compiled and running under windows > 2/ compiled under windows, but run with wine > 3/ compiled as a winelib app The idea of using an interpreter like Perl is precisely that you don't need to compile anything to run tests. I think this is important because not everybody has a Windows compiler. It also allows using the exact same test script under Windows and Wine, so that you don't have to worry whether your Windows binary exactly matches your Winelib binary. > in order to help the pass 2 (and even produce all possible reports), I > had in mind (but didn't give a good look at it) to let the test scripts > produce an XML output. This would allow the test harness to spit out any > information (like used DLLs native/builtin, version of those, version of > windows (emulated by wine or native...), plus the output by itself > analysis and report should be (partially) driven by some XSL/XSLT tools I don't think we need anything fancy like that. The output should be simple ASCII that can be automatically compared with diff, and the test is considered a failure if diff finds any difference against the reference output. Everything should be automated as much as possible. > for developpers, the make test should be made more fine grain (IMO). Like > (not necessarly thru make) test a DLL (if some modifications have been > made to it) or even an entry point... (or a set of entry points). Yes, there should be one set of test scenarios for each dll, and each scenario should test one entry point (or a few related ones); this way you can either run a single test, or do a make test in a dll directory to run the tests for this dll, or make test at the top-level which will simply iterate through all the dlls. The tests should ideally run fast enough that you can do a make test in the dll dir everytime you change something. > It's the way I started splitting the test cases (DLL / set of features...). > This has drawbacks. For example, it's rather hard to test, say, Unicode > support accross all DLLs But you should never need to do that. If you change something in a core Unicode function in kernel, this will be tested by the kernel test scenarios. If the test scenarios don't find a problem but tests for higher level dlls fail, then your kernel test scenarios are buggy since they didn't spot the change. -- Alexandre Julliard julliard(a)winehq.com

Feb. 21, 2001

Re: Wine & Wrapster/UnWrapper/etc

by gerard patel

At 01:34 AM 20/2/01 +1100, you wrote: > >Just a potentially useful data point, since the Wrapster source is freely >available on their website (it's written in PASCAL). Wrapster and >UnWrapper won't work under WINE 20010112. Wrapster appears to sit in an >infinite loop when asked to unwrap a file (although it's a 180Mb+ file so >it may be doing something, but strace implies it's sitting there being >confused, since it continually lstat()'s the destination directory and then >does some miscellaneous memory mapping and unmapping). > >UnWrapper (2.x and 3.x) simply die on startup. <snip> Did you install it with Wine ? You need to add the winedefault.reg data to the Wine registry using regapi and it will install correctly. It starts for me after that using only builtin libraries, with some problems - it seems that this app could be a good test bed for Ole conformance given the number of FIXME issued, and a few run-time errors (caught by the exception handlers of Delphi) I can't test further for now since I don't have any wrapped file available. Gerard

Feb. 21, 2001

Re: Perl/Wine extension for perusal

by Eric Pouech

> I think it would be great if we could start to define > (and build) a test harness. I think that there are a lot of people > who would help write test scripts, who might otherwise be unable > to help with Wine development. The more the merrier, I always say... 100% agreed > What did you have in mind? Our thinking, beyond building the > Perl based winetest, hasn't gone very far. I think we've imagined > the following: > > make test Performs an automated, non interactive regression > test and returns true or false. well, I started thinking on that... there could several uses of a test harness for Wine. We could either define this is a good result or not. But this is a bit deeper than that. For examples, some cases should work in Win98 emulation but fail for Win2k... So, I had rather in mind to have a two passes approach pass 1 : let the scripts run and output the results pass 2 : analyze the results. This could be either comparing with a manually edited reference case, or reference cases could be generated from running the program under Win <put any version here>. So, this imposes to have the test programs also (compile) and run under windows... This could even allow (from source code for example) to have 3 test caes : 1/ compiled and running under windows 2/ compiled under windows, but run with wine 3/ compiled as a winelib app normally, there shouldn't be too many differences between 2 and 3... but, we all know what "normally" means... Of course, we don't need to start with all that in order to help the pass 2 (and even produce all possible reports), I had in mind (but didn't give a good look at it) to let the test scripts produce an XML output. This would allow the test harness to spit out any information (like used DLLs native/builtin, version of those, version of windows (emulated by wine or native...), plus the output by itself analysis and report should be (partially) driven by some XSL/XSLT tools this may be a bit overkill to start but could be a reasonable target on the test cases basis, I wrote a few of them (as any of us has done more or less), basically tackling the multimedia DLLs however, it's also a good basis to reverse engineer at the API level (or better understand some un^^ poorly documented features of the APIs) for developpers, the make test should be made more fine grain (IMO). Like (not necessarly thru make) test a DLL (if some modifications have been made to it) or even an entry point... (or a set of entry points). It's the way I started splitting the test cases (DLL / set of features...). This has drawbacks. For example, it's rather hard to test, say, Unicode support accross all DLLs > make interactive-test Runs through interactive tests that require > user interaction with the system; user > confirms or denies their results. > > Both of these test runs could also be done on a Windows box, so that > an exact 1:1 comparison could be made. > > Of course, the hard part if figuring out how to do the interactive-test. > We've thought about trying to automate it (screen shots, simulating > mouse movements, all that good stuff), but I don't think we have an > obvious or brilliant idea. We looked into tools for that, but found > no good free ones; there is also a suspicion that an X based > test tool won't be enough for Wine. no many thoughts on this one either ... did you try the windows messages journaling API ? IIRC, some early MS test programs did use it. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 21, 2001

Re: Shell32 improvements

by gerard patel

At 08:08 PM 20/2/01 -0500, you (Chris Morgan <cmorgan(a)codeweavers.com>) wrote: >ChangeLog entry: > >*dlls/shell32/shres.rc, shresdef.h, shlfolder.c, shlfileop.c: >Chris Morgan <cmorgan(a)codeweavers.com> >Confirm file deletes. Make delete confirmation messages more consistent. >Improve trace messages on delete failure. > >*dlls/shell32/shlview.c, shell32_main.h: >Chris Morgan <cmorgan(a)codeweavers.com> >Add shell support for deleting files using the Delete key. >Attachment Converted: g:\eudora\eudora\attach\shell32.diff Is it supposed to work ? If I hit 'Delete' in a shell window I get : 0x40863f38 (_ILIsDesktop+0x3c [pidl.c:1382]): cmpw $0,0x0(%esi) 1382 return ( !pidl || (pidl && pidl->mkid.cb == 0x00) ); Wine-dbg>bt bt Backtrace: =>0 0x40863f38 (_ILIsDesktop+0x3c(pidl=0x25dc) [pidl.c:1382]) (ebp=40585d74) 1 0x40864258 (_ILSimpleGetText+0x74(pidl=0x25dc, szOut=0x40585ee3, uOutSize=0x104) [pidl.c:1471]) (ebp=40585e9c) 2 0x408745df (ISFHelper_fnDeleteItems+0x12b(iface=0x4039431c, cidl=0x1, apidl=0x40391a70) [shlfolder.c:1512]) (ebp=40585fd8) 3 0x40878aa5 (ShellView_OnNotify+0x735(This=0x4039428c, CtlID=0x7d0, lpnmh=0x405863ac) [shlview.c:1330]) (ebp=40586258) 4 0x40878d5e (ShellView_WndProc+0x17e(hWnd=0x2548, uMessage=0x4e, wParam=0x7d0, lParam=0x405863ac) [shlview.c:1396]) (ebp=40586278) Gerard

Feb. 21, 2001

Re: Wine winmm

by Ove Kaaven

On Tue, 20 Feb 2001, Eric Pouech wrote: > Vedran Rodic wrote: > > > > Currently I implemented it by adding calls to PROFILE_GetWineIniString to > > OSS_WaveInit and OSS_MidiInit. Now I have a problem that /dev/mixer string is > > defined in 3 different files, and I've been thinking about moving all > > PROFILE_GetWineIniString initialization to a separate file, and make calls > > to the function from that file in audio.c, mixer.c mmaux.c init functions. > > when you say an additional DAC, it really means two different DACs (and not > the same DAC accessed with different sets of parameters) Yes, the ES1371 compensates for its lack of any kind of synthesizer by adding an additional independent DAC. I think the extra DAC is meant to be used by a softsynth in the windows drivers or something.

Feb. 21, 2001

Re: TCP/IP networking and registry keys

by Ove Kaaven

On Mon, 19 Feb 2001, Alan Chandler wrote: > 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). Nah... the IP address can change between Wine invocations (PPP, DHCP, and things like that), so it would have to be a dynamic key, generated at Wine startup or something like that (I think we already have a couple of those?), but then there's a question of how to get the OS's network interface IPs portably...

Feb. 21, 2001

Re: ms apps with muncher

by Josh Walker

By announcing my intentions I've seem to have struck a chord with some people both here at work and on the mailing list (Not a bad chord, but just enough to take notice) Allow me to explain my goals on project muncher. It's a little more than "let's see how much we can make linux look like windows" I understand that Windows is fairly buggy software with an ickey unmalleable interface and a kernel that looks like spaghetti going through a sieve. I also know that Linux is probably one of the most slickest kernels ever created. Modular, scalible, added to the fact it been linked to a filesystem based of one of oldest and best around, topped off with the ablility to configure darn near anything, why would you want anything else? The probelm is this. Most users don't care. Doing the math I've concluded that the percent of users who don't give a hoot about anything that makes linux a good OS is directly proportional to the percent of people using something else. I take the example of my mother as the typical windows user. She is a very nice person, as all mothers are, but really doesn't care that I can skin gkrellm. "And that does what again?" "Does it run Quicken?" "Where's the paperclip?" I think you kind of get the idea here. People don't want things that are differnt, even though it's for the better. Trust me, I have an ex-fiance and was forced to deal with that same issue. The fact of the matter is if it looks like windows and walks like windows, it's windows, at least as far as my mother is concerned. All the behind the scenes linux stuff (which is far cooler as far as we are concerned) will be an added bonus for both us and her. I also like make waves. Apple is theating legal action for people who just make Aqua *themes* Imagine annoucing to the world that you have a version of "windows" that is not only didn't come from Gates, but one that is totaly free. If MS even tried to litagate it'll make napster look like a circius show. MS is already been decalerd a monopoly. Now they are trying to crush a venture to make a compatible system in some garage somewhere. Anyway enough ranting. I have an update. The PC I was using to create the distro blew it's motherboard so it's on hold until I can pin down another cheap PC to use as a test bed. It's cheaper just to get a new a new PC than replace the board. I'd love to work on the do-hickeys here at work with glade, but I'm under contarct that any I devlop on the clock is owned by the company. -Joshua Walker On Tue, 20 Feb 2001, FT Rathore wrote: > Hi > Is it just me or is it that you are trying hard to copy look of a badly > written desktop. This way you are limiting yourself, think beyond POS > windows desktop. Free your mind, come up with something better. > FT >

Feb. 21, 2001

Re: various config files for various applications

by Alexandre Julliard

Martin Pilka <mpilka(a)codeweavers.com> writes: > another way could be have some additional (let's say > ~/.wine/app-config/1database.txt) file which will contain <regular > expression> --> <filename> mappings. that way wine have to open (and > read) only that file, and we're able to do that pretty fast (as i found > out when worked on registry patch). however, it has to evaluate all the > reg. expressions at runtime, but that is linear dependency. > > hmm, i don't know now. first letter or an additional file? This is getting way too complex IMO. I think having everything in the .wine/config file is much more reasonable; most people don't need that many different configurations anyway. What we should do is take advantage of the new config file format to create a deeper configuration hierarchy. So for instance the default x11drv config is under the registry key Wine\Config\x11drv, but we could create subtrees like Wine\Config\AppDefaults\Solitaire\x11drv which would contain the Solitaire-specific config values. This is then very fast to lookup, just try AppDefaults\<current module> and if not found fall back to the current method. I don't think we need regular expressions at all. -- Alexandre Julliard julliard(a)winehq.com

Feb. 20, 2001

Re: various config files for various applications

by Martin Pilka

> well, what I don't like too much is the time at process startup to look up > for the correct file (if it exists). Especially if people start writing > app specific files like rabbits. Couldn't we put a speed up in the file > look up ? Something easy like naming the config file after the first letter > of the application... (I know it'll break *foo.exe, but it shouldn't be > too much of an issue). another way could be have some additional (let's say ~/.wine/app-config/1database.txt) file which will contain <regular expression> --> <filename> mappings. that way wine have to open (and read) only that file, and we're able to do that pretty fast (as i found out when worked on registry patch). however, it has to evaluate all the reg. expressions at runtime, but that is linear dependency. hmm, i don't know now. first letter or an additional file? > Future work may also include version information if available (think of > winword.exe for example ; all of those are rather different apps) well, this doesn't look easy, but we will have to handle it somehow. probably by the set of conditions (as the part of application database file) which allows you to do simple checks for files and maybe their content also in order to determine if it's the right version (so the file settings can be applied). however, as you said, it's something for future work. > regarding configuration, another point which really bugs me is also the > content of the registry. I fear this is going to cause us lots of > trouble in the future... and may be we'll need application specific keys > in the registry... for "wine with windows" it should work - registry will be there from windows partition. for "wine without windows" the install program should add them. and if it relies on some keys which aren't installed by installer, then those keys should be part of winedefault.reg file. martin

Feb. 20, 2001

Re: various config files for various applications

by Martin Pilka

> well, what I don't like too much is the time at process startup to look up > for the correct file (if it exists). Especially if people start writing > app specific files like rabbits. Couldn't we put a speed up in the file > look up ? Something easy like naming the config file after the first letter > of the application... (I know it'll break *foo.exe, but it shouldn't be > too much of an issue). another way could be have some additional (let's say ~/.wine/app-config/1database.txt) file which will contain <regular expression> --> <filename> mappings. that way wine have to open (and read) only that file, and we're able to do that pretty fast (as i found out when worked on registry patch). however, it has to evaluate all the reg. expressions at runtime, but that is linear dependency. hmm, i don't know now. first letter or an additional file? > Future work may also include version information if available (think of > winword.exe for example ; all of those are rather different apps) well, this doesn't look easy, but we will have to handle it somehow. probably by the set of conditions (as the part of application database file) which allows you to do simple checks for files and maybe their content also in order to determine if it's the right version (so the file settings can be applied). however, as you said, it's something for future work. > regarding configuration, another point which really bugs me is also the > content of the registry. I fear this is going to cause us lots of > trouble in the future... and may be we'll need application specific keys > in the registry... for "wine with windows" it should work - registry will be there from windows partition. for "wine without windows" the install program should add them. and if it relies on some keys which aren't installed by installer, then those keys should be part of winedefault.reg file. martin

Feb. 20, 2001

Re: various config files for various applications

by Eric Pouech

> the advantage is much easier maintenance. the disadvantage could be that > you can't see the whole configuration in ~/.wine/config file anymore - > some settings could be overwritten by optional file in > ~/.wine/app-config. well, what I don't like too much is the time at process startup to look up for the correct file (if it exists). Especially if people start writing app specific files like rabbits. Couldn't we put a speed up in the file look up ? Something easy like naming the config file after the first letter of the application... (I know it'll break *foo.exe, but it shouldn't be too much of an issue). Future work may also include version information if available (think of winword.exe for example ; all of those are rather different apps) regarding configuration, another point which really bugs me is also the content of the registry. I fear this is going to cause us lots of trouble in the future... and may be we'll need application specific keys in the registry... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 20, 2001

Re: Wine winmm

by Eric Pouech

(I CC:ed wine-devel, because some answers may interest some folks there too) Vedran Rodic wrote: > > Hi! > > I've been playing a little with winmm dll. I would like to make the > OSS sound devices runtime configurable (/dev/dsp, /dev/mixer and > /dev/sequencer), and maybe make a wine alsa hardware driver implementation. > I've encoutered a few issues, and I'm not making any steps without consulting > you first since you wrote most of winmm code. > > Regarding configuration of devices, I need it because my sound card (es1371) > has an additional DAC mapped to /dev/dsp1, and I would like to make (or > propose) a standard way to configure it for wine. > > Currently I implemented it by adding calls to PROFILE_GetWineIniString to > OSS_WaveInit and OSS_MidiInit. Now I have a problem that /dev/mixer string is > defined in 3 different files, and I've been thinking about moving all > PROFILE_GetWineIniString initialization to a separate file, and make calls > to the function from that file in audio.c, mixer.c mmaux.c init functions. when you say an additional DAC, it really means two different DACs (and not the same DAC accessed with different sets of parameters) if so, you don't need to use GetWineIniString. The most straightforward way of doing it is to implement multiple devices in wineoss/audio.c. Current code only tries to open /dev/dsp. It should try /dev/dsp1... (and so forth) if available. this should be simple to do: bump MAX_WAVEOUTDRV (and MAX_WAVEINDRV) and get the config code look for /dev/dsp for the first, /dev/dsp1 for the second... With this, you'd be able to report several output (and input) channels for the same device if it's in fact the same DAC, then that's more complicated... > I've been thinking about this .wine/config layout: > > [wineoss.drv] > "Wave"="/dev/dsp" > "Mixer"="/dev/mixer" > "Seqencer"="/dev/sequencer" not needed, those are the regular OSS device drivers > Reharding alsa, I first have to be sure that I'll be able to select it > over wineoss driver. I saw that wineoss hardware driver is installed in > winmm/lolvldrv.c, but that needs a few PROFILE_GetWineIniString calls to > MMDRV_Init. this is going to go away. I'm finishing a patch where all drivers will be loaded from settings from the registry. So, if you write an ALSA driver (and, IMO there's a real need for such a driver), you'll just add some keys to the registry, and it'll be done (except that you'd need to define priorities between ALSA and OSS drivers, at configuration time) > I'm not entirely sure what to do about this section, because there can be > more than two mappers in the futurem right? > > [winmm] > "HardwareDriver"="wineoss.drv" > "Mappers"="msacm.drv, midimap.drv" ;; Could something like this be done? > > > > Vedran Rodic HTH A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 20, 2001

Strange wine crashes with /dos mounted "rw" with Unreal

by FT Rathore

Hi I have been trying to run Unreal on wine with windows partition mounted with permission set so wine can write to it. It always crashes strangly I dont get any clues. If I mount /dos in a way that wine cannot write to it, Unreal runs perfectly. This problem only occurs with Unreal. I need write access so that I can save the games. Anyone else have similar problem?. I am about to start rolling up my sleeves and debug it. Any idea what info will help. FT

Feb. 20, 2001

Re: ms apps with muncher

by FT Rathore

Hi Is it just me or is it that you are trying hard to copy look of a badly written desktop. This way you are limiting yourself, think beyond POS windows desktop. Free your mind, come up with something better. FT On Mon, 12 Feb 2001, Josh Walker wrote: > No MS apps will make it into muncher. Mucher will have three main > compents, they are called the the Macrokernel, do-hickies, and > thingamabobs. > > The Macrokernel is the core system, hangs out in the linux partition. > consists of Xfree86, wine, DosEMU, gnome, FVWM95, and supporting libs. > > Do-hickies are the things that hang out on the desktop they are really > linux apps hanging out in the Macrokernel. They look like windows > explorer ActiveX compnents such as My computer and the Control panel. > > Thingamabobs are larger do-hickies. They are full apps that are also on > the macrokernel. This includes apps like Mozillia, a gtk text editor, a > linux gtk verson of winipcfg that just snags output from ifconfig and > makes it look pretty. I will not use any MS thingamabobs. I'll have to see > if I can try and find system TTFs that don't belong to MS though. > > -halkun > > >

Feb. 20, 2001

Re: Perl/Wine extension for perusal

by Jeremy White

I believe that the mailer ate my homework...er...email, so please forgive me if this is a duplicate message: > I also started to think (and write the very first pieces) of a test > harness. If you like to, I'm fully open to discuss all that with you. I think it would be great if we could start to define (and build) a test harness. I think that there are a lot of people who would help write test scripts, who might otherwise be unable to help with Wine development. The more the merrier, I always say... What did you have in mind? Our thinking, beyond building the Perl based winetest, hasn't gone very far. I think we've imagined the following: make test Performs an automated, non interactive regression test and returns true or false. make interactive-test Runs through interactive tests that require user interaction with the system; user confirms or denies their results. Both of these test runs could also be done on a Windows box, so that an exact 1:1 comparison could be made. Of course, the hard part is figuring out how to do the interactive-test. We've thought about trying to automate it (screen shots, simulating mouse movements, all that good stuff), but I don't think we have an obvious or brilliant idea. We looked into tools for that, but found no good free ones; there is also a suspicion that an X based test tool won't be enough for Wine. Thoughts? Jer

Feb. 20, 2001

Re: Baldurs Gate 2 near perfect with transgaming and disk change problem

by FT Rathore

Sorry for the delay I was out. I only tested an existing BG2 installation which was installed using winblowz. The DLL order was default (from stock wine installation). FT On Mon, 5 Feb 2001, Malte Cornils wrote: > Hi, > > have you installed BG2 in a completely non-windows setup? If not, > did you install it in Linux or in Windows and just *run* it in > Linux? > > Also, does the configuration program work for you with builtin DLLs? > > Thanks so far, > > and feel free to cc this to wine-devel, but maybe we should change > to the newsgroup comp.emulators.ms-windows.wine, it might be more > appropriate there. > > Yours Malte #8-) >

Feb. 20, 2001

GetFullPathName & trailing backslash in path arg (Heroes of Might & Magic III problem)

by Tadeusz Szczyrba

It looks like GetFullPathName kernel.dll API func preserves trailing backslash, given in path argument, but implementation of this func in wine (files/dos_fs.c) removes it from return value (code starting at line 1300 in this file). Info about behavior taken from http://www.clubs.psu.edu/perldoc/lib/Pod/Win32.html (I don't have authorized windows api reference and even don't want to look for it - regular wine developer can check this in seconds). Removal 3 lines of code from this file cures runtime of "Heroes of Might & Magic III" (and I don't know what too). Regards TreV__ -- Tadeusz Szczyrba trevor(a)pik-net.pl

Feb. 20, 2001

TCP/IP networking and registry keys

by Alan Chandler

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

Feb. 19, 2001

Re: [gphoto-devel] Running Polaroid PhotoMax under wine

by Nathan Stenzel

It would be really nice if TWAIN and WINE would work together to support TWAIN compatable drivers under Linux. Surely this would be much easier than every piece of hardware having a Linux driver hacked for it. It would open up the hardware makers to a whole new operating system too. I would hope that all the TWAIN drivers would have a way to run on any OS. TWAIN is supposed to be a standard afterall and standards are supposed to make things easier. I decided this was an interesting idea so I am sending copies of this to various other newsgroups (some of which I am not subscribed to). > I set wine up for the express purpose of seeing if the windoze > software would download the pictures from my camera. I had the same > problem with the buttons not showing up in PhotoMAX, but I got > Irfanview to run successfully. However, it wouldn't acknowledge the > existence of the camera, so I posted to the wine newsgroup about it. > They said that the function calls required by the TWAIN driver(s) > aren't [yet?] implemented. > > Regards, > Ben

Feb. 19, 2001

Re: GDI.EXE

by Ove Kaaven

On Mon, 19 Feb 2001, Johan Gill wrote: > Since some apps require a gdi.exe file containing version info, Wine won't > be independent until the need for a true gdi.exe is removed. Are there any > plans on how this should be achieved? The "DLL placeholder files" spot on the Wine Status Page is reserved for this purpose... it should also be covered in earlier WWNs, you may want to search.

Feb. 19, 2001

GDI.EXE

by Johan Gill

Since some apps require a gdi.exe file containing version info, Wine won't be independent until the need for a true gdi.exe is removed. Are there any plans on how this should be achieved? /Johan Gill, johane(a)lysator.liu.se

Feb. 19, 2001

Re: Overlapped read/write fix

by Ove Kaaven

On Mon, 19 Feb 2001, Eric Kohl wrote: > This patch fixes the MS Jet Database Engine. Overlapped reads and writes > must fail on Win9x. That would depend on the file type. Overlapped read and write is supposed to be allowed for sockets and serial ports even on win9x, but for ordinary files only on winNT, as far as I remember.

Feb. 19, 2001

dlls/winsock/socket.c patch

by Chris Morgan

Should we be preserving the values of he, se, pe in the delete? This fixes a problem Jutta Wrage was having with Agent mailreader(win16 app).

Feb. 19, 2001

Wine & Wrapster/UnWrapper/etc

by David Luyer

Just a potentially useful data point, since the Wrapster source is freely available on their website (it's written in PASCAL). Wrapster and UnWrapper won't work under WINE 20010112. Wrapster appears to sit in an infinite loop when asked to unwrap a file (although it's a 180Mb+ file so it may be doing something, but strace implies it's sitting there being confused, since it continually lstat()'s the destination directory and then does some miscellaneous memory mapping and unmapping). UnWrapper (2.x and 3.x) simply die on startup. (And yes, I know there's a Linux version - but it doesn't do a fraction of what the Windows version does, eg, CRC checks and new file formats. So I was hoping to check if the archive I have was corrupt without having to do development on grapster first... other than the fixes I already had to do to get dewrapster to handle large files :-).) I am no longer on this list, so please CC any response to me (especially of the form "it actually works with the latest CVS and some custom patch" :-)), thanks in advance. David. (I wonder how PC-PINE is working these days, it's C source was available and it used to not work so well under WINE either...) -- David Luyer Phone: +61 3 9674 7525 Senior Network Engineer P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 2983 http://www.pacific.net.au/ NASDAQ: PCNTF

Feb. 19, 2001

mailserver operational

by Ove Kaaven

Bad rumors still abound about sendmail anyway, so I just installed exim... hopefully this won't cause problems...

Feb. 19, 2001

EnumPrinterDataEx - one more time

by Ian Pilcher

Here is an updated patch that does not use any macros. I do check all the return values, but hopefully this can be written off as a personal quirk. If no one has any objections, I'll send this to wine-patches tomorrow. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010216/include/winspool.h Sun Feb 11 19:26:47 2001 +++ include/winspool.h Sun Feb 18 18:30:13 2001 @@ -763,6 +763,25 @@ DECL_WINELIB_TYPE_AW(PPROVIDOR_INFO_1) DECL_WINELIB_TYPE_AW(LPPROVIDOR_INFO_1) +typedef struct _PRINTER_ENUM_VALUESA { + LPSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESA, *PPRINTER_ENUM_VALUESA; + +typedef struct _PRINTER_ENUM_VALUESW { + LPWSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESW, *PPRINTER_ENUM_VALUESW; + +DECL_WINELIB_TYPE_AW(PRINTER_ENUM_VALUES) +DECL_WINELIB_TYPE_AW(PPRINTER_ENUM_VALUES) + /* DECLARATIONS */ INT WINAPI DeviceCapabilitiesA(LPCSTR pDevice,LPCSTR pPort,WORD fwCapability, LPSTR pOutput, LPDEVMODEA pDevMode); @@ -1082,6 +1101,14 @@ BOOL WINAPI DeletePrintProvidorW(LPWSTR pName, LPWSTR pEnvironment, LPWSTR pPrintProvidorName); #define DeletePrintProvidor WINELIB_NAME_AW(DeletePrintProvidor) + +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +#define EnumPrinterDataEx WINELIB_NAME_AW(EnumPrinterDataEx) --- ../wine-20010216/dlls/winspool/winspool.drv.spec Sun Feb 11 19:26:47 2001 +++ dlls/winspool/winspool.drv.spec Sun Feb 18 18:30:13 2001 @@ -80,6 +80,10 @@ @ stub EnumPrintProcessorDatatypesW @ stub EnumPrintProcessorsA @ stub EnumPrintProcessorsW +@ stub EnumPrinterDataA +@ stdcall EnumPrinterDataExA(long str ptr long ptr ptr) EnumPrinterDataExA +@ stdcall EnumPrinterDataExW(long wstr ptr long ptr ptr) EnumPrinterDataExW +@ stub EnumPrinterDataW @ stdcall EnumPrinterDriversA(str str long ptr long ptr ptr) EnumPrinterDriversA @ stdcall EnumPrinterDriversW(wstr wstr long ptr long ptr ptr) EnumPrinterDriversW @ stdcall EnumPrintersA(long ptr long ptr long ptr ptr) EnumPrintersA --- ../wine-20010216/dlls/winspool/info.c Sun Feb 11 21:51:05 2001 +++ dlls/winspool/info.c Sun Feb 18 18:33:49 2001 @@ -2561,3 +2561,386 @@ return GetPrinterDataExW(hPrinter, PrinterDriverDataW, pValueName, pType, pData, nSize, pcbNeeded); } + +/******************************************************************************* + * EnumPrinterDataExW [WINSPOOL.197] + */ +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + HKEY hkPrinter, hkSubKey; + DWORD r, ret, dwIndex, cValues, cbMaxValueNameLen, + cbValueNameLen, cbMaxValueLen, cbValueLen, + cbBufSize, dwType; + LPWSTR lpValueName; + HANDLE hHeap; + PBYTE lpValue; + PPRINTER_ENUM_VALUESW ppev; + + TRACE ("%08x %s\n", hPrinter, debugstr_w (pKeyName)); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + ret = WINSPOOL_GetOpenedPrinterRegKey (hPrinter, &hkPrinter); + if (ret != ERROR_SUCCESS) + { + TRACE ("WINSPOOL_GetOpenedPrinterRegKey (%08x) returned %li\n", + hPrinter, ret); + return ret; + } + + ret = RegOpenKeyExW (hkPrinter, pKeyName, 0, KEY_READ, &hkSubKey); + if (ret != ERROR_SUCCESS) + { + r = RegCloseKey (hkPrinter); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegOpenKeyExW (%08x, %s) returned %li\n", hPrinter, + debugstr_w (pKeyName), ret); + return ret; + } + + ret = RegCloseKey (hkPrinter); + if (ret != ERROR_SUCCESS) + { + ERR ("RegCloseKey returned %li\n", ret); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ret; + } + + ret = RegQueryInfoKeyW (hkSubKey, NULL, NULL, NULL, NULL, NULL, NULL, + &cValues, &cbMaxValueNameLen, &cbMaxValueLen, NULL, NULL); + if (ret != ERROR_SUCCESS) + { + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegQueryInfoKeyW (%08x) returned %li\n", hkSubKey, ret); + return ret; + } + + TRACE ("RegQueryInfoKeyW returned cValues = %li, cbMaxValueNameLen = %li, " + "cbMaxValueLen = %li\n", cValues, cbMaxValueNameLen, cbMaxValueLen); + + if (cValues == 0) /* empty key */ + { + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + *pcbEnumValues = *pnEnumValues = 0; + return ERROR_SUCCESS; + } + + ++cbMaxValueNameLen; /* allow for trailing '\0' */ + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ERROR_OUTOFMEMORY; + } + + lpValueName = HeapAlloc (hHeap, 0, cbMaxValueNameLen * sizeof (WCHAR)); + if (lpValueName == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", + cbMaxValueNameLen * sizeof (WCHAR)); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ERROR_OUTOFMEMORY; + } + + lpValue = HeapAlloc (hHeap, 0, cbMaxValueLen); + if (lpValue == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", cbMaxValueLen); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ERROR_OUTOFMEMORY; + } + + TRACE ("pass 1: calculating buffer required for all names and values\n"); + + cbBufSize = cValues * sizeof (PRINTER_ENUM_VALUESW); + + TRACE ("%li bytes required for %li headers\n", cbBufSize, cValues); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, NULL, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + if (HeapFree (hHeap, 0, lpValue) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + TRACE ("%s [%li]: name needs %li bytes, data needs %li bytes\n", + debugstr_w (lpValueName), dwIndex, + (cbValueNameLen + 1) * sizeof (WCHAR), cbValueLen); + + cbBufSize += (cbValueNameLen + 1) * sizeof (WCHAR); + cbBufSize += cbValueLen; + } + + TRACE ("%li bytes required for all %li values\n", cbBufSize, cValues); + + *pcbEnumValues = cbBufSize; + *pnEnumValues = cValues; + + if (cbEnumValues < cbBufSize) /* buffer too small */ + { + if (HeapFree (hHeap, 0, lpValue) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("%li byte buffer is not large enough\n", cbEnumValues); + return ERROR_MORE_DATA; + } + + TRACE ("pass 2: copying all names and values to buffer\n"); + + ppev = (PPRINTER_ENUM_VALUESW) pEnumValues; /* array of structs */ + pEnumValues += cValues * sizeof (PRINTER_ENUM_VALUESW); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, &dwType, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + if (HeapFree (hHeap, 0, lpValue) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + cbValueNameLen = (cbValueNameLen + 1) * sizeof (WCHAR); + memcpy (pEnumValues, lpValueName, cbValueNameLen); + ppev[dwIndex].pValueName = (LPWSTR) pEnumValues; + pEnumValues += cbValueNameLen; + + /* return # of *bytes* (including trailing \0), not # of chars */ + ppev[dwIndex].cbValueName = cbValueNameLen; + + ppev[dwIndex].dwType = dwType; + + memcpy (pEnumValues, lpValue, cbValueLen); + ppev[dwIndex].pData = pEnumValues; + pEnumValues += cbValueLen; + + ppev[dwIndex].cbData = cbValueLen; + + TRACE ("%s [%li]: copied name (%li bytes) and data (%li bytes)\n", + debugstr_w (lpValueName), dwIndex, cbValueNameLen, cbValueLen); + } + + if (HeapFree (hHeap, 0, lpValue) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ret; + } + + if (HeapFree (hHeap, 0, lpValueName) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ret; + } + + ret = RegCloseKey (hkSubKey); + if (ret != ERROR_SUCCESS) + { + ERR ("RegCloseKey returned %li\n", ret); + return ret; + } + + return ERROR_SUCCESS; +} + +/******************************************************************************* + * EnumPrinterDataExA [WINSPOOL.196] + * + * This functions returns value names and REG_SZ, REG_EXPAND_SZ, and + * REG_MULTI_SZ values as ASCII strings in Unicode-sized buffers. This is + * what Windows 2000 SP1 does. + * + */ +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + INT len; + LPWSTR pKeyNameW; + DWORD ret, dwIndex, dwBufSize; + HANDLE hHeap; + LPSTR pBuffer; + + TRACE ("%08x %s\n", hPrinter, pKeyName); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + len = MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, NULL, 0); + if (len == 0) + { + ret = GetLastError (); + ERR ("MultiByteToWideChar failed with code %li\n", ret); + return ret; + } + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + return ERROR_OUTOFMEMORY; + } + + pKeyNameW = HeapAlloc (hHeap, 0, len * sizeof (WCHAR)); + if (pKeyNameW == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", + (LONG) len * sizeof (WCHAR)); + return ERROR_OUTOFMEMORY; + } + + if (MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, pKeyNameW, len) == 0) + { + ret = GetLastError (); + ERR ("MultiByteToWideChar failed with code %li\n", ret); + if (HeapFree (hHeap, 0, pKeyNameW) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + return ret; + } + + ret = EnumPrinterDataExW (hPrinter, pKeyNameW, pEnumValues, cbEnumValues, + pcbEnumValues, pnEnumValues); + if (ret != ERROR_SUCCESS) + { + if (HeapFree (hHeap, 0, pKeyNameW) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + TRACE ("EnumPrinterDataExW returned %li\n", ret); + return ret; + } + + if (HeapFree (hHeap, 0, pKeyNameW) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + return ret; + } + + if (*pnEnumValues == 0) /* empty key */ + return ERROR_SUCCESS; + + dwBufSize = 0; + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + if (dwBufSize < ppev->cbValueName) + dwBufSize = ppev->cbValueName; + + if (dwBufSize < ppev->cbData && (ppev->dwType == REG_SZ || + ppev->dwType == REG_EXPAND_SZ || ppev->dwType == REG_MULTI_SZ)) + dwBufSize = ppev->cbData; + } + + TRACE ("Largest Unicode name or value is %li bytes\n", dwBufSize); + + pBuffer = HeapAlloc (hHeap, 0, dwBufSize); + if (pBuffer == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", dwBufSize); + return ERROR_OUTOFMEMORY; + } + + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + len = WideCharToMultiByte (CP_ACP, 0, ppev->pValueName, + ppev->cbValueName / sizeof (WCHAR), pBuffer, dwBufSize, NULL, + NULL); + if (len == 0) + { + ret = GetLastError (); + ERR ("WideCharToMultiByte failed with code %li\n", ret); + if (HeapFree (hHeap, 0, pBuffer) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + return ret; + } + + memcpy (ppev->pValueName, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + + if (ppev->dwType != REG_SZ && ppev->dwType != REG_EXPAND_SZ && + ppev->dwType != REG_MULTI_SZ) + continue; + + len = WideCharToMultiByte (CP_ACP, 0, (LPWSTR) ppev->pData, + ppev->cbData / sizeof (WCHAR), pBuffer, dwBufSize, NULL, NULL); + if (len == 0) + { + ret = GetLastError (); + ERR ("WideCharToMultiByte failed with code %li\n", ret); + if (HeapFree (hHeap, 0, pBuffer) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + return ret; + } + + memcpy (ppev->pData, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + } + + if (HeapFree (hHeap, 0, pBuffer) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + return ret; + } + + return ERROR_SUCCESS; +}

Feb. 19, 2001

Keyboard events and Direct Draw

by Alan Chandler

Actually this is NOW the third attempt the other attempts were yesterday. Apologies to everyone if they have already seen the following. I posted it several hours ago, but I would have expected it to have bounced back to me from the list by now, but it hasn't... ... and I also wanted to add, that I have been desperately trying to find a way to put a breakpoint on any events coming from the keyboard to try and track where they go - but nothing. I cannot find any evidence of any keyboard events being received within wine at all. With --debugmsg traces on channels "key", "keyboard" or "event", I can find nothing registered as I press a key. Perhaps more problematic since its also using the keyboard, but winedbg is not breaking on a breakpoint set on X11DRV_KEYBOARD_HandleEvent The following ... I am trying to understand the behaviour of wine when running Grand Prix Legends (a racing car simulator) - called GPL below. I posted here last week, and since then some updates have occurred to wine that improve things. Namely the colours now all come out correct. However, I am still trying to find out why key presses don't get fed into the program. This has the unfortunate affect, that once you have told the program to exit, you have to wait several minutes for the credits to scroll by since in the program under Windows, hitting return is the only way to kill these off. This is made worse by the fact that the DirectDraw window created by the program forceses itself on top of all the others so that whilst is there most ofther windows are fully or partially obscured (on any virtual desktop). This makes further debugging extremely difficuly. I am pretty sure the program (GPL) is not trying to use direct input for the keyboard, which implies it is expecting keypress messages on its winproc queue. However I don't know which one. With use of --debugmsg I think it creates one window, and then uses a Direct Draw call SetCooperativeLevel to set this window to full screen and exclusive mode. This window is then made active. Inside wine, dlls/ddraw/dsurface/user.c - there is a routine called when a direct draw surface is to be created. Last week Gavriel State suggested that I look at the #define OWN_WINDOW and comment it out. I tried that, and if I do, the game produces no output. However, when this #define is defined I do get the proper output (I have set the game and wine to only assume a 640x480 screen so its a window created in the upper left of my screen). Mouse events are captured properly, but keyboard events do not seem to be. Instead they seem to be directed at the underlying window from which wine was started (or if running winedbg the debug window). Looking at the code within the dsurface/user.c file, it appears to me that keyboard events received are passed to the orginal DirectDraw window. Therefore I don't understand why its not working. I guess the question I am asking is what are the differences between windows and wine here - I have very little knowledge of windows or x windows operation (other than what a learned about windows 5 years ago by reading manuals - but never actually writing code) so forgive me - and what could GPL doing to actually get keypresses. Some thoughts a) There is a call in the trace "CreateDesktopWindow" a little before the other windows calls. Is this Wine or GPL creating this window b) When I run the game under Windows you can ALT-TAB between two tasks. Maybe this other task has a dummy window taking keypresses and that somehow wine is not emulating windows behaviour correctly when automatically linking keypresses to the DirectDraw window Any comments? Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

Feb. 18, 2001

Re: CRITICAL_SECTION alignment

by Ulrich Weigand

Josh DuBois wrote: > Just as Ulrich suggested, the typedef of the CRITICAL_SECTION struct > was inside a #pragma pack(1) block. On the ppc, this made > CRITICAL_SECTIONs always (or very often) get put on 2-byte boundaries. Aha! ;-) I'd suggest we should try and use pack() as sparingly as possible, e.g. by surrounding only single struct definitions with it. Those large #pragma pack() blocks can be really confusing ... > I didn't expect #pragma pack() to affect the alignment of types - I just > thought it would cause structures to take up the minimum required amount > of room. Seems it makes both members within a structure _and_ separate > structures get tightly packed. Or so I gather. This is really the same thing. The alignment requirement of a structure is the maximum (well, least common multiple) of the alignment requirements of all its member. #pragma pack(1) says that for all subsequent struct definitions, every member's alignment requirement is artificially set to 1. Hence, the struct's alignment requirement is also 1 ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

Feb. 18, 2001

Re: winehq mailserver troubles

by James A. Sutherland

On Sun, 18 Feb 2001, Ove Kaaven wrote: > Looks like mail to winehq was refused since yesterday because 30 sendmail > processes was hung trying to deliver mail to some guy at ameritech.net > (timed out connections etc), and since this was a limit in sendmail, it > refused further incoming connections, and the secondary mailserver at > corel didn't want winehq mails, so all incoming mails have been bounced by > it... you'll probably all need to resend any bounced mails, I think. > > But it seems the hanging sendmail processes are already building up again. > Let's see... should I disable the culprit's subscription, or try to > compile a newer sendmail (if available), or maybe install some other MTA > software, like exim? Hmm... Well, I'm obviously biased given exim's origins... however, upgrading sounds like the best solution. You might be able to do something with sendmail's configuration (switch to "deferred" delivery mode then run sendmail -q frequently??), but upgrading sounds like a better bet. FWIH, qmail is better than exim at outgoing mail. Don't tell the exim authors I said that, though :-) James.

Feb. 18, 2001

winehq mailserver troubles

by Ove Kaaven

Looks like mail to winehq was refused since yesterday because 30 sendmail processes was hung trying to deliver mail to some guy at ameritech.net (timed out connections etc), and since this was a limit in sendmail, it refused further incoming connections, and the secondary mailserver at corel didn't want winehq mails, so all incoming mails have been bounced by it... you'll probably all need to resend any bounced mails, I think. But it seems the hanging sendmail processes are already building up again. Let's see... should I disable the culprit's subscription, or try to compile a newer sendmail (if available), or maybe install some other MTA software, like exim? Hmm...

Feb. 18, 2001

Re: various config files for various applications

by Martin Pilka

hello again! after discussion we discovered quite big lack of this model: maintenance. the config file could easily exceed any reasonable size, and that is something we probably don't want (wine-users: send your config file...). so here is the revision: application specific config information could be stored in separate directory (let's say ~/.wine/app-config), one configuration per file. each file will contain an entry which determines its validity, e.g. "Filename" = "homesite*.exe". then there will be the [DllOverrides] section and maybe some others. this breaks wine configuration into two pieces: application independent part (stored in ~/.wine/config, contains drives, paths and all other independent stuff) and application dependent part (stored in ~/.wine/app-config, contains things like [DllOverrides]). on startup wine will load ~/.wine/config and pass through files stored in ~/.wine/app-config directory. the first match against regular expression defined in these files (Filename=...) causes to overwrite some sections from ~/.wine/config. the advantage is much easier maintenance. the disadvantage could be that you can't see the whole configuration in ~/.wine/config file anymore - some settings could be overwritten by optional file in ~/.wine/app-config. what do you think? martin

Feb. 18, 2001

Re: Perl/Wine extension for perusal

by Eric Pouech

John F Sturtz wrote: > > Greetings. > > I work for CodeWeavers here in St Paul. Awhile back, I was set to > the task of working on winetest, a Wine application which provided a > flex/bison-based parser for a little scripting language from which Wine > API functions could be called. The idea was that one could write test > scripts which would call Wine API functions and examine the results, > and the scripts could be used for regression testing of Wine. > > The scripting language began life with a rather Perl-ish syntax, > and as functionality got added, it got more so. Eventually (about > the time I had implemented a pack function, and wanted an unpack), > I decided to see if I could write a Perl extension that provided > a gateway for calling Wine API functions. That way, scripts for > regression testing could be written directly in Perl instead. from a pure testing standpoint, using perl would be great. but, how will you cope with structure passing, callbacks and all the other great ^ - ^ stuff from the MS API ? (not even talking about the threads) ? on the other hand, for lots of API this would be a very good tool (thinking first on all the string, file manipulation routines - starting with the registry) I also started to think (and write the very first pieces) of a test harness. If you like to, I'm fully open to discuss all that with you. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Feb. 17, 2001

Re: Perl/Wine extension for perusal

by Alan Gonzalez

I believe this will work out of the box on cygwin for windows using the perl 5.6.1 that is bundled with it. No need for ActiveState. Alan > 2) Whether there's anyone who is both a serious Perl > guru and a serious Windows guru (I am marginally > the former and nowhere near the latter) who might > like to take a stab at getting the extension to > work under Windows Perl. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

Feb. 17, 2001