[gwervc]

Even functionally it's very comical because of how we were able to do on Win98 (even 95) almost everything we are doing today: editing documents, browsing the web (with images), playing games, watching videos, printing documents, listening to music.

The only functional improvements I can note over two decades are: Unicode support, higher resolution of everything (from hardware to content), and system reliability thanks to driver isolation.

[signal11]

Higher resolutions (and the accompanying resource sizes) would be hell for 32-bit OSes though.

Also, it’s kind of amazing that many web pages these days are larger than Doom shareware’s zip size.

[M95D]

Not true. Or it's true because of software bloat and resource waste these days.

When I was a teenager, I wanted to see what was the maximum resolution my monitor supported. It was a Samsung Syncmaster 14" entirely analog, no OSD, with analog adjustment knobs on the bottom. The video card was a Matrox Millennium II 8MB VRAM and the OS was Windows 3.10. The maximum resolution that I could get was 1600x1200 @ 41Hz interlaced. That's almost 2K (1.92K to be more precise). 41Hz interlaced hurt my eyes like hell but everything worked on the software side.

[nightski]

There's a lot more to it than just increasing the resolution. Graphics, animations, font rendering quality, huge images, the list goes on.

[userbinator]

Most of that is GPU-accelerated anyway so the OS / CPU doesn't need to do much beyond telling the GPU what to do.

[TheOtherHobbes]

That's clearly not true.

I can run a full virtual music studio on my Mac, with tens of channels, each with a collection of plugins, and multiple samples and audio files streaming off SSD at the same time.

None of that is GPU accelerated - except maybe the UI, which is split across three 4k monitors

On Windows 95 I could barely play a single WAV at once, and a dual monitor system was an exotic luxury.

Hardware has gotten a lot faster, and the software can do more without crashing. (Mostly.)

The real problem has been the move to browser+cloud for productivity applications. The OS is a front end for the browser, which is a front end for remote compute. This is hugely slow and inefficient compared to making everything work locally, and perhaps including some cloud-ish hooks for sharing.

[M95D]

Graphics: Win3.10 had just the right amount.

Animations: NO, THANK YOU!

Font rendering quality: It increases with font size, which is needed for high res displays. Besides, current font authors don't waste any time doing manual font hinting like the old fonts had. Good luck having crisp font rendering without manual hinting! It's all just a blur since antialiasing was introduced.

Huge images: How huge? Win95 without any patches can allocate 500MB to a single program (image viewer). That's 170 megapixels @ 24bit-color.

[monocasa]

I mean, I was rocking a 1920x1200 CRT for my Win2k/Win98SE dual boot system that I had until WinXP64. They were plenty capable of efficiently using the screen real estate.

[therein]

I remember seeing Win9x UI on a really high resolution CRT display for the first time in early 2000s. It just had so much visual appeal to it.

[Amezarak]

I ran a 1999-era machine well into the 2000s (I think 2007?) with Windows 98SE on 1600x1200 and it worked great, and faster than the XP computer I had.

[charles_f]

1) if you're just referring to pointer size, wouldn't it be mostly a matter of computer hardware and recompiling to 64bit exes? Functionally it's the same 2) there's less cluster and more optimization. Why would it suffer at anything?

[inferiorhuman]

Sure, and on the mac side you've got Infinite Mac dot org where you can run System 1 through MacOS 9.0 in the browser. It's crazy to see how fast System 7.5 (which is more or less peak classic mac IMO) boots up versus System 9.0, and just how much attention to detail there was back then.

[actionfromafar]

Windows NT 3.51 had driver isolation. Unicode could have been added to Windows XP.

[projektfu]

Windows NT 3.1 (the first released version) had Unicode, but it was before Unicode 2.0.

[gus_massa]

> editing documents

Orthography and grammar checking was too slow. You had to press a button to check them, and it missed a lot of tricky cases.

[calamari4065]

That's really just because the techniques we use now weren't developed then. I'd bet good money that a port of a modern spell checker would perform beautifully on an old 98 machine.

It's easy to confuse the bad performance of old software with the hardware it's on. But really a lot of the trouble is that the solutions we had to software problems back then are primitive and naive compared to the current state of the art. There's no reason that current software design practices can't massively improve older systems.

Hell, just try installing a modern Linux on an ancient PC, you'll see what I mean. Even considering that the hardware is physically slower, your experience is much, much closer to modern computing than 98 could ever hope to achieve.

[hughw]

Win98 had pretty great Unicode support, didn't it? Or am I confusing it with general multibyte?

[dblohm7]

No unicode in Win98.

[pjmlp]

Even further behind, an Amiga 500 would be more than enough for many folks.

[galangalalgol]

The memory footprint of workbench was incredibly low. A base alpine image with no support for any graphics is several times that size. What are we doing?

[deaddodo]

Workbench had a very limited hardware it supported. Linux Kernel supports 1000x as many pieces of hardware from different CPU configurations, all the way to the most random USB/Firewire devices.

Like, software bloat is totally a thing, but comparing Workbench to the Linux Kernel (let alone the entire GNU/Linux environment) is ridiculously naive.

[galangalalgol]

An alpine docker container doesn't have the kernel, so all that hardware support, and the kernel itself are still on top of that ~8MB GUI-less image. Part of it is elf header size vs hulk. Part of it is that no one bothers stripping symbols. But the reason for both of those reasons is simply that memory isn't scarce so we are lazy/efficient.

[deaddodo]

> An alpine docker container doesn't have the kernel, so all that hardware support

Only if you run it on Linux through para virtualization; in which case it's using the host's kernel. Potato/potato.

The fact that it supports virtualizing an entire other OS in a safe and privileged manner should just further reinforce why the kernel is larger. But ok, got me.

> 8MB GUI-less image

Sure, and you can see all of the contents of that here:

https://github.com/linuxserver/docker-baseimage-alpine/blob/...

Let's just pick a few things from that:

  curl - a library that can handle full bidirectional HTTP communication in Unicode, including via SSL/TLS and arbitrarily manage file streams *or* utilize linux's built-in piping/redirection functionality
  ssl - a full suite of cryptographic libraries and keys to allow secure communications and integration into other libraries/code (the aforementioned curl, for instance)
  onigurama - a full regular expression library for use in other programs (language VMs like Ruby, for instance)
  musl - a libc runtime and it's standard library
  zlib - in-built compression functionality utilized by gzip, png and others

Can you point to a base install of workbench being able to do all of that? About the only thing in the alpine base layout that it is directly comparable to is BusyBox+bash.

> Part of it is elf header size vs hulk. Part of it is that no one bothers stripping symbols. But the reason for both of those reasons is simply that memory isn't scarce so we are lazy/efficient.

This is just some old guy "bah humbug" rant/conspiracy. Your Amiga with workbench is nowhere comparable to modern hardware+OSes. It can do somethings similarly, if you squint appropriately. At a much degraded image fidelity, color quality, insecure, primitively multitasking and non-networked manner with heavy RAM and CPU constraints.

I fully acknowledged software bloat is a thing. But we're not comparing some half-ass coded Electron app to some sleek handcoded C/C++/Rust desktop app. You're comparing base software built by decently-well educated engineers that does inordinately more than the comparison set, by so much moreso that it's ridiculous on its face. And then going on a rant about debug symbols and ELF headers (which brings a ton of benefits itself).

[pjmlp]

I remember when Linux kernel came in floppies, and a plain CD-ROM would give me basically the same what many kids now use on their text terminals with tmux.

Or since the subject is Amiga.

A 500 wouldn't make, but a A3000UX would.

https://en.m.wikipedia.org/wiki/Amiga_Unix

[cies]

> What are we doing?

Making use of what is cheap (hardware (CPU/ram) and network bandwidth) while avoiding to use what is expensive: programmers, tech guy helping you with an upgrade or a troubled windows install.