https://bugs.winehq.org/show_bug.cgi?id=46699
Bug ID: 46699
Summary: total commander cursor color
Product: Wine
Version: 4.0-rc7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: andrej8anubis(a)gmail.com
Distribution: ---
Hello, I have a red cursor in total commander, when I am not at the top of the
window, and I open a new tab with "ctrl + t", I have two cursors, one at the
top, and another on the previous position. But the correct one is the one at
the top. When I click down button, only the the one in the second column is
seen as it should be. Can someone reproduce that? Thank you
--
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=46698
Bug ID: 46698
Summary: delete a file name in tabs
Product: Wine
Version: 4.0-rc7
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: andrej8anubis(a)gmail.com
Distribution: ---
A name of the map in the tab of total commander is not shown correctly. It is
only shown correctly if it is in the beginning of the window, but if it is in
the middle or at the end, the name overlaps with the left tabs. The name of the
map is long.
Can someone reproduce that?
--
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=21966
Summary: Total Commander: Application freezes when queue-ing
file copy operations
Product: Wine
Version: 1.1.40
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: alexandru.balut(a)gmail.com
Total Commander 7.50a
- Press F5 to copy a (large) file and press F2 to queue the operation,
- Notice problem 1: The window that pops up, showing the queued operations, is
frozen. Thus, it does not show the progress.
- While TC is still copying the file, press F5 to copy a different file and
press F2 to queue the operation.
- Notice problem 2: The main TC window is frozen. After the file copy
operations are finished, the application is again responsive.
--
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=41992
Bug ID: 41992
Summary: total commander, copy dialog - Esc key not working
Product: Wine
Version: 1.9.23
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: andrej8anubis(a)gmail.com
Distribution: ---
Created attachment 56411
--> https://bugs.winehq.org/attachment.cgi?id=56411
copy dialog box at it appears
I am using:
total commander 9.0a 64 bit
linuxmint 18 64 bit
"wine 1.9.23" as shown from : "apt policy wine-staging*"
-->>
wine-staging:
Installed: 1.9.23~ubuntu16.04.1
Candidate: 1.9.23~ubuntu16.04.1
Version table:
*** 1.9.23~ubuntu16.04.1 500
500 http://ppa.launchpad.net/wine/wine-builds/ubuntu xenial/main amd64
Packages
100 /var/lib/dpkg/status
wine-staging-amd64:
Installed: 1.9.23~ubuntu16.04.1
Candidate: 1.9.23~ubuntu16.04.1
Version table:
*** 1.9.23~ubuntu16.04.1 500
500 http://ppa.launchpad.net/wine/wine-builds/ubuntu xenial/main amd64
Packages
100 /var/lib/dpkg/status
<<--
test1 - works fine
==================
- pres F8 for delete a file
- a dialog box appear, asking "do you really want to delete..."
- pres Esc
- the dialog box disappears as it should, as it does in windows. Great
test2 - does not work
==================
- pres F5 for copy file
- a dialog box appears offering me options for how to copy
- pres Esc, the dialog box does not disappear as it does in windows, I am
guessing the problem in wine is, because the cursor is in the text box,where I
can make input from keyboard. But in windows works fine. But...
- ...but if I press Tab two times, so the "cursor" is located on plus (+)
button in copy dialog box, as it is the case in test1, where the "cursor" is
located on the button "yes", and then press Esc key on keyboard, the dialog box
disappears as in windows also for copy dialog box .
The point here is, that if the "cursor" is located on the button, the Esc key
works fine in bothe tests
--
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=48141
Bug ID: 48141
Summary: Total Commander: launching of native linux commands
for file associations is broken
Product: Wine
Version: 4.20
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: felix.huber(a)schyf.de
Distribution: ---
Created attachment 65745
--> https://bugs.winehq.org/attachment.cgi?id=65745
Console log of failure to start native linux application
When making an internal association by using a script with the line:
/usr/bin/xdg-open "`wine winepath -u "$1"`"
the launch of the native application creates errors like this:
Configuration file "//.config/kde-open5rc" not writable. Please contact your
system administrator.
and the list of possible applications is empty. It looks like the home path is
missing and thus the root folder is used, which is denied. I could bisect the
problem to this:
commit eee3a4e84a07c50c65c3a7619247f62dbca826b6
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Tue Nov 12 21:48:49 2019 +0100
kernel32: Move support for starting Unix processes to ntdll.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
:040000 040000 72a0a42afdb9b51f77bf482c49429a79d59d9b18
b61e932c3248669edaafbc2f184ebb59a9ea53d2 M dlls
Also, there are error messages on the console that Total Commander cannot get
the home directory. This might be the result of a denied read access for
L"\\??\\z:\\", see attached error log.
--
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=46274
Bug ID: 46274
Summary: Total Commander 8.52a: Closing the Multi-Rename window
after using it is slow and messes up the listbox caret
Product: Wine
Version: 4.0-rc1
Hardware: x86
URL: http://web.archive.org/web/20160121065109/http://totalcmd2.s3.amazonaws.com/tcmd852ax32.exe
OS: Linux
Status: ASSIGNED
Severity: normal
Priority: P2
Component: user32
Assignee: gabrielopcode(a)gmail.com
Reporter: gabrielopcode(a)gmail.com
CC: wine-bugs(a)winehq.org
Distribution: ---
1) Launch Total Commander and press CTRL+M or go to Files->Multi Rename Tool...
2) Press "Start!" which should work fine.
3) Now close the Multi-Rename window (i.e. click on Close or press ESC)
Observe how there's a few seconds of freeze lag, after which the listbox caret
in the panel is gone. Switching to the other panel and back brings it back.
I did a few investigations and it seems this is not a problem with the listbox
at all. Rather, it's a problem with recursive SetFocus and window activation,
that's why it's so slow (until it reaches a limit). I'll try to fix it like on
Windows so I'll have to see how Windows handles this situation (with testcases
of course).
It's interesting to note that this does not happen if you don't click on
"Start!" in the Multi-Rename Tool.
--
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=46669
Bug ID: 46669
Summary: delete a file in total commander mounted disk
Product: Wine
Version: 4.0-rc7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: andrej8anubis(a)gmail.com
Distribution: ---
I have linux mint and permanently mounted drive. When I delete a file in total
commander from this drive, it does not show in Trash in nemo. If I delete a
file in total commander in my home folder, the file does show in trash as
expected.
Am I doing something wrong? Thank you
--
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=46527
Bug ID: 46527
Summary: delete a file in total commander
Product: Wine
Version: 4.0-rc7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: andrej8anubis(a)gmail.com
Distribution: ---
I have up to date linux mint 19.1 cinnamon and winehq-devel 4.0~rc7~bionic,
both great, I like it...
but, when I delete a file in file manager nemo it gets into the trash. When I
delete a file in total commander, a file is not to be found in the trash. Is
this a bug? Thank you
--
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=30329
Bug #: 30329
Summary: Total Commander 8.0 64-bits beta installer crashes due
to pointer truncation (image base address > 4 GiB)
Product: Wine
Version: 1.5.1
Platform: x86-64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello,
the extracted installer "INSTALL.EXE" (64 bits PE binary) can be run alone from
"wc0" temp folder.
The installer tries to fill a list box with language strings.
--- snip ---
0026:Starting process L"Z:\\home\\focht\\Downloads\\wc0\\INSTALL.EXE"
(entryproc=0x14000cca0)
...
0026:Call KERNEL32.GetPrivateProfileStringA(140019788 "languages",0022dc90
"18",140019786 "",0022dcf0,00000103,1400226c0
"Z:\\home\\focht\\Downloads\\wc0\\INSTALL.inf") ret=140001c0d
0026:Ret KERNEL32.GetPrivateProfileStringA() retval=00000013 ret=140001c0d
0026:Call KERNEL32.GetLastError() ret=14000e5c0
0026:Ret KERNEL32.GetLastError() retval=00000000 ret=14000e5c0
0026:Call KERNEL32.GetLastError() ret=14000e5c0
0026:Ret KERNEL32.GetLastError() retval=00000000 ret=14000e5c0
0026:Call
user32.SendDlgItemMessageA(0001007e,00000064,00000180,00000000,0022dcf0)
ret=140001cd1
0026:Call window proc 0x7f45d4b788ef
(hwnd=0x10086,msg=LB_ADDSTRING,wp=00000000,lp=0022dcf0)
0026:Ret window proc 0x7f45d4b788ef
(hwnd=0x10086,msg=LB_ADDSTRING,wp=00000000,lp=0022dcf0) retval=00000011
0026:Ret user32.SendDlgItemMessageA() retval=00000011 ret=140001cd1
0026:Call user32.GetDlgItem(0001007e,00000004) ret=140001cfb
0026:Ret user32.GetDlgItem() retval=0001008a ret=140001cfb
0026:Call user32.ShowWindow(0001008a,00000000) ret=140001d06
0026:Call window proc 0x7f45d4b78593
(hwnd=0x1008a,msg=WM_SHOWWINDOW,wp=00000000,lp=00000000)
0026:Ret window proc 0x7f45d4b78593
(hwnd=0x1008a,msg=WM_SHOWWINDOW,wp=00000000,lp=00000000) retval=00000000
0026:Ret user32.ShowWindow() retval=00000001 ret=140001d06
0026:Call
user32.SendDlgItemMessageA(0001007e,00000064,00000181,00000012,40019670)
ret=140001d30
0026:Call window proc 0x7f45d4b788ef
(hwnd=0x10086,msg=LB_INSERTSTRING,wp=00000012,lp=40019670)
0026:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7b8633f9
ip=7b8633f9 tid=0026
0026:trace:seh:raise_exception info[0]=0000000000000000
0026:trace:seh:raise_exception info[1]=0000000040019670
0026:trace:seh:raise_exception rax=0000000000000000 rbx=0000000000000026
rcx=ffffffffffffffff rdx=0000000040019670
0026:trace:seh:raise_exception rsi=0000000000000181 rdi=0000000040019670
rbp=000000000022d2d0 rsp=000000000022d1a0
0026:trace:seh:raise_exception r8=0000000040019670 r9=00000000ffffffff
r10=0000000000000008 r11=000000399ab7c680
0026:trace:seh:raise_exception r12=000000000001f0ac r13=00000001400226c0
r14=0000000000000000 r15=00000001400226c0
--- snip ---
The reason for the crash is a 32 bit pointer truncation -> application bug.
Most likely the original code was Win32 and had been ported to Win64 with some
casts still in there.
(annotated)
--- snip ---
.text:0000000140001D0D movsxd rax, cs:dword_14001F030
.text:0000000140001D14 movsxd r9, r11d ; wParam
.text:0000000140001D17 mov edx, 64h ; nIDDlgItem
.text:0000000140001D1C mov r8d, 181h ; Msg, LB_INSERTSTRING
.text:0000000140001D22 mov rcx, rdi ; hDlg
.text:0000000140001D25 mov [rsp+20h], rax
.text:0000000140001D2A call cs:SendDlgItemMessageA
--- snip ---
The data reference (I only decoded the 32 bits part to show the 32 bit access):
--- snip ---
.data:000000014001F030 dword_14001F030 dd 40019670h
.data:000000014001F034 db 1
.data:000000014001F035 db 0
.data:000000014001F036 db 0
.data:000000014001F037 db 0
--- snip ---
Page fault address: 0000000040019670
If referenced as 64 bits -> 0x140019670 it would be correct:
--- snip ---
.rdata:0000000140019670 db 4Fh ; O
.rdata:0000000140019671 db 74h ; t
.rdata:0000000140019672 db 68h ; h
.rdata:0000000140019673 db 65h ; e
.rdata:0000000140019674 db 72h ; r
.rdata:0000000140019675 db 20h
...
--- snip ---
Using "dumpbin" tool from Visual Studio/Express/SDK on executable gives:
--- snip ---
Dump of file INSTALL.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (x64)
5 number of sections
4EE124C5 time date stamp Thu Dec 08 21:57:41 2011
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
23 characteristics
Relocations stripped
Executable
Application can handle large (>2GB) addresses
OPTIONAL HEADER VALUES
20B magic # (PE32+)
8.00 linker version
17800 size of code
D800 size of initialized data
0 size of uninitialized data
CCA0 entry point (000000014000CCA0)
1000 base of code
140000000 image base (0000000140000000 to 0000000140028FFF)
1000 section alignment
200 file alignment
4.00 operating system version
0.00 image version
5.02 subsystem version
0 Win32 version
29000 size of image
400 size of headers
303B3 checksum
2 subsystem (Windows GUI)
8000 DLL characteristics
Terminal Server Aware
100000 size of stack reserve
1000 size of stack commit
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
0 [ 0] RVA [size] of Export Directory
1D7D8 [ 64] RVA [size] of Import Directory
26000 [ 23F8] RVA [size] of Resource Directory
24000 [ 10F8] RVA [size] of Exception Directory
22400 [ 1780] RVA [size] of Certificates Directory
0 [ 0] RVA [size] of Base Relocation Directory
0 [ 0] RVA [size] of Debug Directory
0 [ 0] RVA [size] of Architecture Directory
0 [ 0] RVA [size] of Global Pointer Directory
0 [ 0] RVA [size] of Thread Storage Directory
0 [ 0] RVA [size] of Load Configuration Directory
0 [ 0] RVA [size] of Bound Import Directory
19000 [ 5E8] RVA [size] of Import Address Table Directory
0 [ 0] RVA [size] of Delay Import Directory
0 [ 0] RVA [size] of COM Descriptor Directory
0 [ 0] RVA [size] of Reserved Directory
--- snip ---
Section headers:
--- snip ---
SECTION HEADER #1
.text name
176BE virtual size
1000 virtual address (0000000140001000 to 00000001400186BD)
17800 size of raw data
400 file pointer to raw data (00000400 to 00017BFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
Execute Read
SECTION HEADER #2
.rdata name
5B1C virtual size
19000 virtual address (0000000140019000 to 000000014001EB1B)
5C00 size of raw data
17C00 file pointer to raw data (00017C00 to 0001D7FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
Read Only
Section contains the following imports:
KERNEL32.dll
1400190D8 Import Address Table
14001D918 Import Name Table
0 time date stamp
0 Index of first forwarder reference
...
SECTION HEADER #3
.data name
4478 virtual size
1F000 virtual address (000000014001F000 to 0000000140023477)
1600 size of raw data
1D800 file pointer to raw data (0001D800 to 0001EDFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
Initialized Data
Read Write
...
SECTION HEADER #4
.pdata name
10F8 virtual size
24000 virtual address (0000000140024000 to 00000001400250F7)
1200 size of raw data
1EE00 file pointer to raw data (0001EE00 to 0001FFFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
Read Only
...
SECTION HEADER #5
.rsrc name
23F8 virtual size
26000 virtual address (0000000140026000 to 00000001400283F7)
2400 size of raw data
20000 file pointer to raw data (00020000 to 000223FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
Read Only
--- snip ---
The image load base of 0x0000000140000000 (>4 GiB address space) is probably to
catch such 32 vs. 64 bits porting errors.
When pointers are stored as 32 bits they would truncate hence triggering page
fault as seen here.
I've looked into the Total Commander forum
(http://www.ghisler.ch/board/index.php?language=english) but didn't find any
bug reports about installer crashing on Win64 so I assume this installer
somehow runs despite the bug.
Would be nice if someone with Win64 could verify this.
Maybe the loader does something different on Win64?
Even if the bug is invalid it's probably good to have one bug to collect such
misbehaving apps. I suspect there are more apps out there.
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.