VB6 preservation bench

The project opens with an editable Order Entry application. The page exposes the toolbox, project tree, properties, form designer, source editor, debugger, and Run controls. Pressing F5 runs the project inside the browser. The exporter can package an edited project as an independent HTML application.

This is not a screenshot with dead menus. The repository documents a cooperative virtual machine, VB-style source execution, 37 offered control types, project import and export, resource handling, breakpoints, stepping, watches, and eleven examples. A fresh clone in the garage passed all 1,053 Node tests with Node's built-in test runner.

The impressive part is not that the bevels came back. The behavior is inspectable again.

Compatibility is a stack

The project's own compatibility notes draw the right line. Standard controls, source forms, many language behaviors, and supported resources have browser implementations. Native COM and OCX loading, arbitrary DLL calls, Windows API execution, external ADO or DAO providers, and exact native widget behavior do not.

That split matters when an old project opens cleanly. A form loading proves that the parser understood enough of the form and source. A click producing the expected result proves one browser runtime path. Neither result proves that a production workstation, printer driver, registered control, database, or automation server has an equivalent route.

Preservation needs an exit file

The project can save an editable .vb6web file and export a self-contained HTML application. That is more useful than browser storage alone. The README calls origin storage and layout persistence best effort, and tells users to download explicit backups.

The browser boundary also limits filesystem access. MDN documents that browser file handles begin with a user-selected file or directory, and that access is subject to browser security. VB6 Studio Web says it never receives unrestricted host-filesystem access. That is a constraint and a safety property. It also means an old application built around ambient drive access needs redesign, not a checkbox.

Start with one small, real project. Keep the original files untouched. Import a copy, record every warning, and compare a handful of important routes with the native application if you still have a working reference machine.

Make external contacts visible before rewriting them. A call to a DLL, an OCX event, a database provider, a printer, or a shared drive is part of the application's behavior. Replace each contact with a named browser route or keep it outside the migration.

Then test the exit. Download the editable project. Export the application. Open both in a fresh browser profile. A preservation tool earns trust when the recovered work can leave the session that recovered it.