- Wine-Devel - list.winehq.org

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