If the canonical hostname was "localhost", the address info was not
freed.
Don't bother checking whether ai_canonname is NULL because if there is
no canonical name, getaddrinfo must set ai_canonname to the input name.
Fixes: ca5a6d07dc92ba631b178ec175e6b3fd5295e3d6
--
v3: wineboot: Fix a memory leak in create_computer_name_keys.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8918
On Tue Sep 9 08:58:52 2025 +0000, Nikolay Sivov wrote:
> Hi,
> Have you found an application that's using this method?
Yes, its called "RiSCAN PRO" from the company "RIEGL GmbH"
The product page can be found here: http://www.riegl.com/products/software-packages/riscan-pro/
(unfortunately one needs an account to download the software, and to install one needs to get a `tar.exe` into `system32` and `syswow64` as the installer uses `tar.exe` to extract zip files, but that is a different issue :grin: )
RiSCAN PRO under `wine-10.13` can't save a project and errors with the following message:
```
2025-08-19 08:25:47+730 [x] Cannot save project: Not implemented
```
With the following wine-debugging messages:
```
0148:fixme:msxml:domelem_removeAttributeNode (000072400CD21600)->(000072400CD217C0 00007FFFFE1FE0F8)
```
The project file is in xml format. The program itself is a Delphi Program and it seems to use `msxml.dll` to modify its project file
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8928#note_115432
Giving this one final shot. If this is not deemed acceptable, I will abandon the effort and just move on to other things, no hard feelings.
This is IMO a cleaner, more conservative/less invasive change.
What is fixed:
- Bug #56381, "TYPE c:\windows\winhelp.exe >foo", i.e. binary mode operation. I would probably consider this the main reason for this change. I'm trying to get the compiler mentioned in the bug report working.
- Ctrl-Z termination of TYPE output to the console.
- "TYPE con >foo", with Ctrl-Z handling, functionally equivalent to "COPY con foo".
--
v2: cmd/tests: Add tests to check for TYPE truncation in binary mode.
cmd: Fix some TYPE command behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8920
This matches https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/using-a-d… and, as far as I can see, is the intended idea and what the comment implies.
The idea, as I understand it, is to avoid a TOCTOU hazard by first setting the cancel routine and only afterwards checking the Cancel flag. If it's set while the previous cancel routine (returned by the second IoSetCancelRoutine call) is not NULL, that means it's been enabled before our first IoSetCancelRoutine call and we have to take care of it.
Conversely, if there is no previous routine set, it must mean that ntoskrnl has removed the routine we just set and it's going to call it, or has already called it (and it's probably now trying to acquire the spinlock). In that case we leave handling the cancellation to the routine and do nothing special here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8930
Salvage tests and fix a leak found in another review: see https://gitlab.winehq.org/wine/wine/-/merge_requests/897#note_9175 points 1 and 2. 3. is why !897 was reverted.
This does not contain the (incorrect) changes to VariantCopyInd, but instead fixes the leak identified in VariantClear (VT_RECORD needs to free pvRecord), and the wrong allocator being used in VariantCopy (it should have been IMalloc, rather than `HeapAlloc`, as shown by the fact IMallocSpy observes these allocations).
This also cleans up some dubious behavior by the test IRecordInfoImpl, which was modifying a VARIANT that it did not own or receive as an argument in the middle of VariantClear. This was likely undefined behavior, and in any case concealed the heap leak.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1035