He's been impressed by the "naked beauty" of DOS/Unix times. The first thing he wants to be achieved is a blinking cursor after a ">" symbol so that he can type commands. No matter if there's no way to start 2 programs at the same time: he just needs a text editor and a FAT12 driver. Maybe you prefer a different approach.
Reaching Lino's level
A first shell
- Your first goal is an improved keyboard handler. Everything will start there. Make sure you leave room for a keyboard map (for instance easily compilable apart and loaded as a module by GRUB so that beta-testers can load their own map).
- Don't echo characters right from the start and keep track on what's on screen. Commands histories, completions and working character erasure will be a must.
- just put a few "built-in" commands from the start, but keep your mind open to "how will further shell extension add commands?"... scanning a table rather than a switch statement? you're the one who knows.
- Decide what programs will look like. The easiest model is to give them one data+code segment and let them run there.
- Your programs will have to come from somewhere. Lino had used one GRUB module as a 'ramdisk' where programs were stored (he didn't tell whether using FAT or something even more simple for the internals). What is certain is that program see them as "real" files.
- Provide your programs a simple API: open/close/read/write to files, read/write to the console, exit are enough at the start. Prevent your programs from writing directly to video memory.
Real shells have parameters, environments and such things which can be easily defined as read-only segments. If your favourite language doesn't like multi-segments, add a library that will copy strings in a buffer at request.
Once this is done ask yourself how you'll start other programs from one program. This means implementing the system(8) call.
Going further than Lino
Well, in many aspects, Lino's OS looks like first steps of most Unix clones.
Because of the simple "start at offset 0 in CS/DS" approach, whether multiple programs share the same address space or not is not much complicated, but Lino still has to write multitasking support, which will require him a more sophisticated way of allocating and freeing memory
Most books on the market will probably not be of interest (since they discuss "superfluous" things, like UNIX and multitasking). He'll probably look at "FreeDOS Kernel" by Pat Villani and that would be enough. And sure, you can have some of the old volumes of MS-DOS reference manuals and infinite books by Dan Gookin lying around somewhere, don't you? And heck, why not, let's add "Inside The Windows 95 File System" by Stan Mitchell or Microsoft's FAT specification. And yes, most importantly, is The Peter Norton Programmer's Guide to the IBM PC, which is appropriate for the time.
Lino Commando's opponents position
The issue with Lino's approach is that he risks facing the same problems as DOS did: monotasking, too tight coupling between programs and hardware, etc. Despite how good Lino's OS project may be, he'll have to make sure that he studies sufficient abstractions right from the start and that he can't forget that one day he'll want more than one program to run.
- Inflater: "That's me alright :) I just don't have fully working FAT12 driver for my real mode 16-bit Borland Pascal OS :D)"
- Piranha: "Me too. Who needs graphics at this stage! Just making the internals work right is hard enough!"
- Troy: "Text mode calls to me like bananas call to monkeys. Except with me there's no flinging of poo."
- iMate900: Lino, here I come kicking myself with SauOS!!!! Oh, and I'm not even finished with my ATA driver :)
- KotuxGuy: Yeah, this is most likely me too ;) I don't have any filesystem support though
- bellezzasolo: This is always the best way to start. Nice if it's a PMode shell though ;)
- LifeDJIK: Yes! That's definitely me! But I don't have FAT12 driver... I have FAT32 driver!
- Moondeck: Graphics? VGA? Who needs that crap, I use serial!
- Insert your name here