In theory, virtual memory is a good thing, because it enables programs to use more memory than is physically present on a machine by swapping out portions of memory to disk in order to reuse that memory for other processes. But so far, this has meant reduced system performance (you probably have applications that specifically tell you to disable virtual memory) since VM traditionally adds the overhead of reading and writing portions of memory to disk to the overall performance of your applications. The Mac virtual memory implementation has always been slow, but Apple says this will change with Mac OS X.
Apparently, in X, almost all of the system, except for vital areas such as the microkernel and the file system, can be "paged" to disk, leaving more physical memory available to application level software. Currently, the Mac OS doesn't allow its system heap (an area of memory reserved for data structures used by the OS in support of applications) to be "pageable." Instead, the system heap remains in physical memory.
Techspeak aside, if Apple delivers on its promises, as of Mac OS X, you'll no longer have to worry about how much memory an application like Photoshop needs to open large files. When an applications needs memory, the virtual memory manager automatically allocates precisely the amount of memory needed by the application. Cool, huh?
Extensions go bye-bye
Mac OS X has an advanced kernel known as Mach. The kernel is the pivotal component in the operating system that handles most of the interaction between the operating system and the hardware. The Mach kernel has been part of the open source community, undergoing continued development by computer scientists for several years.
One result of using the Mach kernel is the need to eliminate extensions at least when you're outside the Classic environment, which is designed to run current Mac applications. Extensions have historically been the way that Apple developers patched or extended the capabilities of the core Mac OS. In Apple's own words, "this is essentially the wrong thing to do with a kernel-based operating system such as Mac OS X, since the kernel supports all sets of higher-level APIs (the boxes again), each of which has different interfaces and capabilities."
Apple says it will have to leave some hooks in place to allow loadable sets of services, not just for backward compatibility. Functionally, end users like us probably won't see much of a difference, except that our Macs won't have to load rows of extensions when booting, according to Apple. In other words, it seems that OS X will replace traditional extensions with "faceless applications" that run invisibly. As they run, they'll modify the system in whatever way they are meant to do.
The way it will all work out apparently is that different apps and hardware devices will still be accompanied by small files that allow the OS to enable the hardware or software's functions, much like in the current Mac OS's extensions. But they'll be more specialized -- and probably more hidden.
Mac OS X supports POSIX file system semantics and NFS file sharing, as well as standard services like telnet and FTP, allowing easy operability with UNIX systems and applications.
In fact, the system's kernel based on Mach 3.0 from Carnegie-Mellon University and FreeBSD 3.2 (derived from the University of California at Berkeley's BSD 4.4-Lite. Apple also took the Apache Web server -- which runs over half the Web sites on the Internet -- and made it friendly enough to use on your desktop for personal file sharing, the company says.
Darwin incorporates the BSD networking stack, the basis of many TCP/IP implementations on the Internet today. Apple provides built-in support for PPP, allowing users to easily access remote networks. And they've also included full support for AppleTalk, to ensure smooth interoperability with existing Macintosh networks.
However, the good thing is that the complexities of Unix will be hidden from the average Mac OS X user. Apple is going to great lengths to hide the Unix underpinnings from the end user.
By default, most of the UNIX "services" that require configuration files will ship disabled. Many of them will not even be installed by default. Those that are enabled and user-configurable will have a configuration panel in the "Control Panel". Those that simply can be turned off or on with no configuration will have a radio button somewhere to do that.
The final release of OS X won't ship with a shell program, so getting to the command line will require some effort by users. Apple's intent, apparently, is to hide the "terminal" window, which is basically the window GUI (graphical user interface) for the UNIX command line.
In other words, unlike standard Unix config files that are plain text or shell scripts, OS X uses XML property lists; these files are structured data. This means that it was simple for Apple to write a GUI to manipulate the config files and include all sorts of goodies such as dependencies.
Carbon, Cocoa, and Java
With Apple pledging strong support for Java 2 in Mac OS X, when the next generation operating system arrives, it will have three principal application environments for developers: Carbon, Cocoa, and Java. Carbon
Carbon is an adaptation of the Mac OS 9 application programming interfaces (APIs) and libraries for Mac OS X. According to Apple, Carbon keeps 70% of the functions in current Mac OS APIs and dumps the 30% that are too outdated to be part of a modern operating system. To be more precise, Carbon keeps about 70% of the total functions and 95% of the functions used by typical applications. Carbon also includes additional APIs and services specifically developed for Mac OS X.
Programs written using the Carbon APIs can also be deployed on Mac OS 8 and 9, though they won't have the nifty new features of Mac OS X: protected memory, multithreading, preemptive multitasking, etc.
Mac OS X handles memory differently from previous Mac operating systems. Specifically, it offers protected memory (to prevent system wide crashes when one software program goes ka-blooey) and improved virtual memory. So Carbon APIs restrict or get rid of the use of things like zones, system memory, and temporary memory. There are lots more that could be said about the subject, but it would mostly be of interest to developers, who doubtless know more than I could tell them in this column.
Mac OS 9 (and lower) managers used for low-level access to hardware -- goodies like the ADB Manager, the Device Manager, and the Ethernet Driver -- aren't implemented in Mac OS X. Since there's no Mac OS ROM in Mac OS X, functions related to accessing resources in ROM aren't supported in Carbon.
Apple has developed new Carbon versions of the Print Manager and the Event Manager for X. The non-Carbon Print Manager is no longer supported in X. However, the old Event Manager is, though Apple strongly recommends using the Carbon Event Manager instead.
Finally, different Carbon technologies now take the place of earlier libraries. Out: AppleTalk Manager, PPC Toolbox, Standard File Package, QuickDraw 3D, and Help Manager. In: Open Transport, Apple Events, Navigation Services, OpenGL, and Help Viewer.
Cocoa is a collection of advanced, object-oriented APIs for developing applications written in Java and Objective-C. It's based on two object-oriented frameworks: Foundation and the Apple Kit. These frameworks offer both Java and Objective-C APIs (with most Java classes simply "bridging" to their Objective-C implementation).
That's pretty complicated sounding. Apple says that Cocoa is the most advanced object-oriented technology on the market today. It's just like WebObjects. You can write apps 10 times faster in Cocoa so if you're writing a new app, Apple recommends you go this route.
Cocoa is based on the OpenStep operating system technology of NeXT (the company that Steve Jobs formed after leaving Apple, but which Apple later purchased and ... well, it's a long story). Cocoa is an extension to the original OpenStep APIs that were present in OpenStep 4.x.
"Those APIs were based on the original NeXTSTEP APIs, but had many modifications that made most programs not just compile," says Scott Anguish, mastermind behind the must-visit Stepwise Web site. "Cocoa is a third generation set of APIs, although there was little changes required to go from OpenStep to Cocoa.
Cocoa was the second generation. Several changes were required from the first generation NeXTStep APIs. Developers can use Cocoa to write code in terms of objects that pass inheritance through a hierarchy of parent and child classes.
Say what? Yes, it's a bit complicated, but it boils down to this: developers using Cocoa can purportedly reuse up to 90% of their code for future work. And functions published in the operating system as a "service" can be accessed by other Cocoa applications.
By the way, Cocoa includes Java packages that let you develop a Cocoa application using Java as the development language. Apple says you can mix "within reason" the APIs from these packages and native Java APIs.
The Java environment is for the development and deployment of 100% Pure Java and mixed-API Java applications and applets. Apple says this environment will be implemented in conformance with the latest version of the Java Development Kit (JDK), including the Java virtual machine (VM).
This means that a Java app created with this environment is "portable." You can copy it to a complete different hardware platform and operating system. As long as that system includes a compatible version of the Java VM, the app should run on it just fine. And a Java applet should run in any Internet browser with the proper capabilities.
Apple says that Mac OS X will let you copy or cut almost any piece of data and paste it into an application executing in another environment. And it allows dragging of most Finder objects -- and their corresponding data -- between most environments.
And there's much, much more. Enough to fill a book, in fact (and don't worry, they're coming, including "Mac OS X for Dummies"). But this primer should give you a taste of the future.
And, hey, as of today, the future is here.
This story, "Mac OS X Primer" was originally published by PCWorld.