http://bugs.winehq.org/show_bug.cgi?id=239
Austin English <austinenglish(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #19 from Austin English <austinenglish(a)gmail.com> 2009-04-05 14:55:41 ---
Closing.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16172
Summary: processing queued test data: misleading description
Product: WineHQ Apps Database
Version: unspecified
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: appdb-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: bluedzins(a)wp.pl
processing queued test data: misleading description
I am maintainer of two apps and I find to difficult maintaing it beacause of
page when you have to decide whether to process or reject the queued data.
Here is why -- the info says:
"
This is the list of test results waiting for submission, rejection or d
deletion.
"
but the available actions are not three but two -- process and delete.
Info says:
To view a submission, click on its name.
And there is no name field.
So please correct the information to be accurate -- you can view the data by
processing it, and on the next page (processing) you can submit, reject, delete
data not on the queue data page.
Each time I have to figure out and remember from the last time how this page
actually works.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7106
--- Comment #10 from NSLW <lukasz.wojnilowicz(a)gmail.com> 2009-04-05 06:50:00 ---
Created an attachment (id=20298)
--> (http://bugs.winehq.org/attachment.cgi?id=20298)
WINEDEBUG=+relay,+seh Wine 1.1.18
(In reply to comment #9)
I'm using Wine 1.1.18 (compiled from source using gcc version 4.3.2 20081105
(Red Hat 4.3.2-7) ) on Fedora 10 i386.
This is still an issue.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7260
Jeff Gringo <dunerkahl(a)yahoo.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dunerkahl(a)yahoo.de
--- Comment #9 from Jeff Gringo <dunerkahl(a)yahoo.de> 2009-04-05 06:21:07 ---
(In reply to comment #8)
> Is this still an issue in current (1.1.9 or newer) wine?
>
Yes, it unfortunately is, i still have these z-buffer issues described in
Markus' screenshot under wine 1.1.18.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=4286
--- Comment #24 from Ken Sharp <kennybobs(a)o2.co.uk> 2009-04-04 19:55:09 ---
Created an attachment (id=20296)
--> (http://bugs.winehq.org/attachment.cgi?id=20296)
Wine 1.1.18 unhandled exception with native mdac25 and msxml3
(In reply to comment #23)
> According to "wine cmd" the environment variable is set to
> "ALLUSERSPROFILE=C:\windows\profiles\All Users", but c:\windows\profiles isn't
> even created during install.
In Wine 1.1.18 my environment is different.
ALLUSERSPROFILE=C:\users\Public
This directory does exist during installation but the files are still copied to
c:\
Simply moving the eBay folder from c:\ to c:\users\Public allows the app to
start, but an unhandled exception occurs.
winetricks mdac25 works around this unhandled exception.
A second unhandled exception occurs that "winetricks msxml3" takes care of.
When creating a new item, a third unhandled exception occurs (attached log),
but I am not aware of a workaround.
Should separate bugs be opened for each exception (as they are in different
modules)?
Gecko 0.9.1 is already installed on my system.
Also note that this app is affected by Bug 14026.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6953
Cody Logan <clpo13(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clpo13(a)gmail.com
--- Comment #15 from Cody Logan <clpo13(a)gmail.com> 2009-04-04 19:27:44 ---
I'm encountering this problem with version 1.03 of Star Wars: Knights of the
Old Republic. I installed from the CD, patched, and tried to run, but the
SecuROM error showed up.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=4286
Anastasius Focht <focht(a)gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |focht(a)gmx.net
--- Comment #23 from Anastasius Focht <focht(a)gmx.net> 2009-04-04 17:57:04 ---
Hello,
required prerequisites: clean WINEPREFIX
winetricks msxml3 mdac25 gecko
Native msxml3 because the app requests the free threaded version of DOMDocument
(MSXML2.FreeThreadedDOMDocument.3.0) which Wine doesn't provide.
MDAC 2.x can be any current version, not limited to 2.5
Gecko engine is needed later for embedded DHTML stuff.
--- quote ---
There's a difference in the Windows XP and Wine installs.
A folder named "eBay" appears in ~/.wine/drive_c/ when installed with Wine, but
under Windows XP this folder appears under C:\Documents and Settings\All
Users\.
According to "wine cmd" the environment variable is set to
"ALLUSERSPROFILE=C:\windows\profiles\All Users", but c:\windows\profiles isn't
even created during install.
Could it be that the files simply aren't being copied to the correct place?
The installer is failing to do it's job?
--- quote ---
Yes, it's Wine msi bug.
Dumping directory table with ORCA:
--- snip orca dump ---
Directory Directory_Parent DefaultDir
s72 S72 l255
TARGETDIR SourceDir
ALLUSERSPROFILE TARGETDIR .:ALLUSE~1|All Users
...
--- snip orca dump ---
Initial:
--- snip msi trace ---
0022:trace:msi:load_folder L"TARGETDIR"
...
0022:trace:msi:load_folder TargetDefault = L"SourceDir"
0022:trace:msi:load_folder SourceLong = L"SourceDir"
0022:trace:msi:load_folder SourceShort = L"SourceDir"
...
0022:trace:msi:load_folder L"ALLUSERSPROFILE"
...
0022:trace:msi:load_folder TargetDefault = L""
0022:trace:msi:load_folder SourceLong = L"All Users"
0022:trace:msi:load_folder SourceShort = L"ALLUSE~1"
--- snip msi trace ---
The installer executes custom actions to initialize 'USERPROFILE' and
'ALLUSERSPROFILE' properties from environment variables.
--- snip msi trace ---
0022:trace:msi:ACTION_CustomAction Handling custom action L"setUserProfileNT"
(33 L"USERPROFILE" L"[%USERPROFILE]")
0022:trace:msidb:MSI_CreateRecord 1
0022:trace:msidb:MSI_RecordSetStringW 0x1b9a10 0 L"[%USERPROFILE]"
...
0022:trace:msi:MSI_FormatRecordW (L"[%USERPROFILE]")
...
0022:trace:msi:MSI_SetPropertyW 0x16cc60 L"USERPROFILE" L"C:\\users\\focht"
0022:trace:msidb:MSI_CreateRecord 1
...
0022:trace:msi:ACTION_CustomAction Handling custom action
L"setAllUsersProfile2K" (33 L"ALLUSERSPROFILE" L"[%ALLUSERSPROFILE]")
0022:trace:msidb:MSI_CreateRecord 1
0022:trace:msidb:MSI_RecordSetStringW 0x1b7f70 0 L"[%ALLUSERSPROFILE]"
...
0022:trace:msi:MSI_FormatRecordW (L"[%ALLUSERSPROFILE]")
0022:trace:msi:MSI_SetPropertyW 0x16cc60 L"ALLUSERSPROFILE"
L"C:\\users\\Public"
--- snip msi trace ---
'ALLUSERSPROFILE' folder gets properly resolved in CostFinalizeDirectories
action:
--- snip msi trace ---
0022:trace:msi:ITERATE_CostFinalizeDirectories Dir L"ALLUSERSPROFILE" ...
0022:trace:msi:resolve_folder Working to resolve L"ALLUSERSPROFILE"
...
0022:trace:msi:MSI_GetPropertyW returning L"C:\\users\\Public" for property
L"ALLUSERSPROFILE"
0022:trace:msi:resolve_folder property set to L"C:\\users\\Public"
0022:trace:msi:ITERATE_CostFinalizeDirectories resolves to L"C:\\users\\Public"
--- snip msi trace ---
and is used later to build various installer paths:
--- snip msi trace ---
0022:trace:msi:MSI_GetPropertyW returning L"C:\\users\\Public" for property
L"ALLUSERSPROFILE"
0022:trace:msi:resolve_folder property set to L"C:\\users\\Public"
...
0022:trace:msi:MSI_GetPropertyW property L"eBayTLData" not found
0022:trace:msi:resolve_folder ! Parent is L"ALLUSERSPROFILE"
0022:trace:msi:resolve_folder Working to resolve L"ALLUSERSPROFILE"
0022:trace:msi:resolve_folder already resolved to L"C:\\users\\Public"
0022:trace:msi:resolve_folder TargetDefault = L"eBay"
0022:trace:msi:resolve_folder target -> L"C:\\users\\Public\\eBay\\"
0022:trace:msi:MSI_SetPropertyW 0x16cc60 L"eBayTLData"
L"C:\\users\\Public\\eBay\\"
0022:trace:msidb:MSI_CreateRecord 1
0022:trace:msidb:MSI_RecordSetStringW 0x1785c8 1 L"eBayTLData"
--- snip msi trace ---
Some time later ... surprise!
--- snip msi trace ---
0022:trace:msi:MSI_GetPropertyW returning L"C:\\" for property L"TARGETDIR"
0022:trace:msi:resolve_folder already resolved to L"C:\\"
0022:trace:msi:resolve_folder Working to resolve L"ALLUSERSPROFILE"
0022:trace:msi:resolve_folder ! Parent is L"TARGETDIR"
0022:trace:msi:resolve_folder Working to resolve L"TARGETDIR"
0022:trace:msi:resolve_folder already resolved to L"C:\\"
0022:trace:msi:resolve_folder TargetDefault = L""
0022:trace:msi:resolve_folder target -> L"C:\\"
0022:trace:msi:MSI_SetPropertyW 0x16cc60 L"ALLUSERSPROFILE" L"C:\\"
0022:trace:msidb:MSI_CreateRecord 1
0022:trace:msidb:MSI_RecordSetStringW 0x17cd88 1 L"ALLUSERSPROFILE"
--- snip msi trace ---
'ALLUSERSPROFILE' property is reset to "C:\\" which leads to problem that some
installation files are put in wrong location.
The reset of resolved target happens in MSI_SetTargetPathW().
--- snip ---
0022:trace:msi:MSI_SetTargetPathW 0x16cc30 L"USERPROFILE" L"C:\\users\\focht"
0022:trace:msi:resolve_folder Working to resolve L"USERPROFILE"
...
--- snip ---
--- snip dlls/msi/install.c ---
UINT MSI_SetTargetPathW(MSIPACKAGE *package, LPCWSTR szFolder,
LPCWSTR szFolderPath)
{
DWORD attrib;
LPWSTR path = NULL;
LPWSTR path2 = NULL;
MSIFOLDER *folder;
MSIFILE *file;
...
path = resolve_folder(package,szFolder,FALSE,FALSE,FALSE,&folder);
if (!path)
return ERROR_DIRECTORY;
msi_free(folder->Property);
folder->Property = build_directory_name(2, szFolderPath, NULL);
if (lstrcmpiW(path, folder->Property) == 0)
{
/*
* Resolved Target has not really changed, so just
* set this folder and do not recalculate everything.
*/
...
}
else
{
MSIFOLDER *f;
LIST_FOR_EACH_ENTRY( f, &package->folders, MSIFOLDER, entry )
{
msi_free(f->ResolvedTarget);
f->ResolvedTarget=NULL;
}
...
}
...
}
--- snip dlls/msi/install.c ---
Both paths refer to same location ("C:\\users\\focht\\" -> '%USERPROFILE%') but
the resolved path taken from property is missing the terminating backslash.
build_directory_name(2, szFolderPath, NULL) will always add terminating
backslash -> "C:\\users\\focht\\"
resolve_folder(package,szFolder,FALSE,FALSE,FALSE,&folder) will not ->
"C:\\users\\focht"
The path comparison fails and all resolved targets in the package are thrown
away to be re-resolved.
This renders previous custom actions which set specific path properties
useless.
You might want to fix resolve_folder() to have resolved target
backslash-terminated when loading from property.
With that problem fixed, the app overcomes the "first user" problem and starts
successfully.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17944
Summary: [Counterstrike/Steam] Wine won't use fullscreen apps at
proper resolution
Product: Wine
Version: 1.1.18
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: julian.lam(a)gmail.com
Created an attachment (id=20283)
--> (http://bugs.winehq.org/attachment.cgi?id=20283)
Complete WINE terminal log output from start of program to exit.
wine:
Installed: 1.1.18~winehq0~ubuntu~8.10-0ubuntu1
Candidate: 1.1.18~winehq0~ubuntu~8.10-0ubuntu1
Version table:
*** 1.1.18~winehq0~ubuntu~8.10-0ubuntu1 0
500 http://wine.budgetdedicated.com intrepid/main Packages
100 /var/lib/dpkg/status
1.0.1-0ubuntu2 0
500 http://ubuntu.mirror.rafal.ca intrepid/universe Packages
Installed Wine via package manager, and installed Counterstrike through Wine.
Using nvidia driver v180.29 installed off of the nvidia.com website.
When running counter-strike, which, by default, is a full-screen application,
the program defaults to 640x480 in windowed mode. Clicking through the options
from within the game show no way to change the resolution to something higher
(The "resolutions" drop-down box is completely empty).
This is platform independent, as I have run into this problem on both x86 and
x86_64 installations.
It may be because the game itself doesn't support this particular aspect ratio,
but my monitor supports many different resolutions, so that can't be the
problem.
Of notable importance is the following line in the Wine terminal output:
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found
640x480x16 @0! (XRandR)
Please advise.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6953
knan-wine(a)anduin.net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |knan-wine(a)anduin.net
--- Comment #14 from knan-wine(a)anduin.net 2009-04-04 11:25:22 ---
Also happens to Silent Storm retail version with wine 1.1.18+git. ProtectionID
says SecuROM 4.85.07.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17947
Summary: MouseWarpOverride set to force causes mouse in menus to
hang
Product: Wine
Version: 1.1.18
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: directx-dinput
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: felix.kuperjans(a)gmx.de
To avoid the mouse escaping the window or hitting screen edges while playing
for example ego shooters, that don't grab the mouse correctly with DirectInput,
the registry key "MouseWarpOverride" was introduced (see bug 6971). With
setting this key to force, one can cause wine to reset the cursor position
several times per secound, so that the cursor does not escape the window or hit
the screen edges.
This works fine for many games, but in some games this opens a new bug:
The mouse can now be used freely within the gameplay, but in the menus of those
games the cursor is resetted, too, and one can't move the mouse to the menu
items.
Games, where I recognized this bug are:
Gothic III
AquaNox 2 Revelation
I would recommend a workaround until the mouse bug is finally solved and there
are no more problems in any game:
Add a keyboard shortcut, that can be optionally configured to turn
MouseWarpOverride on or off on the fly during the gameplay. This way, one could
leave it as disabled by default, and enable it after the game itself has
started. If one goes back to the menu, it can be disabled again by pressing
this shortcut.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.