Thread
System 6 Browser Development Opinions
I was being fully sarcastic.
Well that's not going to happen anytime soon. Encryption is a killer for a lowly 68000.
Hmm, even when I have MacTCP (1.1.1) installed I still trap.
Also I can't open files via the file:// protocol, though It opens a window
Also I can't open files via the file:// protocol, though It opens a window
Wow. Seems to work pretty well!
I tried on a SE under french System 6.0.8, MacTCP 2.0.6. It's connected via a serial cable to a PB 1400 with IPNetRouter running, which itself is wired to my ethernet router.
What I get on the SE is first a "302 Found" page, then a window with a page title (68k Macintosh Liberation Army Forums, for instance
). There's a debugger window underneath which shows what's being downloaded.
Haven't had time to check further as it's christmas eve and I've still some stuff to buy for tonight's meal… porter, thanks a lot for that encouraging present!
I tried on a SE under french System 6.0.8, MacTCP 2.0.6. It's connected via a serial cable to a PB 1400 with IPNetRouter running, which itself is wired to my ethernet router.
What I get on the SE is first a "302 Found" page, then a window with a page title (68k Macintosh Liberation Army Forums, for instance
). There's a debugger window underneath which shows what's being downloaded.Haven't had time to check further as it's christmas eve and I've still some stuff to buy for tonight's meal… porter, thanks a lot for that encouraging present!
Maybe I could get a download to MacTCP?
That is encouraging. Effectively that is a similar setup to mine. There is a big difference between MacTCP 1 and MacTCP 2.
It would be nice to know what the trap was, I'd like it to be able to view local files if MacTCP does not work.
Look under the File menu for File->Open... ! It should be able to open local GIFs at the moment.
When I find a copy of MacsBug for system 6 I'll let you know.
Right, but file>open doesn't work, if I open something I enter an unimplemented trap. also, .gif files don't show up, I don't know what type code it needs.
I'll look into all this later.
GIF files have type "GIFf", mine have creator as "ogle".
Can you post your exact setup?
Mini vMac Mac Plus 4MB
System 6.0.8 running MultiFinder at the moment. Mac TCP 1.1.1, the ONLY version I had.
I can't try it on my real mac plus cause I'm having zip disk problems (about time already).
System 6.0.8 running MultiFinder at the moment. Mac TCP 1.1.1, the ONLY version I had.
I can't try it on my real mac plus cause I'm having zip disk problems (about time already).
Just out of curiosity… Is MacTCP required for browser6 to load? Since Mini vMav emulates empty network ports and no network connection at all, I thought it would open local files even without MacTCP installed.
As for MacTCP 2.0.6, it's part of the network Software 1.4.4 or 1.4.5, I guess. You can download it for free from Apple on the Older Software downloads page, under the Network & Communication section.
I am getting traps when I try to load a file, and I don't have MacTCP, apparently it's some dependency. Porter, may I recommend making it NOT even start up if it doesn't have what it needs to start and not trap. Anyway, thanks for the MacTCP link, I'll try browser6 w/ MacTCP and see what happens.
I need to know where the traps are. I can't get it build and run with MPW which is concerning. THINK C works very well, but not MPW 3.2 or MPW-3.5.
I also can't take a trap reported in an emulator as seriously as a trap on a real machine.
I tried it on a G3 is OS 8.6. Didn't work. 
I've check the title of the thread and it still says "System 6...."I tried it on a G3 is OS 8.6. Didn't work.
It ran on Mac OS 9 on a G4, but crashed the instant I tried to open something. I am trying to fix the zip disk.
I'm aware of that, I was just trying it for kicks.I've check the title of the thread and it still says "System 6...."I tried it on a G3 is OS 8.6. Didn't work.
Actually it worked on my Performa 6200 running 8.6.I'm aware of that, I was just trying it for kicks.I've check the title of the thread and it still says "System 6...."I tried it on a G3 is OS 8.6. Didn't work.
Seems temperamental. There is quite a different behaviour between real MacTCP and MacTCP emulated on OpenTransport.
Probably the G3 processor?
I'll try it on my 5500 (603e) w/ 8.5 later.
I'll try it on my 5500 (603e) w/ 8.5 later.
Okay, here's my experience:
Mac Plus / 6.0.8 / MacTCP 2.0.6 (no network connected)
I'm able to open gifs with File-->Open. Not able to open html docs, I get "Unimplemented Trap". I'll look up MacBugs when I have a bit more time, as I'm sure this info isn't much help.
Mac Plus / 6.0.8 / MacTCP 2.0.6 (no network connected)
I'm able to open gifs with File-->Open. Not able to open html docs, I get "Unimplemented Trap". I'll look up MacBugs when I have a bit more time, as I'm sure this info isn't much help.
Round 2
LC 475 / System 7.5.3 / TCP/IP
Since this one's actually on the net, it was a bit more fun... File-->Open still bombs on html, but I was able to use File-->Open URL for http:// files. The window displays 302 - File Found, followed by the placeholder text. Cool.
I also tried opening some remote gif files with Open URL and I was pretty impressed with the render speed. Dithering works quite well for photographic stuff, so I think this will be just fine for pr0n ;-)
LC 475 / System 7.5.3 / TCP/IP
Since this one's actually on the net, it was a bit more fun... File-->Open still bombs on html, but I was able to use File-->Open URL for http:// files. The window displays 302 - File Found, followed by the placeholder text. Cool.
I also tried opening some remote gif files with Open URL and I was pretty impressed with the render speed. Dithering works quite well for photographic stuff, so I think this will be just fine for pr0n ;-)
Cool, thanks for that report.
Thanks to all those who have take the time to download and test the work I have done so far, it is both useful and encouraging.
Well, I've spent most of the afternoon finding and installing MacsBug (which turns out to be quite different from Mac Bugs!)... unfortunately I have no idea what I'm doing.
From what I've read, entering "stdlog" at the prompt should be enlightening, but all I get is a blank text file. Other than that there's a lot of mumbo-jumbo onscreen, but it's too much to write down and I'm not sure what (if any) of it is useful.
Still, this has given me an excuse to get the Plus out of hibernation, which has been loads of fun... if slightly unproductive.
From what I've read, entering "stdlog" at the prompt should be enlightening, but all I get is a blank text file. Other than that there's a lot of mumbo-jumbo onscreen, but it's too much to write down and I'm not sure what (if any) of it is useful.
Still, this has given me an excuse to get the Plus out of hibernation, which has been loads of fun... if slightly unproductive.
I've now got it building and working ( in as much as the same as it does for THINK C 5.0 ) using MPW.
The main gotcha is that Apple had '\n' as 13 and '\r' as 10 which screwed up my HTTP requests.
I've now got a portable work around to that issue and can build with MPW 3.2.
This is good because when there are bad traps, running a version built using a different compiler can help home in on the problem.
I intend to a have a PPC built version just so that we can use a different debugger if needed on a bigger platform.
Okay, I'll admit it, I'm doing most of my development using Microsoft Visual C++ 4.0......
The main gotcha is that Apple had '\n' as 13 and '\r' as 10 which screwed up my HTTP requests.
I've now got a portable work around to that issue and can build with MPW 3.2.
This is good because when there are bad traps, running a version built using a different compiler can help home in on the problem.
I intend to a have a PPC built version just so that we can use a different debugger if needed on a bigger platform.
Okay, I'll admit it, I'm doing most of my development using Microsoft Visual C++ 4.0......
That thar doesn't help with compiling
It would if I had the cross platform edition which does generate code for the mac!
However it helps limit the problems I have to deal with on the Mac to Mac specific problems, not the parsing etc issues.
It works on my 3400c in Mac OS 8.6. Still crashes when trying to use cmd+O. But I assume it isn't supposed view HTML yet.
GIFs open via URL flawlessly, though the dithering could use refining, I'll crack into it possibly in a bit.
GIFs open via URL flawlessly, though the dithering could use refining, I'll crack into it possibly in a bit.
Some serious work done so far...
1. Have setup the following build environments:
a. browser6 - THINK C 5.0, 68k classic
b. browser7 - MPW 3.2, 68k classic
c. browser8 - MPW 3.5 Fat CFM-68k and CFM-PPC
d. browser9 - Carbon CFM with 'plst' using MPW 3.5
e. browserx - Carbon Macho using Xcode
f. minihttp - Win32 using VC++ 4.0
2. Using gestalt heavily to determine host features, idea is that application will use as much as is available dynamically
a. if supports apple events then install opendocument and quit
b. if supports FSSpec calls then use FSpOpen/FSpCreate etc instead of using working directorys
c. determine which menu bar to load depening whether its aqua or not
3. Colour support for GIFs
This is a big change, can now render 8 bit GIFs from monochrome, to hundreds, thousands and millions of colours.
If it's 32bit quickdraw it will support ditherCopy on CopyBits, if it is using Color QD 1.0 to 1.2 then convert each line to full 32bit to get dithering to work.
Switching screen resolutions will cause images to re-render to best capability.
4. Colour support for windows, dialogs and controls.
5. Uses Navigation Services if available.
6. Offscreen bit maps use GWorlds on Carbon
7. Use Carbon accessors as much as possible to make code modern even though running on a lowly Classic.
8. Tested on the following environments
Classic running 6.0.8
LC-II running 6.0.8
Quadra700 running AU/X 3.1.1
Quadra 605 running 8.1
Performa 6200 running 8.6
BW G3 running Tiger
Both browser6 and browser7 will run on 6.0.8.
Obviously the CFM builds require CFM, and the Carbon builds need Carbon.
The Carbon CFM version runs on my 8.6 and natively on Tiger.
My next step is to add OpenTransport calls to the Carbon version.
Why am I putting in all this work on other versions other than 6? Simple anwsers are
(a) cross platform development improves robustness as a problem lurking in one environment can be shown up by another
( B) use the best development and debugging environments around, eg Xcode and Visual C++.
© once this beast gets into the wild I want it to look as good as it can in any environment.
I found some curious bugs in the MPW 3.2 compiler which caused much frustration, basically it has problems with some post increment constructs, one which only caused a 68040 or PPC emulation of 68040 to blowup. So now the MPW 3.2 build does work on all environments.
1. Have setup the following build environments:
a. browser6 - THINK C 5.0, 68k classic
b. browser7 - MPW 3.2, 68k classic
c. browser8 - MPW 3.5 Fat CFM-68k and CFM-PPC
d. browser9 - Carbon CFM with 'plst' using MPW 3.5
e. browserx - Carbon Macho using Xcode
f. minihttp - Win32 using VC++ 4.0
2. Using gestalt heavily to determine host features, idea is that application will use as much as is available dynamically
a. if supports apple events then install opendocument and quit
b. if supports FSSpec calls then use FSpOpen/FSpCreate etc instead of using working directorys
c. determine which menu bar to load depening whether its aqua or not
3. Colour support for GIFs
This is a big change, can now render 8 bit GIFs from monochrome, to hundreds, thousands and millions of colours.
If it's 32bit quickdraw it will support ditherCopy on CopyBits, if it is using Color QD 1.0 to 1.2 then convert each line to full 32bit to get dithering to work.
Switching screen resolutions will cause images to re-render to best capability.
4. Colour support for windows, dialogs and controls.
5. Uses Navigation Services if available.
6. Offscreen bit maps use GWorlds on Carbon
7. Use Carbon accessors as much as possible to make code modern even though running on a lowly Classic.
8. Tested on the following environments
Classic running 6.0.8
LC-II running 6.0.8
Quadra700 running AU/X 3.1.1
Quadra 605 running 8.1
Performa 6200 running 8.6
BW G3 running Tiger
Both browser6 and browser7 will run on 6.0.8.
Obviously the CFM builds require CFM, and the Carbon builds need Carbon.
The Carbon CFM version runs on my 8.6 and natively on Tiger.
My next step is to add OpenTransport calls to the Carbon version.
Why am I putting in all this work on other versions other than 6? Simple anwsers are
(a) cross platform development improves robustness as a problem lurking in one environment can be shown up by another
( B) use the best development and debugging environments around, eg Xcode and Visual C++.
© once this beast gets into the wild I want it to look as good as it can in any environment.
I found some curious bugs in the MPW 3.2 compiler which caused much frustration, basically it has problems with some post increment constructs, one which only caused a 68040 or PPC emulation of 68040 to blowup. So now the MPW 3.2 build does work on all environments.
Good effort - that is impressive!
Keep up the good work!
Keep up the good work!
porter, email me when you get a package made with all builds, okay?