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

TCP/IP networking and registry keys
by Alan Chandler March 6, 2001

March 6, 2001

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

3 2

New execution behavior
by Duane Clark Feb. 28, 2001

Feb. 28, 2001

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

1 0

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

Feb. 28, 2001

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

1 0

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

Feb. 27, 2001

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

1 0

Re: winspool.drv initialization problem
by Alexandre Julliard Feb. 27, 2001

Feb. 27, 2001

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

3 3

winspool.drv initialization problem
by Ian Pilcher Feb. 26, 2001

Feb. 26, 2001

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 ========================================================================

2 1

Re: undefined symbol: GetPrinterDataA
by Alexandre Julliard Feb. 26, 2001

Feb. 26, 2001

"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

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard Feb. 26, 2001

Feb. 26, 2001

"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

1 0

undefined symbol: GetPrinterDataA
by Ian Pilcher Feb. 26, 2001

Feb. 26, 2001

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 ========================================================================

5 4

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard Feb. 26, 2001

Feb. 26, 2001

"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

2 1

Re: undefined symbol: GetPrinterDataA
by gerard patel Feb. 26, 2001

Feb. 26, 2001

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

1 0

Re: undefined symbol: GetPrinterDataA
by Ian Pilcher Feb. 26, 2001

Feb. 26, 2001

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 ========================================================================

2 3

Re: various config files for various applications
by Alexandre Julliard Feb. 26, 2001

Feb. 26, 2001

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

3 2

Re: Re: undefined symbol: GetPrinterDataA
by Eric Pouech Feb. 26, 2001

Feb. 26, 2001

>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

2 1

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard Feb. 26, 2001

Feb. 26, 2001

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

2 1

Re: Speeding up wineserver synchronization objects with shared memory
by Michael McCormack Feb. 26, 2001

Feb. 26, 2001

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)

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Michael McCormack Feb. 26, 2001

Feb. 26, 2001

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

1 0

Re: [PATCH] 16 bits print dialog
by Dmitry Timoshkov Feb. 25, 2001

Feb. 25, 2001

"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.

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Robert O'Callahan Feb. 25, 2001

Feb. 25, 2001

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

4 6

Printer setup dialog enhancement
by Duane Clark Feb. 24, 2001

Feb. 24, 2001

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:

1 0

SHLocalAlloc
by J.Brown (Ender/Amigo) Feb. 24, 2001

Feb. 24, 2001

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?!?" | +-------------------------+------------------------------+

2 1

huge library renaming ?
by Andreas Mohr Feb. 24, 2001

Feb. 24, 2001

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

6 7

Re: ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'
by Alexandre Julliard Feb. 23, 2001

Feb. 23, 2001

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

2 1

./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'
by Gerald Pfeifer Feb. 23, 2001

Feb. 23, 2001

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/

1 0

Re: Perl/Wine extension for perusal
by Alexandre Julliard Feb. 23, 2001

Feb. 23, 2001

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

2 1

IBM Websphere Studio
by David.Goodenough＠dga.co.uk Feb. 23, 2001

Feb. 23, 2001

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.

1 0

Re: Perl/Wine extension for perusal
by Alexandre Julliard Feb. 23, 2001

Feb. 23, 2001

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

3 2

Re: huge library renaming ?
by Alexandre Julliard Feb. 23, 2001

Feb. 23, 2001

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

1 0

RE: huge library renaming ?
by Patrik Stridvall Feb. 23, 2001

Feb. 23, 2001

> 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.

2 1

RE: huge library renaming ?
by Patrik Stridvall Feb. 23, 2001

Feb. 23, 2001

> 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.

1 0

Re: page scroller improvements for IE4
by Guy L. Albertelli Feb. 23, 2001

Feb. 23, 2001

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>

1 0

Notes and Java test on 20010216 drop
by David.Goodenough＠dga.co.uk Feb. 22, 2001

Feb. 22, 2001

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.

1 0

Corel XaraX
by Alexander Kellett Feb. 22, 2001

Feb. 22, 2001

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

1 0

Additional registry key for PS driver
by Ian Pilcher Feb. 22, 2001

Feb. 22, 2001

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 ========================================================================

1 0

ms apps with muncher
by Josh Walker Feb. 21, 2001

Feb. 21, 2001

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

3 4

Re: Wine & Wrapster/UnWrapper/etc
by gerard patel Feb. 21, 2001

Feb. 21, 2001

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

1 0

Re: Perl/Wine extension for perusal
by Eric Pouech Feb. 21, 2001

Feb. 21, 2001

> 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

1 0

Re: Shell32 improvements
by gerard patel Feb. 21, 2001

Feb. 21, 2001

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

1 0

Re: Wine winmm
by Eric Pouech Feb. 21, 2001

Feb. 21, 2001

(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

2 1

various config files for various applications
by Martin Pilka Feb. 20, 2001

Feb. 20, 2001

hello everybody! i know it was already at least mentioned here - how to provide config file that works without change for more than one application. what do you think about this concept? the changes to config file are relevant to some sections only. i think these are important: * [DllDefaults], [DllOverrides] * [wine] - because of path variable, some programs want to have something specific there * [x11drv] - for example something runs better in managed mode, something not * i'm not quite sure about [fonts], [spooler] so probably we need to make these sections application dependent. when we parse the config file we don't have a lot information about the application we're going to run - in fact the file name only. anyway that's probably enough. so maybe we could add the new optional sections like [x11drv-homesite*.exe]. the string after "-" sign could be an case insensitive regular expression. when some of this x11drv optional sections match the condition about its filename, it's taken and no more x11drv sections are considered. if not, the default non-optional x11drv section is taken. i think we shouldn't follow some "inherit" concept because it could dim things a lot. simple "this and only this section is valid" should be enough. and of course there have to be some trace message which section was really used. i believe this could significantly increase the number of applications which run fine with the default config file we provide. of course the ideas how to improve/wholly change this concept are welcomed. martin

4 6

Strange wine crashes with /dos mounted "rw" with Unreal
by FT Rathore Feb. 20, 2001

Feb. 20, 2001

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

1 0

Re: Perl/Wine extension for perusal
by Jeremy White Feb. 20, 2001

Feb. 20, 2001

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

1 0

Re: Baldurs Gate 2 near perfect with transgaming and disk change problem
by FT Rathore Feb. 20, 2001

Feb. 20, 2001

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-) >

1 0

GetFullPathName & trailing backslash in path arg (Heroes of Might & Magic III problem)
by Tadeusz Szczyrba Feb. 20, 2001

Feb. 20, 2001

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

1 0

Re: [gphoto-devel] Running Polaroid PhotoMax under wine
by Nathan Stenzel Feb. 19, 2001

Feb. 19, 2001

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

1 0

GDI.EXE
by Johan Gill Feb. 19, 2001

Feb. 19, 2001

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

2 1

Re: Overlapped read/write fix
by Ove Kaaven Feb. 19, 2001

Feb. 19, 2001

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.

1 0

dlls/winsock/socket.c patch
by Chris Morgan Feb. 19, 2001

Feb. 19, 2001

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).

1 0

Wine & Wrapster/UnWrapper/etc
by David Luyer Feb. 19, 2001

Feb. 19, 2001

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

1 0

mailserver operational
by Ove Kaaven Feb. 19, 2001

Feb. 19, 2001

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

1 0

EnumPrinterDataEx - one more time
by Ian Pilcher Feb. 19, 2001

Feb. 19, 2001

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

1 0

Keyboard events and Direct Draw
by Alan Chandler Feb. 18, 2001

Feb. 18, 2001

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

1 0

Re: CRITICAL_SECTION alignment
by Ulrich Weigand Feb. 18, 2001

Feb. 18, 2001

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

1 0

winehq mailserver troubles
by Ove Kaaven Feb. 18, 2001

Feb. 18, 2001

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...

2 1

Perl/Wine extension for perusal
by John F Sturtz Feb. 17, 2001

Feb. 17, 2001

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. I have an initial version done. The practical upshot is that from a Perl script (after going through the proper incantations), you can write something like this: $atom = kernel32->GlobalAddAtomA("bark"); and the script will call the Wine GlobalAddAtomA() function, passing the string "bark", and return the result in $atom, which can then be examined to determine if it's what it should be. At Alexandre's suggestion, I've tossed a tarball of the stuff out on wine.codeweavers.com at ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz for anyone who's interested in having a look (just download the tarball, untar/ungzip it, and look at the README to get started). In particular, I'm curious as to: 1) Whether it works for anyone who tries it 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. 3) Whether any make guru would want to take a stab at writing a real makefile for the package (as opposed to the hack make ksh script I've done) as well as any other comments. Any input is appreciated. Thanks. John Sturtz jsturtz(a)codeweavers.com

3 2

Re: Perl/Wine extension for perusal
by Alan Gonzalez Feb. 17, 2001

Feb. 17, 2001

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/

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by Mike McCormack Feb. 17, 2001

Feb. 17, 2001

Hi, There are some other issues with wineserver that we should consider at the same time as speed of mutexes. Things that come to mind are: * VirtualAlloc/Virtual Protect on other processes memory * inefficiency of async i/o and file i/o in general * lack of interprocess messaging an difficulty of implementing it efficiently with wineserver's architecture The more i think about it, the more i believe that we do need to add *something* into the kernel to improve the efficiency and flexability of the wineserver. Mike ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

winelib and active-X dll´s
by christian richter Feb. 16, 2001

Feb. 16, 2001

hello, has anyone an idea how I can use Functions from Active-X dll´s in my C-programm? those dll´s seem to export com-objects or classes, and i do not know how to use those classes... is it possible ? how `?

1 0

Re: VerQueryValue[A|W]
by François Jacques Feb. 16, 2001

Feb. 16, 2001

James, Where's HEAP_strudupAtoW called from? For all OLE/COM DLLs, strings should be internally stored as OLECHAR* (wchar_t*) strings. I remember it wasn't the case with typelib.c when I started playing with it. A side-effect of that is that we had to HEAP_strdupAtoW / HEAP_strdupWtoA all over the place in that file - making ASCII-based stored strings more expensive than OLECHAR*-based strings (yeah yeah we're still converting back to ASCII strings a lot, but that's for tracing - not run-time) For all OLE/COM DLLs, I would internally store the strings as OLECHAR* strings (or BSTR, as you wish...) wherever it makes sense to do it, e.g. most places. Cheers, Francois -----Message d'origine----- De : James Hatheway <james(a)macadamian.com> À : amohr(a)codeweavers.com <amohr(a)codeweavers.com> Cc : WineHQ Devel <wine-devel(a)winehq.com> Date : 15 février, 2001 10:44 Objet : Re: VerQueryValue[A|W] >> > To convert an ASCII string to Unicode, you can use the >> > function HEAP_strdupAtoW, as in: >> Wrong ;-) > >Yeah, I know, Huw already set me straight on that. ^_^ > > >> HEAP_str* is deprecated (the header file says so). >> Use MultiByteToWideChar() or WideCharToMultiByte() instead. > >I'll admit I wrote the email when my brain wasn't quite >working (by def'n anytime after 1am), thought to >myself "what is that API again?", did a quick search in >WINE, said to myself "oh HEAP_strdupAtoW" >sent a quick email and went to bed. :) That teaches me to >send email without thinking. > >But that gets me to my point. HEAP_strdupAtoW is used in >this capacity 78 times in the WINE source tree (WtoA another >182 times). We should probably change it sometime, since a >lot of people who are writing new code are sure to use >the current code base as an example of "how to do things". > >Out of curiosity, why are we killing these macros? They >seem quite convenient. If it is because they aren't in >standard windows headers, can't we put them somewhere >in include/wine? > > >-James > >-- >James Hatheway >Software Designer - Macadamian Technologies, Inc. >james(a)macadamian.com ~ http://www.macadamian.com > > "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" > "One could be happy if the air were as pure as the beer" > > > >

2 1

Re: GetPixel bug!!!
by Ove Kaaven Feb. 16, 2001

Feb. 16, 2001

On Fri, 16 Feb 2001, François Gouget wrote: > I just wanted to avoid copying the pixmap back into the DIB for the > GetPixel case since obviously it has not been modified. That's what > commit is here for of course. OTOH the subtleties of lossy are a bit > lost on me. AFAICS it's always set to false so I'll just do the same. The "lossy" is only meant for extreme optimization cases - "lossy" suppresses the copying entirely, and is only meant to be useful when some operation would completely overwrite/obliterate everything on the DIB surface anyway, for example, a SRCCOPY blit that'd cover the entire destination DIB. In such cases, it'd just be a waste to do a copy only to have all of the copied data overwritten, it would be more efficient to not copy anything then. But such optimization checks isn't being done yet. I think the reason GetPixel/PutPixel hasn't done DIB updates yet is because it's wasteful to copy the entire DIB graphic back and forth for a single pixel, when it should really be easy to add code that could access the DIB data directly... just that nobody did that yet. We're going to need a proper DIB (aka FB) graphics engine someday...

1 0

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall Feb. 16, 2001

Feb. 16, 2001

> > I think you have missunderstood what the judges meant. > > > > The fact the computer programs are functional doesn't take away > > their copyrightabillity. But copyright only protects the creative > > expression and then the form of these expressisions are dictated > > by external factors such as in the courts words "compatibility > > requirements and industry demands" they are not creative expression > > and thus not copyrightable. > > > > It almost sounded to me as if they were saying that it was purely > functional. But then again I didn't read it really > carefully. The correct > representation is that they are creative but then yield a > function. The > creative part (the source code) should be copyrightable, but > the actual > functionality should not be, and it should be perfectly legal > to duplicate > the functionality of a piece of code so long as you do not > actually verbatim > copy the copyrighted source code. Exactly. > Protecting the functionality would be an issue for patents and not > copyrights. And with the exception of things like the RSA > patent, software > patents for the most part have not been working. Of course, IIRC the > RSA patent is not actually a software patent but a patent on > a hardware > implementation of the algorithm. Note quite, patents do not protect functiality, they protect a specific way to achieve a certain functionality. For example, you could, providing software patents are valid, patent a specific algoritm that sorts list, but you can't patent all algoritms that have the same functionallity, is this cases that sorts list. Patents are for promoting progress by finding new and better way of achieving some specific functionality. The functionallity (end result) is itself it an idea and not protectable. > > Not that fact that the court said "functional" and not > > "is not a creative expression" is AFAICS largely irrelevant. > > > > But I think I can see what you are after, I you have an "optimal" > > compiler every computer program that are functionally equivivalent > > will be reduced to the same binary form. However that doesn't rob > > the source code from copyright, just the binary form. > > > > Binaries should only be copyrightable in the sense that doing > a verbatim > copy (e.g. copy file.exe newfile.exe) should be protected, Careful, we definitely don't want copyright law to mean that. There have been some strange cases involving whether the representation of the program in memory is a copy. While running an application obviously falls under fair use, such a view might be unfortunate since it like the DMCA will lead to logical contradictions which will enable scrupelus persons to use the confusion in legal arguments. IMHO the only sane definition of copy in the meaning of copyright is something is a copy (or a potential copy) if it is made with the intent to distribute. With potential copy I mean for example offering a protected work for download on a website or on Napster or where ever. All other defintion will lead to logical contradictions AFAICS. For example, if I look at protected work, have a copy been made in my eyes? If I have a camera attached to say my glasses that broadcast everything I see on a website will I be a copyright infringer if I look at a protected work. Without having intent as condition you can nail anybody for copyright infringement. > but if the > compiler happens to generate an exact copy, then so be it. Yes, but two works that are the same or similar by coincidence have never been considered copyright infringment. What I meant is that if the representation is optimal it will be purely functional and thus not protectable at all since copyright doesn't protected that. However since optimal compilers doesn't exist, this distinction is rather meaningless, the binary will always retain some of protected creative expression and thus be protectable as a whole.

1 0

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall Feb. 16, 2001

Feb. 16, 2001

> > The court in that case said: > > > > Computer programs pose unique problems for the > application of the > > "idea/expression distinction" that determines the > extent of copyright > > protection. To the extent that there are many possible ways of > > accomplishing a given task or fulfilling a particular > market demand, > > the programmer's choice of program structure and design > may be highly > > creative and idiosyncratic. However, computer programs > are, in essence, > > utilitarian articles -- articles that accomplish tasks. > As such, they > > contain many logical, structural, and visual display > elements that are > > dictated by external factors such as compatibility requirements > > and industry demands... In some circumstances, even the > exact set of > > commands used by the programmer is deemed functional rather than > > creative for the purposes of copyright. When specific > instructions, > > even though previously copyrighted, are the only and > essential means > > of accomplishing a given task, their later use by > another will not > > amount to infringement. > > > > Hmm, I am not so sure I like all of that. Program code > serves two purposes. For one > thing it is functional, and for another (and actually for the > most part) it has a > human readable structure. I think you have missunderstood what the judges meant. The fact the computer programs are functional doesn't take away their copyrightabillity. But copyright only protects the creative expression and then the form of these expressisions are dictated by external factors such as in the courts words "compatibility requirements and industry demands" they are not creative expression and thus not copyrightable. Not that fact that the court said "functional" and not "is not a creative expression" is AFAICS largely irrelevant. But I think I can see what you are after, I you have an "optimal" compiler every computer program that are functionally equivivalent will be reduced to the same binary form. However that doesn't rob the source code from copyright, just the binary form. Anyway, regardless of whether optimal compilers possible, it still doesn't make copyright of computer programs meaningless, since you really want to be able to change the computer program and an optimal representation of it is not very easy to change. :-) So the creative expression of the source code is really useful and thus promotes progress, so it really should be and indeed is protectable.

2 1

RE: Turkish Keybard
by Nerijus Baliunas Feb. 16, 2001

Feb. 16, 2001

> Adding a turkish keyboard layout. > > -aric Why do you use 28591? Shouldn't it be 28599?

1 0

Re: msvcrt/c++
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> writes: > This is a resubmit of the previous patch. It now manages to do the > setjmp/longjmp stuff 90% in C rather than asm. It also implements setjmp3 > which is needed for programs compiled with VC++ v4.0+, and it should fix the > compilation problem reported on cemw. You should _really_ use register functions instead of inline assembly. Then you can do setjmp/longjmp 100% in C. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Gavriel State <gav(a)transgaming.com> writes: > Definitely a drawback, I agree. But the shared memory area could be relatively > high in the address space, so that a stray pointer is much more likely to run > into unmapped memory and segfault before overwriting crucial data. This is only one failure case, but there are many others; for instance stack corruption that causes the app to jump somewhere inside ReleaseMutex, which will then happily modify the right address in the wrong way. > The only way we're going to be able to get both speed and safety though is > to have some kernel support. While that's beyond the scope of what I'd like > to accomplish in the short term, I think that it's something worth thinking > about more. While the solution proposed by David Howells may be overkill, I'm > not sure that simply changing the communication mechanism as you suggested > (http://www.winehq.com/News/2000-37.html#0) will speed things up enough - > we'll still have the context switch overhead. The main problem is the TLB flush due to switching address spaces; but I don't see any way to avoid this if we want memory protection (which we definitely do). The only way to know if we can make it fast enough is to implement it and benchmark it... > At least in the case of mutexes, I believe that all we need to do is > make sure that the count field is always modified through interlocked > increment/decrement/etc including the wineserver. I think you underestimate the complexity of getting this right. For instance, how do you determine the address of the count field from the mutex handle, keeping in mind that handles can be manipulated from other threads or even other processes (cf. DuplicateHandle)? How do you cope with a thread dying in the middle of an operation? Of course you can ignore all these special cases, and it will even work most of the time. But it's clearly not a viable general solution... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Gavriel State <gav(a)transgaming.com> writes: > After some more thinking, Ove and I have come up with a mechanism that should eliminate > most of the wineserver overhead for mutexes and semaphores, without the need to resort > to a kernel module. We're probably going to give this a try over the next few days, so > any feedback will be very much appreciated. I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important. As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: dlls/ntdll/debugtools.c patch
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Chris Morgan <cmorgan(a)wpi.edu> writes: > Resubmit of this patch. Alexander, is this patch ok? Looks good, but I wonder if we shouldn't add an assert() instead. People are not supposed to use the debug interface to print out huge strings, and printing partial lines messes up the output in multi-threaded programs. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Documentation fixes
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > More readable to a human, perhaps. > > Uh, yes, the source code is meant to be read by humans. winapi_check > is a nice tool but it doesn't justify making the code less readable; Sure but grouping all the variants together doesn't nessary make it less readable to human. It entirely depends on how diffrent the variants are. If for example one variant is an optimized i386 assembler variant and the other is a pure C variant it might be more sensible to group them together, in order to more make people making changes remember to change the other variant. In this case, I personally didn't find either way preferable so I did what was best for winapi_check. > instead it should be fixed to understand the existing constructs That is a quite complicated in this case. > (or > at least don't complain about them). OK. I can easily make it ignore multiple definitions. I will do that.

1 0

Re: Documentation fixes
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > More readable to a human, perhaps. Uh, yes, the source code is meant to be read by humans. winapi_check is a nice tool but it doesn't justify making the code less readable; instead it should be fixed to understand the existing constructs (or at least don't complain about them). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: howto use dll´s in C
by christian richter Feb. 15, 2001

Feb. 15, 2001

Thanks, specmaker could use the dll, but i tried specmaker with severall dll´s and there were only four functions: unload_class, registerServer unregisterServer or something like that, i heared this is because of the COM,ActiveX nature of the dll´s ... can i use those classes in C ??? how,is it maybe possible with corba ? -----Ursprüngliche Nachricht----- Von: Jon Griffiths [mailto:tntjpgriff(a)tsnxt.co.uk] Gesendet: Mittwoch, 14. Februar 2001 14:45 An: christian richter; 'wine-devel(a)winehq.com' Betreff: Re: howto use dll´s in C Hi, If you have the wine sources, or browse them from www.winehq.com, checkout tools/specmaker/README. Also see the Winelib developer guide for details on Winelib in general. Note that if all you want is the string routines, thats a lot of overhead for a few routines. You might find they are available in source form from somewhere else. Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

2 1

Speeding up wineserver syncronization objects with shared memory
by Gavriel State Feb. 15, 2001

Feb. 15, 2001

Hi everyone, We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes. Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock. After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module approach. After re-reading the thread and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work. After some more thinking, Ove and I have come up with a mechanism that should eliminate most of the wineserver overhead for mutexes and semaphores, without the need to resort to a kernel module. We're probably going to give this a try over the next few days, so any feedback will be very much appreciated. Here's what we've been discussing in private email: ============================================================================================ Ove writes: > Gav writes: > > > Alternatively, I wonder if there's some way to speed up synchronization stuff > > through the use of some kind of shared memory area that all wine processes know > > about. The shared memory area could be used to do mutexes with atomic test-and- > > set operations. > > Maybe. But we probably don't want extensive busy waits, so we'd need to > call the wineserver when we need to wait. And the wineserver isn't really > designed to do bus-locked atomic access to such shared areas itself. But > perhaps with some client cooperation... in win32, a mutex is just a > different (and slower) kind of a critical section, anyway (but since it's > handle-based it can work across address spaces). > > If each mutex had a wcount field shared among all clients, we could do... > > ReleaseMutex: > wc = InterlockedDecrement(&wcount) > if wc > 0 > call wineserver's ReleaseMutex > > WaitForSingleObject: > wc = InterlockedIncrement(&wcount) > if wc < 0 > return WAIT_OBJECT_0 > call wineserver's WaitForSingleObject > > which would at least do something about the > ReleaseMutex/WaitForSingleObject pairs in the same thread... That's exactly the kind of thing I was thinking about. We can probably do the same for the CriticalSection semaphores as well. I don't think that we can do anything to speed up Events though. So the next question is: what's the best way to manage the shared area for each mutex/semaphore? We could just expose the wineserver handle table directly in the shared memory area, expanding the handle_entry struct in the server with a DWORD to server as the count field. Theoretically it brings up security concerns, but I don't think that we care that much at this point. ============================================================================================ Thoughts, anyone? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

RE: Documentation fixes
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > * dlls/winedos/dosvm.c, > > dlls/winedos/module.c: > > - Added documentation > > - Reorganized the no-DOS support. > > I don't think adding a #ifdef around each function is a good > idea. It's much more readable with a single #ifdef around the whole > file IMO. More readable to a human, perhaps. I'm not sure that I agree, but I don't really care much either way. Let me explain why I did it insteed. Currently winapi_check tried to check whether API functions have the correct inline documentation and the future some other application will generate the .spec files from inline documentation and function prototype. In order to be able to easily do this, it is IMHO much better if all the compile time depend variants is groups together in some standardized way in order for the tool to easily understand that variants exist and under what cirumstances they exist. But sure, we could easily add a kludge in both winapi_check and any future tools what just ignore any multiple occurance of an already documented function. It will be more errorprone but since this is quite rare perhaps it will not matter so much. Anyway, I don't really very much, so just say how want it: 1. Some way similar to mine (easily parsable structure) 2. Just kludge over this rare case (ignore multiple) 3. Some other way.

1 0

Re: VerQueryValue[A|W]
by James Hatheway Feb. 15, 2001

Feb. 15, 2001

> > To convert an ASCII string to Unicode, you can use the > > function HEAP_strdupAtoW, as in: > Wrong ;-) Yeah, I know, Huw already set me straight on that. ^_^ > HEAP_str* is deprecated (the header file says so). > Use MultiByteToWideChar() or WideCharToMultiByte() instead. I'll admit I wrote the email when my brain wasn't quite working (by def'n anytime after 1am), thought to myself "what is that API again?", did a quick search in WINE, said to myself "oh HEAP_strdupAtoW" sent a quick email and went to bed. :) That teaches me to send email without thinking. But that gets me to my point. HEAP_strdupAtoW is used in this capacity 78 times in the WINE source tree (WtoA another 182 times). We should probably change it sometime, since a lot of people who are writing new code are sure to use the current code base as an example of "how to do things". Out of curiosity, why are we killing these macros? They seem quite convenient. If it is because they aren't in standard windows headers, can't we put them somewhere in include/wine? -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

1 0

Re: New EnumPrinterDataEx
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Ian Pilcher <pilcher(a)concentric.net> writes: > In theory, yes. But what about the case of a mistake on my part (or > the part of the person who implemented the underlying call)? We all > do everything possible to produce error-free code, but mistakes *do* > happen. IMHO the likelihood that your macros are going to introduce new bugs is larger than the likelihood that you are ever going to catch a legitimate failure from HeapFree(). Not to mention that there are already WARNs in the heap code that will catch the problem first, so your messages are redundant. Checking for errors is good if you actually handle failures; but if you don't do anything it just obscures the code for no good reason. -- Alexandre Julliard julliard(a)winehq.com

2 1

VersionInfo for built-in DLLs
by Dmitry Timoshkov Feb. 15, 2001

Feb. 15, 2001

Hello all. This patch adds version information to the built-in GDI32.DLL. Attached test program now able to retrieve and display version information for both 32-bit and 16-bit modules. For instance "about.exe notepad.exe" will show information about 16-bit notepad, "about.exe gdi32.dll" - about built-in gdi32.dll. To do: Add 16-bit version information. Before I'll send it to wine-patches I would like to hear your comments and suggestions.

1 0

Re: VerQueryValue[A|W]
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

lawson_whitney(a)juno.com writes: > AOL 5.0 does this, so I guess it is allowed by some flavors of windows. > > ChangeLog: > * dlls/version/info.c: > Lawson Whitney <lawson_whitney(a)juno.com> > If VerQueryValueA is called with a PE resource, cast the call > to VerQueryValueW. Shouldn't you convert the lpSubBlock string to Unicode first? -- Alexandre Julliard julliard(a)winehq.com

4 5

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> Patrik Stridvall wrote: > > > > One fly in the legal ointment is that while the headers may not be > > > copyrighable, the shrinkwrap license may still be legal > as a contract. > > > There's a case where a court suggested that someone who > buys a copy > > > of a product that contains a shrinkwrap license agreement > and unwraps > > > it is legally bound to follow it, while the person who > later finds the > > > unwrapped CD 'on the street' with no such license is > allowed to copy > > > the portions that are unprotected by copyright. > > > > If that is so, wouldn't it mean that if you have a pirated > copy of the > > headers > > you can legally copy and distribute parts that are > unprotected by copyright. > > :-) > > > > Oh, the irony of it all. You don't need to use a pirated copy either just borrow a friends computer that has the headers legally installed and copy any part unprotected by copyright. Any "contract" can only bind him. :-)

1 0

RE: Header file legal issues (was Re: process.h patch)
by Patrik Stridvall Feb. 15, 2001

Feb. 15, 2001

> One fly in the legal ointment is that while the headers may not be > copyrighable, the shrinkwrap license may still be legal as a contract. > There's a case where a court suggested that someone who buys a copy > of a product that contains a shrinkwrap license agreement and unwraps > it is legally bound to follow it, while the person who later finds the > unwrapped CD 'on the street' with no such license is allowed to copy > the portions that are unprotected by copyright. If that is so, wouldn't it mean that if you have a pirated copy of the headers you can legally copy and distribute parts that are unprotected by copyright. :-) Anyway, you don't need to go to such extremes, since the legal status of shrinkwrap licenses in Europe is much more doubtful, just have somebody in Europe do it. I can't see why something posted on wine-patches shouldn't be equal with found on the street, in the meaning that things that is unprotected by copyright can be legally incorperated in the main tree. This is probably true regardless of the legal status of shrinkwrap licenses in Europe, especially since it is IMHO entire reasonable, given existing European cases, to assume that they don't have an legally meaning. > It's unclear where > the anti-trust issue fits in there. I pass, not my area of expertize. :-) > Food for thought, anyhow... Yes.

3 2

Re: process.h patch
by Alexandre Julliard Feb. 15, 2001

Feb. 15, 2001

Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> writes: > Until we have MS style headers, at least declare msvcrt functions extern "C" > so C++ Winelib programs will link. > > I didn't get any feedback to my headers patch. Alexandre, what do I need > to do to get some headers into CVS? Or is that not the plan? Well, I don't know, I was hoping to get some feedback from the winelib experts out there on whether this is better than the approach with macros suggested by David. -- Alexandre Julliard julliard(a)winehq.com

6 7

Re: Re: recording sound?
by Eric Pouech Feb. 15, 2001

Feb. 15, 2001

>winmm wave recording is supposed to be supported, at least at the >low-level wave API level. Maybe less so at the MCI level, though, support at the MCI level should be more or less ok... (at least the Macadamiam folks did a great effort there) >and not >supported at all yet in the DirectSound layer. What kind of API does it >use to record these sounds? You don't say what kind of app it is... post the output of runnnig with the -debugmsg +wave,+mciwave,+dsound would help us pinpointing the issue A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

4 7

Re: Documentation fixes
by Alexandre Julliard Feb. 14, 2001

Feb. 14, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > * dlls/winedos/dosvm.c, > dlls/winedos/module.c: > - Added documentation > - Reorganized the no-DOS support. I don't think adding a #ifdef around each function is a good idea. It's much more readable with a single #ifdef around the whole file IMO. -- Alexandre Julliard julliard(a)winehq.com

1 0

Some strange exception crash
by Lionel Ulmer Feb. 14, 2001

Feb. 14, 2001

Hi all, While trying to debug DMute (http://www.mrao.cam.ac.uk/~gg215/dm/) I get the following crash : Call kernel32.674: SetUnhandledExceptionFilter(0042a8a0) ret=0042a898 fs=008f Ret kernel32.674: SetUnhandledExceptionFilter() retval=00000000 ret=0042a898 fs=008f (...) Call kernel32.473: InterlockedDecrement(fffffff4) ret=00438683 fs=008f trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 trace:seh:EXC_CallHandler calling handler at (nil) code=c0000005 flags=0 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 trace:seh:EXC_CallHandler calling handler at 0x4005ac40 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 2 trace:seh:EXC_CallHandler calling handler at (nil) code=c0000005 flags=10 And it never stops.... It does a segfault when not using --debugmsg +seh. So I am wondering why the exception handler is set to 'NULL' at this point (I am also wondering where that damn application got the 'fffffff4' to use as a 'mutex', but that is another problem :-) ). Anyone has a clue ? Lionel -- Lionel Ulmer - lionel.ulmer(a)free.fr My Advogato Wine diary : http://www.advogato.org/person/bbrox/

1 0

Re: Registry patch
by Alexandre Julliard Feb. 14, 2001

Feb. 14, 2001

davep <davep(a)cyw.uklinux.net> writes: > > Could you please send me a +reg,+server trace of the offending calls? > > Attached. Thanks; does this fix it? Index: dlls/advapi32/registry.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/advapi32/registry.c,v retrieving revision 1.20 diff -u -r1.20 registry.c --- dlls/advapi32/registry.c 2001/01/06 01:29:18 1.20 +++ dlls/advapi32/registry.c 2001/02/13 22:11:00 @@ -447,6 +447,7 @@ return ERROR_INVALID_PARAMETER; status = NtQueryKey( hkey, KeyFullInformation, buffer, sizeof(buffer), &total_size ); + if (status && status != STATUS_BUFFER_OVERFLOW) goto done; if (class) { @@ -460,32 +461,30 @@ status = NtQueryKey( hkey, KeyFullInformation, buf_ptr, total_size, &total_size ); } - if (!status) + if (status) goto done; + + if (class_len && (info->ClassLength/sizeof(WCHAR) + 1 > *class_len)) { - if (class_len && (info->ClassLength/sizeof(WCHAR) + 1 > *class_len)) - { - status = STATUS_BUFFER_OVERFLOW; - } - else - { - memcpy( class, buf_ptr + info->ClassOffset, info->ClassLength ); - class[info->ClassLength/sizeof(WCHAR)] = 0; - } + status = STATUS_BUFFER_OVERFLOW; + } + else + { + memcpy( class, buf_ptr + info->ClassOffset, info->ClassLength ); + class[info->ClassLength/sizeof(WCHAR)] = 0; } } + else status = STATUS_SUCCESS; - if (!status || status == STATUS_BUFFER_OVERFLOW) - { - if (class_len) *class_len = info->ClassLength / sizeof(WCHAR); - if (subkeys) *subkeys = info->SubKeys; - if (max_subkey) *max_subkey = info->MaxNameLen; - if (max_class) *max_class = info->MaxClassLen; - if (values) *values = info->Values; - if (max_value) *max_value = info->MaxValueNameLen; - if (max_data) *max_data = info->MaxValueDataLen; - if (modif) *modif = info->LastWriteTime; - } + if (class_len) *class_len = info->ClassLength / sizeof(WCHAR); + if (subkeys) *subkeys = info->SubKeys; + if (max_subkey) *max_subkey = info->MaxNameLen; + if (max_class) *max_class = info->MaxClassLen; + if (values) *values = info->Values; + if (max_value) *max_value = info->MaxValueNameLen; + if (max_data) *max_data = info->MaxValueDataLen; + if (modif) *modif = info->LastWriteTime; + done: if (buf_ptr != buffer) HeapFree( GetProcessHeap(), 0, buf_ptr ); return RtlNtStatusToDosError( status ); } @@ -502,7 +501,7 @@ NTSTATUS status; char buffer[256], *buf_ptr = buffer; KEY_FULL_INFORMATION *info = (KEY_FULL_INFORMATION *)buffer; - DWORD total_size; + DWORD total_size, len; TRACE( "(0x%x,%p,%ld,%p,%p,%p,%p,%p,%p,%p,%p)\n", hkey, class, class_len ? *class_len : 0, reserved, subkeys, max_subkey, values, max_value, max_data, security, modif ); @@ -511,6 +510,7 @@ return ERROR_INVALID_PARAMETER; status = NtQueryKey( hkey, KeyFullInformation, buffer, sizeof(buffer), &total_size ); + if (status && status != STATUS_BUFFER_OVERFLOW) goto done; if (class || class_len) { @@ -524,39 +524,37 @@ status = NtQueryKey( hkey, KeyFullInformation, buf_ptr, total_size, &total_size ); } - if (!status) - { - DWORD len = WideCharToMultiByte( CP_ACP, 0, - (WCHAR *)(buf_ptr + info->ClassOffset), - info->ClassLength/sizeof(WCHAR), - NULL, 0, NULL, NULL ); - if (class_len) - { - if (len + 1 > *class_len) status = STATUS_BUFFER_OVERFLOW; - *class_len = len; - } - if (class && !status) - { - WideCharToMultiByte( CP_ACP, 0, - (WCHAR *)(buf_ptr + info->ClassOffset), - info->ClassLength/sizeof(WCHAR), - class, len, NULL, NULL ); - class[len] = 0; - } - } - } + if (status) goto done; - if (!status || status == STATUS_BUFFER_OVERFLOW) - { - if (subkeys) *subkeys = info->SubKeys; - if (max_subkey) *max_subkey = info->MaxNameLen; - if (max_class) *max_class = info->MaxClassLen; - if (values) *values = info->Values; - if (max_value) *max_value = info->MaxValueNameLen; - if (max_data) *max_data = info->MaxValueDataLen; - if (modif) *modif = info->LastWriteTime; - } + len = WideCharToMultiByte( CP_ACP, 0, + (WCHAR *)(buf_ptr + info->ClassOffset), + info->ClassLength/sizeof(WCHAR), + NULL, 0, NULL, NULL ); + if (class_len) + { + if (len + 1 > *class_len) status = STATUS_BUFFER_OVERFLOW; + *class_len = len; + } + if (class && !status) + { + WideCharToMultiByte( CP_ACP, 0, + (WCHAR *)(buf_ptr + info->ClassOffset), + info->ClassLength/sizeof(WCHAR), + class, len, NULL, NULL ); + class[len] = 0; + } + } + else status = STATUS_SUCCESS; + + if (subkeys) *subkeys = info->SubKeys; + if (max_subkey) *max_subkey = info->MaxNameLen; + if (max_class) *max_class = info->MaxClassLen; + if (values) *values = info->Values; + if (max_value) *max_value = info->MaxValueNameLen; + if (max_data) *max_data = info->MaxValueDataLen; + if (modif) *modif = info->LastWriteTime; + done: if (buf_ptr != buffer) HeapFree( GetProcessHeap(), 0, buf_ptr ); return RtlNtStatusToDosError( status ); } @@ -821,6 +819,7 @@ } else if (status != STATUS_BUFFER_OVERFLOW) goto done; } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = total_size - info_size; @@ -880,36 +879,35 @@ buf_ptr, total_size, &total_size ); } - if (!status) + if (status) goto done; + + if (is_string(info->Type)) { - if (is_string(info->Type)) + DWORD len = WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), + (total_size - info_size) /sizeof(WCHAR), + NULL, 0, NULL, NULL ); + if (data && len) { - DWORD len = WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), - (total_size - info_size) /sizeof(WCHAR), - NULL, 0, NULL, NULL ); - if (data && len) + if (len > *count) status = STATUS_BUFFER_OVERFLOW; + else { - if (len > *count) status = STATUS_BUFFER_OVERFLOW; - else - { - WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), - (total_size - info_size) /sizeof(WCHAR), - data, len, NULL, NULL ); - /* if the type is REG_SZ and data is not 0-terminated - * and there is enough space in the buffer NT appends a \0 */ - if (len < *count && data[len-1]) data[len] = 0; - } + WideCharToMultiByte( CP_ACP, 0, (WCHAR *)(buf_ptr + info_size), + (total_size - info_size) /sizeof(WCHAR), + data, len, NULL, NULL ); + /* if the type is REG_SZ and data is not 0-terminated + * and there is enough space in the buffer NT appends a \0 */ + if (len < *count && data[len-1]) data[len] = 0; } - total_size = len + info_size; - } - else if (data) - { - if (total_size - info_size > *count) status = STATUS_BUFFER_OVERFLOW; - else memcpy( data, buf_ptr + info_size, total_size - info_size ); } + total_size = len + info_size; } - else if (status != STATUS_BUFFER_OVERFLOW) goto done; + else if (data) + { + if (total_size - info_size > *count) status = STATUS_BUFFER_OVERFLOW; + else memcpy( data, buf_ptr + info_size, total_size - info_size ); + } } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = total_size - info_size; @@ -1056,6 +1054,7 @@ } } } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = info->DataLength; @@ -1151,6 +1150,7 @@ else memcpy( data, buf_ptr + info->DataOffset, total_size - info->DataOffset ); } } + else status = STATUS_SUCCESS; if (type) *type = info->Type; if (count) *count = info->DataLength; -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: process.h patch
by Alexandre Julliard Feb. 14, 2001

Feb. 14, 2001

Jon Griffiths <tntjpgriff(a)tsnxt.co.uk> writes: > * THIS SOFTWARE IS NOT COPYRIGHTED > * > * This source code is offered for use in the public domain. You may > * use, modify or distribute it freely. > * > * This code is distributed in the hope that it will be useful but > * WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY > * DISCLAMED. This includes but is not limited to warranties of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > You can't get more clear than that, I think. Of course it would be good to > acklowdge their contribution and let them know their modified code is being > used. Since it's public domain then yes we can use it; but you should *always* add a comment when you use code from somewhere else stating where it came from, even if there is no license requiring it. It's just the polite thing to do. > One thing I _don't_ think we need to do is to try to use the headers when > building msvcrt and Francois suggested. I think its extra work for no real > benefit, bugs show themselves soon enough, and winapi_check catches several > kinds of parameter bugs already. I alos dont like having to use a different > build command for one dll (ie include he msvcrt header dir). The advantage of using the headers for building msvcrt is that they will then automatically get tested by anybody compiling Wine; while with the other approach they only get tested by people compiling Winelib apps, i.e. just about nobody <grin> OTOH the macros make the headers quite ugly, so I don't have any strong preference one way or the other. -- Alexandre Julliard julliard(a)winehq.com

2 1

howto use dll´s in C
by christian richter Feb. 14, 2001

Feb. 14, 2001

Hello, i have a dll which makes some string conversions, and i want to use it in my C-Programm in Linux, i found out that wine can execute win32 exe´s and so i thought it should be possible to use a winelib or something to use the dll-functions and to get back values from this dll . . please help me, i don´t want to convert the whole dll (written in M$ Visual Basic ) into C - sources .. thank you

2 1

Re: Registry patch
by Alexandre Julliard Feb. 13, 2001

Feb. 13, 2001

davep <davep(a)cyw.uklinux.net> writes: > 123 calls RegQueryValueEx for the binary values with lpData set to NULL and > lpcbData non-NULL. RegQueryValueEx is supposed to return the size of the buffer > needed to hold the data, but Wine is returning the size of its initial buffer > (0xeb IIRC, sizeof(buffer)-sizeof(KEY_VALUE_PARTIAL_INFORMATION)). This causes > a crash when 123 immediately calls the same function again with a real buffer > address, presumably because 123 didn't allocate enough storage space. Could you please send me a +reg,+server trace of the offending calls? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Registry patch
by Alexandre Julliard Feb. 13, 2001

Feb. 13, 2001

davep <davep(a)cyw.uklinux.net> writes: > RegQueryValue() & RegEnumValue() > > We need to return the data length for REG_BINARY value types as well as strings > when called with a null buffer pointer. I don't understand why you need that. We already return the data length in all cases, including REG_BINARY. Could you elaborate a bit on exactly what is going wrong? -- Alexandre Julliard julliard(a)winehq.com

2 1

running a daemon ?
by Philippe Moutarlier Feb. 13, 2001

Feb. 13, 2001

Hi, this is not really a development question .. sorry . I am trying to see if I could use wine for running an lmgrd.exe daemon. How can I do this (and do you think it would work) ? When I just run > wine lmgrd.exe it starts running seemingly correctly and then exits instead of keeping running. Thanks Philippe

2 1

RE: Should Wine use alloca or not?
by Patrik Stridvall Feb. 13, 2001

Feb. 13, 2001

> On Monday 12 February 2001 15:33, Patrik Stridvall wrote: > > > > So perhaps we should debate whether we should use alloca or not. > > It seems this has been decided. Yes, see below. > I haven't examined or used > alloca in years, > so its possible that my personal objections don't apply in todays > implementations ( a quick test shows gcc on i386 _doesn't_ > use a function > call these days, for example, so thats no longer a valid > reason). So rather > than saying its evil, I'll tone down to it simply being > unesessary, and > continue to avoid it for (no doubt dubious) reasons of 'style'. I would rather say that the problem of using it, is that it, as Alexandre pointed out, introduces unrecovorable/undetectable errors if we allocate more than one page memory and if we only need a maximum of one page we can just allocate that or less if we know the exact maximum. The only problem I can see with this approach is that it uses an unnessary amount of stack space for recursive functions, but then I know of no such function in Wine and even if there is one, it is probably better to rewrite it as a non-recursive function anyway. So yes, the issue is decided.

1 0

Re: Should Wine use alloca or not?
by Jon Griffiths Feb. 13, 2001

Feb. 13, 2001

On Monday 12 February 2001 15:33, Patrik Stridvall wrote: > > > So perhaps we should debate whether we should use alloca or not. It seems this has been decided. I haven't examined or used alloca in years, so its possible that my personal objections don't apply in todays implementations ( a quick test shows gcc on i386 _doesn't_ use a function call these days, for example, so thats no longer a valid reason). So rather than saying its evil, I'll tone down to it simply being unesessary, and continue to avoid it for (no doubt dubious) reasons of 'style'. Cheers, Jon -- "Don't wait for the seas to part, or messiahs to come, Dont you sit around and waste this chance ..." -Live tntjpgriff(a)tsnxt.co.uk , jon_p_griffiths(a)yahoo.com

1 0

Re: No implementation for shlwapi.dll.0(StrRetToBufA)
by Francois Gouget Feb. 13, 2001

Feb. 13, 2001

On Sat, 10 Feb 2001, David D. Hagood wrote: > Francois Gouget wrote: > > > David, > > > > Can you shed some light on the MAPS DUL stuff below? > > > > > Evidently, my ISP is implementing the dialup blocking feature of MAPS > (and I never even KNEW they were doing any filtering, from the volume of > spam I get!). Yep. They definitely should really have told you. I'm all for anti-spam measures (if you check my web site you'll see I even translated the 'Advertising on Usenet' FAQ to french a few years back) but I disagree with MAPS DUL. From what you say it seems pretty ineffective and I'm really irked by the following paragraph: >From http://mail-abuse.org/dul/intro.htm: > What gives you the right... > > ...to deny access to our own, privately owned, equipment? > > Our mail servers are private property, to allow others to use as we > see it. We have not found a legitimate reason for dial-up users to > talk directly to recipients' mail servers, especially since your ISP > provides a good mail server for you to use as a gateway. As such, > please respect our choice and use the equipment you're authorized to use. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sure they have the right to deny me access to their mail server, but to imply that I'm only allowed to connect to my ISP's mail server is bullshit. What next? Web site administrators are going to deny access to their site from dialup users if they don't go through their ISP's proxy? After all nobody gave you the autorisation to access their web server! Well, I cannot tell you that you should switch to another ISP, it would be too easy for me and hypocritical as I'm not sure I would do it if I were in your situation. I'll see if I can send them a complaint email (without it getting bounced). Oh. Damn. I cannot send this email to you, it will get bounced! Hmm, I'll spam the mailing list with an OT email then (last and only one hopefully). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

8 14

New EnumPrinterDataEx
by Ian Pilcher Feb. 13, 2001

Feb. 13, 2001

While the great alloca debate rages on, here is a version of the patch that uses HeapAlloc for all dynamic allocation. (FWIW, my personal take is that if alloca causes the program to crash when it fails, then it's not really useful. I only used it, because the GNU libc documentation indicates that it returns NULL when it fails.) If no one has any other feedback on the patch, I'll submit it to wine- patches tomorrow. (So speak now or forever hold your peace.) -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010211cvs/include/winspool.h Sun Feb 11 19:26:47 2001 +++ include/winspool.h Mon Feb 12 09:32:58 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-20010211cvs/dlls/winspool/winspool.drv.spec Sun Feb 11 19:26:47 2001 +++ dlls/winspool/winspool.drv.spec Mon Feb 12 09:32:58 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-20010211cvs/dlls/winspool/info.c Sun Feb 11 19:26:47 2001 +++ dlls/winspool/info.c Mon Feb 12 10:51:00 2001 @@ -2561,3 +2561,328 @@ return GetPrinterDataExW(hPrinter, PrinterDriverDataW, pValueName, pType, pData, nSize, pcbNeeded); } + +/* + * The Win32 doc says that RegCloseKey and HeapFree can fail, but it's hard to + * imagine why either of them would. And what is the calling function supposed + * to do about it anyway? + */ + +#define REGCLOSEKEY(X) \ +{ \ + DWORD ret; \ + \ + ret = RegCloseKey (X); \ + if (ret != ERROR_SUCCESS) \ + WARN ("RegCloseKey returned %li\n", ret); \ +} + +#define HEAPFREE(X,Y,Z) \ +{ \ + if (HeapFree ((X), (Y), (Z)) == 0) \ + WARN ("HeapFree failed with code %li\n", GetLastError ()); \ +} + +/******************************************************************************* + * EnumPrinterDataExW [WINSPOOL.197] + */ +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + HKEY hkPrinter, hkSubKey; + DWORD 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) + { + REGCLOSEKEY (hkPrinter); + TRACE ("RegOpenKeyExW (%08x, %s) returned %li\n", hPrinter, + debugstr_w (pKeyName), ret); + return ret; + } + + REGCLOSEKEY (hkPrinter); + + ret = RegQueryInfoKeyW (hkSubKey, NULL, NULL, NULL, NULL, NULL, NULL, + &cValues, &cbMaxValueNameLen, &cbMaxValueLen, NULL, NULL); + if (ret != ERROR_SUCCESS) + { + REGCLOSEKEY (hkSubKey); + 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 */ + { + REGCLOSEKEY (hkSubKey); + *pcbEnumValues = *pnEnumValues = 0; + return ERROR_SUCCESS; + } + + ++cbMaxValueNameLen; /* allow for trailing '\0' */ + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + REGCLOSEKEY (hkSubKey); + 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)); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + lpValue = HeapAlloc (hHeap, 0, cbMaxValueLen); + if (lpValue == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", cbMaxValueLen); + HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + 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) + { + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + 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 */ + { + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + 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) + { + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + 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); + } + + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + return ERROR_SUCCESS; +} + +/******************************************************************************* + * EnumPrinterDataExA [WINSPOOL.196] + * + * The observant will note that this function returns ASCII strings in Unicode- + * sized buffers (for value names and values of type REG_SZ, REG_EXPAND_SZ, and + * REG_MULTI_SZ). This is what Windows 2000 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); + + 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) + { + HEAPFREE (hHeap, 0, pKeyNameW); + TRACE ("MultiByteToWide Char (%s, %i) failed with code %li\n", pKeyName, + len, GetLastError ()); + return GetLastError (); + } + + ret = EnumPrinterDataExW (hPrinter, pKeyNameW, pEnumValues, cbEnumValues, + pcbEnumValues, pnEnumValues); + if (ret != ERROR_SUCCESS) + { + HEAPFREE (hHeap, 0, pKeyNameW); + TRACE ("EnumPrinterDataExW returned %li\n", ret); + return ret; + } + + HEAPFREE (hHeap, 0, pKeyNameW); + + 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) + { + HEAPFREE (hHeap, 0, pBuffer); + TRACE ("WideCharToMultiByte (%s, %li) failed with code %li\n", + debugstr_w (ppev->pValueName), dwBufSize, GetLastError ()); + return GetLastError (); + } + + 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) + { + HEAPFREE (hHeap, 0, pBuffer); + TRACE ("WideCharToMultiByte (%s, %li) failed with code %li\n", + debugstr_w ((LPWSTR) ppev->pData), dwBufSize, + GetLastError ()); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + return GetLastError (); + } + + memcpy (ppev->pData, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + } + + HEAPFREE (hHeap, 0, pBuffer); + return ERROR_SUCCESS; +} + +#undef REGCLOSEKEY +#undef HEAPFREE

2 4

Re: winebuild ppc
by Ulrich Weigand Feb. 13, 2001

Feb. 13, 2001

Josh DuBois wrote: > Well, on the ppc it seems that CRITICAL_SECTIONS which are initialized (they > get set to CRITICAL_SECTION_INIT a lot) fairly reliably get put on 2-byte > boundaries. I am not certain why this is the case. But this is the real question ;-) As I said, the *default* alignment of these structs is 4 byte. If they are in fact placed at 2-byte boundaries, I can see only a few possible explanations: - compiler bug - some weird interaction with Wine that causes the compiler to misbehave - *another* explicit alignment attribute somewhere The first two I consider rather unlikely (but certainly possible). The last point is the IMO most likely, however. Maybe there's a #pragma pack(1) section somewhere that isn't properly terminated or something similar. > I could perhaps try to change > all the instances of initialized critial sections to have their data copied into > them during an init routine, but that seems like yet another big weirdness. Or > maybe I can convince the compiler to stop aligning them strangely in the first > place. It should by default :-/ > The problem is that the instructions to implement Interlocked* functions on > the ppc require the destination of a store to be 4-byte aligned (so I want to align > the LockCount member). Sure. > I'm not sure, actually, how to be certain that regular > int's passed to these functions will be aligned, but I havn't seen problems (yet) > other than with the funny alignment of the CRITICAL_SECTION structs. Every 'int' is supposed to be 4-byte aligned, unless you override by some explicit alignment/packing statement. Bye, Ulrich

1 0

Re: Should Wine use alloca or not?
by Alexandre Julliard Feb. 13, 2001

Feb. 13, 2001

James Sutherland <jas88(a)cam.ac.uk> writes: > Last time this came up, someone had found the stack overflowing with a > large allocation - something like the char foo[10*1024] Patrik mentions - > and moved it to malloc(). At which point, someone else suggested turning > the malloc() into an alloca(), since it's faster... > > At the time, there were some fairly tight stack constraints in > places. Have these disappeared, or is alloca() still the wrong thing to > do??? The stack space is limited to 1Mb per thread (unless the application changed the defaults); it's not very tight, but it still means we cannot allocate arbitrary-sized data. -- Alexandre Julliard julliard(a)winehq.com

1 0

One step forward two steps back
by Alan Chandler Feb. 12, 2001

Feb. 12, 2001

I noticed that when using winedbg, in konsole of kde, I got an error trying to create the debug terminal. I checked and realised that I did not have xterm installed. So I installed it. Now, when I start winedbg it briefly creates the xterm and almost immediately closes and exits. I don't even get to a first breakpoint before starting the programme, although xterm does have time to complain that it can't find font vga and that its using fixed. What am I doing wrong? TIA Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

2 2

Re: Should Wine use alloca or not?
by Alexandre Julliard Feb. 12, 2001

Feb. 12, 2001

Patrik Stridvall <ps(a)leissner.se> writes: > Sure, but the "char buffer[10*PAGE_SIZE]" have the same problem haven't it? > We are not talking about allocation large amounts of space anyway, > but being able to allocate a buffer for ANSI <=> UNICODE translation > on the stack would be useful and most strings are not that large. If you know that the allocation will be small you don't need alloca(), you can use a constant-size buffer. And if you don't know the allocation maximum size you cannot use alloca() either because it may crash. So it doesn't buy anything and introduces potential portability problems. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: annoying EndDialog "feature"
by Alexandre Julliard Feb. 12, 2001

Feb. 12, 2001

Andreas Mohr <amohr(a)codeweavers.com> writes: > Windows definitely does NOT do it this way, of course > (well, I'd be surprised if it actually did ;-). > This is just a (crude, if you want) hack to make it work. > And I figured sending WM_NULL shouldn't hurt. That's in the "famous last words" category... please check how Windows does it and try to do it the same way. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Should Wine use alloca or not?
by Patrik Stridvall Feb. 12, 2001

Feb. 12, 2001

> > So perhaps we should debate whether we should use alloca or not. > > I'll throw my reasons in: > > -alloca with unknown length argument resolves to a function > call, so isn't as > effiecient as just moving the stack pointer. It does? Even on x86? Why? I'm certainly not an expert on this, but AFAIK you can just dynamically move the stack pointer (SP) register, the base pointer (BP) register will know where the stack frame of the function is anyway. > -it does not fail gracefully, it segfaults (according to the > gcc docs). That is the problem of all cases of runs out of stack. Of course if you allow allocations of more than one page you must have multiple guard pages, but then one page allocation should be enough for most uses in Wine. BTW, haven't void foo(void) { char buffer[10*PAGE_SIZE]; } the same problem. > -Its not available on all platforms True, but does any intresting platform for Wine lack it? > -Over/underwriting stack memory leads to very hard to debug problems > (corrupted stack). Dynamic memory may catch this with page protection. Sure, but the "char buffer[10*PAGE_SIZE]" have the same problem haven't it? We are not talking about allocation large amounts of space anyway, but being able to allocate a buffer for ANSI <=> UNICODE translation on the stack would be useful and most strings are not that large. > -It may not play well with exceptions, and even when it does, > it slows them > down horribly (lists of stack allocated memory must be kept > in order to > unwind the stack correctly). Where we may be mixing c++ and > windows style > exceptions this could be especially bothersome. I (or you) must have missed something but, AFAIK the BP register and not the SP register is used for unwinding. As far as C++ is concerned nobody should expect destructors to be called of alloca:ed memory just like it doesn't on malloc:ed memory. > -Its easy to get it wrong when memory is allocated in a code > block, because > the standard says the memory can be freed at the end of the > block or the > function. Its easy to forget this and use the memory outside > of the block, > which will fail on some implementations. Of course you must be careful with what you do. The same goes for the "char buffer[]" case. > Thats why I say 'style-wise' I don't use it (I do have real > reasons). There > are too many potential problems lurking there for my liking. > I see it as an > optimisation, if required it should be added later, commented > and only once > the need to use it has been demonstrated by profiling. Well, I think for example that stack allocating buffers for ANSI <=> UNICODE translation might be a good idea.

1 0

Re: winebuild ppc
by Ulrich Weigand Feb. 12, 2001

Feb. 12, 2001

Josh DuBois wrote: > @@ -3396,7 +3428,7 @@ > HANDLE OwningThread; > HANDLE LockSemaphore; > ULONG_PTR SpinCount; > -} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION; > +} __attribute__ ((aligned (4))) RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION; Why? The default alignment of this struct is 4 anyway (as all its members have a default alignment of 4 ...) The only situation where a RTL_CRITICAL_SECTION could conceivably be not aligned to 4 would be if if were embedded into a packed struct. In this case, however, the aligned attribute wouldn't help either AFAIK. (Additionally, the gcc'ism will annoy Patrik ;-/) Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

2 1

Should Wine use alloca or not?
by Patrik Stridvall Feb. 12, 2001

Feb. 12, 2001

> Jon Griffiths wrote: > > > > I don't know anything about the Win32 print API, but style > wise I tend to > > stay away from alloca(). It screws up exception handling > because it messes > > with the stack, and is machine dependant. Maybe > LocalAlloc() would be a > > better choice? > > > > According to the Microsoft web site, LocalAlloc is deprecated in favor > of HeapAlloc and friends. Yes, LocalAlloc is for 16 bit source code compabillity and shouldn't be used by Win32 code. > Can anyone comment on whether using alloca will mess up Wine? (Jon's > comment seems to imply that he avoids alloca on general principles, > rather than for Wine-specific reasons.) Does Wine use exceptions? Wine uses exceptions (sort of), but I don't think alloca will interfer. IIRC the only thing alloca does on x86 is to move the stack pointer to allocate space. The general problem with using alloca is that not all platforms supports alloca, however I think all reasonable platforms that has enough power to support Wine is likely to have it so I don't see any real reason not to use it. Currently Wine uses it indirectly since the files generated by flex/bison uses it. That said Alexandre has at least once rejected patches from me that used alloca, so he doesn't seem to like it. I don't remeber him saying why though. So perhaps we should debate whether we should use alloca or not. Alexandre, can you explain why you have rejected patches with alloca? Have you any better reason that better safe than sorry? Not that it is a bad reason but still...

2 1