November 2005 - Wine-Bugs - list.winehq.org

[Bug 2366] Wine unable to initiallize on NetBSD

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=2366 ------- Additional Comments From ingolf.steinbach(a)jena-optronik.de 2005-29-11 03:50 ------- This might be the same as the FreeBSD problem described in http://www.winehq.org/?issue=230#Wine%20on%20FreeBSD Ingolf -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.

Nov. 29, 2005

[Bug 3937] WinAmbulancia application dosen't work

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=3937 ------- Additional Comments From tuharsky(a)misbb.sk 2005-29-11 03:03 ------- Oops, it looks like only DOS version is available for download. The Windows version is only sent after request. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 2332] 16-bit application (WinLED) fails due to regression in NE-module handling

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=2332 saulius.krasuckas(a)elst.vtu.lt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|REMIND | ------- Additional Comments From saulius.krasuckas(a)elst.vtu.lt 2005-29-11 02:52 ------- Still occurs after fixing bug #2978. Maybe it would be easier to hunt if we have 16-bit API test framework incorporated into Wine tree. That would probably require OpenWatcom to be installed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 3937] WinAmbulancia application dosen't work

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=3937 ------- Additional Comments From tuharsky(a)misbb.sk 2005-29-11 02:44 ------- The address for registration is http://www.softprogres.sk/sp_down.php?cmdRegistracia=1 and address for download then is http://www.softprogres.sk/sp_down.php -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 2937] Need to implement header callbacks (IE feature)

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=2937 fenix(a)club-internet.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From fenix(a)club-internet.fr 2005-29-11 02:39 ------- It's not the same problem. You need native usp10.dll because wine builtin library is only stubs. You can see they generate an invalid string (-1) and count (-1 too) to DrawTextW DrawTextW(hdc=0x33c, str=0xffffffff, count=0xffffffff, Re-Closing that bug report. You can open another for usp10.dll implementation (and for that i really cannot help you) Regards, Raphael -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 2978] 16-bit app deadlocks due to changes in initialisation of BIOS and SYSTEM information

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=2978 saulius.krasuckas(a)elst.vtu.lt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CLOSED ------- Additional Comments From saulius.krasuckas(a)elst.vtu.lt 2005-29-11 02:30 ------- I am sure no one gonna to object this, as no one seems to be interested in this app. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 2978] 16-bit app deadlocks due to changes in initialisation of BIOS and SYSTEM information

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=2978 saulius.krasuckas(a)elst.vtu.lt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 2978] 16-bit app deadlocks due to changes in initialisation of BIOS and SYSTEM information

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=2978 saulius.krasuckas(a)elst.vtu.lt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From saulius.krasuckas(a)elst.vtu.lt 2005-29-11 02:26 ------- But now things goes OK and I am sure this is because of one of the patches, yesterday submitted by Alexandre Julliard: http://www.winehq.org/pipermail/wine-cvs/2005-November/019506.html http://www.winehq.org/pipermail/wine-cvs/2005-November/019507.html I am not sure which one is essential, I am just saying lotta thanks to AJ. Nice. :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 2978] 16-bit app deadlocks due to changes in initialisation of BIOS and SYSTEM information

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=2978 saulius.krasuckas(a)elst.vtu.lt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|INVALID | ------- Additional Comments From saulius.krasuckas(a)elst.vtu.lt 2005-29-11 02:23 ------- Actually app crash was very rare and with the latest Wine versions it wasn't exhibiting itself. So until yesterday it was valid. (I was possible to workaround it by adding +relay flag and redirecting everything to /dev/null) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005

[Bug 3902] Unnormal slowness in Heroes 4 (X11DRV_BitBlt?)

by Wine Bugs

http://bugs.winehq.org/show_bug.cgi?id=3902 ------- Additional Comments From giulian2003(a)hotmail.com 2005-29-11 02:00 ------- I am trying to solve this: If i am correct, the problem appears in file bitblt.c, function X11DRV_BitBlt and it has to do with this part of code: sDst = X11DRV_LockDIBSection( physDevDst, DIB_Status_None, FALSE ); if (physDevDst != physDevSrc) sSrc = X11DRV_LockDIBSection( physDevSrc, DIB_Status_None, FALSE ); ......... if (sDst == DIB_Status_AppMod) { FIXME("potential optimization - client-side DIB copy\n"); } X11DRV_CoerceDIBSection( physDevDst, DIB_Status_GdiMod, FALSE ); The problem appears only when you move the mouse icon over the game map or the minimap in the upper right corner of the game window. I tried to debug it with 'WINEDEBUG=+bitblt wine h4mod.exe' and it seems that Heroes keeps one bitmap for the entire window, one for the big map and one for the minimap and when you move the mouse cursor over the later two, it tries to do a X11DRV_BitBlt from the map/minimap to the window bitmap, followed imediately by a X11DRV_BitBlt from the mouse icon bitmap to the same region of the window bitmap. In that case it tries to aquire 'DIB_Status_GdiMod' locking state on t he destination but it finds it in 'DIB_Status_AppMod' state. I looked in dib.c to understand what happens then, anyway, this is a piece of code taken from X11DRV_CoerceDIBSection function: case DIB_Status_AppMod: TRACE("GdiMod requested in status AppMod\n" ); if (!lossy) { /* make it readonly to avoid app changing data while we copy */ X11DRV_DIB_DoProtectDIBSection( physBitmap, PAGE_READONLY ); X11DRV_DIB_DoUpdateDIBSection( physBitmap, FALSE ); } X11DRV_DIB_DoProtectDIBSection( physBitmap, PAGE_NOACCESS ); physBitmap->p_status = DIB_Status_AppMod; physBitmap->status = DIB_Status_GdiMod; break; I tried to modify PAGE_NOACCESS and PAGE_READONLY to PAGE_READWRITE, AND the screen got messed up, because the the order of the displaying bitmaps was wrong, but the slowness problem disappeard completely! In this case, i am sure its a LOCKING PROBLEM. Maybe the first X11DRV_BitBlt puts the region of the window bitmap in PAGE_NOACCESS as we see above and the second X11DRV_BitBlt has to wait for the first one to finish. I am not sure, i am still trying to understand the difference between 'DIB_Status_AppMod' and 'DIB_Status_GdiMod' since i found no documentation at all .. anyway, i am working on it! Help is always welcome :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Nov. 29, 2005