Test module references created by resolving forwarded exports.
The following diagram explains what happens in bug #52094 under the hood:
```mermaid
graph TB
subgraph state_00["Initial"]
direction LR
s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] -. "(import)" .-> s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll]
end
state_00 -. "1. <strong><code><span style='color:#28f'>Load</span>Library("</code></strong>configured Python version (e.g., python311.dll)<strong><code>")</code></strong>" .-> state_01
subgraph state_01["python311.dll loaded"]
direction LR
s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] -. "(import)" .-> s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll]
s01_ida -- "<em>dynamic</em> ref" --> s01_py311
end
state_01 -. "2. <strong><code><span style='color:#28f'>Load</span>Library("</code></strong>idapython64.dll<strong><code>")</code></strong>" .-> state_02
subgraph state_02["idapython64.dll loaded"]
direction LR
s02_ida[ida64.dll] -- "<em>dynamic</em> ref" --> s02_idapy[idapython64.dll] -- "<em><strong>static</strong></em> ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll]
s02_ida -- "<em>dynamic</em> ref" --> s02_py311
s02_idapy -- "<span style='color:red'><em><strong>static forwarded</strong></em> ref</span>" --> s02_py311
end
state_02 -. "3. <strong><code><span style='color:#d70'>Free</span>Library("</code></strong>configured Python version (e.g., python311.dll)<strong><code>")</code></strong>" .-> state_03
subgraph state_03["python311.dll reference removed"]
direction LR
style s03_py311 color:#f00,stroke:#f00
s03_ida[ida64.dll] -- "<em>dynamic</em> ref" --> s03_idapy[idapython64.dll] -- "<em><strong>static</strong></em> ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll]
s03_ida -. "<del><em>dynamic</em> ref (deleted)</del>" .-> s03_py311
s03_idapy -- "<span style='color:red'><em><strong>static forwarded</strong></em> ref</span>" --> s03_py311
end
```
On Windows, the <em><strong>static forwarded</strong></em> ref keeps `python311.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and segfault immediately (since further initialization happens just after step 3 FreeLibrary). The tests aim to reproduce this condition.
---
### Alternative options
1. Find existing DLLs satisfying this scenario: I haven't found any in wine tree. Let me know if I missed anything.
2. Construct PE for the DLLs on-the-fly: This sounds more complicated than a handful of test DLLs.
--
v5: kernel32/tests: Test module refcounting with forwarded exports.
https://gitlab.winehq.org/wine/wine/-/merge_requests/364
This patchset aims to fix #46070 without supplying unix\_name for all server files.
--
v3: kernelbase: Replace FileAllInformation with FileStatInformation in GetFileInformationByHandle().
ntdll: Implement NtQueryInformationFile FileStatInformation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5111
We used to expect a fixed number of DBI substreams (the expected number depended
on the DBI header version).
Recent MSVC generate a different number as we expected.
Implement a more flexible scheme where we allow any number of streams.
This lets these recent PDB files to be properly displayed by winedump, and
loaded/parsed by dbghelp.
--
v2: dbghelp: Don't expected a fixed number of substreams in DBI header (PDB).
winedump: Don't expect a fixed number of substreams in DBI header (PDB).
https://gitlab.winehq.org/wine/wine/-/merge_requests/5112
How about the [attached](/uploads/d104ebd37a462b4fd375640b9e97eb93/patches.mbox.xz) series? I turns out that it's a bit awkward to make the "rasteriser_ordered" flag specific to UAVs due to the way "resource_format" is currently used, but making it a resource flag seems close enough to me. The series has a minor conflict with 569.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/652#note_61911