|Home » Learning Curve
Where'd It Go II
David Pogue's excellent Missing Manual for OS X comes with an appendix for Windows switchers called 'Where'd It Go?' - it's basically spot on but a few caveats are nevertheless in order.
To follow this discussion it might be best to have the book open as you read along. (And if you don't own a copy yet, do yourself a favour and get one now: it's 'required reading' for anyone running OS X.)
Add or Remove Programs control panel
Pogue: Here's another one you just don't need on the Macintosh. Removing a program simply involves dragging its icon to the Trash.
Skinny: No, no, no, no, and again NO: if you're ever dumb enough to give a software installer your password, count on the bastard strewing files all over your disk in areas you won't normally go - in areas that have nothing to do with that 'icon', in areas you won't even know anything about, in areas you won't know how to get into - even if you against all odds find out they exist (which you won't).
Your best defence here is a simple one: do not, under any circumstances, give any third party software or installer your password no matter how much you're begged for it or unless the vendor has made it possible for you to do the 'install' manually so you know exactly what's going to happen and where everything is going to go - and then keep a close recorded list of all those locations so you can in fact 'remove' the application if and when that time comes.
A default OS X system has over 10,000 (ten thousand) directories - keep that fact in mind and don't let things happen on your system without your knowledge and express approval.
Pogue: The Mac clipboard works much like the one in Windows.
Skinny: OS X has multiple clipboards - a whole slew of them - where Windows only has two, one for ordinary copy cut and paste and one for drag-drop. OS X has both of these but also a 'find' clipboard. This latter clipboard requires cooperation from client applications but most are written to use it. When searching for things you'll therefore most often find your last search string already in place so you're ready to go with a new search. The keyboard shortcut for putting something on the 'find' clipboard is ⌘E; you can often select text, use ⌘E, and then use ⌘D or ⌘G to immediately search for the next instance without ever invoking a search panel.
Finder will only let you see the contents of the default ('edit') clipboard; if you need to see what's on all the clipboards, you need Lightman.
Pogue: In OS X the command line is alive and well - but it speaks Unix, not DOS.
Skinny: Latter versions of Windows don't use DOS - they use David Cutler's NT - but even then the OS X command line is way different. Cutler's command line is miles better than what DOS ever had but it still doesn't come close to what Unix has always offered. In addition, Unix 'shells' (command lines) were designed correctly from the get-go, meaning they won't do dumb things like tell you the time (separate programs will do that) and thus they can be interchanged at will: they only interpret commands and no more. The difference is dramatic.
Pogue: There's no such utility included with OS X, although Norton...
Skinny: Don't touch anything from Norton even with a barge pole. Defragging on OS X when using the HFS file system is not to be recommended anyway: HFS is a wobbly file system with too many 'moving parts' and prone to corruption. Starting with OS X 10.3 Panther there's a modicum of self-defragging built in. Settle for that and save yourself the woe of a corrupted hard drive.
Pogue: No Macintosh user ever experiences DLL conflicts or out of date DLL files.
Skinny: This is not entirely true, and now with 'widgets' on Tiger there's a definite security issue: rogue widgets can easily disguise as trusted widgets from Apple. In general Cocoa applications for OS X must be built with their 'DLLs' in a predefined location, so no, there won't be any conflicts, and the equivalent of the DLL, the 'framework', must be built the same way. But never say 'never': conflicts (security exploits) can in practice happen, although the incidence - aside from the abysmal Tiger widgets - is nearly non-existent at the present time.
End Task dialog box
Pogue: Press ⌥⌘<esc>...
Skinny: This feature gives you the equivalent of the command line 'kill' with a 'kind' signal sent to the culprit; if this doesn't work, you need to send a stronger signal which this feature does not provide. You can drop to a command line in such case, look up the culprit's PID, and then issue a 'kill -9' on it, but your default OS X interface will not do this for you. (But Lightman will.)
Skinny: Pogueman offers all the choices available, but remember that ⌘Q is perilously close to the ⌘A used for 'select all'.
Pogue: The Mac has its own 'tree' view of the files and folders on your hard drive...
Skinny: Not quite it doesn't - and the distinction is important. Further, this is Unix, even if Finder remains painfully oblivious of the fact: Windows has very few file attributes, most of which are less than useless, and where you'd like to see more in a general listing in Finder, you will not - Finder remains the only standard file browser for any Unix system that's 'substandard'. (This one is a Unix file browser, but it's extra.)
Skinny: OS X has a 'Favorites' folder on disk normally used to store 'aliases'. But you don't want aliases, as they're dependent on the HFS file system (which - cross your fingers - will shortly meet with its very deserved demise). What you want instead are 'symlinks'. Unfortunately Finder, which is anything but a Unix file browser, won't help you create them - either you do it from a command line with 'ln -s' or you use something like this.
Skinny: Yes, you can associate individual files with applications - something you cannot do on Windows - but this trick is dependent on use of HFS which unbelievably enough has storage in the volume blocks for Finder-specific data. When HFS finally rides off into the sunset, this stuff will no longer work - and on the whole that's still a good thing.
Help and Support
Skinny: Apple's 'help system' is still way under par. It's basically just displaying HTML but its startup times should be measured in weeks or months, not milliseconds. Smart vendors will just hook in HTML files so users don't have to watch a spinning beach ball all through their work week.
Skinny: If you even have this on disk, don't use it. Yes, it is secure as its Windows counterpart will never be, but it's written in the Mac version of Visual Basic and is abysmally slow. Your best browser, despite its noticeable warts, is Safari.
Pogue: Clicking the zoom button never makes the window expand to fill the entire screen. Instead the window grows or shrinks precisely enough to enclose its contents.
Skinny: This is simply not true. By default the zoom button will expand a window to fill the entire screen; applications such as Safari can hook into the system message and change what's going to happen to do as Pogueman suggests, but management of this is at application level and not system level - which makes sense if you think about it, as the system can never know what an application wants to display in its so-called 'content view'.
Pogue: There's only one menu bar, always at the very top of the screen.
Skinny: Very true, but this is only scratching at the surface. Whether it's the cascading menu system as seen in NeXTSTEP or the dweeby menu bar traditionally seen on the Mac, this is an object oriented interface. The ramifications will not be immediately apparent, but given enough time they will be. The way these two systems are used is entirely different and the superiority of the OS X system is undeniable.
Pogue: There's no OS X Notepad program. But give Stickies a try.
Skinny: Or TextEdit, a far more viable program. TextEdit can also do word processing much like WordPad, but the subtle difference here is that TextEdit is a good program, written by Ali Ozer who came over from NeXT and maintains the code to this day. And if you're a programmer, you might benefit by looking at the source code which is available for free on every ADC delivery - Ali has a lot of good ideas and discussions commented in there.
Skinny: The Windows Recycle Bin serialises entries and saves their new names in a database with their corresponding former paths; the OS X equivalent does nothing of the sort. When you have something in the Trash you want to move back, you have to remember where you had it or you're going to be toast.
Think of the OS X Trash as more of a trash folder in your email client and you'll be fine.
Pogue: There is no Registry. Let the celebration begin!
Skinny: For now there isn't, but knock on wood. See a discussion elsewhere about how to prevent applications from wreaking havoc on your system. Apple are now trying to move to something called 'binary property lists' which have users up in arms against them. See a further discussion at this site about how you for now get around this inconvenience.
Pogue: The equivalent command line is Terminal. [sic]
Skinny: Hello? The Run command on Windows is GUI-based. And even though the facility is there in OS X (click here to see how it can be used) there is no facility to use it. (Also, click here to see the full equivalent of the Windows Run command.)
Pogue: Just like Windows, the Mac automatically scans and if necessary repairs its hard drive every time your machine starts up.
Skinny: Yes and no: OS X is supposed to run the Unix fsck on startup but in practice this won't find HFS inconsistencies and you cannot just start Disk Utility and expect great things to happen. Which is why you should always keep a close tab on your disk free space and at the least suspicion something is wrong get out your install DVD, boot into it, and run Disk Utility from there. (OS X won't let you repair a drive being used as the system drive.) So keep that install DVD handy at all times.
Pogue: On the Mac they're known as aliases...
Skinny: No, with 'MacOS' there are aliases, but these depend on the HFS file system. On Unix they're known as symbolic links or 'symlinks' for short, and they will work no matter what file system you're using. Unfortunately, Apple's counterpart to Windows Explorer (and to GNOME Nautilus and KDE Konqueror) is not capable of creating or managing symlinks and other rudimentary Unix devices. You can create and manage them either from the command line (Terminal) or with Xfile.