http://bugs.winehq.org/show_bug.cgi?id=6533
Andrew Nguyen <arethusa26(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #21 from Andrew Nguyen <arethusa26(a)gmail.com> 2010-05-18 14:19:21 ---
The app doesn't exhibit the "type mismatch" error in wine-1.1.44-290-g7d3cb53
with LC_ALL=de_DE.utf8, so this is fixed.
--
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=22580
Summary: RegisterWaitForSingleObject() with tmo=0 causes 100%
CPU load
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: joakim.tjernlund(a)transmode.se
Created an attachment (id=27708)
--> (http://bugs.winehq.org/attachment.cgi?id=27708)
RegisterWaitForSingleObject() fix special tmo == 0 case.
At http://msdn.microsoft.com/en-us/library/aa332406%28VS.71%29.aspx one
can read:
"If the timeOutInterval parameter is not zero (0) and the executeOnlyOnce
parameter is false, the timer is reset every time the event is signaled
or the time-out interval elapses."
timeOutInterval == 0 makes the above false and the timer should NOT
be reset, the attached patch fixes that.
--
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=22756
Summary: Wine64 will not build on GCC 4.4.4
Product: Wine
Version: 1.1.44
Platform: x86
OS/Version: Linux
Status: NEW
Keywords: download, source, win64
Severity: blocker
Priority: P1
Component: build-env
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: kennybobs(a)o2.co.uk
Trying to compile Wine64 on an i386 system, I'm scuppered at the first hurdle.
../configure --enable-win64 --build=amd64
checking whether gcc supports __builtin_ms_va_list... no
configure: error: You need gcc >= 4.4 to build Wine as 64-bit.
$ gcc --version
gcc (GCC) 4.4.4
Is it a case that __builtin_ms_va_list never made it into 4.4.4? I can't find
any information about this in the changelogs.
--
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=7835
--- Comment #16 from MCpaul34 <MCpaul34(a)gmail.com> 2010-05-18 11:33:30 ---
Still present in wine 1.1.44.
--
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=3548
--- Comment #36 from Hans Leidekker <hans(a)meelstraat.net> 2010-05-18 09:55:59 ---
> We shouldn't store the Wine prefix in the .lnk file
Why not? It appears to an extensible format, see IShellLinkDataList.
--
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=3548
--- Comment #35 from Damjan Jovanovic <damjan.jov(a)gmail.com> 2010-05-18 09:18:52 ---
(In reply to comment #33)
> (In reply to comment #32)
> > Perhaps we can store the Wine prefix in the .lnk file somewhere.
> You can't do that. Some dumb installers have "pre-packaged" .lnk files that are
> just copied into place.
Pre-packaged .lnk files that get just copied into place would bypass shell32's
IShellLink's IPersistFile_Save, and winemenubuilder won't get invoked to build
.desktop files. Such files also imply that you can't choose where to install
the application, since that affects the .lnk contents?
We shouldn't store the Wine prefix in the .lnk file, it could go into some
other settings database (maybe not the registry, since that's local to each
Wine prefix), from where the tool that starts .lnk can look up which Wine to
use.
At least we can patch Gnome and write a thumbnailer - it must be real fun and
games to fix this on MacOS :-).
--
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=3548
--- Comment #34 from Hans Leidekker <hans(a)meelstraat.net> 2010-05-18 09:02:05 ---
Those are broken on Windows too, although differently. I recall that
Windows has a dialog to search or browse a missing shortcut target.
We could do something along those lines if we don't find the prefix.
--
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=3548
--- Comment #33 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2010-05-18 08:41:44 ---
(In reply to comment #32)
> Perhaps we can store the Wine prefix in the .lnk file somewhere.
You can't do that. Some dumb installers have "pre-packaged" .lnk files that are
just copied into place.
--
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.