Long time ago, when WebODM was still in its infancy, Windows was still my (Piero’s) primary development platform. As such, the very first versions of WebODM used to run natively on Windows, without docker. But as time went on, with docker entering the development/release process, Windows compatibility was placed aside and focus was shifted on getting docker to work less painfully on Windows (spoiler, it’s still painful).
Despite knowing that in theory WebODM could work natively on Windows , I don’t think anyone attempted to prove it. We’ve added a lot of stuff to WebODM since its old Windows-first days. Dynamic tiling, GRASS engine, background worker processes, message brokers, plugin systems, Python environments… none of which take Windows as a first-class citizen.
Curiosity… would it still work?
Well, I’m happy to report that, after some tweaks, the answer is
Not exactly a trivial endeavor, but the result is quite seamless:
- Run the setup.
- That’s it, there’s no other steps. Just run the software.
Ok, admittedly this requires that you have a processing node running NodeODM somewhere else, as we still haven’t managed to compile/run the full processing pipeline natively on Windows, this is just the user interface, but it’s a really important step toward full native support for Windows (which we have long-term plans for).
If you are used to the docker experience of installing WebODM, you might be seriously impressed by the simplicity of this new option.
The engineering feat is also quiet impressive, because getting WebODM to run natively requires:
- A web server
- A message broker service
- Multiple worker/scheduler processes
- A database (with PostGIS)
- A single Python environment
- An installation of GRASS
- Lots of smaller Python/Node.JS dependencies to work correctly
In particular, issues of compatibility had to be solved between GRASS’s Python environment and WebODM’s virtual environment, as the two can run in the same process space, but Windows does not like that at all. Piggy-backing GRASS’s Python environment to run all of WebODM’s other functions turned out to be a good solution and removed the need for multiple Python environments.
The application setups all of these requirements (with careful consideration for security as well, where strong passwords need to be set to protect from untrusted local users), launches the necessary services in the proper order and wraps the application using Electron. Voila’!44