On Sun, Jul 10, 2022 at 5:03 PM Nico via Freedos-user <freedos-user@lists.sourceforge.net> wrote: > > hi, > I would like to create a minimal bootable image for a USB drive (or > other formats, maybe even floppies, but USB is the focus) that boots > into a single application (in my case, a custom minimal word processor, > although freeDOS EDIT is a decent start for what I want) to create a > kind of "typewriter on a USB drive", that will work on any hardware you > throw it at and provide an environment for writing in. (I understand > that this is very niche) > > freeDOS seemed like an ideal platform for this to me, as it seems small, > boots very fast, runs on all kinds of PC hardware, lets me develop my > application in C without having to go bare-metal, etc. > > I understand that freeDOS can be installed from a booted USB drive, but > could I create a custom USB image that, instead of containing the > installer, contains my small word processor which starts at boot? Or is > freeDOS not a good base for this utility? >
Yes, you can definitely do this. There are two ways you might do this: 1. Install FreeDOS, and add your word processor as the last line in FDAUTO.BAT, so that it always runs the word processor when you boot. Let's say you wanted to run FreeDOS EDIT every time FreeDOS boots up. You would put this line at the end of FDAUTO.BAT: EDIT 2. If you *only* need to run the word processor, you can create a custom FDCONFIG.SYS and list your word processor as the SHELL variable. I wrote an article showing how to do this as an "embedded" system: (An embedded system is basically a very minimal system that is dedicated to run a specific task.) https://opensource.com/article/21/6/freedos-embedded-system Let's say you wanted to run FreeDOS EDIT every time FreeDOS boots up. The full path to EDIT is C:\FREEDOS\BIN\EDIT.EXE, so you would create a custom FDCONFIG.SYS that probably looked like this: FILES=20 BUFFERS=20 SHELL=C:\FREEDOS\BIN\EDIT.EXE For #2, see also this note at the end of the article: > However, there's one limitation here. Embedded systems do not usually need > to exit back to a command prompt, so these dedicated applications don't > usually allow the user to quit to DOS. If you manage to exit the embedded > application, you'll likely see a "Bad or missing Command Interpreter" > prompt, where you'll need to enter the full path to a new shell. For a > user-focused desktop system, this would be a problem. But on an embedded > system that's dedicated to doing only one job, you should never need to > exit anyway. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
