# WelsonJS supports Windows XP Service Pack 3, and its GUI layer runs on a component Microsoft retired

> A framework for building Windows desktop applications on the operating system's own script host, with four transpilers built in and no installation step. The manifest sits eleven patch releases behind the newest tag, the dependency set is frozen in an era when Internet Explorer needed HTML5 shims, and the licensing is dual because GPL compatibility with Microsoft products is the stated problem.

**gnh1201/welsonjs** — WelsonJS - Build apps with the Windows built-in JavaScript engine

- Repository: https://github.com/gnh1201/welsonjs
- Website: https://welson.js.org
- Stars: 512 · Forks: 35
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/gnh1201-welsonjs

## The support floor is Windows XP Service Pack 3

The stated system requirement is Windows XP Service Pack 3 or later, with the note that it is currently tested on a much newer release. Machines running Windows 2000 or earlier are handled separately, and the older consumer versions named as examples include 95, 98 and Me, which the documentation says to raise individually.

That range is the whole product in one line. A framework that runs on a service pack from more than two decades ago, on the script host built into the operating system, needs no runtime installation and can be dropped onto a locked down machine, is the only realistic answer to a class of problem that has no modern solution: an industrial controller or an old office machine that will never see a package manager.

The stated reason is resource constraints and legacy integration, and the language is consistently about operating in extreme conditions where conventional solutions may fail. The claims that follow are about small footprints, standalone execution without external dependencies, and controlled script execution.

The cost of that support range is visible in the dependencies rather than in the code. Everything in the package list exists because of the age of the host, which is the subject of the next section.

## The graphical layer is an HTML application, and the keyword list names it

There are two environments, and the file documents each with a diagram.

The console environment is the simple one: a user opens a command prompt and runs the script host against an application file, passing a module name. The application calls a require function with that name, the module exports back, and the two are connected. That is the whole console story, and it is why the package can be used with no interface at all.

The graphical environment adds a loader. The entry point is an application file with an HTML application extension, which the host opens as a window. That file loads the script, which requires a web loader, which in turn loads an index script along with an HTML file and a stylesheet, and then presents the assembled page back into the HTML application window.

So the interface is a web page displayed by the operating system's own HTML application host, which is also why the keyword list is so revealing. It includes the extension for that host, the command used to launch it, the Internet Explorer engine name, the HTML rendering component, the Windows Script Host, the script file association, and the language version.

The same list also includes the two terms security researchers use for built-in binaries repurposed as application hosts. The project classifies itself under them, which is an accurate description of what it is: an application that runs on the operating system's own binaries rather than shipping its own runtime. That is the feature, and it is also why an endpoint security product is likely to have an opinion about it.

## The dependency list is frozen in the era of HTML5 shims

The package manifest carries eleven runtime dependencies, and several of them exist only because of the host engine.

Two are explicit shims for a browser that predates HTML5: a canvas emulation library for systems with no canvas support, and a HTML5 shiv that teaches old browsers to recognise HTML5 elements. A feature detection library sits next to them, which is the standard combination for making a modern page run on an old engine.

Then there is a scripting library, its user interface components, a form plugin and a notification plugin, all at versions that belong to the same era. Those four are the bulk of the dependency surface, and they are there because the host provides no module loader, no DOM conveniences and no promise implementation, so everything a modern page expects has to arrive as a library.

A polyfill bundle is present for language features the engine lacks. Two entries are data concerns rather than interface concerns: a YAML parser and a query builder, which is a small SQL construction library. Having a SQL builder inside a desktop application framework is unusual, and it says something about what this framework is used for.

None of this is criticism of the dependency choices. Every one of them is the correct answer to running modern code on an old engine. The point is that the dependency set is not going to change, because the reason it looks the way it does is the reason the project exists.

## Two licences, and the second one exists for a stated compatibility reason

The licensing note is the clearest signal about what this project has to contend with.

The default licence is GPL version 3.0. Then there is a qualification: if that licence is not compatible with Microsoft products, the project is subject to the Microsoft Reciprocal License instead. Both licence files are present at the repository root, and the manifest records the pair in a single field as GPL-3.0 or MS-RL.

That is a dual licence created by a specific problem. A framework whose entire premise is running on Microsoft's own script host, whose graphical layer is Microsoft's own HTML application component, and whose target list includes operating systems shipped before Microsoft relicensed anything, has a genuine incompatibility problem with a reciprocal licence. Offering an alternative rather than picking one is the practical resolution, and the condition is written into the licence grant rather than left to interpretation.

For a user this means one question to answer before you build on it: which of the two terms applies to your distribution, and in particular whether the Microsoft reciprocal terms, which carry source disclosure obligations, are acceptable in your context.

The rest of the project's paperwork is unusually complete for its age, with a conduct policy, a contributing guide in two languages, a security policy, an agent instruction file and a citation file with a DOI pointing at an archived deposit.

## The manifest is eleven patch releases behind the newest tag

The manifest declares version 0.2.7.50.

The newest tag is 0.2.7.61, dated 2026-08-23, and the one before it is 0.2.7.60 from 2026-08-17. So the version you get from the repository is eleven patch releases behind the version the releases describe. Anyone installing from a release and anyone cloning the branch are running different builds with no marker on either side telling them so.

The gaps between tags are also uneven. The two August 2026 releases are six days apart, while the tag before them, 0.2.7.57, is dated 2025-12-01. That is roughly eight and a half months with no release, followed by two in a week, which suggests releases follow a batch rather than a cadence.

The version scheme itself is worth noting, because it encodes the shape of the thing: three components where the last one runs to fifty and above. A project that supports everything from Windows XP forward accumulates compatibility fixes for two decades of engines, and a three part patch number with a high final component is what that looks like.

The default branch is also the older name rather than the modern one, which is consistent with a project whose earliest supported operating system predates most of the current tooling conventions.

## Four transpilers, no install step, and a piped PowerShell bootstrap

The specification section is where the project is most confident, and the claims are specific.

Four transpilers are built in, named as TypeScript, ReScript, CoffeeScript version 2 and LiveScript. They are described as built-in rather than as plugins, so there is no toolchain to install and no compile step: the host reads the alternate syntax directly.

That is the mechanism behind the no-installation claim. A machine with nothing but Windows on it can run a TypeScript file, which is the difference between this being usable on an old controller and being a developer tool that happens to deploy as one.

The installation story is where the confidence softens. Alongside a downloadable launcher archive there is a PowerShell one-liner that fetches a bootstrap script from a blob store and executes it, which is a piped remote script by any other name. There is also a mention of deploying through the Microsoft Azure Marketplace, marked as available again soon, which tells you the primary distribution channel for this project is currently unavailable.

The signing story is better than either. The acknowledgements credit a free code signing programme with a certificate from its foundation, so the binaries are signed, which is worth noting next to the pipe-to-shell bootstrap: the artefact is verifiable, the installer is not.

The repository also carries a service installer, an uninstaller, and an interactive service starter, so the framework is expected to run as a registered Windows service as well as from a console.

## Conclusion

WelsonJS is worth a look if you have to automate Windows machines that cannot be upgraded, because the support floor and the absence of any runtime installation are real advantages and there is no modern alternative to either. Two things to weigh before committing. The graphical layer depends on a component Microsoft has deprecated, so it is the part most exposed to a future Windows release retiring it. And the manifest version is behind the newest tag, so anything you automate from source is not the build the releases describe.

## FAQ

### Which Windows versions does WelsonJS support?

Windows XP Service Pack 3 or later, with the note that it is currently tested on a recent release. Machines on Windows 2000 or earlier, including the oldest consumer versions, are handled separately by contacting the maintainers.

### Does WelsonJS need any runtime installed?

No. It runs on the operating system's built-in script engine, and four transpilers are built in, so TypeScript, ReScript, CoffeeScript and LiveScript sources run without a separate toolchain. The documentation states that no additional software installation is required on a Windows machine.

### What licence is WelsonJS under?

Dual. GPL version 3.0 by default, and the Microsoft Reciprocal License if GPL 3.0 is not compatible with Microsoft products. Both licence files are in the repository and the manifest records the pair as GPL-3.0 or MS-RL.

### What is the current WelsonJS version?

The newest tag is 0.2.7.61 from 2026-08-23, while the package manifest declares 0.2.7.50. A clone of the branch is therefore eleven patch releases behind the newest release.

### How does the WelsonJS graphical interface work?

An HTML application file is opened by the operating system, loads the script, which requires a web loader that pulls in an index script, an HTML file and a stylesheet, and presents the assembled page back into that window.

### What does WelsonJS declare as its runtime dependencies?

Eleven, including HTML5 shims for the old host engine, a feature detection library, a polyfill bundle, a scripting library with its user interface, form and notification plugins, a template library, a YAML parser and a SQL query builder.

## Sources

- [gnh1201/welsonjs on GitHub](https://github.com/gnh1201/welsonjs)
- [License: GPL-3.0](https://github.com/gnh1201/welsonjs/blob/master/LICENSE)
- [Project website](https://welson.js.org)
- [README](https://github.com/gnh1201/welsonjs/blob/master/README.md)
- [Releases](https://github.com/gnh1201/welsonjs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gnh1201-welsonjs