> 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)
Show quoted text 9 lines
> 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.
Show quoted text 8 lines
> 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 ( or )
