writing programs for ELKS

[Alfonso <a.martone@retepnet.it>]

Hi!!

I got a bunch of emails about my last messages, and try to answer to 
all questions here.


Re-entrancy: DOS system calls are not reentrant. This means that common 
DOS multitaskers (like DESQview) either emulate them in a reentrant 
manner (e.g.: reading a byte from the console is not that hard, but 
DOS makes it non-reentrant), or multiplex them with semaphores.

ELKS system calls are reentrant, because a task-switch can happen in 
every moment. As in every multitasked system, the calling process will 
be put to "sleep" while waiting for I/O (and, sometimes, while waiting 
for other higher priority operations).


Using Turbo C under ELKS means that we are accepting Turbo C limits 
(i.e.: the "int" type is 16 bit; features like floating-point math and 
overlay structure cannot be used without extreme special care, etc).

I did not consider Turbo Pascal because I do not know well its code 
generator and linker. The generated code must NOT contain far calls 
("extrasegment" calls) or interrupt calls. By using the "small" memory 
model, I am sure to have only one code-segment (upto 64k) and only one 
data-segment (upto 64k) without any need for segment override. That 
is, the program should never need to change the values in CS, DS, SS 
and -maybe- even ES (I cannot be sure that even the simplest Turbo 
Pascal program follows this rule). This is the reason why I defined a 
"clean" program to be an "upto 64k text, upto 64k data/bss/stack", and 
should not make any assumption about location of code segment, data 
segment, free memory, etc.


BSS means "bottom-stack space", and is the uninitialized space 
following the last byte of defined data. ELKS kernel wipes out it 
before starting the process, so that the uninitialized global arrays 
and variables are guaranteed to be zero-filled at the beginning. This 
is not always true in other environments, where BSS space is left 
uninitialized (so that the "startup code" has to wipe it... or, 
simply, warn the programmer that uninitialized data surely contains 
rubbish), and this is why C manuals warn about initialization.


In Linux and every other multitasked system processes are allowed to 
use memory only asking for it to the kernel. A task can use only what 
the kernel allowed for. Under Linux, if you try to access (even for 
reading a byte) other memory, the kernel gets an "exception" and kills 
the task before the operation is done (well, the signalling system is 
more complex, but it's guaranteed that any non-root process actually 
can't read and write anything out of explicitly authorized memory 
segments, files, etc).

ELKS cannot guarantee it, at least in the 8088/8086/80186 processors, 
because they do not have any memory protection instruction. An ELKS 
system has no true protection scheme (that is: it could be attacked by 
a decently written virus, even from a process without full root 
permissions), but remember that the "E" (embeddable) of "ELKS" means 
that you won't use it as a "let's try some dozens of new programs"...! 
Surely you will (re)build the entire system when you will add new 
changes...!
And - also - if you get a source program, you can check yourself if it 
does contain worms or viruses. This is the main reason why the viruses 
are an almost unknown phenomenon in the GNU-based world.


Yes, Turbo C is a nice thing, but, as everyone here, I like much more 
GPL-licensed software.