TCL/Tk too, albeit being far less intuitive than Lazarus+FreePascal. Altough it has far less code, so it's a draw on difficulty. The average Joe would just spend time measuring the sizes of the frames and that's it.
Very excited to see Superlogo there! As a Dutch kid I grew up with Windows 3.11 and have devoured all "Programmeren voor Kinderen" books that made me learn to love programming.
This is super cool! Ran into an issue though, the first time it boots perfectly, after the first refresh it loads for a bit (downloads the image again instead of from cache) and then a cachebuster URL is added and loading starts over, without ever finishing. Ideally it would just load from cache on refresh.
True story, and keep it in your hat if you know it:
I was expelled from highschool about 3 months in to my freshman year for doing this on the library computers to bypass the librarian needing to log us in, because the Mac lab printers weren't working and the report was due next period. Librarian was like "nah i'm on lunch" so i waited like 15 minutes, bypassed, printed, exited windows.
She was fuming, shaking showing printed papers with "autoexec.bat" showing an edit time[1] while she "was on lunch" and i "was the only one in there".
I actually got expelled from that school 3 times, twice for "hacking."
[1] hold shift to get to MS-DOS without restriction, edit AUTOEXEC.BAT to comment out the "security" "software" line, reboot. remove the commented line, reboot.
I think, I may be wrong Windows 3.11 was the last Window that provide instantaneous GUI response. Windows 95 was still fast by today's standard but it wasn't "instant".
Windows 3.x did not have preemptive multitasking, apps had to yield in the message loop (cooperative multitasking). This meant that an instantaneous response was possible, but often wasn't, at all. Win95 brought true preemptive multitasking, which was a breath of fresh air.
Can't help myself: whenever I see Windows 3.11, I have to compute the difference between it and Windows 3.1. So, I fire up the calculator from the Accessories folder, and compute 3.11 - 3.1. The result: 0.00. Try it! :-)
I started from Windows 98 and always loved the icons. They actually represented the application and purpose. These days they are more focused on looking modern. Lots of times they are not even distinguishable between each other.
I love everything except the mouse emulation, it makes it really clunky and hard to click on anything. Any way to let me just use the normal pointer in the browser instead of a javascript abstracted one?
If this were a commercial project then I could understand the complaint.. but this is just a small, for-fun project and they have little motivation to put the extra effort into support for all browsers.
Bellard (yes, him) already had a working VM of Windows 2000 in the browser around a decade ago, with no specific "support for all browsers" (whatever that means):
Also, look at 8086tiny, or PCulator/XTulator. These could be ported with ease to EMSCripten and run everywhere, not just in Chrome.
Chrome almost became the new IE and Google, despite it's motto, the new Microsoft. Ok, the desktop? Android rules the smartphone sales in the world, and its online services are used by millions, with far more metadata grabbing than w9x/wxp on its day and with the same propietary OSes.
Consider: maybe it's not a matter of non-standard APIs, but bad performance. It's not simply porting to the lowest common denominator, it's making sure the code doesn't run at a snail's pace because the JIT/wasm compiler has a pathological edge case.
I'm not really complaining; just harking back to a shitty time that is, on some commercial sites, threatening to return. Especially as Apple finally allows Chrome on iOS, eroding the main bastion against it: Safari.
The long pause after "Verifying DMI Pool Data..." as the disk image downloaded aroused a dormant feeling of dread in me as I panicked and wondered why Windows wasn't loading... back in the day it meant getting yelled at for "breaking" the computer and tasked with spending the day reinstalling Windows and everybody's programs.
Nostalgia tends to make things seem better than they were. Moments like this remind me how much tech has improved over the years.
I used a doublespace/drivespace volume for Windows. Backup was just booting from a floppy and making a copy of that file. Reinstall was "format c:", "sys a: c:", copy the volume file and dblspace.ini from backup.
Ah. Every time I look at the UI, I realize just how much the modern UI/UX degraded.
We had clear colorful icons, text labels, scrollbars, clearly distinguishable checkboxes. And now we have UI that actively promotes "rebelliousness" and "being in the know".
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.
The world runs on Excel. It is the largest development environment by far and no fancy language/framework can come close to touch it. The reason is because it acts as the glue to get real life things done in everything from large governments, militaries, large corporations all the way down to the small bed and breakfast operation across the entire world. Normal people have gotten real processes built by just twiddling around in Excel.
Sadly, Excel and the dumbness of the environment generated disasters on Genomics (and tons of other research areas too) causing millions if not billions of losses. Hint: skewed experiments/data and so on, making years of effort worthless.
That woudn't happen under BioPython/BioPer/Rl and a custom dedicated interface with no data mangling at all.
Poeple in the 90's joked about how MS turned the whole IT industry 20 years back. Now, literally, and not just IT.
And that's sad, because you have Turbo Pascal, Windows NT, the VB6 IDE against C/C++ libraries... good products on MS where data correctned was granted with low level libraries called from VB. For sure BLAS/Lapack would exist in the 90's as products for Visual C/C++.
Reusing MS Office for advanced tasks was the key of the shitty computing we were suffering on tons of places. Such as the idiots using Excel tables for Covid patients instead of having a proper SQL database. Even SQlite (IDK about the constraints, maybe it fits) could have been a better choice.
People said with Unix "Worse it's beter". He, nowadays even NDB 'databases' would grant you correctness on scientific data (it's plain text with tuples) that these rotten binary, propietary, office bound pseudo databases and spreadsheets. Or even AWK with CSV's/TSV's.
You're forgetting that Excel is the most ergonomic programming language in the world, full stop, nothing else even comes close. Until it's as easy to build something with those other things as it is to whip up a sheet in Excel, they're not leaving the starting gate when it comes to usage, especially by people who are not professional software devs
Ergonomic? Who cares? By 'ergonomic' a notebook it's zillions better than Excel or even Org-mode from Emacs when you don't even have to deal with the limited input from the cells, or worse, localized functions in spreadsheets. Go try debugging some functions in Spanish or German being yourself a native English speaker.
The most ergonomic programming environment in the world today it's a mix between a notebook and a REPL with live changes. Something like a cross between Smalltalk and Jupyter, and that doesn't exist yet. Org-mode for Elisp it's close as it allows you to do literate programming, a REPL and such in a 'live' and documented way.
yep and that was Windows which introduced levels of latency and waiting times much worse than equivalent DOS software, but with easier to use and more intuitive menus instead of the usual DOS UI routine of either no menus or menus that showed with key combos, and power users knowing many key combination combos which weren't strictly necessary but both accelerated things and impressed newbs into thinking computers were too hard for them
on a 486, Lotus 1-2-3 was essentially instant - even from floppy disks it would run faster than excel does today on a top of the line machine
I did earn some bread with vba as well, and always advocate for efficiency, but I just opened a 12MB xlsx file in LO, and it took a couple of seconds on a 2024 thinkpad.
As far as I remember, my Win 3.11 machine (a 486 DX with 4MB RAM and 30MB HDD) wouldn't be able to store or open such a file, let alone recognize the extension. Also, it would call the file 2026022~.XL~ or something. And it took more than a couple of seconds to load office programs for sure. It would take well over a minute to load a book from a 1.44MB floppy.
Anyway, software and computers have come a long way and I'm grateful for it.
That file name thing was from Win95 keeping DOS (FAT) compatibility by introducing FAT32/VFAT: long file names were truncated to standard 8.3 names from DOS (and by extension, Win3.11 too) with fs extensions used to store long file names alongside DOS names. Win95 would show long names, DOS would show shorter ones.
Also, file formats were binary optimized at the time, compared to current XML behemoths compressed with zip. So 12MB file in 1993 is probably something like 100k+ rows, and try that out today.
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 does not match my memory of using Windows 3.1. Excel would likely not have been cached in RAM from a previous run because a typical Windows 3.1 machine only had 4 megabytes of RAM.
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.
I mean if people are reverse engineering entire n64 games into its original code that can target the original SGI compilers, then it is possible to reverse this other code. I don't think there is a drive to do so though. Thats where I hope some future LLM could help lower that barrier to people already well experienced in reversing.
>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.
Can modern Office reliably open the old formats? If so they must have implemented the parsers correctly no?
> Can modern Office reliably open the old formats? If so they must have implemented the parsers correctly no?
It can. But at two costs: first, MS has to keep all that legacy garbage code around - and we all know that just blindly deserializing stuff from potentially hostile input raw into C structs is ripe for getting exploited, and there have been a lot of bugs in there. And the second cost is, you can't reliably save an old document into a new XML document, hence the warning you get "this document was created in an old version of Office, are you sure you want to save it".
So simple, so easy. Those were the days.
Instead folks go with Electron crap.
I wrote a blog about this many years ago: https://latedev.wordpress.com/2011/10/06/simple-windows-dial...
Discussion from Nov, 2024 with 160 points and 75 comments: https://news.ycombinator.com/item?id=42104531
True story, and keep it in your hat if you know it:
I was expelled from highschool about 3 months in to my freshman year for doing this on the library computers to bypass the librarian needing to log us in, because the Mac lab printers weren't working and the report was due next period. Librarian was like "nah i'm on lunch" so i waited like 15 minutes, bypassed, printed, exited windows.
She was fuming, shaking showing printed papers with "autoexec.bat" showing an edit time[1] while she "was on lunch" and i "was the only one in there".
I actually got expelled from that school 3 times, twice for "hacking."
[1] hold shift to get to MS-DOS without restriction, edit AUTOEXEC.BAT to comment out the "security" "software" line, reboot. remove the commented line, reboot.
I really would have liked to play Syndicate.
I started from Windows 98 and always loved the icons. They actually represented the application and purpose. These days they are more focused on looking modern. Lots of times they are not even distinguishable between each other.
The icons used in desktop are/were in progman.exe, shell32.dll and control.exe (IIRC, it was a long time ago).
What were the MS-DOS programs that Windows used the progman.exe stock icons for?
https://devblogs.microsoft.com/oldnewthing/20250506-00/?p=11...
What were the intended uses of those icons in moricons.dll?
https://devblogs.microsoft.com/oldnewthing/20250505-00/?p=11...
That's not Windows 3.11. That kind of thing is circa 2000, and a state none of us should want the Web to return to.
https://bellard.org/jslinux/vm.html?url=win2k.cfg&mem=192&gr...
Chrome almost became the new IE and Google, despite it's motto, the new Microsoft. Ok, the desktop? Android rules the smartphone sales in the world, and its online services are used by millions, with far more metadata grabbing than w9x/wxp on its day and with the same propietary OSes.
Nostalgia tends to make things seem better than they were. Moments like this remind me how much tech has improved over the years.
We had clear colorful icons, text labels, scrollbars, clearly distinguishable checkboxes. And now we have UI that actively promotes "rebelliousness" and "being in the know".
Related: https://devblogs.microsoft.com/oldnewthing/20251125-00/?p=11...
em-dosbox is a good project.
The thing runs instantly. And that's in a VM in Javascript.
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.
That woudn't happen under BioPython/BioPer/Rl and a custom dedicated interface with no data mangling at all.
Poeple in the 90's joked about how MS turned the whole IT industry 20 years back. Now, literally, and not just IT.
And that's sad, because you have Turbo Pascal, Windows NT, the VB6 IDE against C/C++ libraries... good products on MS where data correctned was granted with low level libraries called from VB. For sure BLAS/Lapack would exist in the 90's as products for Visual C/C++.
Reusing MS Office for advanced tasks was the key of the shitty computing we were suffering on tons of places. Such as the idiots using Excel tables for Covid patients instead of having a proper SQL database. Even SQlite (IDK about the constraints, maybe it fits) could have been a better choice.
People said with Unix "Worse it's beter". He, nowadays even NDB 'databases' would grant you correctness on scientific data (it's plain text with tuples) that these rotten binary, propietary, office bound pseudo databases and spreadsheets. Or even AWK with CSV's/TSV's.
The most ergonomic programming environment in the world today it's a mix between a notebook and a REPL with live changes. Something like a cross between Smalltalk and Jupyter, and that doesn't exist yet. Org-mode for Elisp it's close as it allows you to do literate programming, a REPL and such in a 'live' and documented way.
on a 486, Lotus 1-2-3 was essentially instant - even from floppy disks it would run faster than excel does today on a top of the line machine
As far as I remember, my Win 3.11 machine (a 486 DX with 4MB RAM and 30MB HDD) wouldn't be able to store or open such a file, let alone recognize the extension. Also, it would call the file 2026022~.XL~ or something. And it took more than a couple of seconds to load office programs for sure. It would take well over a minute to load a book from a 1.44MB floppy.
Anyway, software and computers have come a long way and I'm grateful for it.
Also, file formats were binary optimized at the time, compared to current XML behemoths compressed with zip. So 12MB file in 1993 is probably something like 100k+ rows, and try that out today.
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.
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!
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...
>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.
Can modern Office reliably open the old formats? If so they must have implemented the parsers correctly no?
It can. But at two costs: first, MS has to keep all that legacy garbage code around - and we all know that just blindly deserializing stuff from potentially hostile input raw into C structs is ripe for getting exploited, and there have been a lot of bugs in there. And the second cost is, you can't reliably save an old document into a new XML document, hence the warning you get "this document was created in an old version of Office, are you sure you want to save it".
2024 https://news.ycombinator.com/item?id=42104531