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

RedHat rpms
by Bill Medland 08 Feb '07

08 Feb '07

Just checking I'm looking to see if there are rpms being built for Red Hate Enterprise Linux 3 these days. I see that the Red Hat rpms nowadays are for fc. but they aren't suitable for RHEL3 The download page says that the RedHat/Fedora area is for RedAht 8,9 and fedora, but I don't see any RedHat 8 or 9 there. Are they not there or am I looking in the wrong place? -- Bill Medland

2 1

Getting Fallout 2 to work well
by Joonas Koivunen 08 Feb '07

08 Feb '07

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

5 9

Re: [GDI32] Fix for GetTextExtentExPointW() and ExtTextOutW() - Fixes Bug 50
by John Smith 08 Feb '07

08 Feb '07

Hey Pedro, Was there supposed to be an attachment on your last message? I didn't see one. Regards, John Klehm On 2/8/07, Pedro Araujo Chaves Jr. <inckie(a)gmail.com> wrote: > > Attached is my proposed patch for Bug #50; the test case was attached > in my previous message. > -- > Patch description: > > This patch fixes Wine's Bug #50: "PrgWin95: Text justification needs > beefing up". > > What it does: first, it takes in consideration that not always the > number of extra pixels will be a multiple of the number of break > characters in a given extent of a given string that should be > justified, and so the integer division of extra by breaks in > SetTextJustification() is likely to leave a remainder (which the > latter function addresses, of course, but ExtTextOutW() seems to > overlook — that's the reason for the changes at lines 1788 (breakRem), > and 1901 and 1922 (dc->breakExtra || breakRem), which prevent some > lines from being ignored in the justification). > > That fixed, if there remained any pixels indeed, their number > shouldn't be greater than dc->breakCount; then the first breakRem > break characters in that given extent are widened by one pixel (lines > 1925-1929 added). > > GetTextExtentExPointW() is also fixed so that it now returns the > expected width of the text when it is to be justified. This has the > good side effect that TabbedTextOut() now also returns the proper > width when called after SetTextJustification(). What the patch does > here is that GetTextExtentExPointW() now calculates the extra width > only when (breakExtra || breakRem) resolves TRUE , and corrects the > extra space additions by applying them only to break characters. What > was broken before is that it always added extra space, regardless of > whether it was measuring a single character or a full string, or > whether it was a break character or not. (Lines added: 1191, 1199, > 1227, 1229, 1236-1245, 1254-1268). > > This patch is copyrighted by Banco do Brasil under the LGPL. > > -- > Regards, > Pedro Araújo. > > >

1 0

Re: advapi32: sign-compare fixes
by Vitaliy Margolen 08 Feb '07

08 Feb '07

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.

3 2

Re: [PATCH] coverity: CID35: fixed wrong condition
by Felix Nawothnig 08 Feb '07

08 Feb '07

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?

2 3

IE Dev Toolbar now compatible!
by Darryl Dixon 08 Feb '07

08 Feb '07

Hi All, Just a brief to let you know that it looks like Microsoft is finally taking compatability seriously ;) - the new Beta 3 version of the IE Developers Toolbar (http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511…) improves on the previous Beta release by installing and working correctly with wine 0.9.30 with an IE6 'ies4linux' install. In the previous Beta, the 'View DOM' button did not work in wine 0.9.30 - this new version fixes that and adds lots of enhancements. I don't know if this is useful to many here, but it sure is for me, so I thought I'd share. Nice to see Microsoft improving their software to work better with Wine for once (even though I'm sure it's unintentional ;). Keep up the good work, guys. regards, Darryl Dixon Winterhouse Consulting Ltd http://www.winterhouseconsulting.com

1 0

Re: ole32: Remove casts
by Robert Shearman 08 Feb '07

08 Feb '07

Mike McCormack wrote: > --- > This is the way ref counting is done everywhere else in Wine. > > Ref counts can be assumed to be between 0 and MAXLONG, so the fact > that LONG is signed isn't important. NO. The DCOM spec says that STDOBJREF::cPublicRefs is unsigned, therefore the ref counts can be assumed to be up to MAXULONG. Therefore, this change is incorrect and it would lead to subtle signedness errors. > > Casting ULONG* to LONG* to solve the above problem is unnecessary. > -- Rob Shearman

2 1

Re: msi: Make MsiInstallProduct conformance test depend on proper UI level processing.
by James Hawkins 08 Feb '07

08 Feb '07

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

2 10

Re: winedump: sign-compare fixes
by Dmitry Timoshkov 08 Feb '07

08 Feb '07

"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.

2 1

Undoc. comctl32 mem management functions
by Felix Nawothnig 07 Feb '07

07 Feb '07

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

3 2