Basically, take your application framework of choice - in my case its JUCE (C/C++) - and embed a Lua VM in it. Put the UI in the framework, and then encode all of the program logic and application control flow in Lua, which marshals the UI and the rest of the system through the VM interface.
Sure, you can just 'do everything in C/C++', but I've found that for long-term projects, doing app logic in Lua, a simpler language to wrangle, has been very fruitful. And, it puts the framework in an interesting context - serving the VM - which reduces bugs and keeps things pretty tidy. Most of the C/C++ code is just UI and system-level scaffolding - which I then write Lua tests for - and then once this is in place, the app logic is very productively developed and shipped as byte code. The App becomes a host for the logic.
I am not sure this is the same kind of thing.
In Redbean, you have a single executable that runs on any Operating System (that's right, the same executable file, this is enabled by CosmopolitanC) and that executable has a SQLite DB inside that can be used by the Lua code, which is also itself inside the executable file, and it can be modified at will and still run.
I think most people don't realize just how crazy this is. It's a lot more than LuaVM embedded in a "normal" C executable.
Comments
I don't have an article or blog post, alas.
Basically, take your application framework of choice - in my case its JUCE (C/C++) - and embed a Lua VM in it. Put the UI in the framework, and then encode all of the program logic and application control flow in Lua, which marshals the UI and the rest of the system through the VM interface.
Sure, you can just 'do everything in C/C++', but I've found that for long-term projects, doing app logic in Lua, a simpler language to wrangle, has been very fruitful. And, it puts the framework in an interesting context - serving the VM - which reduces bugs and keeps things pretty tidy. Most of the C/C++ code is just UI and system-level scaffolding - which I then write Lua tests for - and then once this is in place, the app logic is very productively developed and shipped as byte code. The App becomes a host for the logic.
Isn’t this similar to what Redbean does (which inspired this queriable executable idea), except that in Redbean the application is web server based?
Actually its a core feature of the Lua VM as an applicable technology - Lua is literally embedded all over the place.
My favourite other example is turboLua:
https://turbo.readthedocs.io/
I am not sure this is the same kind of thing. In Redbean, you have a single executable that runs on any Operating System (that's right, the same executable file, this is enabled by CosmopolitanC) and that executable has a SQLite DB inside that can be used by the Lua code, which is also itself inside the executable file, and it can be modified at will and still run. I think most people don't realize just how crazy this is. It's a lot more than LuaVM embedded in a "normal" C executable.
Do you have any problems with antivirus or Defender complaining about the embedded VM?
Never. But I deploy in controlled environments where my .exe is well known before install.
I think there are false negatives in some of the lesser-maintained antivirus tools - but I have never had issues with it.