https://bugs.winehq.org/show_bug.cgi?id=52873
Bug ID: 52873
Summary: oleaut32:typelib fails in Wine in Hindi
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: ---
oleaut32:typelib fails in Wine in Hindi:
typelib.c:2514: Test failed: got: L"default?"
typelib.c:2526: Test failed: got: L"default?"
typelib.c:3314: Test failed: got: L"default?"
typelib.c:3326: Test failed: got: L"default?"
https://test.winehq.org/data/patterns.html#oleaut32:typelib
A bisect shows that the test started failing with the commit below:
commit e81327358a26b160740b3421a4c7f300b4d2f06f
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Apr 13 15:13:16 2022 +0200
kernelbase: Move codepage initialization to ntdll.
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
Oddly this is the same commit as for a recent set of vbscript:run failures (see
bug 52872).
--
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=52779
Bug ID: 52779
Summary: Construction Set Extender crash with an Assertion
Error in wine 7.5
Product: Wine
Version: 7.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: lorenzofer(a)live.it
Distribution: ---
Using wine 7.5 Consturction Set Extender (plugin for Oblivion Construction Set)
crash with the following assertion
Assertion failed: Data != ActiveComboBoxes.cend(), file
Y:\CSE\Construction-Set-Extender\UIManager.cpp, line 623
Everything works fine with wine 7.4
There is no log except the common imm fixme and a lot of
d3d:wined3d_check_device_format_conversion and d3d:state_linepattern_w that are
present even in 7.4
Bisection in progress
--
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=42797
Bug ID: 42797
Summary: ICU64 for VICE: No highlighted read/write-colors in
Memory-window.
Product: Wine
Version: 2.4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: enkorv(a)yahoo.com
Distribution: ---
Created attachment 57824
--> https://bugs.winehq.org/attachment.cgi?id=57824
terminal output when running ICU64.exe
VICE is a Commodore 64 (and siblings) emulator. "ICU64 for VICE" is a hacking
tool that piggybacks onto the emulator and shows memory maps in useful ways.
When starting ICU64.exe it opens a small toolbar and starts the VICE emulator
as well. When selecting Memory in the toolbar a window opens which shows the
memory map of the Commodore 64. It should also highlight the memory read and
writes as well as where the CPU is currently running, using color highlighting.
This part doesn't work so the window just has a black background. You can still
zoom in and out in the memory map (using mouse scroll-wheel) and see the values
of the memory locations changing live.
An example of how the color highlighting typically looks is here (could not
find a clip of ICU64 for VICE, so this clip shows ICU64 for Frodo, which is
another Commodore 64 emulator): https://www.youtube.com/watch?v=tjcvR5McmSg
Testing and wine-environment:
Ubuntu 16.10 - 4.8.0-46-generic
wine-2.4
ICU64 needs Microsoft .NET Framework 2.0 (see
http://icu64.blogspot.se/p/download.html )
WINEPREFIX=~/.winetest2017 WINEARCH=win32 wineboot
WINEPREFIX=~/.winetest2017 winetricks dotnet2
ICU64 - https://sites.google.com/site/mathfigure/icu64vice23-v0.1.2.zip
c89d54ea7d64834694c3590660dee69e0738a418
WinVICE 2.3 -
https://sourceforge.net/projects/vice-emu/files/releases/binaries/windows/W…
b2a7ffafbcef1ab159681002616d9cf819c1ef84
Download both, unzip into same folder and run ICU64.exe.
--
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=31927
Bug #: 31927
Summary: ws2_32: sock.c fails intermittently - 'Test succeeded
inside todo block: GetQueuedCompletionStatus returned
0'
Product: Wine
Version: 1.5.14
Platform: x86
OS/Version: Linux
Status: NEW
Keywords: download, testcase
Severity: minor
Priority: P2
Component: winsock
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Classification: Unclassified
Running in a loop for about 15 minutes, I got:
sock.c:5385: Test succeeded inside todo block: GetQueuedCompletionStatus
returned 0
sock.c:5386: Test succeeded inside todo block: Last error was 64
make: *** [sock.ok] Error 2
--
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=53941
Bug ID: 53941
Summary: Chicken Tournament crashes on start
Product: Wine
Version: 7.20
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: dmusic
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Created attachment 73511
--> https://bugs.winehq.org/attachment.cgi?id=73511
Log file
Other issue with directmusic not being implemented completely.
--
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=53625
Bug ID: 53625
Summary: In function ‘get_gnutls_cipher’ ... error:
‘GNUTLS_CIPHER_AES_128_CFB8’ undeclared
Product: Wine
Version: 7.15
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bcrypt
Assignee: wine-bugs(a)winehq.org
Reporter: version2013(a)protonmail.com
Distribution: ---
Created attachment 73024
--> https://bugs.winehq.org/attachment.cgi?id=73024
log.txt
Compiling in distro with:
compiler version 4.8.4
# gcc --version
glibc 2.19
# ldd --version
config line:
configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-x
--libdir=/usr/lib32 CFLAGS="-O2 -march=i686 -mtune=i686"
Compile error in wine-7.15
In function ‘get_gnutls_cipher’:
error: ‘GNUTLS_CIPHER_AES_128_CFB8’ undeclared
error: ‘GNUTLS_CIPHER_AES_192_CFB8’ undeclared
error: ‘GNUTLS_CIPHER_AES_256_CFB8’ undeclared
--
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=53384
Bug ID: 53384
Summary: Hogia Hemekonomi Unexpected error on first start
Product: Wine
Version: 7.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: winehq(a)jonass.user.lysator.liu.se
Distribution: ---
Created attachment 72771
--> https://bugs.winehq.org/attachment.cgi?id=72771
Terminal with start of wine, error dialog and application in background.
On first start Hogia Hemekonomi tries to determine if this is the first run of
the program. If it is, it tries to start another executable called
hekintro.exe. hekintro.exe opens a new windows and shows an introduction.
This bug gives and Unexpected error dialog instead of the intro window.
I have tried bisecting but can not find a conclusive commit. Only that it may
be around commit 9b9d818252fe1a47f3ca52d028dc10d52fa33597 Mar 4 14:29:21 2022.
Wine 7.1 seems to be fine, 7.4 seems to be bad.
Testing on XUbuntu 18.04.6 LTS i686.
--
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=50013
Bug ID: 50013
Summary: MyPhoneExplorer 1.8.15 crashes
Product: Wine
Version: 5.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: maiktapwagner(a)aol.com
Distribution: ---
Created attachment 68435
--> https://bugs.winehq.org/attachment.cgi?id=68435
Backtrace (5.18 Staging)
Hello everyone,
Download-URL is at: https://fjsoft.at/de/
There is also an AppDB entry:
https://appdb.winehq.org/objectManager.php?sClass=version&iId=34110
Installation works fine in a clean prefix with 5.18 (Staging) and the app
requires vb6run installed to start it up.
However it throws a fatal error. Backtrace is attached.
--
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=49394
Bug ID: 49394
Summary: CED1401 USB function driver fails to install
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: usb
Assignee: wine-bugs(a)winehq.org
Reporter: alois.schloegl(a)gmail.com
Distribution: ---
Created attachment 67461
--> https://bugs.winehq.org/attachment.cgi?id=67461
WINEDEBUG=+wineusb,+setupapi,+ntoskrnl,+plugplay,+pid,+msgbox ./wine
winsupp.exe
I'm try to test the fix for bug 35903. In order to do so, I compiled wine from
source (commit 634cb775c27b61ad6ce1fbe3e9972b0edfa31dcb), and used wine from
the build directory.
Now the installation of winsupp.exe is failing (this has been working before)
with this error:
0020:0024:err:module:__wine_process_init
L"Z:\\home\\schloegl\\src\\wineapps\\winsupp.8081a20bbc0c9b99f37b98a823ce07ab25f15e9d.exe"
not supported on this system
The log file is attached.
--
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=53918
Bug ID: 53918
Summary: Building with external PE libraries fails when static
libraries are also installed
Product: Wine
Version: 7.20
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: build-env
Assignee: wine-bugs(a)winehq.org
Reporter: z.figura12(a)gmail.com
Regression SHA1: 6a912649188a765d0c58e8b26e093fb0c31b3e3d
Distribution: ---
The basic problem is that winegcc, when passed e.g.
"-L/usr/x86_64-w64-mingw32/lib -lvkd3d", looks up that library in the search
path, finds libvkd3d.a, and tries to link to it.
The mingw-w64 linking process, at least for vkd3d (but presumably others as
well), provides both "libvkd3d.a" and "libvkd3d.dll.a". The former is a static
library, and the latter is essentially an import library for libvkd3d-1.dll.
Normal mingw-w64 gcc, when passed -lvkd3d, links to the latter, according to
the search path specified in [1] s.v. "direct linking to a dll". winegcc does
not know about .dll.a and hence finds the static library first.
This worked before 6a912649 because winegcc would try to find a library ending
in ".cross.a", fail to find *any* vkd3d libraries, and just leave the linker
argument as "-lvkd3d".
Given this, an obvious solution is to teach winegcc about the ld linker path.
However, I find myself asking—why are we trying to rewrite the command line at
all? Why can't we just let mingw-w64 gcc work by itself? winegcc is, naturally,
devoid of any comments, and as far as I can tell the code doesn't actually *do*
anything that depends on the library type or path, so I started looking in the
git history, but unfortunately was only partly able to answer the question.
Here is what I found:
* c7a210bc2f27 forces the use of library paths if -mno-cygwin is set (in
addition to some other conditions). The commit message specifies that we *can*
do this (due to our use of -nodefaultlibs), but doesn't specify why we *need*
to do this. Jacek, can you by chance explain?
* 33147c947500 forces the use of library paths (sort of) if lib_suffix is set,
which makes sense—gcc won't be able to find any libraries if we are overriding
lib_suffix.
* 870d490eecdb forces the use of library paths for all winelib DLLs, so that
"-lfoo" links to "foo/foo.dll". This makes sense, but is also now obsolete—our
makefiles pass the direct paths. Or do we want to support winelib users outside
of wine including from the build tree?
* 006ec80dd5c1 introduces the logic in the first place, forcing the use of
library paths for static libraries. This was written by Dimitrie O. Paun, with
the comment "For static libs (.a) we need to pass the actual filename to
winebuild, not a -l switch." No further explanation is given.
Alexandre, can you please shed light on this?
[1] https://sourceware.org/binutils/docs-2.39/ld/WIN32.html
--
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.