[fpc-pascal]OS develing.

[Marco van de Voort]

> > You can't.
> 
> Then how do I get it to link to an alternate?

- Create the alternate. (see also the "Internal" developper docs, which
  lists some of the external systems) 	 1)
  Also watch the name of the system unit.
- Compile the new system unit with -Us
- Now it will link with own made programs. Use special LD options
   to get the effect you want. You can get full control over assembling
   and linking by doing it by hand (use -s)
- Thoroughly test it.

> > See rtl/fakertl and rtl/template for examples of ultra tin System.
> 
> So RTL== System unit?

No. RTL is simply the base system as it is standardly distributed 
with the compiler. The rest are "extra" packages. 

The RTL mostly contains basic functionality, and often some OS 
specific base units. (like the Windows API definitions)

The System unit is a part of the RTL, and at the same time also the 
_minimal_ possible RTL.  ( minimal as in minimal number of units 
used, 1)

> > Note however that certain parts of the System unit are necessary for
> > certain language features:
> 
> > - Nearly all string handling needs external routines in System
> > - Certain Set operations do.
> > - coprocessor (floating point types)
> > - int64 handling
> 
> These, ofcourse stay...

Coprocessor handling and even routines might be system dependant, 
since your kernel may initialize the coprocessor in a different way. 

> Memory managment needs to be totally revamped though. =\

Don't forget that a linear address space for the basic segments is 
mandatory. Extra segments can only be used by extra code. (or via
the FS construct of Go32V2)

> Additionally, there will need to be system managment functions...

One first has to define the kernel -> program interface.

> > - File IO does, and with that writeln and readln.
> 
> File support is optional in my OS. This is the case so that all
> persistant storage schemes is equally well supported...

Standard IO to the screen also uses the concept of files in a limited 
way.

> > If you move certain parts of the system unit (like e.g. memory 
> > management, which is a "larger" part) to the kernel, the system unit
> > can be very thin.
> 
> In a standard OS, there needs to be a two-level memory managment scheme.
> A system/protection level, and an object level scheme. The system level
> providing hardware level protection and the object level being
> light-weight and quick.

I'm talking about the usermode interface, and the way how user and 
kernel mode memory management interact (how can the application 
request a block from the kernel)
 
Also some Delphi features (and maybe more code nowadays) needs 
a way to retrieve the size of an allocated block. This could be a 
consideration in designing your userland memory system.

var p : pointer;

getmem (p,1000000);
freemem(p);				// freemem must be able to deallocate P 	
	  			  	   without getting the size of the allocated block 
					as param. 

> Thanx for the pointers, I'll see what I can do with them.

Try to find Ozon OS on the net. I had some discussions with them 
about these subjects before.

> In Unix land, more is actually less.

Actually, no :-) There is a "more" and there is a "less". 

Some stupid Linux distro's might symlink more to less though.

> DOS is much more streight forward. ;)

Actually, I find protected mode programming easier than the old 16-
bit dos way.

One can program PM programs under Dos, but always has to 
consider 16-bit issues when interfacing with the kernel (io.sys, 
msdos.sys)

Marco van de Voort (MarcoV at Stack.nl or marco at freepascal.org)