https://bugs.winehq.org/show_bug.cgi?id=46935
Bug ID: 46935
Summary: AirDC++ (all versions) has display glitches.
Product: Wine
Version: 4.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: voidrc(a)gmail.com
Distribution: ---
Created attachment 64047
--> https://bugs.winehq.org/attachment.cgi?id=64047
browsing shares.
AirDC++ (all versions from 2014 until now, 32bit and 64) display graphical
glitches in the transfers area and the user share browsing. also some glitches
in the network config display as reported here
(https://bugs.winehq.org/show_bug.cgi?id=45744).
Browsing file shares does not refresh the whole display are when going into a
different folder. Whatever was shown previously remains on the screen unless
there's something to draw over it.
The black area in the transfers goes away if you resize it or if some file
transfers are initiated (it draws over it).
Basically all glitches related to incorrect rendering because of stale
graphical elements not being refreshed properly.
Tested with wine versions as old as 2.x and the bugs are still present.
https://github.com/airdcpp/airgit/releases/download/3.54/airdcpp_3.54_x64.7z
Please test and advise if any tweaking/custom configuration might help.
--
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=50665
Bug ID: 50665
Summary: Inconsistent behavior of kernel32.OutputDebugStringA/W
API with regards to Wine 'debugstr' and 'seh' debug
channel usage
Product: Wine
Version: 6.2
Hardware: x86-64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: focht(a)gmx.net
Distribution: ---
Hello folks,
before commit
https://source.winehq.org/git/wine.git/commitdiff/3b002685fe18ca3985af744d8…
("kernel32: Move debugger functions to kernelbase.") one could use 'debugstr'
channel facility for apps/drivers that make use of 'OutputDebugStringA/W' API
without all the other debug channels noise. Definitely helpful besides running
the app under a debugger or Sysinternal's 'DebugView' tool.
After that commit one had to use 'seh' debug channel and filter all the
unwanted messages to get a similar result.
With the fix for bug 48059 ("IMVU Social Network Client v539 hangs"), commit
https://source.winehq.org/git/wine.git/commitdiff/4ac3cbd6ccba52ad8d528ee74…
("kernel32: Duplicate OutputDebugStringA implementation.") to old 'debugstr'
debug channel got reintroduced again which leads to inconsistent behavior.
If the app calls 'OutputDebugStringA' - which only few do - one can still use
the old 'debugstr' channel but any 'OutputDebugStringW' calls won't be seen.
That's not very useful.
Either put 'OutputDebugStringA' into 'seh' debug channel or duplicate
'OutputDebugStringW' to kernel32.
$ wine --version
wine-6.2
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.
https://bugs.winehq.org/show_bug.cgi?id=48059
Bug ID: 48059
Summary: IMVU Social Network Client hangs
Product: Wine
Version: 4.19
Hardware: x86
URL: https://secure.imvu.com
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Regression SHA1: 3b002685fe18ca3985af744d8f147f29b2c588f0
Distribution: ---
There's clearly some nonsense going on with hooking. The game tries to call
kernel32.OutputDebugString(), which, instead of then executing Wine's
implementation, instead goes on to write the message to a file in the game's
directory, repeatedly, in a loop.
Reverting 3b002685f fixes this. Changing kernel32's spec file to forward to
kernelbase instead of using an import thunk also fixes this. What's confusing
me is I can't figure out how the hooking is actually done. Tracing the code of
OutputDebugString(), both A and W versions, both from kernel32 and kernelbase,
never seems to show signs of hooking, i.e. it's entirely identical to the
version on disk.
Note that the application requires an email-based account to be created.
--
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=7054
--- Comment #23 from joaopa <jeremielapuree(a)yahoo.fr> ---
Bug still occurs with wine-6.2.
--
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=49026
Bug ID: 49026
Summary: Topaz Video Enhance AI: video card support is not
detected.
Product: Wine
Version: 5.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: depositmail(a)mail.ru
Distribution: ---
Topaz Video Enhance AI: video card support is not detected.
--
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=44402
Bug ID: 44402
Summary: Shamela3.64 crashes when opening a book in (non-root)
user mode
Product: Wine
Version: 3.0-rc6
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: batou.dum(a)free.fr
Distribution: ---
Created attachment 60329
--> https://bugs.winehq.org/attachment.cgi?id=60329
The backtrace followed by a copy of the end of the terminal output
Shamela is an electronic arabic library which downloads packages, imports the
books which are in it and enable the user to read it and make plain-text
searches.
I use it with Linux 4.9.0-5-amd64 under Debian 6.3.0-18.
When I launch it with Wine as a non-root user, it downloads and imports the
books, but if I select a book to read it crashes. I attached the backtrace with
the end of the terminal output. Sometimes it doesn't do anything when I select
the book, but if I try again it crashes.
(It does run well with Wine when I execute it as root, yet it doesn't seems to
me a good idea to do it.)
If you want to install the program, you can download it at :
http://d.shamela.ws/downloads/shamela3.64.rar
Then simply uncompress it and run wine ~/shamela3.64/_shamela.exe.
(If you want a correct arabic display, you can use this tutorial :
https://abuhirr.wordpress.com/2013/12/20/syamilah/. GoogleTranslate from
Indonesian to English works quite fine ! But I don't think it necessary if you
don't read Arabic.)
Look here for the meaning of the icons :
http://uloom.com/edu/mod/page/view.php?id=151.
Normally, when opening the program will open a small window. Click on the right
button. If it doesn't, click on the "upgrade" button (first on the left in the
most recent versions).
Then unselect all the directories (it will take a few seconds if you do it by
unselecting the parent directory), open the first directory, select the first
book and press the right button in the bottom-right corner. When the next
question appears, click on the left button.
When the download ends, wait a little and click on the "Select book" icon
(first on the right). Open the first directory and double-click on the book. If
you are not in root, a window should appear informing you about the error.
Click on the right button in the bottom-left corner to see the backtrace, and
again on the right button to save it.
--
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=50284
Bug ID: 50284
Summary: FSCTL_GET_REPARSE_POINT doesn't contain any target for
a symbolic link
Product: Wine-staging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: martin(a)martin.st
CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com,
z.figura12(a)gmail.com
Distribution: ---
Created attachment 68841
--> https://bugs.winehq.org/attachment.cgi?id=68841
Test program
https://github.com/wine-staging/wine-staging/blob/fce121fcd95380ca56c9d027b…
does contain some support for reading relative symlinks, but it doesn't seem to
work currently; the SubstituteNameLength and PrintNameLength fields of
SymbolicLinkReparseBuffer are zero after a call to
DeviceIoControl(FSCTL_GET_REPARSE_POINT), see the attached test program.
--
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=50303
Bug ID: 50303
Summary: MSI package installation fails in wine-staging
Product: Wine-staging
Version: 6.0-rc1
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 68874
--> https://bugs.winehq.org/attachment.cgi?id=68874
terminal output during prefix creation (Wine-Mono fails to install)
This may be related to bug #50036.
The problem is present in Staging since
https://github.com/wine-staging/wine-staging/commit/f9e86098b3136869479621e…
For example when you create a new prefix, the Wine-Mono package fails to
install.
The same failure occurs when I try to install Nvidia Physx via winetricks.
Works properly with the previous staging commit:
https://github.com/wine-staging/wine-staging/commit/023588ac34c3314d18f4ebb…
--
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=50036
Bug ID: 50036
Summary: Remaining issues in Bugs in ntdll-Junction_Points in
staging
Product: Wine-staging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: martin(a)martin.st
CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com,
z.figura12(a)gmail.com
Distribution: ---
Created attachment 68477
--> https://bugs.winehq.org/attachment.cgi?id=68477
Test code for showing the issue
With the ntdll-Junction_Points, there's a few remaining issues that are
unimplemented:
- When opening a symbolic link with CreateFile(), it doesn't take the
FILE_FLAG_OPEN_REPARSE_POINT flag into account. E.g. if the symlink points at a
nonexistent file, if the link is opened with CreateFile() with the
FILE_FLAG_OPEN_REPARSE_POINT flag set, the operation should succeed (inspecting
the link), but without the flag, it should fail (as the link points at a
nonexistent file). Currently, it succeeds in both cases.
- If inspecting the handle opened with CreateFile() with
GetFileInformationByHandleEx(FileAttributeTagInfo), the ReparseTag field is
left zero.
This can be tested with the attached test app. On real windows, it prints
something like this:
CreateFile(FILE_FLAG_OPEN_REPARSE_POINT) = 0000000000000094
ReparseTag = a000000c
CreateFile(0) = FFFFFFFFFFFFFFFF
While on wine with the ntdll-Junction_Points patchset applied, it prints:
CreateFile(FILE_FLAG_OPEN_REPARSE_POINT) = 000000000000003C
ReparseTag = 0
CreateFile(0) = 000000000000003C
ReparseTag = 0
--
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=50283
Bug ID: 50283
Summary: FILE_OPEN_REPARSE_POINT breaks error reporting for
deletes of directories
Product: Wine-staging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: martin(a)martin.st
CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com,
z.figura12(a)gmail.com
Distribution: ---
Created attachment 68840
--> https://bugs.winehq.org/attachment.cgi?id=68840
Test program
In order to generically delete a file system entry, regardless of whether it is
a regular file, symlink or directory, one can open a handle to it and delete it
with a call to SetFileInformationByHandle(FileDispositionInfo). By opening the
handle with FILE_FLAG_OPEN_REPARSE_POINT, a potential symlink gets handled by
removing the symlink itself, not the target file it points to.
If a handle opened with the FILE_FLAG_OPEN_REPARSE_POINT flag set turns out to
be a directory, error reporting for the SetFileInformationByHandle call fails.
This is caused by [1] in combination with [2]. These two cases make O_SYMLINK,
which includes O_PATH, be added when opening the file descriptor which turns
out to be a directory. The O_PATH flag causes the later fdopendir() and
readdir() to not return anything, causing is_dir_empty [3] to indicate that the
directory is empty and removal will succeed, even though it doesn't.
This triggers errors in a std::filesystem testcase in libc++ [4], when checking
to make sure that attempts to remove a non-empty directory properly signals
errors.
[1]
https://github.com/wine-staging/wine-staging/blob/fce121fcd95380ca56c9d027b…
[2]
https://github.com/wine-staging/wine-staging/blob/fce121fcd95380ca56c9d027b…
[3]
https://source.winehq.org/git/wine.git/blob/fac1e40aaf0726a3e328a922cb49692…
[4]
https://github.com/llvm/llvm-project/blob/1e260f955d3123351fc68de8c2dde02b1…
The issue can be reproduced with the attached fairly minimal test program.
--
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.