Michael, I'm with you on this! In fact, I had had some previous
thoughts on the subject (see attachment). Let's prove that Bill G.
was right when he said "640K should be enough for anybody.".
Of course, with the web, that can't include data files, but we
can profit by Intel's accident when they hacked the "PM" atrocity and
use "flat real mode" memory.
I made a nice living for quite a few years, several of which in-
volved assembly-language programming for various processors, including
several of Intel's. I am now involuntarily retired and would welcome
the chance to work on a web browser. It seems to me that a browser is
the supreme challenge for what I would call a "useful" program for the
average computer user.
Ken Martwick
<PRE>
<HEADER>
<H1>Programming a Web Browser- a Contrary View</H1>
</HEADER>
<BODY>
When I began my search for a DOS-based web browser,
it was my thought that it would be substantially faster
than a Windows-based (either X or MS) browser because of
the elimination of the overhead of PM and the windowing
code. The only such graphical browser I have yet seen
is Arachne; it is not presently as fast as I had hoped.
I suggested to Michael Polak that the use of FRM memory
could greatly boost the speed of Arachne, but he wasn't
too impressed with the idea even though I wrote a small
interrupt handler for him and a demo program showing it
to be compatible with Borland C/C++ 3.1. He did state
that the memory-management code had not been optimised.<P>
Still, this got me to thinking about "modern" pro-
gramming practices and compilers. For a quick test I
tried the classic "Hello world" program. My "B-Flat"
compiler produced a program of about 3900 bytes, "bcc"
about double that and "gcc" v.2.8.0 for DJGPP came out
with an 84K program. That would surely slow one down!<P>
So, taking the web-browser as a good example of a
program that is at least as complex as any the typical
PC user would likely encounter, what can be done to in
crease the speed of such a program?<P>
Perhaps the most important step would be to find
or create an efficient compiler. An alternative would be
the use of assembly language, but the sheer complexity
inherent in the web-related protocols would result in a
truly monumental task. "B-Flat", as it is now, wouldn't
make the task very much easier. It could certainly be
extended to be more useful.<P>
If possible, do all memory management within the
program. Unneeded system calls can be a big penalty.
The "core" program that is called first (after the con-
nection is established) should be a "com" program that
inherently "owns" all free memory. All large data blocks
should be in FRM memory. No external "memory-management"
programs (e.g. "himem.sys") should be used.<P>
Since (at least) several auxiliary programs would be
needed, maximum efficiency would result if they could be
written as far procedures to be called by the "core" pro-
gram as needed. While a DOS call would be needed to read
the program into memory, at least some could be kept there
for later use. The others could be quickly swapped to FRM
memory and as quickly be restored as needed. Note that each
of these programs must save the caller's DS register, set DS
to equal CS, and restore the caller's DS before returning.
If the auxiliary program sets up its own stack, the same
conditions apply for the SS and SP registers. Compiling the
programs in the style of "com" programs (starting at 0x100)
would allow a "command tail" and other information to be passed.<P>
Ken Martwick 1/4/2000
E-mail: [EMAIL PROTECTED]<P>
</BODY>
</PRE>
