Running Hollow Knight Silksong on Windows 7: A PC Modding Feat

A stubborn little triumph unfolded on the internet this week: an enterprising tinkerer managed to resurrect Windows 7, coerce the Steam client into running on it, and — after a series of creative workarounds — boot Hollow Knight: Silksong on that ancient platform, delivering a textbook example of why the PC modding community will never let legacy systems die quietly.

Background: why this matters (and why it’s messy)​

For most PC users, Windows 7 has been a relic for half a decade. Microsoft ended mainstream support for Windows 7 in January 2020, and ecosystem vendors have been gradually phasing it out ever since. Valve’s Steam client formally stopped supporting Windows 7, 8 and 8.1 on January 1, 2024 — a decision the company said was forced by its dependency on an embedded Chromium build and the need for Windows feature/security updates only present on Windows 10 and newer. This means Steam on Win7 no longer receives updates, security fixes, or guaranteed functionality.
At the same time, Team Cherry’s Hollow Knight: Silksong — a hand‑drawn 2D Metroidvania and one of the most eagerly awaited indie titles in recent memory — launched to massive demand in 2025. The game’s PC uptake pushed storefronts and services hard on launch, and its system requirements (modest by modern standards) rekindled a perennial community question: how far back can you go and still run contemporary games? The official Steam product pages and many third‑party requirement trackers offer differing minimum OS lines (some listing Windows 7, others Windows 10 21H1 or newer), which has only added confusion about what “supported” means for legacy systems.
This is where the story gets interesting: when a game is technically light and a community is resourceful, old OSes — even unsupported ones — sometimes keep running with a little elbow grease. The stunt we’re exploring is less an indictment of Microsoft than a showcase of how resilient and creative the PC community can be. It also raises hard questions about risk, sustainability, and what “support” actually protects.

---

Overview of the stunt: what the tinkerer did (reported sequence)​

The public writeups and video coverage describe the following sequence of steps the tinkerer took to get Silksong running on a Windows 7 machine. The exact order and file names vary between accounts, but the broad approach is consistent:

• Boot Windows 7 on a machine (or virtual machine) and install an existing Steam client copy.
• Trick the Steam client into launching by removing or renaming specific DLLs the client checks for on startup; this bypass prevents the client from failing immediately on unsupported OS checks.
• Confront Steam’s download restrictions (the client refused to finish downloading Silksong on Win7) by acquiring the game files on a modern machine and copying the full game folder over to the Win7 installation.
• Install and apply community kernel extenders, third‑party compatibility patches, and specific Microsoft Knowledge Base updates to patch missing runtime functionality.
• Run the game; resolve leftover runtime errors and missing components until Silksong boots and becomes playable — in the reported case, even advancing past early bosses with integrated GPU performance.

Those steps read like a checklist for extreme backwards-compatibility work: hack the launcher, transplant game assets, and patch the OS with community tools that reintroduce modern kernel behaviors or drivers the old OS lacks. It’s a classic “make the environment look modern enough for old code paths” approach.

---

Verifying the core claims: what’s provable and what needs caution​

This section checks the most load‑bearing assertions and ties them to authoritative sources.

• Valve stopped supporting Windows 7 / 8 / 8.1 on January 1, 2024. Verifiable: Valve’s support announcement and multiple respected outlets reported the move in 2023–2024, noting Chrome/CEF dependencies and missing Windows security features as the rationale.
• Silksong’s PC system requirements are intentionally low; earlier store metadata listed Windows 7 as a minimum in some storefront snapshots, while other pages and aggregated trackers list Windows 10 (64‑bit) or Windows 10 21H1 as the minimum after updates. That discrepancy is real and demonstrable: Steam’s product pages and third‑party requirement databases show slightly different OS lines at different times (store pages can be updated pre/post‑release). Treat any single “minimum OS” line with caution — always cross‑check the current Steam product page.
• A user successfully ran Silksong on Windows 7 after manual workarounds. Partially verifiable: multiple news outlets and community posts describe enthusiasts getting modern games to run on legacy systems; the specific ChrisPro video referenced in community coverage is widely discussed in gaming press as an example of this tendency, but the step‑by‑step details come from a mix of video evidence and community reporting rather than a single canonical technical write‑up. Readers should treat the hands‑on claims as demonstrations of possibility, not as officially supported configurations.
• Running an unsupported OS online is insecure. Verifiable and important: unsupported OSes do not receive security patches from Microsoft, and running exposed network software (Steam, browsers, DRM, multiplayer clients) increases risk of compromise. Practically every security advisory covering EOL operating systems says the same. This is not a philosophical point — it’s a concrete security reality.

In short: Valve’s support cutoff is factual and documented. Silksong’s low CPU/GPU/DRAM needs are real and make the game a reasonable candidate for legacy runs. The exact steps used by the tinkerer are community‑reported and demonstrably reproducible in skilled hands, but they are not “official” and come with measurable security, stability, and maintenance costs.

---

Why this worked (technical analysis)​

Several technical factors make a feat like this feasible on Windows 7:

• Game engine friendliness: Silksong is built in Unity and is a 2D, non‑GPU‑heavy title compared with modern AAA games. Unity titles, especially 2D ones, often rely on widely available APIs and are tolerant of older DirectX/OpenGL backends, which reduces the amount of modern OS plumbing required. This dramatically increases the odds a skilled tinkerer can find a viable compatibility surface.
• Launcher vs. game separation: Many modern launchers (Steam included) are responsible for downloads, updates, DRM/achievements, and storefront UI — not the core runtime loop of the game itself. If the community can bypass or emulate the launcher’s checks, and if the game’s binaries are present, the game executable can often run independent of the client. That’s why copying a fully downloaded game directory from another machine is a standard fallback. The dangers of this approach are practical: automatic updates, anti‑cheat integration, and Steam Cloud features may break or behave unpredictably.
• Community drivers and kernel extensions: Over the last decade hobbyists have produced micro‑patches, kernel compatibility shims, and driver wrappers that restore or emulate Windows features on older kernels. These tools can be surprisingly robust for specific tasks (display modes, audio stacks, virtual device interfaces), but they are not equivalents to vendor‑supplied drivers and can introduce instability or security gaps. The Windows tinkering scene has a long history of such projects — Tiny builders, compatibility shims, and driver “glue” — which make modern software usable on unsupported systems in a pinch.

Why did it still throw errors? Because there are many moving parts: DRM libraries that expect signed system services; anti‑cheat code that hooks kernel routines; modern CEF/bundled Chromium components that assume updated TLS and OS security features. Overcoming one barrier often reveals another.

---

Strengths and merits of the achievement​

• Technical ingenuity: This is a clear demonstration of grassroots engineering. The process requires system‑level familiarity, reverse engineering instincts, and a patient test/debug cycle. It’s a useful case study for what’s achievable with careful tinkering.
• Preservation and reuse: Tinkering like this extends the life of older hardware and illustrates how software optimization and clever compatibility work can lower the demand for immediate hardware refreshes — a nontrivial sustainability win when hardware churn and e‑waste are considered.
• Community knowledge sharing: The whole feat stands on prior work — community patches, archived drivers, and shared HOWTOs. That cumulative, open knowledge helps other users revive machines for light gaming, classic apps, or archival purposes.

---

Risks, caveats, and the responsible take​

This is important: getting a game to run on Windows 7 does not make the configuration safe, supported, or appropriate for everyday use. The main risks:

• Security: Windows 7 receives no security fixes from Microsoft; running a networked game client and a modern browser on such an OS exposes you to unpatched vulnerabilities. This is non‑negotiable: unsupported OSes are inherently more dangerous online.
• Updates and DRM/anti‑cheat: Many modern games rely on services that update automatically. Without a supported client, you’ll lose automatic updates, official troubleshooting, and (for some titles) anti‑cheat support. That can break multiplayer or even single‑player DRM.
• Stability and data loss: Community kernel extensions and driver shims are not vendor‑certified. They can cause system instability and data corruption — not a trivial downside for anyone keeping important files on the machine.
• Legal/terms‑of‑service implications: Bypassing launcher checks or altering runtime behavior may violate service terms for some platforms. It’s rare that single‑player gameplay carries legal risk, but account suspension and support ineligibility are possible. Always check terms before attempting drastic modifications.

In plain terms: this is a brilliant hobbyist stunt, not a recommended production path.

---

How someone could (safely) replicate parts of this experiment — a stepwise primer​

Note: the following is a high‑level outline intended for experienced tinkerers only. Running unsupported OS versions online is unsafe; perform tests in isolated VMs and on disposable hardware. This is intentionally non‑prescriptive about exact file/registry edits because those specifics change frequently and can brick systems.

• Prepare a disposable environment
• Create a virtual machine or use a spare physical PC that can be wiped freely.
• Take full disk images and have recovery media at hand.
• Acquire the game properly
• Download the legal game files on a modern, supported PC.
• Verify the digital signature / integrity of the files where possible.
• Install the game files on the old OS
• Copy the whole game folder to the Windows 7 VM/hardware.
• Avoid copying launcher executables that will attempt to auto‑update themselves.
• Emulate/patch missing dependencies
• Apply community‑recommended OS hotfixes or runtime libraries required by the game (visual C++ redistributables, DirectX runtimes).
• Use community kernel shims or driver wrappers only if they are reputable and well‑documented.
• Isolate the machine
• Keep the Win7 test system offline unless you’re deliberately testing networked features behind a controlled firewall.
• Consider running the game with network features disabled if the executable supports it.
• Test and iterate
• Run the game, capture logs, and address missing DLLs or runtime errors pragmatically.
• Expect to run into DRM/anti‑cheat roadblocks that may be insurmountable without official client support.

If these steps sound fiddly and risky, that’s because they are — which is why the pragmatic recommendation for most users is to upgrade the OS or use a modern VM.

---

Broader implications: what this says about modern OS strategy and vendor timelines​

Three larger industry signals emerge from stories like this:

• The “support cliff” problem: When platform vendors (Microsoft, Valve, etc.) tighten their baseline requirements — whether for security or architecture reasons — a chunk of functional hardware becomes officially obsolete. That’s defensible from a security posture, but it accelerates hardware churn and frustrates users whose devices were otherwise fine for daily tasks. Community tooling (Tiny builders, compatibility shims) is a partial answer, but it transfers maintenance and security responsibility to hobbyists.
• Transparency and nuance in “supported OS” messaging: The Steam store and other product pages have shown divergent OS minimums at different times. That inconsistency confuses users who want to know whether an OS is genuinely supported — a problem that matters most to hobbyists running older stacks and to organizations with long lifecycles.
• The value of the modding ecosystem: For many users the ability to keep appliances and older PCs alive matters more than vendor timelines. The mod community isn’t just nostalgic; it’s a functional backstop that keeps devices useful longer and holds vendors to account on compatibility choices. The tradeoff is that the community’s solutions are not safe for everyone, and they should not be marketed as alternatives to supported upgrades.

---

Final verdict: celebrate the engineering, but don’t treat it as a plan​

What the tinkerer achieved is fun, technically impressive, and emblematic of the PC community’s brute‑force ingenuity. The spectacle — a modern indie hit running on a decade‑old operating system — is the perfect symbol of hobbyist resilience.
That said, it is not a path for everyday users or businesses. The security and support realities are stark: Valve stopped supporting Win7 clients for good reasons, and running a storefront client in an unsupported OS is inherently fragile. For playability and safety, the recommended routes remain:

• Upgrade to a supported OS (Windows 10/11) if you want a smooth and secure Steam experience.
• Use virtual machines and sandboxed test rigs if you’re experimenting.
• For older hardware you want to keep, consider a lightweight modern Linux distribution with Steam/Proton support — that’s often a better long‑term preservation strategy than sticking with an unpatched Windows 7 install.

The stunt is a neat reminder that the creative fringe of PC tinkering will always be a step ahead of deprecation — and that for every “you can’t,” there’s likely a passionate person somewhere asking “how can we?” Just keep in mind: ingenuity doesn’t equal hygiene. If you try something similar, do it on disposable hardware in an isolated environment, and treat it as a hobbyist proof‑of‑concept rather than a recommended configuration.

---

Appendix: quick reads and resources for the curious​

• Steam’s support policy and end‑of‑life notices (context on why older Windows versions lost client updates).
• Steam product page(s) for Hollow Knight: Silksong — note the changing minimum OS entries across snapshots.
• Community discussions and Tiny11 / compatibility‑builder threads outlining the ecosystem of shims and “Tiny” Windows builds that enable modern OS installs on older hardware.
• Coverage of Silksong’s launch and its massive demand (the release demonstrated how even an indie title can stress modern storefront infrastructure).

---

This episode is a love letter to why the PC remains special: a machine you can tinker with, argue about, and resurrect — at least temporarily — with enough know‑how. It’s also a practical reminder that the comfortable middle ground between nostalgia and safety lies in supported upgrades, careful virtualization, and using the right tools for the right job.

---

Source: PC Gamer Heroic tinkerer revives Windows 7 and gets Steam and Silksong running on it, so take that Microsoft and your constant nagging to upgrade to Win11