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

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

Feb. 13, 2001

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

8 14

New EnumPrinterDataEx
by Ian Pilcher Feb. 13, 2001

Feb. 13, 2001

While the great alloca debate rages on, here is a version of the patch that uses HeapAlloc for all dynamic allocation. (FWIW, my personal take is that if alloca causes the program to crash when it fails, then it's not really useful. I only used it, because the GNU libc documentation indicates that it returns NULL when it fails.) If no one has any other feedback on the patch, I'll submit it to wine- patches tomorrow. (So speak now or forever hold your peace.) -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010211cvs/include/winspool.h Sun Feb 11 19:26:47 2001 +++ include/winspool.h Mon Feb 12 09:32:58 2001 @@ -763,6 +763,25 @@ DECL_WINELIB_TYPE_AW(PPROVIDOR_INFO_1) DECL_WINELIB_TYPE_AW(LPPROVIDOR_INFO_1) +typedef struct _PRINTER_ENUM_VALUESA { + LPSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESA, *PPRINTER_ENUM_VALUESA; + +typedef struct _PRINTER_ENUM_VALUESW { + LPWSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESW, *PPRINTER_ENUM_VALUESW; + +DECL_WINELIB_TYPE_AW(PRINTER_ENUM_VALUES) +DECL_WINELIB_TYPE_AW(PPRINTER_ENUM_VALUES) + /* DECLARATIONS */ INT WINAPI DeviceCapabilitiesA(LPCSTR pDevice,LPCSTR pPort,WORD fwCapability, LPSTR pOutput, LPDEVMODEA pDevMode); @@ -1082,6 +1101,14 @@ BOOL WINAPI DeletePrintProvidorW(LPWSTR pName, LPWSTR pEnvironment, LPWSTR pPrintProvidorName); #define DeletePrintProvidor WINELIB_NAME_AW(DeletePrintProvidor) + +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +#define EnumPrinterDataEx WINELIB_NAME_AW(EnumPrinterDataEx) --- ../wine-20010211cvs/dlls/winspool/winspool.drv.spec Sun Feb 11 19:26:47 2001 +++ dlls/winspool/winspool.drv.spec Mon Feb 12 09:32:58 2001 @@ -80,6 +80,10 @@ @ stub EnumPrintProcessorDatatypesW @ stub EnumPrintProcessorsA @ stub EnumPrintProcessorsW +@ stub EnumPrinterDataA +@ stdcall EnumPrinterDataExA(long str ptr long ptr ptr) EnumPrinterDataExA +@ stdcall EnumPrinterDataExW(long wstr ptr long ptr ptr) EnumPrinterDataExW +@ stub EnumPrinterDataW @ stdcall EnumPrinterDriversA(str str long ptr long ptr ptr) EnumPrinterDriversA @ stdcall EnumPrinterDriversW(wstr wstr long ptr long ptr ptr) EnumPrinterDriversW @ stdcall EnumPrintersA(long ptr long ptr long ptr ptr) EnumPrintersA --- ../wine-20010211cvs/dlls/winspool/info.c Sun Feb 11 19:26:47 2001 +++ dlls/winspool/info.c Mon Feb 12 10:51:00 2001 @@ -2561,3 +2561,328 @@ return GetPrinterDataExW(hPrinter, PrinterDriverDataW, pValueName, pType, pData, nSize, pcbNeeded); } + +/* + * The Win32 doc says that RegCloseKey and HeapFree can fail, but it's hard to + * imagine why either of them would. And what is the calling function supposed + * to do about it anyway? + */ + +#define REGCLOSEKEY(X) \ +{ \ + DWORD ret; \ + \ + ret = RegCloseKey (X); \ + if (ret != ERROR_SUCCESS) \ + WARN ("RegCloseKey returned %li\n", ret); \ +} + +#define HEAPFREE(X,Y,Z) \ +{ \ + if (HeapFree ((X), (Y), (Z)) == 0) \ + WARN ("HeapFree failed with code %li\n", GetLastError ()); \ +} + +/******************************************************************************* + * EnumPrinterDataExW [WINSPOOL.197] + */ +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + HKEY hkPrinter, hkSubKey; + DWORD ret, dwIndex, cValues, cbMaxValueNameLen, + cbValueNameLen, cbMaxValueLen, cbValueLen, + cbBufSize, dwType; + LPWSTR lpValueName; + HANDLE hHeap; + PBYTE lpValue; + PPRINTER_ENUM_VALUESW ppev; + + TRACE ("%08x %s\n", hPrinter, debugstr_w (pKeyName)); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + ret = WINSPOOL_GetOpenedPrinterRegKey (hPrinter, &hkPrinter); + if (ret != ERROR_SUCCESS) + { + TRACE ("WINSPOOL_GetOpenedPrinterRegKey (%08x) returned %li\n", + hPrinter, ret); + return ret; + } + + ret = RegOpenKeyExW (hkPrinter, pKeyName, 0, KEY_READ, &hkSubKey); + if (ret != ERROR_SUCCESS) + { + REGCLOSEKEY (hkPrinter); + TRACE ("RegOpenKeyExW (%08x, %s) returned %li\n", hPrinter, + debugstr_w (pKeyName), ret); + return ret; + } + + REGCLOSEKEY (hkPrinter); + + ret = RegQueryInfoKeyW (hkSubKey, NULL, NULL, NULL, NULL, NULL, NULL, + &cValues, &cbMaxValueNameLen, &cbMaxValueLen, NULL, NULL); + if (ret != ERROR_SUCCESS) + { + REGCLOSEKEY (hkSubKey); + TRACE ("RegQueryInfoKeyW (%08x) returned %li\n", hkSubKey, ret); + return ret; + } + + TRACE ("RegQueryInfoKeyW returned cValues = %li, cbMaxValueNameLen = %li, " + "cbMaxValueLen = %li\n", cValues, cbMaxValueNameLen, cbMaxValueLen); + + if (cValues == 0) /* empty key */ + { + REGCLOSEKEY (hkSubKey); + *pcbEnumValues = *pnEnumValues = 0; + return ERROR_SUCCESS; + } + + ++cbMaxValueNameLen; /* allow for trailing '\0' */ + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + lpValueName = HeapAlloc (hHeap, 0, cbMaxValueNameLen * sizeof (WCHAR)); + if (lpValueName == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", + cbMaxValueNameLen * sizeof (WCHAR)); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + lpValue = HeapAlloc (hHeap, 0, cbMaxValueLen); + if (lpValue == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", cbMaxValueLen); + HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + return ERROR_OUTOFMEMORY; + } + + TRACE ("pass 1: calculating buffer required for all names and values\n"); + + cbBufSize = cValues * sizeof (PRINTER_ENUM_VALUESW); + + TRACE ("%li bytes required for %li headers\n", cbBufSize, cValues); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, NULL, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + TRACE ("%s [%li]: name needs %li bytes, data needs %li bytes\n", + debugstr_w (lpValueName), dwIndex, + (cbValueNameLen + 1) * sizeof (WCHAR), cbValueLen); + + cbBufSize += (cbValueNameLen + 1) * sizeof (WCHAR); + cbBufSize += cbValueLen; + } + + TRACE ("%li bytes required for all %li values\n", cbBufSize, cValues); + + *pcbEnumValues = cbBufSize; + *pnEnumValues = cValues; + + if (cbEnumValues < cbBufSize) /* buffer too small */ + { + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + TRACE ("%li byte buffer is not large enough\n", cbEnumValues); + return ERROR_MORE_DATA; + } + + TRACE ("pass 2: copying all names and values to buffer\n"); + + ppev = (PPRINTER_ENUM_VALUESW) pEnumValues; /* array of structs */ + pEnumValues += cValues * sizeof (PRINTER_ENUM_VALUESW); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, &dwType, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + cbValueNameLen = (cbValueNameLen + 1) * sizeof (WCHAR); + memcpy (pEnumValues, lpValueName, cbValueNameLen); + ppev[dwIndex].pValueName = (LPWSTR) pEnumValues; + pEnumValues += cbValueNameLen; + + /* return # of *bytes* (including trailing \0), not # of chars */ + ppev[dwIndex].cbValueName = cbValueNameLen; + + ppev[dwIndex].dwType = dwType; + + memcpy (pEnumValues, lpValue, cbValueLen); + ppev[dwIndex].pData = pEnumValues; + pEnumValues += cbValueLen; + + ppev[dwIndex].cbData = cbValueLen; + + TRACE ("%s [%li]: copied name (%li bytes) and data (%li bytes)\n", + debugstr_w (lpValueName), dwIndex, cbValueNameLen, cbValueLen); + } + + HEAPFREE (hHeap, 0, lpValue); HEAPFREE (hHeap, 0, lpValueName); + REGCLOSEKEY (hkSubKey); + return ERROR_SUCCESS; +} + +/******************************************************************************* + * EnumPrinterDataExA [WINSPOOL.196] + * + * The observant will note that this function returns ASCII strings in Unicode- + * sized buffers (for value names and values of type REG_SZ, REG_EXPAND_SZ, and + * REG_MULTI_SZ). This is what Windows 2000 does. + * + */ +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + INT len; + LPWSTR pKeyNameW; + DWORD ret, dwIndex, dwBufSize; + HANDLE hHeap; + LPSTR pBuffer; + + TRACE ("%08x %s\n", hPrinter, pKeyName); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + len = MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, NULL, 0); + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + return ERROR_OUTOFMEMORY; + } + + pKeyNameW = HeapAlloc (hHeap, 0, len * sizeof (WCHAR)); + if (pKeyNameW == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", + (LONG) len * sizeof (WCHAR)); + return ERROR_OUTOFMEMORY; + } + + if (MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, pKeyNameW, len) == 0) + { + HEAPFREE (hHeap, 0, pKeyNameW); + TRACE ("MultiByteToWide Char (%s, %i) failed with code %li\n", pKeyName, + len, GetLastError ()); + return GetLastError (); + } + + ret = EnumPrinterDataExW (hPrinter, pKeyNameW, pEnumValues, cbEnumValues, + pcbEnumValues, pnEnumValues); + if (ret != ERROR_SUCCESS) + { + HEAPFREE (hHeap, 0, pKeyNameW); + TRACE ("EnumPrinterDataExW returned %li\n", ret); + return ret; + } + + HEAPFREE (hHeap, 0, pKeyNameW); + + if (*pnEnumValues == 0) /* empty key */ + return ERROR_SUCCESS; + + dwBufSize = 0; + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + if (dwBufSize < ppev->cbValueName) + dwBufSize = ppev->cbValueName; + + if (dwBufSize < ppev->cbData && (ppev->dwType == REG_SZ || + ppev->dwType == REG_EXPAND_SZ || ppev->dwType == REG_MULTI_SZ)) + dwBufSize = ppev->cbData; + } + + TRACE ("Largest Unicode name or value is %li bytes\n", dwBufSize); + + pBuffer = HeapAlloc (hHeap, 0, dwBufSize); + if (pBuffer == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", dwBufSize); + return ERROR_OUTOFMEMORY; + } + + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + len = WideCharToMultiByte (CP_ACP, 0, ppev->pValueName, + ppev->cbValueName / sizeof (WCHAR), pBuffer, dwBufSize, NULL, + NULL); + if (len == 0) + { + HEAPFREE (hHeap, 0, pBuffer); + TRACE ("WideCharToMultiByte (%s, %li) failed with code %li\n", + debugstr_w (ppev->pValueName), dwBufSize, GetLastError ()); + return GetLastError (); + } + + memcpy (ppev->pValueName, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + + if (ppev->dwType != REG_SZ && ppev->dwType != REG_EXPAND_SZ && + ppev->dwType != REG_MULTI_SZ) + continue; + + len = WideCharToMultiByte (CP_ACP, 0, (LPWSTR) ppev->pData, + ppev->cbData / sizeof (WCHAR), pBuffer, dwBufSize, NULL, NULL); + if (len == 0) + { + HEAPFREE (hHeap, 0, pBuffer); + TRACE ("WideCharToMultiByte (%s, %li) failed with code %li\n", + debugstr_w ((LPWSTR) ppev->pData), dwBufSize, + GetLastError ()); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + return GetLastError (); + } + + memcpy (ppev->pData, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + } + + HEAPFREE (hHeap, 0, pBuffer); + return ERROR_SUCCESS; +} + +#undef REGCLOSEKEY +#undef HEAPFREE

2 4

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

Feb. 13, 2001

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

1 0

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

Feb. 13, 2001

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

1 0

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

Feb. 12, 2001

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

2 2

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

Feb. 12, 2001

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

2 1

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

Feb. 12, 2001

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

1 0

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

Feb. 12, 2001

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

1 0

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

Feb. 12, 2001

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

2 1

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

Feb. 12, 2001

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

2 1