System 6 Browser Development Opinions

[II2II]

How are you proposing to handle verbose sites within 1MB RAM?

Cry?

Or, you avoid buffering all of the data from the web page. Something like

can be regarded as "switch into header mode". You stick a shorthand (perhaps one byte) into a processed data buffer. You automatically reduce the token to a fraction of it's original size, a quarter in my example, but much less if there is other information added to that
token such as styles. (Sorry, but I forget my HTML terminology.)

I'm suggesting that one byte control codes will work since I'm assuming an ASCII character set. You have at least 128 unused characters due to the high bit (ASCII is only 7-bits), and a few more non-displaying control characters in the low 7-bits. If the processed page is still larger than the available memory, you buffer it to disk, but I doubt that will happen often since few web pages contain more than a few kilobytes of readable content.

But yeah, unfortunately you do need some sort of buffer because you need that for screen redraws. Still, I don't see it having a large impact on performance as long as you have a few screens worth of buffered data in RAM (both before and after the content that is currently being displayed). After all, the user will probably be spending most of their time reading. You simple grab data from the disk buffer when they are doing that reading.

 

[porter]

Spilling to disk is a reasonable option.

To my mind there are two parts to HTML, which actually maps rather neatly to resource files (yes I've been reading my Inside Macintosh Volume 1 again).

1. The document structure, header, body, paragraphs, list definitions, basically all the ELEMENT type information.

2. Secondly all the text data itself

The structure should be able to be held in memory all the time, then this refers by offset to the textual data itself, only a small window of which needs to be in memory at any time.

 

[Charlieman]

And one more thing...

How will the browser handle gzip HTTP transmissions? To me at least, it makes sense to hold the gzip data in RAM, and then decompress and parse in a single operation. Alas gzip is not going to be fast on a 68000. The routine is a prime candidate for 68K optimisation.

An alternative is for the browser to request raw text HTTP transmissions. I assume that development will be conducted on Macs with a healthy amount of RAM so this should not be a problem. Gzip requests could be added later, once the ability to meaningfully process raw text transmissions is sorted.

And another thing. How will the browser handle memory allocation? The browser requires three big memory pools -- transmission data, parsed content, presentation layer. They may be listed in order of size as well as processing, but we can't assume it. The browser has to reallocate memory very efficiently. And the browser must stop cleanly well before it has run out of RAM.

Having thought about the above, I appreciate the difficulties faced by the Mosaic and Netscape engineers 15 years ago. In particular, I understand why the Mosaic developers chose not to provide in-line images; in-line images require that the presentation layer demands more and more RAM, which eventually kills the browser engine.

IIRC, Netscape 1.0 etc required 32 bit QuickDraw. For handling in-line images, I can understand this as a requirement. But I think the problem was something different to do with dialog boxes. I definitely recall that a colleague who was programming some NetWare for Macintosh utilities hit the same limitation.

 

[porter]

How will the browser handle gzip HTTP transmissions?

Put in the version two list. It shouldn't occur if you ask for "text/plain, text/html".

I assume that development will be conducted on Macs with a healthy amount of RAM so this should not be a problem.

Yes, but the classic heap size of 384k can still be assigned to the application.

How will the browser handle memory allocation?

Using NewHandle, SetHandleSize etc . Using unlocked moveable memory is the most efficient on small macs. I'm also intending to use the segment loader efficiently so that the parser is jettisoned after reading a document. Similar for any printing code.

Tables such as mapping element/attribute names and look ups for escaped characters can be held in discardable resources.

IIRC, Netscape 1.0 etc required 32 bit QuickDraw.

I intend this to work on 68000, so no 32bit QD. Funnily enough, the Windows 3.1 version of Netscape needed WIN32S.

 

[porter]

I've done some tinkering and come up with a GIF decoder that works inside out.

Most examples I've seen show a main loop which "pulls" in the bitmap. I've written mine so that it is "written" to. This means we can have an event driven driven architecture, and as fragments of the image are received from the net the GIF decoder can carry on rendering for a packets worth.

This is essential to have GIFs appearing on the screen as they are downloading without having the machine lock up.

The final coupe de grace is simple dithering for monochrome which doesn't actually look too bad.

 

[tomlee59]

A little like progressive gif (itself designed for rendering on network-speed challenged machines)...

 

[Bunsen]

Just out of interest, what language/IDE are you building this in?

 

[porter]

Just out of interest, what language/IDE are you building this in?

I'm writing in ANSI C.

At the moment I'm using Visual C++ 4.0 on Windows to get all the parsing and layout working properly.

Then I will move all this to THINK C 5.0 on Basilisk II to continue the Mac specific portions.

Then I will make an MPW build environment.

I have LightSpeed 3.0, THINK C5.0, Symantec C++ 7 and a few versions of MPW.

There is a small bit of 68000 assembler to handle completion routines for MacTCP.

As for coding standards, and what is legal, I'm sticking to Inside Macintosh Volumes I to IV. (V really covers colour, and VI is for System 7).

It's greating not having to worry about Balloon Help, Apple Events, Apple Guide Drag & Drop.

 

[ealex79]

Basilisk dies on me on a lot of things.. it dies on MPW editing, on debugging (well, that's not really a wonder), and and and..tha latest MPW doesn't really run well, too.

 

[porter]

Basilisk dies on me on a lot of things.. it dies on MPW editing, on debugging (well, that's not really a wonder), and and and..tha latest MPW doesn't really run well, too.

Which version of OS?

I'm intending doing most of my debugging on windows. Writing portable code has the advantage of choice of where best to solve different problems.

 

[ealex79]

I seriously tried 7.6 and 7.5.5 and 8.1 (under Vista and OS X).

Actually it was the reason why I wanted to have a Sawtooth or cousin of it.

 

[porter]

What are the standard Macintosh file types for HTML and GIF? (eg, text is 'TEXT')....

 

[Charlieman]

Do the Internet Config docs from the early/mid 1990s help?

 

[porter]

Ah,

The Internet Configuration system requires System 7 or late, and Component Manager

http://www.quinn.echidna.id.au/Quinn/Config/User_Documentation.html

On the positive side that is another thing it doesn't have to work with.

 

[II2II]

I did a quick search, and it looks like HTML files are of the file type 'TEXT' and GIFs can be 'GIFf' or 'GIF ' (note the space at the end).

Someone mentioned Internet Config, I don't think that it will make it easier to implement the web browser since it seems to be some sort of system to centralize settings for web browsers, FTP clients, and such. But I seem to recall it having a list of extensions, as well as file types and creators -- so it may answer many questions on type/creator.

 

[porter]

Wow, the Apple Developer register application "creator" codes website is still running.

I've now got a new one to make this app legit. A couple more weeks and I should have something to demonstrate.

 

[paws]

Not bad. Not bad at all!

Any idea about the size of the binary?

 

[ChristTrekker]

I've now got a new one to make this app legit. A couple more weeks and I should have something to demonstrate.

Wow, a System 6 browser! Ought to run OK in 7-9 also, right?

 

[II2II]

Yeah, Apple is pretty good at keeping old stuff on their site. Particularly developer stuff. They even have ancient stuff, for the Apple II.

As for a System 6 browser running in System 7 through Mac OS 9, it should. I've even seen pre-System 6 stuff work in Mac OS 9. Indeed, I believe the main breakage was the switch to 32-bit addressing since some developers used the high address 8-bits to store extra data. (Hey, it wouldn't be used otherwise! Or so they thought.) But you don't have to do that.

 

[porter]

It will still be 32bit clean. Though technically storing information in the high byte of pointers is used all over Inside Macintosh I and II, from memory manager, to window and control definitions.

Also binary size is not the same as "working set" size. I am juggling with some caching mechanisms to keep the amount of runtime memory to a minimum and allow complex documents to still be viewed.

Some basic sites are rather rude, they don't return the "Content-Type:" and expect the browser to delve into the data or look at the file extension to work out what the data is, I'm not going to support that, that is like a Macintosh working out the TYPE/CREATOR for you.