First post, by ssokolow
- Rank
- Member
One of the hobby projects I've started to poke at again (mind you, very slowly) is an effort to build an installer builder for DOS. (InnoSetup, NSIS, WiX, and MS Setup 2.0 serve everything from Windows 3.1 onward, but I couldn't find anything for DOS that was both legally free and as polished as the professional installers of the period.)
Up until now, I've mostly been focusing on infrastructural bits where I don't need feedback. (writing the most compact alternative to graph.h that I can, finding some public domain unzipping code I can adapt to function in real-mode, surveying the sizes of period installers, etc.)
Now, I'm getting to the point where I need to start designing bits that would actually be experienced by other developers using the code to build installers, so I thought it'd be a good idea to start getting other people's input.
Since I'm taking a bit of a rose-coloured glasses approach to retro-nostalgia (trying to paper over things in the vein of "Really? Windows 9x didn't have Ctrl+A bound to "Select All"?), my goal is to have an installer that, like InnoSetup 1.2.x for Windows 3.1, is a single-file distributable rather than a Zip or self-extractor containing loose installer files.
Here's my idea so far:
- Use Open Watcom C/C++ and a real-mode target with my own hand-tuned library of functions (many wrapping inline assembly) as a compromise between ease of development and size. (My research shows period installer sizes cluster around 15K or 50K and using DPMI or graph.h starts me off at a ~35K Hello World while I can get a very fancy-looking Hello World as a test for a set of INT 10h API wrappers in 1.6K with real-mode Open Watcom and it makes it trivial to support both cross-compilation and building on genuine hardware... 996 bytes of which is the Open Watcom C runtime at the smallest size I could accomplish.)
- To make installers easy to distribute yet easy to pick apart, design the runtime as a Zip SFX stub that pulls human-readable control scripting from a scripts folder inside the Zip file.
- To keep parser size down, have a compiler which converts InnoSetup-style declarative project definitions into an imperative scripting language designed to be easy to parse with minimal code.
- To allow reusing syntax highlighting definitions and to share the tokenizer between the argument parser and the scripting interpreter, make the internal control scripting DOS batch syntax with a different set of internal commands.
- To save on code footprint, using trees of folders inside the Zip file if a hierarchical key-value store is needed.
- To allow debugging and unit testing, implement a command-line flag which writes status messages to a specified file, with COM1 being the default since DOSBox can map that to a telnet server for the integration test harness running on the host OS to connect to.
- For nostalgia and retro-utility, design it to be able to replicate the look and feel of iconic installers of the period by providing drawing primitives based on INT 10h functions and bundling theme definitions for the compiler which are just libraries of script functions which satisfy a certain API. (I've already taken reference screenshots for the vast majority of my installers.)
- Since the tokenizer will be doing half the work anyway in a language with no nested block syntax, I figured I might as well write a pretty-printing reformatter for the control scripting that could be hooked into something like ALE for Vim for format-on-save. (In which case, maybe I'll also add a switch to use it for reformatting .BAT files.)
- More modern standards for code quality through a judicious use of ifdefs to hide things like near and far from splint and cccc. (Already set up and part of the build process when the Watcom WMAKE Makefile is run on Linux.)
- Complete and polished Doxygen documentation (I take pride in how I document release-ready projects and, for something like the control scripting for the project, writing the documentation beforehand as a spec helps me to think through the implications of the design.)
- Some kind of unattented install mode... probably by designing the API such that every user prompt is bound to a named variable and having a command-line flag which pre-fills the variables from a file and skips prompting the user. (I'll need to think about ways to make this compatible with name reuse in the context of looping.)
I've also been thinking that it'd make a nice way to quickly and easily build pretty DOS menus if I provide support for having a menu selection result in "write selected command to a batch file and then exit" so the conventional memory-freeing trick for menus can apply.
So, the kinds of questions I'm asking you guys are:
- What kinds of things would you want to build with something like this?
- What do you think of the "Control scripting that looks like a cleaned up DOS batch file" idea?
- GOTO in DOS batch is nostalgic, but has the potential for ugly code and bugs akin to forgetting a break in a C switch. What's your opinion on supporting and promoting CALL :label as the recommended way, and having a label implicitly end the previous label's block? (ie. ":label" would have an implicit "exit /b" before it when CALLed and the reformatter would treat ":label" as akin to "def label() :" in Python... whether it'd indent the block body would be something I'd have to experiment with.)
- Which do you find more unpleasant? Syntax highlighting where the list of valid keywords is significantly divergent from the language or a language that looks familiar but has the keywords behave differently? (eg. possibly having ERASE affect the screen rather than being a synonym for DEL or having VOL prompt to swap disks.)
- How important is multi-volume (ie. floppy disk set) support to you?
- There are a lot of three-letter extensions that FILExt has no entries for either beginning or ending with IH which could be used for things like ".tih = Theme for ..." and ".cih = Control Script for ...". What do you think of a name like "Installer4H"? (With a FAQ explaining that it's short for something like "Installer for Hobbyists" because, with Intel phasing out support for non-UEFI boot, hobbyists are the only people who care about writing new things for DOS anymore.)
- ...other questions that will no-doubt reoccur to me when I'm not struggling with being over-tired.
Internet Archive: My Uploads
My Blog: Retrocomputing Resources
My Rose-Coloured-Glasses Builds
I also try to announce retro-relevant stuff on on Mastodon.