Browser Porting Toolkit

Browser Porting Toolkit (BPTK) is a proposed Maphy Technologies toolkit for evaluating, adapting, testing, and packaging Windows games for the browser.

This repository contains the research-backed roadmap, its validation harness, and a dependency-free pre-alpha npm CLI for reading roadmap status and local environment facts. It does not contain a working game runtime, and no Windows game has been shown to run through BPTK yet.

Quick start

Install the public roadmap-tooling preview with Node.js 22 or later:

npm install --global @bygelo/bptk@0.1.0-alpha.0
bptk status
bptk doctor

status reads a bundled, revisioned roadmap snapshot. doctor reports Node and operating-system facts. Neither command imports, inspects, transforms, executes, or tests a game; both state that no game runtime exists.

To validate the source repository, install its dependency-free lockfile and run the complete gate:

git clone https://github.com/bygelo/BPTK.git
cd BPTK
npm ci --ignore-scripts
npm run gate

The source gate requires Node.js 22 or later and Python 3. The roadmap-only validator remains available as python3 tool/validate.py.

Product thesis

The useful promise is not “every Windows game magically becomes React.” The useful promise is:

Import broadly, diagnose precisely, and make the supported path to a browser build repeatable.

BPTK is planned as one workbench with three compatibility lane:

1. Binary lane — load eligible unmodified 32-bit PE game executable, execute x86 code, and translate a measured Win32 and DirectX subset to WebAssembly, WebGPU or WebGL, WebAudio, browser input, and OPFS.
2. Source lane — compile available C or C++ game source through Emscripten, then adapt graphics, audio, input, file, thread, and network behavior to browser constraints.
3. Engine lane — plug in a game-family engine replacement when a compatible open implementation already exists and the player supplies legally obtained asset.

Plain HTML and canvas are host targets. A React adapter is an optional integration shell; React is not the execution substrate.

Initial compatibility contract

The first product boundary is deliberately narrow:

• Target: DRM-free, 32-bit x86 Windows game from roughly the DirectDraw through Direct3D 9 era.
• Input: local folder, ZIP, selected installer, executable, or source tree.
• Output: a compatibility report in every case; a runnable browser package only when the required capability is implemented and proven.
• Execution: imported game code and asset remain client-side; an explicit network relay may mediate multiplayer traffic but never runs the game.
• Explicit early non-support: kernel driver, kernel anti-cheat, DRM circumvention, x86-64, Direct3D 10–12, and arbitrary native socket behavior.

“Import” means the toolkit accepts and safely inspects an input. It does not mean every input is executable.

Why this is feasible—and why it is hard

The component technology is demonstrated: PE loading and Win32 high-level emulation in the browser, x86-to-Wasm execution, Direct3D translation, source compilation to Wasm, browser file storage, and browser game ports all exist in prior art. The closest precedent, BottleShip, already combines several of these pieces.

The hard part is compatibility breadth. A Windows game can depend on a unique mixture of CPU instruction, undocumented behavior, Win32 call, graphics state, codec, installer, network protocol, timing assumption, middleware, DRM, or driver feature. BPTK therefore treats compatibility as a measured corpus and a growing generic shim set, not a marketing absolute.

Current state

• Roadmap candidate frozen: 46
• Accepted item with benchmark specification: 33
• Rejected candidate: 8
• Deferred candidate: 5
• Implemented item: 0
• Passing roadmap benchmark: 0 / 33 (0%)
• Published npm surface: @bygelo/bptk@0.1.0-alpha.0, roadmap status and environment diagnostics only

Start with ROADMAP.md, then read the architecture, source audit, legal boundary, third-party inventory, test contract, release procedure, and contribution guide.

Validation

The repository package is machine-checkable with one command:

npm run gate

The gate checks roadmap count, dependency integrity, item-to-benchmark mapping, promotion state, local link, singular naming, the exact dependency-free npm package surface, the deterministic status snapshot, CLI behavior, and the intended tarball file list.

The same command runs on Node.js 22 and 24 for every push and pull request through the repository's GitHub Actions gate.

Naming and affiliation

Browser Porting Toolkit is a working name for a Maphy Technologies project. It is not affiliated with or endorsed by Apple, Microsoft, Valve, CodeWeavers, or any game publisher. This public planning repository and its scoped roadmap-tooling package are not public-product-name clearance and remain rename-ready. Naming and trade dress require review before a runtime or product launch; the project must not copy Apple source code, icon, screenshot, or interface treatment. The unscoped npm name bptk is not used by this project.

License state

BPTK-authored material in this repository and the @bygelo/bptk tarball is licensed under the Apache License 2.0, with copyright and repository status recorded in NOTICE. The npm package has zero package dependency and uses only Node.js built-in modules; it incorporates no third-party software or game content. Factual prior-art references are not bundled dependencies.

Apache-2.0 does not relicense a future dependency, user-supplied game, trademark, proprietary asset, or restricted SDK. The third-party policy and legal boundary require component-level provenance and obligation review before upstream material enters the repository. BPTK-001 remains planned until the runtime reuse graph and public-name path receive their required review.