Office really chugged on the PCs of the time though. We can debate whether modern Excel actually delivers enough more value than historical Excel to justify being as more resource-hungry, thus slower to load, as it is. But historical Excel appears fast on modern hardware, even in emulation, because the CPU, RAM, and permanent storage have had 30 years to evolve since it was released. Contemporary 386s and 486s would not have been that snappy.
Let's go back to say around 1994/5. I've just got a job as the first dedicated IT bod for a pie factory near Plymouth (Devon not MA)! Win 3.11 was pretty much everywhere and was almost reliable - patching wasn't really a thing then in the MS world. By then Pentium (586) was a thing but the majority of machines were 80486, 80386s were still useful. There were also the 386/486 SX/DX and DX2 and Cyrix and so on.
The planning spreadsheets were a series of Lotus 1-2-3 jobbies with a lot of manual copy and pasting and I gradually ported it to a Excel VBA job. To cut a long story short, I was running Win311 and Excel on a Pentium 75 with 16MB RAM, IDE HDD. Excel was way quicker to start than on a modern PC running Win 11 with an SSD.
Yes, a lot of things took a while but I ended up with a finite capacity plan in VBA for an entire factory that took less than five minutes per run. That was for meat and dough prep, make, bake and wrap and dispatch for 150 odd finished product lines. It generated a labour plan as well and ran totally to forecast (which it also did). Pasties, sossie rolls etc are generally made to forecast - they take a while to get through the plant and have to be delivered into depot with enough code (shelf life) for the customer (store) to be able to sell them and the consumer to not be given a dose of the trots. As reality kicked in, you input the actual orders etc and it refined the plan.
OK not the best tool for the job but I hope I show that a spreadsheet back in the day was more than capable of doing useful things. I've just fired up LO calc on my laptop with a SSD and it took longer than I remember old school Excel starting up or perhaps the same time.
This is just not true. The only chugging back then was reading from disks, and the entire Office suite was only a handful of 3.5" floppies. If you had already started Excel earlier, then it was likely still cached in RAM and would start nearly instantly. If not, then it was still only a few seconds.
Now what was slow was actual computations. Like try running a big spreadsheet in Excel or counting words in a big Word document on that hardware. It takes a very long time, while on modern hardware it's nearly instant.
This isn't true at all, based on my experiences. Contemporary 386s were kind of slow, I guess, but these programs did not chug on a 486. I spent tons and tons of time in Excel and Access and writing VB/VBScript/macros.
They haven't released the old Excels as open source right?
Wonder if its feasible to reverse the old version using LLMs, vibecode it to run on modern platforms and then shorehorn in support for modern XLS format. At the rate LLMs are improving I hope someone will eventually partake in this challenge!
> Wonder if its feasible to reverse the old version using LLMs, vibecode it to run on modern platforms and then shorehorn in support for modern XLS format.
Oh no it won't. Photoshop PSD and the legacy Office file formats have one thing in common... they are raw dumps of the C in-memory structs representing the contents. That's how they save and load so fast [1], in contrast to the modern formats which are a bunch of XMLs in a ZIP in a trenchcoat. Unfortunately, that makes reverse engineering them not just a challenge in itself, but also reimplementing because you have to reimplement Microsoft's original engines piece by piece, quirk by quirk.
And that's before wading into the mess that is OLE or, yes, the older people will shudder, ActiveX. Or the wonders that VBA macros could achieve, including just running stuff directly from kernel32.dll. I'm reasonably sure you could import the DirectX DLLs into an Office VBA macro and implement a full blown 3D shooter engine with DirectX instead of Excel.
And that's also why conversion in either direction almost always carries loss potential, simply put, not each quirk of the legacy format has been carried over to the "new" XML storage format, and certainly not into OpenOffice XML.
bitwize|8 days ago
gerdesj|8 days ago
Let's go back to say around 1994/5. I've just got a job as the first dedicated IT bod for a pie factory near Plymouth (Devon not MA)! Win 3.11 was pretty much everywhere and was almost reliable - patching wasn't really a thing then in the MS world. By then Pentium (586) was a thing but the majority of machines were 80486, 80386s were still useful. There were also the 386/486 SX/DX and DX2 and Cyrix and so on.
The planning spreadsheets were a series of Lotus 1-2-3 jobbies with a lot of manual copy and pasting and I gradually ported it to a Excel VBA job. To cut a long story short, I was running Win311 and Excel on a Pentium 75 with 16MB RAM, IDE HDD. Excel was way quicker to start than on a modern PC running Win 11 with an SSD.
Yes, a lot of things took a while but I ended up with a finite capacity plan in VBA for an entire factory that took less than five minutes per run. That was for meat and dough prep, make, bake and wrap and dispatch for 150 odd finished product lines. It generated a labour plan as well and ran totally to forecast (which it also did). Pasties, sossie rolls etc are generally made to forecast - they take a while to get through the plant and have to be delivered into depot with enough code (shelf life) for the customer (store) to be able to sell them and the consumer to not be given a dose of the trots. As reality kicked in, you input the actual orders etc and it refined the plan.
OK not the best tool for the job but I hope I show that a spreadsheet back in the day was more than capable of doing useful things. I've just fired up LO calc on my laptop with a SSD and it took longer than I remember old school Excel starting up or perhaps the same time.
queuebert|8 days ago
Now what was slow was actual computations. Like try running a big spreadsheet in Excel or counting words in a big Word document on that hardware. It takes a very long time, while on modern hardware it's nearly instant.
runjake|8 days ago
pjerem|8 days ago
The thing runs instantly. And that's in a VM in Javascript.
nebula8804|8 days ago
Wonder if its feasible to reverse the old version using LLMs, vibecode it to run on modern platforms and then shorehorn in support for modern XLS format. At the rate LLMs are improving I hope someone will eventually partake in this challenge!
mschuster91|8 days ago
Oh no it won't. Photoshop PSD and the legacy Office file formats have one thing in common... they are raw dumps of the C in-memory structs representing the contents. That's how they save and load so fast [1], in contrast to the modern formats which are a bunch of XMLs in a ZIP in a trenchcoat. Unfortunately, that makes reverse engineering them not just a challenge in itself, but also reimplementing because you have to reimplement Microsoft's original engines piece by piece, quirk by quirk.
And that's before wading into the mess that is OLE or, yes, the older people will shudder, ActiveX. Or the wonders that VBA macros could achieve, including just running stuff directly from kernel32.dll. I'm reasonably sure you could import the DirectX DLLs into an Office VBA macro and implement a full blown 3D shooter engine with DirectX instead of Excel.
And that's also why conversion in either direction almost always carries loss potential, simply put, not each quirk of the legacy format has been carried over to the "new" XML storage format, and certainly not into OpenOffice XML.
[1] https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...