From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alfonso Subject: writing programs for ELKS Date: Fri, 7 Feb 2003 13:22:27 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <200302071322.27842.a.martone@retepnet.it> References: <200301301341.h0UDf5Z25323@preshak.recjai.ac.in> <200302011118.58025.a.martone@retepnet.it> <1044556130.1597.23.camel@Castle.goembel> Reply-To: a.martone@retepnet.it Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Return-path: In-Reply-To: <1044556130.1597.23.camel@Castle.goembel> List-Id: Content-Type: text/plain; charset="us-ascii" To: linux-8086@vger.kernel.org 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.