wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

various config files for various applications
by Martin Pilka 20 Feb '01

20 Feb '01

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

4 6

Strange wine crashes with /dos mounted "rw" with Unreal
by FT Rathore 20 Feb '01

20 Feb '01

Hi I have been trying to run Unreal on wine with windows partition mounted with permission set so wine can write to it. It always crashes strangly I dont get any clues. If I mount /dos in a way that wine cannot write to it, Unreal runs perfectly. This problem only occurs with Unreal. I need write access so that I can save the games. Anyone else have similar problem?. I am about to start rolling up my sleeves and debug it. Any idea what info will help. FT

1 0

Re: Perl/Wine extension for perusal
by Jeremy White 20 Feb '01

20 Feb '01

I believe that the mailer ate my homework...er...email, so please forgive me if this is a duplicate message: > I also started to think (and write the very first pieces) of a test > harness. If you like to, I'm fully open to discuss all that with you. I think it would be great if we could start to define (and build) a test harness. I think that there are a lot of people who would help write test scripts, who might otherwise be unable to help with Wine development. The more the merrier, I always say... What did you have in mind? Our thinking, beyond building the Perl based winetest, hasn't gone very far. I think we've imagined the following: make test Performs an automated, non interactive regression test and returns true or false. make interactive-test Runs through interactive tests that require user interaction with the system; user confirms or denies their results. Both of these test runs could also be done on a Windows box, so that an exact 1:1 comparison could be made. Of course, the hard part is figuring out how to do the interactive-test. We've thought about trying to automate it (screen shots, simulating mouse movements, all that good stuff), but I don't think we have an obvious or brilliant idea. We looked into tools for that, but found no good free ones; there is also a suspicion that an X based test tool won't be enough for Wine. Thoughts? Jer

1 0

Re: Baldurs Gate 2 near perfect with transgaming and disk change problem
by FT Rathore 20 Feb '01

20 Feb '01

Sorry for the delay I was out. I only tested an existing BG2 installation which was installed using winblowz. The DLL order was default (from stock wine installation). FT On Mon, 5 Feb 2001, Malte Cornils wrote: > Hi, > > have you installed BG2 in a completely non-windows setup? If not, > did you install it in Linux or in Windows and just *run* it in > Linux? > > Also, does the configuration program work for you with builtin DLLs? > > Thanks so far, > > and feel free to cc this to wine-devel, but maybe we should change > to the newsgroup comp.emulators.ms-windows.wine, it might be more > appropriate there. > > Yours Malte #8-) >

1 0

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

20 Feb '01

It looks like GetFullPathName kernel.dll API func preserves trailing backslash, given in path argument, but implementation of this func in wine (files/dos_fs.c) removes it from return value (code starting at line 1300 in this file). Info about behavior taken from http://www.clubs.psu.edu/perldoc/lib/Pod/Win32.html (I don't have authorized windows api reference and even don't want to look for it - regular wine developer can check this in seconds). Removal 3 lines of code from this file cures runtime of "Heroes of Might & Magic III" (and I don't know what too). Regards TreV__ -- Tadeusz Szczyrba trevor(a)pik-net.pl

1 0

Re: [gphoto-devel] Running Polaroid PhotoMax under wine
by Nathan Stenzel 19 Feb '01

19 Feb '01

It would be really nice if TWAIN and WINE would work together to support TWAIN compatable drivers under Linux. Surely this would be much easier than every piece of hardware having a Linux driver hacked for it. It would open up the hardware makers to a whole new operating system too. I would hope that all the TWAIN drivers would have a way to run on any OS. TWAIN is supposed to be a standard afterall and standards are supposed to make things easier. I decided this was an interesting idea so I am sending copies of this to various other newsgroups (some of which I am not subscribed to). > I set wine up for the express purpose of seeing if the windoze > software would download the pictures from my camera. I had the same > problem with the buttons not showing up in PhotoMAX, but I got > Irfanview to run successfully. However, it wouldn't acknowledge the > existence of the camera, so I posted to the wine newsgroup about it. > They said that the function calls required by the TWAIN driver(s) > aren't [yet?] implemented. > > Regards, > Ben

1 0

GDI.EXE
by Johan Gill 19 Feb '01

19 Feb '01

Since some apps require a gdi.exe file containing version info, Wine won't be independent until the need for a true gdi.exe is removed. Are there any plans on how this should be achieved? /Johan Gill, johane(a)lysator.liu.se

2 1

Re: Overlapped read/write fix
by Ove Kaaven 19 Feb '01

19 Feb '01

On Mon, 19 Feb 2001, Eric Kohl wrote: > This patch fixes the MS Jet Database Engine. Overlapped reads and writes > must fail on Win9x. That would depend on the file type. Overlapped read and write is supposed to be allowed for sockets and serial ports even on win9x, but for ordinary files only on winNT, as far as I remember.

1 0

dlls/winsock/socket.c patch
by Chris Morgan 19 Feb '01

19 Feb '01

Should we be preserving the values of he, se, pe in the delete? This fixes a problem Jutta Wrage was having with Agent mailreader(win16 app).

1 0

Wine & Wrapster/UnWrapper/etc
by David Luyer 19 Feb '01

19 Feb '01

Just a potentially useful data point, since the Wrapster source is freely available on their website (it's written in PASCAL). Wrapster and UnWrapper won't work under WINE 20010112. Wrapster appears to sit in an infinite loop when asked to unwrap a file (although it's a 180Mb+ file so it may be doing something, but strace implies it's sitting there being confused, since it continually lstat()'s the destination directory and then does some miscellaneous memory mapping and unmapping). UnWrapper (2.x and 3.x) simply die on startup. (And yes, I know there's a Linux version - but it doesn't do a fraction of what the Windows version does, eg, CRC checks and new file formats. So I was hoping to check if the archive I have was corrupt without having to do development on grapster first... other than the fixes I already had to do to get dewrapster to handle large files :-).) I am no longer on this list, so please CC any response to me (especially of the form "it actually works with the latest CVS and some custom patch" :-)), thanks in advance. David. (I wonder how PC-PINE is working these days, it's C source was available and it used to not work so well under WINE either...) -- David Luyer Phone: +61 3 9674 7525 Senior Network Engineer P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 2983 http://www.pacific.net.au/ NASDAQ: PCNTF

1 0

mailserver operational
by Ove Kaaven 19 Feb '01

19 Feb '01

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

1 0

EnumPrinterDataEx - one more time
by Ian Pilcher 19 Feb '01

19 Feb '01

Here is an updated patch that does not use any macros. I do check all the return values, but hopefully this can be written off as a personal quirk. If no one has any objections, I'll send this to wine-patches tomorrow. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010216/include/winspool.h Sun Feb 11 19:26:47 2001 +++ include/winspool.h Sun Feb 18 18:30:13 2001 @@ -763,6 +763,25 @@ DECL_WINELIB_TYPE_AW(PPROVIDOR_INFO_1) DECL_WINELIB_TYPE_AW(LPPROVIDOR_INFO_1) +typedef struct _PRINTER_ENUM_VALUESA { + LPSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESA, *PPRINTER_ENUM_VALUESA; + +typedef struct _PRINTER_ENUM_VALUESW { + LPWSTR pValueName; + DWORD cbValueName; + DWORD dwType; + LPBYTE pData; + DWORD cbData; +} PRINTER_ENUM_VALUESW, *PPRINTER_ENUM_VALUESW; + +DECL_WINELIB_TYPE_AW(PRINTER_ENUM_VALUES) +DECL_WINELIB_TYPE_AW(PPRINTER_ENUM_VALUES) + /* DECLARATIONS */ INT WINAPI DeviceCapabilitiesA(LPCSTR pDevice,LPCSTR pPort,WORD fwCapability, LPSTR pOutput, LPDEVMODEA pDevMode); @@ -1082,6 +1101,14 @@ BOOL WINAPI DeletePrintProvidorW(LPWSTR pName, LPWSTR pEnvironment, LPWSTR pPrintProvidorName); #define DeletePrintProvidor WINELIB_NAME_AW(DeletePrintProvidor) + +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues); +#define EnumPrinterDataEx WINELIB_NAME_AW(EnumPrinterDataEx) --- ../wine-20010216/dlls/winspool/winspool.drv.spec Sun Feb 11 19:26:47 2001 +++ dlls/winspool/winspool.drv.spec Sun Feb 18 18:30:13 2001 @@ -80,6 +80,10 @@ @ stub EnumPrintProcessorDatatypesW @ stub EnumPrintProcessorsA @ stub EnumPrintProcessorsW +@ stub EnumPrinterDataA +@ stdcall EnumPrinterDataExA(long str ptr long ptr ptr) EnumPrinterDataExA +@ stdcall EnumPrinterDataExW(long wstr ptr long ptr ptr) EnumPrinterDataExW +@ stub EnumPrinterDataW @ stdcall EnumPrinterDriversA(str str long ptr long ptr ptr) EnumPrinterDriversA @ stdcall EnumPrinterDriversW(wstr wstr long ptr long ptr ptr) EnumPrinterDriversW @ stdcall EnumPrintersA(long ptr long ptr long ptr ptr) EnumPrintersA --- ../wine-20010216/dlls/winspool/info.c Sun Feb 11 21:51:05 2001 +++ dlls/winspool/info.c Sun Feb 18 18:33:49 2001 @@ -2561,3 +2561,386 @@ return GetPrinterDataExW(hPrinter, PrinterDriverDataW, pValueName, pType, pData, nSize, pcbNeeded); } + +/******************************************************************************* + * EnumPrinterDataExW [WINSPOOL.197] + */ +DWORD WINAPI EnumPrinterDataExW(HANDLE hPrinter, LPCWSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + HKEY hkPrinter, hkSubKey; + DWORD r, ret, dwIndex, cValues, cbMaxValueNameLen, + cbValueNameLen, cbMaxValueLen, cbValueLen, + cbBufSize, dwType; + LPWSTR lpValueName; + HANDLE hHeap; + PBYTE lpValue; + PPRINTER_ENUM_VALUESW ppev; + + TRACE ("%08x %s\n", hPrinter, debugstr_w (pKeyName)); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + ret = WINSPOOL_GetOpenedPrinterRegKey (hPrinter, &hkPrinter); + if (ret != ERROR_SUCCESS) + { + TRACE ("WINSPOOL_GetOpenedPrinterRegKey (%08x) returned %li\n", + hPrinter, ret); + return ret; + } + + ret = RegOpenKeyExW (hkPrinter, pKeyName, 0, KEY_READ, &hkSubKey); + if (ret != ERROR_SUCCESS) + { + r = RegCloseKey (hkPrinter); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegOpenKeyExW (%08x, %s) returned %li\n", hPrinter, + debugstr_w (pKeyName), ret); + return ret; + } + + ret = RegCloseKey (hkPrinter); + if (ret != ERROR_SUCCESS) + { + ERR ("RegCloseKey returned %li\n", ret); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ret; + } + + ret = RegQueryInfoKeyW (hkSubKey, NULL, NULL, NULL, NULL, NULL, NULL, + &cValues, &cbMaxValueNameLen, &cbMaxValueLen, NULL, NULL); + if (ret != ERROR_SUCCESS) + { + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegQueryInfoKeyW (%08x) returned %li\n", hkSubKey, ret); + return ret; + } + + TRACE ("RegQueryInfoKeyW returned cValues = %li, cbMaxValueNameLen = %li, " + "cbMaxValueLen = %li\n", cValues, cbMaxValueNameLen, cbMaxValueLen); + + if (cValues == 0) /* empty key */ + { + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + *pcbEnumValues = *pnEnumValues = 0; + return ERROR_SUCCESS; + } + + ++cbMaxValueNameLen; /* allow for trailing '\0' */ + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ERROR_OUTOFMEMORY; + } + + lpValueName = HeapAlloc (hHeap, 0, cbMaxValueNameLen * sizeof (WCHAR)); + if (lpValueName == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", + cbMaxValueNameLen * sizeof (WCHAR)); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ERROR_OUTOFMEMORY; + } + + lpValue = HeapAlloc (hHeap, 0, cbMaxValueLen); + if (lpValue == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", cbMaxValueLen); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ERROR_OUTOFMEMORY; + } + + TRACE ("pass 1: calculating buffer required for all names and values\n"); + + cbBufSize = cValues * sizeof (PRINTER_ENUM_VALUESW); + + TRACE ("%li bytes required for %li headers\n", cbBufSize, cValues); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, NULL, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + if (HeapFree (hHeap, 0, lpValue) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + TRACE ("%s [%li]: name needs %li bytes, data needs %li bytes\n", + debugstr_w (lpValueName), dwIndex, + (cbValueNameLen + 1) * sizeof (WCHAR), cbValueLen); + + cbBufSize += (cbValueNameLen + 1) * sizeof (WCHAR); + cbBufSize += cbValueLen; + } + + TRACE ("%li bytes required for all %li values\n", cbBufSize, cValues); + + *pcbEnumValues = cbBufSize; + *pnEnumValues = cValues; + + if (cbEnumValues < cbBufSize) /* buffer too small */ + { + if (HeapFree (hHeap, 0, lpValue) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("%li byte buffer is not large enough\n", cbEnumValues); + return ERROR_MORE_DATA; + } + + TRACE ("pass 2: copying all names and values to buffer\n"); + + ppev = (PPRINTER_ENUM_VALUESW) pEnumValues; /* array of structs */ + pEnumValues += cValues * sizeof (PRINTER_ENUM_VALUESW); + + for (dwIndex = 0; dwIndex < cValues; ++dwIndex) + { + cbValueNameLen = cbMaxValueNameLen; cbValueLen = cbMaxValueLen; + ret = RegEnumValueW (hkSubKey, dwIndex, lpValueName, &cbValueNameLen, + NULL, &dwType, lpValue, &cbValueLen); + if (ret != ERROR_SUCCESS) + { + if (HeapFree (hHeap, 0, lpValue) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + TRACE ("RegEnumValueW (%li) returned %li\n", dwIndex, ret); + return ret; + } + + cbValueNameLen = (cbValueNameLen + 1) * sizeof (WCHAR); + memcpy (pEnumValues, lpValueName, cbValueNameLen); + ppev[dwIndex].pValueName = (LPWSTR) pEnumValues; + pEnumValues += cbValueNameLen; + + /* return # of *bytes* (including trailing \0), not # of chars */ + ppev[dwIndex].cbValueName = cbValueNameLen; + + ppev[dwIndex].dwType = dwType; + + memcpy (pEnumValues, lpValue, cbValueLen); + ppev[dwIndex].pData = pEnumValues; + pEnumValues += cbValueLen; + + ppev[dwIndex].cbData = cbValueLen; + + TRACE ("%s [%li]: copied name (%li bytes) and data (%li bytes)\n", + debugstr_w (lpValueName), dwIndex, cbValueNameLen, cbValueLen); + } + + if (HeapFree (hHeap, 0, lpValue) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + if (HeapFree (hHeap, 0, lpValueName) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ret; + } + + if (HeapFree (hHeap, 0, lpValueName) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + r = RegCloseKey (hkSubKey); + if (r != ERROR_SUCCESS) + WARN ("RegCloseKey returned %li\n", r); + return ret; + } + + ret = RegCloseKey (hkSubKey); + if (ret != ERROR_SUCCESS) + { + ERR ("RegCloseKey returned %li\n", ret); + return ret; + } + + return ERROR_SUCCESS; +} + +/******************************************************************************* + * EnumPrinterDataExA [WINSPOOL.196] + * + * This functions returns value names and REG_SZ, REG_EXPAND_SZ, and + * REG_MULTI_SZ values as ASCII strings in Unicode-sized buffers. This is + * what Windows 2000 SP1 does. + * + */ +DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR pKeyName, + LPBYTE pEnumValues, DWORD cbEnumValues, + LPDWORD pcbEnumValues, LPDWORD pnEnumValues) +{ + INT len; + LPWSTR pKeyNameW; + DWORD ret, dwIndex, dwBufSize; + HANDLE hHeap; + LPSTR pBuffer; + + TRACE ("%08x %s\n", hPrinter, pKeyName); + + if (pKeyName == NULL || *pKeyName == 0) + return ERROR_INVALID_PARAMETER; + + len = MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, NULL, 0); + if (len == 0) + { + ret = GetLastError (); + ERR ("MultiByteToWideChar failed with code %li\n", ret); + return ret; + } + + hHeap = GetProcessHeap (); + if (hHeap == (HANDLE) NULL) + { + ERR ("GetProcessHeap failed\n"); + return ERROR_OUTOFMEMORY; + } + + pKeyNameW = HeapAlloc (hHeap, 0, len * sizeof (WCHAR)); + if (pKeyNameW == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", + (LONG) len * sizeof (WCHAR)); + return ERROR_OUTOFMEMORY; + } + + if (MultiByteToWideChar (CP_ACP, 0, pKeyName, -1, pKeyNameW, len) == 0) + { + ret = GetLastError (); + ERR ("MultiByteToWideChar failed with code %li\n", ret); + if (HeapFree (hHeap, 0, pKeyNameW) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + return ret; + } + + ret = EnumPrinterDataExW (hPrinter, pKeyNameW, pEnumValues, cbEnumValues, + pcbEnumValues, pnEnumValues); + if (ret != ERROR_SUCCESS) + { + if (HeapFree (hHeap, 0, pKeyNameW) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + TRACE ("EnumPrinterDataExW returned %li\n", ret); + return ret; + } + + if (HeapFree (hHeap, 0, pKeyNameW) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + return ret; + } + + if (*pnEnumValues == 0) /* empty key */ + return ERROR_SUCCESS; + + dwBufSize = 0; + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + if (dwBufSize < ppev->cbValueName) + dwBufSize = ppev->cbValueName; + + if (dwBufSize < ppev->cbData && (ppev->dwType == REG_SZ || + ppev->dwType == REG_EXPAND_SZ || ppev->dwType == REG_MULTI_SZ)) + dwBufSize = ppev->cbData; + } + + TRACE ("Largest Unicode name or value is %li bytes\n", dwBufSize); + + pBuffer = HeapAlloc (hHeap, 0, dwBufSize); + if (pBuffer == NULL) + { + ERR ("Failed to allocate %li bytes from process heap\n", dwBufSize); + return ERROR_OUTOFMEMORY; + } + + for (dwIndex = 0; dwIndex < *pnEnumValues; ++dwIndex) + { + PPRINTER_ENUM_VALUESW ppev = + &((PPRINTER_ENUM_VALUESW) pEnumValues)[dwIndex]; + + len = WideCharToMultiByte (CP_ACP, 0, ppev->pValueName, + ppev->cbValueName / sizeof (WCHAR), pBuffer, dwBufSize, NULL, + NULL); + if (len == 0) + { + ret = GetLastError (); + ERR ("WideCharToMultiByte failed with code %li\n", ret); + if (HeapFree (hHeap, 0, pBuffer) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + return ret; + } + + memcpy (ppev->pValueName, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + + if (ppev->dwType != REG_SZ && ppev->dwType != REG_EXPAND_SZ && + ppev->dwType != REG_MULTI_SZ) + continue; + + len = WideCharToMultiByte (CP_ACP, 0, (LPWSTR) ppev->pData, + ppev->cbData / sizeof (WCHAR), pBuffer, dwBufSize, NULL, NULL); + if (len == 0) + { + ret = GetLastError (); + ERR ("WideCharToMultiByte failed with code %li\n", ret); + if (HeapFree (hHeap, 0, pBuffer) == 0) + WARN ("HeapFree failed with code %li\n", GetLastError ()); + return ret; + } + + memcpy (ppev->pData, pBuffer, len); + + TRACE ("Converted '%s' from Unicode to ASCII\n", pBuffer); + TRACE (" (only first string of REG_MULTI_SZ printed)\n"); + } + + if (HeapFree (hHeap, 0, pBuffer) == 0) + { + ret = GetLastError (); + ERR ("HeapFree failed with code %li\n", ret); + return ret; + } + + return ERROR_SUCCESS; +}

1 0

Keyboard events and Direct Draw
by Alan Chandler 18 Feb '01

18 Feb '01

Actually this is NOW the third attempt the other attempts were yesterday. Apologies to everyone if they have already seen the following. I posted it several hours ago, but I would have expected it to have bounced back to me from the list by now, but it hasn't... ... and I also wanted to add, that I have been desperately trying to find a way to put a breakpoint on any events coming from the keyboard to try and track where they go - but nothing. I cannot find any evidence of any keyboard events being received within wine at all. With --debugmsg traces on channels "key", "keyboard" or "event", I can find nothing registered as I press a key. Perhaps more problematic since its also using the keyboard, but winedbg is not breaking on a breakpoint set on X11DRV_KEYBOARD_HandleEvent The following ... I am trying to understand the behaviour of wine when running Grand Prix Legends (a racing car simulator) - called GPL below. I posted here last week, and since then some updates have occurred to wine that improve things. Namely the colours now all come out correct. However, I am still trying to find out why key presses don't get fed into the program. This has the unfortunate affect, that once you have told the program to exit, you have to wait several minutes for the credits to scroll by since in the program under Windows, hitting return is the only way to kill these off. This is made worse by the fact that the DirectDraw window created by the program forceses itself on top of all the others so that whilst is there most ofther windows are fully or partially obscured (on any virtual desktop). This makes further debugging extremely difficuly. I am pretty sure the program (GPL) is not trying to use direct input for the keyboard, which implies it is expecting keypress messages on its winproc queue. However I don't know which one. With use of --debugmsg I think it creates one window, and then uses a Direct Draw call SetCooperativeLevel to set this window to full screen and exclusive mode. This window is then made active. Inside wine, dlls/ddraw/dsurface/user.c - there is a routine called when a direct draw surface is to be created. Last week Gavriel State suggested that I look at the #define OWN_WINDOW and comment it out. I tried that, and if I do, the game produces no output. However, when this #define is defined I do get the proper output (I have set the game and wine to only assume a 640x480 screen so its a window created in the upper left of my screen). Mouse events are captured properly, but keyboard events do not seem to be. Instead they seem to be directed at the underlying window from which wine was started (or if running winedbg the debug window). Looking at the code within the dsurface/user.c file, it appears to me that keyboard events received are passed to the orginal DirectDraw window. Therefore I don't understand why its not working. I guess the question I am asking is what are the differences between windows and wine here - I have very little knowledge of windows or x windows operation (other than what a learned about windows 5 years ago by reading manuals - but never actually writing code) so forgive me - and what could GPL doing to actually get keypresses. Some thoughts a) There is a call in the trace "CreateDesktopWindow" a little before the other windows calls. Is this Wine or GPL creating this window b) When I run the game under Windows you can ALT-TAB between two tasks. Maybe this other task has a dummy window taking keypresses and that somehow wine is not emulating windows behaviour correctly when automatically linking keypresses to the DirectDraw window Any comments? Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

1 0

Re: CRITICAL_SECTION alignment
by Ulrich Weigand 18 Feb '01

18 Feb '01

Josh DuBois wrote: > Just as Ulrich suggested, the typedef of the CRITICAL_SECTION struct > was inside a #pragma pack(1) block. On the ppc, this made > CRITICAL_SECTIONs always (or very often) get put on 2-byte boundaries. Aha! ;-) I'd suggest we should try and use pack() as sparingly as possible, e.g. by surrounding only single struct definitions with it. Those large #pragma pack() blocks can be really confusing ... > I didn't expect #pragma pack() to affect the alignment of types - I just > thought it would cause structures to take up the minimum required amount > of room. Seems it makes both members within a structure _and_ separate > structures get tightly packed. Or so I gather. This is really the same thing. The alignment requirement of a structure is the maximum (well, least common multiple) of the alignment requirements of all its member. #pragma pack(1) says that for all subsequent struct definitions, every member's alignment requirement is artificially set to 1. Hence, the struct's alignment requirement is also 1 ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

1 0

winehq mailserver troubles
by Ove Kaaven 18 Feb '01

18 Feb '01

Looks like mail to winehq was refused since yesterday because 30 sendmail processes was hung trying to deliver mail to some guy at ameritech.net (timed out connections etc), and since this was a limit in sendmail, it refused further incoming connections, and the secondary mailserver at corel didn't want winehq mails, so all incoming mails have been bounced by it... you'll probably all need to resend any bounced mails, I think. But it seems the hanging sendmail processes are already building up again. Let's see... should I disable the culprit's subscription, or try to compile a newer sendmail (if available), or maybe install some other MTA software, like exim? Hmm...

2 1

Perl/Wine extension for perusal
by John F Sturtz 17 Feb '01

17 Feb '01

Greetings. I work for CodeWeavers here in St Paul. Awhile back, I was set to the task of working on winetest, a Wine application which provided a flex/bison-based parser for a little scripting language from which Wine API functions could be called. The idea was that one could write test scripts which would call Wine API functions and examine the results, and the scripts could be used for regression testing of Wine. The scripting language began life with a rather Perl-ish syntax, and as functionality got added, it got more so. Eventually (about the time I had implemented a pack function, and wanted an unpack), I decided to see if I could write a Perl extension that provided a gateway for calling Wine API functions. That way, scripts for regression testing could be written directly in Perl instead. I have an initial version done. The practical upshot is that from a Perl script (after going through the proper incantations), you can write something like this: $atom = kernel32->GlobalAddAtomA("bark"); and the script will call the Wine GlobalAddAtomA() function, passing the string "bark", and return the result in $atom, which can then be examined to determine if it's what it should be. At Alexandre's suggestion, I've tossed a tarball of the stuff out on wine.codeweavers.com at ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz for anyone who's interested in having a look (just download the tarball, untar/ungzip it, and look at the README to get started). In particular, I'm curious as to: 1) Whether it works for anyone who tries it 2) Whether there's anyone who is both a serious Perl guru and a serious Windows guru (I am marginally the former and nowhere near the latter) who might like to take a stab at getting the extension to work under Windows Perl. 3) Whether any make guru would want to take a stab at writing a real makefile for the package (as opposed to the hack make ksh script I've done) as well as any other comments. Any input is appreciated. Thanks. John Sturtz jsturtz(a)codeweavers.com

3 2

Re: Perl/Wine extension for perusal
by Alan Gonzalez 17 Feb '01

17 Feb '01

I believe this will work out of the box on cygwin for windows using the perl 5.6.1 that is bundled with it. No need for ActiveState. Alan > 2) Whether there's anyone who is both a serious Perl > guru and a serious Windows guru (I am marginally > the former and nowhere near the latter) who might > like to take a stab at getting the extension to > work under Windows Perl. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by Mike McCormack 17 Feb '01

17 Feb '01

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

1 0

winelib and active-X dll´s
by christian richter 16 Feb '01

16 Feb '01

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

1 0

Re: VerQueryValue[A|W]
by François Jacques 16 Feb '01

16 Feb '01

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

2 1

Re: GetPixel bug!!!
by Ove Kaaven 16 Feb '01

16 Feb '01

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

1 0

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

16 Feb '01

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

1 0

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

16 Feb '01

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

2 1

RE: Turkish Keybard
by Nerijus Baliunas 16 Feb '01

16 Feb '01

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

1 0

Re: msvcrt/c++
by Alexandre Julliard 15 Feb '01

15 Feb '01

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

2 2

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