Thread
A System 6 Browser
I've been waiting for someone (meaning, someone else) to do just that. Any volunteers? It's been ported to the C64, and there were sporadic reports of getting it to (sort of) work on a VIC-20.
As I've mentioned before, I'm legally prohibited from writing code, so I can't do it...
Yes, but the source is available on sourceforge. It appears to be CodeWarrior 11, which I don't have, so I've not been able to build it.And I guess the fact that the site has devolved into an anonymous directory listing is a good sign that development has ceased.
Although, I can't imagine there's much left to do is there?
Although, considering what can be done with the Contiki browser on a 1MHz 8 bit 6502 or Z80 with 64kb of RAM, porting it to an 8MHz 32 bit 68000 with 128k doesn't sound like a bad idea at all.
Can anyone here even give a feasibility estimate for such a project? Porting to System 6 would be ideal; perhaps the whole Contiki OS could be ported to run as a Mac process. It is designed to be highly portable.
Can anyone here even give a feasibility estimate for such a project? Porting to System 6 would be ideal; perhaps the whole Contiki OS could be ported to run as a Mac process. It is designed to be highly portable.
Speaking of amazing OS efforts on 8 bit machines:
http://en.wikipedia.org/wiki/SymbOS
Although admittedly, it does make use of dedicated support ICs in the host for video &c
http://en.wikipedia.org/wiki/SymbOS
Although admittedly, it does make use of dedicated support ICs in the host for video &c
http://en.wikipedia.org/wiki/Contiki#Ports
- Atari ST
- x86-based Unix-like systems, on top of GTK+ as well as directly using the X Window System
I dunno...preemptive multithreading (Contiki) vs cooperative multitasking (Sys 6)...depending on what you're trying to do, Contiki might be the better performer. Now the browser, unless it's evolved past the point where scrolling required a page reload, I don't think I'd want to be using it extensively. It would be amusing to port it to check it out and test with, but nothing I'd use as a regular browser, unlike Links/Lynx which are quite functional in that sense.
One of the things that has always bothered me about the Mac world is that programming is actively discouraged. I don't think I've ever seen anyone put down for wanting to program in BASIC on an Apple II, so games like Silvern Castle were well received. I've never seen people complain about HyperCard games on the IIgs, which is why we have Shipwrecked (or Myst on the Mac for that matter).
For that matter, I've never seen people claim that Apple IIe programs have to be written for ProDOS. Yet I have seen people told NOT to program for System 6, because the System 7 API is so much better.
If you want people to make neat software, stop discouraging them with your linguistic and OS ideological wars. If you can, help them.
I know that people are being pretty supportive in this thread, but two threads over are people telling a guy not to program in BASIC on Mac OS X because languages that noone has ever even heard of are superior.
For that matter, I've never seen people claim that Apple IIe programs have to be written for ProDOS. Yet I have seen people told NOT to program for System 6, because the System 7 API is so much better.
If you want people to make neat software, stop discouraging them with your linguistic and OS ideological wars. If you can, help them.
I know that people are being pretty supportive in this thread, but two threads over are people telling a guy not to program in BASIC on Mac OS X because languages that noone has ever even heard of are superior.
I suggested four languages as alternatives for Mac OS X programming in one of those threads, two of which are actually included with OS X and supported by Apple as ways to build Cocoa apps; one that is used as a scripting language in little-used applications by unknown software developers such World of Warcraft and Adobe Lightroom and the last (Common Lisp) is taught in a lot of computer science courses.
(shortened)
Because no System 6 browser exists (I'm treating Samba as more of a stunt), the issue isn't really whether the putative NewBrowser would be worth using regularly. Rather than comparing it to modern browsers that operate on much more capable machines, we're comparing it to...nothing. And compared to nothing, something is pretty damn nice. It would be helpful to be able to download System 6 software on a System 6 Mac. Among others, it would permit us to bypass the "How do I get software onto an 800K floppy?" problem that often crops up when using a more modern computer.
And there's also the "we want to do it because we think we can" geektosterone spirit that ultimately motivates many of us here.
:lol: ;D :lol: Old macs tend to have SCSI, so you can connect a zip drive up and transfer drivers and apps as needed (unless you are a ludite who only has a SE for their main computer).
Probably faster to connect serial ports between macs and transfer files the old fashioned way via chooser. Or try the phonenet.
Probably faster to connect serial ports between macs and transfer files the old fashioned way via chooser. Or try the phonenet.
Well, I am a luddite... but you make several good points. However, I think if we look at this in terms of pure practicality then we might as well just not bother with old Macs at all.
tomlee59 hit the nail right on the head... it's a challenge... dare I say a RetroChallenge.
tomlee59 hit the nail right on the head... it's a challenge... dare I say a RetroChallenge.
I have no idea, but I can probably get you in contact with the author. I just need to rummage through a mountain of bytes to find his email address. He used to work at CERN (where he wrote Samba). He was unable to unearth a copy of the source code, and doubts that it even exists anywhere at CERN (although that assertion did surprise me; I thought these folks backed up everything three ways).
The problems aren't with MacTCP, the problems are with Samba. For example, from http://home24.inet.tele.dk/ccadams/se/samba.html ...
"Do not close any windows as this crashes the Mac; also quitting MacWWW seems to cause a crash. Note that with System 6, MacTCP may crash when saving prefs for the first time, so check that the prefs are actually saved".
"Do not close any windows as this crashes the Mac; also quitting MacWWW seems to cause a crash. Note that with System 6, MacTCP may crash when saving prefs for the first time, so check that the prefs are actually saved".
You have to treat MacTCP as an asychronous driver, when you invoke a control command you do need to confirm it has been completed before you continue. As it may use memory in your heap (System 6 being very different to 7 in this regard) you need to ensure all streams are correctly closed.
The MacTCP that sits on top of OpenTransport has quite a different behaviour, so when developing MacTCP code you need to test in both environments (eg with and without OT).
The MacTCP that sits on top of OpenTransport has quite a different behaviour, so when developing MacTCP code you need to test in both environments (eg with and without OT).