search

evmar / retrowin32

windows emulator
https://evmar.github.io/retrowin32/
Apache License 2.0
578 stars 24 forks source link

Web/Desktop client SDK with samples #38

Closed mateli closed 1 month ago

mateli commented 2 months ago

To develop client applications that run on both web browsers and desktops are difficult today. One can use C/C++ with emscripten and various other C/C++ compilers and create WASM, windows binaries, Linux binaries etc. However this adds a lot of extra work and for that and there aren't really any "compile once run everywhere" solution.

To enable developing win32 applications that can take full advantage of all API:s provided by browsers while also allowing the same applications to run on legacy windows the idea is to create both native and emulated DLL files for such api:s.

WASI api:s can for example be called wasi-apiname.dll. When running on retrowin32 calls into such a dll can run on native code and in the browser be a thin layer to the browsers api.

For web applications the first thing that retrowin32 needs to add is communication support. Wasi-sockets does provide primitive tcp/udp communication and wasi-http provides up to http3 communication however neither of those (i may be wrong here) supports websockets/webtransport and similar that can be very useful when writing web applications and tunneling of communication trough a web server is required.

For game development the current web technology is WebGPU which is often used together with SDL2 to create games that can run both in the browser or native

Here is a full list of API:s that are available in modern web browsers: https://developer.mozilla.org/en-US/docs/Web/API

Wasi API:s https://wasi.dev/interfaces

It is also possible to make a long list of things that are commonly used in applications such as zlib/zlib-ng for compression that benefits a lot from being an emulated dll instead of running inside the emulator. Creating both windows-native and emulated dll-files and thereby making them part of a "retrowin32 API" allows for writing fast and modern applications that uses retrowin32 as a virtual machine and if all the heavy lifting is done by such API:s then the execution speed of the 32 bit windows exe file doesn't really matter. Such API:s should be as abstract as possible wo that it is not to heavily tied to a current implementation. For the zlib example some host platforms may work best using zlib while others work best with zlib-ng. Fortunately zlib-ng is written to be a drop in replacement for zlib.

Why can retrowin32 as a virtual machine/portable executable runner succeed where Java and others failed?

  1. It looks and feels very familiar...
  2. No browser plugin are needed as retrowin can leverage existing browser technology like JavaScript, wasm, WASI, WebGPU etc. That could of course also be leveraged for running Java applications in the browser but no one is doing that.
  3. Retrowin32 can already run in a browser and on desktop platforms using a single executable (excluding retrowin32 itself of course).
  4. An extensive API can be built by wrapping existing C libraries. Python is similar in this aspect.
  5. Existing developer tools can be repurposed. Such as any compiler that can target Win32.
  6. Java started to focus heavily on JIT compilation at the cost of not producing a rich set of API:s that run as optimized native code. Python did the opposite and has become immensely popular. So let's do it the python way and create an extensive and fast API.
evmar commented 1 month ago

I think if you're trying to make a binary that runs anywhere, targeting wasm directly is better than targeting 32-bit x86. retrowin32's emulation of x86 is necessarily very slow, while wasm is designed to be able to run quickly. People now run wasm outside of browsers (which is where wasi runs for example).

From that perspective, what I think you're then talking about here is providing web implementations of wasi modules, which seems like like a cool idea, but probably one that someone else is already investigating, and pretty far out of scope for retrowin32.