May 2005 - Wine-devel - list.winehq.org

Assertion fails in riched20; relay debug segfaults
by Adrian Harvey 09 May '05

09 May '05

The wine version of riched20 fails an assertion when starting StreamboxVCR $ wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33- b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke did not find member id fffffdfa, flags 4! err:ole:ITypeInfo_fnInvoke did not find member id fffffdfb, flags 4! fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed. fixme:ole:ITypeInfo_fnRelease destroy child objects Along with a popup dialogue box from the visual C++ runtime library indicating abnormal program termination. The file run.c appears to be part of riched20, and indeed overriding the load order to native only for that DLL allows the program work. All reasonably standard debugging so far, and I went for some more logging to aid tracing the problem (or to log in bugzilla when it all gets too hard for my skill level ;-) ) $ WINEDEBUG="+relay" wine .wine/drive_c/Program\ Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Segmentation fault Shortest relay trace I've ever had! But I'm not really sure where to go from here... Running GDB on it gives me no useful results. I have an AMD64 box running Fedora Core 3 and wine is the latest from CVS. I'm going to try some other tracing to look at the riched problem, but +relay crashing seems serious to me. Adrian

4 8

Quicken/CreateCompatibleBitmap issue revisited
by Carl Sopchak 09 May '05

09 May '05

In the bug found at http://bugs.winehq.org/show_bug.cgi?id=2096 , I have described an issue that I am having with Quicken Deluxe 2000 when running under Wine. The symptom is that Quicken was crashing HARD when trying to print a partial page of checks on a laser printer. Now, I just get fixme's stating that CreateCompatibleBitmap is getting bad parameters. (In lieu of reading the following, you could probably just read the last few posts in bugzilla for this bug...) Long story short, with the help of some others (thanks guys!), it seems that CreateCompatibleBitmap is being called directly from Quicken, and that Quicken seems to be passing an address instead of a value for the height parameter. Now, I would normally just mark the bug as INVALID, and let it go. But, while looking into things, I read the MSDN page describing the function of CreateCompatibleBitmap, and it appears to me that there may be "issues" with Wine's implementation of CreateCompatibleBitmap. To quote my post attached to the bug: "I would have changed this bug entry's resolution to INVALID, except that (a) I wouldn't mind a more knowledgeable (of Wine, Win API, and C) person to verify my findings, and, more importantly, (b) it seems to me that Windows would be handling this scenario differently than Wine (or Intuit/Quicken would have some customer relations problems due to frequent crashes) - should Wine do something different when the parameters are out of whack? The only thing I can see on MSDN under CreateCompatibleBitmap is "Windows 95/98/Me: The created bitmap cannot exceed 16MB in size." "Which I guess brings up another point... dlls/gdi/bitmap.c's CreateCompatibleBitmap shows the aforementioned fixme message if the width or height exceeds 0x10000, and no bitmap is returned. This seems wrong to me on three counts: (1) MSDN states that if either width or height is zero, a 1x1 monochrome bitmap is returned (in my case the height was 0, but the width was "huge", so a 1x1 bitmap should be returned); (2) a 0x11000 by 0x2 bitmap is within the (more restrictive Win95) 16 MB limit and should be valid; and (3) Win NT/2000/XP do not seem to have any restriction on a bitmap's size (except physical and paged memory constraints), so at least in theory, any values for width and height are "valid". So, this begs the question, should Wine's CreateCompatibleBitmap be modified for any (or all?) of the reasons above? Thoughts? Comments? Carl

3 3

Bugs out of my league
by Dustin Navea 08 May '05

08 May '05

Bug 2938: Seemed at first like this was due to the recent patch to get Mozilla/FF installers working, but after he reverted to the Feb release and the problem still existed, it must be something else.. Bug 2919: If I am reading the backtrace right, it looks like the installer is crashing in kernel32, but then again it does the same for the quicktime installer on the same cd, so could it be configuration related? Just need someone to take a look and comment here, and I'll take care of em, until I need a patch anyways lol. Dustin

1 0

Now hiring
by Dustin Navea 08 May '05

08 May '05

Jeremy, guys, it seems we have run low on "official" janitors, I have talked with someone that seems to know what they are doing as far as the right way to bug report (he contribs to MPlayer), and he said he would be willing to help maintain bugzilla, but that he doesn't have a whole lot of time, the extra hand will be helpful. Could you add 'canconfirm' and 'editbugs' to inverseparadox(a)comcast.net? Does anyone have any objection to me posting a note on wine-users that we are accepting applications for dedicated bug maintainers (read: janitors lol)? I will handle "interviewing and hiring", and just send an email to Jeremy when we get people that know what they are doing and can really be of use.. I think 5 should be good for now.. Dustin

2 2

LockDIBSection problem
by Rein Klazes 08 May '05

08 May '05

Hi, Here is another problem in BigJig a jigsaw puzzle game (free download at www.lenagames.com) The program calls BitBlt with destination an in memory DIB. Inside BitBlt, the destination bits are set to PAGE_NOACCESS: | 0009:Call kernel32.VirtualProtect(727f0000,00123324,00000001,77a5f7bc) ret=770032ba | 0009:Call ntdll.NtProtectVirtualMemory(ffffffff,77a5f69c,77a5f6a0,00000001,77a5f7bc) ret=77b6929e | trace:virtual:NtProtectVirtualMemory 0xffffffff 0x727f0000 00123324 00000001 | trace:virtual:VIRTUAL_SetProt 0x727f0000-0x72913fff c---- | View: 0x727f0000 - 0x72913fff (valloc) | 0x727f0000 - 0x72913fff c---- | 0009:Ret ntdll.NtProtectVirtualMemory() retval=00000000 ret=77b6929e This memory segment (727f0000,00123324) does not appear in the log anymore until it is written to disk: | 0009:Call kernel32.WriteFile(00000084,727f0000,00123324,77a5f360,00000000) ret=00408ac1 .. The call fails ( not in the log because I fixed it) with error STATUS_INVALID_USER_BUFFER and the program hangs. I managed to fixed it in two ways: 1. put a X11DRV_CoerceDIBSection( physDevDst, DIB_Status_InSync, FALSE ); at the end of X11DRV_BitBlt. This probably defeats the whole purpose of these protections so: 2. Add a "IsBadReadPtr( buffer, bytesToWrite)" in the top of WriteFile to force an exception and everything works. Would that be an acceptable fix? Rein.

2 2

Re: ignore requested height for non-menubar ownerdraw popups
by Rein Klazes 08 May '05

08 May '05

On Sun, 8 May 2005 13:30:30 +0200, you wrote: > On 05/08/2005 12:25:18 PM, Rein Klazes wrote: > > That does not seem correct on the Win2k system that I am using for > > testing. > > Right. Windows sets itemHeight before and not after WM_MEASUREITEM. > Sorry for that. > > And it also seems not to be GetSystemMetrics(SM_CYMENU)-1 but a rather > strange magic value of 16. (with my test it looked 100% the same ... > sigh. I'll go to bed soon. ;) > > How about this patch? Much better. About the magic number: I looked at the value on Win2k and WinME with different resolutions ( desktop->properties->settings, click on advanced tab and change what windows calls "font size" but is really changing the DPI, dots-per-inch, which is also reported). DPI Win2k WinME ================== 96 16 13 120 20 16 I assume that you are using a DPI of 96, and XP and 2k behave the same way. The DPI you can retrieve with GetDeviceCaps( hdc, LOGPIXELSY). I would recommend using the Win2k values computed by: DPI/6. Rein.

2 2

wineconsole exits immediately (Wine 20050310 debian sarge/testing)
by J. Grant 08 May '05

08 May '05

Hello, I was trying to run wcmd, it seems to have been renamed wineconsole. However, unfortunately it exits immediately before producing a DOS command prompt in my terminal like wcmd used to. I think this is a bug, (unless I missed something). $ wineconsole Invoking /usr/lib/wine/wine.bin wineconsole.exe ... Wine exited with a successful status $ I thought that maybe there was an argument I needed to pass, but there isn't a man page, or command line --help /? help unfortunately at present. $ wineconsole --help Invoking /usr/lib/wine/wine.bin wineconsole.exe --help ... err:wineconsole:WinMain Wrong command line options Wine exited with a successful status $ wineconsole /? Invoking /usr/lib/wine/wine.bin wineconsole.exe /? ... Wine exited with a successful status $ I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

3 7

Wine -> WineHQ -> codeweavers
by Derzu 08 May '05

08 May '05

Hi all, I saw at the www.winehq.org/ the banner (http://www.winehq.org/images/bannerads/cw-ad02.gif) that ponts to the www.codeweavers.com/ page. That banner has a little penguin opening a bottle of wine and after, the penguin appears very drunk, does any one knows who did that banner? I wanna the picture of the drunk penguin to set as mine wallpaper, but I wanna a big one. Any one can help me? Sorry if that mesage is not exatly a devel question. Thanks, Derzu ____________________________________________________Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br

2 1

Re: [DInput] Fix 'peek' code for mouse (S3 problem)
by Stefan Dösinger 08 May '05

08 May '05

Am Mittwoch, 4. Mai 2005 20:44 schrieb Lionel Ulmer: > This should fix the mouse issue in S3. > > Lionel > > Changelog: > - do not flush the buffer when the application only wants to peek the > number of elements in the queue > - trace the GetDeviceState values before they are reset No, saidly, it doesn't. I have attached a +dinput log again. Stefan

2 10

Re: ignore requested height for non-menubar ownerdraw popups
by Rein Klazes 08 May '05

08 May '05

On Sun, 8 May 2005 11:14:52 +0200, you wrote: > This fixes bug 2764 (the scrolling issue seems to be resolved > already?). Verified this behaviour on WinXP and changed the comment to > reflect that. > > ChangeLog: > Ignore requested height for non-menubar ownerdraw popups too. > > Index: menu.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/menu.c,v > retrieving revision 1.26 > diff -u -r1.26 menu.c > --- menu.c 19 Apr 2005 09:47:02 -0000 1.26 > +++ menu.c 8 May 2005 09:09:06 -0000 > @@ -887,17 +887,14 @@ > SendMessageW( hwndOwner, WM_MEASUREITEM, 0, (LPARAM)&mis ); > lpitem->rect.right += mis.itemWidth; > > - if (menuBar) > - { > - lpitem->rect.right += MENU_BAR_ITEMS_SPACE; > + /* under windows you are given a standard height for the > + menu and the height value is ignored. delphi 7 depends > + on this behaviour. */ > > + lpitem->rect.bottom += GetSystemMetrics(SM_CYMENU)-1; > That does not seem correct on the Win2k system that I am using for testing. Attached is the test that I am working on. It creates a non-menubar popup menu, fills it with a couple of items and traces the resulting item rectangles. It is all work in progress of course, not meant for submitting yet. Without your patch the rectangles get the height that is returned by the WM_MEASUREITEM handler both Win2k and Wine. With your patch the Wine behavior is broken. I have a real world application too, that is affected by this brokenness. Can you see if that is different on WinXP. If it is not, can you look what is different with your test and mine? Rein.

1 0