This document describes the Mac OS Compatibility environment shipped with Mac OS X Server 1.1. This environment is implemented by the MacOS.app application, sometimes referred to as the "Blue Box".

Note: This document was installed by Mac OS X Server in /System/Documentation/Read Me For a list of other release notes see article 30925: " Mac OS X Server: Release Notes "

Contents

• Overview
• Quick Start
• System Requirements
• Installation
• Features
• Disk Access Modes
• Disk Drive Support
• Working with Disk Image Files
• Startup Options
• Bugs and Compatibility Issues

Overview

MacOS.app, sometimes referred to as the "Blue Box", is a high-performance, high compatibility environment for running Mac OS software within the Mac OS X Server operating system.

High compatibility is achieved by running Mac OS essentially unchanged in a virtual environment, which appears to be a new Macintosh hardware model. Because of this, the vast majority of Mac OS applications, utilities, extensions and software drivers just work. Software that directly accesses hardware, uses undocumented internal APIs of the Mac OS, or relies on Mac OS managers not yet supported by this release of MacOS.app is not expected to work.

The Mac OS managers not currently supported by this release are those generally associated with hardware not yet fully supported by Mac OS X Server. Such missing functionality is explicitly listed in this document and will likely be provided in subsequent releases of MacOS.app.

This release of MacOS.app comes with Mac OS 8.5.1 and will support future versions of Mac OS that have not shipped as of this writing. Previous versions of Mac OS are not supported, and MacOS.app will not allow them to run.

MacOS.app allows you to use your current Mac OS applications to "live" on Mac OS X Server, to explore its new capabilities while preserving your current Mac OS environment.

You are encouraged to read these release notes before running MacOS.app. If you just can't resist, at least read the following "Quick Start" section.

Quick Start

To start MacOS.app, choose Mac OS in the Mac OS X Server Apple menu or double-click on "/System/Applications/MacOS.app" in the Workspace File Manager. You may also want to drag an alias onto the Workspace for quicker access to MacOS.app. It is best not to launch MacOS.app from a Terminal window, since it will not result in a clean MacOS.app shutdown when logging out from the Mac OS X Server's Workspace.

The first time you launch MacOS.app, a private Mac OS 8.5.1 startup disk image (called StartupDisk.img) will be created. The language of the image will be selected based on the Localization settings from the Preferences application and the MacOS.app languages that have been installed. The selected image will be copied and uncompressed into /Local/Library/MacOS/Users/. This process will take a little time and is accompanied by a dialog box with a progress bar. At the end of creating the startup disk image, a virtual PRAM file called "PRAM" will also be created in the same directory.

Choosing Shut Down from the Mac OS Finder's Special menu will quit MacOS.app. Similarly, choosing Restart will quit and re-launch MacOS.app. You may also use the Power key, which will bring up the standard Mac OS "Shut Down / Restart" dialog box.

To switch between the Mac OS and Mac OS X Server environments, use the Application menu at the far right of the menu bar. In both MacOS.app and Mac OS X Server, this menu has been extended to list all applications running in both environments, grouped by environment. If you choose an application that is running in the other environment, you will be switched to that environment and the selected application will be activated.

There is a special item in the application menu of each environment that will switch you to the other environment and bring you back to the last application you were using in that environment. That item is called "Mac OS X Server" in the Mac OS environment and "MacOS" in the Mac OS X Server environment.

The following special keys combinations are available when you are in the Mac OS environment, and supersede any Mac OS use of these key combinations:

Command-Return is a shortcut for choosing "Mac OS X Server" from the application menu. Since this may interfere with some applications that use this combination of keys, you may disable it, as discussed under "User Input" in the "Bugs and Compatibility Issues" section.

Command-Shift-Q will force-quit MacOS.app. This would be equivalent to pulling the power plug out of the wall on native Mac OS and should only be used when Mac OS is hung.

All other Mac OS special keys (e.g., Command-Power for NMI - to enter MacsBug) function as expected.

Before installing software, read the section "Use of Disk Image Files", under "Working with Disk Image Files".

System Requirements

The minimum recommended RAM for running Mac OS X Server with MacOS.app is 64 MB.

Each user running MacOS.app on this machine will require a minimum of 175 MB of disk space for the Mac OS 8.5.1 startup disk image. The Japanese localized startup disk image requires approximately 200 MB of disk space.

Installation

MacOS.app is installed as part of the standard Mac OS X Server installation. Earlier versions of MacOS.app are not compatible with Mac OS X Server.

The installation consists of the following installed items:

/System/Documentation/ReadMe/MacOS.html

/System/Applications/MacOS.app

/usr/bin/createimage

Features

System Software

Do not attempt to install previous versions of Mac OS. Future versions of Mac OS are likely to be directly installable by running their installer in MacOS.app.

Virtual Memory

MacOS.app always runs on top of Mac OS X Server's Virtual Memory, but Mac OS VM will appear to be off to applications.

Temporary Memory

File Systems

MacOS.app supports file systems on nearly all kinds of disk devices that are supported under the native Mac OS. These include, but are not limited to floppies, CD-ROMs, hard drives, and disk image files stored in the Mac OS X Server file system (UFS). Both SCSI and ATA/IDE (including ATAPI) drives are supported.

Disks can be accessed in one of three modes: Shared, Exclusive, or SCSI. Not all disk modes are available for all disks. The default access mode is Shared mode, except for disk images (which are always accessed in Exclusive mode). In order of highest-to-lowest interoperability with Mac OS X Server applications, the modes are Shared, Exclusive, and SCSI. Conversely, the modes in order of highest-to-lowest compatibility with Mac OS applications are: SCSI, Exclusive, and Shared.

Thus, there is a fundamental tradeoff involved with choosing which mode to use to access a disk. Shared mode was chosen as the default access mode because it provides a high enough level of compatibility to support typical productivity applications, while at the same time permitting access to the same disk via Mac OS X Server applications.

For more information, see the sections entitled "Disk Access Modes" and "Disk Drive Support".

Copy and Paste Between Mac OS and Mac OS X Server

Text can be copied (without style information) back and forth between the two kinds of applications. This includes some support for two-byte characters. See the "Bugs and Compatibility Issues" section for more details.

Pictures ('PICT') can be copied from Mac OS to Mac OS X Server applications, but are converted to RTF, which cannot be copied back to Mac OS. Many more data types are expected to be supported in future releases of MacOS.app.

Networking

AppleShare Client as well as Personal File Sharing, AppleShare Server and AppleShare IP Server are fully supported by MacOS.app. Personal Web Sharing is also supported.

Since Mac OS uses a different networking model than Mac OS X Server (Open Transport vs. Sockets), you must use a separate IP address for MacOS.app TCP/IP from that used by Mac OS X Server. This is best accomplished by using a static IP address in the TCP/IP control panel (or by using MacIP - IP over AppleTalk). In previous versions of MacOS.app, when the same IP address was used for Mac OS X Server and MacOS.app, Open Transport reported an error message indicating the reason TCP/IP networking is not available. If the same IP address is used in the present versions of Mac OS X Server and MacOS.app, Open Transport TCP/IP will silently be disabled.

PCI Native Driver Model

Video

Because of limitations in Mac OS X Server, MacOS.app cannot change resolution (size and scan rate). The resolution must be changed in Mac OS X Server's Preferences application and the changes take effect after logging out of Mac OS X Server.

MacOS.app supports multiple monitors. However, you may set it up to use only one monitor on a multiple-monitor system. MacOS.app assigns the number 0 to the main monitor (the one with the menu bar). Additional monitors are assigned the numbers 1, 2, etc. Setting the Mac OS X Server user preference "MonitorSelect" for MacOS.app to a value that indicates that monitor's assigned number will cause MacOS.app to only use that monitor for displaying video.

For example, from a Mac OS X Server Terminal window:

"defaults write MacOS MonitorSelect 0"

"defaults write MacOS MonitorSelect 1"

AppleEvents and AppleScript

For Mac OS X Server applications to be scriptable, they must use the Scripting Framework. Developer documentation on the use of this framework can be found in /System/Documentation/Developer/YellowBox/ReleaseNotes/

The Script Editor in MacOS.app can target applications that are running in the Mac OS X Server environment. On the local machine, targeting these applications is done the same way that targeting Mac OS applications is done.

For example, if you have a Mac OS X Server application named Sketch, you would target the application with standard AppleScript syntax:

tell application "Sketch"

...

end tell

tell application "Sketch;hostname"

...

end tell

tell application "Finder" of machine "machine name" of zone "zone name"

...

end tell

The MacOS.app Script Editor cannot get the dictionary information for a Mac OS X Server application in Mac OS X Server 1.1. This functionality will be added in a later release.

By default, Scripting between two machines is turned off for security purposes (similar to Mac OS Program Linking which is turned off as the default). The following information will help you turn on remote AppleEvents and remote AppleScripting.

The remote scripting default is called NSAllowRemoteAppleEvents.

It can be set from a Terminal window like this:

defaults write NSGlobalDomain NSAllowRemoteAppleEvents YES

defaults write Sketch NSAllowRemoteAppleEvents YES

defaults write TextEdit NSAllowRemoteAppleEvents YES

Sound Output

SCSI Manager

Both the original SCSI Manager and SCSI Manager 4.3 are supported with the following limitations:

Original SCSI Manager:
• SCSIReset will not reset the SCSI bus.
• The values returned from SCSIStat provide only an approximate indication of what is going on during a transaction. Code that relies on SCSIStat to control an operation may fail.

SCSI Manager 4.3:
• MacOS.app does not support Mac OS drivers for third-party SCSI cards. Mac OS X Server DriverKit drivers are required to use these cards.
• The SCSIBusInquiry function does not return complete information about each SCSI bus.
• The SCSIResetBus function will not reset the SCSI bus.
• Command queuing functions, such as scsiQEnable, scsiSIMQHead, scsiSIMQFreeze, scsiSIMQNoFreeze, scsiSIMQFrozen and SCSIReleaseQ are not implemented.
• All SCSI transfers use DMA. Handshaking information is ignored. The scsiSelectTimeout parameter is ignored.
• SCSIAbortCommand and SCSITerminateIO are not implemented.
• The SCSI implementation will attempt to negotiate synchronous data transfer and device disconnect by default.
• scsiNoParityCheck, scsiDisableSelectWAtn, scsiSavePtrOnDisconnect, scsiDisableWide, scsiInitiateWide, and scsiRenegotiateSense, scsiNoBucketIn, and scsiNoBucketOut are not supported.
• If an application traverses the SCSI chain, devices that are already reserved or in use (e.g., by Mac OS X Server) will not be found. In order to have an application recognize a device via the SCSI manager, you must explicitly set that device to SCSI mode as described below.

Disk Access Modes

The sections below describe the tradeoffs among the three access modes: Shared, Exclusive, and SCSI. If you are just running Mac OS productivity applications, you should not need to switch the access mode for any of your disks or partitions. However, in case you need to run disk utilities - such as Disk First Aid, Disk Copy, or Drive Setup - you may need to (temporarily) switch the access mode of one or more of your disks or partitions. The "Blue Volume Mount Options" control panel is provided to allow you to set these access modes for individual disks and disk partitions. It is described below, after the explanations of the three access modes.

You can determine in which mode a volume is being accessed by selecting it in the Finder and invoking the "Get Info" command from the "File" menu. The dialog that appears includes a "Where" string that describes the mode in which the underlying disk is currently being accessed, along with an indication of the physical disk to which it corresponds. Disks accessed in Shared mode will have "Shared" in this string. Similarly, disks accessed in Exclusive mode will have "Exclusive" in this string. Disk image files (which are always accessed in Exclusive mode) will list the pathname of the disk image file. Disks accessed in SCSI mode will have a string identical to the one they would display if running native Mac OS; typically this string gives the SCSI Bus number and SCSI device ID of the drive.

For disks accessed in Shared or Exclusive mode, the SCSI bus and ID (or ATA/IDE ID) are not given; instead, they are identified in the "Where" string by their Mac OS X Server device name. In order to understand how Mac OS X Server names disk devices, you will need to consult the documentation for Mac OS X Server. Briefly, SCSI (and ATAPI) disks have names like "sd0", "sd1", etc. ATA/IDE drives have names like "hd0"; and floppy disks have names like "fd0". Disk devices may also have more than one HFS(+) partition; the first HFS(+) partition of "sd0" is "sd0_hfs_a", the second is "sd0_hfs_b", etc. Disks without partition maps (such as floppies and ISO9660 CD-ROMs) are treated as though they consisted of a single HFS(+) partition, comprising the whole disk (e.g., "sd0_hfs_a").

Shared Mode

Although Shared mode access provides the highest level of interoperability between Mac OS and Mac OS X Server applications, it is not compatible with Mac OS applications that require low-level disk access. Mac OS productivity applications are not affected by this incompatibility since they access files and folders via the high-level interface provided by the File Manager. On the other hand, disk utility programs typically require low-level disk access. Examples of disk utilities that require Exclusive mode access are Disk First Aid, and Norton Disk Doctor. Examples of disk utilities that require SCSI mode access are Drive Setup, and FWB's Hard Disk Toolkit. None of these utilities will function correctly on a volume accessed in Shared mode.

Volumes accessed via Shared mode are slightly less compatible with Mac OS applications than if they were mounted in Exclusive or SCSI mode. But they are far more flexible because they allow you to concurrently share data between Mac OS applications running inside MacOS.app and Mac OS X Server applications running in the Mac OS X Server environment. This means that the files and folders you see in MacOS.app can also be seen from Mac OS X Server.

In Shared mode you should be able to run nearly all of the applications you run on a native Mac OS system. One small difference between volumes accessed via Shared mode is that the size of the underlying "disk" may not be reported accurately. For small HFS disks (like floppies), it might be overestimated by a few kilobytes and for large HFS+ disks (like multi-gigabyte hard drives) it might be underestimated by a few megabytes. This cosmetic difference should not have any adverse affect, since block-level access is not permitted on disks accessed via Shared mode.

In general, other incompatibilities and inconsistencies result from conflicts over shared resources. For example, if a Mac OS application running inside MacOS.app is accessing a file (or group of files) at the same time that a Mac OS X Server application is accessing them, there is a risk that they might make conflicting changes.

One place where this arises is in the process by which the Mac OS Finder rebuilds the Desktop Database. In Mac OS X Server, the Desktop Database is a shared resource that is managed by an independent server task (the "DesktopDB" server) and which fields requests from various clients, including MacOS.app. This works well and provides a centralized place for serializing access to the shared Desktop Database files. However the mechanism used by the Mac OS Finder for rebuilding the Desktop Database conflicts with the Desktop Database server. Consequently, rebuilding the Desktop Database on a Shared volume will not always have the desired effect. This issue will be addressed in a future Finder and MacOS.app. As a workaround you can switch the disk to Exclusive mode, rebuild the Desktop Database, and then switch the disk back to Shared mode. See the section on the "Blue Volume Mount Options" control panel for information on switching modes.

Another example of a shared resource conflict can be seen when attempting to eject a disk from one environment (the Workspace or the Finder) while it is in use by an application in the other environment. In this case, the ejection attempt may appear to succeed (i.e., the volume's icon may disappear from the desktop) but the disk might not be physically ejected from the disk drive. If this happens, the solution is to switch to the other environment and eject the disk from that environment as well (after closing any files that may be in use first, of course). Since Mac OS X Server cannot tell if individual files are open by Mac OS applications running inside MacOS.app, the Workspace will refuse to eject a disk that is mounted in MacOS.app, even if there are no individual files opened from that volume by Mac OS applications. Going in the other direction is a little better; when you attempt to eject a removable disk from MacOS.app it will ask the Workspace to unmount any volumes mounted from that disk and to eject the disk. If there are no files open from that volume and no processes whose current working directory is set to a directory on that volume, then the disk will be automatically unmounted from Workspace and ejected - there will be no need to switch to the Workspace and eject the disk again.

Remember, having a Mac OS X Server application with its "current working directory" set to a folder on a disk marks that disk as "in use" the same way that having an open file does. For example, if you insert a floppy in the Workspace then in a Terminal window "cd" to some directory within the floppy, you will not be able to eject that floppy via MacOS.app.

Removable disks accessed via Shared mode are not ejected upon shutdown of MacOS.app (floppies are an exception).

How does Shared volume support work? MacOS.app contains the same File Manager code used by the native Mac OS with the addition of some logic that determines when a file system request is targeting an object on a Shared volume. These requests are passed over to the HFS(+) implementation in Mac OS X Server. The important thing to note is that this processing happens at the level of Mac OS File Manager requests, as opposed to disk driver requests or SCSI Manager requests. Thus, when you ask to "open" a file on a Shared volume, that request is sent to Mac OS X Server and is processed there. The results of the "open" in Mac OS X Server are passed back to MacOS.app and mapped into Mac OS "open" results. Then, a "read" from the newly opened file would be mapped into a Mac OS X Server "read" request and the results mapped in a Mac OS "read" result. The MacOS.app implementation of the Shared file system tries to map the file system requests and their results as closely as possible to native Mac OS. Applications should never know (or care) that they are running in the MacOS.app on a Shared volume, as long as they limit themselves to making File Manager requests and do not attempt to make disk driver or SCSI Manager requests.

The choice between Shared and Exclusive mode access can be made on a per-partition basis for disks with multiple HFS(+) partitions.

Exclusive Mode

When Mac OS X Server first detects an HFS(+) disk partition (either when starting up or when a removable disk is inserted into a drive) it mounts it and notifies MacOS.app. MacOS.app is also notified about disks that are not recognized or mounted by Mac OS X Server. When MacOS.app notices a disk that has been mounted in Mac OS X Server for which the user has selected Exclusive mode, it asks Mac OS X Server to unmount the disk and then mounts it exclusively.

Because it remains under the control of the Mac OS X Server SCSI drivers, a disk accessed via Exclusive mode cannot be accessed via the Mac OS SCSI Manager, even if the underlying disk is a SCSI disk.

Volumes accessed in Exclusive mode can be read from and written to, regardless of the access rights of the user.

Disk image files like the supplied StartupDisk.img are always accessed via Exclusive mode.

The choice between Exclusive and Shared mode access can be made on a per-partition basis for disks with multiple HFS(+) partitions.

Removable disks accessed via Exclusive mode are usually ejected upon Shutdown or Restart of MacOS.app. CD-ROMs are an exception and are not ejected upon shutdown, in order to more closely mimic the behavior of Mac OS.

SCSI Mode

Like Exclusive mode, SCSI mode must be selected by using the "Blue Volume Mount Options" control panel. When MacOS.app first detects a disk for which SCSI mode has been selected, it attempts to unmount it from Mac OS X Server. If this succeeds, MacOS.app can access it in SCSI mode without fear of interference from Mac OS X Server applications.

Volumes accessed in SCSI mode can be read from and written to, regardless of the access rights of the user.

Unlike the choice between Shared and Exclusive mode access - which can be made on a per-partition basis for disks with multiple HFS(+) partitions - accessing a disk via SCSI mode precludes any other sort of access, either by Mac OS X Server or via Shared or Exclusive mode in MacOS.app. One consequence of this is that a disk containing a UFS file system partition that is mounted by Mac OS X Server cannot be accessed via SCSI mode in MacOS.app. For example, if your system has only one hard drive and has separate partitions for UFS and HFS(+) file systems, you will not be able to access the disk in SCSI mode.

Removable SCSI drives without media present will become reserved for SCSI mode access if probed via a SCSI disk utility like Drive Setup.

SCSI mode access is not available for ATAPI devices (which includes the internal CD-ROM and optional Zip drive on some Power Macintosh G3 models) or IDE/ATA devices (which include the internal disks on most non-Server Power Macintosh G3 models).

Switching Modes: The "Blue Volume Mount Options" Control Panel

Launching the "Blue Volume Mount Options" control panel displays a single dialog which can be dismissed by quitting the control panel or closing the window. Any changes that are made are stored immediately upon quitting the control panel, although most changes do not take effect until MacOS.app is restarted.

The control panel lists all the disk drives and disk partitions that it finds on the system, together with three columns of radio buttons, named after the three possible modes of operation: SCSI, Exclusive, and Shared. If a radio button does not appear in one of the columns, it means that the corresponding mode is not available for that drive (e.g., SCSI mode for an ATAPI CD-ROM drive). Radio buttons are used to convey the fact that each drive or partition can only be accessed in one mode at a time. For a brief explanation of how Mac OS X Server names disk devices, see the beginning of the "Disk Access Modes" section. If a disk partition is already mounted in Shared or Exclusive mode, it will appear in the control panel under that name (e.g., "sd0_hfs_a"). If it is a removable drive with no disk present, it will appear under the name of the drive (e.g., "sd0"). Finally, if it is being accessed via SCSI mode, it will appear labeled with its SCSI Bus and device ID (e.g., "Bus 0, ID 0"). In each case, these labels should correspond closely to what you will find in the "Where" string displayed in the Finder's "Get Info" dialog for that volume.

The same disk may appear under different names at different times in the "Blue Volume Mount Options" control panel depending on whether there is a disk in the drive. For example, the internal ATAPI CD-ROM drive on a Power Macintosh G3 will appear as "ATA drive sd0" when there is no CD-ROM in the drive, but as "HFS partition sd0_hfs_a" when a CD-ROM is in the drive.

If a disk has multiple HFS(+) partitions, they can be accessed in Shared or Exclusive mode independently from one another. In other words, the choice between Shared and Exclusive mode can be made on a per-partition basis. Similarly, Mac OS X Server can mount a UFS partition from a disk containing one or more HFS(+) partitions, each of which may be accessed in Shared or Exclusive mode. SCSI mode is different, though, because it requires complete control of all requests going to the disk. Therefore, selecting SCSI mode for one partition on a disk causes all the partitions on the disk to be accessed via SCSI mode. If you try this, you will see that the settings of the radio buttons automatically reflect this constraint. Similarly, you cannot select SCSI mode for a disk containing a mounted UFS file system. If you do select SCSI disk mode for a disk that contains an unmounted UFS file system, your selection will be honored. You will not be able to mount that UFS file system in Mac OS X Server while MacOS.app is accessing the disk in SCSI mode.

For fixed, non-removable disks, changes made via the "Blue Volume Mount Options" control panel will not take effect until MacOS.app is restarted. Removable disks are an exception to this rule: if you change the access mode for a removable disk then it will be accessed in that mode the next time you insert a disk in the drive. Consequently, you can quickly change the access mode for a removable disk by changing the setting in the control panel (and quitting it), ejecting the disk, and reinserting it - all without needing to restart MacOS.app.

There is one situation in which switching modes requires special care. When switching a non-removable disk to Shared mode from some other mode, you must shut down MacOS.app and wait for the Workspace to remount the disk on its desktop before re-launching MacOS.app. Otherwise, if you were to switch a disk to Shared mode and restart MacOS.app (e.g., from the Finder) then the Workspace might not have enough time to remount the disk before MacOS.app claimed it in Exclusive mode again. In this situation, the disk would not appear on the desktop of the Workspace and the "Where" string in the Finder's "Get Info" dialog for the disk would indicate "Exclusive". If this happens, the only way to get the Workspace to remount the disk for Shared access is to log out of the Workspace (after shutting down MacOS.app) and log back in again.

Currently, settings made via the "Blue Volume Mount Options" control panel are stored in the user's defaults database, although this might change in the future. Consequently, in a NetInfo environment, the same settings will be used for a user regardless of the machine they login to - beware. To see which disks have been set up in Exclusive mode, execute this command from the command line (i.e., in a Terminal window): "defaults read MacOS ExclusiveDisks". This "defaults" setting is a list consisting of device and/or individual partition names, separated by spaces. To see which disks have been set up in SCSI mode, execute this command at the command line: "defaults read MacOS SCSIDiskLoans". This list consists of ":" pairs, separated by spaces. If a disk or partition is not mentioned on either of these lists then MacOS.app will attempt to access it via Shared mode. In general, there should be no need to view these settings from the Mac OS X Server command line rather than with the "Blue Volume Mount Options" control panel. However, this information is provided because it might be useful for remote diagnosis and trouble-shooting.

The disk mode selections made via the "Blue Volume Mount Options" control panel are only requests. In some cases, it might not be possible to honor them and MacOS.app may mount a disk in a mode other than the one selected in the control panel. To find out what mode a volume is being accessed in, you can interpret the "Where" string displayed in the Finder's "Get Info" dialog for that volume, as described at the beginning of the "Disk Access Modes" section. For example, if Exclusive mode is selected for a disk partition but a Mac OS X Server application has a file from that partition open, then MacOS.app will not be able to get Exclusive access when it starts up. Rather than having the disk not appear in MacOS.app in this situation, MacOS.app will fall back to mounting the disk in Shared mode.

Mac OS X "Disk Mounting" Preferences

To invoke the "Disk Mounting" preference panel, select it in the "Computer Settings" submenu of the Mac OS X Server Apple Menu. The panel includes some explanatory text. To change the panel's setting, you must be logged-in as root. Changes will not take effect until Mac OS X Server is restarted.

The default setting for a Server configuration is either "Fixed & removable disks" or "Only fixed disks". In a non-Server configuration where MacOS.app is going to be used extensively, it may be more convenient to select the "Only the startup disk" setting, for reasons that will be explained. However, this setting is not appropriate for a Server, because it means that files cannot be served from disks other than the startup disk unless someone is logged into the server. The other two settings are more appropriate for a Server because they permit files to be served from all disks attached at startup time, regardless of whether anyone is logged into the server.

In either of the Server modes you must be logged-in as root if you wish to use MacOS.app to eject removable disks or access disks via Exclusive or SCSI mode. This is a security precaution that is appropriate for a Server configuration, but might be overly restrictive for a Macintosh that is being used as a personal workstation, especially if it is shared between non-root users. If you select the "Only the startup disk" setting in the "Disk Mounting" preference panel (and restart Mac OS X Server), then disks other than the startup disk will be mounted upon login and unmount upon logout. As a result, the user that logs in will be able to use MacOS.app to unmount these disks, e.g. in order to eject a removable disk or to access a disk via Exclusive or SCSI mode.

Disk Drive Support

The following sections discuss the level of support provided for various kinds of disk media. Since some things apply to whole families of drives (e.g., SCSI drives) and some things apply to specific kinds of drives (e.g., CD-ROM drives), there is some overlap between the categories and you may need to read them all in order to find what you are looking for.

SCSI Disk Drives

For more information on SCSI mode file system access, see the section on "SCSI Mode File System Access". For more information on switching the access mode, see the section on the "Blue Volume Mount Options" control panel.

SCSI disk devices (e.g., hard drives, CD-ROM drives, Zip drives, and Jaz drives) are supported, including those with multiple partitions. In Shared and Exclusive mode they behave like generic SCSI hard drives with the addition that disk-insertion detection and auto-ejection are supported. In Shared and Exclusive mode, special vendor-specific drivers (e.g., the Iomega Driver) are not loaded or used. If the drive has a manual-ejection button then it will be disabled while the disk is being accessed.

In SCSI mode, most third-party SCSI drivers are supported, including those that make possible special device-specific features (e.g., hardware write-protection or password protection). In this mode, MacOS.app supports the original SCSI Manager and SCSI Manager 4.3 with limitations. See the section on "Bugs and Compatibility Issues" for more details.

Mac OS X Server implements SCSI device arbitration. This means that only one client can send SCSI commands to a SCSI device at a time. Often, in the case of SCSI disks, this client is the Mac OS X Server file system. When MacOS.app is accessing a disk partition in Exclusive mode, then it is the client. For the purpose of SCSI mode access, MacOS.app can "see" any SCSI device not in use by Mac OS X Server (or any other client). In particular, removable disk drives with no media in place are always visible to MacOS.app and if probed will be accessed in SCSI mode until MacOS.app is shut down.

ATA/IDE/ATAPI Disk Drives

"ATA" and "IDE" are used interchangeably. The internal hard drives on most non-Server Power Macintosh G3 models are ATA/IDE drives. MacOS.app does not currently support the Mac OS ATA Manager. A future release may include an "ATA mode" similar to the existing "SCSI mode". "ATAPI" drives are special ATA/IDE drives with additional features. The internal CD-ROM and optional Zip drives on Power Macintosh G3 models are ATAPI drives.

Floppy Drives

High Density (1.44 MB) floppies are fully supported. 800 KB floppies are supported read-only.

MacOS.app supports auto-detection and auto-ejection of floppies. Low-level initialization is only supported in Exclusive mode. If you insert a floppy that lacks a low-level format, it will be automatically accessed in Exclusive mode in order to permit you to initialize it. If, after initializing such a floppy, you wish to access it in Shared mode, you will need to eject it and reinsert it. See the section on the "Blue Volume Mount Options" control panel for instructions on how to change the mode. See the "Bugs and Compatibility Issues" section for other floppy issues.

Disk Image Files

CD-ROMs

HFS(+) CDs can be accessed in Shared, Exclusive, or SCSI mode. DOS, ProDOS, PhotoCD, ISO 9660, and High Sierra CDs are automatically mounted in Exclusive mode, even if Shared mode is selected. They are also accessible in SCSI mode.

ISO9660 CDs are treated specially: they are mounted simultaneously in Mac OS X Server and in MacOS.app, but they are mounted in Exclusive mode in both environments. This may sound like a contradiction, but is possible because CD-ROMs are read-only media and there is no risk of writing inconsistent data or causing disk corruption. ISO9660 CD-ROMs are the only exception to the rule that disks appearing in MacOS.app in Exclusive mode do not appear in Mac OS X Server.

Only the first session of a multisession CD-ROM will be accessible in Shared or Exclusive mode. To access additional sessions the CD-ROM drive must be accessed in SCSI mode. See the section on the "Blue Volume Mount Options" control panel for instructions on how to change the mode.

Audio CDs are only accessible in SCSI mode. Audio playthrough is not supported, however.

If an Audio CD or any other CD in an unsupported format is inserted in Shared or Exclusive mode then the CD will automatically be ejected from the drive.

CD-ROMs are not ejected upon Shutdown or Restart of MacOS.app, even if accessed via Exclusive mode. This mimics the behavior of the native Mac OS.

DVD ROMs

Working with Disk Image Files

Use of Disk Image Files

Although disk image files are used as default startup volumes in this release, they may not be the best choice for long-term use. More convenient startup volume options are available in this release which supports HFS(+) volumes that can be shared between Mac OS X Server and Mac OS.

You can use the Mac OS Startup Disk control panel to select a different startup volume. This can be very useful, but a few important steps are needed to properly setup a startup volume. If you plan to use this feature, be sure to read the "Startup Options" section below.

The StartupDisk.img created when you first launch MacOS.app is a relatively small startup volume (175 MB), which will not allow installing much software. It is suggested that you use available Mac OS partitions or create additional disk images to hold Mac OS applications and documents.

Even if you install applications elsewhere, as suggested, many applications also take up space in the System Folder on the startup disk. Enough free space (about 40 MB) has been left for the System Folder additions of a few applications. However, you may eventually run out and be forced to enlarge your StartupDisk.img, as described below, or switch to startup from an HFS(+) partition.

Creating New Disk Image Files

/Local/Library/MacOS/Users/<user name>

~/Library/MacOS

/Local/Library/MacOS

/System/Library/MacOS

MacOS.app respects the file permissions for disk images. If the user has only read permissions for the disk image file in the Mac OS X Server file system, then the image will appear locked in MacOS.app.

You can create new disk image files in Mac OS X Server by using Disk Copy in MacOS.app and creating the disk image on a shared volume, which can then be moved to one of the above directories. You can also create a disk image on a native Mac OS system and transfer the file to Mac OS X Server with "ftp" (or other utility).

Alternatively, you can use the provided "createimage" tool in the /usr/bin/ directory. It creates an empty image file that can be made available within MacOS.app. To use this tool, from a Terminal window (when logged in as the user who intends to use the image), execute:

createimage -mb num -o name

"/Local/Library/MacOS/Users/<user name>/<name>.img".

createimage -mb 100 -o /Local/Library/MacOS/Users/me/mydata.img

Note: Issue Initializing Disk Image File

Enlarging Your Startup Disk Image File

1. Make sure that MacOS.app is not running.

2. Create a new, larger, disk image using "createimage".
cd /Local/Library/MacOS/Users/<user name>

createimage -mb <size in MB> -o NewStartupDisk.img

3. Start MacOS.app.

4. Initialize the new volume when asked.

5. Copy the contents of the startup disk to the new volume.

6. Shut down MacOS.app.

7. Rename the original StartupDisk.img and rename your new disk image.


cd /Local/Library/MacOS/Users/<user name>

mv StartupDisk.img StartupDisk.img.old

mv NewStartupDisk.img StartupDisk.img

When you are satisfied that the new startup disk image is OK, the old image may be removed to conserve disk space.

It is also possible to transfer image files to native Mac OS and modify their contents using Apple's Disk Copy utility. The correct file type and creator for image files are 'hdrv' and 'ddsk', respectively. These can be set when transferring if using Fetch, or afterwards via ResEdit or other utilities. The version of Disk Copy included with this release of MacOS.app supports opening disk image files with incorrect file types via drag and drop. Disk Copy will treat the data fork as a valid image only if the resource fork does not have any of the NDIF specific resources in it (or if there is no resource fork at all). So, if ftp is used to download just the data fork of a Disk Copy image file, Disk Copy should be able to mount it.

Startup Options

Startup

If you wish, you may select an HFS(+) partition as your startup disk, using the Startup Disk control panel. You can even dual boot native Mac OS and MacOS.app from the same startup disk.

As with native Mac OS systems, you can hold the "C" key down to start up from the CD-ROM drive. This is done just after starting up MacOS.app, but before the gray screen appears.

Configuring a Startup Disk's System Folder

Once your new startup disk is set up, select it using the Startup Disk control panel and then restart MacOS.app.

After setting your system to start up from a Mac OS partition, you may remove the StartupDisk.img file from the /Local/Library/MacOS/Users/ directory.

Startup Issues

Startup Disk Issues

After modifying your PRAM file, you will be given the option of deleting, using or renaming your current StartupDisk.img. If the disk image is corrupted and you don't want to mount it, but you don't want to delete it, be sure to remove the ".img" extension when renaming. Renaming a disk image across Mac OS X Server file system volumes (mount points) will result in a copy (rather than a rename). This will take a while.

If the "Copying StartupDisk.img" dialog is cancelled when MacOS.app is not in the foreground (i.e., the dialog is frontmost, but is not active), the "Cancel" button may appear pressed, but then doesn't release. Click anywhere in the dialog to complete the cancel operation.

Renaming a startup disk image across file system volumes when there is insufficient disk space available may cause Mac OS X Server to fail. Due to the large size of the disk images, caution should be used when maintaining several on your disks.

Copying StartupDisk.img Issues

Bugs and Compatibility Issues

Killing MacOS.app from Mac OS X Server Workspace Process Menu

ps -aux | grep MacOS

machine ps -aux | grep MacOS

user 721 96.5 26.1 1.03G 33.4M ? R N 2:21 MacOS.app

user 752 0.2 0.1 924K 88K p1 U 0:00 grep MacOS

kill -9 721

Tear Off Application Menu

AppleShare File Server connection lost using TCP/IP

Unable to read PC Zip disks

Norton's CrashGuard

Launching PowerPC Applications from Disks in Direct SCSI Mode

Symantec's ACT!

Eudora Pro 4.1

MacBench 5.0

Myth II

Switching from MacOS.app to Mac OS X Server

Locked files not owned by current user

Disk Icons

Disk First Aid, Drive Setup, and the Mac OS installer

Versions of Disk First Aid and the Mac OS installer currently shipping will not function correctly when their target is a disk accessed via Shared mode. Starting in a future version of Mac OS, Disk First Aid will simply report "no errors" for disks accessed via Shared mode without actually examining the disk. You can run the Mac OS X Server version of Disk First Aid (DiskFirstAid.app) or you can set the access mode of the target disk to Exclusive mode. See the "Disk Access Modes" section for more information.

In general, the Drive Setup application cannot be used on disk volumes that are accessed via Shared or Exclusive mode. It can only be used on SCSI disks (not ATA/IDE/ATAPI disks) that are accessed via SCSI mode. One of the things that the Mac OS installer does is ask Drive Setup to update the disk drivers of all the disks connected to your Macintosh. Disks that are being accessed via Shared or Exclusive mode will not be detected by Drive Setup and so will not have their drivers updated. Therefore, if you ever intend to boot your Macintosh into the native Mac OS, you should run Drive Setup manually from within the native Mac OS and select the "Update Drivers" menu option. Setting your disks to be accessed via SCSI mode from within MacOS.app might also work, but there are a few things that might prevent this from working as well as it would if you did it from within the native Mac OS: you might have non-SCSI disks on your system, or you might not be able to get SCSI mode access to all of your disks since at least one of them is used as the Mac OS X Server boot disk and therefore cannot be unmounted. See the "Disk Access Modes" section for more details.

If you have a 36 GB disk, do not format it with the version of Drive Setup that is located on your MacOS.app Startup disk. This could result in an improper format of the disk. Drive Setup 1.7.1, which can be found on the Mac OS X Server installation CD, should be used to format 36 GB disks.

Desktop Rebuild For Shared Mode Volumes

MacOS Crashes After Improper Shutdown

Runtime Performance

File System Performance

NMI (Non-Maskable Interrupt)

Mac OS X Server Workspace Logout

Sparse Virtual Memory

Aliases on Removable Disks

Disk Copy Disk Images

Disk images will only mount from shared volumes when the new Disk Copy driver (6.3.3) is loaded. This will happen if you run Disk Copy 6.3.3. The newer driver will override older drivers and "stick" until Shutdown once loaded. This does mean that if you mount an SMI (Self Mounting Archive) created with an earlier version of Disk Copy before the new Driver has loaded, it will not work. The workaround is to run Disk Copy 6.3.3 once.

Disk Initialization

SCSI mode: The low-level formatting and partitioning of SCSI disks can only be achieved via Drive Setup for disks that are accessed via SCSI mode. Currently, this is not supported for ATA/IDE drives.

Exclusive mode: The Finder's "Erase disk..." menu option should function as expected for all volumes accessed via Exclusive mode. It will even perform a low-level format for floppies, as long as they are accessed via Exclusive mode.

Shared mode: Neither Drive Setup nor the Finder's "Erase disk..." menu option will function for disks accessed via Shared mode. You should not attempt to reformat or erase a volume that is being accessed via Shared mode. If you select a Shared disk and invoke the "Erase disk..." menu option and then select either the "Mac OS Standard" or "Mac OS Extended" format, then the operation will be aborted and you will get an error alert stating that the "Erasing the disk failed!", and the volume will be unmounted causing it to disappear from the desktop. If this happens, you can remount the volume via the Disk First Aid application - no data will be lost or altered.

The mouse cursor may freeze while performing the low-level format portion of the initialization process on a floppy. Switching to Mac OS X Server will be disabled until the formatting has completed, which may take several minutes.

MacOS.app ignores UFS disks by design, so you cannot reinitialize a UFS disk as HFS(+) with MacOS.app. However, you can do this via the native Mac OS.

NFS Sharing of Disk Images

Floppy Disk Can Prevent Startup

Removable Media - Insertion and Ejection

A request to eject a removable disk within MacOS.app may fail silently if the disk is shared with Mac OS X Server and files are open on the Mac OS X Server side (or a process has its current working directory set to a directory on the disk). In this situation, MacOS.app will behave as though the disk had been ejected (e.g., the disk's icon will disappear from the Finder's desktop), but the disk will not have been physically ejected from the drive. In this situation, you will have to switch to Mac OS X Server and eject the disk via the Workspace (after closing any open files, of course).

MacOS.app ejects all removable media upon shutdown if they are accessed via Exclusive mode, with the exception of the CD-ROM drive. If you select a removable disk as the startup disk using the Startup Disk control panel and that disk is accessed via Exclusive mode, then you will have to quickly reinsert the disk into the drive during the restart.

File System Permissions on HFS(+) Volumes

HFS+ volumes mounted in shared mode behave similarly to HFS volumes with the exception of permissions that are explicitly set. Permissions are saved to disk on HFS+ volumes and are persistent on Mac OS X Server. However, native Mac OS completely ignores the permission information: it is neither enforced nor maintained. The HFS+ volume mount point will be owned by root and the group will be set to "macos", just as with HFS volumes. When a file is created the current user will be owner of the file and the group will be "macos". This will enable users in MacOS.app to access files as if they were running native MacOS. Please note that once permissions are set on HFS+ volumes they are honored when MacOS.app runs. So if you, or someone else, sets permissions in a terminal window, the above mechanism to allow MacOS.app access (via group macos) to files and folders will not allow access for someone without appropriate permissions to a file or folder. Unfortunately, MacOS was not designed to run in an environment where file access permissions might deny access. In most cases volumes mounted in shared mode will return "access denied" error codes that the Finder will pass along to the user when a permissions failure is noticed in the underlying file system. But there may be some cases where a confusing error may occur - so if you see strange error messages or odd behavior from an application on an HFS+ volume mounted in shared mode, keep permissions in mind.

As noted above, the group "macos" is a special group used to allow users of MacOS.app to access HFS and HFS+ file systems. If this group is removed or renamed, MacOS.app will not be able to access some local filesystems, and will refuse to run unless you are logged in as root.

Apple file services uses group permissions to control remote access to exported filesystems. If you set the group of an exported filesystem to anything other than "macos", then non-root users will not be able to access these filesystems in MacOS.app. To set the group for exported file systems using Remote Administration, click Disk & Share Points and click the disk or folder you want to share, then click Set Privileges.

Symbolic Links in Shared Mode

Sound Input /Output

Playing sound from an application running in Mac OS X Server at the same time an application is playing sound in MacOS.app may result in unpredictable results.

Sound input is not currently supported. This will affect speech recognition software.

Video Capture

Special Hardware Support

Using Localized Disk Images

Copy and Paste Between Mac OS and Mac OS X Server

When copying data from MacOS.app to a Mac OS X Server application, it may take a noticeable period (up to several seconds) before the pasteboard is synchronized with data from the MacOS.app clipboard. If a paste is performed before this time (e.g., immediately after switching out of MacOS.app), the data may be incorrect, and the paste should be performed again.

MacOS.app supports the pasting of Japanese text between the Mac OS and Mac OS X Server environments. Starting with System 8.5.1, Japanese text can be copied to or from a Japanese localized Mac OS if MacOS.app was started with the Mac OS X Server Localization Preference set to Japanese.

System Folder Pieces

Serial

Printing

Mouse Acceleration

Video

Similarly, if you switch to Mac OS X Server and then Mac OS hangs, you can't switch back. In that case, you must kill the MacOS.app process from Mac OS X Server. If MacOS.app drops into MacsBug while hidden, you may be able to unhide MacOS.app, but user input will not work. Command-Shift-Q should work.

The Video vertical retrace queue is hung off the System vertical retrace queue, and is therefore not synchronized with the actual monitor refresh interval.

If for any reason MacOS.app causes the Mac OS X Server cursor to go away, you can restore it with the following command from a Terminal window:

/System/Applications/MacOS.app/MacOS -showcursor 50

Some Mac OS applications that draw directly to the screen may continue to do so even after switching from Mac OS to Mac OS X Server. The occurrence of this behavior may be limited by switching to the Finder before switching to Mac OS X Server.

Video mirroring in Mac OS is the feature where both monitors of a dual-monitor system display the same exact picture. Use of this feature is not fully supported in MacOS.app. If you use video mirroring, make sure to turn it off before switching to Mac OS X Server from the application menu.

Hardware video acceleration is not yet supported.

User Input

Command-Shift-Q will force MacOS.app to quit. This only works if Mac OS is hung, not if the Mac OS X Server part of MacOS.app is hung. See more details under "Video", above.

MacOS.app will intercept the Command-Return key sequence and use it to jump to Mac OS X Server. This is the same key combination that PC compatibility cards use. However, some Mac OS applications (like MPW) need this key combination for full functionality. To disable special handling of this key combination, type "defaults write MacOS ScreenToggleKey 0" on the command line of a Terminal window.

Date & Time

Canceling the "Copying StartupDisk.img" Dialog

SCSI Based Printers

Apple Software

The Mac OS Setup Assistant on MacOS.app takes a little longer to configure printers than it does on native Mac OS. During this time do not select any menu or you will hang MacOS.app.

The Graphing Calculator has a bug which can cause a crash when running its "Mouse Control" demo and the application is located high in memory. This also happens on native Mac OS, but is much more common in MacOS.app.

The AppleCD Audio Player does not work in MacOS.app without additional configuration. Since the AppleCD Audio Player uses the SCSI Manager to find CD-ROM drives, this causes the application not to work in MacOS.app because CD-ROM drives are not mounted in SCSI mode by default in MacOS.app.

If the AppleCD Audio Player does not find at least one CD-ROM drive, it will return an error indicating that the CD-ROM drive is not responding. Some CD-ROM drives can be enabled to use direct SCSI access; see the section on the "Blue Volume Mount Options" control panel for instructions on how to switch the mode. If direct SCSI access is enabled on at least one CD-ROM drive, the AppleCD Audio Player will launch with no error and audio CDs can be played from MacOS.app, although audio playthrough is not supported.

Apple Video Player refuses to launch because MacOS.app does not currently support video capture.

When using the Extensions Manager, some of the installed Apple software is not a part of the "Mac OS 8.5 all" set (for example, "AppleScript" and "QuickTime"). This is normal when newer releases are installed.

Disk Copy prior to version 6.3.3 cannot mount images on a Mac OS volume that is in the Shared Access mode.

MacOS.app does not contain all the necessary Unicode converters to handle file and folder names on HFS+ volumes that were created on a native Mac OS machine using a system script other than Mac OS Roman. For example, if you take an HFS+ volume that was used on native Mac OS with the Japanese language kit installed, and you access it on Mac OS X Server, the file and folder names will appear garbled.

Third-Party Software

Networking modes promiscuous/raw are not supported in MacOS.app; therefore, applications such as Etherpeek are not supported.

Versions of CodeWarrior prior to the Pro 4 release do not support debugging; everything else seems to work. CodeWarrior Pro 4 (IDE 3.1) with version 1.3.6 of the MetroNub supports debugging and break/watch points.

RAM Doubler attempts to access the internals of Mac OS Virtual Memory and is therefore not compatible with MacOS.app.

Virtual PC attempts to access the internals of Mac OS Virtual Memory and is therefore not compatible with MacOS.app.

Disk Doubler Pro (and especially its Finder Menu feature) is not compatible with Mac OS 8.5 and therefore not with MacOS.app.

Speed Doubler causes MacOS.app to hang at startup, presumably because it attempts to modify undocumented Mac OS internals, and is therefore not compatible with MacOS.app.

The Disinfectant system extension (installed via the Protection menu of the Disinfectant application) should not be installed because it can cause some applications to quit with errors (such as Type 1 error). Conflict Catcher and Note Pad are particularly likely to crash when Disinfectant is present. Such errors are more likely to occur on MacOS.app than on native Mac OS because of the memory allocation scheme used in MacOS.app. Disinfectant is no longer supported by its developer, who recommends a full-featured virus protection program.

Adobe Persuasion 4.0's installer frequently fails with a bus error because of a bad memory access. Due to memory layout, this rarely occurs on native Mac OS, so a workaround is to run the installer there. Adobe has discontinued this product.

If drives formatted with FWB's Hard Disk Toolkit are mounted in "Shared" or "Exclusive" mode, any driver-level password protection will be ignored. Data that is encrypted will be inaccessible. Mounting these drives in "Direct SCSI" mode will re-enable password protection and access to encrypted data.

Descent II, like many other video games, uses SCSI Manager calls as part of its copy protection. By default, MacOS.app accesses SCSI disks via Shared mode. In both Shared and Exclusive mode, SCSI-level access is disallowed. The CD-ROM drive needs to be manually configured for direct access via SCSI mode. This can be done with the "Blue Volume Mount Options" application. However, the "Blue Volume Mount Options" application cannot set an ATA/IDE/ATAPI CD-ROM drive to direct SCSI mode. See the section on the "Blue Volume Mount Options" control panel for more information.