Lino Commando: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
(moved inflater's comment)
No edit summary
Line 33: Line 33:
{{Stub}}
{{Stub}}
* Inflater: ''"That's me alright :) I just don't have fully working FAT12 driver for my real mode 16-bit Borland Pascal OS :D)"''
* 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 need graphics at this stage! Just making the internals work right is hard enough!"''

Revision as of 02:55, 12 March 2008

He's been impressed by the "naked beauty" of DOS 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

  1. 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)
  2. 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
  3. 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

Starting programs.

  1. Decide what programs will look like. The easiest model is to give them one data+code segment and let them run there.
  2. 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.
  3. 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.

More things

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.

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 systems support, which will require him a more sophisticated way of allocating and freeing memory

Lino Commando's opponents position

The default of Lino's approach is that he risks to face the same problems as DOS did: monotasking, too tight coupling between programs and hardware, etc. Despites Lino Commando's OS project may be good, he'll have to make sure that he puts sufficient abstractions right from the start and don't forget that one day he'll want more than one program to run

People and OSes related to Lino Commando

This page is a stub.
You can help the wiki by accurately adding more contents to it.
  • 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 need graphics at this stage! Just making the internals work right is hard enough!"