Old Mac, Modern Internet

[VMSZealot]

I'm doing a bit of development which might interest users here - and not just users of old Macs either.  The problem that I'm trying to solve is making the Internet, and specifically the Web and Email, available to old Macs - many of which can't do ssl secured email or browsing.

There are solutions available, but they're kludgy, and they may not work on really old machines.  I want to remove the kludge, and make email and the web available (relatively securely) on all vintage machines - regardless of whether they're ancient Macs, 8088 DOS PCs, Amiga, ST, or any other machine with an email client.

My solution is a gateway application running on a Windows / Linux / macOS / whatever modern OS you like.  The best bet, I think, would be a Raspberry Pi (or similar) since the power requirements are low, connected to your Mac of choice using Ethernet or SLIP.

It's not entirely pie in the sky either.  Code has been cut (C++), and progress is being made, on a cross platform server to get old Macs accessing the Modern Internet.

Whether it gets finished or not depends on several things. How much time I can muster for this project, and how much interest there is.  Comment here on whether you think that this is a fools errand or a worthwhile endeavour.

 

[bigmessowires]

Somebody else made virtually the exact same proposal just two days ago - maybe you can work together. https://68kmla.org/forums/index.php?/topic/30760-internet-on-older-macs/

 

[Nathan]

It'd be really nice if someone would make a new browser for these machines that conforms to more modern standards as much as possible... That way a stripped down modern page would be loadable/renderable/usable barring totally insufficient processing power. The gateway approach adds a fair bit of extra hardware into the scenario and seems sort of silly when the unit in question already has ethernet.

 

[VMSZealot]

Somebody else made virtually the exact same proposal just two days ago - maybe you can work together. https://68kmla.org/forums/index.php?/topic/30760-internet-on-older-macs/

Wow. Great minds think alike and all that. Reading that post though, it looks like it might be a clever collection of existing software. Certainly, it mentions using stunnel - which isn't the easiest software to use.

The solution that I'm writing will be self contained and, hopefully, a lot simpler to configure and set up. No tunnelling will happen at all - to the vintage computer the Pi will look like the server. When it makes a request to the Pi (when requesting a page, requesting email, sending email) it will send it to the Pi and then the Pi will process it and make a separate request of its own, using modern internet standards. When the Pi receives a response it will package it up appropriately and then return it to the requesting machine.

Sure, this approach will add a little latency - but not enough that you'd notice.

 

[mactjaap]

[SIZE=10.5pt]Nice initiative!![/SIZE]

[SIZE=10.5pt]I have tried this one long time ago: Browsy[/SIZE]

http://www.macip.net/?page_id=77

It was a nice try to get a browser on a old Mac System 6!

But I guess you will be aiming for higher OS and machines?

I really like to try if you have something ready.

 

[techknight]

my thought in the past was using an external co-processor to do all the rendering, Like a server as you suggest, or a Pi, or something along the lines. 

But instead of coming back to the old browser as images, it needs to come back as full content, just in a language the older machines can understand. 

Almost like a translator of sorts. That would be one way. 

The other way would be a co-processor running the entire browser except for the UI, and its outputbuffer/displaybuffer gets dumped to a custom "browser" written to run on those old machines. So they work and act like todays browsers and are just as responsive, because all the heavy hitting is done on the copro. Then your mouse movement, key types, and mouse action are all sent as datagrams/packets/etc back to the browser engine running on the copro. browser processes those as if it were running on the native machine, and then browser responds like it normally would, say hovering over hamburger menus, etc... and re-renders what it needs to and dumps it back to the displaybuffer. 

Sure the UI then becomes a "terminal" at that point, but at least the internet browsing would be responsive. and the UI looks native instead of a window that is like an X-window remote connection. 

 

[VMSZealot]

At the moment, I'm concentrating on getting email going so that vintage computers with old email clients running on them can get their email. My focus is on retrieving IMAPS email (the secure version of IMAP, as used by everyone these days) and forwarding it using POP. SMTP is SMTP, but I'll wrap it up securely before sending. It's not an easy task, but I have a plan and I can see my way through.

HTTP is trickier. I can deal with stripping the S off - and I'm pondering ditching the CSS, or causing the mobile version to be requested (but I fear this will still be too slow / incompatible with old browsers). The other option is to have an XWindows setup on the Linux machine which runs in 1 or 4 bitdepth (so as to avoid mucking up the Mac colour palette, and to keep transfer speeds fast) and connect to a browser on the Linux machine using MacX (or similar). There are options - and I'd welcome any thoughts that you might have.

When I'm a bit closer to completion I'll open source it on GitHub and you can all dive in.

 

[VMSZealot]

@techknight

I forgot to say, I like your idea. Presumably the custom browser on the Mac would send the required page to the Linux machine using a nice free port, the Linux machine would then, XWindows style, send the page description back for display. Any mouse click coordinates / text entry in the browser window would be sent to the Linux machine for handling.

I wonder if it'd be possible to reuse any of the XWindows code to achieve this?

 

[techknight]

Probably. especially if you have an active UDP link just to push framebuffer/pixel data. or even XWindowing data. 

 

[VMSZealot]

I don't really want to push pixel data - that'd be like VNC and terribly slow.  Doing something XWindowsy would be faster - but I can see it quickly developing into an utter ball ache.  I think that, initially at least, I'll try to go down the road of wrapping / unwrapping the ssl and altering the css.  In fact, perhaps the best route would be to create a new browser based on links and just load the images (which links clearly doesn't do).  Options, options.

Thinking about it, the linux box might also take any image data coming over and change it from whatever fancy massive bit depth and resolution that it has down to something more appropriate for an old computer.  4bit, low res.

 

[CC_333]

Would it be infeasible to take techknight's idea and put it on a PDS and/or NuBUS card? Sure, the transfer speeds are still low (because of the bus), but all the processing can be done on the card, which would have its own dedicated ethernet port, and power can be taken from an internal port somewhere (the hard drive, on Macs so equipped, perhaps?).

That way, it can be marketed as an extra-special network card, as opposed to a Pi stuck in an external box that makes the Mac feel like a terminal (I mean, if it works like my naive mind thinks it will, there's technically no difference, except that the coprocessor will be internal to the machine).

c

 

[Nathan]

It might be feasible, assuming you can even find someone with the knowledge/skill that is willing to do it.

The bus speeds really aren't all that slow and they would be pretty fast under optimal conditions even compared to to an average user's network speed. It's PC world, but -> http://www.pcguide.com/ref/mbsys/buses/funcBandwidth-c.html  Also, http://www.interfacebus.com/Apple_NuBus.html Note that basic Nubus has, according to them, a max throughput of 40 Mbps. Not sure what PDS looks like, but I imagine it's more limited by the processor in question. Afaik you need controllers/interface chips for Nubus (yay internet) so that might pose a problem, no? If you knew how they worked and FPGA or similar device could do it.

Does the mac even need a co-processor though? If someone wrote the necessary software for the Mac itself might it be fast enough? Altering text doesn't seem that intensive, although the encryption it might be. Hiding the mac behind an interface has some appeal, but on the other hand that creates it's own kind of problem.

Regardless cost will be an issue. I wouldn't expect such a product to be less than USD $100 considering cost of materials, parts, time, etc.

 

[VMSZealot]

I've fantasised (briefly) about this too.  It would require a custom network card to be built with a 3 port hub onboard.  One port would provide a connection to the ethernet controller on the card itself (in effect, the ethernet port for the Mac), the second would be for the Raspberry Pi (preferably the zero model) and the third would be a connection to the outside world.  Add a fourth and you could have wireless LAN too!

As mentioned by Nathan, it would be expensive - especially since, for optimum compatibility with existing drivers, it would probably need to be based on the Asante Ethernet cards.  Given how cheap the Pi is though, and how low its power consumption, does it even matter if you have to have one extra bit of hardware on the network?  Stick it next to your router - and then forget about it.

That said, if such a device ever were made, it would make for a pretty sweet accelerator - if anyone fancied writing new software for it.  An API would need to be developed to send work requiring heavy lift to the Pi, and retrieve the results back to the host Mac program. I don't imagine that there'd be much of a market for it - but, given how much nicer System 7 is than the Pixel GUI, it'd make for a nice workstation.

 

[bigmessowires]

It'd be really nice if someone would make a new browser for these machines that conforms to more modern standards as much as possible.

Have you seen Classilla? http://www.floodgap.com/software/classilla/

 

[Nathan]

Yes, I have seen Classilla and it used to work passably for some sites (although supposedly it presents a mobile browser agent these days). However it's very, very far from new (it's built on an the foundations of an even older browser). Unfortunately I have it on my iMac G3 (333mhz) so it might be a little hard to tell what is a hardware deficiency and what is the browser's fault. It would probably do somewhat better on my PM G4.

 

[bigmessowires]

What exactly are you looking for in a "vintage" browser then? You mentioned you wished for a browser that ran on old hardware while conforming as much as possible to modern standards. Classilla is probably as good a solution as you're likely to find. A different browser isn't likely to run any faster on the same hardware, unless you suspect Classilla is somehow designed inefficiently. Adding support for newer web standards (HTML5?) would be nice, but is going to make it run even slower. Realistically, a 20-year-old computer doesn't have horsepower needed to render modern web sites, and no browser software is going to change that. Some kind of gateway or proxy like the one proposed here  (or what's already in MacIPgw) seems like the best path to me for modern web browsing on these machines.

 

[Nathan]

Idk, really, I guess. Maybe it's just wishful thinking. I'd settle for a somewhat stripped down interface to be honest (since the bigger problem is likely just bloated web design or attempts to make it a one size fits all page rather than accomodating a handful of device categories. I'm pretty sure there are plenty of Facebook features that I could care less about. A site like ArsTechnica for instance should be possible to have work. Visually it's mostly text and pictures and occasionally stuff like twitter embeds. It doesn't work in classilla 9.3 though. The same goes for Twitter itself.

^ both sites partially load but don't get to a really working state.

I do suspect that there may be inefficiencies in Classilla, but I wouldn't even know where to look. Most of my programming experience is in Java anyway (I can read C/C++ and probably code reasonably well in the former to a certain degree). If there are any they're probably legacy stuff or design in recent FF that doesn't do well with older OSes or alternate architecture. If  It just seems like a more substantial redesign, even ground-up, might offer some advantages. Rendering HTML and CSS (if that's even the right word at that level) really shouldn't pose any real problems.

Features similar to the old FF RequestPolicy add-on (more granular cross site request policies) might help a lot for all I know.

What exactly needs "horsepower" in rendering anyway? Arranging pictures, showing text, and loading pictures/text from other sites alone really shouldn't be that expensive. I get that streaming video is cpu and network heavy and that interactive games poses some issues, but what else are you referring to?

Tangentially MacOS 9 on my iMac seems to hang a fair bit, but I'm sure there any number of ways to improve that. A clean reinstall on a newer, larger HD might help for one and it may just be the fault of cooperative multi-tasking..

^ Bondi iMac G3 333MHz (upgraded proc) w/ 512mb ram and a 4gb hard drive.

 

[bigmessowires]

I'm not any kind of expert, but I've done enough web development and graphics programming to guess what the challenges are in making a layout engine. CSS can be very complex - you can even specify 3D object transformations in CSS! It also handles stuff like animations and image transparency (implying alpha blending in the browser). Even "simple" CSS involves parsing a gazillion interdependent layout rules to finally determine just how a bit of text or graphics could be rendered. Most modern web sites also make heavy use of javascript, an interpreted language. A little javascript snippet to initialize something isn't a big deal, but when there are complicated javascript functions running continuously, you can notice it even on a modern computer. Add stuff like Flash or HTML5 effects, and rendering a simple web page can be surprisingly complex. There's also also the advertising and analytics stuff embedded in many web pages, which you don't always see, but is still there making server requests and eating up compute power.

If so many web sites didn't use all these effects like candy, it wouldn't be a big deal. I agree a site like ArsTechnica shouldn't really need anything more than a G3 Mac to render its pages, but that's the reality of how most modern web sites are built.

 

[denodster]

I'm currently working on building the first release of Mozilla for PPC mac. based on what I'm looking at it had a build target of a PPC mac running MacOS 7.6. the 68k c++ seems to be present in the source as the maintainers were asking for someone to devise a 68k build of Mozilla, but no one ever stepped up. My thinking is that if I can get it to build on a PPC mac (In Sheephshaver) I can start to strip down features until I'm left with just a bare bones Browser. At which point I would try come up with a build process for 68k macs. From there we could implement modern ssl support if possible. or at least patch up a few web standards.

I've been documenting my efforts here: http://andrew.colchagoff.com/netscapeI'm currently blocked by a lack of a single build tool, but I think I've got a cd on it's way from ebay that will supply the tool I need.