test_logfont in dlls/gdi32/tests/font.c calls CreateFontIndirectA with a
non-null-terminated font name and expects it to not crash.
--
v2: gdi32: Limit source string length in logfont_AtoW (ASan).
https://gitlab.winehq.org/wine/wine/-/merge_requests/7925
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
peb was limited in limit_2g ,but after user_space_wow_limit was assigned a value in init_peb function , wow64_params can be allocated in limit_4g if application perfers.
@julliard
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7935
Description: The printing function (non-Windows application call) used by Wine developers
is unnecessary to abort process when the string is super long. For example, the developer
prints a long commandline of wwmapp.exe by MESSAGE. As a result, the process cannot be
started, and the conference function cannot be used.
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: If06f0309f9745777f89b07dff8d302cb34b2a90e
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4635
According to the DPMI specification, when DPMI function 0800h (Physical
Address Mapping) fails then the carry flag has to be set.
For example if the application request for physical memory mapping via the
DPMI 0800h call it is required to set carry flag to indicate failure.
Otherwise application would be treated as successful operation in which
case in BX:CX registers is stored linear address of the mapped memory to
which application can access. Obviously on successful path if the BX:CX
registers are not set then application would try to access random memory
and crashes.
SysToolsLib, WinIO or libpci are just few examples of 32-bit Windows
libraries which issue this DPMI call via the kernel32.dll VxDCall()
function and are expecting either the carry flag on the failure or the
valid mapped address in BX:CX registers on success.
As the wine does not implement this DPMI function, always sets the carry
flag.
Windows NTVDM DPMI host does not implement the DPMI function 0800h too and
also always sets the carry flag. Tested and verified with a very simple
gcc/djgpp application on Windows NT.
So this also change aligns the wine behavior with the Windows NT.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7905
This fixes Trials Fusion often crashing when disconnecting a controller while there are more still connected.
--
v3: hidclass: Set Status for pending IRPs of removed devices to STATUS_DEVICE_NOT_CONNECTED.
ntdll/tests: Add more NtCancelIoFile[Ex]() tests.
ntdll: Wait for all pending operations to be cancelled in NtCancelIoFile[Ex]().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7797
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object.
This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later.
--
v3: server: Use an event as debug event sync.
server: Use an event as file lock sync.
server: Use an event as process startup info sync.
server: Use an event as thread context sync.
server: Use an event as thread apc sync.
server: Use an event as fd sync.
server: Redirect fd-based objects sync to the fd.
server: Move object grab/release out of (add|remove)_queue.
server: Split object sync related vtable.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7848
On Tue Apr 29 09:47:17 2025 +0000, Piotr Caban wrote:
> Prior to these commits the tests were also skipped, test output looked
> like this:
> ```
> msvcr100.c:258: Tests skipped: msvcr100.dll not installed (got 126)
> 1e24:msvcr100: 0 tests executed (0 marked as todo, 0 as flaky, 0
> failures), 1 skipped.
> msvcr100:msvcr100:1e24 done (0) in 0s 157B
> ```
> msvcr100 (and many other versions) are not part of Windows install, it
> needs to be installed later.
I see, is this what needs to be installed: https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?vi… ?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7853#note_102135
On Tue Apr 29 09:47:17 2025 +0000, Rémi Bernon wrote:
> Fwiw this and !7875 !7876 !7877 !7878 now cause many tests to be skipped
> on windows: https://test.winehq.org/data/patterns.html#msvcr100:msvcr100
Prior to these commits the tests were also skipped, test output looked like this:
```
msvcr100.c:258: Tests skipped: msvcr100.dll not installed (got 126)
1e24:msvcr100: 0 tests executed (0 marked as todo, 0 as flaky, 0 failures), 1 skipped.
msvcr100:msvcr100:1e24 done (0) in 0s 157B
```
msvcr100 (and many other versions) are not part of Windows install, it needs to be installed later.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7853#note_102134
Over the past several weeks I've been working on and off on this. I didn't track the hours but I'm sure that I've spent 80+ hours on the feature. I've tested and retested all known scenarios and it seems to be working as expected.
--
v25: cmd: Implement tab completion for command line entry.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7843