https://bugs.winehq.org/show_bug.cgi?id=41564
Bug ID: 41564
Summary: Google Nik Collection: Top menu bar gone and cursor
gone
Product: Wine-staging
Version: 1.9.21
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dan.Tableau(a)gmail.com
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
Hello, I just want to report that using wine 1.9.21 (staging) with the Google
Nik Collection creates the following issues:
Top menu bar gone, cursor gone (while inside the window).
After switching to winehq-devel, as suggest in the IRC (Thanks, slackner), the
problem was gone. Both times the version used was: 1.9.21
Let me know if more info is needed. Thank for doing all this and keeping it up
and running!
--
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.
https://bugs.winehq.org/show_bug.cgi?id=47408
Bug ID: 47408
Summary: Katamari Damacy: AppData\Local mismatch causes Steam
Cloud to be ignored
Product: Wine
Version: 4.10
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: devilj(a)outlook.pt
Distribution: ---
Hi,
This game seems to have hardcoded the directories for the AppData\Local and
AppData\LocalLow folders, and that means the game isn't syncing with Steam
Cloud, because Steam is a good program and knows where to store the files
correctly and this game doesn't.
Specifically, Steam saves in the right directory ("%LocalAppData%" ->
"%USERPROFILE%\Local Settings\Application Data\"), and the game is looking for
"%USERPROFILE%\AppData\Local\"; thus, Steam can't see the files that the game
writes and vice-versa. Note that the game loads and saves correctly; it just
does it in the wrong directory.
There is also the issue of LocalLow being missing entirely.
Now, obviously, this bug sits entirely with the game; but there seems to be
more reports about games missing these specific folders (see bug #45713). And
this bug is very easily fixable, too, by creating symlinks.
That said, the AppData directories are standard since Windows Vista, and Wine
is using the very old, XP-style Application Data structure.
I propose that we create symlinks from AppData\Local and AppData\Romaing
pointing to the correct directories, and create AppData\LocalLow on prefix
creation. Hopefully that would be simple to do, and it'd fix every bug of this
kind.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=40403
Bug ID: 40403
Summary: WARCRAFT III NO VIDEO
Product: Wine
Version: 1.9.7
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: legluondunet(a)free.fr
Distribution: ---
Hello,
I just installed Warcraft III and tested it with wine 1.9.7, the videos are not
played, just skipped.
I joined you the wine log.
The videos played well with Wine 1.7.12, is it a regression?
--
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=27325
Summary: after install wine delete program files...
Product: Wine
Version: 1.3.21
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gymka(a)mail.ru
Application finereader 10 professional, http://finereader.abbyy.com/
OS: archlinux
i install finereader 10 professional, not everything works ok, but for that
there is workaround; after install i start application and all program files
dissapears... with wine 1.3.19 everything worked ok, problems only with 1.3.20
and 1.3.21
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44076
Bug ID: 44076
Summary: LA NOIRESteam Version crash at startup
Product: Wine
Version: 2.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: legluondunet(a)free.fr
Distribution: ---
Created attachment 59792
--> https://bugs.winehq.org/attachment.cgi?id=59792
LA NOIRE Wine 2.21-staging terminal log
Hello,
I installed LA NOIRE Steam version, it crashed at start.
I joined you terminal log and backtrace.
nota: I installed Dotnet 3.5, directx9 and vcredist.
--
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=32336
Bug #: 32336
Summary: finereader 11 trial version install fails and
rollbacks
Product: Wine
Version: 1.5.18
Platform: x86
OS/Version: Linux
Status: NEW
Keywords: download, Installer
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fracting(a)gmail.com
Classification: Unclassified
Created attachment 42679
--> http://bugs.winehq.org/attachment.cgi?id=42679
Log: install ABBYY FineReader 11
We have a similar bug for ABBYY finereader 10: Bug 27325
However, +msi console log is different between ABBYY finereader 10 and ABBYY
finereader 11, I'm not sure if this bug is a duplication.
1. Download trial version from
http://download.abbyy.cn/dist/fr11/ABBYY_FineReader_11_Chinese.exe
2. run the outer installer, it will extract and run the inner installer
$ wine ABBYY_FineReader_11_Chinese.exe
3. click "安装 ABBYY FineReader 11" of the inner installer
4. the install wizard will ask you to install MSXML6, either install it or skip
it.
5. run the real ABBYY FineReader installer
There is something wrong and the installation will be rollback.
Here is a workaround:
1. run the outer installer and extract the inner installer
2. run the inner installer with DISABLEROLLBACK=1
$ msiexec /I ABBYY\ FineReader\ 11.msi TRANSFORMS="C:\Temp\ABBYY FineReader
11\2052.mst" /Liwrmo\!vepacu "C:\users\fracting\Temp\ABBYY FineReader 11.log"
LAUNCH_FROM_SETUP=1 DISABLEROLLBACK=1
--
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.
https://bugs.winehq.org/show_bug.cgi?id=46545
Bug ID: 46545
Summary: WINEPREFIX doesn't work when ends with "windows"
Product: Wine
Version: 4.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: paleozogt(a)gmail.com
Distribution: ---
Created attachment 63407
--> https://bugs.winehq.org/attachment.cgi?id=63407
wine default prefix
Setting WINEPREFIX to something that ends with "windows" (e.g., $HOME/windows)
causes wineboot to create a broken wine instance.
In particular, C:\ won't exist, for example:
> ~ wine cmd /C dir 'C:\'
> Volume in drive C has no label.
> Volume Serial Number is 0000-0000
>
> Directory of C:
>
> File not found.
whereas with the default prefix C:\ is fine:
> ~ wine cmd /C dir 'C:\'
> Volume in drive C has no label.
> Volume Serial Number is 0000-0000
>
> Directory of C:
>
> 1/28/2019 11:31 AM <DIR> Program Files
> 1/28/2019 11:31 AM <DIR> Program Files (x86)
> 1/28/2019 11:31 AM <DIR> ProgramData
> 1/28/2019 11:31 AM <DIR> users
> 1/28/2019 11:31 AM <DIR> windows
> 0 files 0 bytes
> 5 directories 90,299,498,496 bytes free
Setting WINEPREFIX to other values seems to work fine (e.g., $HOME/win). Why
is "windows" special? Are there any other special values that WINEPREFIX
shouldn't use?
See the attached console log for more details.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39807
Bug ID: 39807
Summary: Cannot install a programm
Product: Wine
Version: 1.7.55
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: msrom(a)mail.ru
Distribution: ---
Created attachment 53142
--> https://bugs.winehq.org/attachment.cgi?id=53142
log
Cannot install the ABBYY Aligner
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39224
Bug ID: 39224
Summary: Warcraft 3: Sound rustles without -opengl
Product: Wine
Version: 1.7.50
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: sworddragon2(a)aol.com
Distribution: ---
If Warcraft 3 is started without the -opengl option I'm hearing at the
startscreen besides the normal music a quiet rustle.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39570
Bug ID: 39570
Summary: Multiple application crash handlers fail to load
symbol information using 'dbghelp.SymLoadModule64',
reporting 'dbghelp:validate_addr64 Unsupported address
0xfffffffffxxxxxxx'
Product: Wine
Version: 1.7.54
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: dbghelp
Assignee: wine-bugs(a)winehq.org
Reporter: focht(a)gmx.net
Distribution: ---
Hello folks,
the issue/question was raised in
https://bugs.winehq.org/show_bug.cgi?id=32237#c15
--- quote ---
I did try 2012 this time and I end up crashing
fixme:dbghelp:validate_addr64 Unsupported address fffffffff33a0000
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr
0x7bc3db51
What's wrong with the address?
--- quote ---
Searching the Internet reveals this pattern/message many times - also in Wine
Bugzilla - but no or even incorrect explanation - until now ;-)
On 64-bit Linux machines, the Wine loader allows 32-bit dlls being mapped at
high >2GB, >3GB address ranges in 32-bit processes, not having certain (design)
restrictions of 32-bit process address space layout on 64-bit Windows machines
(even with /LARGEADDRESSWARE).
Good case, 32-bit Wine builtin dll mapped < 2 GiB virtual address space range:
--- snip ---
...
0009:Call PE DLL (proc=0x7e1b6838,module=0x7e1b0000
L"wsock32.dll",reason=PROCESS_ATTACH,res=0x1)
...
0027:Call dbghelp.SymLoadModule64(ffffffff,00000000,0b36a960
"C:\\windows\\system32\\wsock32.dll",0b36a988
"wsock32.dll",7e1b0000,00000000,0000e000) ret=005eff32
0027:trace:dbghelp:SymLoadModuleEx (0xffffffff (nil)
"C:\\windows\\system32\\wsock32.dll" "wsock32.dll" 7e1b0000 0000e000 (nil)
00000000)
...
0027:trace:dbghelp:SymLoadModuleExW (0xffffffff (nil)
L"C:\\windows\\system32\\wsock32.dll" L"wsock32.dll" 7e1b0000 0000e000 (nil)
00000000)
...
0027:trace:dbghelp:elf_load_file Processing elf file
'L"/home/focht/projects/wine/wine.repo/install/bin/../lib/wine/wsock32.dll.so"'
at 7e1a2000
...
0027:Ret dbghelp.SymLoadModule64() retval=7e1b0000 ret=005eff32
--- snip ---
Bad case, 32-bit Wine builtin dll mapped near end of 4 GiB virtual address
space range:
--- snip ---
...
0009:Call PE DLL (proc=0xf734e3fc,module=0xf72f0000
L"winex11.drv",reason=PROCESS_ATTACH,res=(nil))
...
0027:Call dbghelp.SymLoadModule64(ffffffff,00000000,0b36a960
"C:\\windows\\system32\\winex11.drv",0b36a988
"winex11.drv",f72f0000,ffffffff,00090000) ret=005eff32
0027:trace:dbghelp:SymLoadModuleEx (0xffffffff (nil)
"C:\\windows\\system32\\winex11.drv" "winex11.drv" fffffffff72f0000 00090000
(nil) 00000000)
"winex11.drv",ffffffff,2d053b40,0000000c) ret=edbc2fa6
...
0027:trace:dbghelp:SymLoadModuleExW (0xffffffff (nil)
L"C:\\windows\\system32\\winex11.drv" L"winex11.drv" fffffffff72f0000 00090000
(nil) 00000000)
0027:fixme:dbghelp:validate_addr64 Unsupported address fffffffff72f0000
...
0027:Ret dbghelp.SymLoadModule64() retval=00000000 ret=005eff32
--- snip ---
In this specific case, the game registered an own crash handler which dumps
various debugging information in case of a crash.
'dbghelp.SymLoadModule64' is called by the custom crash handler.
Source:
https://source.winehq.org/git/wine.git/blob/1fa7710ff92dd9555b2b4753e22ce5f…
--- snip ---
656 DWORD64 WINAPI SymLoadModule64(HANDLE hProcess, HANDLE hFile, PCSTR
ImageName,
657 PCSTR ModuleName, DWORD64 BaseOfDll, DWORD
SizeOfDll)
658 {
659 return SymLoadModuleEx(hProcess, hFile, ImageName, ModuleName,
BaseOfDll, SizeOfDll,
660 NULL, 0);
661 }
--- snip ---
So how does high DWORD of 'BaseOfDll' parameter get the 0xffffffff value?
A few caller frames up in the app crash handler:
--- snip ---
...
005F06D6 8B55 D0 MOV EDX,DWORD PTR SS:[EBP-30]
005F06D9 8B45 CC MOV EAX,DWORD PTR SS:[EBP-34]
005F06DC 8B4D F8 MOV ECX,DWORD PTR SS:[EBP-8]
005F06DF 52 PUSH EDX
005F06E0 99 CDQ
005F06E1 52 PUSH EDX ; high DWORD BaseOfDll
005F06E2 50 PUSH EAX ; low DWORD BaseOfDll
005F06E3 8B45 FC MOV EAX,DWORD PTR SS:[EBP-4]
005F06E6 50 PUSH EAX
005F06E7 51 PUSH ECX
005F06E8 8B4D E8 MOV ECX,DWORD PTR SS:[EBP-18]
005F06EB 56 PUSH ESI
005F06EC E8 EFF7FFFF CALL A_Slower.005EFEE0
...
--- snip ---
'winex11.drv' -> 0xf72f0000
Since the highest bit in low 32-bit 'BaseOfDll' DWORD is set, the 'CDQ'
instruction copies the sign (bit 31) of the value in the EAX register into
every bit position in the EDX register.
Voila - you get the 0xffffffff EDX value which is then propagated through the
caller chain as high 32-bit 'BaseOfDll' DWORD to 'dbghelp.SymLoadModule64',
leading to symbol load failure and fixme/warning messages.
This should be fixed, allowing symbol information even for dlls mapped in high
address range to be loaded.
$ wine --version
wine-1.7.54-261-g61c49bd
Regards
--
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.