https://bugs.winehq.org/show_bug.cgi?id=54345
Bug ID: 54345
Summary: CJK glyphs are not displayed in notepad.exe by default
Product: Wine
Version: 8.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nekotekina(a)gmail.com
Distribution: ---
Created attachment 73918
--> https://bugs.winehq.org/attachment.cgi?id=73918
Screenshot of broken Japanese text in notepad.exe
Hello, I've installed wine-staging (over wine-stable) and I noticed I'm no
longer able to open Japanese text files with notepad.exe using locale override
LANG=ja_JP.UTF-8
Squares appear instead of Japanese glyphs. I tested with empty wine prefix. I'm
attaching a screenshot of the following text file:
たこ焼き
てすと
test
한국어
æ
I also noticed similar problem in the edit fields of another program.
Expected behaviour:
Default "System" font should display all these characters in one way or
another.
Workaround:
Change font in notepad.exe to one explicitly containing Japanese characters.
--
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=54343
Bug ID: 54343
Summary: USB Device Not Recognized 64-bit Stack Overflow Looks
related
Product: Wine
Version: 7.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: dave.connett(a)gmail.com
Distribution: ---
Created attachment 73913
--> https://bugs.winehq.org/attachment.cgi?id=73913
Backtrace of the stack overflow.
Hello,
Use Case: I am using Joysticks for some of my games. They are detected by the
games, but trying to calibrate, change the configuration, or flash the firmware
with the vendor's software I am getting an unhandled exception with a stack
overflow error in the kernelbase.dll module. The vendor executable can be found
at the following link:
https://support.virpil.com/en/support/solutions/47000010107
I have attached two separate backtraces of the error to this report as well as
a screenshot detailing the resulting missing connections. I would appreciate
any assistance in resolving this issue.
Steps to reproduce:
Install the vendor's software for joystick configuration suite in Wine.
Running the software immediately triggers the stack overflow.
Connect the joystick to the computer.
Attempt to use the software to configure, calibrate, or flash the firmware.
No Joysticks detected in software. (Though launching a separate executable
from the main instance does seem to detect them, screenshot attached)
Expected Result: The software should successfully detect and configure the
device or flash the firmware.
Actual Result: An unhandled exception with a stack overflow error in the
kernelbase.dll module is encountered.
I am using Wine version: 7.22.
Operating System: Arch Linux 6.1.6-arch1-3.
Thank you for your help.
Sincerely,
Dave
--
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=40569
Bug ID: 40569
Summary: application crashes with exception in
ddraw_allocate_handle (win98)
Product: Wine
Version: 1.9.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: o.dierick(a)piezo-forte.be
Distribution: ---
Created attachment 54407
--> https://bugs.winehq.org/attachment.cgi?id=54407
Terminal output (wine 1.9.9)
I get a page fault in 32-bit code when starting a game in TOCA Touring Car
Championship. This is an old game that requires windows version <= win98.
The demo also has the bug.
---begin quote---
...
wine: Unhandled page fault on read access to 0x00000110 at address 0x7e7fcf1d
(thread 0028), starting debugger...
Unhandled exception: page fault on read access to 0x00000110 in 32-bit code
(0x7e7fcf1d).
...
Backtrace:
=>0 0x7e7fcf1d ddraw_allocate_handle+0x1d(t=0x10c, object=0x15f960,
type=DDRAW_HANDLE_MATERIAL)
[/home/olivier/Projets/wine-builds/1.9.9_x86/dlls/ddraw/../../../wine-git/dlls/ddraw/main.c:118]
in ddraw (0x0033f478)
...
---end quote---
This is with git wine 1.9.9-35-gbd2999d and no patch.
--
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=51481
Bug ID: 51481
Summary: Why is the Epson printer printing blank pages?
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: baroncorrz(a)gmail.com
Distribution: ---
Epson printer printing blank pages because there must be some problem related
to the cartridge ink or the nozzle. The cartridge ink must have been depleted.
You need to check the level of ink by comparing the ink level with the marker
on the ink tank. If the ink level is low, then it means that you need to put in
a new cartridge. If you have an ink tank with a low ink level, then fill the
ink tank with the ink. The problem can also be due to the clogging of the
nozzle. You need to clean the nozzle if this happens. One of the best ways to
prevent this is by giving fewer jobs to the printer.
https://www.epsonprintersupportpro.us/blog/printer-printing-blank-pages/
--
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=21158
Summary: Hitman: Contracts ignores mouse press events
Product: Wine
Version: 1.1.35
Platform: x86
URL: http://www.gamershell.com/download_5663.shtml
OS/Version: Linux
Status: NEW
Keywords: download, regression
Severity: minor
Priority: P2
Component: directx-dinput
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: arethusa26(a)gmail.com
CC: vitaliy(a)kievinfo.com
With wine-1.1.35-180-g20a50f3, after launching Hitman: Contracts, mouse press
events at the main menu are ignored by the game. Since a user reported that the
game worked normally in wine-1.1.9, a regression test was performed, which
indicated:
3743a1a7ca170c765cd779c61b9e362c5b1c5203 is first bad commit
commit 3743a1a7ca170c765cd779c61b9e362c5b1c5203
Author: Vitaliy Margolen <wine-patches(a)kievinfo.com>
Date: Sun Feb 1 13:11:46 2009 -0700
dinput: Consume mouse & keyboard events in exclusive mode.
:040000 040000 6ae6b43b3c100af38ed4f27384470dc4d2595bc1
700b35b9bc8fd27239ee8faaed8ca1c10cfc31d4 M dlls
Wine built prior to the indicated commit allows mouse input to work normally.
Interestingly, doing graphical mode changes (via keyboard input) makes mouse
input work again. The AppDB also suggests adding the strings:
UseDirectInputMouse
UseDirectInputKeyboard
to the HitmanContracts.ini configuration file to have mouse input work. The
only visible output under wine-1.1.35-180-g20a50f3 is:
fixme:dinput:SysMouseAImpl_Acquire Clipping cursor to (0,0)-(1280,1024)
fixme:win:EnumDisplayDevicesW ((null),0,0x32eb58,0x00000000), stub!
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x253b060,0x253afa8): stub
fixme:dsound:DllCanUnloadNow (void): stub
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x253b060,0x253afa8): stub
(Z:\code\hitman2\gui\MainMenu.cpp:554)Hitman Contracts build 171 (Apr 26 2004
14:42:27)
fixme:dsound:DllCanUnloadNow (void): stub
--
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=53816
Bug ID: 53816
Summary: KartRider: Failed to initialize Nexon Game Security
with error code e3010104
Product: Wine
Version: 7.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: j20001970(a)yahoo.com.tw
Distribution: ---
The game is unable to get past the initialization stage to login window.
How to reproduce the bug:
1. Install the game with PopKart_Setup_<version number>.exe
2. Locate the game directory (the installation path is "C:\Program Files
(x86)\Gamania\PopKart\M01" by default) and run KartRider.exe with wine.
3. You will see game splash at the center with "Init...Ok", and Nexon Game
Security splash at bottom right, then popup "Nexon Game Security Initialize
Error.|Code = e3010104" will show.
Game account registration is **NOT** required to reproduce the bug.
--
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=54291
Bug ID: 54291
Summary: vbscript stuck in endless for loop when UBound on
Empty and On Error Resume Next
Product: Wine
Version: 7.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vbscript
Assignee: wine-bugs(a)winehq.org
Reporter: jsm174(a)gmail.com
Distribution: ---
I ran across some code similar to the following:
WScript.echo "Start"
Dim ii
Dim tmp
Dim vpmMultiLights() : ReDim vpmMultiLights(0)
On Error Resume Next
For Each tmp In vpmMultiLights
For ii = 1 To UBound(tmp) : tmp(ii).State = tmp(0).State : Next
Next
On Error Goto 0
WScript.echo "Done"
In real vbscript, the result is:
Start
Done
In wine vbscript, this code will get stuck in an endless loop.
To work around this I hacked UBound to return 0 with VT_EMPTY, but I think real
vbscript treats this differently.
--
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=50129
Bug ID: 50129
Summary: Calibre-portable error initializing the bypy frozen
importer
Product: Wine
Version: 5.0.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bilbiliblus(a)gmail.com
Distribution: ---
When I try to run Calibre-portable.exe y have this message:
There was an error initializing the bypy frozen importer:
<class 'MemoryError'>:
Traceback (most recent call last):
File bypy-importer.py, line 250, in <module>
File bypy-importer.py, line 195, in __init__
It only happens since Calibre changed to version 5 and on.
This very morning I've tried with Calibre 5.3
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=53205
Bug ID: 53205
Summary: user32:input - test_rawinput() has a rare pair of
failures in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
user32:input - test_rawinput() has a rare pair of failures in Wine:
input.c:2784: Test failed: 15: expected WM_INPUT message
input.c:2787: Test failed: 15: expected RIM_INPUT message
https://test.winehq.org/data/patterns.html#user32:input
These failures don't seem to depend on the locale or bitness. But there are
only two known instances of these failures in WineTest making them likely to
cause false positives (~0.5% failure rate).
--
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=52461
Bug ID: 52461
Summary: The Legend of Heroes: Trails of Cold Steel III usually
hangs on exit
Product: Wine
Version: 7.0
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Distribution: ---
Created attachment 71749
--> https://bugs.winehq.org/attachment.cgi?id=71749
patch mitigating the race
To reproduce it's sufficient to install the game from Steam, get into the main
menu, and select the "exit" option (page down with the S key then press Enter).
Closing the window also works. The hang doesn't happen every time but does
happen most times I tested.
This is an application bug. There are two threads—a main thread and a worker
thread. The main thread closes the handle to a mutex, goes off and does some
other things, and then tries to wait on the mutex handle again (with a timeout
of INFINITE). The worker thread basically does a timed wait, in a loop, on a
set of handles, except that instead of passing a timeout to
WaitForMultipleObjects(), it repeatedly creates a non-periodic auto-reset timer
object, sets it for 1 ms, and adds it to the wait array, and then closes the
handle.
Because of the way handles are allocated in Wine (i.e. "lowest slot first"),
and because of the specific pattern of handle usage of the program, what
usually happens is that when the mutex handle is closed, the value is reused
for a timer handle in the worker thread. While the worker thread is sleeping on
the timer, the main thread also waits on it, and when the timer fires, it only
wakes up the worker thread (which is almost always first in the queue). Closing
the handle of a waitable object in Windows doesn't interrupt other waits in
progress, and because the timer is non-periodic and auto-reset, the main thread
ends up waiting forever.
It turns out that Windows doesn't allocate handles like this. Rather, it seems
to use a free list, much like we use in other places in Wine: testing shows
that handles are always allocated in the reverse order that they are freed,
including across multiple threads, and regardless of how many handles were just
allocated.
Changing Wine to use a free list like this actually does mitigate the problem.
Because the worker thread closes its timer handle and then immediately creates
a new one, it will almost always get back the same handle value. The main
thread will most likely close its mutex handle while the worker thread is still
sleeping, with the effect that the mutex handle won't be reallocated and the
subsequent wait will return STATUS_INVALID_HANDLE.
In theory the potential for the race is still there, however; it's still
possible for the mutex handle to be closed after the timer handle is closed but
before a new timer is created, in which case the mutex handle value will be
reused for the timer value as it is currently. In practice I'm not sure if this
happens more than a negligible fraction of the time. I certainly couldn't
reproduce it after 6 or so tries, although that's not very many. Note that
there are also reports of it hanging on Windows [1]...
[1] https://steamcommunity.com/app/991270/discussions/0/2145343189632898904/
--
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.