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

Re: urlmon: Corrected tests (resend)
by Alexandre Julliard Feb. 13, 2009

Feb. 13, 2009

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > > Changelog: > urlmon: Corrected tests Please write a better description. "Corrected tests" applies to every test commit. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Fixed a couple of Win64 pointer cast compiler warnings
by Alexandre Julliard Feb. 13, 2009

Feb. 13, 2009

Eddie Leung <eddie.leung.2009(a)anderson.ucla.edu> writes: > diff --git a/dlls/gdi32/dc.c b/dlls/gdi32/dc.c > index c8a3c4c..44a9a6f 100644 > --- a/dlls/gdi32/dc.c > +++ b/dlls/gdi32/dc.c > @@ -1433,7 +1433,7 @@ static BOOL WINAPI call_dc_hook16( HDC hdc, WORD code, DWORD_PTR data, LPARAM lP > args[2] = LOWORD(data); > args[1] = HIWORD(lParam); > args[0] = LOWORD(lParam); > - WOWCallback16Ex( (DWORD)dc->hookProc, WCB16_PASCAL, sizeof(args), args, &ret ); > + WOWCallback16Ex( (DWORD_PTR)dc->hookProc, WCB16_PASCAL, sizeof(args), args, &ret ); The correct fix for these things is to move them to a 16-bit file that doesn't get compiled at all for Win64. It doesn't make sense to call WOWCallback16 in 64-bit mode. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: lz32: Fix several test failures on Windows 9x systems
by Alexandre Julliard Feb. 13, 2009

Feb. 13, 2009

Juan Lang <juan.lang(a)gmail.com> writes: > @@ -231,7 +231,9 @@ static void test_LZOpenFileA_existing_compressed(void) > file = LZOpenFileA(_terminated, &test, OF_EXIST); > ok(file >= 0, "LZOpenFileA failed on switching to a compressed file name\n"); > ok(test.cBytes == sizeof(OFSTRUCT) || > - broken(test.cBytes == 40), /* win95 */ > + broken(test.cBytes == 34) /* winME */ || > + broken(test.cBytes == 40) /* win95 */ || > + broken(test.cBytes == 48), /* some win95 */ My guess is that this depends on the length of the filename, not on the platform. -- Alexandre Julliard julliard(a)winehq.org

1 0

Problem with compiling ole32 crosstest
by Vitaly Perov Feb. 13, 2009

Feb. 13, 2009

Hi! Does anybody have a problem compilling the crosstest of ole32? Or maybe it's only my fault? I have: usrmarshal.cross.o: In function `func_usrmarshal': /srv/vitperov/Projects/wine-dev/dlls/ole32/tests/usrmarshal.c:445: undefined reference to `_WdtpInterfacePointer_UserSize(a)20' /srv/vitperov/Projects/wine-dev/dlls/ole32/tests/usrmarshal.c:448: undefined reference to `_WdtpInterfacePointer_UserMarshal(a)20' ... -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

2 2

Re: wintrust(2/3): Remove a couple tests that fail on a variety of systems (try 2)
by Paul Vriens Feb. 13, 2009

Feb. 13, 2009

Juan Lang wrote: > This removes the unused variables in the last version. > --Juan > > > ------------------------------------------------------------------------ > > I think that these failures are also because of "not enough rights" (people running winetest as a normal user). So just removing them is probably not the best approach? -- Cheers, Paul.

4 8

Re: [5/5] fusion: Implement IAssemblyCache::QueryAssemblyInfo.
by James Hawkins Feb. 13, 2009

Feb. 13, 2009

It would be a lot easier if you just took over my patches that implement this properly: [PATCH 1/3] fusion: Implement the IAssemblyEnum interface. [try4] http://winehq.org/pipermail/wine-patches/2009-January/066994.html [PATCH 2/3] fusion: Add tests for the IAssemblyEnum interface. [try4] http://winehq.org/pipermail/wine-patches/2009-January/066995.html [PATCH 3/3] fusion: Add initial implementation of IAssemblyCache::QueryAssemblyInfo. [try4] http://winehq.org/pipermail/wine-patches/2009-January/066996.html The tests need to be fixed in a couple places to take directory ordering (or lack-thereof) into account. http://winehq.org/pipermail/wine-devel/2009-January/071727.html -- James Hawkins On Fri, Feb 13, 2009 at 12:14 AM, Hans Leidekker <hans(a)meelstraat.net> wrote: > > diff --git a/dlls/fusion/asmcache.c b/dlls/fusion/asmcache.c > index 73756b3..2ce1995 100644 > --- a/dlls/fusion/asmcache.c > +++ b/dlls/fusion/asmcache.c > @@ -41,6 +41,9 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(fusion); > > +static const WCHAR ext_exe[] = {'.','e','x','e',0}; > +static const WCHAR ext_dll[] = {'.','d','l','l',0}; > + > static BOOL create_full_path(LPCWSTR path) > { > LPWSTR new_path; > @@ -167,15 +170,102 @@ static HRESULT WINAPI IAssemblyCacheImpl_UninstallAssembly(IAssemblyCache *iface > return E_NOTIMPL; > } > > +static BOOL get_file_size(const WCHAR *filename, LARGE_INTEGER *size) > +{ > + HANDLE file; > + > + size->QuadPart = 0; > + file = CreateFileW(filename, GENERIC_READ, FILE_SHARE_READ, > + NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > + if (file == INVALID_HANDLE_VALUE) return FALSE; > + GetFileSizeEx(file, size); > + CloseHandle(file); > + return TRUE; > +} > + > +#define TOKEN_LEN 16 > +#define CULTURE_LEN 17 > +#define NAME_LEN 100 > + > static HRESULT WINAPI IAssemblyCacheImpl_QueryAssemblyInfo(IAssemblyCache *iface, > DWORD dwFlags, > LPCWSTR pszAssemblyName, > ASSEMBLY_INFO *pAsmInfo) > { > - FIXME("(%p, %d, %s, %p) stub!\n", iface, dwFlags, > - debugstr_w(pszAssemblyName), pAsmInfo); > + static const WCHAR fmt[] = > + {'%','s','\\','%','s','\\','%','u','.','%','u','.','%','u', > + '.','%','u','_','%','s','_','%','s','\\','%','s','%','s',0}; > > - return E_NOTIMPL; > + HRESULT hr; > + IAssemblyName *asmname; > + WCHAR asmdir[MAX_PATH], path[MAX_PATH]; > + WCHAR name[NAME_LEN + 1], culture[CULTURE_LEN + 1], token[TOKEN_LEN + 1]; > + WORD major, minor, build, revision; > + BYTE buf[8]; > + DWORD size; > + LARGE_INTEGER filesize; > + BOOL installed; > + > + TRACE("(%p, %d, %s, %p)\n", iface, dwFlags, debugstr_w(pszAssemblyName), pAsmInfo); > + > + hr = CreateAssemblyNameObject(&asmname, pszAssemblyName, CANOF_PARSE_DISPLAY_NAME, NULL); > + if (FAILED(hr)) > + return hr; > + > + size = sizeof(name); > + IAssemblyName_GetProperty(asmname, ASM_NAME_NAME, name, &size); > + > + size = sizeof(buf); > + memset(buf, 0, sizeof(buf)); > + IAssemblyName_GetProperty(asmname, ASM_NAME_PUBLIC_KEY_TOKEN, buf, &size); > + > + token_to_str(buf, token); > + > + size = sizeof(major); > + IAssemblyName_GetProperty(asmname, ASM_NAME_MAJOR_VERSION, &major, &size); > + > + size = sizeof(minor); > + IAssemblyName_GetProperty(asmname, ASM_NAME_MINOR_VERSION, &minor, &size); > + > + size = sizeof(build); > + IAssemblyName_GetProperty(asmname, ASM_NAME_BUILD_NUMBER, &build, &size); > + > + size = sizeof(revision); > + IAssemblyName_GetProperty(asmname, ASM_NAME_REVISION_NUMBER, &revision, &size); > + > + size = sizeof(culture); > + IAssemblyName_GetProperty(asmname, ASM_NAME_CULTURE, &culture, &size); > + > + get_assembly_directory(asmdir, MAX_PATH); > + > + sprintfW(path, fmt, asmdir, > + name, major, minor, build, revision, culture, token, name, ext_dll); > + > + /* FIXME: there can be more than one file */ > + if (!(installed = get_file_size(path, &filesize))) > + { > + strcpyW(strrchrW(path, '.'), ext_exe); > + if (!(installed = get_file_size(path, &filesize))) > + hr = HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND); > + } > + > + if (pAsmInfo) > + { > + pAsmInfo->uliAssemblySizeInKB.QuadPart = filesize.QuadPart; > + pAsmInfo->dwAssemblyFlags = 0; > + if (installed) > + { > + pAsmInfo->cbAssemblyInfo = sizeof(ASSEMBLY_INFO); > + pAsmInfo->dwAssemblyFlags = ASSEMBLYINFO_FLAG_INSTALLED; > + pAsmInfo->pszCurrentAssemblyPathBuf = strdupW(path); > + pAsmInfo->cchBuf = strlenW(pAsmInfo->pszCurrentAssemblyPathBuf) + 1; > + } > + } > + > + if (dwFlags & QUERYASMINFO_FLAG_VALIDATE) FIXME("not validating assembly\n"); > + > + IAssemblyName_Release(asmname); > + return hr; > } > > static HRESULT WINAPI IAssemblyCacheImpl_CreateAssemblyCacheItem(IAssemblyCache *iface, > @@ -216,9 +306,6 @@ static HRESULT WINAPI IAssemblyCacheImpl_InstallAssembly(IAssemblyCache *iface, > LPWSTR ext; > HRESULT hr; > > - static const WCHAR ext_exe[] = {'.','e','x','e',0}; > - static const WCHAR ext_dll[] = {'.','d','l','l',0}; > - > TRACE("(%p, %d, %s, %p)\n", iface, dwFlags, > debugstr_w(pszManifestFilePath), pRefData); > > diff --git a/dlls/fusion/assembly.c b/dlls/fusion/assembly.c > index 049bf15..a7b09c8 100644 > --- a/dlls/fusion/assembly.c > +++ b/dlls/fusion/assembly.c > @@ -818,25 +818,6 @@ static BYTE *assembly_get_blob(ASSEMBLY *assembly, WORD index, ULONG *size) > return GetData(&assembly->blobs[index], size); > } > > -static void bytes_to_str(BYTE *bytes, DWORD len, LPWSTR str) > -{ > - DWORD i; > - > - static const WCHAR hexval[16] = { > - '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f' > - }; > - > - for(i = 0; i < len; i++) > - { > - str[i * 2] = hexval[((bytes[i] >> 4) & 0xF)]; > - str[i * 2 + 1] = hexval[(bytes[i]) & 0x0F]; > - } > -} > - > -#define BYTES_PER_TOKEN 8 > -#define CHARS_PER_BYTE 2 > -#define TOKEN_LENGTH (BYTES_PER_TOKEN * CHARS_PER_BYTE + 1) > - > HRESULT assembly_get_pubkey_token(ASSEMBLY *assembly, LPWSTR *token) > { > ASSEMBLYTABLE *asmtbl; > @@ -896,8 +877,7 @@ HRESULT assembly_get_pubkey_token(ASSEMBLY *assembly, LPWSTR *token) > goto done; > } > > - bytes_to_str(tokbytes, BYTES_PER_TOKEN, tok); > - tok[TOKEN_LENGTH - 1] = '\0'; > + token_to_str(tokbytes, tok); > > *token = tok; > hr = S_OK; > diff --git a/dlls/fusion/fusionpriv.h b/dlls/fusion/fusionpriv.h > index 405133b..6dec11b 100644 > --- a/dlls/fusion/fusionpriv.h > +++ b/dlls/fusion/fusionpriv.h > @@ -445,4 +445,24 @@ static inline WCHAR *strdupW(const WCHAR *src) > return dst; > } > > +#define BYTES_PER_TOKEN 8 > +#define CHARS_PER_BYTE 2 > +#define TOKEN_LENGTH (BYTES_PER_TOKEN * CHARS_PER_BYTE + 1) > + > +static inline void token_to_str(BYTE *bytes, LPWSTR str) > +{ > + DWORD i; > + > + static const WCHAR hexval[16] = { > + '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f' > + }; > + > + for(i = 0; i < BYTES_PER_TOKEN; i++) > + { > + str[i * 2] = hexval[((bytes[i] >> 4) & 0xF)]; > + str[i * 2 + 1] = hexval[(bytes[i]) & 0x0F]; > + } > + str[i * 2] = 0; > +} > + > #endif /* __WINE_FUSION_PRIVATE__ */ > diff --git a/dlls/fusion/tests/asmcache.c b/dlls/fusion/tests/asmcache.c > index fe2b466..42d8cba 100644 > --- a/dlls/fusion/tests/asmcache.c > +++ b/dlls/fusion/tests/asmcache.c > @@ -1020,11 +1020,8 @@ static void test_QueryAssemblyInfo(void) > /* assembly not installed yet */ > INIT_ASM_INFO(); > hr = IAssemblyCache_QueryAssemblyInfo(cache, 0, wine, &info); > - todo_wine > - { > - ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > - "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > - } > + ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > + "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > ok(info.dwAssemblyFlags == 0, "Expected 0, got %08x\n", info.dwAssemblyFlags); > @@ -1043,10 +1040,7 @@ static void test_QueryAssemblyInfo(void) > INIT_ASM_INFO(); > hr = IAssemblyCache_QueryAssemblyInfo(cache, QUERYASMINFO_FLAG_VALIDATE, > NULL, &info); > - todo_wine > - { > - ok(hr == E_INVALIDARG, "Expected E_INVALIDARG, got %08x\n", hr); > - } > + ok(hr == E_INVALIDARG, "Expected E_INVALIDARG, got %08x\n", hr); > ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > ok(info.dwAssemblyFlags == 0, "Expected 0, got %08x\n", info.dwAssemblyFlags); > @@ -1062,10 +1056,7 @@ static void test_QueryAssemblyInfo(void) > INIT_ASM_INFO(); > hr = IAssemblyCache_QueryAssemblyInfo(cache, QUERYASMINFO_FLAG_VALIDATE, > empty, &info); > - todo_wine > - { > - ok(hr == E_INVALIDARG, "Expected E_INVALIDARG, got %08x\n", hr); > - } > + ok(hr == E_INVALIDARG, "Expected E_INVALIDARG, got %08x\n", hr); > ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > ok(info.dwAssemblyFlags == 0, "Expected 0, got %08x\n", info.dwAssemblyFlags); > @@ -1100,11 +1091,8 @@ static void test_QueryAssemblyInfo(void) > /* pwzCachePath is full filename */ > INIT_ASM_INFO(); > hr = IAssemblyCache_QueryAssemblyInfo(cache, 0, winedll, &info); > - todo_wine > - { > - ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > - "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > - } > + ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > + "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > ok(info.dwAssemblyFlags == 0, "Expected 0, got %08x\n", info.dwAssemblyFlags); > @@ -1332,11 +1320,8 @@ static void test_QueryAssemblyInfo(void) > lstrcatW(name, badver); > hr = IAssemblyCache_QueryAssemblyInfo(cache, QUERYASMINFO_FLAG_GETSIZE, > name, &info); > - todo_wine > - { > - ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > - "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > - } > + ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > + "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > ok(info.dwAssemblyFlags == 0, "Expected 0, got %08x\n", info.dwAssemblyFlags); > @@ -1379,11 +1364,8 @@ static void test_QueryAssemblyInfo(void) > lstrcatW(name, badculture); > hr = IAssemblyCache_QueryAssemblyInfo(cache, QUERYASMINFO_FLAG_GETSIZE, > name, &info); > - todo_wine > - { > - ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > - "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > - } > + ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > + "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > ok(info.dwAssemblyFlags == 0, "Expected 0, got %08x\n", info.dwAssemblyFlags); > @@ -1426,11 +1408,8 @@ static void test_QueryAssemblyInfo(void) > lstrcatW(name, badpubkey); > hr = IAssemblyCache_QueryAssemblyInfo(cache, QUERYASMINFO_FLAG_GETSIZE, > name, &info); > - todo_wine > - { > - ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > - "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > - } > + ok(hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), > + "Expected HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND), got %08x\n", hr); > ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > ok(info.dwAssemblyFlags == 0, "Expected 0, got %08x\n", info.dwAssemblyFlags); > @@ -1466,6 +1445,31 @@ static void test_QueryAssemblyInfo(void) > "Expected %d, got %d\n", lstrlenW(asmpath) + 1, info.cchBuf); > } > > + /* fully qualified display name */ > + INIT_ASM_INFO(); > + lstrcpyW(name, wine); > + lstrcatW(name, commasep); > + lstrcatW(name, ver); > + lstrcatW(name, commasep); > + lstrcatW(name, culture); > + lstrcatW(name, commasep); > + lstrcatW(name, pubkey); > + hr = IAssemblyCache_QueryAssemblyInfo(cache, QUERYASMINFO_FLAG_GETSIZE, > + name, &info); > + ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > + "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); > + ok(info.uliAssemblySizeInKB.u.HighPart == 0, > + "Expected 0, got %d\n", info.uliAssemblySizeInKB.u.HighPart); > + ok(hr == S_OK, "Expected S_OK, got %08x\n", hr); > + ok(info.dwAssemblyFlags == ASSEMBLYINFO_FLAG_INSTALLED, > + "Expected ASSEMBLYINFO_FLAG_INSTALLED, got %08x\n", info.dwAssemblyFlags); > + ok(info.uliAssemblySizeInKB.u.LowPart == sizeof(ASSEMBLY), > + "Expected 4, got %d\n", info.uliAssemblySizeInKB.u.LowPart); > + ok(!lstrcmpW(info.pszCurrentAssemblyPathBuf, asmpath), > + "Wrong assembly path returned\n"); > + ok(info.cchBuf == lstrlenW(asmpath) + 1, > + "Expected %d, got %d\n", lstrlenW(asmpath) + 1, info.cchBuf); > + > /* uninstall the assembly from the GAC */ > disp = 0xf00dbad; > hr = IAssemblyCache_UninstallAssembly(cache, 0, wine, NULL, &disp); > > >

2 2

Re: [3/5] fusion: Assembly version numbers are WORDs.
by James Hawkins Feb. 13, 2009

Feb. 13, 2009

This definitely needs a test. -- James Hawkins On Fri, Feb 13, 2009 at 12:14 AM, Hans Leidekker <hans(a)meelstraat.net> wrote: > > diff --git a/dlls/fusion/asmname.c b/dlls/fusion/asmname.c > index acf0411..ebf76af 100644 > --- a/dlls/fusion/asmname.c > +++ b/dlls/fusion/asmname.c > @@ -45,7 +45,7 @@ typedef struct { > LPWSTR name; > LPWSTR culture; > > - BYTE version[4]; > + WORD version[4]; > DWORD versize; > > BYTE pubkey[8]; > @@ -145,28 +145,28 @@ static HRESULT WINAPI IAssemblyNameImpl_GetProperty(IAssemblyName *iface, > > case ASM_NAME_MAJOR_VERSION: > *pcbProperty = 0; > - *((LPDWORD)pvProperty) = name->version[0]; > + *((WORD *)pvProperty) = name->version[0]; > if (name->versize >= 1) > *pcbProperty = sizeof(WORD); > break; > > case ASM_NAME_MINOR_VERSION: > *pcbProperty = 0; > - *((LPDWORD)pvProperty) = name->version[1]; > + *((WORD *)pvProperty) = name->version[1]; > if (name->versize >= 2) > *pcbProperty = sizeof(WORD); > break; > > case ASM_NAME_BUILD_NUMBER: > *pcbProperty = 0; > - *((LPDWORD)pvProperty) = name->version[2]; > + *((WORD *)pvProperty) = name->version[2]; > if (name->versize >= 3) > *pcbProperty = sizeof(WORD); > break; > > case ASM_NAME_REVISION_NUMBER: > *pcbProperty = 0; > - *((LPDWORD)pvProperty) = name->version[3]; > + *((WORD *)pvProperty) = name->version[3]; > if (name->versize >= 4) > *pcbProperty = sizeof(WORD); > break; > > >

2 1

Re: [1/5] fusion: Assembly version must be taken from the metadata, not the file version.
by James Hawkins Feb. 13, 2009

Feb. 13, 2009

On Fri, Feb 13, 2009 at 12:12 AM, Hans Leidekker <hans(a)meelstraat.net> wrote: > > Office 2007 SP1 installer depends on this. > Please write a test case. -- James Hawkins

2 2

Re: msi: Fix case of assembly field names.
by James Hawkins Feb. 13, 2009

Feb. 13, 2009

Fix how? Both cases should be accepted... -- James Hawkins 2009/2/13 Hans Leidekker <hans(a)meelstraat.net>: > > diff --git a/dlls/msi/action.c b/dlls/msi/action.c > index fd38f7a..38d2484 100644 > --- a/dlls/msi/action.c > +++ b/dlls/msi/action.c > @@ -5870,11 +5870,11 @@ static UINT parse_assembly_name(MSIRECORD *rec, LPVOID param) > LPCWSTR name = MSI_RecordGetString(rec, 2); > LPWSTR val = msi_dup_record_field(rec, 3); > > - static const WCHAR Name[] = {'N','a','m','e',0}; > - static const WCHAR Version[] = {'V','e','r','s','i','o','n',0}; > - static const WCHAR Culture[] = {'C','u','l','t','u','r','e',0}; > + static const WCHAR Name[] = {'n','a','m','e',0}; > + static const WCHAR Version[] = {'v','e','r','s','i','o','n',0}; > + static const WCHAR Culture[] = {'c','u','l','t','u','r','e',0}; > static const WCHAR PublicKeyToken[] = { > - 'P','u','b','l','i','c','K','e','y','T','o','k','e','n',0}; > + 'p','u','b','l','i','c','K','e','y','T','o','k','e','n',0}; > > if (!lstrcmpW(name, Name)) > asmname->name = val; > > >

1 0

Re: [sane.ds 1/3] Get resolution from sane, instead of hard coding -1.
by Jeremy White Feb. 12, 2009

Feb. 12, 2009

I'm sorry; I failed to do a git-add options.c prior to this commit. Please use this patch instead. Cheers, Jeremy

1 0

Re: gdiplus: in GdipDrawString only NULL terminate if we have room in the buffer.
by Nikolay Sivov Feb. 12, 2009

Feb. 12, 2009

Aric Stewart wrote: > --- > dlls/gdiplus/graphics.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 2673042..c276a43 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -1901,7 +1901,8 @@ GpStatus WINGDIPAPI GdipDrawString(GpGraphics *graphics, GDIPCONST WCHAR *string > j++; > } > > - stringdup[j] = 0; > + if (j < length) > + stringdup[j] = 0; > length = j; > > while(sum < length){ > Hm, maybe I don't follow something, but I think 'j < length' is always true after that: --- for(i = 0, j = 0; i < length; i++){ if(!isprintW(string[i]) && (string[i] != '\n')) continue; stringdup[j] = string[i]; j++; } stringdup[j] = 0; length = j; --- Or you thought about zero length case? It should be handled earlier, on stringdup allocation or before...

2 1

Re: [2/2] tools/winemaker.man.in: update man-page
by Nikolay Sivov Feb. 12, 2009

Feb. 12, 2009

André Hentschel wrote: > sorry, had the wrong mail-account last time. > updating the man-page of winemaker. > there were such old things, there was dust on it! > > > > No attachment here...

1 0

Re: mshtml: Implement IHTMLStyle get/put minHeight (resend)
by Jacek Caban Feb. 12, 2009

Feb. 12, 2009

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IHTMLStyle get/put minHeight > [get|set]_nsstyle_attr_var functions were introduces to avoid the code duplication like you do. You should use them (and probably implement VT_I4 handling in set_nsstyle_attr_var). Jacek

1 0

Is the test.winehq.org front page too pessimistic?
by Juan Lang Feb. 12, 2009

Feb. 12, 2009

The front page of test.winehq.org shows statistics about failed tests, but it doesn't seem to take into account the number of individual tests that passed and failed, rather the number of files that had any failures. So, for example, about a week ago I got a fix committed for some failing mapi32 tests. Looking at the machines with test failures, before the fix was committed, 139 tests were run, with 134 of them failing, whereas after the fix was committed, the same number of tests were run, with only 6 of them failing. Nonetheless, the 4th of February shows a higher failure rate (14.6%) than the 3rd of February (12.4%). I know other tests could have started failing in the interim, but it seems like we've been putting a fair amount of effort into reducing test failures lately, while the percent of failed tests isn't going down, at least not on the main page. If you look at a particular day's results, the numbers look a bit better over time. I'm not sending a patch, because there may be different opinions on this. That is, perhaps some people like to see a statistic on the number of files with failing tests on any machine, which the front page appears to show, while others may like to see the number of failures in a particular file, which a day's results show. My own opinion is that it's hard to get motivated to fix something without some sort of positive feedback for it, so changing the front page would be better. My own feeling is that there are far fewer failing tests now than there used to be, and I'd sure like to see that reflected somewhere at a quick glance. Thoughts? --Juan

8 11

Re: mshtml: Implement IHTMLStyle_put_textDecorationUnderline (resend)
by Jacek Caban Feb. 12, 2009

Feb. 12, 2009

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IHTMLStyle_put_textDecorationUnderline + + return set_style_attr(This, STYLEID_TEXT_DECORATION, v == VARIANT_TRUE ? valUnderline : emptyW, 0); You shouldn't compare v to VARIANT_TRUE. The correct way to deal with bool values is 'v ? valUnderline : emptyW'. Jacek

1 0

ntdll: Avoid Potential Infinite Loop
by Paul Bryan Roberts Feb. 12, 2009

Feb. 12, 2009

Hi, I expect this patch will be accepted due to precedent - a few months ago I submitted the same patch for the same problem in a different routine in a different compilation unit of ntdll. Yes, I guess the infinite loop does not occur in practice (someone would have noticed) and I guess it has been there a very long time. But it isn't exactly hard to spot - I was speed reading the code looking for something else. I've seen a lot of chatter recently about something called Coverity. I looked it up on Wikipedia (after checking the spelling). Apart from it's obvious use as a conversation piece, is it proving useful to the project ? Is there a feedback policy ? Something like "We think your product is superlative .... but someone may wonder if your code not finding this bug in our code might be a bug in your code." Security :); false sense of security :( Paul Bryan Roberts >From dd2f31b0176e795edf5b1eb081410de7ed5ed03d Mon Sep 17 00:00:00 2001 From: Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk> Date: Thu, 12 Feb 2009 08:09:17 +0000 Subject: ntdll: avoid potential infinite loop --- dlls/ntdll/nt.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c index 879a324..dc81648 100644 --- a/dlls/ntdll/nt.c +++ b/dlls/ntdll/nt.c @@ -293,17 +293,20 @@ NTSTATUS WINAPI NtQueryInformationToken( char stack_buffer[256]; unsigned int server_buf_len = sizeof(stack_buffer); void *buffer = stack_buffer; - BOOLEAN need_more_memory = FALSE; + BOOLEAN need_more_memory; /* we cannot work out the size of the server buffer required for the * input size, since there are two factors affecting how much can be * stored in the buffer - number of groups and lengths of sids */ do { + need_more_memory = FALSE; + SERVER_START_REQ( get_token_groups ) { TOKEN_GROUPS *groups = tokeninfo; + req->handle = wine_server_obj_handle( token ); wine_server_set_reply( req, buffer, server_buf_len ); status = wine_server_call( req ); -- 1.5.4.3

2 1

Re: gdi32/tests: Use the ANSI text metrics so the tests work on win9x.
by Paul Vriens Feb. 12, 2009

Feb. 12, 2009

Huw Davies wrote: > --- > dlls/gdi32/tests/font.c | 20 ++++++++++---------- > 1 files changed, 10 insertions(+), 10 deletions(-) > > > ------------------------------------------------------------------------ > > Looks a lot like: http://www.winehq.org/pipermail/wine-patches/2009-February/069297.html Maybe we should use yours as it has less changes to the code. -- Cheers, Paul.

2 1

Download page requires too much scrolling...
by Dan Kegel Feb. 12, 2009

Feb. 12, 2009

While I was generating screenshots for my presentation, I noticed that http://www.winehq.org/download/ has too much clutter at the top. I don't mind the Codeweavers ad, but it's not good that users have to scroll down to see the useful part of the page...

2 1

Wine64 : Trying to load PE image for unsupported architecture (I386)
by Erik de Castro Lopo Feb. 12, 2009

Feb. 12, 2009

Hi all, I build Wine64 using the instructions here: http://wiki.winehq.org/Wine64 While I expected it to not work with my Win64 program I was a little surprised that when running a WIn32 program I got: Trying to load PE image for unsupported architecture (I386) I realise that the Win64 stuff is experimental but I'm curions, in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- J. Headley: "God, root, what is difference ?" G. Haverland: "God can change the byte order on the CPU, root can't."

6 7

Fwd: Need Your Help about "dll" on linux
by Jigar Joshi Feb. 11, 2009

Feb. 11, 2009

---------- Forwarded message ---------- From: Jigar Joshi <jigarjm(a)gmail.com> Date: Mon, Feb 9, 2009 at 6:53 PM Subject: Need Your Help about "dll" on linux To: wine-devel(a)winehq.org Respected sir, i refered your post at http://www.winehq.org/pipermail/wine-devel/2007-April/055855.html i want to know have you completed successfully that project? (using dll on linux) please reply soon . actually i have dlls derived from c , i dont have c code and i need to use those dlls on linus using java (JNI), first i tried to convert dll to ".so" bt i couldn't. . . read your post and got some moral support please reply soon . . . Regards Jigar

1 0

Error on CVS server: no space left on device
by Paul Chitescu Feb. 11, 2009

Feb. 11, 2009

Hi! The CVS server cvs.winehq.org is out of disk space: $ cvs -z3 -q up -APd can't create temporary directory /tmp/cvs-serv29410 No space left on device Message is received from remote server. Anyone able to fix it? Regards, Paul Chitescu

3 2

Re: itss: Replace malloc() with HeapAlloc()
by Nikolay Sivov Feb. 11, 2009

Feb. 11, 2009

Andrew Talbot wrote: > Changelog: > itss: Replace malloc() with HeapAlloc(). > > diff --git a/dlls/itss/lzx.c b/dlls/itss/lzx.c > index b5fdfc7..0ffeeb6 100644 > --- a/dlls/itss/lzx.c > +++ b/dlls/itss/lzx.c > @@ -36,15 +36,17 @@ > ***************************************************************************/ > > #include "lzx.h" > +#include <stdarg.h> > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > > +#include "windef.h" > +#include "winbase.h" > + > /* sized types */ > typedef unsigned char UBYTE; /* 8 bits exactly */ > typedef unsigned short UWORD; /* 16 bits (or more) */ > -typedef unsigned int ULONG; /* 32 bits (or more) */ > -typedef signed int LONG; /* 32 bits (or more) */ > > /* some constants defined by the LZX specification */ > #define LZX_MIN_MATCH (2) > @@ -178,8 +180,8 @@ struct LZXstate *LZXinit(int window) > if (window < 15 || window > 21) return NULL; > > /* allocate state and associated window */ > - pState = malloc(sizeof(struct LZXstate)); > - if (!(pState->window = malloc(wndsize))) > + pState = HeapAlloc(GetProcessHeap(), 0, sizeof(struct LZXstate)); > + if (!(pState->window = HeapAlloc(GetProcessHeap(), 0, wndsize))) > { > free(pState); > return NULL; > Why didn't you replace corresponding free() calls?

4 5

An idea for the appdb
by Luke Benstead Feb. 11, 2009

Feb. 11, 2009

Hi all, I was thinking earlier it would be quite nice if when I double clicked a Windows app in GNOME it would display a nice dialog saying something like "This Windows application may not run correctly as it is currently rated Silver. Please report any bugs to the Wine project. Continue | Cancel". Obviously this kind of functionality is not a job for Wine, but for the distro. Still, it got me thinking how this kind of functionality might be achieved. My idea is that the appdb should allow for people to associate a list of checksums with an application version. For example, WoW might have the checksum for the setup program and the game's executable, associated with the appdb entry. The other extension to the appdb would be to allow a way to programmatically retrieve information on an application's rating etc. by going to a certain address (e.g. http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...) which would return the info in XML or some other format. So what do you guys think? Perhaps some of this functionality exists and I don't know about it :) Luke.

4 7

Re: An idea for the appdb
by James Mckenzie Feb. 11, 2009

Feb. 11, 2009

-----Original Message----- >From: alex(a)centroidcafe.com >Sent: Feb 11, 2009 10:59 AM >To: wine-devel(a)winehq.org >Subject: Re: An idea for the appdb > >Sorry .. forgot to reply all. > >Automatic submission of test data could be a very handy tool. Scenario: >User A tries to run an application, it crashes due to bugs in Wine. User A >elects to submit data. Sometime in the future, User B tries to run the same >application under a similar configuration. It crashes also, but User B >being a sly user figures out what DLL overrides, patches, etc. allow this >app to progress past the original crash point. Wine detects this and >collects the information. Now when User C tries to run this app, Wine >displays a message like: "This application has been known to fail under the >current configuration. However, workarounds have been discovered that may >yield greater success. <link to AppDB>" > This would be great, but as previously discussed, who would maintain this information and verify it is correct and proper? Although some features would be 'neet to have' it is best to leave them on the drawing board for now and work on the various bugs that require workarounds. This is because of two limited resources: People and Time. If you have the skills to implement this feature, go ahead and try on a limited database on your home system. You would quickly see that we have about 10,000 applications in the AppDB and there are many versions of Wine. This gives you some starting point of the size of this task. Supporting a few applications would lead to the 'why isn't my wiz-bang application there' and a great deal of discussion, wasting more resources. Of course, if you could produce something that would emulate the "Report to ...." functionality that is in popular use, that would help keep the AppDB and Bugzilla up to date as long as a search capability were added to sweep these systems for pre-existing entries related to the current problem. Just my opinion, but this project is not worth attempting at this point. James McKenzie

5 4

Re: winedos: Replace [c]alloc() with HeapAlloc()
by Andrew Talbot Feb. 11, 2009

Feb. 11, 2009

Andrew Talbot wrote: Sorry, title should be: winedos: Replace [m|c]alloc() with HeapAlloc() -- Andy.

1 0

Re: An idea for the appdb
by alex＠centroidcafe.com Feb. 11, 2009

Feb. 11, 2009

Sorry .. forgot to reply all. On Wed, 11 Feb 2009 18:08:47 +0200, Gert van den Berg <wine-devel(a)mohag.net> wrote: > On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead <kazade(a)gmail.com> wrote: >> I can also see what you mean about >> spyware, but other apps retrieve stuff from the web if there is a >> connection (CDDB, and album covers are two examples). >> > Wine transmitting every application I run to someone else would be > rather worrying... > > It should rather be opt-in. Such as "Wine has detected that it is the > first time you run this application, do you want to check AppDb for > more information (Yes/No/Ask again/Never ask for any application)" It > must be easy to disable globally as well... It might have some other > uses as well such as "A newer version of the application works > better", etc. > > I might be handy to allow automatic submission of test data to AppDb > (which IMHO might be more useful than just retrieving...), which > should automatically include the Wine executables' checksums + > version, distro info (if accessible from lsb-release, parts of the > uname output & kernel checksum, which might be used to detect the > distro), kernel version, cpu architecture, X server name and version, > graphics driver name and version, DLL overrides, etc. This might help > modified wine versions and the level of tweaks to be detected by AppDb > automatically. (There should be a very specific opt-in process for > this data's submission though, such as letting the user manually > upload a file with this data and fully disclosing the file's contents) > This kind of data can be handy for bug reports as well. > Automatic submission of test data could be a very handy tool. Scenario: User A tries to run an application, it crashes due to bugs in Wine. User A elects to submit data. Sometime in the future, User B tries to run the same application under a similar configuration. It crashes also, but User B being a sly user figures out what DLL overrides, patches, etc. allow this app to progress past the original crash point. Wine detects this and collects the information. Now when User C tries to run this app, Wine displays a message like: "This application has been known to fail under the current configuration. However, workarounds have been discovered that may yield greater success. <link to AppDB>" That would be pretty sweet, no? -Alex Corrado

2 1

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 11, 2009

Feb. 11, 2009

Alexandre Julliard <julliard(a)winehq.org> wrote: >Sent: Feb 9, 2009 7:53 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Austin English <austinenglish(a)gmail.com>, wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >James Mckenzie <jjmckenzie51(a)earthlink.net> writes: > >> New wine installation: >> >> su (no dash so root's environment is not picked up) >> wine notepad >> install various programs and use them. >> exit > >This shouldn't hurt anything. Please specify the exact platform and show >us the exact commands you are using, or better file a bug with that >info. > It does not hurt anything but Wine's reputation. I don't know, but the phrase "I would rather be run over rather than run down" does apply here. In other words, we should be getting positive responses to user experiences, rather than dealing with newbies having to delete their .wine directories because they ran Wine as root without setting to the root environment. Fortunately, I run a Mac and running as root is disabled and it is a lengthy process to enable that user, which I did to attempt to get around a problem that running as root did not fix. I agree that user education is key, educating some folks is hard. James McKenzie

13 30

Re: An idea for the appdb
by Tim Schwartz Feb. 11, 2009

Feb. 11, 2009

On Wed, Feb 11, 2009 at 8:58 AM, <wine-devel-request(a)winehq.org> wrote: > Send wine-devel mailing list submissions to > wine-devel(a)winehq.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.org/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.org > > You can reach the person managing the list at > wine-devel-owner(a)winehq.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Message: 2 > Date: Wed, 11 Feb 2009 23:57:48 +1100 > From: Ben Klein <shacklein(a)gmail.com> > Subject: Re: An idea for the appdb > To: Luke Benstead <kazade(a)gmail.com> > Cc: Wine Devel <wine-devel(a)winehq.org> > Message-ID: > <d7e40be30902110457t3d84c396ibfd264aead12d6e9(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 2009/2/11 Luke Benstead <kazade(a)gmail.com>: >> 2009/2/11 Ben Klein <shacklein(a)gmail.com>: >>> 2009/2/11 Luke Benstead <kazade(a)gmail.com>: >>>> My idea is that the appdb should allow for people to associate a list >>>> of checksums with an application version. For example, WoW might have >>>> the checksum for the setup program and the game's executable, >>>> associated with the appdb entry. The other extension to the appdb >>>> would be to allow a way to programmatically retrieve information on an >>>> application's rating etc. by going to a certain address (e.g. >>>> http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...) >>>> which would return the info in XML or some other format. >>> >>> You've clearly put quite some thought into this, which is highly >>> commendable. However, I would personally be against such a move, as it >>> would put a lot of extra load on AppDB (in terms of network >>> bandwidth). I'm also not too keen about something that retrieves data >>> from the net every time you run an app. It's too easy for people to >>> mistake it for spyware. >> >> Hmm.. I see your point. However would it really use that much >> bandwidth? I mean, any sane implementation of the functionality I >> described would only display the dialog the first time that >> application was used. Retrieving a tiny xml file is surely less >> bandwidth than browsing the appdb for the application (granted it will >> happen more often than people browsing the site but I still don't >> think it's masses of bandwidth). I can also see what you mean about >> spyware, but other apps retrieve stuff from the web if there is a >> connection (CDDB, and album covers are two examples). > > A request to AppDB would be at least once per user, application > version and Wine version combination. Given the number of people using > Wine, this would almost certainly be a massive load increase on AppDB, > it would repeat roughly every 2 weeks (when new releases come out), > and possibly even bring AppDB down as a worst-case scenario. What about packaging the latest appdb information with each release? Tim Schwartz Sanity Internet tim(a)sanityinternet.com

1 0

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 11, 2009

Feb. 11, 2009

Steve Brown <sbrown7(a)umbc.edu> wrote: > >On Tue, 10 Feb 2009, Vitaliy Margolen wrote: > >> Ben Klein wrote: >>> This is not a problem with Wine, this is OpenSUSE breaking the >>> environment when sudo is called. Remember, Wine is not the only X11 >>> app out there. Others will need $DISPLAY working! >> This is something called security.... > >No, the whole point of using sudo is that it removes the necessity of >anyone other than root knowing the root password. If OpenSuSE's default >config requires anyone that needs elevated privileges to know the root >password, it is broken. Using a properly configured sudo, the non-root >users are allowed to execute a (possibly limited) number of commands with >root privileges, but authenticating using their OWN password. > The password method of invoking sudo depends on the UNIX release and the security policy in effect. I've used SUDOUSERS to set who has access to this, used a special password. It is not good security policy to use root's password, unless login as root is completely disabled, as it is with the Mac (it takes six steps to enable root login and Apple advises that this is not necessary.) However, under no circumstances, should a non-admin user run any Wine application as a super-user through this method. It causes problems as files are created with root's credentials and this causes confusion with some new users. Experts (supposedly) know how to fix this. Running Wine as root should bring up a warning message, in Windows format (that is with the warning icon) advising users that they are running Wine as root and that applications installed and files created will not be available to all users (as they would be in some versions of Windows(TM)). I think this is the purpose of the original request. I do support this as a one-time only warning. Permission to run Wine applications as sudo should remain disabled as some users know of this function and use it to get around running and having root's information. James McKenzie

1 0

Re: imm32: Make space for a 64bit pointer in the IMM window.
by Aric Stewart Feb. 11, 2009

Feb. 11, 2009

I am not a 64 bit expert but i do not think this is going to work. ddk/imm.h is a Microsoft header so IMEs and programs compiled with the original header will not have the expanded space. To fix this properly (I assume you are trying to support 64 bit) is that we will probibly have to store a handle instead of a pointer in the LONG value. The IME is expecting a HIMC in that value. Which leads to a more general question. What is the suggested way to generate handles like that? Working toward 64 bit means that everywhere that we are using pointers as LONG handles is going to have problems. -aric Michael Stefaniuc wrote: > --- > Next try at fixing this problem. I didn't find any other place where > IMMGWL_IMC is used and the window classes are not my area of expertise. > > > > dlls/imm32/imm.c | 2 +- > dlls/winex11.drv/ime.c | 2 +- > include/ddk/imm.h | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 14178c3..bb50e5e 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -2291,7 +2291,7 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) > data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, > data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, 1, 1, 0, > 0, data->immKbd->hIME, 0); > - SetWindowLongW(data->imeWnd, IMMGWL_IMC, (LONG)data); > + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); > IMM_GetThreadData()->hwndDefault = data->imeWnd; > } > > diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c > index 87d4faa..6d083d1 100644 > --- a/dlls/winex11.drv/ime.c > +++ b/dlls/winex11.drv/ime.c > @@ -1326,7 +1326,7 @@ static LRESULT WINAPI IME_WindowProc(HWND hwnd, UINT msg, WPARAM wParam, > * messages. > */ > > - hIMC = (HIMC)GetWindowLongW(hwnd,IMMGWL_IMC); > + hIMC = (HIMC)GetWindowLongPtrW(hwnd,IMMGWL_IMC); > if (!hIMC) > hIMC = RealIMC(FROM_X11); > > diff --git a/include/ddk/imm.h b/include/ddk/imm.h > index 6e4d42f..bc9617e 100644 > --- a/include/ddk/imm.h > +++ b/include/ddk/imm.h > @@ -114,7 +114,7 @@ HIMCC WINAPI ImmReSizeIMCC(HIMCC, DWORD); > DWORD WINAPI ImmGetIMCCSize(HIMCC); > > #define IMMGWL_IMC 0 > -#define IMMGWL_PRIVATE (sizeof(LONG)) > +#define IMMGWL_PRIVATE (sizeof(LONG_PTR)) > > /* IME Property bits */ > #define IME_PROP_END_UNLOAD 0x0001 > > > ------------------------------------------------------------------------ > >

2 2

Re: crypt32(1/4): Add chain debugging channel for debugging certificate chaining errors
by Alexandre Julliard Feb. 11, 2009

Feb. 11, 2009

Juan Lang <juan.lang(a)gmail.com> writes: > +static void dump_element(PCCERT_CONTEXT cert) > +{ > + LPWSTR name = NULL; > + DWORD len, i; > + > + TRACE_(chain)("%p\n", cert); > + len = CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, > + CERT_NAME_ISSUER_FLAG, NULL, NULL, 0); > + name = CryptMemAlloc(len * sizeof(WCHAR)); > + if (name) > + { > + CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, > + CERT_NAME_ISSUER_FLAG, NULL, name, len); > + TRACE_(chain)("issued by %s\n", debugstr_w(name)); > + CryptMemFree(name); > + } > + len = CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, 0, NULL, > + NULL, 0); > + name = CryptMemAlloc(len * sizeof(WCHAR)); > + if (name) > + { > + CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE, 0, NULL, > + name, len); > + TRACE_(chain)("issued to %s\n", debugstr_w(name)); > + CryptMemFree(name); > + } You probably don't want to do all this work unless tracing is enabled. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdiplus: add a drawing test for GdipFillRectangleI
by Nikolay Sivov Feb. 10, 2009

Feb. 10, 2009

Vincent Povirk wrote: > This is a very simple drawing test that I've created to establish a precedent for drawing tests in gdiplus. > > Gdiplus currently has no tests that draw things and then check what was drawn. I've added some functions that should make this easy. It's important to get this right the first time so any feedback will be most appreciated. > As for me I'm not against it if it'll work stably, but will this really help? It's much easier to check this visually, comparing with native output. These pixel-by-pixel tests should use current bpp depth for 'relaxation' when we start draw gradients for example...That's will add another complexity. Maybe it makes sense to add an antialiasing drawing tests to find out a closer algorithm for line drawing with different SmoothingModes...

2 3

Re: imagicos
by James Mckenzie Feb. 10, 2009

Feb. 10, 2009

Jeremy White <jwhite(a)winehq.org> wrote: > >EA Durbin wrote: >> I just saw this linux distribution on distrowatch. They claim to be able >> to run all microsoft products. Interesting. > >Just for the record, these folks are customers of ours. > Thank you for the clarification of your relationship with this company. > >It is my belief that their distribution of CrossOver complies with all >of the terms of the LGPL; we try to make sure of that for our customers. > I even believe that money they make as a result of their windows >compatibility will, albeit fairly indirectly, support Wine development. > This is very true. Hopefully, the legal folks have taken a look at how they are utilizing your product. I, for one, don't like to see one company's efforts usurped by another. > >Obviously, I like it when folks can celebrate the contributions of >everyone to Wine, and to all the FOSS products that go into something >like a Linux distribution. But Free Software means that folks are also >free to market as they see fit :-/. > I have warned folks against 'Free' software due to support concerns. I use Crossover because CodeWeavers is an ongoing concern. I advise folks to work with Wine, with the cavet that it is FOSS and that support is only available through the Wine Forums or Wine Mailing Lists. I also warn them that a problem they encounter may or may not be corrected. The same is true of most commercial software, but there is available telephone support (if you pay for it.) Again, I like where Wine is moving and the advances in just the last year. Also, I do support those companies that attempt to commercialize products, like RedHat and CodeWeavers. Please continue to do the great things that will move Wine forward. James McKenzie

1 0

Re: Fixing AppDB once and for all
by James Mckenzie Feb. 10, 2009

Feb. 10, 2009

Zachary Goldberg <zgold(a)bluesata.com> >Sent: Feb 3, 2009 10:44 AM >To: Wine Devel <wine-devel(a)winehq.org> >Cc: Jeremy Newman <jnewman(a)codeweavers.com> >Subject: Fixing AppDB once and for all > >All, >Lets (arbitrarily) set a time for the chat at: > >When: 11PM UTC (6PM EST) 2/6/09 (Friday) >Where: #winehackers > This would be too early for people on the West Coast of the United States by about three hours. No time will be satisfactory for all people who work on this project. What I feel is necessary at this point is to collect who lives in what time zone so that we incovience as few people as possible. Since this would be Saturday in Asia, this time may work for the majority of the people on this list. Also, will there be a transcript of the discussion and where will it be placed since this has a major impact on the functionality of the Applications Database. James McKenzie

9 15

imagicos
by EA Durbin Feb. 10, 2009

Feb. 10, 2009

I just saw this linux distribution on distrowatch. They claim to be able to run all microsoft products. Interesting. http://www.imagicos.com/ http://www.imagicos.com/microsoft.html _________________________________________________________________ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_022009

13 21

Re: [PATCH] gdi32: handle failure in __wine_make_gdi_object_system (Coverity)
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -445,6 +445,11 @@ static const struct DefaultFontInfo default_fonts[] = > void CDECL __wine_make_gdi_object_system( HGDIOBJ handle, BOOL set) > { > GDIOBJHDR *ptr = GDI_GetObjPtr( handle, 0 ); > + > + if (!ptr) { > + ERR("System object for handle %p not found.\n", handle); > + return; > + } That shouldn't happen, it's an internal function and the caller is supposed to pass a valid handle. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mshtml/tests: Better check for installed Gecko.
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -4199,9 +4199,8 @@ static void run_domtest(const char *str, domtest_t test) > } > > hres = IHTMLDocument2_get_body(doc, &body); > - ok(hres == S_OK, "get_body failed: %08x\n", hres); > - > - if(body) { > + if(hres != E_UNEXPECTED) { > + ok(hres == S_OK, "get_body failed: %08x\n", hres); > IHTMLElement_Release(body); We've been through this before, there needs to be at least one failure if mshtml is non-functional because Gecko is missing. I'd suggest to remove the Gecko install workaround and have the test force the install in all cases, it's not useful to run the tests without Gecko anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: spoolss: Implement EnumPorts [try 2]
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Detlef Riekenberg <wine.dev(a)web.de> writes: > Synced to current git. It doesn't work here: ../../../tools/runtest -q -P wine -M winspool.drv -T ../../.. -p winspool.drv_test.exe.so info.c && touch info.ok info.c:505: Test failed: got 1 with 127 (expected '0' with ERROR_INVALID_PARAMETER) make: *** [info.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] winegcc: Free the temporary string arrays (Coverity)
by Alexandre Julliard Feb. 10, 2009

Feb. 10, 2009

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > This fixes CID 883, 882, 881, 880, 879, 878, 877, > which are all basically missing strarray_free(arr)s. winegcc is a short-lived program, there's no reason to care about memory leaks. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [try2] dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
by Ben Klein Feb. 10, 2009

Feb. 10, 2009

2009/2/10 Vincent Pelletier <plr.vincent(a)gmail.com>: > On Tue, Feb 10, 2009 at 8:51 AM, Ben Klein <shacklein(a)gmail.com> wrote: >> You're taking out the strcpy into device, and replacing it with a >> strcpy into instance_name. What value will the device field hold? > > Err... strcpy from instance_name to the other struct. It's strcpy(out, in). > It's wine which is providing the windows program with names. OK, disregard everything I said ... ever ;) Well, at least about the strcpy. Sorry, must be my dyslexia playing tricks on me again. Oh, and can you try to hit "Reply to all" so it goes back to the mailing list too?

1 0

Re: dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
by Vitaliy Margolen Feb. 10, 2009

Feb. 10, 2009

Vincent Pelletier wrote: > joydevs[id].name value comes from EVIOCGNAME iotcl, and is the product name. > > I think joystick device path qualifies as a "Friendly name for the instance" > (as defined for tszInstanceName on MSDN). > > If not, please tell me and I will extend the patch to generate a "Joystick %i" > name, or maybe put joydevs[id].name in both fields. > > - strcpy(lpddi->tszInstanceName, joydevs[id].name); > - strcpy(lpddi->tszProductName, joydevs[id].device); > + strcpy(lpddi->tszInstanceName, joydevs[id].device); > + strcpy(lpddi->tszProductName, joydevs[id].name); No this is not entirely correct. Native doesn't return any device paths. But it does return proper joystick name: Wine: Instance: Logitech Logitech Dual Action ProductName: /dev/input/event7 Win XP: Instance: Logitech Dual Action USB ProductName: Logitech Dual Action USB Another joystick: Wine: Instance: Logitech Logitech MOMO Racing ProductName: /dev/input/event7 Win XP: Instance: Logitech MOMO Racing USB ProductName: Logitech MOMO Racing USB So I'd suggest copying name into both places. I think some applications looking for particular information there. And append "evdev?" at the end so we can tell how it's handled. Vitaliy.

3 3

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 10, 2009

Feb. 10, 2009

Alexandre Julliard <julliard(a)winehq.org> wrote: >Sent: Feb 9, 2009 7:26 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Austin English <austinenglish(a)gmail.com>, wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >James Mckenzie <jjmckenzie51(a)earthlink.net> writes: > >> Second, the problem is that newbies, figuring that their favorite >> program will not run as an ordinary user, gets a wiff that root has >> more privileges, will attempt run as root totally hosing their Wine >> directory. This then starts the 'you should not run Wine as root' >> mantra on Wine-Users. This then causes the newbie to question why did >> I go to Linux/Wine when I had a perfectly running Windows system? > >Please explain how running as root will screw their Wine directory. If >that's really true, surely it should be fixed instead of simply throwing >out a warning and proceeding. New wine installation: su (no dash so root's environment is not picked up) wine notepad install various programs and use them. exit User logs in a second time after learning how to properly use Wine. Attempt to do anything with Wine in user space. Cannot do due to permissions problems. The solution: sudo rm -rf .wine User now upset because everything they did is gone. Yes, there are legit reasons to run as root, one of them is the now famous ICMP 'Ping' unavailability issue in Linux. Experts know about this and how to work around it. Newbies, used to Windows and how it works, just figure that this is restricted to administrators, and switch to root to get around it. The proper command, as I have learned through years of UNIX administration, is 'su -' but newbies don't know this and most just use 'su'. Thus, the need for the warning. Experts tend to know what they are doing, newbies don't for the most part. And yes, I borked many a system as a newbie and as an expert (building kernels for RedHat/Fedora for my Thinkpad. James McKenzie

10 12

Regression in 1.1.14 for Athena Visual Studio
by Erich Hoover Feb. 9, 2009

Feb. 9, 2009

In Wine 1.1.14 Athena Visual Studio fails to build Fortran applications and returns with an error, doing a git bisect gives this result: ---- ebe4a9e321800fbe6d2004a640cd276a28d15c38 is first bad commit commit ebe4a9e321800fbe6d2004a640cd276a28d15c38 Author: Dan Kegel <dank(a)kegel.com> Date: Sun Jan 18 19:19:46 2009 -0800 msvcrt: Remove CRs earlier in ascii mode. :040000 040000 44cfaec7cd552af4c92f220ad34a06d864eff79d 685d15aa69a9e0f91e0d4cbc933191a29837dce9 M dlls ---- However, removing this patch from the latest git doesn't do enough - Athena instead hangs indefinitely trying to build. I guessed that it would also be necessary to remove the related patch "msvcrt: Remove CRs earlier in ascii mode in fseek, too.": http://source.winehq.org/git/wine.git/?a=blob;f=dlls/msvcrt/file.c;hb=7f3c7… Fortunately, that did the trick and got things working again. I don't have a lot of free time right now, but if there's some information I can give that will help in fixing this issue then please let me know and I will do my best to provide it. A 15 day trial of Athena is available, this error can be reproduced by attempting to build any sample in the "Curve Fitting Models" folder.

2 1

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

Aurimas Fišeras <aurimas(a)gmail.com> wrote: >Sent: Feb 9, 2009 7:45 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >James Mckenzie wrote: >> Alexandre Julliard <julliard(a)winehq.org> wrote: >>[...] >> New wine installation: >> >> su (no dash so root's environment is not picked up) >> wine notepad >> install various programs and use them. >> exit >> >> User logs in a second time after learning how to properly use Wine. >> Attempt to do anything with Wine in user space. Cannot do due to permissions problems. >> >> The solution: >> >> sudo rm -rf .wine >No, the solution is >sudo chown -R user:user .wine Correct. However, this is not being given as the solution. Also, if the user is on an alternate wine prefix this would change to: sudo chown -R <username>:users $WINEPREFIX Is this in the FAQ somewhere? James McKenzie

3 2

[try2] dinput: joydevs[id].name (EVIOCGNAME) is product name, joydevs[id].device is a path
by Vincent Pelletier Feb. 9, 2009

Feb. 9, 2009

Le Saturday 07 February 2009 14:16:15 Vincent Pelletier, vous avez écrit : > If not, please tell me and I will extend the patch to generate a "Joystick > %i" name, or maybe put joydevs[id].name in both fields. Same patch as first proposed on wine-devel, no reaction so I guess it's correct. -- Vincent Pelletier

2 2

Re: comctl32/tests: [try 2] Make the test dpi and Theme aware: use SM_CYSIZE
by Paul Vriens Feb. 9, 2009

Feb. 9, 2009

Detlef Riekenberg wrote: > try 2: without the check for win9x > > > The status test failed on installations with 120 dpi. > > After a lot of "try and error" from 72 to 144 dpi with > different formula for the min height, different results on my machine > and a failing XP machine at 96dpi, I found the reason: > > The minimal height depends on the appearance setting > "[In]Active Title Bar", which is SM_CYSIZE. > > The test now pass on win98se, win2k and Wine with a different height > for the title bar (tested from 18 to 30). > > To reduce the test log size, I moved the dump of the current tested > font name from a trace to the ok. > > > Why is MS so stupid and use BYTE in ENUMLOGFONTEXA and > WCHAR in ENUMLOGFONTEXW for the strings in wingdi.h, > while MSDN document them as TCHAR? > > > > > ------------------------------------------------------------------------ > > Hi Detlef, This patch introduced a lot of failures on specifically some XP and W2K3 boxes. Could you have a look? -- Cheers, Paul.

2 1

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

Michael Stefaniuc <mstefani(a)redhat.com> wrote: >Sent: Feb 9, 2009 7:39 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >> sudo rm -rf .wine >Solution is sudo chmod -R $username.$groupname .wine > Correct. However, this is not the solution given on Wine Users. >> User now upset because everything they did is gone. >Not if you do it right. > I agree, but some users are very sensitive and are worse that a colicy baby. The problem is that we should not need to direct users to run as root to perform any function. Some Linux distributions restrict network functions, such as ICMP, to only root. This is sillines in my opinion and actually employs poor security practices. However, a new that receives a message like the following "You must be an Administrator to run this program" when attempting to run a program in Wine will think "Administrator == root" and try to run the program as root. The program does not run, and they are futher frustrated. Also, some new users think, incorrectly, that running Wine as root will give them more permissions. It does not and should not. Again, the warning should address this. What I don't want to see, and I agree with AJ, is the disablement of running Wine as the root user. There are situations where this is necessary. A short notification message is all that is necessary and Austin's change does exactly that. James McKenzie

1 0

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

Chris Howe <mrmessiah(a)gmail.com> wrote: >Sent: Feb 9, 2009 8:06 AM >To: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >It would seem to me that the right place for this to go would be >not in Wine itself but in the likes of Crossover and Cedega - the >"distributions" and value added apps built around Wine. > >I can't reconcile in my head the case where you have a newbie >running the latest GIT of Wine needing this kind of thing at all. > Newbies don't run GITs, they download a prebuild version of Wine from a repository. Thus, this 'fix' would not appear to them until the release of 1.1.15 at the earliest. >Either they want the power and compatibility of the latest GIT >version, and all that that entails, including the potential for doing >things they didn't intend if they run it as root, or they want some >newbie friendly environment that seizes back the reins a little >and stops them doing that. > All versions of Wine that I've run into have the ability to run as root. This is inherent as a part of any UNIX program. What we are discussing is that running as root may make your system vulnerable and may cause problems later when Wine is run in user space. My example is that a user logs in and installs a program as root because they were told that it 'runs better' as root. When it is discovered to not be true, the user then attempts to run in user space only to be advised they have no access to the program. The solution given is to remove the user space Wine directories and to start over. The user gets upset, sometimes with implied violence, and then abandons Wine. What happens is that this user gets on other areas and talks bad about Wine. Thus, Wine gets another black eye to overcome. The idea is to warn users that problems may be encountered if they run Wine as root. If they continue on, it is on them. A message box or warning on the screen, shown one time, is all most newbies need to come back to the forum and ask how to do something. Experts will charge on and if they mess up their system, they know how to fix it. James McKenzie

2 1

Fwd: EVE online losing its Linux Client
by Andrew Fenn Feb. 9, 2009

Feb. 9, 2009

On Mon, Feb 9, 2009 at 2:22 PM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > Since there is not a great Wine audience for the Mac, the Eve Online Mac client should not be abandoned just for that reason. The real reason may be that there is not a great deal of demand for an on-line game interface for the Mac. Most Mac users loath having to use X11 for any purpose, and a game tops the list. I'm pretty sure they're not abandoning the mac client which has shown growth compared to the Linux client.

1 0

Re: ntdll: add a warning about running wine as root (resend)
by James Mckenzie Feb. 9, 2009

Feb. 9, 2009

David Gerard <dgerard(a)gmail.com> wrote: >Sent: Feb 9, 2009 7:45 AM >To: wine-devel(a)winehq.org >Subject: Re: ntdll: add a warning about running wine as root (resend) > >2009/2/9 James Mckenzie <jjmckenzie51(a)earthlink.net>: > >> Thus, the need for the warning. Experts tend to know what they are doing, newbies don't for the >>most part. And yes, I borked many a system as a newbie and as an expert (building kernels for >>RedHat/Fedora for my Thinkpad. > > >Yep. The problem is that newbies are coming from Windows - (a) where >the answer to inability to do something is to try again as >administrator (b) which sometimes takes precautions to keep you from >shooting your foot off. Which is why most establishments have disabled users from having access to Administrator level functions. > >Solutions: > >1. Get better newbies. (Strikes me as unlikely.) I agree and the situation is getting worse rather than better. We have to be able to gently guide newbies from causing harm to themselves. Sort of like handing a new soldier an unloaded weapon and telling them it is. This is what the warning should do. If a newbie carries on, then they 'have been warned' and they cannot blame Wine for causing harm to their system. >2. Something to help stop them shooting their foot off that won't >hamper those who really want to do this. > Again, the one-time warning should suffice. This can set a Registry value so the warning will not display again in that WINEPREFIX. Experts will just ignore the message whereas newbies might just heed it and stop. Then again, some won't. James McKenzie

1 0