RE: RE: Why the call instruction points 2 bytes before to the realstart sub-routine - MS-DOS

Hi:
Thanks again for your response:

The IPL program is working fine in botting time (not O.S. present).
Booting from a diskette. The IPL is mounted to the first sectors of the
diskette using rawrite tool. In VMWARE is working too. IPL is coded in
assembler, and I can call SW interrupts, 0x13 for disk, 0x10 for video
and so on. The IPL works fine.

In the last hours I read documents about switching 32 bits mode, these
is very complex for the purpose, and in this way, please, tell me what
16-bit "C" compiler (decent whit support) I can use for write a small
Operating System for educational purposes?

Thanks for your time.


Att.
Diego Cueva.

-----Original Message-----
From: Hans-Bernhard Broeker [mailto:broeker@physik.rwth-aachen.de]
Sent: Wednesday, November 02, 2005 12:53
To: djgpp@delorie.com
Subject: Re: Why the call instruction points 2 bytes before to the real
start sub-routine ?

Diego Cueva wrote:

> com file not are my final objective. My Objective is creating a small
> operating system to educational purposes, and I need compile C
programs
> with GCC that can execute in booting time.

In that case, .com files are not just not your final goal, they're not
even likely to be particularly useful as a stepping stone getting there.

Code compiled by the DJGPP version of GCC strictly assumes a DPMI-like
environment. You'ld have to recreate basically all of a DPMI server,
and large parts of DOS, before this code will run reliably. To get an
idea of what that means, have a good look at the CWSDPMI sources.

It might end up being easier to embed FreeDOS, CWSDPMI and your
program into a single binary image, instead.

> To this moment I have a IPL program with a group small routines in
> assemble compiled/linked with "as/ld". This is working fine.

Working fine in what kind of environment? Called from DOS?

> But link that with C compiled code is the WALL to climb now.

Exactly. Wherein "WALL" is not just some bedroom wall or something
--- it's more like the Eiger North side.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.


TODO1 SERVICES, INC. -TODO1- es la propietaria de la información contenida
en este mensaje y sus anexos, que puede tener carácter confidencial y ha
sido enviada para uso exclusivo del destinatario intencional. Si usted ha
recibido este mensaje por error, por favor informe de ello al remitente a la
mayor brevedad y elimine este mensaje y sus anexos. Está prohibido su uso,
distribución, divulgación o almacenamiento, salvo autorización escrita de
TODO1. Todo mensaje enviado y/o recibido por TODO1 es monitoreado por
motivos operativos y actuando de acuerdo con prácticas de negocio y de
seguridad legítimas.

TODO1 SERVICES, INC. -TODO1- is the proprietary of the information contained
herein and its attachments, that may have confidential character and has
been sent to the intended recipient only. If you are not the intended
recipient, please contact the sender immediately by replying to this e-mail
and delete the message and its attachments. The use, forward, disclosure,
record or retention of this message for any purpose whatsoever, is strictly
prohibited, unless prior written authorization from TODO1. E-mails to and
from TODO1 are monitored for operational reasons and in accordance with
lawful business and security practices.

Diego Cueva wrote:

> In the last hours I read documents about switching 32 bits mode, these
> is very complex for the purpose, and in this way, please, tell me what
> 16-bit "C" compiler (decent whit support) I can use for write a small
> Operating System for educational purposes?

This is drifting seriously off the topic of this newsgroup, but here
are the two most prominent options you have: Turbo C 2.0 from
Borland's collection of antiques, or OpenWatcom. Only the latter has
any kind of support worth speaking of.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.