Wow, the fact that Mac OS Classic did not even have a command line interface really baffles me. I looked it up and https://news.ycombinator.com/item?id=18646286 - it seems to be true.
It's ironic that in 2018, the terminal is more prominent then ever in any developer scene (thinking only of package managers for diverse programming languages), while in the 90s somehow people thought the GUI could solve all problems, not only for the novices but also for computer experts.
Yes, classic Mac OS truly did not have a command line interface of any kind. As a consequence, everything your application did must have had a GUI command or preference corresponding to it.
Command line interfaces are powerful, yes, but they're also a crutch. It's very easy to hide certain features by exposing them only through command line flags or what have you. On classic Mac OS you could not do this; you needed to attach every feature to a GUI control of some kind.
As a consequence, people came up with all kinds of GUI tools for pro/expert users. Linux, comparison, treats GUI users as second class citizens and tends to relegate them to only the most basic functionality.
Eh, lots of stuff would be just stuffed into an appropriate resource and if you wanted to hack it you would use ResEdit.
I miss ResEdit. Pretty much every Mac app in the day used the standard system for managing their resources, so you could pick apart anything with ease using ResEdit. I don't know of any modern equivalent for Unix/Windows/Mac programs.
Well, I was too young to really explore classic Mac OS at that time. But from my feeling, the unixoidity of Mac OS X was really a blessing for the hacking community. So there definetly was a need.
Oh don't get me wrong, I live in the terminal these days. It's immensely satisfying to whip up a quick bash or Perl script to solve a problem. That being said, I believe the reliance Unix command line tools has made this computing power inaccessible to ordinary users.
In some sense, I think it has deepened the digital divide.
I like your viewpoint, but my experience with GUIs was largely that THEY hid power...from me. Any setting that could only be managed from within a GUI meant automation was pretty much off the table (and by "automation" I mean any basic connection of two tasks, things joe average user would want, not necessarily heavy industrial automation). Remember when Windows NT had only a binary event log, and their graphical client was the only way to view it?
I think the issue is not so much "command line hides power and treats GUI like a second-class citizen", though that is true, but rather that preferring one over the other creates problems.
This issue is again rearing its head in website design - many "web applications" have states that are not reachable via linking.
Back before the Unix-ization of macOS, there was a large focus on programs providing accessibility/automation APIs. The GUI parts of macOS were actually far more scriptable back in the OS7-9 days (and early OSX days) than they are today. It used to be that any effect you wanted to trigger in the OS, you could do by sending an https://en.wikipedia.org/wiki/Apple_event through the OSA scripting component to the relevant system service.
Nowadays on macOS, with the availability of the CLI, Apple engineers have decided to expose those same effects through CLI utilities that call directly into private system APIs (which are themselves usually client libraries for private Mach client-server ABIs.) If there's a switch exposed in the GUI but not the CLI, it's unlikely there's an event to reach it any more.
(Though, in macOS or Windows or Linux, it's always a possibility to write a script that has GUI effects directly in terms of "click the first button on the right"-style accessibility directions. But that's extremely brittle to system version updates, and precisely the thing that exposing an automation API is meant to avoid.)
Most applications focus on either the GUI or the CLI because building two complete interfaces takes a lot of work.
You're right that a lot of GUIs aren't designed for automation, but CLIs aren't the only answer. Classic MacOS had a powerful scripting architecture. (It still exists, but it's been neglected.)
Yes, and I'm an old fan of AppleScript as well. The difference, as far as I know, is that you couldn't hide core application functionality behind that API, could you?
If you could, I think most developers didn't, since AppleScript isn't a default means of using the computer the way Unix shells are.
IFIR, Win3.1 didn't have a command line either, you had to exit Windows completely back to DOS.
IMHO the Amiga offered the best of both worlds at that time (except for expensive UNIX workstations). On one hand you had a modern windowing UI, and a real multitasking OS. On the other hand you had terminal windows with a command line interface that was slightly different to UNIX, but close enough to be enjoyable.
Later in the life of the Amiga it became standard that UI applications provided standardized scripting interfaces (via AREXX), so you could write complex automation tasks that glued together all sorts of UI- and command-line-programs. In a way this was a lot more advanced than anything that's available on Windows or Linux today, since it wasn't limited to a few applications that all live in their own isolated world.
Oh, AREXX, the one thing Amiga had which still has no counterpart. I mean, the technology is of course there, but the ecosystem and culture is not. AREXX integration is so alien it's hard to even explain it someone who did not see it in action back in the day.
The closest I can think of is Siri and such automation, except AREXX was a full programming language in its own. (The language was from IBM REXX.)
Windows 1.x-3.x didn't really have a command line, the window you use to run command.com was for DOS programs only. Windows programs didn't have a text mode to utilize it.
Windows NT's console window was properly accessible to Windows programs, as well as DOS compatibility. Windows 95/98/Me inherited limited forms of text-mode compatibility from NT.
the window you use to run command.com was for DOS programs only.
This is not strictly true. You could launch Windows programs from the DOS box. If you tried to run something like PBRUSH.EXE from true DOS you would get "This program requires Windows" but in a DOS box it would detect that Windows was running and launch the program.
I think it is true that there were no Windows-only command line apps though.
There was no native support for command line apps (in part because the cooperative multitasking model is not especially conductive to such things), but at least some Win16 development environments came with libraries for emulating console applications (eg. BP7 and Delphi 1 had unit WinCRT which did exactly that).
By the Win95 era there was. In the 3.x and below era people tended to either be in DOS or be in Windows rather than running DOS in Windows. Or at least that was my experience, YMMV
I think you could largely get around having to boot into DOS mode by enabling a specific setting on the MS-DOS shortcut for those games. I think it unloaded win.com - so you're essentially shutting down Windows rather than rebooting into DOS) but we're talking > 20 years since I've last used that trick so my memory is a bit fuzzy.
In practice, people usually rebooted into DOS mode to play so as to do memory optimization in config.sys & autoexec.bat (HIMEM, EMM386 etc). Although that was for the benefit of older 16-bit games - 32-bit DOS extender stuff like Redneck Rampage wouldn't care.
I don’t think you’d need to reboot to take advantage of that because they’re loaded as part of Windows booting and then a lot of the DOS kernel was patched into the Windows kernel for 16bit driver support.
I certainly don’t recall ever having any issues with 16 bit games (aside my weird soundcard not working with half the games I tried, but I can’t recall why that was off hand).
It's not a 16-bit driver issue; it's the conventional memory size issue. Remember the old 640 Kb limit? When you had too many DOS drivers loaded, you often ended up with less than 600 Kb free - and some 16-bit games didn't like running that low, hence the need to use HIMEM etc. And while it still works when running DOS apps from Windows, it reduced the amount of conventional memory even further.
Yes, I understand the problem but what I’m saying is when you shutdown to DOS (even without rebooting) win.com was shutoff. Since it was win.com that disabled EMM386 you were free to run your HIMEM whatever again. Thus having a full DOS environment without a full reboot (which used to be slow in those days).
Thinking about it some more, I think I might have had a subset autoexec.bat I used to run for those occasions.
That technique seemed to work for me. Maybe I’m forgetting a tonne of 16 bit games that didn’t play but nothing immediately springs to mind
EMM386 was usually run from autoexec.bat. But HIMEM was a driver installed via config.sys. I think there were some complications with the latter with "reboot to DOS".
It examines the issue of GUIs vs. command line interfaces, among other things.
I'm pretty sure there is an anecdote there that says that Mac OS did have a hidden command line? It was only for Apple engineers, not for end users, but it was there. I'd appreciate a pointer if anyone remembers.
MPW had an interesting way to ease GUI-centric users into its CLI-centric world. There was a mode you could trigger for commands that brought up a help-oriented GUI for the command to build the command argument list, which would then echo onto the command line. Depending upon who built the GUI, it was usually a less terse and friendlier help for new users than AIX's SMIT, for those who are familiar with that.
I sometimes wish there was an open source equivalent like that for Linux , but with live, interactive building of the command as the GUI options were manipulated so new users could get a feel for commands more readily. This would act as an intermediate help system for casual users that is friendlier than manpages, and more immediate than searching around the Net.
> There was a mode you could trigger for commands that brought up a help-oriented GUI for the command to build the command argument list, which would then echo onto the command line.
This still lives on in a sense. For example, in VSCode, many UI commands translate to executing shell code in its internal terminal (and you can see both the commands and the output).
Wow, the fact that this is baffling to someone is, in turn, baffling to me! I don't mean this to be insulting, it's just one of those generational things. It hadn't occurred to me that someone (someone who cares about CLIs, at least) wouldn't know this.
It might be informative to step back and point out that this is why so many of "us" originally disliked Macs; before the "walled garden" of iOS, before even the walled garden of needing iTunes to load music onto your iPod, there was the GUI-only MacOS. Now, those in the know could dramatically alter Mac OS with Resedit, but I wasn't a "Mac guy", so I never really knew anything about it; I hated a locked down OS that only let you do things you could click on.
It was such a step forward to many of us hobbyists that OS X was based on Unix, and suddenly we had the best of both worlds -- a good GUI and a good CLI. Suddenly Windows was no longer the commercial OS that let you "do whatever you wanted" with it (relatively speaking).
In fact, (to personalize this for a paragraph), as a Linux desktop person buying his first laptop in 2002, I decided "well, I guess I might as well buy a Windows laptop instead of trying to hassle with running Linux on it." It felt like "giving in" to buy the commercial OS just to have easy access to Office and DVD players and the like. It slowly dawned on me "wait, if I'm going to buy a commercial OS, maybe I could buy a Mac?" I had never considered a Mac in my life, but I realized, wait, I can have Office on it (which not everyone realized, even then), AND easily play DVDs, AND this new OS X thing (which had come out a year before). It was a huge leap of faith, though.
The reputation of Apple building things that are just "pretty and shiny", I think, still stems from this sense that it's a consumer device that only does what Apple lets you do with it. And yes, some of these criticisms are still valid, but for those who weren't aware of the no-CLI Mac OS, I think it's very useful context that many of us take for granted.
It's worth considering what about command line interfaces makes them useful, who they are useful for and whether Mac OS offered an analogous interface somehow that fit the bill for their users. For me, the main gain of using a shell is that you can easily automate and document workflows. Apple added this to System 7 with AppleScript, to some extent. I haven't used AppleScript, so I have no idea of how successful it was to this end, but it does seem to cover some surface that would traditionally be in the domain of a command line shell.
Apple released their GUI operating system to consumers before most competitors had anything like it. Rough contemporaries in the GUI consumer OS space, in the mid-80s through the 90s almost all had some kind of command line interface. The addition of AppleScript was probably a response to this, while trying to stay true to Jobs' and Raskin's idea of the Macintosh as a "computer appliance".
I remember vaguely having to create a bootable floppy for an old os9 installation. It had to be done by dragging a system file from the OS onto the floppy in a special way which is termed "Blessing".
AppleScript existed on System 7 - I used to use it like a very limited command line (scripting common activities and complex workflows.)
The fun thing about it was that you were essentially interfacing with the GUI. Everything was incredibly discoverable - if you knew something was possible then it was almost always obvious how to do it in AppleScript.
Well, to be fair, GUIS can be powerful commandlines, to the point that they even satisfy most experts. But it needs more work, and you either end up using textinput anyway, or have a slightly worst performing interface. So at the end most invest into the simple solution.
With the raise of HTML5 & Electron and their simplicity for creating powerful GUIs and AI-Speech-Driven interfaces we might be again reach somewhere in the next decades the point where Keyboard-interfaces are in decline. And if the AI overlords take over whe don't have any need for complicated interfaces anyway.
It didn't have a Unix shell, but you likely had some way to type commands and get the computer to run them. Depending on context, you might have had HyperTalk, or AppleScript, or the MPW Shell.
In some ways these could be even more powerful than a Unix shell. What's the Unix way to say "Select a menu item", if the developer of your favorite app didn't think to also include a command-line interface to it?
(Yeah, I know: accessibility APIs. Do all your apps include a complete set of those, too?)
It's ironic that in 2018, the terminal is more prominent then ever in any developer scene (thinking only of package managers for diverse programming languages), while in the 90s somehow people thought the GUI could solve all problems, not only for the novices but also for computer experts.