WebRunLocal, now PluginOK, replaces the ActiveX control a browser no longer allows

A two-way bridge between a browser tab and a local Windows program

WebRunLocal, originally named with a Chinese trade name and now sold as PluginOK, is a middleware layer that lets a browser and a local desktop program call each other. The frontend interface is language independent, and the README is explicit that a web page only needs simple JavaScript to talk to the local side, which is the property that matters for a B/S system.

The problem it addresses is specific and old. For years the answer to calling a local program from a web page was an ActiveX control in IE, and the equivalent plugin technology in Chrome and Firefox. Chrome dropped NPAPI support from version 45, and PPAPI support was abandoned in 2022, which closed the door on browser plugin based integration for most businesses. Legacy systems that used those technologies could not keep working in current browsers.

The scope of what the middleware aims to cover is broad: hardware devices attached to the machine, operating system APIs, local DLL functions, and the embedding of ActiveX controls and desktop automation programs such as Microsoft Office, WPS Office, AutoCAD, SolidWorks and CATIA. The stated compatibility targets are Windows XP through Windows 11 on 32 and 64 bit systems, and Windows Server 2008 through 2025, with the embedded web applet feature listing Chrome 41 and later, Firefox 50 and later, Edge on the Chromium engine from 80, Opera 36 and later, IE 8 and later, plus Electron, Brave, Vivaldi, Yandex and a long list of regional browsers.

The author is Chengdu Zorro Software, sold and supported commercially under the ZorroSoft name, with a patent cited for the embedded web applet technique.

WebSocket and COM do the work, so no browser plugin is needed

Four arguments are given for using the middleware, and they are the real architecture.

The first is lightness. The package is small, it depends on no browser plugin or extension interface, and it needs no third party support libraries to run. The second is compatibility, and the mechanism behind it is the important part: the bridge uses the WebSocket technology from the HTML5 standard, so it does not depend on any browser extension API that a vendor can remove.

The third is the developer interface. On the Windows platform the middleware uses COM component technology to give the applet developer a friendly interface, and it supports most development languages. The fourth is packaging: the installation and upgrade of the small programs is configurable and flexible, and there is OEM support so a vendor can integrate the middleware into their own product line.

The use cases listed make the intent clear. A web page driving a local scanner, high speed camera, printer or card reader in a B/S office system. Calling a local ActiveX control or a VBA interface to embed online document editing and review. Using a third party DLL module from a page, such as a network phone library. Security controls for online banking and payment sites that need access to a USB key and certificates. And a decentralised distributed system that pools the GPU compute of scattered machines.

That last one is the most interesting for a systems reader, because it uses the same bridge to solve a different problem.

Three applet types, three different privilege models

The middleware supports three kinds of native applet, and the difference between them is a privilege decision rather than a technical detail.

The first is the DLL applet, implemented as an in-process COM component. It exists to wrap hardware driver libraries and Windows API functions with no interface of their own. This type runs in the same process as the main PluginOK service, which gives it a high level of system access, and it generally cannot reach the registry or configuration of the user currently logged into the desktop.

The second is the popup applet, an EXE with a user interface. It is an ordinary Win32 executable that wraps interface-bearing ActiveX controls such as printers, scanners and high speed cameras, and it opens a window that behaves like a web page. Its permissions are the same as any normal desktop application, which is the point: the user sees a normal application, not a privileged in-process component.

The third is the embedded web applet, also an EXE, built for continuous interface work such as video playback controls and office OLE windows, running inside the page the way an ActiveX control or NPAPI plugin used to in IE.

A team choosing between them is really choosing a trust boundary. The DLL type is the fastest and the most privileged, the popup type behaves like a desktop app the user launched, and the embedded type is the one that reproduces the old browser experience.

Embedding an ActiveX control in a modern browser has two routes with different costs

For the case that matters most in practice, an ActiveX control with a real interface, the middleware offers two technical options, and the README is refreshingly direct about the trade-off between them.

The first option calls an IE control applet or an IE new tab applet on top of the middleware to produce a programmable dual core browser. The stated drawbacks are high memory usage, low running efficiency and poor user experience; the stated advantages are low development cost and minimal frontend changes, and it is recommended when upgrading an old project.

The second option uses the embedded web applet development interface of the middleware, building an embedded applet wrapper on top of the ActiveX control and abandoning the IE core entirely. The stated advantages are low memory usage, high running efficiency and a better user experience; the stated disadvantages are a higher development cost and more frontend changes, and it is recommended for new projects, with the vendor offering a version that needs no development at all when some control parameters are specified.

There is also a path for the case where a desktop program has no source code and cannot be modified, since the newly released EXE web applet can embed those programs into a page, which is presented as the answer to converting a C/S system into a B/S one.

The honest reading is that the first option buys speed of delivery with an old engine, and the second buys a modern result with a rewrite of the embedding layer.

FireBreath, Node.js FFI and the plugin era are the comparison points

The README names two well known solutions for two-way calls between a browser and a local program, and explains why each falls short.

FireBreath is the prior art in this space, built on ActiveX and NPAPI. The stated problem is compatibility with browser versions released after 2015, and the project is described as abandoned with its website already closed. This is the solution the middleware positions itself as a replacement for.

Node.js is the other, and the objection is architectural rather than historical. Node.js is a JavaScript runtime built on the Chrome V8 engine, and its FFI module can call native C style dynamic libraries from JavaScript. The listed drawbacks are that running and deploying it depends on Python and npm, that 32 bit and 64 bit calls have to be handled separately, and that it cannot support object oriented component calls such as ActiveX controls, so it cannot merge with a web page the way the middleware does.

The difference in approach is therefore about where the bridge lives. FireBreath put it inside the browser as a plugin, and the browser vendors killed that channel. Node.js puts it in a separate process that JavaScript reaches through an FFI, which loses the in-page embedding and the object model. The middleware puts it in a local service that the page talks to over WebSocket, so the page only needs JavaScript and the browser needs no extension.

For a reader deciding between a maintained open source bridge and a commercial one, that architectural difference matters more than any feature list.

The repository licence and the vendor terms are two different things

The repository carries an MIT licence file, and the metadata records the project as MIT licensed. The README says something different about use: commercial use requires a paid licence, while non-commercial use, for a public interest organisation able to provide proof, can apply for a free authorisation. The middleware and the applets are developed and sold by Chengdu Zorro Software, and the README asks that questions about pricing and integration go through the vendor's WeChat contact rather than the issue tracker.

There are also separate terms for the applets themselves and for the third party components they wrap, and the samples in the Demo directory include Office, CAD, VLC and player applets with plain JavaScript and Vue versions, plus a note on packaging the Vue builds. The Plugins directory holds the officially developed applets for common application scenarios.

The directory layout separates the editions. Bin holds the standalone standard edition, with InstallWrl.bat to install the middleware, RemoveWrl.bat to uninstall it and StopWrl.bat to stop the service, and a TestWrl.txt for checking the standard edition. Net holds the network edition with the same batch files, WrlSDK holds the standalone SDK with interface documentation, sample applet projects and a packaging tool, and ZbaSDK holds the network edition SDK. The installer scripts at the root, including PluginOK_Install.iss, PluginOK_Net.iss, PluginOK_Office.iss, PluginOK_Player.iss and PluginOK_CAD.iss, are the Inno Setup sources for the various packages.

The release tags stop in 2023, with the newest listed at PluginOK22108 from July 2023, while the last push to the repository was on 2026-05-03, and the product history in the README runs to a major update in February 2025 covering multilingual installers and support for more browsers.

Editorial conclusion

WebRunLocal is worth a look if you maintain a Windows desktop system that has to run inside a browser, especially an Office, CAD or hardware vendor integration where an ActiveX control already exists, because the DLL, popup and embedded web applet types cover most of those shapes and the demo pages show the JavaScript side. It is the wrong tool if you need a cross platform bridge, if your application is a greenfield web product with no local component, or if your organisation cannot accept a commercial licence with a vendor contact requirement. Verify first which edition the package you are looking at contains, since the standalone Bin and network Net packages differ in features, and confirm the licence terms in the LICENSE file and in the vendor's terms before shipping anything built on it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wangzuohuai/WebRunLocal on GitHub