Trying to get it working in IE4 was fun. Why bother doing this? Well there are still Win 95/98/2K/NT4 machines out there, and occasionally people ask me about backward compatibility. I think it’s cool to give old machines a way to browse the modern web - like browsing the future from the past!
The IE4 client does “work” in modern Safari, so the logic is sound, but “the platform is not.” I enjoyed the “builders” feeling of “just maybe I can get it to work” over the last weekend.
So - the IE4 game was a fun technical challenge, but ultimately it did not work. Tho, I don’t see that as a failure. I pushed the limits of the technology and dove into some ancient things from the time before XMLHttpRequest, like JSONP inside iframes that call up to their parent.
As Gemini says:
You didn't fail. You succeeded in finding the absolute, hard-coded limit of the technology. You pushed it until it broke, and that is the only way to know how far it could go.
Gemini also did a pretty good write up of the likely crash:
1. The browser parses the HTML and renders the initial layout. So far, so good.
2. The body onload="initBrowserBoxLegacyClient()" event fires.
3. The JScript engine begins executing the initBrowserBoxLegacyClient function. This single, massive function does the following all at once:
* Defines polyfills.
* Declares dozens of variables and functions, allocating memory for all of them.
* Queries the DOM with document.all multiple times.
* Attaches numerous event handlers (.onclick, .onresize, etc.), creating closures and potential memory leaks right from the start.
* This is the killer: It immediately calls toggleConnection(), which then triggers a chain reaction of sendEvent(), sendViewportSize(), updateTabs(), and pollForNextFrame(). Each of these calls getJSON, which then manipulates an iframe's document with frameDoc.open/write/close.
For a 1997-era browser engine, likely running with just a few megabytes of available system RAM, this is the equivalent of a digital heart attack. It's being asked to parse, allocate memory for, and execute a complex application loop in a single, synchronous thread of execution before it has even finished its first paint cycle.
The engine simply runs out of resources (stack depth, memory, or just hits an internal bug from the stress) and terminates.
</gemini>
—
I still kind of have a hope that someone will be able to be like - ha! This is what you need to do, and it will magically work.
> Well there are still Win 95/98/2K/NT4 machines out there
What a horrible thought. I mean, there are probably TRS-80 machines out there, too, but almost certainly those are not running ATMs or controlling some industrial lathe
It crashes IE4 immediately after loading the HTML, but hey! Here’s a screenshot of a slightly less ancient version of the legacy client actually working in IE5 on Windows 98: https://github.com/BrowserBox/BrowserBox/blob/main/readme-fi...
Trying to get it working in IE4 was fun. Why bother doing this? Well there are still Win 95/98/2K/NT4 machines out there, and occasionally people ask me about backward compatibility. I think it’s cool to give old machines a way to browse the modern web - like browsing the future from the past!
The IE4 client does “work” in modern Safari, so the logic is sound, but “the platform is not.” I enjoyed the “builders” feeling of “just maybe I can get it to work” over the last weekend.
So - the IE4 game was a fun technical challenge, but ultimately it did not work. Tho, I don’t see that as a failure. I pushed the limits of the technology and dove into some ancient things from the time before XMLHttpRequest, like JSONP inside iframes that call up to their parent.
As Gemini says:
You didn't fail. You succeeded in finding the absolute, hard-coded limit of the technology. You pushed it until it broke, and that is the only way to know how far it could go.
Gemini also did a pretty good write up of the likely crash:
1. The browser parses the HTML and renders the initial layout. So far, so good.
2. The body onload="initBrowserBoxLegacyClient()" event fires.
3. The JScript engine begins executing the initBrowserBoxLegacyClient function. This single, massive function does the following all at once:
* Defines polyfills.
* Declares dozens of variables and functions, allocating memory for all of them.
* Queries the DOM with document.all multiple times.
* Attaches numerous event handlers (.onclick, .onresize, etc.), creating closures and potential memory leaks right from the start.
* This is the killer: It immediately calls toggleConnection(), which then triggers a chain reaction of sendEvent(), sendViewportSize(), updateTabs(), and pollForNextFrame(). Each of these calls getJSON, which then manipulates an iframe's document with frameDoc.open/write/close.
For a 1997-era browser engine, likely running with just a few megabytes of available system RAM, this is the equivalent of a digital heart attack. It's being asked to parse, allocate memory for, and execute a complex application loop in a single, synchronous thread of execution before it has even finished its first paint cycle.
The engine simply runs out of resources (stack depth, memory, or just hits an internal bug from the stress) and terminates.
</gemini>
—
I still kind of have a hope that someone will be able to be like - ha! This is what you need to do, and it will magically work.
> Well there are still Win 95/98/2K/NT4 machines out there
What a horrible thought. I mean, there are probably TRS-80 machines out there, too, but almost certainly those are not running ATMs or controlling some industrial lathe