https://bugs.winehq.org/show_bug.cgi?id=54376
Bug ID: 54376
Summary: ws2_32:sock - test_reuseaddr() overflows a sockaddr
variable by reading an AF_INET6 peer name into it
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: jinoh.kang.kr(a)gmail.com
CC: pgofman(a)codeweavers.com
Regression SHA1: c6da691926c418697ab982a284228772837a4be2
Distribution: ---
ws2_32:sock - test_reuseaddr() overflows a sockaddr variable (saddr) by passing
it as a peer name buffer to accept() on an IPv6 TCP listener socket, which then
assumes that the buffer is at least as large as struct sockaddr_in6.
--
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=54353
Bug ID: 54353
Summary: crypt32:cert - testVerifyRevocation() gets unexpected
success in Wine on second run
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: crypt32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
crypt32:cert - testVerifyRevocation() gets unexpected success in some Wine
configurations:
cert.c:3910: Test failed: success
cert.c:3911: Test failed: got 00000000
See https://test.winehq.org/data/patterns.html#crypt32:cert
In fact the test only succeeds on the first run in a given wineprefix. All
later runs fail:
$ rm -rf ~/.wineprefix
$ ./wine dlls/crypt32/tests/i386-windows/crypt32_test.exe cert
0700:cert:0.615 608 tests executed (0 marked as todo, 0 as flaky, 0 failures),
0 skipped.
$ ./wine dlls/crypt32/tests/i386-windows/crypt32_test.exe cert
cert.c:3910: Test failed: success
cert.c:3911: Test failed: got 00000000
078c:cert:0.242 608 tests executed (0 marked as todo, 0 as flaky, 2 failures),
0 skipped.
# Running the test again gets the same failures
This is why the test.winehq.org only has failures for my fg_deb64-wow32 test
configuration: on my desktop I run the wow64 tests first, and then the wow32
tests in the same wineprefix.
A bisect shows that these failures were introduced by the commit below:
commit 67de946ca9bdc8f39adffca57a336165936e62e2 (refs/bisect/bad)
Author: Paul Gofman <pgofman(a)codeweavers.com>
Date: Wed Jan 11 14:00:48 2023 -0600
cryptnet: Check cached revocation status in verify_cert_revocation().
That is, before this commit, running the test twice in a row was not an issue.
--
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=54337
Bug ID: 54337
Summary: AviUtl shows Japanese text as garbage after conversion
in ExEdit edit box
Product: Wine
Version: 8.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: sagawa.aki+winebugs(a)gmail.com
Distribution: ---
Created attachment 73906
--> https://bugs.winehq.org/attachment.cgi?id=73906
Illustration of AviUtl mojibake
AviUtl is a Japanese AVI file editing tool. When a user inputs Japanese text to
the certain edit box with Input Method, it shows garbage, i.e. mojibake.
How to reproduce:
1. Download aviutl110.zip and exedit93rc1.zip respectively from
http://spring-fragrance.mints.ne.jp/aviutl/
2. Unzip them.
3. Launch aviutil.exe in Japanese locale, i.e. LANG=ja_JP.UTF-8 wine aviutl.exe
4. From the menu bar, select [設定]-[拡張編集の設定] (Settings-ExEdit Settings). The
window titled 拡張設定 (ExEdit) will be shown.
5. Right click the time-line part on the window and select [新規プロジェクトの作成]
(Create new project) in the context menu. New dialog window will appear.
6. In 新規プロジェクトの作成 dialog window, click [OK].
7. Right click the time-line part on the 拡張編集 window, again.
8. In the context menu, select the topmost [メディアオブジェクトの追加] (Add a media object)
- [テキスト] (Text) in the context menu. Another dialog window titled テキスト will be
shown.
9. Focus on the edit box in the bottom most of the dialog window.
10. Input Japanese characters "あいう" (aiu) with your favorite Input Method.
11. Type [ENTER] to finish conversion.
Expected behavior:
* After conversion, "あいう" will be shown in the edit box.
Actual behavior:
* After conversion, "・「・、・" is shown.
--
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=52506
Bug ID: 52506
Summary: Setup of game "What's the Secret?" fails to create
icon
Product: Wine
Version: 7.1
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: shell32
Assignee: wine-bugs(a)winehq.org
Reporter: alexhenrie24(a)gmail.com
Distribution: ---
Created attachment 71804
--> https://bugs.winehq.org/attachment.cgi?id=71804
Output of `WINEDEBUG=+shell wine 3msetup.exe`
The children's educational game "What's the Secret?" creates a program group
named "3M Learning Software" and an icon within it named "What's the Secret?",
as can be seen in the attached trace:
0080:trace:shell:Dde_OnExecute conv=000000000025B0A0 topic=L"Progman"
data=L"[CreateGroup(3M Learning Software)]"
0080:trace:shell:Dde_OnExecute conv=000000000025B0A0 topic=L"Progman"
data=L"[AddItem(\"C:\\windows\\apw_data\\launch.exe F:\\3MSecret.exe\",What's
the Secret?)]"
There are two problems here:
1. The icon's target is a path plus arguments, which Wine does not support.
2. The icon name includes a question mark. That worked just fine on Windows
3.1, but when the Program Manager was replaced with the Start menu in Windows
95, "What's the Secret?" was automatically converted to "What's the Secret_" to
make it a valid file name. Wine imitates the Start menu but doesn't do any icon
name sanitization.
Although installation fails, the game can still be run directly from the CD.
--
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=54371
Bug ID: 54371
Summary: loader won't launch from PATH unless named "wine"
Product: Wine
Version: 7.22
Hardware: x86-64
OS: Mac OS X
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: loader
Assignee: wine-bugs(a)winehq.org
Reporter: gcenx83(a)gmail.com
When attempting to load wine64 from $PATH from wine-7.22 and later I'm getting
the following message.
> wine: could not exec the wine loader
When launched using the full path aka /opt/local/bin/wine64 it works without
issue.
--
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=52878
Bug ID: 52878
Summary: Improve software components also for using “Free PC
Audit”
Product: Wine
Version: 7.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: Markus.Elfring(a)web.de
Distribution: ---
I have tried the tool “Free PC Audit 5.1.211.96” out together with the software
“Wine 7.7-1449.4”.
Markus_Elfring@Sonne:~> wine
/home/altes_Heim2/elfring/geladen/Freeware/freepcaudit.exe
00c4:err:ntoskrnl:ZwLoadDriver failed to create driver
L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\SecDrv": c0000142
003c:fixme:service:scmdatabase_autostart_services Auto-start service L"SecDrv"
failed to start: 1114
0024:fixme:thread:GetThreadUILanguage : stub, returning default language.
…
0024:fixme:nls:RtlGetThreadPreferredUILanguages 00000038, 0113D9D4, 033AA680
0113D9FC
0024:fixme:nls:get_dummy_preferred_ui_language (0x38 0113D9D4 033AA680
0113D9FC) returning a dummy value (current locale)
0024:fixme:wtsapi:WTSRegisterSessionNotification Stub 00010078 0x00000000
0024:fixme:uxtheme:BufferedPaintInit Stub ()
0024:err:listview:LISTVIEW_WindowProc unknown msg 109d, wp 0, lp 0
0070:fixme:imm:ImeSetActiveContext (0x5a7b0, 0): stub
0070:fixme:imm:ImmReleaseContext (0000000000010020, 000000000005A7B0): stub
0024:fixme:imm:ImeSetActiveContext (0x268260, 1): stub
0024:fixme:imm:ImmReleaseContext (000100BE, 00268260): stub
0024:fixme:ntdll:NtQuerySystemInformation info_class
SYSTEM_PERFORMANCE_INFORMATION
0024:fixme:wbemdisp:object_Instances_
…
0024:fixme:wbemprox:class_object_GetMethod Method L"GetBinaryValue" not found
in class L"StdRegProv".
0024:fixme:wbemdisp:object_SpawnInstance_
…
0058:fixme:mountmgr:harddisk_ioctl The DISK_PARTITION_INFO and
DISK_DETECTION_INFO structures will not be filled
wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial
are not available.
…
0024:fixme:wuapi:automatic_updates_GetIDsOfNames
…
0120:fixme:secur32:get_cipher_algid unknown algorithm 23
0120:fixme:secur32:get_mac_algid unknown algorithm 200, cipher 23
I would like to see more helpful information on the tab “Brief” (than an IP
address).
--
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=54357
Bug ID: 54357
Summary: Spurious fixme message when calling ScrollWindow()
Product: Wine
Version: 8.0-rc3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: vz-wine(a)zeitlins.org
Distribution: ---
`ScrollWindow()` calls `NtUserScrollWindowEx()` with `SW_NODCCACHE` in the
flags, but this function complains if it's passed anything other than
`SW_SCROLLCHILDREN | SW_INVALIDATE | SW_ERASE`.
This seems to be due to a relatively recent b2db69efcf4 (win32u: Move
NtUserScrollWindowEx implementation from user32., 2022-06-08) as it replaced
the call to the internal `scroll_window()` with a call to
`NtUserScrollWindowEx()` with this unrecognized flag.
--
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=54234
Bug ID: 54234
Summary: vbscript fails to compile when colon follows Else in
If...Else
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 just ran into a script where there is a ':' separator on a new line after an
ELSE:
if IsEmpty(BallData(idx).id) and aBall.VelY < -12 then 'if tip
hit with no collected data, do vel correction anyway
if PSlope(aBall.x, FlipperStart, 0, FlipperEnd, 1) >
1.1 then 'adjust plz
VelCoef = LinearEnvelope(5, VelocityIn,
VelocityOut)
if partialflipcoef < 1 then VelCoef =
PSlope(partialflipcoef, 0, 1, 1, VelCoef)
if Enabled then aBall.Velx =
aBall.Velx*VelCoef'VelCoef
if Enabled then aBall.Vely =
aBall.Vely*VelCoef'VelCoef
end if
Else
: VelCoef = LinearEnvelope(BallPos, VelocityIn,
VelocityOut)
if Enabled then aBall.Velx = aBall.Velx*VelCoef
if Enabled then aBall.Vely = aBall.Vely*VelCoef
end if
I was able to fix this by changing:
Else_opt
: /* empty */ { $$ = NULL; }
| tELSE NL StatementsNl_opt { $$ = $3; }
| tELSE StatementsNl_opt { $$ = $2; }
to
Else_opt
: /* empty */ { $$ = NULL; }
| tELSE StSep_opt StatementsNl_opt { $$ = $3; }
| tELSE StatementsNl_opt { $$ = $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=53926
Bug ID: 53926
Summary: New typelib marshaller depends on IID_IDispatch
support from target interface
Product: Wine
Version: 7.21
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression, testcase
Severity: normal
Priority: P2
Component: oleaut32
Assignee: wine-bugs(a)winehq.org
Reporter: dmitry(a)baikal.ru
CC: z.figura12(a)gmail.com
Regression SHA1: 077b4391d442e927a2a59b5afb244355b0634aaa
Distribution: ---
Created attachment 73481
--> https://bugs.winehq.org/attachment.cgi?id=73481
test (source + binary)
New typelib marshaller depends on IID_IDispatch support from target
interface, however applications created with Delphi/.Net don't always
follow this implication.
This is a regression, and it starts from
commit 077b4391d442e927a2a59b5afb244355b0634aaa
Author: Zebediah Figura <z.figura12(a)gmail.com>
Date: Fri Nov 9 18:02:00 2018 -0600
oleaut32: Rip out the old typelib marshaller.
Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com>
Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de>
Signed-off-by: Huw Davies <huw(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
Old typelib marshaller didn't have a requirement that an interface a proxy/
stub being created for must support IID_IDispatch.
Attached testcase replicates what I can deduce from the logs, and runs
without failures under wine-3.0.5, but fails in several places under newer
versions of Wine. The test produces 2 extra IUnknown::QueryInterface() calls
under wine-3.0.5 during ::CreateStub() invocation, however it's pretty simple
to fix following a FIXME in oleaut32 and stub manager in ole32, after that
the test output from wine-3.0.5 matches what I observe under windows 10.
Although the test uses IConnectionPoint::Advise() to reproduce the bug (as
the application that I have here does) it seems that any client<=>server
remote call reliably replicates the problem, and source of the bug leads
to CreateStub/CreateProxy limitations.
--
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=54364
Bug ID: 54364
Summary: RtlGenRandom fails on systems with more than 128 cores
Product: Wine
Version: 8.0-rc5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: advapi32
Assignee: wine-bugs(a)winehq.org
Reporter: tjeerd.bakker38(a)gmail.com
Distribution: ---
WinHttpSendRequest() fails with ERROR_OUTOFMEMORY when the
WINHTTP_OPTION_UPGRADE_TO_WEB_SOCKET is set on systems with 256 cores. I've
tracked it down to dlls/advapi32/crypt.c.
RtlGenRandom is implemented by calling
NtQuerySystemInformation(SystemInterruptInformation, ...) with a buffer
sufficient for the data from at most 128 CPUs. The buffer size is determined by
the #define in line 2393:
#define MAX_CPUS 128
Changing this line to
#define MAX_CPUS 256
make the problem go away for me, but the problem will probably return when
someone builds a system with even more cores. I would suggest implementing
RtlGenRandom() with a better source of randomness instead.
--
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.