http://bugs.winehq.org/show_bug.cgi?id=892
fgouget(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From fgouget(a)codeweavers.com 2007-30-04 11:38 -------
Alexandre committed a patch using CPUID to detect de CPU. See commit
82274f8b1631312893d3052b06ccb2e264e674.
So I think this bug can be closed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=4278
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2007-30-04 11:37 -------
Hi, Microsoft Flight Simulator fails in the same way and doesn't run. I made a
workaround attached hereafter. Analysis:
Even if I set the (not very well known) registry key "ScreenDepth" to 32, the
game still fails in the same way. Here's what happens (from x11drv_main.c):
------------------------------------------------------------------------------------------------------------------
if (!get_config_key( hkey, appkey, "ScreenDepth", buffer, sizeof(buffer) ))
screen_depth = atoi(buffer);
So we have a 32-bit resolution if we set this registry key
---------------------------------------------------------------------------------------------------------------
Later on:
/* If OpenGL is available, change the default visual, etc as necessary */
if ((desktop_vi = X11DRV_setup_opengl_visual( display )))
{
visual = desktop_vi->visual;
screen = ScreenOfDisplay(display, desktop_vi->screen);
screen_depth = desktop_vi->depth;
XFree(desktop_vi);
}
----------------------------------------------------------------------------------------------------
Now we end up with a screendepth of 24 again. The only solution I see is the
workaround in the patch attached hereafter. SplinterCell Pandora and MicroSoft
Flight Simulator X start fine with this patch, and the registry key set.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=765
fgouget(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From fgouget(a)codeweavers.com 2007-30-04 11:30 -------
As far as I can tell the bug is still there. I'm adding screenshots to show the
issue.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=5828
cimmo(a)libero.it changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cimmo(a)libero.it
------- Additional Comments From cimmo(a)libero.it 2007-30-04 10:44 -------
why cursor patches cannot be applied upstream?
--
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.
http://bugs.winehq.org/show_bug.cgi?id=8235
Summary: Mutli-CD installs fail
Product: Wine
Version: 0.9.36.
Platform: PC
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: karl(a)qdh.org.uk
This problem has been tested significantly on Ubuntu 7.04 and can easily be
repeated.
When attempting to install Call of Duty (other games may be affected), when
reaching the second CD the eject button fails to eject the disc, an error is
reported explaining the disc is currently in use.
More info:
I had tested this with wine C. 0.9.20 on Fedora and the problem didn't appear.
Is this an Ubuntu specific problem?
Using wine eject on the command line at the point of the second disc request,
succeeds up until the first disc requires re-inserting. At which point it fails
again with a spurious error message. After using wine eject on ubuntu, HAL fails
to correctly control CD mounts.
Further testing:
Will test again with fedora and recent wine, if I see failure then this will
probably be as a result of some regression.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=8222
------- Additional Comments From focht(a)gmx.net 2007-30-04 10:32 -------
Hello,
--- quote ---
This might be a dup of bug 5348, ask James.
--- quote ---
nope.
After much investigation on my own, it actually turns out to be a dup of bug 5768
I couldnt believe the installer wont run on windows so i debugged msi installer
service process itself, which loads and executes custom action dlls.
Basically the windows part itself is wrong due to an internal msi ansi<->unicode
conversion bug (Windows XP SP2 with latest patches).
It turns out this bug goes rather unnoticed without further damage due to the
nature of returned data :)
I recorded all stack parameters before the call to windows msi.MsiGetPropertyA()
and compared after.
Same just like wine.
First call is to determine buffer length.
--- snip analysis ---
009AF80C 00000042 hInstall
009AF810 003A21B0 Name -> ASCII "AUMUSEORIGINALAPPID"
009AF814 00000000 szValueBuf
009AF818 009AF830 pchValueBuf
pchValueBuf: 009AF830 -> 0x0
upon return:
pchValueBuf: 009AF830 -> 0x8 <--- bug!
second call:
009AF80C 00000042 hInstall
009AF810 003A21B0 Name -> ASCII "AUMUSEORIGINALAPPID"
009AF814 003A2200 szValueBuf
009AF818 009AF830 pchValueBuf
dump of szValueBuf (ANSI):
003A2200 54 72 75 65 00 00 00 00 08 00 02 00 EE 01 0C 00 True............
--- snip analysis ---
Remember, the property value to be retrieved is "True" (ANSI -> len = 4).
The first call returns: len = 8
This is indeed the ANSI version of msi.MsiGetProperty that returns this!
Windows internal API is unicode based.
That's why all passed in parameters get converted to unicode and back upon return.
E.g. for ANSI api function: ansi2unicode -> internal msi (rpc4) -> unicode2ansi.
Thats the theory.
Due to a bug in the "ERROR_MORE_DATA" case, the length parameter which was
lstrlenW("True") == 4 upon return gets incorrectly doubled (2*len) - probably
some "sizeof(WCHAR)*len" code.
Regards
--
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.
http://bugs.winehq.org/show_bug.cgi?id=8234
Summary: Supreme Commander Install fail - Error : 87
Product: Wine
Version: 0.9.36.
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: tehstealth(a)yahoo.com
I can't install Supreme Commander with the latest Wine. Near the end of the
install, when it starts installing tutorial files, it freezes. When it reaches
TUB200.lua, a little error box comes up, "Error: 87". I press the only button on
it, OK, and the installation closes after a few seconds.
--
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.