- Wine-Devel - list.winehq.org

Fix to OpenGL for BadMatch issue with Alice
by Gavriel State Feb. 12, 2001

Feb. 12, 2001

Hi Lionel, I recently remembered that I hadn't mentioned the below patch to you. This is something that we put in the last TG patch to fix an issue with Alice, but I'm not sure if the problem in question is the fault of the Wine OpenGL code or an issue with NVidia's OpenGL driver (I haven't really tried it on other drivers yet). Alice creates a rendering window, then walks through the pixel formats for that window's DC using DescribePixelFormat. The current implementation of DescribePixelFormat simply creates a new visual for each pixel format by calling glXChooseVisual. Under the NVidia libGL, at least, this creates a new visual even if there's already a visual that matches the requested parameters. Once we try to create a wgl context, the previous implementation was picking one of the newly created visuals, and initializing the glX context with that. An instant later, we get an X BadMatch error, since the rendering window that Alice is using was created with the default X11DRV visual, not the visual that was created by DescribePixelFormat. The patch below is a simple fix to just always use the X11DRV visual when creating contexts. Ideally we would somehow recreate the X11DRV window with the new visual, but I suspect that will have to wait for significant restructuring of the X11DRV. I didn't notice until later that you'd done a similar hack in X11DRV_ChoosePixelFormat, forcing the visual there to be the default. We could do the same thing for X11DRV_DescribePixelFormat as well, or we could simply drop most of the visual management code in graphics/x11drv/opengl.c and use my patch below. What's your preference? -Gav Index: wine/dlls/opengl32/wgl.c diff -u wine/dlls/opengl32/wgl.c:1.1.1.3 wine/dlls/opengl32/wgl.c:1.3 --- wine/dlls/opengl32/wgl.c:1.1.1.3 Tue Jan 23 12:12:23 2001 +++ wine/dlls/opengl32/wgl.c Tue Jan 23 12:23:42 2001 @@ -78,6 +78,8 @@ X11DRV_PDEVICE *physDev; XVisualInfo *vis; Wine_GLContext *ret; + int num; + XVisualInfo template; TRACE("(%08x)\n", hdc); @@ -88,8 +90,9 @@ physDev = (X11DRV_PDEVICE *)dc->physDev; - /* First, get the visual for the choosen pixel format */ - vis = physDev->visuals[physDev->current_pf - 1]; + /* First, get the visual in use by the X11DRV */ + template.visualid = XVisualIDFromVisual(X11DRV_GetVisual()); + vis = XGetVisualInfo(display, VisualIDMask, &template, &num); if (vis == NULL) { ERR("NULL visual !!!\n"); @@ -299,7 +302,7 @@ return ret->func; } else { - ERR("Extension defined in the OpenGL library but NOT in opengl_ext.c... Please report (lionel.ulmer(a)free.fr) !\n"); + ERR("Extension %s defined in the OpenGL library but NOT in opengl_ext.c... Please report (lionel.ulmer(a)free.fr) !\n", lpszProc); return NULL; } } -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

Novell filesystem support
by Simeon Pilgrim Feb. 12, 2001

Feb. 12, 2001

Hello, I have been making Wine support Novell Bindery calls via the ncplib, so that I can get Pegasus mail to do mhs mail. But i've hit the brick wall, novell file operations on a window -> unix -> novell file system dose not work very well. So what needs to happen is make Wine know about other file system types other than dos / windows / unix. What I was thinking is, there must be some system that windows uses to register extra file systems and then use supplied functions for read/write/etc operations. Dose Wine also support this system, or should it be made to do this? If this is in place where in the code should I look for references. If it is not supported, is it something that is should be supported in the future( i.e. a clean implementation ) or is an ugly little hack ok. If doing a hack, what structures should I add the extra information to, what structures should I not touch. p.s. sorry if this has been brought up before, I found it hard to search the archives. Regards, Simeon Pilgrim ------------------------------------------------------------- Simeon Pilgrim 27 Nazareth Avenue System Test Engineer PO Box 8011 Allied Telesyn Research Christchurch 8034 (An Allied Telesyn Group company) New Zealand phone +64 3 377 8900 fax +64 3 377 8870 -------------------------------------------------------------

2 2

[Fwd: Eyes requested]
by Ian Pilcher Feb. 12, 2001

Feb. 12, 2001

Ian Pilcher wrote: > > 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? > Never mind. Upon further review, alloca looks like a bad idea all the way around. (God forbid C should actually include a feature that makes someone's life easier!) -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

1 0

Eyes requested
by Ian Pilcher Feb. 12, 2001

Feb. 12, 2001

Attached is a patch to implement EnumPrinterDataEx (which should let everyone be happy about where the PostScript driver's font substitution table goes). Since this is the first time I've implemented a "real" Win32 API, rather than just doing internal tweaking, I may have missed something that's glaringly obvious to the more experienced. Before I send this to wine- patches, I'd appreciate it if some folks would take a quick look and let me know what they think. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010203cvs/include/winspool.h Sun Feb 11 21:46:34 2001 +++ include/winspool.h Sun Feb 11 14:59:53 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-20010203cvs/dlls/winspool/winspool.drv.spec Sun Feb 11 21:46:34 2001 +++ dlls/winspool/winspool.drv.spec Sun Feb 11 14:59:53 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-20010203cvs/dlls/winspool/info.c Sun Feb 11 21:46:34 2001 +++ dlls/winspool/info.c Sun Feb 11 21:36:19 2001 @@ -2561,3 +2561,322 @@ 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' */ + lpValueName = alloca (cbMaxValueNameLen * sizeof (WCHAR)); + if (lpValueName == NULL) + { + ERR ("Failed to allocate %li bytes on stack\n", + cbMaxValueNameLen * sizeof (WCHAR)); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + lpValue = HeapAlloc (hHeap, 0, cbMaxValueLen); + if (lpValue == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", cbMaxValueLen); + 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); + 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); + 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); + 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); + 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); + + pKeyNameW = alloca (len * sizeof (WCHAR)); + if (pKeyNameW == NULL) + { + ERR ("Failed to allocate %li bytes on stack\n", + (LONG) len * sizeof (WCHAR)); + return ERROR_OUTOFMEMORY; + } + + if (MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, pKeyNameW, len) == 0) + { + 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) + { + TRACE ("EnumPrinterDataExW returned %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); + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + return ERROR_OUTOFMEMORY; + } + + 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 2

Re: Novell filesystem support
by gerard patel Feb. 12, 2001

Feb. 12, 2001

At 12:41 PM 12/2/01 +1200, you wrote: >Hello, > >I have been making Wine support Novell Bindery calls via the >ncplib, so that I can get Pegasus mail to do mhs mail. But i've hit >the brick wall, novell file operations on a window -> unix -> novell >file system dose not work very well. <snip> What is not working in file operations ? I have my news messages with a reader working under Wine stored on a 4.10 file server since years. It's not exactly fast but I have yet to lose data. Gerard

1 0

Re: No implementation for shlwapi.dll.0(StrRetToBufA)
by gerard patel Feb. 11, 2001

Feb. 11, 2001

At 01:11 AM 11/2/01 -0800, you wrote: > But I'm not behind a modem. I'm behind a DSL so the above really >doesn't matter much. > I know I could just as well use my ISP's mail server and maybe I'll >change my configuration one day. But it seems to me that the MAPS DUL is >treating innocent users as criminals, especially when they say "and use >the equipment you're authorized to use." This means in their eyes I'm >not allowed to connect to anyone's mail server myself since they are not >part of the 'equipment I'm allowed to use'. I see this as an undue >restriction of my freedom and this is what I think is wrong with >MAPS DUL. They are allowing only regular mail servers. What's so surprising or immoral here ? Allowing others the right to use your property is not an all or nothing proposition; as an (hypothetical) example, I can refuse in general the right to people to use a way on my land, but allow an association to organize a walking at a specified date. That Mr X travels on my property as a member of this association does not give him the right to come any way and any times he chooses. > I'm more favorable to other forms of Spam prevention like MAPS RSS >and ORBS. At least in these cases the servers being blocked are at a >minimum guilty of negligence (by being open relays). > In contrast, people using MAPS DUL are discriminating against >individuals just because some might be spammers (they don't even claim >there is a larger proportion of spammers among them). What if a big >chain store refused to let you in because some statistics says you >belong to a population group with a higher percentage of shop-lifters. >'But of course, feel free to shop on the web, it's more convenient >anyway'. It's discrimination just the same and, IMO, the wrong way to >tackle the problem. I had just last week a real-life experience with this kind of setup: >Received: from unknown-fn4p2i6 ([192.76.183.3]) > by mail1.asi.fr (8.11.0/8.11.0) with SMTP id f1AKZmN32007 (...) >Message-Id: <200102102035.f1AKZmN32007(a)mail1.asi.fr> (...) >Subject: CAN YOU ADVERTISE TO OVER 20 MILLION E-MAIL ADDRESSES? I won't give you the detail on how to use a Paypal account after which I would (eventually) get a Web address to download the evil stuff ;-). Very probably a complete crook. As you see, I get this interesting proposal from an IP address (192.76.183.3) that is not responding to a nslookup query. So I guess it's probably a rogue mail server on ADSL. Now, I have sent a mail to abuse(a)verio.com, but I am not sure it will do much good : this guy has probably registered under a false name and with a stolen credit card, so after he get kicked out by verio (if it happens at all...) he will just get another IP address from another ISP (or the same) and get back at its game. IMHO the main problem is that this kind of mail server is almost anonymous. Not as much as with relay mail, but my ISP takes care of that. If there was a regular Internet domain for the mail server, there would be *some* serious business information and as such some responsability. Gerard

3 2

Current Directory Strangely Affects Behaviour of Applications
by Alan Chandler Feb. 11, 2001

Feb. 11, 2001

I am trying to debug a game called Grand Prix Legends, running on wine with the transgaming patch. If just spent all day getting nowhere in winedbg because I couldn't get hold of what the game was doing. If I cd to the directory in which the game is installed (ie ~/win/sierra/gpl) and then run wine gpl.exe The program starts and fills the whole of my screen with a single black window. It sits there until I move the mouse, at which time it exits. I have just discovered that if I cd to the root of my c: drive (ie ~/win) and then run wine c:\\sierra\\gpl\\gpl.exe The program starts and I get a 640x480 window with the correct startup screen (I have "Desktop" = "640x480" in my config file). It is NOT managed (even though I have "Managed" = "Y" in my config file). However the program appears to partially work - in that a) The program responds to the mouse when I click on the correct parts of the screen, b) It runs a race with computer AI cars when I tell it too. Can anyone suggest why this subtle change might exist? [As an aside, the colours seem to be the negative of what they should be - but it could just be a completely wrong pallette, the program should respond to the keyboard, but all keys affect the underlying console window in which the game was started, and there is a multiplayer option where it should (at least) detect that I have a TCP/IP connection, but doesn't - can anyone say, are these known limitations of the transgaming patch?] Lastly, is the transgaming patch likely to be folded into the up to date CVS versions of wine anytime soon. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

2 3

Re: No implementation for shlwapi.dll.0(StrRetToBufA)
by gerard patel Feb. 11, 2001

Feb. 11, 2001

At 02:36 PM 11/2/01 +0100, you (I) wrote: >I had just last week a real-life experience with this kind of setup: > <snip> Err, I was wrong, it was probably not an ADSL user, but I don't think it affects the issue : too many mail servers with no control is not good (not until they pay me for the right to spam me :-)) Btw, I wonder if the wine-devel list is not used as a spam resource; since I changed my ISP (6 weeks ago) I only posted my mail address on this list (on cemw or for web surfing I used my old address) and I got the same awful stuff as before only 4 days after my old mail box expired :-/// I remember also (a long time ago) a spam with CC'ed the whole wine-devel subscriber list I think :-) Gerard

1 0

Re: No implementation for shlwapi.dll.0(StrRetToBufA) (fixed)
by David D. Hagood Feb. 11, 2001

Feb. 11, 2001

I hadn't tried setting an explicit override for shlwapi in the DLLoverrides. Silly me, it never occurred to me that I could ADD MY OWN DLLs. However, I noticed that shlwapi is not in the default configuration for Wine. Perhaps somebody who isn't an Anonymous Coward as far as the CVS server goes should add it? To Francois: thanks for the quick turn-around. Kinda late over there, isn't it?

1 0

No implementation for shlwapi.dll.0(StrRetToBufA)
by David D. Hagood Feb. 10, 2001

Feb. 10, 2001

I've tried to install several programs under Wine (the most recent being Delorme's AAA MapNGo V6.0) and I consistently get this error: err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef Always followed by the app calling StrRetToBufW and dying. It looks to me like this function does exist in the code. I've tried forcing my system to use the native DLL, to use the Wine DLL, to no avail. Any pointers on where to go from here? fixme:pthread_kill_other_threads_np err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef fixme:pthread_kill_other_threads_np Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np Warning: locale not supported by C library, locale unchanged

2 2