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

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote: > On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > Hi, here is my proposed patch to the current msi MsiInstallProduct > > consistency test that will make it's success depend on proper process of > > UI flags (as well as everything else it depends on to make a successful > > install). It seems to me like this is the simplest way to add this test > > (it is only 5-6 lines added total), and it seems fair to me to add it to > > this existing test for two reasons: > > 1. The test is already testing a full product install (installs files, > > services, registry values, etc) and my modification will simply result > > in either no modification to these actions if UI level processing is > > good or complete failure if it is bad, which will make the problem very > > easy to diagnose. > > 2. Looking through instructions on msdn it seems that there isn't a > > kosher way to make a very simple MSI file that just, say, writes a > > registry value (without doing costing, install validation, having a full > > features table, installing some features, etc.) which would make a > > separate function easy to implement and it does not really seem > > necessary to copy and paste the whole test_MsiInstallProduct (or > > similar) function just to check UI level processing. > > > > Changelog: > > > > * msi: Make MsiInstallProduct conformance test depend on proper UI > > level processing. > > > > You need to put whatever you're trying to test into a new test > function. As-is, it's not clear what you're testing and we need to > keep the tests logically separate. Test both a success and a failure > case, plus all the in between cases. > > > If the full UI is started (incorrectly) > > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > > + * not started (correctly) the InstallExecuteSequence table will be used. > > Why does the install fail if we run the InstallUISequence action?. > Also, InstallExecuteSequence runs no matter what so this comment would > need to be fixed. > a fa Weird, because it does indeed fail when running in full UI mode. Do you know a better (more proper) way to do this then? I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test? Thanks Misha

Feb. 7, 2007

Re: advapi32: sign-compare fixes

by Joris Huizer

Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: Joris Huizer wrote: > - int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, > + unsigned int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, This isn't right. WideCharToMultiByte returns INT, which is signed. > @@ -1995,11 +1995,11 @@ LookupAccountSidW( > > if (dm) { > BOOL status = TRUE; > - if (*accountSize > lstrlenW(ac)) { > + if (*accountSize > (unsigned)lstrlenW(ac)) { > if (account) > lstrcpyW(account, ac); > } > - if (*domainSize > lstrlenW(dm)) { > + if (*domainSize > (unsigned)lstrlenW(dm)) { > if (domain) > lstrcpyW(domain, dm); > } This isn't correct either. lstrlenW() also returns INT and you can't just cast it to (unsigned). Unsigned what? int/long/dword? Vitaliy. Sorry I'll fix it; Will try and check in future Joris --------------------------------- Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit.

Feb. 7, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by James Hawkins

On 2/7/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Hi, here is my proposed patch to the current msi MsiInstallProduct > consistency test that will make it's success depend on proper process of > UI flags (as well as everything else it depends on to make a successful > install). It seems to me like this is the simplest way to add this test > (it is only 5-6 lines added total), and it seems fair to me to add it to > this existing test for two reasons: > 1. The test is already testing a full product install (installs files, > services, registry values, etc) and my modification will simply result > in either no modification to these actions if UI level processing is > good or complete failure if it is bad, which will make the problem very > easy to diagnose. > 2. Looking through instructions on msdn it seems that there isn't a > kosher way to make a very simple MSI file that just, say, writes a > registry value (without doing costing, install validation, having a full > features table, installing some features, etc.) which would make a > separate function easy to implement and it does not really seem > necessary to copy and paste the whole test_MsiInstallProduct (or > similar) function just to check UI level processing. > > Changelog: > > * msi: Make MsiInstallProduct conformance test depend on proper UI > level processing. > You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases. > If the full UI is started (incorrectly) > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > + * not started (correctly) the InstallExecuteSequence table will be used. Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. -- James Hawkins

Feb. 7, 2007

Re: advapi32: sign-compare fixes

by Vitaliy Margolen

Joris Huizer wrote: > - int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, > + unsigned int len = WideCharToMultiByte(CP_ACP, 0, lpNameW, -1, lpName, This isn't right. WideCharToMultiByte returns INT, which is signed. > @@ -1995,11 +1995,11 @@ LookupAccountSidW( > > if (dm) { > BOOL status = TRUE; > - if (*accountSize > lstrlenW(ac)) { > + if (*accountSize > (unsigned)lstrlenW(ac)) { > if (account) > lstrcpyW(account, ac); > } > - if (*domainSize > lstrlenW(dm)) { > + if (*domainSize > (unsigned)lstrlenW(dm)) { > if (domain) > lstrcpyW(domain, dm); > } This isn't correct either. lstrlenW() also returns INT and you can't just cast it to (unsigned). Unsigned what? int/long/dword? Vitaliy.

Feb. 7, 2007

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

On Wed, 2007-02-07 at 08:33 -0600, Misha Koshelev wrote: > Hi, just wanted to double-check with msi ppl and other wine developers > if it's okay to add my conformance test to the test_MsiInstallProduct > function. My reasons for doing this versus a completely separate test > function are as follows: > > 1. The test is already testing a full product install (installs files, > services, registry values, etc) and my modification will simply result > in either no modification to these actions if UI level processing is > good or complete failure if it is bad, which will make the problem very > easy to diagnose. > 2. Looking through instructions on msdn it seems that there isn't a > kosher way to make a very simple MSI file that just, say, writes a > registry value (without doing costing, install validation, having a full > features table, installing some features, etc.) which would make a > separate function easy to implement and it does not really seem > necessary to copy and paste the whole test_MsiInstallProduct (or > similar) function just to check UI level processing. > > I could do a separate function, it just seems unnecessary. > > Misha > > p.s. For some reason, I can't compile the msi crosstests (it gives an > error on linking with -lcabinet, whereas, say, kernel32 crosstests > compile file), so if anyone can crosstest it for me that would be > great :) Alright, got the crosstest to work, no new errors with and without my patch on Windows XP. Misha

Feb. 7, 2007

Re: winedump: sign-compare fixes

by Dmitry Timoshkov

"Joris Huizer" <joris_huizer(a)yahoo.com> wrote: > -static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr, int str_idx) > +static const MINIDUMP_DIRECTORY* get_mdmp_dir(const MINIDUMP_HEADER* hdr,unsigned long int str_idx) Please keep white space unchanged. > - while (ptr - (const unsigned char*)table < len) > + while ((unsigned long)(ptr - (const unsigned char*)table) < len) > - int i, length; > + unsigned long int i, length; > - while (file - (const char*)symbols < sizeof(PDB_SYMBOLS) + symbols->module_size) > + while ((unsigned long int)(file - (const char*)symbols) < sizeof(PDB_SYMBOLS) + symbols->module_size) Your changes are inconsistent: sometimes you change 'int' to 'unsigned long int', sometimes to 'unsigned long'. Why not change 'int' simply to 'unsigned'? -- Dmitry.

Feb. 7, 2007

Re: winegcc: sign-compare fixes

by Joris Huizer

Joris Huizer <joris_huizer(a)yahoo.com> wrote: I believe this one causes problems -- please do not commit yet Sorry for the spamming - the patch should be alright --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta.

Feb. 7, 2007

Re: winegcc: sign-compare fixes

by Joris Huizer

I believe this one causes problems -- please do not commit yet Joris Huizer <joris_huizer(a)yahoo.com> wrote: --------------------------------- Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.>From 8686a200bd1f1cbd934d761013c487a9ddc195c9 Mon Sep 17 00:00:00 2001 From: Joris Huizer Date: Wed, 7 Feb 2007 15:19:25 +0100 Subject: [PATCH] winegcc sign-compare fixes To: wine-patches --- tools/winegcc/utils.c | 13 +++++++------ tools/winegcc/winegcc.c | 11 ++++++----- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/tools/winegcc/utils.c b/tools/winegcc/utils.c index 1af91e9..c144077 100644 --- a/tools/winegcc/utils.c +++ b/tools/winegcc/utils.c @@ -120,14 +120,14 @@ void strarray_add(strarray* arr, const c void strarray_del(strarray* arr, int i) { - if (i < 0 || i >= arr->size) error("Invalid index i=%d", i); + if (i < 0 || (unsigned int)i >= arr->size) error("Invalid index i=%d", i); memmove(&arr->base[i], &arr->base[i + 1], (arr->size - i - 1) * sizeof(arr->base[0])); arr->size--; } void strarray_addall(strarray* arr, const strarray* from) { - int i; + unsigned int i; for (i = 0; i < from->size; i++) strarray_add(arr, from->base[i]); @@ -136,7 +136,7 @@ void strarray_addall(strarray* arr, cons strarray* strarray_dup(const strarray* arr) { strarray* dup = strarray_alloc(); - int i; + unsigned int i; for (i = 0; i < arr->size; i++) strarray_add(dup, arr->base[i]); @@ -160,7 +160,7 @@ strarray* strarray_fromstring(const char char* strarray_tostring(const strarray* arr, const char* sep) { char *str, *newstr; - int i; + unsigned int i; str = strmake("%s", arr->base[0]); for (i = 1; i < arr->size; i++) @@ -277,7 +277,7 @@ static file_type guess_lib_type(const ch file_type get_lib_type(strarray* path, const char* library, char** file) { - int i; + unsigned int i; for (i = 0; i < path->size; i++) { @@ -289,7 +289,8 @@ file_type get_lib_type(strarray* path, c void spawn(const strarray* prefix, const strarray* args, int ignore_errors) { - int i, status; + unsigned int i; + int status; strarray* arr = strarray_dup(args); const char** argv; char* prog = 0; diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c index f1aa87e..f1a7bb0 100644 --- a/tools/winegcc/winegcc.c +++ b/tools/winegcc/winegcc.c @@ -170,7 +170,7 @@ struct options static void clean_temp_files(void) { - int i; + unsigned int i; if (keep_generated) return; @@ -239,7 +239,8 @@ static const strarray* get_translator(en static void compile(struct options* opts, const char* lang) { strarray* comp_args = strarray_alloc(); - int j, gcc_defs = 0; + unsigned int j; + int gcc_defs = 0; switch(opts->processor) { @@ -434,7 +435,7 @@ static void build(struct options* opts) const char *output_name, *spec_file, *lang; const char* winebuild = getenv("WINEBUILD"); int generate_app_loader = 1; - int j; + unsigned int j; /* NOTE: for the files array we'll use the following convention: * -axxx: xxx is an archive (.a) @@ -719,7 +720,7 @@ static int is_linker_arg(const char* arg "-static", "-static-libgcc", "-shared", "-shared-libgcc", "-symbolic", "-framework" }; - int j; + unsigned int j; switch (arg[1]) { @@ -769,7 +770,7 @@ static int is_mingw_arg(const char* arg) { "-mno-cygwin", "-mwindows", "-mconsole", "-mthreads", "-municode" }; - int j; + unsigned int j; for (j = 0; j < sizeof(mingw_switches)/sizeof(mingw_switches[0]); j++) if (strcmp(mingw_switches[j], arg) == 0) return 1; -- 1.4.4 --------------------------------- Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.

Feb. 7, 2007

msi: Make MsiInstallProduct conformance test depend on proper UI level processing.

by Misha Koshelev

Hi, just wanted to double-check with msi ppl and other wine developers if it's okay to add my conformance test to the test_MsiInstallProduct function. My reasons for doing this versus a completely separate test function are as follows: 1. The test is already testing a full product install (installs files, services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing. I could do a separate function, it just seems unnecessary. Misha p.s. For some reason, I can't compile the msi crosstests (it gives an error on linking with -lcabinet, whereas, say, kernel32 crosstests compile file), so if anyone can crosstest it for me that would be great :)

Feb. 7, 2007

Re: [urlmon 1/2] Cast-qual warning fix

by Joris Huizer

--- Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Fix a warning and remove the now not needed cast. > > Changelog > Cast-qual warning fix > > Cheers, > > Paul. > > > > diff --git a/dlls/urlmon/umon.c b/dlls/urlmon/umon.c > index 49260ab..d593c81 100644 > --- a/dlls/urlmon/umon.c > +++ b/dlls/urlmon/umon.c > @@ -1605,7 +1605,7 @@ HRESULT WINAPI > URLDownloadToCacheFileW(LPUNKNOWN lpUnkCaller, > LPCWSTR szURL, LPW > HRESULT hr; > LPWSTR ext; > > - static const WCHAR header[] = { > + static WCHAR header[] = { > 'H','T','T','P','/','1','.','0',' > ','2','0','0',' ', > > 'O','K','\\','r','\\','n','\\','r','\\','n',0 > }; > @@ -1631,7 +1631,7 @@ HRESULT WINAPI > URLDownloadToCacheFileW(LPUNKNOWN lpUnkCaller, > LPCWSTR szURL, LPW > modified.dwLowDateTime = 0; > > if (!CommitUrlCacheEntryW(szURL, cache_path, > expire, modified, NORMAL_CACHE_ENTRY, > - (LPWSTR)header, > sizeof(header), NULL, NULL)) > + header, > sizeof(header), NULL, NULL)) > return E_FAIL; > > if (lstrlenW(cache_path) > dwBufLength) > -- If CommitUrlCacheEntryW does not take a constant pointer, this might be dangerous - if it changes the string, the next time this code executes the wrong (modified) string gets used If this is indeed possible, the static keyword needs to be dropped too (ensuring the string is reinitialised with the next call) If it is only not possible in this particular case, sorry for complaining; (though it may be possible to factor out that part of the code that is used, thus ensuring constness) If this is not possible in general, the function CommitUrlCacheEntryW should take a constant pointer instead (same for the other patch) regards, Joris ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

Feb. 7, 2007

Re: Undoc. comctl32 mem management functions

by Michael Stefaniuc

Felix Nawothnig wrote: > Hi. comctl32 exports (undocumented) Alloc() and friends which call > LocalAlloc => GlobalAlloc => HeapAlloc since it's doesn't use any fancy > LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc() directly? > > If Global/Local* behave different than Heap* on Windows - wouldn't it > then be desirable to replace the Alloc()/etc. calls in our comctl32 (we > use it all over the place) by Heap*? > > Reason I'm asking: Since it's not documented the Free(NULL) semantics > are not clear (although it's safe in our implementation) - and I'm > wondering if we really want to internally use undocumented functions > with unclear semantics when there is an easy (documented) way. > > And besides - the comctl32 code is full of "if(p) Free(p);"... Looks like i need to add Free() to my redundant_null_check.pl Smatch script. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Feb. 7, 2007

How to find rendering code

by Markus

Hi, I am new to Wine development and wanted to ask on the list, whether someone could point me to the correct place where the code for issues 3 and 4 in http://bugs.winehq.org/show_bug.cgi?id=7273 might be located. It looks like the solution could be rather straightforward to implement but I have no idea how to find the respective rendering method. Any help would be greatly appreciated. Thanks. -- Markus

Feb. 6, 2007

Re: comctl32: tab: update the item mask after a TB_SETITEM (fixes bug #7345)

by Mikołaj Zalewski

> Actually all members are always valid (for the internal structure at > least). I already sent a patch which removes the mask. > > Felix Sorry, I didn't notice the patch. Mikolaj

Feb. 6, 2007

Re: comctl32: tab: update the item mask after a TB_SETITEM (fixes bug #7345)

by Felix Nawothnig

Mikołaj Zalewski wrote: > Tab uses a mask to mark which fields are set but it new fields were set > by SetItem the mask wasn't updated. Actually all members are always valid (for the internal structure at least). I already sent a patch which removes the mask. Felix

Feb. 6, 2007

Undoc. comctl32 mem management functions

by Felix Nawothnig

Hi. comctl32 exports (undocumented) Alloc() and friends which call LocalAlloc => GlobalAlloc => HeapAlloc since it's doesn't use any fancy LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc() directly? If Global/Local* behave different than Heap* on Windows - wouldn't it then be desirable to replace the Alloc()/etc. calls in our comctl32 (we use it all over the place) by Heap*? Reason I'm asking: Since it's not documented the Free(NULL) semantics are not clear (although it's safe in our implementation) - and I'm wondering if we really want to internally use undocumented functions with unclear semantics when there is an easy (documented) way. And besides - the comctl32 code is full of "if(p) Free(p);"... Felix

Feb. 6, 2007

qemu-0.9.0 and kqemu-1.3.0pre10 (now GPL) released

by Detlef Riekenberg

http://www.qemu.org/ QEMU 0.9.0 was released. The QEMU Accelerator Module kqemu-1.3.0pre10 was released and is now available under the GPL license. Thanks Fabrice, the qemu-team and every contributor. -- By by ... Detlef

Feb. 6, 2007

Re: msi: InstallPackage check for UI level must not disregard flags (updated)

by Felix Nawothnig

Misha Koshelev wrote: >>>So do you think I should add a define like INSTALLUILEVEL_NOFLAGS >>>somewhere set to 0xf then? >>Shouldn't that be 0x7? > I guess either one would work since the first flag is 0x20. Do I need to > change it to 0x7 or leave as is? So would 0x1f or 0xfffffe1f. Doesn't make it correct and could fail if there are undocumented flags (that gap before 0x20 looks suspicious to me...) - and that's more likely than undocumented levels imho (and even with 0x7 we cover another 2). Felix

Feb. 6, 2007

Re: msi: InstallPackage check for UI level must not disregard flags (updated)

by Misha Koshelev

On Tue, 2007-02-06 at 19:51 +0100, Felix Nawothnig wrote: > Misha Koshelev wrote: > >>>So do you think I should add a define like INSTALLUILEVEL_NOFLAGS > >>>somewhere set to 0xf then? > >>Shouldn't that be 0x7? > > I guess either one would work since the first flag is 0x20. Do I need to > > change it to 0x7 or leave as is? > > So would 0x1f or 0xfffffe1f. Doesn't make it correct and could fail if > there are undocumented flags (that gap before 0x20 looks suspicious to > me...) - and that's more likely than undocumented levels imho (and even > with 0x7 we cover another 2). > > Felix Ok, sent a patch update. Sound reasonable. Misha

Feb. 6, 2007

Re: msi: InstallPackage check for UI level must not disregard flags (updated)

by Misha Koshelev

On Tue, 2007-02-06 at 19:23 +0100, Felix Nawothnig wrote: > Koshelev, Misha Vladislavo wrote: > > So do you think I should add a define like INSTALLUILEVEL_NOFLAGS > > somewhere set to 0xf then? > > Shouldn't that be 0x7? I guess either one would work since the first flag is 0x20. Do I need to change it to 0x7 or leave as is? Misha

Feb. 6, 2007

Re: Window focus testing

by Duane Clark

Dmitry Timoshkov wrote: > "Duane Clark" <fpga(a)pacbell.net> wrote: > >> Is it possible to do window focus testing in Wine conformance tests? Or >> does the windows not being mapped mean that this testing cannot be done? >> Or maybe I am doing something completely wrong; which is likely ;) > > Have a look at dlls/user32/tests/win.c,test_SetFocus(). > > Ah, ok. This test shows the window temporarily. Somewhere I had gotten the idea that we didn't do that. Thanks.

Feb. 6, 2007

Re: msi: InstallPackage check for UI level must not disregard flags (updated)

by Felix Nawothnig

Koshelev, Misha Vladislavo wrote: > So do you think I should add a define like INSTALLUILEVEL_NOFLAGS > somewhere set to 0xf then? Shouldn't that be 0x7?

Feb. 6, 2007

Re: [PATCH] coverity: CID35: fixed wrong condition

by Felix Nawothnig

Marcus Meissner wrote: >>>- if(nRelPos>=0) { /* if this or preceding row */ >>>+ if(nRelPos<=0) { /* if this or preceding row */ >>> while(nRelPos<=0) { >>Shouldn't that become a "do { ... } while()" then? > No, since there is a return item; after the while () loop. I meant replacing just the while(), not the if() while(). It's mostly a matter of style though as gcc most likely will compile it to a do {} while() anyway. Felix

Feb. 6, 2007

Re: msi: InstallPackage check for UI level must not disregard flags (updated)

by James Hawkins

On 2/6/07, Koshelev, Misha Vladislavo <mk144210(a)bcm.tmc.edu> wrote: > > > > So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere > set to 0xf then? Should > this be in msi.h (or would this be confusing as this is not defined in > Windows I don't think) or > just in the same file where the other change is being made? > The patch was accepted as-is, so I wouldn't worry about it. P.S. Please bottom-post on replies. -- James Hawkins

Feb. 6, 2007

Re: [PATCH] make CarbonPoker (previously Poker.com) client work.

by Juan Lang

Hi Trent, thanks for the patches. Please send the split up patches to wine-patches instead of wine-devel. The crypt32 patches won't make it in as-is, but I think you can get a better quality hack accepted. As MSDN states, CryptGetMessageCertificates is just a wrapper around CertOpenStore. So you could write something like the following: HCERTSTORE WINAPI CryptGetMessageCertificates( DWORD dwMsgAndCertEncodingType, HCRYPTPROV hCryptProv, DWORD dwFlags, const BYTE* pbSignedBlob, DWORD cbSignedBlob) { CRYPT_DATA_BLOB blob = { cbSignedBlob, (LPBYTE)pbSignedBlob }; TRACE("%d, %p, %d, %p, %d\n", dwMsgAndCertEncodingType, hCryptProv, dwFlags, pbSignedBlob, cbSignedBlob); return CertOpenStore(CERT_STORE_PROV_PKCS7, dwMsgAndCertEncodingType, hCryptProv, dwFlags, &blob); } Then in store.c, add a stub function for opening and closing PKCS7 stores - look at CRYPT_PhysOpenStore for an example. Cheers, --Juan ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

Feb. 6, 2007

Re: Linuxtag 2007 in Berlin

by Kai Blin

On Tuesday 06 February 2007 10:26, Stefan Munz wrote: > Is anybody interested in participating in a Wine booth? More information > (in german) is here: > > http://www.linuxtag.org/2007/de/community/projects/cfpro/call-for-projects. >html English link is http://www.linuxtag.org/2007/en/community/projects/cfpro/call-for-projects.… Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Feb. 6, 2007

RE: msi: InstallPackage check for UI level must not disregard flags (updated)

by Koshelev, Misha Vladislavo

So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere set to 0xf then? Should this be in msi.h (or would this be confusing as this is not defined in Windows I don't think) or just in the same file where the other change is being made? Thanks Misha -----Original Message----- From: James Hawkins [mailto:truiken(a)gmail.com] Sent: Tue 2/6/2007 1:57 AM To: wine-devel(a)winehq.org Cc: Koshelev, Misha Vladislavo Subject: Re: msi: InstallPackage check for UI level must not disregard flags (updated) On 2/6/07, James Hawkins <truiken(a)gmail.com> wrote: > On 2/5/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > This is an update, a little less hacky thanks to advice from Dmitry > > Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was > > getting to the > > point where it was trying to launch the .msi files that do the actual > > install, but was quitting with the message "This module is not designed > > for direct execution." Install worked fine with native MSI. After a > > while of playing with it and disassembling the MSI file with dark.exe > > tool, I noticed that the .msi files ran in execute mode but not UI mode. > > Finally, I checked the UI level that wine msi was reading, and it was > > 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, > > MSI_InstallPackage was only checking if the uilevel >= > > INSTALLUILEVEL_REDUCED, which would have been true in this case as > > INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui > > level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This > > patch fixes this check, and now the installer finished successfully > > (although it seems upon a quick check that there are more install bugs > > for this program in wine, as not all files that should be there seem to > > be there after this install). > > > > Changelog: > > > > * msi: InstallPackage check for UI level must not disregard > > INSTALLUILEVEL flags. > > > > + if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED ) > > > > Magic numbers are bad. What is 0xF? > I just read the thread that this patch came from, but the fact that I had to ask in the first place shows that we need at least a comment or a descriptive constant variable/define. -- James Hawkins

Feb. 6, 2007

Re: Bug 4791 - Civ4 crashes because of recent explorer/systray changes

by Fabian Bieler

Hello! In my last mail I confused a few message types. However, I think I know why this bug occurs. Apparently windows silently ignores nullpointer callbacks passed to SendMessageCallback (although it does deliver the message). Fabian

Feb. 6, 2007

Presenting at LinuxTag?

by Dan Kegel

David asked if anyone's interested in manning a Wine booth at Linuxtag. A related question: is anybody proposing a Wine talk or tutorial at Linuxtag? The deadline for submitting proposals is Feb 16th. (Here's the CFP: http://www.linuxtag.org/2007/en/conf/cfp/cfp-target.html )

Feb. 6, 2007

DirectDrawRenderer=opengl - screen size changeable for final rendering?

by Christoph Frick

hiho what i ever wondered but never dared to ask: i tried recently the said key with jagged alliance 2. as the game has quite a low resolution 640 or 800 it would be nice to allow higher resolutions when rendering ddraw with opengl (e.g. game wants 800 but for the final rendering use 1600). is this doable via registry or somewhere else? for the files: i run the apps in desktop-mode. -- cu

Feb. 6, 2007

Re: Daylight saving changes

by Shachar Shemesh

Francois Gouget wrote: > Israel Standard Time At least with this one I can help. Feel free to use the data under LGPL: http://lingnu.com/support.html#timezone Which is not to say that I know what to do about it..... :-) Shachar

Feb. 6, 2007

Numeric keypad fix for WoW & Warcraft Bug 6323

by Nick Law

Hi Dean Kuslar has patched keyboard.c so that the numeric keypad now works in both World of Warcraft and Warcraft. If anybody is currently doing any development or bug fixing to other games and the numeric keypad doesn't work on the game your working on, we would be interested in hearing if this patch fixes the numeric keypad on your game. The patch is here .. http://bugs.winehq.org/attachment.cgi?id=4730&action=view and the bug is 6323. Regards Nick

Feb. 6, 2007

Re: [PATCH] coverity: CID35: fixed wrong condition

by Marcus Meissner

On Mon, Feb 05, 2007 at 10:29:23PM +0100, Felix Nawothnig wrote: > Marcus Meissner wrote: > >- if(nRelPos>=0) { /* if this or preceding row */ > >+ if(nRelPos<=0) { /* if this or preceding row */ > > while(nRelPos<=0) { > > Shouldn't that become a "do { ... } while()" then? No, since there is a return item; after the while () loop. Actually we might want to kill the whole function, it seems not to be used. I am just not comfortable with removing it. Ciao, Marcus

Feb. 6, 2007

Linuxtag 2007 in Berlin

by Stefan Munz

Hi, there is a "CALL FOR PROJECTS" for Linuxtag 2007 in Germany/Berlin from May 30 to June 2. Is anybody interested in participating in a Wine booth? More information (in german) is here: http://www.linuxtag.org/2007/de/community/projects/cfpro/call-for-projects.… Projects should be registered until February 23. cu, Stefan

Feb. 6, 2007

Re: msi: InstallPackage check for UI level must not disregard flags (updated)

by James Hawkins

On 2/6/07, James Hawkins <truiken(a)gmail.com> wrote: > On 2/5/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > > This is an update, a little less hacky thanks to advice from Dmitry > > Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was > > getting to the > > point where it was trying to launch the .msi files that do the actual > > install, but was quitting with the message "This module is not designed > > for direct execution." Install worked fine with native MSI. After a > > while of playing with it and disassembling the MSI file with dark.exe > > tool, I noticed that the .msi files ran in execute mode but not UI mode. > > Finally, I checked the UI level that wine msi was reading, and it was > > 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, > > MSI_InstallPackage was only checking if the uilevel >= > > INSTALLUILEVEL_REDUCED, which would have been true in this case as > > INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui > > level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This > > patch fixes this check, and now the installer finished successfully > > (although it seems upon a quick check that there are more install bugs > > for this program in wine, as not all files that should be there seem to > > be there after this install). > > > > Changelog: > > > > * msi: InstallPackage check for UI level must not disregard > > INSTALLUILEVEL flags. > > > > + if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED ) > > > > Magic numbers are bad. What is 0xF? > I just read the thread that this patch came from, but the fact that I had to ask in the first place shows that we need at least a comment or a descriptive constant variable/define. -- James Hawkins

Feb. 6, 2007

Re: msi: InstallPackage check for UI level must not disregard flags (updated)

by James Hawkins

On 2/5/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > This is an update, a little less hacky thanks to advice from Dmitry > Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was > getting to the > point where it was trying to launch the .msi files that do the actual > install, but was quitting with the message "This module is not designed > for direct execution." Install worked fine with native MSI. After a > while of playing with it and disassembling the MSI file with dark.exe > tool, I noticed that the .msi files ran in execute mode but not UI mode. > Finally, I checked the UI level that wine msi was reading, and it was > 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, > MSI_InstallPackage was only checking if the uilevel >= > INSTALLUILEVEL_REDUCED, which would have been true in this case as > INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui > level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This > patch fixes this check, and now the installer finished successfully > (although it seems upon a quick check that there are more install bugs > for this program in wine, as not all files that should be there seem to > be there after this install). > > Changelog: > > * msi: InstallPackage check for UI level must not disregard > INSTALLUILEVEL flags. > > + if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED ) > Magic numbers are bad. What is 0xF? -- James Hawkins

Feb. 6, 2007

Re: [PATCH] make CarbonPoker (previously Poker.com) client work.

by Jan Zerebecki

On Mon, Feb 05, 2007 at 11:15:15PM -0600, John Smith wrote: > Is the GPL w/ library exception compatible with LGPL? Seems like they could > be similair. If so we could utilize the gnu PKCS7 code. Does any one know? IANAL but AFAIK, Yes, GPL w/ library exception like on http://www.gnu.org/software/gnu-crypto/ is compatible with LGPL. Jan

Feb. 6, 2007

Re: user32: WM_SETFONT on button doesn't repaint directly

by Dmitry Timoshkov

"Clinton Stimpson" <cjstimpson(a)utwire.net> wrote: > This patch fixes WM_SETFONT on a button to not paint directly. Instead, > it calls InvalidateRect. > A test is included that demonstrates that no paint events come out of > sending a WM_SETFONT. > > > Thanks, > Clinton Stimpson > > ChangeLog: > Setting font on button doesn't repaint directly. I think that your previous version of the test that called UpdateWindow and demonstrated that WM_SETFONT triggers full painting sequence was more correct. I have no idea though why it has not been accepted. Also, as a way to simplify the test there is no need to create a font, I'd suggest to use GetStockObject to retrieve a handle to one of the stock fonts. -- Dmitry.

Feb. 6, 2007

Re: It's that time again - time to start thinking about WineConf 2007!

by richardvoigt＠gmail.com

On 2/5/07, John Smith <xixsimplicityxix(a)gmail.com> wrote: > Yeah, I can no longer find them on MSDN. Laying the blame on MS.... all I can say is "nice!". > > > On 2/5/07, Tom Wickline <twickline(a)gmail.com> wrote: > > On 2/5/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > > > > > That would change the critical path... how do you put that requirement > > > on a Gantt chart? > > > > Have a list of requirements that DNF depends on? > > > > :D > > > > Tom > > > > > > > > :) > > > > > > > > > > >

Feb. 6, 2007

Re: msi patch: Is this too hacky?

by Misha Koshelev

That seems like a good way to do it. I sent an updated patch to wine-patches. Misha On Tue, 2007-02-06 at 12:15 +0800, Dmitry Timoshkov wrote: > "Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > > > Hi, I submitted the following patch to wine-patches but was thinking > > about it some more. The problem is that you have the following UI levels > > and flags: > > INSTALLUILEVEL_NOCHANGE = 0, > > INSTALLUILEVEL_DEFAULT = 1, > > INSTALLUILEVEL_NONE = 2, > > INSTALLUILEVEL_BASIC = 3, > > INSTALLUILEVEL_REDUCED = 4, > > INSTALLUILEVEL_FULL = 5, > > INSTALLUILEVEL_HIDECANCEL = 0x20, > > INSTALLUILEVEL_PROGRESSONLY = 0x40, > > INSTALLUILEVEL_ENDDIALOG = 0x80, > > INSTALLUILEVEL_SOURCERESONLY = 0x100 > > and the code to check for the level was: > > > > if ( msi_get_property_int(package, szUILevel, 0) >= > > INSTALLUILEVEL_REDUCED) > > > > but the problem is that if any of the flags are set, then immediately > > this would assume full UI install even though this is not the case for > > some installers (see bug #6992). I proposed this change: > > > > if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) > >>= > > INSTALLUILEVEL_REDUCED ) > > > > It will work because INSTALLUILEVEL_FULL is 4+1 and so doing an AND operation with > > INSTALLUI_LEVEL FULL will be 4+1 and with INSTALLUILEVEL_REDUCED will be 4, both > > of which are greater than or equal to four. However, if for some reason these UI > > levels were to change in the future, or if someone decided to further modify > > this code and say, try to check for INSTALLUILEVEL_BASIC (3) they would actually > > be getting a 1 instead by doing INSTALLUILEVEL_BASIC & INSTALLUILEVEL_FULL. So > > is this too hacky? Is there a simple, better way to do this? > > Looks like that the flags are placed in the bits higher than 4, so I'd vote > for something like the following: > > if ( (msi_get_property_int(package, szUILevel, 0) & 0x0f)>= INSTALLUILEVEL_REDUCED ) > ... >

Feb. 6, 2007

Re: [PATCH] make CarbonPoker (previously Poker.com) client work.

by John Smith

Is the GPL w/ library exception compatible with LGPL? Seems like they could be similair. If so we could utilize the gnu PKCS7 code. Does any one know? John On 2/5/07, Trent Waddington <trent.waddington(a)gmail.com> wrote: > > On 2/6/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > Please break your patch into logical pieces per dll and submit them > > separately. There is no need to patch ChangeLog, just provide a comment > > what your patch is doing. > > Ok. Seperate patches are attached, comment at the top of each. > > Thanks, > > Trent > > > > >

Feb. 6, 2007

Re: It's that time again - time to start thinking about WineConf 2007!

by John Smith

Yeah, I can no longer find them on MSDN. On 2/5/07, Tom Wickline <twickline(a)gmail.com> wrote: > > On 2/5/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > > > That would change the critical path... how do you put that requirement > > on a Gantt chart? > > Have a list of requirements that DNF depends on? > > :D > > Tom > > > > > :) > > > > >

Feb. 6, 2007

Re: It's that time again - time to start thinking about WineConf 2007!

by Tom Wickline

On 2/5/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > That would change the critical path... how do you put that requirement > on a Gantt chart? Have a list of requirements that DNF depends on? :D Tom > > :) >

Feb. 6, 2007

Re: [PATCH] make CarbonPoker (previously Poker.com) client work.

by Trent Waddington

On 2/6/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Please break your patch into logical pieces per dll and submit them > separately. There is no need to patch ChangeLog, just provide a comment > what your patch is doing. Ok. Seperate patches are attached, comment at the top of each. Thanks, Trent

Feb. 6, 2007

Re: [PATCH] make CarbonPoker (previously Poker.com) client work.

by Dmitry Timoshkov

"Trent Waddington" <trent.waddington(a)gmail.com> wrote: > These changes make the Carbon Poker (www.carbonpoker.com) client work. Please break your patch into logical pieces per dll and submit them separately. There is no need to patch ChangeLog, just provide a comment what your patch is doing. -- Dmitry.

Feb. 6, 2007

Re: [PATCH] make CarbonPoker (previously Poker.com) client work.

by Trent Waddington

On 2/6/07, Trent Waddington <trent.waddington(a)gmail.com> wrote: > These changes make the Carbon Poker (www.carbonpoker.com) client work. > > Run the Carbon Poker installer; then > Run c:/windows/system32/Macromed/Flash/GetFlash.exe; then > Run c:/windows/CarbonPoker/Poker.exe That should be c:/Program Files/CarbonPoker/Poker.exe Sorry, Trent

Feb. 6, 2007

Re: msvcrt: implement _mbbtype according to MSDN

by Dmitry Timoshkov

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > /********************************************************************* > + * _mbbtype(MSVCRT.@) > + */ > +int CDECL _mbbtype(unsigned char c, int type) > +{ > + if (type == 1) > + { > + if ((c >= 0x20 && c <= 0x7e) || (c >= 0xa1 && c <= 0xdf)) > + return _MBC_SINGLE; > + else if ((c >= 0x40 && c <= 0x7e) || (c >= 0x80 && c <= 0xfc)) > + return _MBC_TRAIL; > + else > + return _MBC_ILLEGAL; > + } > + else > + { > + if ((c >= 0x20 && c <= 0x7e) || (c >= 0xa1 && c <= 0xdf)) > + return _MBC_SINGLE; > + else if ((c >= 0x81 && c <= 0x9f) || (c >= 0xe0 && c <= 0xfc)) > + return _MBC_LEAD; > + else > + return _MBC_ILLEGAL; > + } Since MSVCRT_mbctype array is not currently being initialized, probably using MSVCRT_current_ctype would be good enough for now. -- Dmitry.

Feb. 6, 2007

Re: It's that time again - time to start thinking about WineConf 2007!

by richardvoigt＠gmail.com

On 2/5/07, Kai Blin <kai.blin(a)gmail.com> wrote: > On Monday 05 February 2007 23:26, Jeremy White wrote: > > So we can ask, once again: when will 1.0 ship!?!?! > [...] > > p.s. I think Wine will go 1.0 in the same year that is the > > year of Linux on the Desktop <evil grin>. > > Oooh, can we make "Duke Nukem Forever runs" a 1.0 release requirement? Then we > could bundle Wine 1.0 with DNF. ;) That would change the critical path... how do you put that requirement on a Gantt chart? :) > > Cheers, > Kai > > -- > Kai Blin, <kai Dot blin At gmail Dot com> > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin/ > -- > Will code for cotton. > > > > >

Feb. 6, 2007

Re: msi patch: Is this too hacky?

by Dmitry Timoshkov

"Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > Hi, I submitted the following patch to wine-patches but was thinking > about it some more. The problem is that you have the following UI levels > and flags: > INSTALLUILEVEL_NOCHANGE = 0, > INSTALLUILEVEL_DEFAULT = 1, > INSTALLUILEVEL_NONE = 2, > INSTALLUILEVEL_BASIC = 3, > INSTALLUILEVEL_REDUCED = 4, > INSTALLUILEVEL_FULL = 5, > INSTALLUILEVEL_HIDECANCEL = 0x20, > INSTALLUILEVEL_PROGRESSONLY = 0x40, > INSTALLUILEVEL_ENDDIALOG = 0x80, > INSTALLUILEVEL_SOURCERESONLY = 0x100 > and the code to check for the level was: > > if ( msi_get_property_int(package, szUILevel, 0) >= > INSTALLUILEVEL_REDUCED) > > but the problem is that if any of the flags are set, then immediately > this would assume full UI install even though this is not the case for > some installers (see bug #6992). I proposed this change: > > if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) >>= > INSTALLUILEVEL_REDUCED ) > > It will work because INSTALLUILEVEL_FULL is 4+1 and so doing an AND operation with > INSTALLUI_LEVEL FULL will be 4+1 and with INSTALLUILEVEL_REDUCED will be 4, both > of which are greater than or equal to four. However, if for some reason these UI > levels were to change in the future, or if someone decided to further modify > this code and say, try to check for INSTALLUILEVEL_BASIC (3) they would actually > be getting a 1 instead by doing INSTALLUILEVEL_BASIC & INSTALLUILEVEL_FULL. So > is this too hacky? Is there a simple, better way to do this? Looks like that the flags are placed in the bits higher than 4, so I'd vote for something like the following: if ( (msi_get_property_int(package, szUILevel, 0) & 0x0f)>= INSTALLUILEVEL_REDUCED ) ... -- Dmitry.

Feb. 6, 2007

Re: Window focus testing

by Dmitry Timoshkov

"Duane Clark" <fpga(a)pacbell.net> wrote: > Is it possible to do window focus testing in Wine conformance tests? Or > does the windows not being mapped mean that this testing cannot be done? > Or maybe I am doing something completely wrong; which is likely ;) Have a look at dlls/user32/tests/win.c,test_SetFocus(). -- Dmitry.

Feb. 6, 2007

[PATCH] make CarbonPoker (previously Poker.com) client work.

by Trent Waddington

These changes make the Carbon Poker (www.carbonpoker.com) client work. Run the Carbon Poker installer; then Run c:/windows/system32/Macromed/Flash/GetFlash.exe; then Run c:/windows/CarbonPoker/Poker.exe Screenshot: http://rtfm.insomnia.org/~qg/CarbonPoker-Ubuntu-wine.png If someone would like to implement PKCS7 support in crypt32, this patch could be much cleaner. --- ChangeLog | 15 +++++++++++++++ dlls/crypt32/cert.c | 16 ++++++++++++++++ dlls/crypt32/crypt32.spec | 2 +- dlls/crypt32/main.c | 12 +++++++++++- dlls/crypt32/store.c | 4 ++++ dlls/usp10/usp10.c | 33 +++++++++++++++++++++++++++++++++ dlls/usp10/usp10.spec | 2 +- dlls/wininet/http.c | 4 ++-- 8 files changed, 83 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index 658036c..297fb08 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,18 @@ +2007-02-06 Trent Waddington <trent.waddington(a)gmail.com> + + * dlls/crypt32/cert.c: + dlls/crypt32/main.c: + dlls/crypt32/store.c: + dlls/crypt32/crypt32.spec: + crypt32: Hacks to make Macromedia's GetFlash.exe not complain about the lack of PKCS7 support. + + * dlls/usp10/usp10.c: + dlls/usp10/usp10.spec: + usp10: Implemented ScriptGetLogicalWidths. + + * dlls/wininet/http.c: + wininet: Implement a feature of HttpOpenRequestA where lpszAcceptTypes can be terminated with an empty string instead of a NULL. + 2007-01-24 Vitaliy Margolen <wine-patches(a)kievinfo.com> * server/token.c: diff --git a/dlls/crypt32/cert.c b/dlls/crypt32/cert.c index b39c3ca..e3ed7e0 100644 --- a/dlls/crypt32/cert.c +++ b/dlls/crypt32/cert.c @@ -130,6 +130,10 @@ BOOL WINAPI CertFreeCertificateContext(PCCERT_CONTEXT pCertContext) { TRACE("(%p)\n", pCertContext); + // HACK for GetFlash.exe + if (pCertContext == 0xdeadbeef) + return TRUE; + if (pCertContext) Context_Release((void *)pCertContext, sizeof(CERT_CONTEXT), CertDataContext_Free); @@ -921,6 +925,12 @@ PCCERT_CONTEXT WINAPI CertFindCertificateInStore(HCERTSTORE hCertStore, TRACE("(%p, %d, %d, %d, %p, %p)\n", hCertStore, dwCertEncodingType, dwFlags, dwType, pvPara, pPrevCertContext); + // HACK for GetFlash.exe + if (hCertStore == 0xdeadbeef) { + ret = 0xdeadbeef; + return ret; + } + switch (dwType >> CERT_COMPARE_SHIFT) { case CERT_COMPARE_ANY: @@ -987,6 +997,12 @@ BOOL WINAPI CertVerifySubjectCertificateContext(PCCERT_CONTEXT pSubject, static const DWORD supportedFlags = CERT_STORE_REVOCATION_FLAG | CERT_STORE_SIGNATURE_FLAG | CERT_STORE_TIME_VALIDITY_FLAG; + // HACK for GetFlash.exe + if (pSubject == 0xdeadbeef || pIssuer == 0xdeadbeef) { + *pdwFlags = 0; + return TRUE; + } + if (*pdwFlags & ~supportedFlags) { SetLastError(E_INVALIDARG); diff --git a/dlls/crypt32/crypt32.spec b/dlls/crypt32/crypt32.spec index 7ee23f4..705fb8f 100644 --- a/dlls/crypt32/crypt32.spec +++ b/dlls/crypt32/crypt32.spec @@ -118,7 +118,7 @@ @ stub CryptGetAsyncParam @ stdcall CryptGetDefaultOIDDllList(long long ptr ptr) @ stdcall CryptGetDefaultOIDFunctionAddress(long long wstr long ptr ptr) -@ stub CryptGetMessageCertificates +@ stdcall CryptGetMessageCertificates(long long long ptr long) @ stub CryptGetMessageSignerCount @ stdcall CryptGetOIDFunctionAddress(long long str long ptr ptr) @ stdcall CryptGetOIDFunctionValue(long str str wstr ptr ptr ptr) diff --git a/dlls/crypt32/main.c b/dlls/crypt32/main.c index dd9e1fb..80567ab 100644 --- a/dlls/crypt32/main.c +++ b/dlls/crypt32/main.c @@ -238,5 +238,15 @@ BOOL WINAPI CryptVerifyMessageSignature(PCRYPT_VERIFY_MESSAGE_PARA pVerifyPara, FIXME("stub: %p, %d, %p, %d, %p, %p, %p\n", pVerifyPara, dwSignerIndex, pbSignedBlob, cbSignedBlob, pbDecoded, pcbDecoded, ppSignerCert); - return FALSE; + return TRUE; +} + +HCERTSTORE WINAPI CryptGetMessageCertificates(DWORD dwMsgAndCertEncodingType, + HCRYPTPROV hCryptProv, DWORD dwFlags, const BYTE* pbSignedBlob, + DWORD cbSignedBlob) +{ + FIXME("stub: %d, %p, %d, %p, %d\n", + dwMsgAndCertEncodingType, hCryptProv, dwFlags, pbSignedBlob, + cbSignedBlob); + return 0xdeadbeef; // HACK for GetFlash.exe } diff --git a/dlls/crypt32/store.c b/dlls/crypt32/store.c index 8c8cda5..c82fcbc 100644 --- a/dlls/crypt32/store.c +++ b/dlls/crypt32/store.c @@ -2431,6 +2431,10 @@ BOOL WINAPI CertCloseStore(HCERTSTORE hCertStore, DWORD dwFlags) TRACE("(%p, %08x)\n", hCertStore, dwFlags); + // HACK for GetFlash.exe + if (hCertStore == 0xdeadbeef) + return TRUE; + if( ! hCertStore ) return TRUE; diff --git a/dlls/usp10/usp10.c b/dlls/usp10/usp10.c index c3b0a17..6f860e0 100644 --- a/dlls/usp10/usp10.c +++ b/dlls/usp10/usp10.c @@ -1553,6 +1553,39 @@ HRESULT WINAPI ScriptStringGetLogicalWidths(SCRIPT_STRING_ANALYSIS ssa, int *piD } /*********************************************************************** + * ScriptGetLogicalWidths (USP10.@) + * + * Returns logical widths from an analysis. + * + * PARAMS + * psa [I] analysis. + * cChars [I] count of logical code points in the run. + * cGlyphs [I] count of glyphs in the run. + * piGlyphWidth [I] array of glyph advance widths. + * pwLogClust [I] array of logical clusters. + * psva [I] visual attributes. + * piDx [O] logical widths returned. + * + * RETURNS + * Success: S_OK + * Failure: a non-zero HRESULT. + */ +HRESULT WINAPI ScriptGetLogicalWidths(const SCRIPT_ANALYSIS *psa, int cChars, + int cGlyphs, const int *piGlyphWidth, const WORD *pwLogClust, + const SCRIPT_VISATTR *psva, int *piDx) +{ + int i; + + TRACE("%p, %d, %d, %p %p, %p, %p\n", psa, cChars, cGlyphs, piGlyphWidth, pwLogClust, psva, piDx); + + for (i = 0; i < cGlyphs; i++) + { + piDx[i] = piGlyphWidth[i]; + } + return S_OK; +} + +/*********************************************************************** * ScriptStringValidate (USP10.@) * * Validate a string analysis. diff --git a/dlls/usp10/usp10.spec b/dlls/usp10/usp10.spec index df07f43..ac1506e 100644 --- a/dlls/usp10/usp10.spec +++ b/dlls/usp10/usp10.spec @@ -8,7 +8,7 @@ @ stdcall ScriptGetCMap(ptr ptr ptr long long ptr) @ stdcall ScriptGetFontProperties(long ptr ptr) @ stdcall ScriptGetGlyphABCWidth(ptr ptr long ptr) -@ stub ScriptGetLogicalWidths +@ stdcall ScriptGetLogicalWidths(ptr long long ptr ptr ptr ptr) @ stdcall ScriptGetProperties(ptr long) @ stdcall ScriptIsComplex(wstr long long) @ stdcall ScriptItemize(wstr long long ptr ptr ptr ptr) diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c index 8a34749..379b03e 100644 --- a/dlls/wininet/http.c +++ b/dlls/wininet/http.c @@ -803,11 +803,11 @@ HINTERNET WINAPI HttpOpenRequestA(HINTERNET hHttpSession, if (lpszAcceptTypes) { /* find out how many there are */ - while (lpszAcceptTypes[acceptTypesCount]) + while (lpszAcceptTypes[acceptTypesCount] && *lpszAcceptTypes[acceptTypesCount]) acceptTypesCount++; szAcceptTypes = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR *) * (acceptTypesCount+1)); acceptTypesCount = 0; - while (lpszAcceptTypes[acceptTypesCount]) + while (lpszAcceptTypes[acceptTypesCount] && *lpszAcceptTypes[acceptTypesCount]) { len = MultiByteToWideChar(CP_ACP, 0, lpszAcceptTypes[acceptTypesCount], -1, NULL, 0 ); -- 1.4.4.3

Feb. 6, 2007

Re: Dead links

by Tom Wickline

Hello, It's kind of bad when you intend on fixing broken URLs and then send one :) I have that page linked on my wiki page (and have since fixed) and was in a hurry and sent the old broke link. If all goes as planed I should have some free time starting next week to work on this. Cheers, Tom On 1/19/07, Lei Zhang <thestig(a)google.com> wrote: > I get the 403 error as well, most of time from pages under hypermail/ > Google indexed. I don't know when the mailing list archives changed, > but the page is still viewable here: > http://winehq.org/pipermail/wine-devel/2003-June/017893.html > > On 1/19/07, Francois Gouget <fgouget(a)free.fr> wrote: > > On Fri, 19 Jan 2007, Tom Wickline wrote: > > [...] > > > http://www.winehq.com/hypermail/wine-devel/2003/06/0325.html > > > > Does this URL work for you? > > It gives me a 403 Forbidden error here.

Feb. 6, 2007

msi patch: Is this too hacky?

by Misha Koshelev

Hi, I submitted the following patch to wine-patches but was thinking about it some more. The problem is that you have the following UI levels and flags: INSTALLUILEVEL_NOCHANGE = 0, INSTALLUILEVEL_DEFAULT = 1, INSTALLUILEVEL_NONE = 2, INSTALLUILEVEL_BASIC = 3, INSTALLUILEVEL_REDUCED = 4, INSTALLUILEVEL_FULL = 5, INSTALLUILEVEL_HIDECANCEL = 0x20, INSTALLUILEVEL_PROGRESSONLY = 0x40, INSTALLUILEVEL_ENDDIALOG = 0x80, INSTALLUILEVEL_SOURCERESONLY = 0x100 and the code to check for the level was: if ( msi_get_property_int(package, szUILevel, 0) >= INSTALLUILEVEL_REDUCED) but the problem is that if any of the flags are set, then immediately this would assume full UI install even though this is not the case for some installers (see bug #6992). I proposed this change: if ( (msi_get_property_int(package, szUILevel, 0) & INSTALLUILEVEL_FULL) >= INSTALLUILEVEL_REDUCED ) It will work because INSTALLUILEVEL_FULL is 4+1 and so doing an AND operation with INSTALLUI_LEVEL FULL will be 4+1 and with INSTALLUILEVEL_REDUCED will be 4, both of which are greater than or equal to four. However, if for some reason these UI levels were to change in the future, or if someone decided to further modify this code and say, try to check for INSTALLUILEVEL_BASIC (3) they would actually be getting a 1 instead by doing INSTALLUILEVEL_BASIC & INSTALLUILEVEL_FULL. So is this too hacky? Is there a simple, better way to do this? Thanks Misha

Feb. 6, 2007

Re: Donation for your work on Direct 3D

by Tom Wickline

On 2/1/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > > > Send it to the Wine Party Fund, I'd say. Here is the link: http://www.winehq.org/site/contributing#wpf Cheers, Tom > > Henri > > >

Feb. 6, 2007

Re: It's that time again - time to start thinking about WineConf 2007!

by Kai Blin

On Monday 05 February 2007 23:26, Jeremy White wrote: > So we can ask, once again: when will 1.0 ship!?!?! [...] > p.s. I think Wine will go 1.0 in the same year that is the > year of Linux on the Desktop <evil grin>. Oooh, can we make "Duke Nukem Forever runs" a 1.0 release requirement? Then we could bundle Wine 1.0 with DNF. ;) Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Feb. 6, 2007

Window focus testing

by Duane Clark

Is it possible to do window focus testing in Wine conformance tests? Or does the windows not being mapped mean that this testing cannot be done? Or maybe I am doing something completely wrong; which is likely ;) I am specifically trying to test window focus in this bug: http://bugs.winehq.org/show_bug.cgi?id=7280 As mentioned in the bug, I turned the treeview conformance test into a standalone test with a mapped window, and added testing that does show focus behavior. But so far I have not been able to get it to give good results in a Wine conformance test.

Feb. 5, 2007

Re: It's that time again - time to start thinking about WineConf 2007!

by John Smith

You mean once wine 1.0 is shipped that will bring about the year of linux on the desktop. =) On 2/5/07, Jeremy White <jwhite(a)codeweavers.com> wrote: > > So we can ask, once again: when will 1.0 ship!?!?! > > I'd invite anyone with an interest in attending to subscribe > to the Wineconf mailing list: > > http://www.winehq.org/mailman/listinfo/wineconf > > I think an approach that makes sense is for us to discuss > options as to where to hold it this year on that list, and > then present either a consensus or choices back to the wine-devel list > once we're done. > > So please come join us, particularly if you have a suggestion > or preference for where it should be held! > > Cheers, > > Jeremy > > p.s. I think Wine will go 1.0 in the same year that is the > year of Linux on the Desktop <evil grin>. > > >

Feb. 5, 2007

It's that time again - time to start thinking about WineConf 2007!

by Jeremy White

So we can ask, once again: when will 1.0 ship!?!?! I'd invite anyone with an interest in attending to subscribe to the Wineconf mailing list: http://www.winehq.org/mailman/listinfo/wineconf I think an approach that makes sense is for us to discuss options as to where to hold it this year on that list, and then present either a consensus or choices back to the wine-devel list once we're done. So please come join us, particularly if you have a suggestion or preference for where it should be held! Cheers, Jeremy p.s. I think Wine will go 1.0 in the same year that is the year of Linux on the Desktop <evil grin>.

Feb. 5, 2007

Re: [Bug 6689] Created links do not reflect WINEPREFIX used

by Lei Zhang

On 1/29/07, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > Mandag 29 januar 2007 20:58, skrev Kuba Ober: > > On Monday 29 January 2007 12:50, Tomas Carnecky wrote: > > > Lei Zhang wrote: > > > > Setting the Exec= line in a .desktop file to: WINEPREFIX=foo wine bar > > > > worked in KDE. In Gnome, it works if "run from the terminal" is set. > > > > > > > > Unfortunately the Freedesktop spec for desktop entries does not > > > > specify a way to add environment variables. So yes, it looks like > > > > we'll need a wrapper script, or perhaps add a --prefix option to Wine? > > > > > > or change the exec line to: > > > /bin/sh -i -c "WINEPREFIX=foo wine" > > > > Instead, wouldn't > > /bin/sh -i -c "WINEPREFIX=foo exec wine" > > also properly dispose of the now useless copy of the shell? > > > > You don't have to start a new shell if you use > > env WINEPREFIX=foo wine > > > Regards, > > Alexander N. Sørnes > > > Cheers, Kuba > > > This sounds like the best solution so far. If nobody else has any objections, I'll test it out in Gnome and KDE, and then send in a patch.

Feb. 5, 2007

Re: [PATCH] coverity: CID35: fixed wrong condition

by Felix Nawothnig

Marcus Meissner wrote: > - if(nRelPos>=0) { /* if this or preceding row */ > + if(nRelPos<=0) { /* if this or preceding row */ > while(nRelPos<=0) { Shouldn't that become a "do { ... } while()" then?

Feb. 5, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Damjan Jovanovic

On 2/5/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > On 2/3/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > "Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > > > > > In wine's struct _stati64, st_size has an offset of 20 bytes from the > > > beginning of the struct, unlike mingw's and Window's 24. This breaks > > > Java 1.4.x pretty badly, it dies on startup complaining about a > > > truncated class file (#2953). Using #include <pshpack8.h> and #include > > > <pshpop8.h> around the struct didn't help, so a padding field was used > > > instead. > > > > Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to > > align the Size field help? > > > > #include <pshpack8.h> > > typedef struct _WIN32_STREAM_ID { > > DWORD dwStreamId; > > DWORD dwStreamAttributes; > > LARGE_INTEGER DECLSPEC_ALIGN(8) Size; > > DWORD dwStreamNameSize; > > WCHAR cStreamName[ANYSIZE_ARRAY]; > > } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; > > #include <poppack.h> > > That doesn't help. Sorry, that (as in DECLSPEC_ALIGN(8)) DOES work, I didn't see it before. I'll send a patch that does that instead of using a padding field. > > Dmitry. > > Damjan Damjan

Feb. 5, 2007

Re: Synchronize code page 20127 table with Windows one

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> writes: > That's not really possible due to a confusing license accompanying the unicode.org > mappings, and a policy (until at least now) to not patch unicode.org provided data. > Otherwise we have to patch the unicode collation table (I had a patch for it somewhere) > as well as some other code page tables (problem with cp1251 table comes to mind as was > reported recently). Distributing patched unicode.org files is not something we want to do, but modifying the mapping tables in cpmap.pl after they are loaded is acceptable, we already have a couple of cases where we do that. -- Alexandre Julliard julliard(a)winehq.org

Feb. 5, 2007

Re: Bugzilla: Adding a 'patch' keyword

by Francois Gouget

On Tue, 30 Jan 2007, Francois Gouget wrote: [...] > But it would be nice if there was an easy way to find bugs that have a > patch, even, and maybe especially, if it is incorrect. This would make > it easier for interested parties to survey what potential fixes are > languishing in Bugzilla and push them to wine-devel or wine-patches. I see everyone agrees :-/ So could someone add the 'patch' keyword? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

Feb. 5, 2007

Re: [try3]: user32/tests: add tests for WM_SETICON - what's wrong?

by Kirill K. Smirnov

Hi, I've asked before: What's wrong with them? Maybe, unnecessary PeekMessage in tests??? http://www.winehq.org/pipermail/wine-patches/2007-January/035044.html http://www.winehq.org/pipermail/wine-patches/2007-January/035043.html Please, answer! Do not ignore! -- Kirill

Feb. 5, 2007

Re: help in debugging

by Ioannis Nousias

forgot to mention that I've added a bug report for this few weeks ago: http://bugs.winehq.org/show_bug.cgi?id=7227 and an entry in wine's Application Database: http://appdb.winehq.org/appview.php?iAppId=2922 regards Ioannis > Damjan Jovanovic wrote: >> On 2/5/07, Ioannis Nousias <s0238762(a)sms.ed.ac.uk> wrote: >>> Hello Wine developers, >>> >>> I've decided to see what causes floAt's Mobile Agent[1] to fail with >>> wine >>> >>> I checked the wine developers' cheatsheet to help me debug the >>> application, but I'm lost. >>> >>> The application installs but with some error: >>> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll >>> Unable to register the DLL/OCX: LoadLibrary failed; code 126 >>> Module not found." >> >> Can you try typing >> $ regsvr32 BramusICQ.dll >> manually? You'll have to do it from the directory it's in. >> > sure. > > $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll > err:module:import_dll Library MSVBVM60.DLL (which is needed by > L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found > Failed to load DLL BramusICQ.dll > > it's seems I need this MSVBVM60.DLL. It's nowhere in the application's > installation or wine's systems folders. > >>> I click "ignore" and the installation continues. When I try to execute >>> the installed binary "MobileAgent.exe" it fails. >>> >>> I invoke it like this: >>> >>> WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe >>> >>> no error messages are produce by the app itself. >>> >>> on wine's debug log I see the following, just before winedbg starts: >>> >>> 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 >>> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >>> trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade >>> flags=1 >>> 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) >>> ret=0040427c >>> 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >>> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >>> flags= >>> 00200246 >>> trace:seh:__regs_RtlUnwind code=eedfade flags=3 >>> trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade >>> flags=3 >>> trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 >>> 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c >>> 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >>> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >>> flags= >>> 00200246 >>> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >>> trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade >>> flags=1 >>> trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 >>> trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade >>> flags=1 >>> 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc >>> wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 >>> (thread 0009), starting debugger... >>> trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" >>> >>> this is not the first "trace:seh". Relatively early in the call stack >>> there is this: >>> >>> 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b >>> trace:seh:raise_exception info[0]=00000000 >>> trace:seh:raise_exception info[1]=ffffffff >>> trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 >>> edx=0000ffff esi=00000000 edi=ffffffff >>> trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b >>> es=007b fs=0033 gs=003b flags=00010206 >>> trace:seh:call_stack_handlers calling handler at 0x602b5540 >>> code=c0000005 flags=0 >>> trace:seh:__regs_RtlUnwind code=c0000005 flags=2 >>> trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 >>> flags=2 >>> trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 >>> ffffffff (invalid)) ret=6033e95f >>> >>> which looks suspicious to me. >>> >>> Am I on the right track? Unfortunately I'm not familiar with windows >>> API >>> or wine's underlying architecture. I need some guidance please :) >>> I'm an >>> experienced C/C++ programmer. >>> >>> thanks >>> >>> -Ioannis >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [1] http://fma.sourceforge.net/index2.htm >>> >>> >>> > > >

Feb. 5, 2007

Re: Getting Fallout 2 to work well

by Mitchell Mebane

Stefan Dösinger wrote: > Am Freitag 02 Februar 2007 08:34 schrieb Joonas Koivunen: > >> Profiling with oprofile (GDI session) shows that most of the time is used >> in the game (I suppose it's the "anon" from wine-preload), next most time >> consuming is winex11 drivers X11DRV_DIB_SetImageBits which seems to be >> doing the conversion. >> > It seems that you have a game that has problems with the gdi engine(or lack > thereof): http://wiki.winehq.org/DIBEngine > > http://bugs.winehq.org/show_bug.cgi?id=421 > > ------------------------------------------------------------------------ > > > How much work would this be? I know nothing about Windows or X11 programming, but is it something that I might be able to study up on and propose for a Summer of Code project? --mmebane

Feb. 5, 2007

Re: help in debugging

by Ioannis Nousias

Kuba Ober wrote: >>>> The application installs but with some error: >>>> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll >>>> Unable to register the DLL/OCX: LoadLibrary failed; code 126 >>>> Module not found." >>>> >>> Can you try typing >>> $ regsvr32 BramusICQ.dll >>> manually? You'll have to do it from the directory it's in. >>> >> sure. >> >> $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll >> err:module:import_dll Library MSVBVM60.DLL (which is needed by >> L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found >> Failed to load DLL BramusICQ.dll >> >> it's seems I need this MSVBVM60.DLL. It's nowhere in the application's >> installation or wine's systems folders. >> > > Er, google for it? The first hit is a free download of that dll. The > application's installer is probably broken in assuming that such a dll will > exist on all windows systems (it probably doesn't exist on a clean win95, at > least). > :) yes, of course. done that already. The dll registers fine. unfortunately, that was not the problem. thanks. -Ioannis

Feb. 5, 2007

Re: comctl32 kibitzers wanted

by Dimi Paun

On Mon, February 5, 2007 03:16, Dan Kegel wrote: > I and Lei Zhang, with some help from James Hawkins, > are leading a group of 13 UCLA students who are > writing conformance tests for comctl32. Brilliant! > Each student picked one control, and is now busily writing > getter/setter tests. In the coming few weeks we'll > also try more interesting tests, like verifying that > the right messages are sent in the right order. > If you're interested in helping the students in any way > (reviewing code before it hits wine-patches, offering > suggestions on how to test tricky bits, or whatever), > please let me know and I can add you to the project's > mailing list. Sure, please add me to the list. I've had my share of work in that area (comboex, listview, progressbar, updown, etc.) and I might be able to help. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Feb. 5, 2007

Re: help in debugging

by Kuba Ober

> >> The application installs but with some error: > >> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll > >> Unable to register the DLL/OCX: LoadLibrary failed; code 126 > >> Module not found." > > > > Can you try typing > > $ regsvr32 BramusICQ.dll > > manually? You'll have to do it from the directory it's in. > > sure. > > $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll > err:module:import_dll Library MSVBVM60.DLL (which is needed by > L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found > Failed to load DLL BramusICQ.dll > > it's seems I need this MSVBVM60.DLL. It's nowhere in the application's > installation or wine's systems folders. Er, google for it? The first hit is a free download of that dll. The application's installer is probably broken in assuming that such a dll will exist on all windows systems (it probably doesn't exist on a clean win95, at least). Cheers, Kuba

Feb. 5, 2007

Re: shell32: shlfileop tests: avoid buffer overflows for paths

by Mikołaj Zalewski

>> @@ -329,8 +329,8 @@ static void test_delete(void) >> static void test_rename(void) >> { >> SHFILEOPSTRUCTA shfo, shfo2; >> - CHAR from[MAX_PATH]; >> - CHAR to[MAX_PATH]; >> + CHAR from[5*MAX_PATH]; >> + CHAR to[5*MAX_PATH]; >> DWORD retval; >> >> shfo.hwnd = NULL; >> > > This is really hacky. If this is fixed, it needs to be fixed properly. > I thought this is enough - we never put more that three paths in the buffer and tester probably won't have paths longer than MAX_PATH as they are not supported by the shell. What do you mean by a proper fix - some overflow checking in set_curr_dir_path and skipping the rest of tests in such a case? Mikolaj Zalewski

Feb. 5, 2007

Re: help in debugging

by Ioannis Nousias

Damjan Jovanovic wrote: > On 2/5/07, Ioannis Nousias <s0238762(a)sms.ed.ac.uk> wrote: >> Hello Wine developers, >> >> I've decided to see what causes floAt's Mobile Agent[1] to fail with >> wine >> >> I checked the wine developers' cheatsheet to help me debug the >> application, but I'm lost. >> >> The application installs but with some error: >> "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll >> Unable to register the DLL/OCX: LoadLibrary failed; code 126 >> Module not found." > > Can you try typing > $ regsvr32 BramusICQ.dll > manually? You'll have to do it from the directory it's in. > sure. $ WINEPREFIX=/tmp/winetemp regsvr32 BramusICQ.dll err:module:import_dll Library MSVBVM60.DLL (which is needed by L"C:\\Program Files\\Fma\\sframework\\helper\\BramusICQ.dll") not found Failed to load DLL BramusICQ.dll it's seems I need this MSVBVM60.DLL. It's nowhere in the application's installation or wine's systems folders. >> I click "ignore" and the installation continues. When I try to execute >> the installed binary "MobileAgent.exe" it fails. >> >> I invoke it like this: >> >> WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe >> >> no error messages are produce by the app itself. >> >> on wine's debug log I see the following, just before winedbg starts: >> >> 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 >> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >> trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade >> flags=1 >> 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) >> ret=0040427c >> 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >> flags= >> 00200246 >> trace:seh:__regs_RtlUnwind code=eedfade flags=3 >> trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade >> flags=3 >> trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 >> 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c >> 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 >> edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b >> flags= >> 00200246 >> trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 >> trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade >> flags=1 >> trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 >> trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade >> flags=1 >> 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc >> wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 >> (thread 0009), starting debugger... >> trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" >> >> this is not the first "trace:seh". Relatively early in the call stack >> there is this: >> >> 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b >> trace:seh:raise_exception info[0]=00000000 >> trace:seh:raise_exception info[1]=ffffffff >> trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 >> edx=0000ffff esi=00000000 edi=ffffffff >> trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b >> es=007b fs=0033 gs=003b flags=00010206 >> trace:seh:call_stack_handlers calling handler at 0x602b5540 >> code=c0000005 flags=0 >> trace:seh:__regs_RtlUnwind code=c0000005 flags=2 >> trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 >> flags=2 >> trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 >> ffffffff (invalid)) ret=6033e95f >> >> which looks suspicious to me. >> >> Am I on the right track? Unfortunately I'm not familiar with windows API >> or wine's underlying architecture. I need some guidance please :) I'm an >> experienced C/C++ programmer. >> >> thanks >> >> -Ioannis >> >> >> >> >> >> >> >> >> >> >> >> [1] http://fma.sourceforge.net/index2.htm >> >> >>

Feb. 5, 2007

Re: help in debugging

by Damjan Jovanovic

On 2/5/07, Ioannis Nousias <s0238762(a)sms.ed.ac.uk> wrote: > Hello Wine developers, > > I've decided to see what causes floAt's Mobile Agent[1] to fail with wine > > I checked the wine developers' cheatsheet to help me debug the > application, but I'm lost. > > The application installs but with some error: > "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll > Unable to register the DLL/OCX: LoadLibrary failed; code 126 > Module not found." Can you try typing $ regsvr32 BramusICQ.dll manually? You'll have to do it from the directory it's in. > I click "ignore" and the installation continues. When I try to execute > the installed binary "MobileAgent.exe" it fails. > > I invoke it like this: > > WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe > > no error messages are produce by the app itself. > > on wine's debug log I see the following, just before winedbg starts: > > 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 > trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 > trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade > flags=1 > 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c > 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 > edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b > flags= > 00200246 > trace:seh:__regs_RtlUnwind code=eedfade flags=3 > trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade > flags=3 > trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 > 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c > 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 > edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b > flags= > 00200246 > trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 > trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade > flags=1 > trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 > trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade > flags=1 > 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc > wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 > (thread 0009), starting debugger... > trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" > > this is not the first "trace:seh". Relatively early in the call stack > there is this: > > 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b > trace:seh:raise_exception info[0]=00000000 > trace:seh:raise_exception info[1]=ffffffff > trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 > edx=0000ffff esi=00000000 edi=ffffffff > trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b > es=007b fs=0033 gs=003b flags=00010206 > trace:seh:call_stack_handlers calling handler at 0x602b5540 > code=c0000005 flags=0 > trace:seh:__regs_RtlUnwind code=c0000005 flags=2 > trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 > flags=2 > trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 > ffffffff (invalid)) ret=6033e95f > > which looks suspicious to me. > > Am I on the right track? Unfortunately I'm not familiar with windows API > or wine's underlying architecture. I need some guidance please :) I'm an > experienced C/C++ programmer. > > thanks > > -Ioannis > > > > > > > > > > > > [1] http://fma.sourceforge.net/index2.htm > > >

Feb. 5, 2007

help in debugging

by Ioannis Nousias

Hello Wine developers, I've decided to see what causes floAt's Mobile Agent[1] to fail with wine I checked the wine developers' cheatsheet to help me debug the application, but I'm lost. The application installs but with some error: "C:\Program Files\Fma\sframeword\helper\BramusICQ.dll Unable to register the DLL/OCX: LoadLibrary failed; code 126 Module not found." I click "ignore" and the installation continues. When I try to execute the installed binary "MobileAgent.exe" it fails. I invoke it like this: WINEDEBUG=+seh,+relay WINEPREFIX=/tmp/winetemp wine MobileAgent.exe no error messages are produce by the app itself. on wine's debug log I see the following, just before winedbg starts: 0009:Ret kernel32.SetEvent() retval=00000001 ret=00410759 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x477d9a code=eedfade flags=1 0009:Call ntdll.RtlUnwind(0034feb8,0040427c,0034f140,00000000) ret=0040427c 0009: eax=0034f140 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:__regs_RtlUnwind code=eedfade flags=3 trace:seh:__regs_RtlUnwind calling handler at 0x60178400 code=eedfade flags=3 trace:seh:__regs_RtlUnwind handler at 0x60178400 returned 1 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040427c 0009: eax=00000000 ebx=0034eca0 ecx=005acb61 edx=0034feb8 esi=0034feb8 edi=00000001 ebp=0034ecb8 esp=0034ec6c ds=007b es=007b fs=0033 gs=003b flags= 00200246 trace:seh:call_stack_handlers handler at 0x4045c7 returned 1 trace:seh:call_stack_handlers calling handler at 0x69ff49 code=eedfade flags=1 trace:seh:call_stack_handlers handler at 0x69ff49 returned 1 trace:seh:call_stack_handlers calling handler at 0x4046b8 code=eedfade flags=1 0009:Call kernel32.UnhandledExceptionFilter(0034ec90) ret=004046dc wine: Unhandled exception 0x0eedfade at address 0x0000:0x6024daa0 (thread 0009), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 8 228" this is not the first "trace:seh". Relatively early in the call stack there is this: 000b:Call user32.SetDeskWallPaper(code=c0000005 flags=0 addr=0x601b044b trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=ffffffff trace:seh:raise_exception eax=ffffffff ebx=6011999c ecx=00000003 edx=0000ffff esi=00000000 edi=ffffffff trace:seh:raise_exception ebp=00117b98 esp=0034f61c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010206 trace:seh:call_stack_handlers calling handler at 0x602b5540 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x602b5400 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x602b5400 returned 1 ffffffff (invalid)) ret=6033e95f which looks suspicious to me. Am I on the right track? Unfortunately I'm not familiar with windows API or wine's underlying architecture. I need some guidance please :) I'm an experienced C/C++ programmer. thanks -Ioannis [1] http://fma.sourceforge.net/index2.htm

Feb. 5, 2007

Re: shell32: shlfileop tests: avoid buffer overflows for paths

by James Hawkins

On 2/4/07, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > These buffers can contain multiple paths and set_curr_dir_path can make > the paths long resulting in a buffer overflow. > > From 36e05f3140e57bad2af790c56073799d23f7ef60 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= <mikolaj(a)zalewski.pl> > Date: Thu, 25 Jan 2007 12:17:11 +0100 > Subject: [PATCH] shell32: shlfileop tests: avoid buffer overflows for paths > > --- > dlls/shell32/tests/shlfileop.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index b363c5e..23aaeba 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > @@ -329,8 +329,8 @@ static void test_delete(void) > static void test_rename(void) > { > SHFILEOPSTRUCTA shfo, shfo2; > - CHAR from[MAX_PATH]; > - CHAR to[MAX_PATH]; > + CHAR from[5*MAX_PATH]; > + CHAR to[5*MAX_PATH]; > DWORD retval; > > shfo.hwnd = NULL; > This is really hacky. If this is fixed, it needs to be fixed properly. -- James Hawkins

Feb. 5, 2007

comctl32 kibitzers wanted

by Dan Kegel

I and Lei Zhang, with some help from James Hawkins, are leading a group of 13 UCLA students who are writing conformance tests for comctl32. Each student picked one control, and is now busily writing getter/setter tests. In the coming few weeks we'll also try more interesting tests, like verifying that the right messages are sent in the right order. If you're interested in helping the students in any way (reviewing code before it hits wine-patches, offering suggestions on how to test tricky bits, or whatever), please let me know and I can add you to the project's mailing list. Thanks, Dan

Feb. 5, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Damjan Jovanovic

On 2/3/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > > > In wine's struct _stati64, st_size has an offset of 20 bytes from the > > beginning of the struct, unlike mingw's and Window's 24. This breaks > > Java 1.4.x pretty badly, it dies on startup complaining about a > > truncated class file (#2953). Using #include <pshpack8.h> and #include > > <pshpop8.h> around the struct didn't help, so a padding field was used > > instead. > > Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to > align the Size field help? > > #include <pshpack8.h> > typedef struct _WIN32_STREAM_ID { > DWORD dwStreamId; > DWORD dwStreamAttributes; > LARGE_INTEGER DECLSPEC_ALIGN(8) Size; > DWORD dwStreamNameSize; > WCHAR cStreamName[ANYSIZE_ARRAY]; > } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; > #include <poppack.h> That doesn't help. I heard somewhere GCC up to version 4.1.12 or so didn't align some things properly (I'm using 4.0.3). Since mingw aligns it properly with the same declaration as wine and it uses GCC 3.4.4, maybe it's a GCC bug. > > +static void test_stat( void ) > > +{ > > + int offset = offsetof(struct _stati64, st_size); > > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > > +} > > This should be a part of auto generated header tests. Have a look at > dlls/*/tests/generated.c files. Thanks. > -- > Dmitry. Damjan

Feb. 5, 2007

Re: Detect screen resolution change errors

by Stefan Dösinger

Am Freitag 02 Februar 2007 16:24 schrieb Francois Gouget: > Is there some code that would show what cleaning the GL context entails? > I have looked at the other exit paths of CreateAdditionalSwapChain() > but the only relevant one only does stuff if object->frontBuffer != NULL > which cannot be the case there. I have patches in my tree which change the context creation, and they also clean up properly in the case of an error(hopefully). I'll send them when things get going again after Alexandre's return.

Feb. 5, 2007

Re: Detect screen resolution change errors

by Francois Gouget

H. Verbeet wrote: > On 30/01/07, Francois Gouget <fgouget(a)codeweavers.com> wrote: >> I have attached the relevant patches. Does this look ok to the DirectX >> gurus? >> > At least the wined3d part looks ok to me, although we should probably > be cleaning up the GL context as well, there and in the other places > where we return. Is there some code that would show what cleaning the GL context entails? I have looked at the other exit paths of CreateAdditionalSwapChain() but the only relevant one only does stuff if object->frontBuffer != NULL which cannot be the case there. -- Francois Gouget fgouget(a)codeweavers.com

Feb. 4, 2007

Re: Detect screen resolution change errors

by Francois Gouget

Stefan Dösinger wrote: > Am Mittwoch 31 Januar 2007 10:25 schrieb H. Verbeet: >> On 30/01/07, Francois Gouget <fgouget(a)codeweavers.com> wrote: >>> I have attached the relevant patches. Does this look ok to the DirectX >>> gurus? >> At least the wined3d part looks ok to me, although we should probably >> be cleaning up the GL context as well, there and in the other places >> where we return. > For some reason I didn't get the original patch, or I accidentally deleted > it(more likely). Yo can find it there: http://www.winehq.org/pipermail/wine-devel/2007-January/053725.html [...] > I do not know to what extend we want to catch screen res change failures. The > resolution? I'd say yes. Color depth? Propably no because we can't change it > anyway. Refresh rate? Don't think its important. There's already some code dealing with color depth issues: devmode.dmBitsPerPel = (bpp >= 24) ? 32 : bpp; /* Stupid XVidMode cannot change bpp */ But there's another place where we deal with these issues differently: if(devmode.dmBitsPerPel == 24) devmode.dmBitsPerPel = 32; [...] ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL, CDS_FULLSCREEN, NULL); if (ret != DISP_CHANGE_SUCCESSFUL) { if(devmode.dmDisplayFrequency != 0) { WARN("ChangeDisplaySettingsExW failed, trying without the refresh rate\n"); devmode.dmFields &= ~DM_DISPLAYFREQUENCY; devmode.dmDisplayFrequency = 0; ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL, CDS_FULLSCREEN, NULL) != DISP_CHANGE_SUCCESSFUL; } if(ret != DISP_CHANGE_SUCCESSFUL) { return DDERR_INVALIDMODE; } } -- Francois Gouget fgouget(a)codeweavers.com

Feb. 4, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Detlef Riekenberg

On Sa, 2007-02-03 at 13:00 -0800, Scott Ritchie wrote: > > The Sidenet - Script is still there. > > > I removed all traces of it from the wine wiki page I set up here, which > the download-deb page should link to now: > http://wiki.winehq.org/UbuntuAMD64 > I agree with you and Vitaly about this, by the way. Great. It's still there, but it's intresting, how fast it went away: https://help.ubuntu.com/community/WineForAMD64 > > Another Tip: > > "Next get the libxxf86dga1 package" > > > > Why that? > > DGA was dropped in July 2006: > The main problem is that I don't have a 64-bit machine and haven't > tested the instructions myself, I have also no 64-Bit machine here. > if Wine was compiled with DGA support (as the 32 bit package was) That is not possible since Aug. 2006. The Part of the Patch "Kill DGA support", that removed "-lXxf86dga": http://source.winehq.org/git/wine.git/?a=commitdiff;h=98179f06565b7f681d3cd… > But if it can be eliminated entirely that's really good news. You can remove the libXxf86dga-dev package and build wine again: The same "winex11.dev.so" is build. -- By by ... Detlef

Feb. 4, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Hans Leidekker

On Sunday 04 February 2007 06:58:58 Dmitry Timoshkov wrote: > To make sure that Wine headers are free of alignment bugs we have > dlls/*/tests/generated.c auto generated by tools/winapi. We just need > to add msvcrt types to tests.dat. Sure, that will help fixing Wine alignment bugs. But an MSVC source that makes assumptions about the alignment of __int64, when recompiled as a Winelib app with GCC could still prove to be very hard to debug. So it's important to find a way to make all 64 bit types align on 8 byte boundaries, like MinGW does as well. We have to do it selectively of course, because Unix libraries have different assumptions about the alignment of 64 bit types. -Hans

Feb. 4, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Dmitry Timoshkov

"Hans Leidekker" <hans(a)it.vu.nl> wrote: >> Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to >> align the Size field help? > > That should fix this particular struct but __int64 is used elsewhere > inside and outside of Wine, so maybe the typedef for __int64 itself > should get the alignment attribute? To make sure that Wine headers are free of alignment bugs we have dlls/*/tests/generated.c auto generated by tools/winapi. We just need to add msvcrt types to tests.dat. It looks like a lot of the CRT headers in PSDK (including sys/stat.h) set alignment manually to 8, for example direct.h has the following comment: #ifdef _MSC_VER /* * Currently, all MS C compilers for Win32 platforms default to 8 byte * alignment. */ #pragma pack(push,8) #endif /* _MSC_VER */ -- Dmitry.

Feb. 4, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Francois Gouget

On Sat, 3 Feb 2007, Damjan Jovanovic wrote: [...] > * Added padding so that struct _stati64's st_size has an offset of 24 > bytes from the beginning of the struct like it should. Does the st_size field get the right offset when using Wine's header with the Windows compiler? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Feb. 3, 2007

Bug 4791 - Civ4 crashes because of recent explorer/systray changes

by Fabian Bieler

Hello! I tried to look into Bug 4791 (Civ4 crashes because of recent explorer/systray changes http://bugs.winehq.org/show_bug.cgi?id=4791 ). Pretty early during initialization (before the application creates any windows itsself) a WM_FONTCHANGE message is broadcasted. The only window to which the message gets actually send is the Wine Systray Listener window. The message is immediately pulled by peek_message as a MSG_NOTIFY message. A few seconds later the WM_FONTCHANGE message is pulled from the queue of the Wine Systray Listener window again, this time of the type MSG_CALLBACK. the callback function pointer is a nullpointer resulting in a pagefault. If the Wine Desktop window is set as its own parent (like described in the bugzilla thread), the WM_FONTCHANGE message does not get send to the window and the program starts up fine. Now, I do not really understand the wine messaging system (particularly the difference between notify and callback messages) so I thought maybe somebody here could help me with that or point me to some introduction other than http://winehq.org/site/docs/winedev-guide/c3762#AEN3825 and message.c. Should the fontchange-message really be send to the Wine Systray Listener window? All test were run using wine-0.9.30, civ4 v1.61 with nocd-patch and native msxml3. Fabian

Feb. 3, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Hans Leidekker

On Saturday 03 February 2007 18:25:05 Hans Leidekker wrote: > inside and outside of Wine, so maybe the typedef for __int64 itself > should get the alignment attribute? To answer my own question: __int64 is not a typedef when compiling with GCC, but a preprocessor define. This way it is possible to use signed/unsigned modifiers as you can on MSVC because it's a builtin type there. We can't add an alignment attribute to the preprocessor define because that will result in compiler errors when the type is used in function declarations. So it seems like we're stuck with fixing individual structs in Wine. Winelib apps will still be affected though. -Hans

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Detlef Riekenberg

On Sa, 2007-02-03 at 01:33 -0800, Scott Ritchie wrote: > I'll change the link to a page on our wiki with the same info and > resend. Please remove the tips for libxxf86dga from http://wiki.winehq.org/UbuntuAMD64 winex11.drv dropped DGA Support at the end of July 2006 Thanks -- By by ... Detlef

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Scott Ritchie

On Sat, 2007-02-03 at 21:52 +0100, Detlef Riekenberg wrote: > On Sa, 2007-02-03 at 01:33 -0800, Scott Ritchie wrote: > > > > > > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > > > > https://help.ubuntu.com/community/WineForAMD64 > > > > > > > > The provided automatic installation script includes the sidenet-script. > > > > Please include a BIG WARNING, that this is never supported by winehq > > > > and the users need a clean wine, before they ask for help on #winehq > > > > or wine-users(a)winehq.org > > > > I just fixed it to make it better. I have half a mind to delete all > > mention of sidenet from the page entirely. > > The Sidenet - Script is still there. > I removed all traces of it from the wine wiki page I set up here, which the download-deb page should link to now: http://wiki.winehq.org/UbuntuAMD64 I agree with you and Vitaly about this, by the way. > > Another Tip: > "Next get the libxxf86dga1 package" > > Why that? > DGA was dropped in July 2006: > http://source.winehq.org/git/wine.git/?a=commitdiff;h=98179f06565b7f681d3cd… > > The main problem is that I don't have a 64-bit machine and haven't tested the instructions myself, but as I understand it if Wine was compiled with DGA support (as the 32 bit package was) then it would go nuts if it expected to find the lib and didn't, which the DGA hack was a workaround for. But if it can be eliminated entirely that's really good news. Thanks, Scott Ritchie

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Detlef Riekenberg

On Sa, 2007-02-03 at 01:33 -0800, Scott Ritchie wrote: > > > > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > > > https://help.ubuntu.com/community/WineForAMD64 > > > > > > The provided automatic installation script includes the sidenet-script. > > > Please include a BIG WARNING, that this is never supported by winehq > > > and the users need a clean wine, before they ask for help on #winehq > > > or wine-users(a)winehq.org > I just fixed it to make it better. I have half a mind to delete all > mention of sidenet from the page entirely. The Sidenet - Script is still there. Another Tip: "Next get the libxxf86dga1 package" Why that? DGA was dropped in July 2006: http://source.winehq.org/git/wine.git/?a=commitdiff;h=98179f06565b7f681d3cd… IMHO, the only useful things, a wine download script can do is: - download and install wine - optional download and install the gecko-engine - add the "IE 6.0"-Version to the Registry - optional download and install mono - add the ".Net"-Version to the Registry (The above mono provides ".Net 1.1") - optional download and install the corefonts suggest a BUG-Report, when the buildin Fonts are not correct Enable download and installation for native DCOM / native MSI only as a test, when the buildin versions do not work and an active wine BUG-ID is provided. Thanks -- By by ... Detlef

Feb. 3, 2007

Re: Getting Fallout 2 to work well

by Stefan Dösinger

Am Samstag 03 Februar 2007 12:20 schrieb Mirek: > Sorry, my mistake :) How can I download wine from your tree? Yes, your > latest patches from 26.1.2007 fixed this regression, great work! "In my tree" == Those patches :-) > Mirek > > Stefan Dösinger napsal(a): > > Am Freitag 02 Februar 2007 17:15 schrieb Mirek: > >> Getting Fallout 2 to work well > >> Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan > >> patches from 26.1.2007 > > > > Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a > > Direct3D9 game afaik. > > > > Did you do a regression test to localize the Flatout 2 performance > > regression? I suspect my StretchRect patch, and I have a fix for it in my > > tree.

Feb. 3, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Hans Leidekker

On Saturday 03 February 2007 16:15:11 Dmitry Timoshkov wrote: > Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to > align the Size field help? That should fix this particular struct but __int64 is used elsewhere inside and outside of Wine, so maybe the typedef for __int64 itself should get the alignment attribute? -Hans

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Vitaliy Margolen

Scott Ritchie wrote: > On Sat, 2007-02-03 at 00:06 -0700, Vitaliy Margolen wrote: >> Detlef Riekenberg wrote: >>> On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: >>>> + >>>> +While there is currently no Wine package explicitly designed for >>>> the 64-bit version >>>> +of Ubuntu, there are several hacks that can be used to install the >>>> 32-bit package >>>> +into the 64-bit distribution and have it function normally. See >>>> +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the >>>> Ubuntu wiki</a> >>>> +for more details. >>> IMHO, a link to our own Wiki should be placed on the download-deb page >>> >>> http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… >>> >>> >>> And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and >>> https://help.ubuntu.com/community/WineForAMD64 >>> >>> The provided automatic installation script includes the sidenet-script. >>> Please include a BIG WARNING, that this is never supported by winehq >>> and the users need a clean wine, before they ask for help on #winehq >>> or wine-users(a)winehq.org >>> >>> >>> You mention sidenet on that page: >>> "If you followed the manual instructions you need to install the Sidenet >>> script" >>> This is wrong. Please remove that line! >>> >>> Even, when the sidenet-script might help some users to run an app, >>> "you need to install the Sidenet script" is wrong! >> I still see that information listed on the mentioned page. I was hopping >> we could get some useful information for Ubuntu-64 users. >> I guess not. I will discourage anyone from referring to the above >> mentioned page because it has sedenet script as a "requirement". It's >> the same stuff as winetools and _brakes_ default Wine configuration. >> >> >> Vitaliy > > I just fixed it to make it better. I have half a mind to delete all > mention of sidenet from the page entirely. Can you explain why is it needed? This is the same _exact_ stuff as winetools! I failed to find a single piece of it that is useful for every day user. However almost every single thing it does, will compromise Wine's integrity. Vitaliy.

Feb. 3, 2007

Re: [msvcrt] properly align struct _stati64's st_size

by Dmitry Timoshkov

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > In wine's struct _stati64, st_size has an offset of 20 bytes from the > beginning of the struct, unlike mingw's and Window's 24. This breaks > Java 1.4.x pretty badly, it dies on startup complaining about a > truncated class file (#2953). Using #include <pshpack8.h> and #include > <pshpop8.h> around the struct didn't help, so a padding field was used > instead. Does the approach used in winbase.h in declaration of WIN32_STREAM_ID to align the Size field help? #include <pshpack8.h> typedef struct _WIN32_STREAM_ID { DWORD dwStreamId; DWORD dwStreamAttributes; LARGE_INTEGER DECLSPEC_ALIGN(8) Size; DWORD dwStreamNameSize; WCHAR cStreamName[ANYSIZE_ARRAY]; } WIN32_STREAM_ID, *LPWIN32_STREAM_ID; #include <poppack.h> > +static void test_stat( void ) > +{ > + int offset = offsetof(struct _stati64, st_size); > + ok(offset == 24, "struct _stati64's st_size is misaligned, got %d, expected 24\n", offset); > +} This should be a part of auto generated header tests. Have a look at dlls/*/tests/generated.c files. -- Dmitry.

Feb. 3, 2007

Re: Getting Fallout 2 to work well

by Mirek

Sorry, my mistake :) How can I download wine from your tree? Yes, your latest patches from 26.1.2007 fixed this regression, great work! Mirek Stefan Dösinger napsal(a): > Am Freitag 02 Februar 2007 17:15 schrieb Mirek: >> Getting Fallout 2 to work well >> Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan >> patches from 26.1.2007 > > Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a Direct3D9 > game afaik. > > Did you do a regression test to localize the Flatout 2 performance regression? > I suspect my StretchRect patch, and I have a fix for it in my tree.

Feb. 3, 2007

Re: Getting Fallout 2 to work well

by Stefan Dösinger

Am Freitag 02 Februar 2007 17:15 schrieb Mirek: > Getting Fallout 2 to work well > Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan > patches from 26.1.2007 Not the same game. Fallout 2 is an old ddraw game, Flatout 2 is a Direct3D9 game afaik. Did you do a regression test to localize the Flatout 2 performance regression? I suspect my StretchRect patch, and I have a fix for it in my tree.

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Scott Ritchie

On Sat, 2007-02-03 at 00:06 -0700, Vitaliy Margolen wrote: > Detlef Riekenberg wrote: > > On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: > >> + > >> +While there is currently no Wine package explicitly designed for > >> the 64-bit version > >> +of Ubuntu, there are several hacks that can be used to install the > >> 32-bit package > >> +into the 64-bit distribution and have it function normally. See > >> +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the > >> Ubuntu wiki</a> > >> +for more details. > > > > IMHO, a link to our own Wiki should be placed on the download-deb page > > > > http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… > > > > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > > https://help.ubuntu.com/community/WineForAMD64 > > > > The provided automatic installation script includes the sidenet-script. > > Please include a BIG WARNING, that this is never supported by winehq > > and the users need a clean wine, before they ask for help on #winehq > > or wine-users(a)winehq.org > > > > > > You mention sidenet on that page: > > "If you followed the manual instructions you need to install the Sidenet > > script" > > This is wrong. Please remove that line! > > > > Even, when the sidenet-script might help some users to run an app, > > "you need to install the Sidenet script" is wrong! > > I still see that information listed on the mentioned page. I was hopping > we could get some useful information for Ubuntu-64 users. > I guess not. I will discourage anyone from referring to the above > mentioned page because it has sedenet script as a "requirement". It's > the same stuff as winetools and _brakes_ default Wine configuration. > > > Vitaliy I just fixed it to make it better. I have half a mind to delete all mention of sidenet from the page entirely. I'll change the link to a page on our wiki with the same info and resend. Thanks, Scott Ritchie

Feb. 3, 2007

Re: [lostwages] Update download-deb page with better information, error fixes

by Vitaliy Margolen

Detlef Riekenberg wrote: > On Di, 2007-01-30 at 01:09 -0800, Scott Ritchie wrote: >> + >> +While there is currently no Wine package explicitly designed for >> the 64-bit version >> +of Ubuntu, there are several hacks that can be used to install the >> 32-bit package >> +into the 64-bit distribution and have it function normally. See >> +<a href="https://wiki.ubuntu.com/I386WineInAmd64">this page on the >> Ubuntu wiki</a> >> +for more details. > > IMHO, a link to our own Wiki should be placed on the download-deb page > > http://wiki.winehq.org/WineOn64bit#head-56206e8bc74083807ffe06ccb471d3f964c… > > > And as a Note on https://wiki.ubuntu.com/I386WineInAmd64 and > https://help.ubuntu.com/community/WineForAMD64 > > The provided automatic installation script includes the sidenet-script. > Please include a BIG WARNING, that this is never supported by winehq > and the users need a clean wine, before they ask for help on #winehq > or wine-users(a)winehq.org > > > You mention sidenet on that page: > "If you followed the manual instructions you need to install the Sidenet > script" > This is wrong. Please remove that line! > > Even, when the sidenet-script might help some users to run an app, > "you need to install the Sidenet script" is wrong! I still see that information listed on the mentioned page. I was hopping we could get some useful information for Ubuntu-64 users. I guess not. I will discourage anyone from referring to the above mentioned page because it has sedenet script as a "requirement". It's the same stuff as winetools and _brakes_ default Wine configuration. Vitaliy

Feb. 3, 2007

Re: winetest: add support for http_proxy environment variable

by Detlef Riekenberg

On So, 2007-01-14 at 15:13 +0100, Németh Márton wrote: Welcome to wine. I have some comments about your Patch: > diff -u -r wine-0.9.29.orig/ChangeLog wine-0.9.29/ChangeLog > --- wine-0.9.29.orig/ChangeLog 2007-01-09 16:42:47.000000000 +0100 > +++ wine-0.9.29/ChangeLog 2007-01-14 15:02:31.000000000 +0100 The changelog will be updated during a release with the Informations from the subject. > + > + http_proxy = getenv("http_proxy"); > + if (http_proxy) { > + /* Proxy configuration found */ > + memset(&regex, 0, sizeof(regex)); > + retval = regcomp(&regex, The Idea to support a http-proxy is good, but the Programm must run on Windows. 1. I never saw an environment-variable "http_proxy" on Windows. Most Windows-Applications use the Proxy-Data from IE (Get the settings from there) 2. "regcomp" and friends are posix, but not available on windows Thanks for helping wine. -- By by ... Detlef

Feb. 2, 2007

Re: [PATCH] ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps.

by John Morris

On 2/2/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > John Morris wrote: > > I'm resubmitting the patch without the changelog entry. > > > > > > ------------------------------------------------------------------------ > > > > From 4c51e49d432eb8342cadb71a3d539b2e8574849b Mon Sep 17 00:00:00 2001 > > From: John Morris <mailjohnmorris(a)gmail.com> > > Date: Fri, 2 Feb 2007 13:20:34 -0600 > > Subject: ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. > > > > --- > > dlls/ole32/ole32.spec | 1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > > index d775556..3ae0240 100644 > > --- a/dlls/ole32/ole32.spec > > +++ b/dlls/ole32/ole32.spec > > @@ -76,6 +76,7 @@ > > @ stub CoUnloadingWOW > > @ stdcall CoUnmarshalHresult(ptr ptr) > > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > @ stdcall CreateAntiMoniker(ptr) > > @ stdcall CreateBindCtx(long ptr) > > @ stdcall CreateClassMoniker(ptr ptr) > > > > > > ------------------------------------------------------------------------ > > > > > Hi, > > I thought we use: > > @ stub CoWaitForMultipleHandles > > for functions that should be exported and are not implemented at all, and use > > @ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > where we at least have something in a *.c file (although that could be a simple > return): > > HRESULT WINAPI CoWaitForMultipleHandles(<stuff>) { > FIXME("unimplemented stub!\n"); > return E_FAIL; <or something alike> > } > > Isn't the first one a stub and the second one a semi-stub, or have I mixed up > things? > > Cheers, > > Paul. > > > It appears to be implemented in dlls/ole32/compobj.c

Feb. 2, 2007

Re: [PATCH] ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps.

by Paul Vriens

John Morris wrote: > I'm resubmitting the patch without the changelog entry. > > > ------------------------------------------------------------------------ > > From 4c51e49d432eb8342cadb71a3d539b2e8574849b Mon Sep 17 00:00:00 2001 > From: John Morris <mailjohnmorris(a)gmail.com> > Date: Fri, 2 Feb 2007 13:20:34 -0600 > Subject: ole32: Add CoWaitForMultipleHandles to spec file do it will be visible to windows apps. > > --- > dlls/ole32/ole32.spec | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > index d775556..3ae0240 100644 > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -76,6 +76,7 @@ > @ stub CoUnloadingWOW > @ stdcall CoUnmarshalHresult(ptr ptr) > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > @ stdcall CreateAntiMoniker(ptr) > @ stdcall CreateBindCtx(long ptr) > @ stdcall CreateClassMoniker(ptr ptr) > > > ------------------------------------------------------------------------ > > Hi, I thought we use: @ stub CoWaitForMultipleHandles for functions that should be exported and are not implemented at all, and use @ stdcall CoWaitForMultipleHandles(long long long ptr ptr) where we at least have something in a *.c file (although that could be a simple return): HRESULT WINAPI CoWaitForMultipleHandles(<stuff>) { FIXME("unimplemented stub!\n"); return E_FAIL; <or something alike> } Isn't the first one a stub and the second one a semi-stub, or have I mixed up things? Cheers, Paul.

Feb. 2, 2007

Re: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to W indows apps.

by John Morris

Sorry, I misunderstood the sending patches guideline on the winehq page. It sounds like it is instructing me to include a changelog entry. I'll resubmit it. Thanks, John On 2/1/07, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Hello John, > > thanks for the patch. > You do not need to add the entry to the ChangeLog file. That is done > automaticly using the git changelog entries during the release of a new > Wine version. Would you mind resubmitting the patch without that? > > bye > michael > > John Morris wrote: > > From 79b3a4ba86ec3ddbd4b8be7c04bb350d78c78bfa Mon Sep 17 00:00:00 2001 > > From: John Morris <mailjohnmorris(a)gmail.com> > > Date: Wed, 31 Jan 2007 17:38:04 -0600 > > Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to Windows apps. > > > > --- > > ChangeLog | 5 +++++ > > dlls/ole32/ole32.spec | 1 + > > 2 files changed, 6 insertions(+), 0 deletions(-) > > > > diff --git a/ChangeLog b/ChangeLog > > index 658036c..ce545d0 100644 > > --- a/ChangeLog > > +++ b/ChangeLog > > @@ -1,3 +1,8 @@ > > +2007-01-31 John Morris <mailjohnmorris(a)gmail.com> > > + > > + * dlls/ole32/ole32.spec: > > + ole32: Add CoWaitForMultipleHandles to spec file so it will be visible to windows apps. > > + > > 2007-01-24 Vitaliy Margolen <wine-patches(a)kievinfo.com> > > > > * server/token.c: > > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > > index d775556..3ae0240 100644 > > --- a/dlls/ole32/ole32.spec > > +++ b/dlls/ole32/ole32.spec > > @@ -76,6 +76,7 @@ > > @ stub CoUnloadingWOW > > @ stdcall CoUnmarshalHresult(ptr ptr) > > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > > @ stdcall CreateAntiMoniker(ptr) > > @ stdcall CreateBindCtx(long ptr) > > @ stdcall CreateClassMoniker(ptr ptr) > > > > > > ------------------------------------------------------------------------ > > > > > > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart >

Feb. 2, 2007

Re: comdlg32-colordlg fix bgcolor

by Dmitry Timoshkov

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > This line obviously sets color (considering the current scheme), it transfers > as a background current system color of the scheme for display of a > background of elements of management. Has checked up, at change of color > schemes - dialogue is displayed correctly. My concern is why do you change GCLP_HBRBACKGROUND (a system setting) at all? Should the painting code be changed instead to use explicit background color in CC_PaintTriangle? -- Dmitry.

Feb. 2, 2007

Re: Getting Fallout 2 to work well

by Mirek

Hi, for me Flatout 2 works perfect with latest CVS wine and some Stefan patches from 26.1.2007 I have GF6800GS, GLSL enabled, FBO enabled, thread patch (for better sound), ALSA, Pixel and vertex shaders enabled too. There was big performance regression in latest wine release (0.9.30). Mirek Joonas Koivunen napsal(a): > Hello everyone! > > Recently I tried fallout2 again, and for some reason it has again > started working with wine. I searched the archives and it seems there > have been lots of times when it has worked and then again hasn't.. Glad > to see I'm not the only one interested in it :) > > From what I gathered from old postings, there had mainly been issues > with mouse input, from which I at least don't suffer. Nor are there any > more reports (appdb at least) of it not working with the latest 0.9.30 . > > The problem I have is that fallout2.exe takes all the available CPU > power, optimizing that might make other old games work better too. I'm > interested in the task, though I haven't got much of an idea how GDI or > DirectDraw api's work and I'd need some pointers where to start solving > this problem. > > Game taking all of available CPU doesn't make it unplayable. It just > makes mouse movement jerky and overall feeling is that my computer (amd > athlon xp 1800+) is too slow :) AFAIK minimum requirements for this game > were something like P90 with 16MB ram :) > > Some "features" like fading to black and white (going to menu for > example) are simply missing (these were in use a while ago, with older > wine). The rendering of animations slows down (in the combat mode) if > the animation happens to be under the animated cursor. > > I have tried Thunderbirds (from #winehq @ freenode.net > <http://freenode.net>) patch, which when rendering with opengl uses > pixel shaders to do 8bit->32bit conversion. It resulted in a bit more > sluggish (compared to GDI) game play experience. > > Profiling with oprofile (GDI session) shows that most of the time is > used in the game (I suppose it's the "anon" from wine-preload), next > most time consuming is winex11 drivers X11DRV_DIB_SetImageBits which > seems to be doing the conversion. > > I have included a bit cleaned version of opreport -l, only the first 40 > lines. Any help would be appreciated. > > -- > -- Joonas Koivunen > > > ------------------------------------------------------------------------ > >

Feb. 2, 2007

Re: Getting Fallout 2 to work well

by Felix Nawothnig

Joonas Koivunen wrote: > The problem I have is that fallout2.exe takes all the available CPU > power, optimizing that might make other old games work better too. I'm > interested in the task, though I haven't got much of an idea how GDI or > DirectDraw api's work and I'd need some pointers where to start solving > this problem. See http://bugs.winehq.org/show_bug.cgi?id=5526 (at least that's what causing performance issues for Fallout 1 but IIRC they use the same engine) Felix

Feb. 2, 2007

Re: Getting Fallout 2 to work well

by Stefan Dösinger

Am Freitag 02 Februar 2007 08:34 schrieb Joonas Koivunen: > Profiling with oprofile (GDI session) shows that most of the time is used > in the game (I suppose it's the "anon" from wine-preload), next most time > consuming is winex11 drivers X11DRV_DIB_SetImageBits which seems to be > doing the conversion. It seems that you have a game that has problems with the gdi engine(or lack thereof): http://wiki.winehq.org/DIBEngine http://bugs.winehq.org/show_bug.cgi?id=421

Feb. 2, 2007

Re: Conformance test for bug #7286

by Dmitry Timoshkov

"Koshelev, Misha Vladislavo" <mk144210(a)bcm.tmc.edu> wrote: > I copied and pasted that code straight from the StartNotificationThread function in the same > file (well, minus the fact that I am waiting for two events, which is how the refcount problem > is brought about), that is dlls/kernel32/tests/change.c. I will change it in my patch, Thanks. > do I also > need to change it in the existing StartNotificationThread function? If you do please send that fix as a separate patch. -- Dmitry.

Feb. 2, 2007

Getting Fallout 2 to work well

by Joonas Koivunen

Hello everyone! Recently I tried fallout2 again, and for some reason it has again started working with wine. I searched the archives and it seems there have been lots of times when it has worked and then again hasn't.. Glad to see I'm not the only one interested in it :) >From what I gathered from old postings, there had mainly been issues with mouse input, from which I at least don't suffer. Nor are there any more reports (appdb at least) of it not working with the latest 0.9.30. The problem I have is that fallout2.exe takes all the available CPU power, optimizing that might make other old games work better too. I'm interested in the task, though I haven't got much of an idea how GDI or DirectDraw api's work and I'd need some pointers where to start solving this problem. Game taking all of available CPU doesn't make it unplayable. It just makes mouse movement jerky and overall feeling is that my computer (amd athlon xp 1800+) is too slow :) AFAIK minimum requirements for this game were something like P90 with 16MB ram :) Some "features" like fading to black and white (going to menu for example) are simply missing (these were in use a while ago, with older wine). The rendering of animations slows down (in the combat mode) if the animation happens to be under the animated cursor. I have tried Thunderbirds (from #winehq @ freenode.net) patch, which when rendering with opengl uses pixel shaders to do 8bit->32bit conversion. It resulted in a bit more sluggish (compared to GDI) game play experience. Profiling with oprofile (GDI session) shows that most of the time is used in the game (I suppose it's the "anon" from wine-preload), next most time consuming is winex11 drivers X11DRV_DIB_SetImageBits which seems to be doing the conversion. I have included a bit cleaned version of opreport -l, only the first 40 lines. Any help would be appreciated. -- -- Joonas Koivunen

Feb. 2, 2007

Re: Conformance test for bug #7286

by Misha Koshelev

Sending new patch to wine-patches now. Also, the important thing I think about this conformance test (although the checks of course are important too) is that on the current git version this conformance test will completely kill wineserver (which my other patch for this bug fixes). Misha On Fri, 2007-02-02 at 13:15 +0800, Dmitry Timoshkov wrote: > "Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > > > + /* Now create the notification thread */ > > + events[1] = CreateThread(NULL, 0, NotificationThread, (LPVOID)events[0], > > + 0, &threadId); > > + ok(events[1] != INVALID_HANDLE_VALUE, "CreateThread error: %d\n", GetLastError()); > > CreateThread returns NULL on error, not INVALID_HANDLE_VALUE. >

Feb. 2, 2007

RE: Conformance test for bug #7286

by Koshelev, Misha Vladislavo

I copied and pasted that code straight from the StartNotificationThread function in the same file (well, minus the fact that I am waiting for two events, which is how the refcount problem is brought about), that is dlls/kernel32/tests/change.c. I will change it in my patch, do I also need to change it in the existing StartNotificationThread function? Misha -----Original Message----- From: Dmitry Timoshkov [mailto:dmitry(a)codeweavers.com] Sent: Thu 2/1/2007 11:15 PM To: Koshelev, Misha Vladislavo Cc: wine-devel(a)winehq.org Subject: Re: Conformance test for bug #7286 "Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > + /* Now create the notification thread */ > + events[1] = CreateThread(NULL, 0, NotificationThread, (LPVOID)events[0], > + 0, &threadId); > + ok(events[1] != INVALID_HANDLE_VALUE, "CreateThread error: %d\n", GetLastError()); CreateThread returns NULL on error, not INVALID_HANDLE_VALUE. -- Dmitry.

Feb. 2, 2007

Re: Conformance test for bug #7286

by Dmitry Timoshkov

"Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > + /* Now create the notification thread */ > + events[1] = CreateThread(NULL, 0, NotificationThread, (LPVOID)events[0], > + 0, &threadId); > + ok(events[1] != INVALID_HANDLE_VALUE, "CreateThread error: %d\n", GetLastError()); CreateThread returns NULL on error, not INVALID_HANDLE_VALUE. -- Dmitry.

Feb. 2, 2007

Re: [PATCH 3/7] server: Implement object's security descriptor check against token.

by Vitaliy Margolen

Robert Shearman wrote: > Vitaliy Margolen wrote: >> + res = token_access_check( token, obj->sd, *access, &priv, >> &priv_count, >> + &mapping, access, &status ) == >> STATUS_SUCCESS && >> + status == STATUS_SUCCESS; >> + if (!res) >> + { >> + fprintf( stderr, "access check failed\n" ); >> + set_error( STATUS_ACCESS_DENIED ); >> + } > > We don't want anything in the wineserver that can possibly spam the > console, so this should be made conditional on debug_level being non-zero. In case we will have any problems related to security checks this will be really helpful troubleshooting them. > Also, is there any reason you return STATUS_ACCESS_DENIED instead of the > statuses returned by token_access_check? Could you try writing a test > that creates or opens an object with ACCESS_SYSTEM_SECURITY access and > see if it returns STATUS_PRIVILEGE_NOT_HELD or STATUS_ACCESS_DENIED? > The two programs I'm fixing does not require this. Nor do we handle it properly anyway. Vitaliy.

Feb. 1, 2007

Re: [PATCH 1/7] server: Get the primary group from the token.

by Vitaliy Margolen

Robert Shearman wrote: > Vitaliy Margolen wrote: >> list_add_tail( &token->groups, &group->entry ); >> + /* Use first owner capable group as an owner */ >> + if (!token->primary_group && group->owner) >> + token->primary_group = &group->sid; >> + } >> + /* we really need a primary group */ >> + if (!token->primary_group && group_count) >> + { >> + release_object( token ); >> + return NULL; >> } >> > > According to documentation from Microsoft, "the primary group only needs > to be set if POSIX compatibility is required." Also, the default > security descriptor does not require a group - a NULL group is fine. > However access check against token will fail without group being set. So I don't see why can't we require valid group in the security descriptor? Vitaliy.

Feb. 1, 2007

Re: [PATCH] rasapi32: RasEnumConnections now returns correct buffer size (zero) when there are zero connections available

by James Hawkins

On 2/1/07, John Smith <xixsimplicityxix(a)gmail.com> wrote: > When RasEnumConnections completes the expected behaviour is to have the > needed buffer size stored in *lpcb. Right now wine just leaves it at > whatever size was passed. The windows 2000 behaviour (tested) for when > they're are zero connections, *lpcb is 0. > > Changelog: > RasEnumConnections the buffersize needed reported is now 0 when the number > of connections is 0 > You need to add a test to the test suite for this. -- James Hawkins

Feb. 1, 2007

Office 2003 Installation

by Jan de Mooij

Hi, I have tried to run the office 2003 installation, and in doing that I came across the following issues: - I think we need to undo a patch for msiexec [1]. CommandLineToArgvW does not what we want with slashes in paths followed by an " (this also happens on Windows). Therefore we need to parse the commandline arguments ourselves, what's done by reverting the patch. I can give an example of when it goes wrong if you want. - Office 2003 installation fails with this (from the log): ------------------------ Successfully launched MsiExec.... 2/1/2007 8:30:55 PM Chained install return code: 1603 Exit code was an error. Shutting down chained setup processing. Set Verbose logging for subsequent setup. ------------------------ BUT, when I add WINEDEBUG=+relay,+seh,+tid,+msi,+msiexec, it runs well and installs alright, so I think it's a timing issue. Anyone has experienced this before? What would be the best way to debug this? (I only choose to install Word, I don't know what happens when I select the other Office-applications) Thanks in advance, Jan de Mooij [1] http://source.winehq.org/git/wine.git/?a=blobdiff;f=programs/msiexec/msiexe…

Feb. 1, 2007

Re: Donation for your work on Direct 3D

by H. Verbeet

On 31/01/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Hi, > Thanks for the offer :-) I am employed by CodeWeavers, so its cw where you > should donate to. I think the best way of doing so is to just buy a copy of > CrossOver :-) > > Stefan > > > Hi Stefan and Henry, i would like to send you 35 EUR or 45 USD for your > > work on Direct 3D in wine, how can i do that? Can you send me your > > account number and prefered currency? > Send it to the Wine Party Fund, I'd say. Henri

Feb. 1, 2007

Re: Synchronize code page 20127 table with Windows one

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: > If you change a codepage from a unicode.org mapping then you need to add > the changed .TXT file you generated it from to the build tree and update > cpmap.pl to use it. That's not really possible due to a confusing license accompanying the unicode.org mappings, and a policy (until at least now) to not patch unicode.org provided data. Otherwise we have to patch the unicode collation table (I had a patch for it somewhere) as well as some other code page tables (problem with cp1251 table comes to mind as was reported recently). The patch I sent mostly was provided for the reference, since I think that Alexandre won't accept it. Just for the reference I'm attaching both the patched US-ASCII-QUOTES.TXT and a diff against original version US-ASCII-QUOTES.TXT.diff. -- Dmitry.

Feb. 1, 2007

Re: [PATCH 3/7] server: Implement object's security descriptor check against token.

by Robert Shearman

Vitaliy Margolen wrote: > + res = token_access_check( token, obj->sd, *access, &priv, &priv_count, > + &mapping, access, &status ) == STATUS_SUCCESS && > + status == STATUS_SUCCESS; > + if (!res) > + { > + fprintf( stderr, "access check failed\n" ); > + set_error( STATUS_ACCESS_DENIED ); > + } We don't want anything in the wineserver that can possibly spam the console, so this should be made conditional on debug_level being non-zero. Also, is there any reason you return STATUS_ACCESS_DENIED instead of the statuses returned by token_access_check? Could you try writing a test that creates or opens an object with ACCESS_SYSTEM_SECURITY access and see if it returns STATUS_PRIVILEGE_NOT_HELD or STATUS_ACCESS_DENIED? -- Rob Shearman

Feb. 1, 2007

Re: [PATCH 1/7] server: Get the primary group from the token.

by Robert Shearman

Vitaliy Margolen wrote: > list_add_tail( &token->groups, &group->entry ); > + /* Use first owner capable group as an owner */ > + if (!token->primary_group && group->owner) > + token->primary_group = &group->sid; > + } > + /* we really need a primary group */ > + if (!token->primary_group && group_count) > + { > + release_object( token ); > + return NULL; > } > According to documentation from Microsoft, "the primary group only needs to be set if POSIX compatibility is required." Also, the default security descriptor does not require a group - a NULL group is fine. -- Rob Shearman

Feb. 1, 2007

Re: Synchronize code page 20127 table with Windows one

by Robert Shearman

Dmitry Timoshkov wrote: > The problem is that our translation table for code page 20127 is different from > what Windows has, and the ansi_buf get mangled. Attached patch synchronizes our > code page 20127 table with Windows one and fixes the bug. If you change a codepage from a unicode.org mapping then you need to add the changed .TXT file you generated it from to the build tree and update cpmap.pl to use it. -- Rob Shearman

Feb. 1, 2007

Re: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to W indows apps.

by Michael Stefaniuc

Hello John, thanks for the patch. You do not need to add the entry to the ChangeLog file. That is done automaticly using the git changelog entries during the release of a new Wine version. Would you mind resubmitting the patch without that? bye michael John Morris wrote: > From 79b3a4ba86ec3ddbd4b8be7c04bb350d78c78bfa Mon Sep 17 00:00:00 2001 > From: John Morris <mailjohnmorris(a)gmail.com> > Date: Wed, 31 Jan 2007 17:38:04 -0600 > Subject: Added CoWaitForMultipleHandles to ole32.spec so it will be visible to Windows apps. > > --- > ChangeLog | 5 +++++ > dlls/ole32/ole32.spec | 1 + > 2 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index 658036c..ce545d0 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2007-01-31 John Morris <mailjohnmorris(a)gmail.com> > + > + * dlls/ole32/ole32.spec: > + ole32: Add CoWaitForMultipleHandles to spec file so it will be visible to windows apps. > + > 2007-01-24 Vitaliy Margolen <wine-patches(a)kievinfo.com> > > * server/token.c: > diff --git a/dlls/ole32/ole32.spec b/dlls/ole32/ole32.spec > index d775556..3ae0240 100644 > --- a/dlls/ole32/ole32.spec > +++ b/dlls/ole32/ole32.spec > @@ -76,6 +76,7 @@ > @ stub CoUnloadingWOW > @ stdcall CoUnmarshalHresult(ptr ptr) > @ stdcall CoUnmarshalInterface(ptr ptr ptr) > +@ stdcall CoWaitForMultipleHandles(long long long ptr ptr) > @ stdcall CreateAntiMoniker(ptr) > @ stdcall CreateBindCtx(long ptr) > @ stdcall CreateClassMoniker(ptr ptr) > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Feb. 1, 2007

Re: comdlg32-colordlg fix bgcolor

by Ivan Sinitsin

В сообщении от 1 февраля 2007 07:00 Dmitry Timoshkov написал(a): > "Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > > The patch corrects background color of a dialogue window " Choose color " > > at copying a triangular marker, the user colors and the predetermined > > colors. Earlier the background about these elements was more dark than > > the basic background of a window. > > > > + SetClassLongPtrW( hwnd, GCLP_HBRBACKGROUND, (LONG_PTR) > > GetSysColorBrush(COLOR_BTNFACE)); > > This fix is not correct, think for instance about different color themes. > Probably CC_PaintTriangle needs to specify the background color of a > triangle explicitly. This line obviously sets color (considering the current scheme), it transfers as a background current system color of the scheme for display of a background of elements of management. Has checked up, at change of color schemes - dialogue is displayed correctly.

Feb. 1, 2007

Re: comdlg32-colordlg fix bgcolor

by Dmitry Timoshkov

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > The patch corrects background color of a dialogue window " Choose color " at > copying a triangular marker, the user colors and the predetermined colors. > Earlier the background about these elements was more dark than the basic > background of a window. > + SetClassLongPtrW( hwnd, GCLP_HBRBACKGROUND, (LONG_PTR) GetSysColorBrush(COLOR_BTNFACE)); This fix is not correct, think for instance about different color themes. Probably CC_PaintTriangle needs to specify the background color of a triangle explicitly. -- Dmitry.

Feb. 1, 2007