January 2004 - Wine-Bugs - list.winehq.org

[Bug 1957] New: regression: did work in nov2002, but now: err:bitmap:X11DRV_DIB_SetImageBits Out of memory!
by Wine Bugs Jan. 23, 2004

Jan. 23, 2004

http://bugs.winehq.org/show_bug.cgi?id=1957 Summary: regression: did work in nov2002, but now: err:bitmap:X11DRV_DIB_SetImageBits Out of memory! Product: Wine Version: CVS Platform: PC URL: http://monostep.org/demo/thehit.html OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx AssignedTo: wine-bugs(a)winehq.org ReportedBy: a.stenglein(a)gmx.net TheHit Realtime (http://monostep.org/demo/thehit.html thehitrt.zip 3,8MByte) did work in Nov2002, at least to a certain extend. It only showed some err:opengl:wglGetProcAddress Extension wglGetExtensionsStringARB ... and some fixme:ole, dsound, system then with wine-cvs from some weeks ago it showed only these two fixmes and didnt work at all: fixme:ole:CoCreateInstance no classfactory created for CLSID {3901cc3f-84b5-4fa4-ba35-aa8172b8a09b}, hres is 0x80040154 fixme:ole:CoCreateInstance no classfactory created for CLSID {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x80040154 and now with current wine cvs I get these errors and it still doesnt work: err:bitmap:X11DRV_DIB_SetImageBits Out of memory! err:bitmap:X11DRV_DIB_SetImageBits Out of memory! wine: Unhandled exception (thread 0009), starting debugger... err:win32:_EnterSysLevel (0x40743400, level 2): Holding 0x40805660, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x40743400, level 2): Holding 0x40805660, level 3. Expect deadlock! -- 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.

1 0

[Bug 1956] [PATCH] Incorrect random multicast MAC address creation in UUID generator
by Wine Bugs Jan. 23, 2004

Jan. 23, 2004

http://bugs.winehq.org/show_bug.cgi?id=1956 ------- Additional Comments From rse(a)engelschall.com 2004-23-01 03:00 ------- Created an attachment (id=500) --> (http://bugs.winehq.org/attachment.cgi?id=500&action=view) Patch to fix UUID generation -- 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.

1 0

[Bug 1956] New: [PATCH] Incorrect random multicast MAC address creation in UUID generator
by Wine Bugs Jan. 23, 2004

Jan. 23, 2004

http://bugs.winehq.org/show_bug.cgi?id=1956 Summary: [PATCH] Incorrect random multicast MAC address creation in UUID generator Product: Wine Version: 20031212 Platform: All OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: rse(a)engelschall.com In case no real/physical IEEE 802 address is available, both the expired "draft-leach-uuids-guids-01" (section "4. Node IDs when no IEEE 802 network card is available") and RFC 2518 (section "6.4.1 Node Field Generation Without the IEEE 802 Address") recommend (quoted from RFC 2518): "The ideal solution is to obtain a 47 bit cryptographic quality random number, and use it as the low 47 bits of the node ID, with the _most_ significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards." Unfortunately, this incorrectly explains how to implement this and this UUID generator code inherited this generation bug from the broken reference code in the standards draft. They should instead specify the "_least_ significant bit of the first octet of the node ID" as the multicast bit in a memory and hexadecimal string representation of a 48-bit IEEE 802 MAC address. This standards bug arised from a false interpretation, as the multicast bit is actually the _most_ significant bit in IEEE 802.3 (Ethernet) _transmission order_ of an IEEE 802 MAC address. The standards authors forgot that the bitwise order of an _octet_ from a MAC address _memory_ and hexadecimal string representation is still always from left (MSB, bit 7) to right (LSB, bit 0). The following patch fixes this: --- wine/dlls/rpcrt4/rpcrt4_main.c.orig Thu Sep 11 03:05:19 2003 +++ wine/dlls/rpcrt4/rpcrt4_main.c Thu Jan 15 18:18:08 2004 @@ -351,7 +351,7 @@ if (sd < 0) { /* if we can't open a socket, just use random numbers */ /* set the multicast bit to prevent conflicts with real cards */ - a[0] = (rand() & 0xff) | 0x80; + a[0] = (rand() & 0xff) | 0x01; a[1] = rand() & 0xff; a[2] = rand() & 0xff; a[3] = rand() & 0xff; @@ -366,7 +366,7 @@ close(sd); /* no ifconf, so just use random numbers */ /* set the multicast bit to prevent conflicts with real cards */ - a[0] = (rand() & 0xff) | 0x80; + a[0] = (rand() & 0xff) | 0x01; a[1] = rand() & 0xff; a[2] = rand() & 0xff; a[3] = rand() & 0xff; @@ -403,7 +403,7 @@ } /* if we didn't find a valid address, make a random one */ /* once again, set multicast bit to avoid conflicts */ - a[0] = (rand() & 0xff) | 0x80; + a[0] = (rand() & 0xff) | 0x01; a[1] = rand() & 0xff; a[2] = rand() & 0xff; a[3] = rand() & 0xff; @@ -416,7 +416,7 @@ } #else /* no networking info, so generate a random address */ - a[0] = (rand() & 0xff) | 0x80; + a[0] = (rand() & 0xff) | 0x01; a[1] = rand() & 0xff; a[2] = rand() & 0xff; a[3] = rand() & 0xff; -- 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.

1 0

[Bug 1952] half-life, unreal tournament: video runs too 1.5x too fast
by Wine Bugs Jan. 23, 2004

Jan. 23, 2004

http://bugs.winehq.org/show_bug.cgi?id=1952 ------- Additional Comments From lesha(a)netman.ru 2004-22-01 23:59 ------- Additional bizarreness: I've since recompiled 20031212 with --enable-debug, and the problem went away (all other things being the same). That makes it rather difficult to debug properly (ideas?). -- 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.

1 0

[Bug 1955] New: error on application install of AutoCAD 2000 ( R15)
by Wine Bugs Jan. 22, 2004

Jan. 22, 2004

http://bugs.winehq.org/show_bug.cgi?id=1955 Summary: error on application install of AutoCAD 2000 ( R15) Product: Wine Version: CVS Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-binary AssignedTo: wine-bugs(a)winehq.org ReportedBy: NaveR(a)FidelityTech.com 1/22/2004 I have just installed the latest wine binary from wine-cvs-glibc23-opengl-20040122-1.586.rpm on a pentium system running Red Hat Fedora 1 with both kernel versions 2.4.22 and 2.6.1 I attempted to install AutoCAD R15 by running wine setup.exe from the Autocad source directory. The installation appeared to proceed flawlessly with no errors. When I attempted to start AutoCAD by typing wine acad.exe I received the following message err: map_image StandardLoadaddress for a Win32 program ( 0x00400000 ) is not available - security patched kernel ? I get the same error with both the 2.4.22 and 2.6.1 kernels. Note ( I have tried Auto CAD on previous versions of Wine with no success ) This is the first version that appears to cleanly install. This is a new error message that I have never seen before. I am not sure what the error message means. -- 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.

1 0

[Bug 1954] New: SHNotifyCopyFileW doesn't create subdirectories (it should)
by Wine Bugs Jan. 22, 2004

Jan. 22, 2004

http://bugs.winehq.org/show_bug.cgi?id=1954 Summary: SHNotifyCopyFileW doesn't create subdirectories (it should) Product: Wine Version: 20031212 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.org ReportedBy: phillip.ezolt(a)hp.com SHNotifyCopyFileW does NOT create subdirectories if they do not already exist. The installer for RollerCoaster tycoon demo requires this to be working properly to install. (The real version has the same problem.) (This demo is located at: ftp://ftp.microprose.com/pub/demos/rollercoaster/rct-edl.exe ) During installation, the install creates the directory: C:\\Program Files\\Hasbro Interactive\\RollerCoaster Tycoon Demo\\ It can successfully copy files to this newly created directory, but coping into any (currently non-existant) directories below it fail. According to MS: " Copy and Move operations can specify destination directories that do not exist and the system will attempt to create them. " (See footnote #1 for more info) For example, this succeeds: trace:shell:SHNotifyCopyFileW (L"E:\\WZS21db.tmp\\English\\rct.exe" L"C:\\Program Files\\Hasbro Interactive\\RollerCoaster Tycoon Demo\\rct.exe" ) But this fails: trace:shell:SHNotifyCopyFileW (L"E:\\WZS21db.tmp\\Saved Games\\001" L"C:\\Program Files\\Hasbro Interactive\\RollerCoaster Tycoon Demo\\Saved Games\\001" ) The directory "Saved Games" should be created before "001" is copied into it. Instead, the call fails. I've verified that this true, by creating the proper directories as it is installing, and the game works fine. (When the install is running, I cd into: "C:\\Program Files\\Hasbro Interactive\\RollerCoaster Tycoon Demo\\" and from Linux type: mkdir "Saved Games" ; mkdir "Data" ; mkdir "Tracks" ; mkdir "Scenarios" The will make the directories and the installation will complete. Note this bug shows up on /usr/src/wine-20040121 as well. (1) According to: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… ... pTo Address of a buffer to contain the name of the destination file or directory. This parameter must be set to NULL if it is not used. Like pFrom, the pTo member is also a double-null terminated string and is handled in much the same way. However, pTo must meet the following specifications. ... * Copy and Move operations can specify destination directories that do not exist and the system will attempt to create them. The system normally displays a dialog box to ask the user if they want to create the new directory. To suppress this dialog box and have the directories created silently, set the FOF_NOCONFIRMMKDIR flag in fFlags. * For Copy and Move operations, the buffer can contain multiple destination file names if the fFlags member specifies FOF_MULTIDESTFILES. ... -- 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.

1 0

[Bug 1950] Regression - MDI Failure in 16-Bit Program
by Wine Bugs Jan. 22, 2004

Jan. 22, 2004

http://bugs.winehq.org/show_bug.cgi?id=1950 ------- Additional Comments From Andrew.Talbot(a)talbotville.com 2004-22-01 10:59 ------- Yes, I sent Dmitry a copy of the app. and he has submitted a patch. -- 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.

1 0

[Bug 1951] running ldraw.exe gives: unprotecting the first 64KB of memory to allow real-mode calls.
by Wine Bugs Jan. 22, 2004

Jan. 22, 2004

http://bugs.winehq.org/show_bug.cgi?id=1951 mike(a)theoretic.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID ------- Additional Comments From mike(a)theoretic.com 2004-22-01 09:11 ------- This warning is harmless and is intended for Wine developers. It can be ignored. -- 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.

1 0

[Bug 1950] Regression - MDI Failure in 16-Bit Program
by Wine Bugs Jan. 22, 2004

Jan. 22, 2004

http://bugs.winehq.org/show_bug.cgi?id=1950 mike(a)theoretic.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry(a)codeweavers.com ------- Additional Comments From mike(a)theoretic.com 2004-22-01 09:10 ------- Is this application available? Dmitry said at the time this was not well tested with 16 bit apps as he doesn't have any. -- 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.

1 0

[Bug 1953] New: incorrect mouse / menu interaction (compared to windows)
by Wine Bugs Jan. 22, 2004

Jan. 22, 2004

http://bugs.winehq.org/show_bug.cgi?id=1953 Summary: incorrect mouse / menu interaction (compared to windows) Product: Wine Version: 20030813 Platform: All URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228539 OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-gui AssignedTo: wine-bugs(a)winehq.org ReportedBy: ovek(a)arcticnet.no Luke Kenneth Casson Leighton <lkcl(a)samba-tng.org> reports: this is a sort of non-conformity of "correctness" against the behaviour of windows and wine. on windows: when left-mouse-button-pressing-and-holding on a menu, the menu stays popped up. mouse-moving can be used to select sub-menus, etc. etc. all whilst still left-mouse-button-holding. on left-mouse-button-release, if the mouse is over a menu item, it is "actioned". on wine: when left-mouse-button-pressing-and-holding on a menu, the menu stays popped up. mouse-moving can be used to select sub-menus, etc. etc. all whilst still left-mouse-button-holding. on left-mouse-button-release, if the mouse is over a menu item, it is NOT "actioned". in fact, occasionally, the menu stays popped up! only by selecting an option on it (with a left-mouse-click), which is not always desirable, does the menu disappear! -- 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.

1 0