[PR #3713] [CLOSED] Core: Improved workaround for legacy Windows versions. #3676

New issue

Closed

opened 2026-02-27 22:04:35 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 22:04:35 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/shadps4-emu/shadPS4/pull/3713
Author: @StevenMiller123
Created: 10/6/2025
Status: ❌ Closed

Base: main ← Head: address-space-adjust

📝 Commits (2)

c2a5df5 Improved workaround
87c0b62 More descriptive warning

📊 Changes

1 file changed (+18 additions, -15 deletions)

View changed files

📝 src/core/address_space.cpp (+18 -15)

📄 Description

Upon further investigation, the part of these OS memory mappings that "hung" were associated with searching for an address (so in our case, VirtualAlloc2 calls with nullptr address). We can "fix" hanging in our code by specifying an address to our allocation for the backing file's virtual memory.

Unfortunately, C and C++ functions seem to perform these types of mappings internally too, so to completely prevent hangs, we also need to increase SYSTEM_MANAGED_MIN to leave some lower addresses for mappings outside our control.

Based on my tests in a VM, these changes allow me to run basic homebrew on a Windows 10 VM (with our HLE for VideoOut and GnmDriver disabled).

For now, I've hardcoded the minimum based on the current lowest address we've observed in fixed mappings from games (see https://github.com/shadps4-compatibility/shadps4-game-compatibility/issues/1413).

This PR needs extensive testing from Windows 10 and old Windows 11 builds (22H2 and before). While my tests suggest there's plenty of address space this leaves open, it might be ideal to hardcode a start offset to apply for the workaround instead. Ideally, people should test with more complex AAA titles, since those are likely to create many threads or otherwise hit code that would allocate host memory.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/shadps4-emu/shadPS4/pull/3713 **Author:** [@StevenMiller123](https://github.com/StevenMiller123) **Created:** 10/6/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `address-space-adjust` --- ### 📝 Commits (2) - [`c2a5df5`](https://github.com/shadps4-emu/shadPS4/commit/c2a5df50ac1468ea5111d982cd9843da96a537a5) Improved workaround - [`87c0b62`](https://github.com/shadps4-emu/shadPS4/commit/87c0b62579f7af9c0348a248a95e29001b48fdb5) More descriptive warning ### 📊 Changes **1 file changed** (+18 additions, -15 deletions) <details> <summary>View changed files</summary> 📝 `src/core/address_space.cpp` (+18 -15) </details> ### 📄 Description Upon further investigation, the part of these OS memory mappings that "hung" were associated with searching for an address (so in our case, VirtualAlloc2 calls with nullptr address). We can "fix" hanging in our code by specifying an address to our allocation for the backing file's virtual memory. Unfortunately, C and C++ functions seem to perform these types of mappings internally too, so to completely prevent hangs, we also need to increase `SYSTEM_MANAGED_MIN` to leave some lower addresses for mappings outside our control. Based on my tests in a VM, these changes allow me to run basic homebrew on a Windows 10 VM (with our HLE for VideoOut and GnmDriver disabled). For now, I've hardcoded the minimum based on the current lowest address we've observed in fixed mappings from games (see https://github.com/shadps4-compatibility/shadps4-game-compatibility/issues/1413). This PR needs extensive testing from Windows 10 and old Windows 11 builds (22H2 and before). While my tests suggest there's plenty of address space this leaves open, it might be ideal to hardcode a start offset to apply for the workaround instead. Ideally, people should test with more complex AAA titles, since those are likely to create many threads or otherwise hit code that would allocate host memory. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>