Regarding exiting the program. What about wrapping it in endless cycle?
Only hard reset or shutdown would break it. Something like while (true) {}
? Or just put it in bat multiple times, so if you exit, it start again and
user will ignore it few times :-DOn Mon 11. 7. 2022 at 1:23, Jim Hall <jh...@freedos.org> wrote: > 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 >
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
