Mario wrote:

Makes me wonder how is it possible for an unknown German guy to create a browser that does the job of browsing so well with a 3MB application, while Netscape 6 requires 24MB?

Simple: Most computers today have so much RAM they encourage programmers to waste resources out of laziness.

Here's a little background on computer programming in the 1980s that should help illustrate my point:

Back in the early 1980s most computers had 64 or 128 KILObytes of memory. Some PCs had 640K, but that was about the most RAM you'd EVER see in a computer of that era.

In fact, some computers, like the Commodore VIC-20, had as little as FIVE K of memory. To add insult to injury, the VIC operating system needed some of THAT for its own use on startup. So by the time the system was up and running, the poor VIC programmer only had 3983 BYTES of memory to work with... :o

Because memory in these early machines was at such a premium, programmers were forced to program efficiently to make these computers really do anything useful. They had to squeeze as many instructions as possible into the smallest possible space in order to have enough memory left over for the program to actually do its work.

As a result, many programmers created code so efficient, they figured out ways to make these computers do things they were never designed to do. This was especially true of the Commodore 64. Some astonishing programs became available on the 64 over its life. It was THE most powerful 8-bit computer ever made. Heck, I managed to get along using one as late as 1996.

Compact code, by its nature, avoids unnecessary steps. It includes only the ABSOLUTE MINIMUM number of steps necessary to get a job done. Since there are far fewer steps in such efficient, compact code, a processor can execute it a LOT faster. (That's the main reason the Power PC processor is faster than Intel. The Intel processor takes more cycles to do the same job as a PPC).

Now, here's an example of efficient programming at work:

The 64 was the first and only 8-bit computer that actually had a whole new operating system come out for it during its life. Most of these old 8-bit machines had their operating systems burned into ROM chips, as did the 64, and that, of course, made upgrading the operating system impossible. The OS was literally a part of the computer's circuits and could not be changed.
(Editor: The big advantage of this approach for the user was that when a machine was turned on it was ready for action instantly. No time required to load the operating system.)

However, unlike many of the other computers of that era, the 64 also had RAM memory at the same addresses as the Kernal ROM. It was possible to switch off the Kernal ROM and point to the underlying RAM. Theoretically, it would be possible to write a whole new operating system for the 64 by switching off the built-in OS and running off a new OS in the RAM underneath.
(Editor: In fact things were better than this because the Kernal ROM could be replaced by up to 4 banks of 16K each so, providing you got your bank switching right, you had much more space available. The Commodore 64 really was a unique machine.)

The programmers at Berkley Softworks apparently saw the potential of this, because in 1986 they came out with a brand new OS for the 64. Called GEOS, (Graphic Environment Operating System), it was the first and ONLY functional Graphical User Interface for an 8-bit machine.

Initially, GEOS loaded a startup routine, which would load the basic instructions GEOS would need to load WITHOUT the help of the 64's built-in Kernal. Then it would switch off the Kernal altogether and load its own instructions into the underlying RAM. Once completely loaded, GEOS would take over the functions of the Kernal entirely.

Now remember, the 64 was an 8-bit machine with a processor that ran at only *1.44Mhz*. Most people didn't believe that an 8 bit machine, especially one that ran more than five times slower than an IBM PC, would be fast enough to handle a GUI. And it shouldn't have BEEN possible. Yet, somehow, the programmers at Berkley Softworks did it.

GEOS was hardly blindingly fast, but the fact of the matter is that it was fast enough to be practical. The amazing thing was that it drew all its screens in high resolution graphics instead of using text mode. It shouldn't have been possible for the 64 to process high resolution graphics fast enough to make GEOS practical. But it WAS done.

The only way to get an 8-bit 1.44Mhz machine with 64K of memory to do what GEOS did would be to squeeze EVERY ounce of computing power out of it. No wasted steps. So GEOS was probably one of the most efficient operating systems ever written. It had to be, given the limited resources it had to work with.

That era in computer programming was ended as RAM got cheaper. Soon, computers had MEGS of memory available, and there was no longer any incentive for programmers to program so efficiently. There was lots of memory to work with, so their attitude is if the code takes up a little more memory than it has to, who cares? There's plenty to go around.

Unfortunately, this has made programmers on all platforms rather lazy. The smallest system these days has no less than 32 MEGS of RAM. Most brand new entry-level systems have 64. The average system has 96 or 128. Many people have more still. So a programmer can be pretty certain that his program will run even if the code isn't as compact as it could be.
(Editor: While agreeing with the sentiments I think the author has gone a little overboard here. Many people still use systems with well under 32Mb and I don't think that many have more than 128Mb. Maybe he is quoting US figures. However, an important thing to mention is PDAs where the memory must be much less than this.)

Now, to return to your question: How can one independent German programmer create a browser that has all the functionality of Netscape or Internet Explorer and yet only use a fraction of the memory they do?

I suspect that this German programmer could be a child of the 80s computer era, when programming code was elegant and compact. He applied some of that old programming elegance to the programming of iCab. He wasn't satisfied that iCab would work well. He wanted it to work well and take as little memory as possible.

Actually, although iCab is more efficient than all the major browsers, it's probably not as efficient as it could be, in theory.

Theoretically, if one was to program a browser from scratch at the machine level, without using any higher level language, it would probably be possible to program a browser with all the functionality of Netscape Communicator that would use less than 2 megs of memory. If the program could be made as efficient as GEOS, maybe it could be done in under one meg.

Unfortunately, that's no longer a practical goal. Programs today dosophisticated things that go well beyond anything even imagined in the days of 8-bit machines.

Programming in machine language on the 64 was mind-numbingly difficult. It took three or four cryptic instructions just to print a single character on the screen. But it was worth doing because, by programming at the machine level, you control every single instruction executed by the processor, giving you a chance to make absolutely sure there were no wasted steps.

It's theoretically possible to program at the machine level on any processor. However, given the enormous complexity of today's programs, it would probably take five years or more to write an app that way with all the functionality people have come to expect. Then, it would probably take a decade to fully debug that app.

About the only thing still programmed at the machine level these days are the programming languages themselves... and even some languages are written using other languages. Whenever you write in a high-level language that doesn't give you control over every processor instruction, the resulting code is never as efficient as "pure" machine code.

Still, programmers should be shooting to make their programs as efficient as possible. Some programmers program sloppily even using the high level languages. When you write a sloppy program in a high level language, every sloppy instruction might waste hundreds of processing cycles.

That sloppiness, combined with the bloat caused by the programming language itself, is the reason there's so much ridiculously bloated code out there.

It's too bad all programming couldn't be done at the machine level... It would be interesting to see what today's machines could do if all applications and operating systems were as efficiently programmed as GEOS was.

Maybe 16Megs would be all the memory anyone would need.

John A. Ardelli is the Owner/Moderator of BIFIDA-L: The Spina Bifida Discussion List and The Crystal Corner: The Dark Crystal Discussion List ICQ# 73892773
Personal Home Page: http://www.angelfire.com/ar/Ardelli/
John's Crystal Corner: http://www.angelfire.com/ar/Ardelli/DarkCrystal.html