https://bugs.winehq.org/show_bug.cgi?id=54604
Bug ID: 54604
Summary: improved file browser
Product: Wine-staging
Version: 8.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: gizmo_1979(a)yahoo.it
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 74135
--> https://bugs.winehq.org/attachment.cgi?id=74135
file browser
it would be handy if the completion of the names if you type in the file name
field was implemented in the file open window called by the programs as it
happens in any system more modern than windows 95...
--
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=54620
Bug ID: 54620
Summary: advapi32:registry causes mshtml:htmldoc to time out
when run without elevated privileges on Windows 8
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: mshtml
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
advapi32:registry causes mshtml:htmldoc to time out when run without elevated
privileges on Windows 8:
htmldoc.c:6220: put_href L"about:replace"...
htmldoc.c:6503: open...
htmldoc.c:6503: open...
mshtml:htmldoc:0744 done (258) in 120s 899B
See https://test.winehq.org/data/patterns.html#mshtml:htmldoc
This timeout does not happen when running mshtml:htmldoc on its own. I
determined that the source of interference is advapi32:registry and that the
timeout is caused by a UAC prompt:
A website wants to open web content using this
program on your computer.
This program will open outside of Protected mode. Internet Explorer's
Protected mode helps protect your computer. If you do not trust this
website, do not open this program.
Name: Microsoft Edge
Publisher: Microsoft Corporation
This happens in the IHTMLWindow2_open() call in test_open_window() in
htmldoc.c:
hres = IHTMLWindow2_open(window, url, name, NULL, VARIANT_FALSE,
&new_window);
So this issue is very similar to the ieframe:ie one described in bug 54613.
--
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=15480
Summary: Saving files in Word/Excel creates useless .lnk files
Product: Wine
Version: 1.1.5
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: andrew(a)etc.gen.nz
Hi,
In Word and Excel 2003 when we save files then a .lnk file is created in the
same directory as the source file. These files are useless for two reasons:
1) They're in the same directory as the original .doc or .xls files which have
Word and Excel associated with them respectively.
2) On a standard Debian Lenny machine running Gnome the .lnk files aren't
recognised by any apps and won't cause Word or Excel to run.
I've searched around the place to see if we can turn this "feature" off, but
haven't found anything. Is this possible? If not, could this please be added.
--
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=53847
Bug ID: 53847
Summary: NfRemote: mouse input ignored
Product: Wine
Version: 7.0
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: thelen(a)radiomankato.com
https://www.telosalliance.com/uploads/Omnia%20Products/Software/NfRemote.exe
Say hello to nfremote. It's a little piece of software used to administer a
particular manufacturer's equipment, commonly used at radio and TV stations.
I can confirm it has, and does, work fine under Wine 2.21 - just tested today
on a MacBookPro8,1 running the official binaries
(https://dl.winehq.org/wine-builds/macosx/pool/winehq-staging-2.21.pkg) under
OS 10.13.6.
Meanwhile, I have a new Mac (MacBookPro16,2 - Intel-based), on which I’ve
deployed Wine 7.0 via homebrew under OS 12.6.1.
There I can start nfremote just fine... but it ignores my mouse input.
If I were to start it with the command-line argument "run", it presents me with
a window where both keyboard and mouse input are accepted; there I can type in
the text fields, so I know it's responsive. But when I hover the cursor over
buttons, they do not 'light up’ to indicate such. And when I click, nothing
happens.
Even in years past, I found that newer versions of Wine exhibited the issue I
describe below, so I simply never updated beyond 2.21. Wonder if this might be
a long-undiscovered regression of some sort?
--
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=54141
Bug ID: 54141
Summary: console: pressing ctrl+4 in any console application
terminates it
Product: Wine
Version: 7.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: taviso(a)gmail.com
Distribution: ---
Reproduce:
$ wine cmd.exe
Z:\home\taviso>
[Now press Ctrl+4]
I think all of the Ctrl+Number keys don't work (oddly, except Ctrl+2), but
Ctrl+4 is especially annoying because it immediately terminates the
application.
I was trying to use a Windows console application, but didn't have much luck
because of the missing keybindings.
--
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=53501
Bug ID: 53501
Summary: Test Drive Unlimited not working
Product: Wine
Version: 7.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ds000001(a)outlook.de
Distribution: ---
Created attachment 72860
--> https://bugs.winehq.org/attachment.cgi?id=72860
Lutris and Wine
Hello,
I try to run Test Drive Unlimited DVD 1.66 version with Wine.
My system:
CPU: 3700X
GPU: 6700XT
RAM: 32 GB
Wine: 7.15 installed through pacman and using Lutris 0.5.10.1-2 for easier
management of all WINEPREFIX's
WINEPREFIX:
- 32 Bit and complete new
- Through winecfg set as Win XP
- No additional packages installed
- ESync, Fsync and DXVK not enabled
- Virtual window mode enabled with 1080p resolution, that way it is easier for
me to see, if something happens or not
- no additional modules installed with Winetricks
If I try to start the game, the configured Wine desktop appears, the disc drive
starts to spin and after that nothing happens.
Output from "lutris -d" and enabled diagnostics for the WINEPREFIX gave me the
output from
tdudebug1.txt.
Enabled debug with "WINEDEBUG=warn+all" and tried to start the game through the
wine command. Got the log tdudebug2.txt out of this.
Any ideas what I am doing wrong?
--
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=9221
Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |leslie_alistair(a)hotmail.com
--
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=54562
Bug ID: 54562
Summary: The 64-bit oleaut32:usrmarshal crashes in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: oleaut32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The 64-bit oleaut32:usrmarshal crashes in Wine:
usrmarshal.c:572: Test marked todo: Unexpected refcount 4
Unhandled exception: page fault on read access to 0xffffffffffffffff in 64-bit
code (0x00000062138b51).
[...]
Backtrace:
=>0 0x00000062138b51 LPSAFEARRAY_UserUnmarshal+0xa1(pFlags=00000000009AFA10,
Buffer=0000000000ABA614, ppsa=0000000000AE24A0)
[Z:\home\winetest\tools\testbot\var\wine\dlls\oleaut32\usrmarshal.c:1073] in
oleaut32 (0x00000000000014)
1 0x000000621394c4 VARIANT_UserUnmarshal+0x454(pFlags=00000000009AFA10,
Buffer=0000000000ABA5D0, pvar=<internal error>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\oleaut32\usrmarshal.c:575] in
oleaut32 (0x000000009af9b0)
2 0x0000000044f9e0 in oleaut32_test (+0x4f9e0) (0x000000009af928)
3 0x0000000045110b in oleaut32_test (+0x5110b) (0x00000000ab44b5)
4 0x0000000050d92b in oleaut32_test (+0x10d92b) (0x00000000ab44b5)
5 0x0000000050d187 in oleaut32_test (+0x10d187) (0000000000000000)
6 0x0000007b6293d9 BaseThreadInitThunk+0x9(unknown=<internal error>,
entry=<internal error>, arg=<internal error>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\kernel32\thread.c:61] in kernel32
(0000000000000000)
7 0x00000170061143 __wine_pop_frame(entry=000000000050D120,
arg=00000000003F0000)
[Z:\home\winetest\tools\testbot\var\wine\include\wine\exception.h:277] in ntdll
(0000000000000000)
8 0x00000170061143 RtlUserThreadStart+0x83(entry=[<register RSP not
accessible in this frame>, arg=[<register RSP not accessible in this frame>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\ntdll\thread.c:295] in ntdll
(0000000000000000)
0x00000062138b51 LPSAFEARRAY_UserUnmarshal+0xa1
[Z:\home\winetest\tools\testbot\var\wine\dlls\oleaut32\usrmarshal.c:1073] in
oleaut32: cmpw (%rcx),%ax
1073 if(*ppsa && (*ppsa)->cDims==wiresa->cDims)
See https://test.winehq.org/data/patterns.html#oleaut32:usrmarshal
A bisect shows that this crash started with the commit below:
commit 27665f35e4da13bac1e4dd8948a65f484c9dadfa
Author: Rémi Bernon <rbernon(a)codeweavers.com>
Date: Sat Feb 11 09:43:30 2023 +0100
ntdll: Implement Low Fragmentation Heap frontend.
This implements the reduced fragmentation from the heap frontend, by
carving smaller blocks out of larger allocated blocks.
The super block and each sub-block are all flagged with BLOCK_FLAG_LFH.
The super-block (struct group) uses a standard struct block header, as
well as a list entry to be linked in free list, and a free bit map to
track free sub-blocks.
Sub-blocks reference their super block through the base_offset, instead
of the subheap, using the block size as radix.
--
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=54149
Bug ID: 54149
Summary: shlwapi:ordinal - test_SHFormatDateTimeA() fails on
the mixed locales configuration
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: shlwapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
test_SHFormatDateTimeA() fails on the mixed locales configuration:
ordinal.c:1765: Test failed: expected (mercredi 14 décembre 2022), got
(mercredi 14 decembre 2022)
ordinal.c:1773: Test failed: expected (mercredi 14 décembre 2022), got
(mercredi 14 decembre 2022)
ordinal.c:1787: Test failed: expected (mercredi 14 décembre 2022) got (mercredi
14 decembre 2022) for date part
ordinal.c:1801: Test failed: expected (mercredi 14 décembre 2022) got (mercredi
14 decembre 2022) for date part
See https://test.winehq.org/data/patterns.html#shlwapi:ordinal
All was fine until 2022-12-09. Then on the 11th I let the TestBot rebuild the
snapshot [1] to ensure that Internet time synchronization would be disabled to
fix random failures in other tests. And on the 12th this test started failing:
the date lost its e-acute!
Yet the WineTest system information shows that none of the locale settings
changed, not even the code page. Before and after they are:
SystemDefaultLCID 0411
UserDefaultLCID 040c
ThreadLocale 0411
SystemPreferredUILanguages 0412,0409
UserDefaultUILanguage 0412
ThreadUILanguage 0412
Country 231
ACP 932
The test did not change and the binary from the 9th has the same failure. So it
is some obscure Windows setting that changed for some unknown reason.
Furthermore given that the code page is 932 I would expect the plain 'e' to be
the more correct result. Unfortunately there is no record of what the result
was before the test started failing. Is it possible for SHFormatDateTimeA() and
GetDateFormatA() to use different code pages?
[1] It goes like this: that VM has a 'langs' powered-off snapshot with all the
locales installed. This snapshot has not changed since 2022-04-24. From this
the TestBot produces the 'langs-mx-MX-live' live snapshot using LibvirtTool.pl
and SetWinLocale to change the locale settings.
--
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=45756
Bug ID: 45756
Summary: Button not clickable when dpi setting changed in
Office 2007 Installer
Product: Wine
Version: 3.15
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: ulrich.gemkow(a)ikr.uni-stuttgart.de
Distribution: ---
After upgrading from wine 3.14 to wine 3.15 (self-compiled, 32-bit-only) the
push buttons in the office 2007 installer are no longer "clickable".
When pushing them with the mouse, nothing happens. Using the keyboard to "push"
the buttons works as before. Sometimes the mouse pointer is not even visible
inside the installer window.
This only happens when changing the screen resolution in winecfg (i.e. to 168
dpi). The windows version is set to Windows XP
A bisect shows this commit as the first bad commit:
commit 2068b73db5e19e1ce3b54b2a8ecb5a5b99ea19b5
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Mon Aug 27 14:02:43 2018 +0200
user32: Process hardware messages in physical coordinates.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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.