It takes a while to start up though.
Have you heard of the DOS port of MicroPython?
It exists, but doesnt have the stdlib.
I have built a binary of python3.11 for DOS, but it will not work, because it cannot import the encodings module which is truncated because of 8.3, that issue is also present in rustpython-nofreeze.exe, but rustpython will still run.
I have tried MicroPython a little, but managing the subtle differences tends to throw me, especially since I update DOS scripts only irregularly.
The LFN issue is funny! I do know that the older available PYTHOND.EXE also returns
>>> ImportError: No module named encodings
on `import encodings` unless I run DOSLFN.EXE beforehand.
I think I understand that your *nofreeze.exe is the fast version of the application,
and requires DOSLFN, the standard library in a separate directory structure, and specified with %PYTHONPATH% for `import encodings` to work.
Anyway, your *freeze.exe application has no external dependency aside from standard DPMI extender, is portable, and is great for my usage. Half a minute to start up in a virtual environment
is perfectly fine, since I develop the system administration scripts on a more modern machine anyway.
With DOS, I personally am interested in hobby graphics applications, but I know the platform still appears in business applications such as point-of-sale terminals, for supporting legacy file formats, or by professionals in a niche field that prefer a specific workflow, like with the 16-bit versions of ArcView.
This uses https://github.com/turbolent/w2c2 to convert RustPython,
built for the wasm32-wasi platform, to C89, which is then compiled with DJGPP and linked to the w2c2 wasi runtime library.
rustpython-nofreeze.exe is built without the freeze-stdlib feature, so it does not have the stdlib.
rustpython-freeze.exe is built with freeze-stdlib, so the standard library is there and usable.
Both need CWSDPMI.EXE, to provide the 32-bit runtime.
