Thread
System 6 Browser Development Opinions
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.
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.
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.
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.
Put in the version two list. It shouldn't occur if you ask for "text/plain, text/html".
Yes, but the classic heap size of 384k can still be assigned to the application.
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.
I intend this to work on 68000, so no 32bit QD. Funnily enough, the Windows 3.1 version of Netscape needed WIN32S.
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.
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.
A little like progressive gif (itself designed for rendering on network-speed challenged machines)...
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.
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.
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.
Actually it was the reason why I wanted to have a Sawtooth or cousin of it.
What are the standard Macintosh file types for HTML and GIF? (eg, text is 'TEXT')....
Do the Internet Config docs from the early/mid 1990s help?
Ah,
On the positive side that is another thing it doesn't have to work with.
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.
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.
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.
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.
I've now got a new one to make this app legit. A couple more weeks and I should have something to demonstrate.
Not bad. Not bad at all!
Any idea about the size of the binary?
Any idea about the size of the binary?
Wow, a System 6 browser! Ought to run OK in 7-9 also, right?
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.
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.
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.
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.
Okay, I'll admit I'm a bit rusty on some System 6 details....
(a) seeing as "FindFolder()" is System 7 upwards, where should your preferences file live and how do you determine the appropriate ioVRefNum and ioDirID for use with PBHOpen()?
( B) having WaitNextEvent() is all good to work with MultiFinder but how do you wake up a process given you don't have a process manager, process number and no WakeUpProcess()? Do you just use PostEvent with a null event and hope?
(a) seeing as "FindFolder()" is System 7 upwards, where should your preferences file live and how do you determine the appropriate ioVRefNum and ioDirID for use with PBHOpen()?
( B) having WaitNextEvent() is all good to work with MultiFinder but how do you wake up a process given you don't have a process manager, process number and no WakeUpProcess()? Do you just use PostEvent with a null event and hope?
Wouldn't you know, next I open Inside Macintosh Volume V, and there on page 5, SysEnvirons(), SysEnvRec.sysVRefNum is a working directory reference.
I've got some stuff compiling and working but have some interesting issues....
(a) none of my versions of MPW will produce a binary that works on 6.0.8. I have 3.4b7 and 3.5, both have SC rather than MPW C. Perhaps that is part of the problem.
( B) THINK C 5.0 is producing a binary that works, but I have to fudge "memset" with my own implementation rather than the one from the ANSI lib. Is the whole of ANSI on THINK C 5.0 a pile of poo or just the ones they wrote in assembler? I have tried both the 4 byte and 2 byte ints to see if either made a difference, but no.
My current development environment pathway is interesting to say the least, partly down to lack of common networking and floppies...
Windows laptop -> G3 B& W running Tiger + MPW -> Quadra 605 -> Mac Plus
(a) none of my versions of MPW will produce a binary that works on 6.0.8. I have 3.4b7 and 3.5, both have SC rather than MPW C. Perhaps that is part of the problem.
( B) THINK C 5.0 is producing a binary that works, but I have to fudge "memset" with my own implementation rather than the one from the ANSI lib. Is the whole of ANSI on THINK C 5.0 a pile of poo or just the ones they wrote in assembler? I have tried both the 4 byte and 2 byte ints to see if either made a difference, but no.
My current development environment pathway is interesting to say the least, partly down to lack of common networking and floppies...
Windows laptop -> G3 B& W running Tiger + MPW -> Quadra 605 -> Mac Plus
there was a browser for newton that did that. it used a server to convert a site to be displayed properly on the newton then sent everything to the client.
Yes, I remember there used to be something like that for WAP phones. That;s where I got the idea
Technical question:
I want to use temporary files and put them somewhere near the application binary. How, on system 6.0.x do I find the vRefNum(work directory hopefully) and name of my application?
I can use
to get a handle on the applications resource fork, but how do I turn that into a filepath I can use?
I want to use temporary files and put them somewhere near the application binary. How, on system 6.0.x do I find the vRefNum(work directory hopefully) and name of my application?
I can use
Code:
Handle h=GetResource('SIZE',1);short resFile=HomeResFile(h);
Off the top of my head (ie "maybe wrong"), I think you want CurApName and CurApRefNum.
Excellent. Inside Macintosh, II-58 describes GetAppParms() which does exactly what I want. Thanks.
Progress so far, running on a Quadra 605, it has successfully
(a) downloaded HTML pages and parsed them, including following redirection links.
( B) downloaded and displayed GIF files in glorious dithered monochrome.
© as many internal objects as possible (except WindowRecords and MacTCP buffers) are held in unlocked Handle to allow efficient relocation.
I have a few more tasks...
(i) efficient rendering of the HTML indexed from the "Y" coordinate to allow quick scrolling of large documents.
(ii) implementation of the temporary files
(iii) a busy/progress indicator
(iv) table layout logic
That should provide a useable read only browser. (no forms, cookies or printing yet).
but the only bad thing about that is if the server goes down the browser is useless.
The technical term being "single point of failure"
Woot! Major milestone in the testing department..
i. Built using THINK C 5.0
ii. System 6.0.8 on a 4Mb Macintosh Plus
iii. MacTCP 2.0.4 using MacIP over LocalTalk Bridge 2. 1 to a MacIP gateway
iv. Successfully downloaded and displayed a GIF file from an IRIX box using HTTP, "http://indy/outbox/images/sgi_banner.gif".
i. Built using THINK C 5.0
ii. System 6.0.8 on a 4Mb Macintosh Plus
iii. MacTCP 2.0.4 using MacIP over LocalTalk Bridge 2. 1 to a MacIP gateway
iv. Successfully downloaded and displayed a GIF file from an IRIX box using HTTP, "http://indy/outbox/images/sgi_banner.gif".