The path through language design

I took a few hours to work at modifying the NekoVM boot so it’s possible to create standalone binaries.

The idea is first to link the bytecode (using the -link neko compiler parameter). This will look for all $loader.loadmodule("constant string",$loader) calls inside the bytecode, and will replace it by the corresponding inlined module. It works very nice with NekoML and MotionTypes, and should work for all other languages that are using such statements for module resolution, which is the normal way of doing things.

neko -link myapp.n MyModule

The output is one big linked bytecode file that shouldn’t need any other .n bytecode library anymore. Only in the case there is unpredictable loadmodule calls, then theses are left as-it and the loaded bytecode files are needed.

Then a simple Neko program called nekoboot will concat the NekoVM boot with the linked bytecode, and modify at some place a special value that is storing the filesize so it can access to it. At runtime, since the filesize is defined, the boot will load the module directly by reading itself instead of taking an argument. You only need std.ndll that is required by the boot loader, and of course the VM library (neko.dll or libneko.so) and other ndll C libraries that you are using.

nekoboot myapp.n

This will build a myapp.exe (or without extension on Linux/OSX) standalone binary.