Linuxtag 2007 in Berlin
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.html Projects should be registered until February 23. cu, Stefan pgprk62k608NR.pgp Description: PGP signature
Re: [PATCH] coverity: CID35: fixed wrong condition
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
Numeric keypad fix for WoW Warcraft Bug 6323
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=4730action=view and the bug is 6323. Regards Nick
Re: Daylight saving changes
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
DirectDrawRenderer=opengl - screen size changeable for final rendering?
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 pgpk1mmTmmclW.pgp Description: PGP signature
Re: Bug 4791 - Civ4 crashes because of recent explorer/systray changes
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
Presenting at LinuxTag?
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 )
RE: msi: InstallPackage check for UI level must not disregard flags (updated)
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:[EMAIL PROTECTED] Sent: Tue 2/6/2007 1:57 AM To: wine-devel@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 [EMAIL PROTECTED] wrote: On 2/5/07, Misha Koshelev [EMAIL PROTECTED] 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
Re: Linuxtag 2007 in Berlin
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.html Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpeoak3Pa4H6.pgp Description: PGP signature
Re: [PATCH] make CarbonPoker (previously Poker.com) client work.
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
Re: msi: InstallPackage check for UI level must not disregard flags (updated)
On 2/6/07, Koshelev, Misha Vladislavo [EMAIL PROTECTED] 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
Re: [PATCH] coverity: CID35: fixed wrong condition
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
Re: msi: InstallPackage check for UI level must not disregard flags (updated)
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?
Re: Window focus testing
Dmitry Timoshkov wrote: Duane Clark [EMAIL PROTECTED] 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.
Re: msi: InstallPackage check for UI level must not disregard flags (updated)
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
Re: msi: InstallPackage check for UI level must not disregard flags (updated)
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 0xfe1f. 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
Re: msi: InstallPackage check for UI level must not disregard flags (updated)
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 0xfe1f. 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
qemu-0.9.0 and kqemu-1.3.0pre10 (now GPL) released
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
Undoc. comctl32 mem management functions
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
Re: comctl32: tab: update the item mask after a TB_SETITEM (fixes bug #7345)
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
