cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1997/09/29/11:17:40

From: mfb AT mbunix DOT mitre DOT org (Michael F Brenner)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: A DJ Web Browser
Date: 29 Sep 1997 14:12:00 GMT
Organization: The MITRE Corporation
Lines: 54
Message-ID: <60ocvg$t6m@top.mitre.org>
References: <Pine DOT A32 DOT 3 DOT 93 DOT 970926192035 DOT 33634A-100000 AT lausd DOT k12 DOT ca DOT us> <342DB71E DOT C33F119A AT uni-bremen DOT de>
NNTP-Posting-Host: mbunix.mitre.org
Summary: Do it, it would raise the level of the djgpp tools
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> DOS web browser

Yes, lets do it. It would significantly raise the level of the
djgpp tools. It would require slight improvements in the compiler,
run time libraries, keyboard interrupt handler, VGA codes,
serial interrupt handler, and mouse drivers to make them meet
hard realtime deadlines, and act a tiny bit more in parallel.
While several serial and VGA drivers and numerous keyboard links are
available for use with djgpp tools, there is not a single set which
works together to guarantee meeting realtime deadlines. 

The problems required to make this happen are the same which make
it difficult to write any other realtime systems, such as 
embedded systems, robots, and Ada compilers. Ada has requirements
which are difficult to meet under DOS because DOS itself is not
reentrant, nor was DOS designed with meeting realtime schedules
in mind. The Ada requirements are equally applicable for C, C++,
and Java. These requirements appear in ANSI Standard 8652:1995,
Appendix C (Interrupt Handlers), Appendix D (Hard Realtime Deadlines),
and Appendix E (Net Communication, including remote procedure
calls). 

Unfortunately, there are other details, including writing a kernel
to compete with Windows NT, enhancing the above drivers to work
with each other and the kernel, working around the non-reentrancy
of DOS, integrating all of the realtime system related patches into a
single configuration of the compilers and libraries, implementing a
method of noticing when the system is hung and giving the user an
alternative, re-implementing many DOS interrupts as 32-bit protected
mode handlers to that they are no longer over-written when user 
programs go haywire, eliminating purposeful infinite loops as the
method of choice for indicating errors instead of throwing 
an exception, permitting parallel disk operation, making an easy
interface to permit executing other EXE files without the 
possibility of clobbering local variables.

While all of these things would be nice to have, the number of
volunteers it would take would be about 16 staff years. An 
alternative, of course, is to just do the user interface using
the existing drivers and put up with the memory leaks, mouse
hangs, unreliable deadlines, unlimited waits, infinite loops, 
lost data, and undocumented bugs. This could be done in less
than a staff year. However, there is already enough commercial 
software out there providing these problems, so the free software
community should pick projects it can complete successfully, 
that is, with a minimum of the above problems. In summary,
the tremendous speed and price advantage of DOS over Windows
makes a DOS web browser a useful project, and it would require
the same upgrades to the free tools which are needed by many
other projects. However, it would take quite a bit of effort
to make those upgrades.

Mike Brenner

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019