MacSurf — a real NetSurf-based browser for Mac OS 9 (CSS3, ES5 JS, native HTTPS)
- Thread starter ptricky
- Start date
Yeah for sure. None of it is "worth doing" at the root of it, I just love classic Mac OS and wanted to see what could be accomplished. I think the next step would be to see how far down I could get some form of modern browser to work on these systems.It's probably not worth spending a bunch of time on 8.6 since anything that realistically make use of this browser should have no trouble running OS 9, but I'm sure some people would enjoy it
That's great, because a few of my favorite machines I have run 8.6. Anything sub 500Mhz seems to run 9 poorly, so I avoid it.
I feel like I have to apologize on behalf of the whole forum of members about your being trolled about having used AI to code your browser.
Just to be clear: I don't like AI and don't particularly want to use it myself, nor do I like those who don't bother to proofread what the AI puts out and just present the slop as is (this, to me, amounts almost to a form of plagiarism), I'm all for people who know how to code, and are simply using AI as an aid to speed their projects along and/or accomplish things that would be too difficult or time intensive to do on their own.
That said, I'm excited about the prospect of having a new up to date, modern and standards-compliant browser for classic Mac OS.
c
Just to be clear: I don't like AI and don't particularly want to use it myself, nor do I like those who don't bother to proofread what the AI puts out and just present the slop as is (this, to me, amounts almost to a form of plagiarism), I'm all for people who know how to code, and are simply using AI as an aid to speed their projects along and/or accomplish things that would be too difficult or time intensive to do on their own.
That said, I'm excited about the prospect of having a new up to date, modern and standards-compliant browser for classic Mac OS.
c
I understand the reaction, AI seems to be a lot of good and a lot of bad, it can easily be labeled the best or worst development in the past ten years. It's also easy to dismiss the work if you don't realize it's much more complicated than just writing C code.
Regardless, I hope to push the possibilities of what macsurf can do until I'm forced to call it enough. As of the most recent code changes it now runs with native TLS 1.2 from the mac itself, without the need for a proxy. This opens up a lot more possibilities and modern sites once I iron out the CSS and load balancing.
I admit freely there is no way I could do this without AI. I would definitely need a large team to complete a lot of the mundane tasks that have been required to get it working at this stage. At the same time I have been coding and building websites since my first computer, which wasn't a computer it was a WebTV, and have a reasonably good idea of how to properly manage a product.
Either way it's a passion project that I hope gets better everyday and becomes something people can open on their old macs and browse modern sites for no reason other than they want to and it's now possible.
Regardless, I hope to push the possibilities of what macsurf can do until I'm forced to call it enough. As of the most recent code changes it now runs with native TLS 1.2 from the mac itself, without the need for a proxy. This opens up a lot more possibilities and modern sites once I iron out the CSS and load balancing.
I admit freely there is no way I could do this without AI. I would definitely need a large team to complete a lot of the mundane tasks that have been required to get it working at this stage. At the same time I have been coding and building websites since my first computer, which wasn't a computer it was a WebTV, and have a reasonably good idea of how to properly manage a product.
Either way it's a passion project that I hope gets better everyday and becomes something people can open on their old macs and browse modern sites for no reason other than they want to and it's now possible.
V1.3.1 is live with a fresh face and dozens of improvements.
Multi-curve ECDHE lands in TLS 1.3. macTLS now offers three curves in supported_groups — X25519, P-256, P-384 — and handles HelloRetryRequest cleanly. That unblocks servers that disallow X25519 (FIPS zones, certain XenForo-on-nginx configs, some Cloudflare strict zones).
68kmla.org/bb/ — one of the largest active Classic Mac communities — now fully renders on a G3 iMac via TLS 1.3 + P-384.
Mind you there is so much work for me to do but a lot is getting done every day?
Multi-curve ECDHE lands in TLS 1.3. macTLS now offers three curves in supported_groups — X25519, P-256, P-384 — and handles HelloRetryRequest cleanly. That unblocks servers that disallow X25519 (FIPS zones, certain XenForo-on-nginx configs, some Cloudflare strict zones).
68kmla.org/bb/ — one of the largest active Classic Mac communities — now fully renders on a G3 iMac via TLS 1.3 + P-384.
Mind you there is so much work for me to do but a lot is getting done every day?
Impressive work. Indeed, your work is impressive, and it shows. LLMs with/without agentic coding are merely software tools like any other, such as Excel, or CWPro8, or ResEdit, and so on. While there are many good reasons to favor pure traditional coding, there's absolutely no issue here so far, especially because you are curating the work, testing the work, and sharing the work here with others, so that more people test the work and provide valuable feedback.
On behalf of all Mac OS users (the real deal, not the UNIX spinoffs), thank you for making this, since Mac OS, specifically Mac OS 9.2.2, is my daily driver OS on real hardware to this day above all the other OSes out there. (And when not using it, Windows 7 is my fallback option, e.g. for MKV and MP4 videos.)
I will test your browser at the first opportunity I get, with its native TLS (no proxies wanted on my end).
In advance, may I give a bit of feedback already? Regarding Carbon.
The main advantage of Carbon is so that your application runs not just on Mac OS, but also natively on OS X, up to 10.6.8 Snow Leopard. While this is nice for users on 10.0 Cheetah ~ 10.3 Panther, who lack TenFourFox and its descendants, it comes at a cost, at the expense of the real Mac OS: performance. On Mac OS, such as Mac OS 9, Carbon API calls are more expensive than their equivalent Macintosh Toolbox API calls. You can easily see this by running any application from "back in the day" that had both a Carbon and a non-Carbon version. I believe there's also a significant RAM footprint reduction in doing so.
In other words, it's not a deal breaker as is, but if you switch from Carbon to Mac Toolbox, you have greater chances of success at bringing more and more modern webbrowser features to this venerable OS. As a side benefit, you even make it System-7-compatible by ditching Carbon, for some of the serious System 7 users out there.
(As a side-note, earlier versions of CarbonLib also supported Mac OS as low as Mac OS 8.1, however since CarbonLib is PowerPC-only, there's hardly any justification to target such older versions of Carbon, as Mac OS 8.1 only serves more of a purpose on 68k hardware that can't go beyond.)
Regardless, do focus on whatever you'd rather focus on, I don't mean to distract. This was just a "FYI" kinda thing. My rig will run any Carbon app very happily. (Mac mini G4 1.5 GHz model.)
Based on various benchmarks and other testings carried out by user "MacTron" of "Mac OS 9 Lives!", even when using all the exact same extensions between both OSes, Mac OS 9.2.2 outperforms Mac OS 8.6 for most (but not all) tasks. Most of the speed benefits were introduced in Mac OS 9.2, which were carried over to 9.2.1 and 9.2.2, as well. I'm not sure if the result of the tests are applicable to only G4s, or also to all PPC hardware they can run on, but you may want to give it another shot. It's also important to make sure to use the latest Mac OS ROM file, as well, with the latest CPU Software version (which you can see from invoking "Get Info" on the ROM file).
That being said, Mac OS 8.6 is also great, and is closer to Mac OS 9 than it is to its immediate predecessor, Mac OS 8.5.1 (complete PPC nanokernel overhaul, AKA nanokernel v2 or nkv2).
On behalf of all Mac OS users (the real deal, not the UNIX spinoffs), thank you for making this, since Mac OS, specifically Mac OS 9.2.2, is my daily driver OS on real hardware to this day above all the other OSes out there. (And when not using it, Windows 7 is my fallback option, e.g. for MKV and MP4 videos.)
I will test your browser at the first opportunity I get, with its native TLS (no proxies wanted on my end).
In advance, may I give a bit of feedback already? Regarding Carbon.
The main advantage of Carbon is so that your application runs not just on Mac OS, but also natively on OS X, up to 10.6.8 Snow Leopard. While this is nice for users on 10.0 Cheetah ~ 10.3 Panther, who lack TenFourFox and its descendants, it comes at a cost, at the expense of the real Mac OS: performance. On Mac OS, such as Mac OS 9, Carbon API calls are more expensive than their equivalent Macintosh Toolbox API calls. You can easily see this by running any application from "back in the day" that had both a Carbon and a non-Carbon version. I believe there's also a significant RAM footprint reduction in doing so.
In other words, it's not a deal breaker as is, but if you switch from Carbon to Mac Toolbox, you have greater chances of success at bringing more and more modern webbrowser features to this venerable OS. As a side benefit, you even make it System-7-compatible by ditching Carbon, for some of the serious System 7 users out there.
(As a side-note, earlier versions of CarbonLib also supported Mac OS as low as Mac OS 8.1, however since CarbonLib is PowerPC-only, there's hardly any justification to target such older versions of Carbon, as Mac OS 8.1 only serves more of a purpose on 68k hardware that can't go beyond.)
Regardless, do focus on whatever you'd rather focus on, I don't mean to distract. This was just a "FYI" kinda thing. My rig will run any Carbon app very happily. (Mac mini G4 1.5 GHz model.)
Based on various benchmarks and other testings carried out by user "MacTron" of "Mac OS 9 Lives!", even when using all the exact same extensions between both OSes, Mac OS 9.2.2 outperforms Mac OS 8.6 for most (but not all) tasks. Most of the speed benefits were introduced in Mac OS 9.2, which were carried over to 9.2.1 and 9.2.2, as well. I'm not sure if the result of the tests are applicable to only G4s, or also to all PPC hardware they can run on, but you may want to give it another shot. It's also important to make sure to use the latest Mac OS ROM file, as well, with the latest CPU Software version (which you can see from invoking "Get Info" on the ROM file).
That being said, Mac OS 8.6 is also great, and is closer to Mac OS 9 than it is to its immediate predecessor, Mac OS 8.5.1 (complete PPC nanokernel overhaul, AKA nanokernel v2 or nkv2).
Thank you, that means a lot, especially coming from someone running 9.2.2 as a daily driver on real hardware. That's exactly who I'm building this for.
And great feedback on Carbon. You're right on the facts: the CarbonLib calls do carry overhead on OS 9, the RAM cost is real, and honestly the big Carbon selling point (running on OS X too) is one I'm not even using, since this is OS 9 first and always.
Where I've landed though is that Carbon isn't really what's holding the modern stuff back. The slow parts on a G3 are the CSS layout, the JavaScript engine, and the TLS crypto, all of which are heavy math in my own code, not Toolbox call overhead. The drawing path is mostly straight QuickDraw already. So dropping Carbon would buy a bit of RAM and a few percent, but it wouldn't move the ceiling much.
The one spot where you're really onto something is stability: a couple of my nastier crashes are CarbonLib bugs (the scroll bar and the mouse wheel), and a pure Toolbox build would just not have them.
So I do think a Toolbox version is worth doing someday, and it's the only way to ever reach System 7. But it's basically a second frontend rather than a tweak, since the networking layer is tied to Carbon's Open Transport calls. The good news is the engine, CSS, JS, images, and TLS would all carry over untouched, so it's a parallel project on the same core, not a rewrite.
For now I'll keep pushing features on the Carbon build, but this is staying on the roadmap. Really appreciate you taking the time, and enjoy it on the mini G4, that thing will fly compared to my test G3.
And great feedback on Carbon. You're right on the facts: the CarbonLib calls do carry overhead on OS 9, the RAM cost is real, and honestly the big Carbon selling point (running on OS X too) is one I'm not even using, since this is OS 9 first and always.
Where I've landed though is that Carbon isn't really what's holding the modern stuff back. The slow parts on a G3 are the CSS layout, the JavaScript engine, and the TLS crypto, all of which are heavy math in my own code, not Toolbox call overhead. The drawing path is mostly straight QuickDraw already. So dropping Carbon would buy a bit of RAM and a few percent, but it wouldn't move the ceiling much.
The one spot where you're really onto something is stability: a couple of my nastier crashes are CarbonLib bugs (the scroll bar and the mouse wheel), and a pure Toolbox build would just not have them.
So I do think a Toolbox version is worth doing someday, and it's the only way to ever reach System 7. But it's basically a second frontend rather than a tweak, since the networking layer is tied to Carbon's Open Transport calls. The good news is the engine, CSS, JS, images, and TLS would all carry over untouched, so it's a parallel project on the same core, not a rewrite.
For now I'll keep pushing features on the Carbon build, but this is staying on the roadmap. Really appreciate you taking the time, and enjoy it on the mini G4, that thing will fly compared to my test G3.
All of my sub-500Mhz machines are pre-G3 Powermacs, so they only support 9.1, not 9.2, or maybe that doesn't matter much? My use case was a 225Mhz 603e, then the same system with a 400MHz G3 accelerator card. I'm willing to try it again, as a fun project, because I'd like to be mistaken on this one. It's been years.
More on topic, I have yet to try this browser, and I'm mad at myself because last night I was looking up an MSDOS Midi juke box to play music on an 8088, and I booted up a machine with Classizilla and Internet Explorer running through a proxy and both were atrocious to try to do anything with. This experience will be my reminder.
Ha, an MSDOS MIDI jukebox for an 8088 is the most retro-computing sentence I've read all week.
On 9.1 vs 9.2, don't worry, it runs fine on 9.1. The only real difference is that text looks a little rougher, because 9.1's font smoothing is weaker than 9.2's. That's an OS thing, not the browser, and it's purely cosmetic.
For the hardware, go with the 400MHz G3 card. The plain 225MHz 603e will boot it, but the TLS handshake and the JavaScript will crawl, since those are the heavy math parts. The G3 card puts you right in the range I actually test against.
And honestly, that Classilla and IE through a proxy experience is the exact itch I was trying to scratch. Native TLS, no proxy, talking straight to the site. It is still early alpha, so hand built and retro style pages are where it shines and the big modern sites are still rough, but the goal is for it to not feel atrocious.
Would love to hear how it goes on the G3 card, screenshots especially. Real hardware reports are gold.
It does, actually. 9.1 is considerably heavier than 9.2. I think it is also heavier than its immediate predecessor, 9.0.4, which is also generally good at replacing 8.6.
For most, but not all, machines stuck at 9.1 maximum, you can use OS 9 Helper. See if you can get 9.2.x running?