Hacker News Reader

I was using Macs back in the late '90s, and none of the things you say ring true.

Extensions could easily bring down the entire system because there was no memory protection. Full OS crashes (what modern macOS calls kernel panics) were a daily occurrence for the typical Mac-using professional who ran complex software.

The window system was often difficult to understand because apps tended to use a plethora of little panel windows that could overlap even from different apps. Windows preferred large windows that contained the entire app UI, and users typically maximized them. The Windows 95 Task Bar was much better for actually keeping track of your tasks than whatever the MacOS 8 thing was.

File extensions were always a hack, but one that Apple adopted too for Mac OS X. The days of Mac's file-specific associations were numbered when the Internet happened, because Unix servers wouldn't keep track of that metadata, so you needed file extensions anyway.

Besides, the file-specific associations were often super annoying because they were created by the editor app even for exported files. You saved a JPEG file from Photoshop, and it forever insisted on launching the full Photoshop when you double-clicked on it, instead of your preferred lightweight image viewer. This would happen even when you copied the file to someone else because the association was in the file metadata.

Windows NT 4 and its next version Windows 2000 were just heads and shoulders above MacOS 8 and 9 in terms of performance, stability and usability.

(And programming in Mac OS 8... Ugh. No memory protection, no multitasking, APIs originally designed in Pascal.)

> Extensions could easily bring down the entire system because there was no memory protection.

Yes, they were quite unstable. I didn't say that they were stable; I said that they were easy-to-understand and easy-to-disable, which they were: each extension had a distinct icon displayed at system boot; disabling one was as easy as dragging it to another folder; disabling all was a matter of, IIRC, holding down Command as you booted.

> Windows preferred large windows that contained the entire app UI, and users typically maximized them.

As a Mac user at the time, I much preferred the multi-window mode: it meant that I could customise my desktop as I liked. The Windows single-window mode was terrible, as it meant that I couldn't layer windows properly.

> You saved a JPEG file from Photoshop, and it forever insisted on launching the full Photoshop when you double-clicked on it, instead of your preferred lightweight image viewer.

We considered that a plus at the time: it meant that different files of the same type could be opened up by different apps by default. One could always, IIRC, Save As if one wanted to change the file type — or use ResEdit.

> Windows NT 4 and its next version Windows 2000 were just heads and shoulders above MacOS 8 and 9 in terms of performance, stability and usability.

Stability, probably. Performance, maybe. But usability? Never! That was back when Apple cared about UX.

We were talking about 95, which is a completely different universe from NT (though current versions of NT have a GUI that's based on 95).

Windows NT 4.0 had the same GUI as Windows 95 and was released in 1996. That's the version of Windows that sealed the deal for professional applications.

The late '90s I remember had a mishmash of NT, NetWare, and some (or maybe several) variant(s) of Unix on the bits that lived in the room with all the air conditioners.

Windows 9x and maybe OS/2 were far and away the dominant OSes on actual workstations. Macs and even aging Amigas at some creative shops, some more Unix workstations at places where most people could recognize and identify the purpose of (if not actually use) a slide rule. But what I essentially never saw on any desktops was Windows NT. Lack of driver support and inability to run many business applications kept it out of that space.

I suppose it depends a lot on geography and business. I remember Windows NT/2000 rapidly displacing Macs in the creative fields, and being widely used as developer workstations.

Especially developers moved from Win95 to NT in hordes during late 90s.

I’m trying to suss up some old memories...

But NT was the first winOS which supported multi-proc, correct?

NT4 was the first OS I could have my dual 266 intel procs run softimage IIRC

"I’m trying to suss up some old memories..."

NT4, Adaptec 2940u2w, and mirrored segate cheetah drives.

You had to space them out because a stack of two cheetahs would cook the upper one to death ...

hahaha

I actually recall that Cheetah problem. :-)

The funny thing I have always thought about mac vs win is that mac was so set on doing it “their way(think different)” that they ignored UX that really was intuitive and “just worked”

Mac was so set on being different, that they aschewed UX tropes that were natural.. and had to spend ridiculous amounts of resources trying to convince people that their way was the right way, but clearly it was not.

This, IMO, is where the “fanboi” concept evolved.

Brainwashing.

Who cares - in the long term - where the UX and UI elements came from, the point is to make machines immediately accessible to humans creative desires, not to mold workflows to a corporate ego...

So, Apple figured out how to develop products that were managed through the extension of the desire of the user, but they are still struggling with the requirement from Jobs to be “different” - and Ives’ perception of a common user is skewed toward “Ives’ has stated that this is how it should be done” type design, which I find completely ironic given the whole “think different, so long as it’s exactly how I am designing you to think” campaign is a hypocracy that goes up to an 11

What Apple have done with both first and second generations of the Macintosh -- System 1 and OSX -- is pick a basic GUI metaphor and stick with it for at least fifteen years.

The original Mac released in 1984 and was produced through 2000, sixteen years. OSX released in 2000 and is now in its eighteenth year. Whilst each system has seen some evolution over time, the general metaphores and interfaces have remained consistent.

Apple have realised and internalised a core concept of GUIs: change is bad. There is a far higher cost to changing interfaces than can be gained through efficiency, and the retraining and unlearning costs are exceedingly high relative to benefits.

This is a message apparently lost on Microsoft and most of the leading Linux desktops.

Mind: I write this as someone who whilst using a Mac presently doesn't much care for the interface. My preferred desktop remains WindowMaker (itself based on Aqua's predecessor, NextStep), which has a key advantage of having changed almost not at all in the 20+ years that I've been using it. It's also configurable in ways I find useful, and I schlep around a configuration directory to new systems as needed.

That and a terminal window.

Microsoft hasn't been too different in that regard. In terms of interfaces with any real userbase to speak of, the only real Microsoft UI systems I can come up with could be characterized as

* MS-DOS/Windows 3.1-like * Windows 95-like * Windows 8-like

Windows 8 basically was born and died in a couple of years, to be replaced with Windows 10, which is very much the same basic set of metaphors as Windows 95. There's a start menu, a little dock of pinned icons next to it, a taskbar, a clock and some little icons for what are basically background processes. There's a maximize and minimize and close button on windows. There's a File/Edit/Whatever set of menus. You can right click for context items, many of which are consistent with Windows 95 20+ years ago. That basic system is now something like 21 years old now.

You can maybe argue that Microsoft forgot your message five or so years ago, but they obviously rediscovered it.

I'm largely familiar with the DOS -> Win2K period, and have made little use of Microsoft operating systems since.

Windows 3, 95, NT, and 2K each saw significant changes in where and how major system functionality was presented.

During the same period I was using numerous Unix and Linux platforms (and still do). Those have largely seen far less substantive change at the shell and system level, with a few notable exceptions.

I'm not discussing Linux GUIs, which have been all over the goddamned map. I've used twm, fvwm, fvwm2, VUE, CDE, WindowMaker (my preferred option), GNOME and KDE through multiple generations, Enlightenment, various of the 'boxes (black, open, flux, ...), ion, xfce4, ... And those are the ones I've trialed to some significant extent. I've at least fired up and looked at virtually all the options mentioned on the XWinMan page: http://www.xwinman.org/

There are several fairly central components which have changed fairly markedly. The shift from telnet to ssh, multiple iterations of firewalling, various scripting languages of preference (bash, perl, python, an oddment of others), mailers (sendmail, qmail, anything reasonably sane, mostly exim and/or postfix now), and of course, the whole init replacement clusterfuck.

But the notional concepts of files, filesystem, shell, utilities, pipes, etc., has remained consistent, and even across several utility / server replacements (particularly ssh and mailers), command-level compatibility has been preserved to a remarkable extent with previous options (e.g., rsh and sendmail syntax).

If Microsoft can only be relied on for five-year stints of "having learnt this lesson" then they have not learnt this lesson.

I fear though that command level compatibility is under attack these days, as fewer and fewer see shell scripting as something positive (never mind trying to do more and more via dbus rather than pipes and such).

Tools that fail to provide a stable scripting interface tend to be ditched early and hard by sysadmins.

This includes a hell of a lot of systems configuration tools. The corrective force on failure to adhere to this norm is strong.

And already with 8.1 the "start screen" could behave like a very large start menu.

Hell, you can today configure Windows 10 to behave much like 8.1. The one thing i see some people miss with the 8.1 to 10 transition is the charm bar. In particular that it gave easy access to printing and such.

Seem to me that Apple and MS focus on different kinds of change.

While Apple may retain the UI across time, they are more than willing to change APIs etc on a whim.

MS on the other hand may change the UI (though outside of 8.x, the core layout and behavior has remained much the same, and even 8.x could to a large degree behave like the older UI) but they bend over backwards to maintain APIs across time.

Very interesting point, and one that may play in subtle ways to each platform's audience and scale.

Microsoft was always more vendor / ISV / VAR oriented, and stable APIs matter there.

I get the feel that stable APIs are undervalued as a user retention element.

Being able to get a new computer but install from the same software library (i can hear the _sec people getting hissy already) as was used on the old one makes people more likely to pick the same "platform" over time.

Right, I see that point and would have acknowledged it more explicitly had I time earlier. That's the interesting part of this.

The counter is that Apple caters to a smaller software development community, though several of the tools also see extensive use and support (particularly photoshop). But there's a heck of a lot fundamental functionality on Apple's platforms that you can get without relying on third-party software, or at least, third-party proprietary software. Given the dynamics of proprietary software markets, particularly toward adware, nagware, and malware, this seems a possibly positive development.

(I've made much the same observation in recent years about the Android marketplace, which I see as a growing cesspit, and of the Windows application space, particularly at the peak of its crapware / spyware / adware period in the decade of the 2000s.)

Linux solves the software compatibility problem by allowing for recompiling of software for which the source is freely available, for the most part. This isn't a perfect solution, and there are complex systems which tend to not be particularly forward-compatible. One possible argument is that such complex systems are themselves inherently problematic and ought perhaps be avoided. You may not agree with the argument, but I'd expect you'd admit to its existence.

Microsoft was addressing a different space, and one in which there was a massive focus on desktop-distributed client software, much of it aimed at very specific business applications. This is a major application area for computers, though it's also one that's shifted significantly toward client-server Web-based solutions (or app-based, now). Which presents its own set of features and limitations.

And again, all this is what I was hinting at earlier with noting that you'd presented a very interesting point. I'll be thinking about this for a while.

> “think different, so long as it’s exactly how I am designing you to think”

That's Macintosh all over. "You're holding it wrong" is not a new failing of Apple, nor is it exclusively post-Jobs.

Jobs was just better at convincing people that, yes, they were holding it wrong.

Windows 95 was no paragon of stability when you started loading it up with tray apps and running big nasty applications or trying to use the damn printer with its piece of shit driver. We are spoiled these days by how stable our computers are.

I agree with you that keeping the file metadata in a separate fork is far superior to keeping the file metadata in a three character extension, but sadly the world zagged on this one when Apple zigged. I especially like that you could have two files of the same type associated with different applications, so if you created a text file in your IDE it would open back up in that IDE instead of launching the word processor. And you could change it (somewhat clunkily) at will.

Win95 did have some advantages though. The Start Menu was a better organization system than Apple's Application folder for example. Macs of that era were also slow and badly overpriced.

> The Start Menu was a better organization system than Apple's Application folder for example.

These were not actually that different. The original Start Menu was just a menuized view of a folder hierarchy (which mostly contained shortcuts but could contain any document).

The resource fork idea is great if everyone agrees on it and everyone preserves them, even across OSes.

Or if you're going to Very Deliberately Ignore the Other OSes and go do things your own way. VDIing like that seems to be a very Apple trait.

My point is, I'm not sure how well the resource fork model could have ever survived prolonged and sustained contact with the Internet and modern pervasive networking.

> I agree with you that keeping the file metadata in a separate fork is far superior to keeping the file metadata in a three character extension

Since we're talking about Win95, then the 3 characters limit doesn't apply (long filenames was a major new feature of this OS after all). .jpeg and .html were relatively common for example at the time, and worked fine.

I find the extension system still kludgy, but arguing than it was worse in part because of the limited pool, is incorrect starting from Win95.

Yet for the same compatibility reasons most people stuck with .jpg and .htm, at least in the Windows world. Even now it's very unusual to see a .jpeg extension on a filename.

The metadata that Macs kept in the resource fork go way beyond file type and creator too. It included things like the file's Icon, creation/modification information (so it would survive a trip over the Internet!), loads of stuff for applications (menus, graphics, sounds, etc...), formatting for plain text documents (so they fall back to plain text on unsupported systems), and so much more.

Fun fact: NTFS supports the concept of a resource fork on files, but almost nothing in Windows uses it. I think I've seen more malware hiding stuff in there than legitimate uses in the wild. Worse, even the obvious case of loading a Mac file on a Windows machine it usually fails and falls back to creating the clunky separate directory instead.

NTFS does not have resource fork in the MacOS sense nor extended attributes in the unix sense. Instead it allows for file to have multiple named contents that are accessible by same file IO API (in essence the file can behave like a simplified directory). There is no distinction between data and metadata stored this way. In the late 90s MS even intended to not use OLE compound storage fileformat (ie. what office 97/2000 formats are built on) on NTFS drives and instead write the objects into separate streams (reportedly it was not implemented because then windows would have to somehow transparently reconstruct the compound storage when you copy such file to non-NTFS drive or upload it to the internet). Today apart from malvare hidding only major usage multiple streams have are the "this file was downloaded from internet, are you sure you want to open it?" prompts which store the internet-ness of file in secondary stream.

Conceptually the MacOS Resource Fork is basically a directory where all of your filenames have to be exactly 4 characters long. The only difference is that each "file" might be a stack of "files". So you might have a CODE resource that has multiple CODE segments in it.

One thing I loved about old MacOS apps is opening them up in ResEdit and so much of how the thing was built.

> Conceptually the MacOS Resource Fork is basically a directory where all of your filenames have to be exactly 4 characters long. The only difference is that each "file" might be a stack of "files". So you might have a CODE resource that has multiple CODE segments in it.

Sort of. It would be more accurate to say that each filename was a 4-letter type code and a 16-bit ID. Each resource could also have a name, but that was less frequently used (and didn't have to be present, let alone unique).

More importantly, resource forks didn't exist in isolation. They were loaded into a chain of active resource files -- for instance, while working with a Hypercard stack, the resource chain would include the active stack, the Home stack, the Hypercard application, and the System suitcase. A stack could use resources (like icons or sounds) from any of those sources.

You don't see .jpeg because people are used to .jpg. There's nothing incompatible with long names that we care about.

Also, that Windows feature you mention is called ADS - alternate data stream.

Yes, but you also never see extensions like:

.jpeg.photoshop.ro.creat127339292....

The filename extension is the bare minimum of metadata for a file and not easy to extend.

Even then Unix systems will skip even that minimal metadata and force you to messily search for magic numbers at the start of the file and make a guess.

> I think that the Mac back then was head-and-shoulders a better system than Windows.

I completely disagree.

First of all, Windows 95 had preemptive multitasking (the Amiga was the only computer that had this at the time), Mac OS was single task and used a terrible scheduling and it would be years before Mac OS gained preemptive multitasking because of terrible architecture choices that made this extremely challenging.

From a GUI standpoint, Windows 95 was a total revolution and made Mac OS look completely antiquated: rendering, scrolling speed, font types, menu items and dialogs, etc...

From 1991, Linux had preemptive multitasking.

The Amiga was exotic hardware, like the BeBox. If you want to include those, you might as well include SGI and Sun hardware. Preemptive multitasking was common on non-PC hardware.

Well yes and Minix had preemptive multitasking a decade before.

We're talking about consumer facing computers, and at the time, the market was pretty much only Windows, Mac, OS/2, Amiga and Atari.

> The window system itself was better-thought-out and less-confusing than Windows's was

I miss window shades so much.

There used to be some good haxies that would let you do this on OSX, not sure what their current state of support/brokenness is.

Yup, I remember using them. WindowBlindsX if I recall. It worked alright, but it was never as snappy as shades were.

Cocoa is pretty painful compared to web UI alternatives like Electron. I feel stupid for mastering it considering there’s no jobs there and the Mac App Store is probably impossible to make any money off of anymore.

Windows has always been head-and-shoulders above the Mac and that's why it won the 90s desktop wars and that's why just about every business on earth uses Windows and not Macs.

You are in a tiny minority if you think Mac window and file management are any good. File extensions are the most pragmatic way of dealing with associations and that just about sums up the difference between Mac and Windows: Microsoft made Windows to be practical whereas Apple has always focused on style above all else.