- Wine-Devel - list.winehq.org

Re: RESEND: CreateDIBitmap: Don't create monochrome bitmaps
by Dmitry Timoshkov Sept. 7, 2004

Sept. 7, 2004

"Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > + /* Need to check if the bitmap is monochrome, and if the > + two colors are really black and white */ > + if (is_dib_monochrome(pbi)) > + { > + /* Top-down DIBs have a negative height */ > + DWORD height = pbi->bmiHeader.biHeight; > + if (height < 0) height = -height; [skipped] > + /* If it's possible, create a monochrome bitmap */ > + > + DWORD height = fix_info->bmiHeader.biHeight; > + if (height < 0) height = -height; In the code above 'DWORD height' should be changed to 'LONG height' otherwise the test 'height < 0' will always fail. -- Dmitry.

1 0

D3D7: textures, mipmaps, DDSCAPS_COMPLEX
by andrejoh＠c2i.net Sept. 6, 2004

Sept. 6, 2004

Hi! First some good news (for me at least): Cedega from CVS can now be used to play Anarchy Online! [1] To get this working, Marius Grigoriu had to implement support for DDSCAPS_COMPLEX in the Cedega code; this support seems to be lacking in Wine. I've had a look at the patch, and both the Cedega and Wine implementations -- they are quite similar, but do have some differences in the texture creation part. In particular, Cedega has a lot of additional code in create_texture, and the parts in Wine's version seems to reside in the function create_mipmaps in the Cedega file (dlls/ddraw/ddraw/main.c). As far as I've understood things, the Cedega DDraw code is under the AFPL license, and cannot be merged with the Wine LPGL code; thus I've not looked further into that (the changes seems to be related to cube map support). However, the patch from Marius is released under the X11 license, and can be applied to Wine with minor tweaking (due to support for compressed textures in the Wine code). Should this be applied to the Wine tree (depending on me having ported it correctly, of course)? For reference, I've included the related part from the original patch as well (see also [1]). Unfortunately, even with this patch, running AO under Wine crashes with some texture related code: First chance exception: divide by zero in 32-bit code (0x419c6d5c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033 EIP:419c6d5c ESP:4085e784 EBP:4085e7e4 EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:00000002 ECX:00000000 EDX:00000000 ESI:4085e958 EDI:00000002 Stack dump: 0x4085e784: 4085e984 4085e928 40530088 0000007c 0x4085e794: 0010180f 00000100 00000100 00000200 0x4085e7a4: 00000000 00000000 00000000 00000000 0x4085e7b4: 50bb0000 00000000 00000000 00000000 0x4085e7c4: 00000000 00000000 00000000 00000000 0x4085e7d4: 00000000 00000020 00000041 00000000 Backtrace: =>1 0x419c6d5c _D3DXLoadTextureFromSurface(a)28+0x3e9 in randy31d (0x4085e7e4) 2 0x00007c00 (0x00000010) 3 0x00000000 (0x00000000) 0x419c6d5c _D3DXLoadTextureFromSurface(a)28 in randy31d: divl 0x40(%ebp),%eax Wine-dbg>bt Backtrace: =>1 0x419c6d5c _D3DXLoadTextureFromSurface(a)28+0x3e9 in randy31d (0x4085e7e4) 2 0x00007c00 (0x00000010) 3 0x00000000 (0x00000000) Doing "bt all" crashes the debugger with this message after getting a listing of one thread: wineserver: debugger.c:477: debugger_detach: Assertion `event->sender->debug_event == event' failed. I've been unable to figure out what happens here, but I assume it might be caused by an invalid texture surface. Hacking in the AO code base (as in disabling certain textures), I've been able to get all the way into the client, but with almost no rendering. Any further help would be greatly appreciated! [1] http://www.csh.rit.edu/~marius/aolinux/ -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

1 0

Re: CreateDirectoryW improvement
by Uwe Bonnes Sept. 6, 2004

Sept. 6, 2004

>>>>> "Wolfgang" == Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: Wolfgang> Description: Return error ERROR_ALREADY_EXISTING if an Wolfgang> existing drive (e.g. 'C:') without '\\' is specified Wolfgang> ChangeLog: CreateDirectoryW: Return error Wolfgang> ERROR_ALREADY_EXISTING e.g. for path 'C:' Wolfgang> Index: dlls/kernel/path.c Wolfgang, having some test cases in our test suite for those problems is a good idea... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Don't crash on failing DRIVER_FindFromHDrvr
by Uwe Bonnes Sept. 6, 2004

Sept. 6, 2004

Hallo, I sent a patch to prevent wine from crashing last friday. It happend, when DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that patch before last year. Eric answered > this doesn't seem right to me: either the loading fails and we shouldn't > get a valid handle, or it succeeds and we should be able to find it > there's must be something wrong elsewhere > could you please send a -debugmsg +driver,+module,+winmm to see what > happens ? and like before, I can't reproduce the error after reverting the patch: > the error no longer exists. I guess some registry entry was corrupt and a > successfull run corrected it later. > > However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of > the code... If one dose "grep -3 DRIVER_FindFromHDrvr wine/dlls/winmm/*", every other usage of DRIVER_FindFromHDrvr is like if ((lpDrv = DRIVER_FindFromHDrvr(hDrvr)) != NULL) Why should expecting a NULL return be wrong? It happens, as the the crashes show. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 4

Re: Battlefield 1942 d3d8 crash
by Ann and Jason Edmeades Sept. 6, 2004

Sept. 6, 2004

Does changing the line 575 (in device.d, dlls/d3d8) to be if (ppBackBuffer) IDirect3DSurface8Impl_AddRef((LPDIRECT3DSURFACE8) *ppBackBuffer); make any difference - Looks like the app is doing an odd way to work out how many back buffers there are. Jason

2 2

dlls/msvcrt/time.c picks up wrong CLOCKS_PER_SEC define
by Uwe Bonnes Sept. 6, 2004

Sept. 6, 2004

Hallo, wine/include/msvcrt/time.h defines CLOCKS_PER_SEC conditionally: #ifndef CLOCKS_PER_SEC #define CLOCKS_PER_SEC 1000 #endif in wine/dlls/msvcrt/time.c, <time.h> is included and defines CLOCKS_PER_SEC unconditional before to 1000000l. So MSVCRT_clock returns a value 1000 times to high. How should this be fixed? Should wine/dlls/msvcrt/time.c do the define unconditional? Do we need to use a different define (e.g. MSVCRT_CLOCKS_PER_SEC) in MSVCRT_clock()? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: PROPSHEET: Fix wizard regression
by Filip Navara Sept. 6, 2004

Sept. 6, 2004

Filip Navara wrote: > This fixes the regression caused by the Mike McCormack's patch and > solves the problem with Macromedia Flash MX in the correct way. There > is still other problem with Macromedia Flash MX when you check the > options on the "Publish Settings" if anyone wants to jump in and solve > that... > > Changelog: > - Revert incorrect change to tab control resizing from revision 1.109. > - Move the property sheet resizing code from PROPSHEET_CreatePage to > PROPSHEET_SetCurSel. It needs to be executed on every page change > because the application can modify it during the notifications. Use the attached patch instead please. Regards, Filip

1 0

Re: Wine Developer Cheatsheet, v1
by Mike Hearn Sept. 6, 2004

Sept. 6, 2004

> That's is very interesting and useful, but I think there's two things that > can be improved: first the debug delay patch, I wasn't able to find it out > searching with gmane, maybe if you can add a link to the post on gmane it > should be better :) Yeah, it's a bit of a pain keeping track of useful patches that were never merged. Maybe we need a list somewhere. > The second thing is about the coding style. As I said before, I have a patch > for shlwapi which fixes some MSXML/Borland XML Components problems with the > builtin one, which wasn't accepted for some problem about the style and the > placement of the variables. I posted it as a bug at > http://bugs.winehq.org/show_bug.cgi?id=2385 . If you can add something > about the coding style I can fix it up and repost it for inclusion. A few things that jump out at me (not really reviewed the code itself): - No C++ // style comments, I'm afraid. They aren't portable enough. - Use HeapAlloc() over malloc(), as it says in the cheatsheet - Are you sure there is a debugstr_a?? I can't think what it would do, ANSI strings can just be printed by regular printf - You have to declare all the variables at the start of a block. Yes, it's a pain. Another C portability rule. So, can't do this: LPSTR foo = bar; StrCpyA(a, b); int i; They all have to go at the top. - Minor stylistic note: you can use strcpy rather than StrCpyA. But I doubt this was a problem. - Usually best to space stuff out, ie rather than this: if ( temp_out == temp_out2 ) { temp_in += 3; continue; } use this: if ( temp_out == temp_out2 ) { temp_in += 3; continue; } ... again I doubt Alexandre would reject the patch because of this. - //if ( *temp_in == '.' ) ... wine code generally doesn't do this. If you find it hard to match up a closing brace with the statement that opened it maybe you need ... *fanfare* EMACS! :) - Is it possible to implement the ANSI version by converting to unicode then calling the wide version, rather than duplicate it? The rest looks fine, I expect it was just the C portability stuff that tripped you up. Please do try again! thanks -mike

4 4

Re: RESEND: CreateDIBitmap: Don't create monochrome bitmaps
by Huw D M Davies Sept. 6, 2004

Sept. 6, 2004

Hmm, actually this requires more work, because although CreateDIBitmap is now correct, the patch is messing up the toolbar icons in IE... Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: DestroyMenu: Check if the menu is still used (fix for bug 1486)
by Dmitry Timoshkov Sept. 6, 2004

Sept. 6, 2004

"Michael Kaufmann" <hallo(a)michael-kaufmann.ch> wrote: > Some applications call DestroyMenu for menus that are still displayed in > a window. We need to check if a menu is still used and set the window's > menu handle to NULL if that's the case. > > This patch fixes the important bug 1486. > > Changelog: > - DestroyMenu: Check if the menu is still displayed and adjust the > window's menu handle There is a test case in Wine (dlls/user/tests/win.c,test_SetMenu) which shows that your patch is wrong. It was said many times already that the real fix for that bug is to move all user object management into wineserver and use the same handle allocation scheme as the one used for windows. -- Dmitry.

4 4