wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Should Wine use alloca or not?
by Jon Griffiths 13 Feb '01

13 Feb '01

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 13 Feb '01

13 Feb '01

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 13 Feb '01

13 Feb '01

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 13 Feb '01

13 Feb '01

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 13 Feb '01

13 Feb '01

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 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

> > 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 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

> 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

AFM-Handling problem
by Joerg Mayer 12 Feb '01

12 Feb '01

Moin, Marcus last patch to add default paths for afm files triggered a bug: Inside my font dirs, there is a directory that contains gzipped afm files. After I unzipped these files, wine started up again. Not nice. Ciao Jörg PS: This is the directory *after* decompression of the .afm.gz files: jmayer@alice:/usr/X11R6/lib/X11/fonts/Type1 > ls UTBI____.afm c0419bt_.afm c0632bt_.afm cour.afm cursor.pfa lcdxro.afm UTBI____.pfa c0419bt_.pfb c0632bt_.pfb cour.pfa encodings.dir lcdxro.pfa UTB_____.afm c0582bt_.afm c0633bt_.afm courb.afm fonts.dir lcdxrr.afm UTB_____.pfa c0582bt_.pfb c0633bt_.pfb courb.pfa fonts.scale lcdxrr.pfa UTI_____.afm c0583bt_.afm c0648bt_.afm courbi.afm lcdxmo.afm lcdxso.afm UTI_____.pfa c0583bt_.pfb c0648bt_.pfb courbi.pfa lcdxmo.pfa lcdxso.pfa UTRG____.afm c0611bt_.afm c0649bt_.afm couri.afm lcdxmr.afm lcdxsr.afm UTRG____.pfa c0611bt_.pfb c0649bt_.pfb couri.pfa lcdxmr.pfa lcdxsr.pfa jmayer@alice:/usr/X11R6/lib/X11/fonts/Type1 > -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

2 1

The Muncher project.
by Josh Walker 12 Feb '01

12 Feb '01

I aplolgize for the spelling. I never was any good at english. The muncher project is the implmentation of wine into a very very unique distro of linux and used as a true windows clone. I know, it's not a good name for a project, but it's the best I could come up with after spinning around in a desk chair for five minutes. I also know that this isn't the first time anyone has come up with the idea either, but this is differnt. I have an implentation scheme. I came up with the idea while working on an mp3 player for my car (which also runs linux) There are two HDs in my car stereo. The first is a small 512M drive running linux with all the core compents to make xmms work. The second drive is the mp3 drive, an 8GB removable with FAT32 on it so I can swap it into a windows box too. The mall Linux drive does all the work. It struck me one day that wouldn't it be cool at have a real windows interface for wine. I mean, you can hack the system as much as you can, but when it comes to it, the explorer start bar and all of the activeX do-hickies like control panel and My computer are owned by microsoft. So I devised a plan to make Linux look, run, smell, feel, and act like windows. The goal is to fool my mom by swapping the OS and seeing if she notices. The system works muck like the mp3 player in my car. Two partitons, one is the linux "Macrokenrel" which does all the behind the scenes stuff and the a fat32 partition, which holds the windows files and that the user only sees. The Macrokenel will be a linux partition that has the ability to boot, starts the devices, and then run the neccary core files. The big ones are X, FVWM95, the gnome desktop (Just the desktop, no icons, or panels, no virtual displays, nothing crazy... yet), and wine. Using glade, I will write little replacements for the ActiveX compents that are missing, (My computer, Control panel, etc) GTK will handle the windows "theme" as far as widgets go and fvwm95 is small, sleek, and gives you the right window dressings and a start button. I have here a compiled list of what I plan to add. CORE: Main Kernel -> Linux 2.4.1, USB and harware support big plus/framebuffer for startup screen http://www.kernel.org/ Dos support -> DosEMU 1.0.1 with FreeDOS .98, depending on dos support under wine http://www.dosemu.org/ http://www.freedos.org/ Windows support -> Wine, the latest http://www.winehq.org/ Graphic Display -> Xfree86 4.0.2 more graphics cards, the better font server http://www.xfree86.org DirectX -> Transgameing Explorer(GUI) -> modded FVWM95/Gnome desktop combo ftp://mitac11.uia.ac.be/html-test/fvwm95.html http://www.gnome.org Explorer(filelister) -> gmc (was Midnight Commander, swallowed by Gnome) http://www.gnome.org Explorer(Browser) -> Mozilla (activeX compent, full browser) http://www.iol.ie/~locka/mozilla/mozilla.htm http://www.mozilla.org/ DO-HICKIES & THINGAMABOBS: These are small apps that are written in gtk (possably quick glide apps) that mimic the function of native windows apps. My Computer -> GTK do-hickie that looks like My Computer Launches gmc and the contol panel do-hiokie. System -> GTK do-hickie that will list devices that are valid in /dev in a windows format, intermixed with kernal modules and stuff from kudzu. Network Neighborhood -> LinNeighborhood/Samba http://www.bnro.de/~schmidjo/ Trash -> Gnome's trash Display Properties -> GTK do-hickie that edits xf86config, xscreensaver, and fvwmrc is a windows fimilar way Dial-up Networking -> working for an ISP, I know this thing foreward and backwards do-hickie that writes chat/pppd scripts, easy! Control Panel -> Ugh! Do what WinME does. Make it simple unless you want complex. Start with date/time, internet options, display, printers, and totaly ignore add/remove programs for now. Complex will have date/time, display, fonts, internet options keyboard, modems, mouse, network, passwords, printers regonal settings, scedualed tasks, system Date/Time -> simple GTK app internet options -> working for an ISP know this foreward amd backwards too edits chat/pppd scripts Printers -> Wrapper for redhat's printtool w/ tweaks add/remove programs -> not gonna touch this with a 10 foot pole. maybe later fonts -> links to the font dirs in X keyboard -> edits keyboard properties and Xkeyboard settings who's config file escapes me for the moment. modems -> chat script tweaking mouse -> gtk app that pays with mouse bindings network -> know this back and foreward too, grabbs info from the loaded kernel modules passwords -> password wrapper for xdm, gdm, *dm password thingies regonal settings -> sets loocale varible sceduled tasks -> wrapper for editing the chrontab It's a big task, but I have faith in myself. I'm going to be build a "base system" tomarrow (Ceryix 133, 40M ram, Sound Blaster, Matrox graphics card, and a 814M HD) Feel free to comment. I have no web page on the porject yet, I don't want to call attention to myself in case it turns out to be a bigger project that I intended. Maybe we can use a form of this as a DirectX-compatible only OS that can just run games. Look out X-box ^_^ -Halkun

1 0

Small DDraw problem
by Lionel Ulmer 12 Feb '01

12 Feb '01

Hi all, After seeing the reports on cemw of Grim Fandango not working anymore, I decided to check it out. Install worked fine, but the game did not work. It stopped just after doing a SetCooperativeLevel. After some checkings, the error came from there (file dlls/ddraw/ddraw/main.c) : HRESULT WINAPI Main_DirectDraw_SetCooperativeLevel(LPDIRECTDRAW7 iface, HWND hwnd, DWORD cooplevel) { (....) if ((This->cooperative_level & DDSCL_EXCLUSIVE) && (cooplevel & DDSCL_EXCLUSIVE)) return DDERR_EXCLUSIVEMODEALREADYSET; (....) } Grim Fandango did the following : fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4039a090)->(00000138,00000051) - DDSCL_FULLSCREEN DDSCL_ALLOWMODEX DDSCL_EXCLUSIVE (...) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x4039a090)->(00000138,00000011) - DDSCL_FULLSCREEN DDSCL_EXCLUSIVE I wonder if this test is really needed ? My interpretation of the 'DDERR_EXCLUSIVEMODEALREADYSET' error was that ANOTHER application already used this flag, not that it was already set for the current application. Anyway, removing this test fixed Grim Fandango. It now starts fine, except for some palette problems. If you agree, I will submit a patch that removes this test :-) Lionel PS: I found out that Grim Fandango eats up my X auto repeat (I need to do a 'xset r on' after)... I thought that this was removed in recent Wine versions ?

4 3

Explorer/shell question.
by Rob Landley 12 Feb '01

12 Feb '01

I don't personally use windows, but I have a lot of friends who do. I just showed a friend 98lite.net (which has apparently gone commercial in the last year or two; I was actually looking for the list of instructions the used to have on how to replace the 98 I.E. based explorer with the 95 filesystem only explorer and delete I.E. from the system). Unfortunately, the 95 explorer, being MS intellectual property, can't be included with 98lite, they have to have a copy of 95 (pre OSR 2.5) lying around. I vaguely remembered this list discussing cloning the filesystem explorer months and months back, so my next thought was to wander over to winehq and see if you guys had cloned the filesystem explorer in such a way it could potentially be cleaned up and used to browse the filesystem so I.E. can be deleted. I didn't find one here, so I'm guessing the outcome of said discussion was "no, we aren't going to do that", but it seemed to be a question worth asking anyway. So: has anybody simply cloned the 95 explorer yet? Would the clone run under windows itself? How deeply does it have its tentacles into the guts of the rest of the system? Where would I go to look for such a thing? Rob __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

3 2

Re: Novell filesystem support
by gerard patel 12 Feb '01

12 Feb '01

At 01:44 PM 12/2/01 +1200, you wrote: <snip> >program, by writting into the users maildir. How this is done is >under novel you can Create files in directorys that you cannot see(if >that permisson is greated to you). But you can't do this under unix. >So the need to implement file i/o for novell files arises. Why not just give the Scan file right to the user ? Certainly more simple, and this is not a very serious security breakage IMO. Gerard

3 3

Fix to OpenGL for BadMatch issue with Alice
by Gavriel State 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

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 12 Feb '01

12 Feb '01

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 11 Feb '01

11 Feb '01

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 11 Feb '01

11 Feb '01

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 11 Feb '01

11 Feb '01

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 11 Feb '01

11 Feb '01

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel