Contents
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.6 and will only support that version and versions beginning with Mac OS 8.5. Versions of Mac OS prior to Mac OS 8.5 and later than Mac OS 8.6 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
The first time you launch MacOS.app, a private Mac OS 8.6 startup disk image (called StartupDisk.img) will be created. The image will be copied and uncompressed into /Local/Library/MacOS/Users/<user name>. 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
Each user running MacOS.app on this machine will require a minimum of 225 MB of disk space for the Mac OS 8.6 startup disk image.
Installation
The installation consists of the following installed items:
/System/Documentation/ReadMe/MacOS.html
Features
MacOS.app currently supports Mac OS 8.6. The supplied StartupDisk.img files contain complete default installations of English language Mac OS 8.6 except for Apple Remote Access and Text-to-Speech. These were omitted to save space and because they rely on features not yet supported by MacOS.app.
Do not attempt to boot MacOS.app from System Folders with versions of Mac OS prior to Mac OS 8.5. You may install Mac OS 8.5 or 8.5.1 using the normal Mac OS installation techniques in MacOS.app.
Virtual Memory
MacOS.app uses a new method for virtual memory, taking advantage of Mac OS X Server's VM system. This method, called "Sparse Virtual Memory", allows application heaps to be protected from each other with "guard" pages of unmapped memory. In addition, it allows a large number of applications to be launched, using disk space for memory as it is needed. The total virtual application memory available is 1024 MB.
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
In native Mac OS, an application's memory heap comes out of the same memory area as temporary memory. Since some applications allocate large fractions of available temporary memory, MacOS.app does not offer the entire unused portion of its 1024 MB sparse virtual address space as temporary memory. Instead, the temporary memory heap is created at startup time, with the size determined by the machine's available physical memory, with a minimum size of about 16 MB. Some applications may require a larger amount of temporary memory in order to run properly, and you can allocate additional temporary memory by setting SysZoneMemorySize to the desired size. For example "defaults write MacOS SysZoneMemorySize 0x10000000" will set the temporary memory size to approximately 256 MB. You may notice this difference in the Finder's "About This Computer" dialog box. In native Mac OS, the first bar (labeled "Mac OS") shows the amount of memory allocated to Mac OS and is usually almost fully in use. In MacOS.app, this bar includes the memory allocated to Mac OS plus the temporary memory allocation. On machines with a large amount of physical memory, this bar will be significantly larger.
File Systems
Throughout this document, "HFS(+)" is used as an abbreviation for "HFS or HFS+". HFS is also known as "Mac OS Standard Format" and HFS+ as "Mac OS Extended Format".
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
MacOS.app currently supports basic Copy and Paste between Mac OS and Mac OS X Server applications.
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
MacOS.app supports Open Transport AppleTalk and TCP/IP networking using built-in Ethernet and any PCI Ethernet devices supported by Mac OS X Server. LocalTalk (AppleTalk over serial ports) is not supported. As with native Mac OS, AppleTalk networking is active by default if connected to a network.
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
MacOS.app partially supports the PCI native driver model. This means that the name registry, DriverServicesLib, and associated libraries are present. However, the Mac OS device tree is currently empty, so no 'ndrv' drivers are loaded.
Video
Unlike Mac OS X Server, MacOS.app can change color depth on the fly and supports multiple monitors in color depths of 8, 16, and 24-bit (256, "thousands" or "millions" of Colors or Grays). However, if Mac OS X Server is in grayscale mode, then MacOS.app will not allow depth changes.
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"
means only use the main monitor and
"defaults write MacOS MonitorSelect 1"
means only use the second monitor.
AppleEvents and AppleScript
AppleEvents and AppleScript are supported as usual within MacOS.app and from MacOS.app to scriptable Mac OS X Server applications.
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:
...
end tell
...
end tell
...
end tell
is not supported in this 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 TextEdit NSAllowRemoteAppleEvents YES
Sound Output
Sound output is fully supported by MacOS.app, although breakup may occur during times of heavy CPU usage or memory paging. Occasionally, this may result in sound going silent altogether until the application using sound quits or MacOS.app is restarted. Playing sound in Mac OS X Server and MacOS.app simultaneously will have unpredictable results.
SCSI Manager
The Mac OS SCSI manager is partially supported in this release. It can be used via SCSI Mode for disks, as discussed in the section "Disk Access Modes", and to access non-disk devices (such as scanners and tape drives) which are not in use by Mac OS X Server.
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
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
MacOS.app supports mounting HFS(+) volume(s) which are already mounted by Mac OS X Server. This mode of access is called Shared mode because all the files and folders on Shared volumes are simultaneously accessible from Mac OS applications running inside MacOS.app and Mac OS X Server applications running outside of it. Shared mode was chosen as the default file system access mode because it does not require the user to unmount a volume from one environment before mounting it in the other.
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 problem 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
MacOS.app supports mounting HFS(+) disk volumes in a mode that permits block-level access. This mode permits certain disk utilities (such as Disk First Aid and some operations in Disk Copy) to run that would not work with a disk accessed via Shared mode. This is called Exclusive mode because disks accessed by MacOS.app in this mode appear exclusively in MacOS.app and cannot be accessed by Mac OS X Server applications. You can request that a disk or partition be accessed via Exclusive mode by using the "Blue Volume Mount Options" control panel.
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
MacOS.app supports SCSI disk devices that are recognized by Mac OS X Server. MacOS.app provides a special compatibility mode for accessing these devices via the SCSI Manager, just as they would be accessed under the native Mac OS. This mode provides the highest level of compatibility with Mac OS disk utilities, especially with those that require SCSI access, like Drive Setup.
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
In the "Apple Extras" folder of the supplied StartupDisk.img is the control panel to set the desired access mode for disks and disk partitions. Disks can be accessed in one of three modes (Shared, Exclusive, or SCSI), although not all disks will permit access in SCSI mode. A disk cannot be accessed in SCSI mode if it is not a SCSI disk (e.g., floppies, ATA/IDE/ATAPI disks). Nor can it be accessed in SCSI mode if there is a UFS file system mount point active on the disk at the time the mode switch is attempted (either when the control panel is launched or when MacOS.app is starting up).
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
There is a preference setting, "Disk Mounting", which can restrict MacOS.app's ability to unmount volumes from Mac OS X Server. In turn, this can prevent MacOS.app from ejecting removable disks and from accessing disks via Exclusive or SCSI mode.
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
SCSI Disk Drives
SCSI disk drives can be accessed in Shared, Exclusive, or SCSI mode.
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/IDE/ATAPI drives can be accessed via Shared or Exclusive mode. They cannot be accessed via SCSI mode.
"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
Floppy drives can be accessed in Shared or Exclusive mode. They cannot be accessed in SCSI mode.
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
Disk image files are volume images in Mac OS Disk Copy uncompressed format, stored in Mac OS X Server's UFS file system. They are always accessed in Exclusive mode. From the Mac OS X Server environment, they appear as large binary files whose name end in ".img". In the Mac OS environment, however, they appear as regular Mac OS volumes (with a special icon). By default, MacOS.app will startup from the disk image file in /Local/Library/MacOS/Users//StartupDisk.img. See the section "Working With Disk Image Files", below, for details.
CD-ROMs
CD-ROMs are supported in MacOS.app. They behave like locked SCSI hard drives when accessed via Shared or Exclusive mode. MacOS.app supports auto-detection and auto-ejection of 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
DVD ROM disks are supported in Exclusive and SCSI modes. MacOS.app supports the UDF file system format that is used on these disks. DVD ROM movie playback is not supported in Mac OS X Server.
Working with 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 (215 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
At startup time, after finding the startup volume (StartupDisk.img by default), MacOS.app will search for and attempt to mount image files (files ending in ".img", but excluding StartupDisk.img) in the following Mac OS X Server directories:
/Local/Library/MacOS/Users/<user name>
~/Library/MacOS
/Local/Library/MacOS
/System/Library/MacOS
Note that the first two directories are private to a particular user ("~" means the current user's home directory), whereas the last two are global to all users of the machine.
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
where "num" is the desired disk image size in MB and "name" is the pathname of the image file to be created, usually of the form:
"/Local/Library/MacOS/Users/<user name>/<name>.img".
For example:
createimage -mb 100 -o /Local/Library/MacOS/Users/me/mydata.img
The next time MacOS.app is started, Mac OS will present a dialog offering to initialize this new volume; you should allow the initialization to proceed.
Enlarging Your Startup Disk Image File
You can enlarge your StartupDisk.img by creating a new disk image with "createimage," and copying the contents of the startup disk to that new image. Perform the following steps to create a larger startup disk.
createimage -mb <size in MB> -o NewStartupDisk.img
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
By default, MacOS.app starts up from your StartupDisk.img. If you have problems with your StartupDisk.img, see the section "Startup Disk Problems", below. If the currently selected Startup volume for MacOS.app does not support MacOS.app, a new StartupDisk.img will be created to allow proper 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
For versions of Mac OS prior to Mac OS 8.6 installation requires that the target disk be in Exclusive mode during installation. Beginning with Mac OS 8.6 it is possible to perform an installation to a target disk in Shared mode as well.
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 Problems
If MacOS.app immediately quits on a user's first attempt to start up, check the ownership of the /Local/Library/MacOS/Users/ directory. If it is owned by root, change the ownership to using the chown command, then restart MacOS.app.
Startup Disk Problems
If you have a problem with your StartupDisk.img, MacOS.app can be forced to install a new StartupDisk.img. When starting MacOS.app, hold down the Command-Option-Shift keys. You will be given the option to modify your PRAM file. You must modify your PRAM file to proceed with fixing your startup disk problems. If you accidentally pressed the Command-Option-Shift keys, you should choose the Quit option.
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 Problems
If you receive the "Helper Copy Problem. Exception raised during the write." alert while copying the StartupDisk.img, verify that there is sufficient disk space available for the copy (~ 225 M). This alert can be received if there is negative space available as reported by "df". As a non-root user, type "df -kl" in a Terminal window to get this information.
Bugs and Compatibility Issues
If you use the Mac OS X Server Workspace process menu to force-kill MacOS.app, a problem occurs if MacOS.app has gone through a restart since being launched by the Workspace. The problem occurs because whenever MacOS.app goes through a restart it gets different process IDs for all of the processes associated with MacOS.app. The force-kill option will shut down all of the MacOS.app windows, but the MacOS.app processes will not be killed because the kill signal will be sent to the original process IDs which no longer correspond to the running MacOS.app processes. Therefore, it will appear that MacOS.app has been killed, but you will not be able to launch a new MacOS.app. To work around this problem, you must manually kill the old MacOS.app processes from the command line using the kill command. You must first find the process ID of MacOS.app. You can do this by typing the following command from the command line:
ps -aux | grep MacOS
This will produce output that looks something like this:
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
This output shows that the process ID for MacOS.app is 721 and the process ID for the grep command you just ran is 752. You must now kill the MacOS.app process by entering the following command (substitute the process ID of the MacOS.app process you are trying to kill for the process ID 721 as shown below):
kill -9 721
After killing the MacOS.app process in this way, you should be able to launch a new MacOS.app from the Workspace.
Tear Off Application Menu
The Mac OS Applications window that appears when the Applications menu is "torn off" does not list any Mac OS X Server applications that normally appear in the MacOS.app Applications menu. To switch from MacOS.app to another Mac OS X Server application, you must use the Applications menu and not the tear-off window.
AppleShare File Server connection lost using TCP/IP
When running MacOS.app using Mac OS System 8.5, there is a problem that may cause loss of connection to AppleShare File Servers that are connected via TCP/IP. The workaround for this problem is to connect to the server using the AppleTalk protocol instead. To do this, when selecting the File Server using the Chooser, hold down the Option key when you click on the OK button. This forces the system to connect via AppleTalk and not TCP/IP. This problem has been corrected in Mac OS System 8.6 which is the version that ships with MacOS.app.
Unable to read PC Zip disks
The present version of Mac OS X Server is unable to read PC Zip disks that have been formatted using the Iomega Tools. The problem does not occur if you initialize the Zip disk using MacOS.app by accessing the Zip drive using Exclusive mode and then initializing it by selecting the Finder's "Erase Disk" menu item.
Launching PowerPC Applications from Disks in Direct SCSI Mode
There is a problem that occasionally occurs when launching PowerPC Macintosh applications from disks accessed via direct SCSI mode. The problem causes MacOS.app to hang because of repeated timeouts attempting to access the disk. If you encounter this problem try changing the disk access to Exclusive mode. See the "Disk Access Modes" section for more details.
Symantec's ACT!
When running MacOS.app using Mac OS System 8.5, Symantec_s ACT! will not run properly in MacOS.app. This problem has been fixed in Mac OS System 8.6 which is the version that ships with this release of MacOS.app.
Eudora Pro 4.1
When running this version of Eudora Pro on MacOS.app, the application crashes because it is making a power manager call which is not implemented in MacOS.app. A future version of Eudora Pro will correct this problem.
MacBench 5.0
When running the MacBench 5.0 "all" test (with CD in), MacOS.app will crash when it arrives at the Microsoft Word formatting stage. This problem is currently under investigation and should be corrected in a future version of MacOS.app.
Myth II
When launching Myth II under MacOS.app you may receive an error dialog saying "Myth does not have enough free memory to launch. Try closing open applications or turning on VM". This message is incorrect; the actual problem is due to the Myth application attempting to perform a dynamic screen resolution change that is not supported in MacOS.app. In order to run Myth II under MacOS.app you must first change the screen resolution in Mac OS X Server to 640x480 using the Preferences.app application, then launch MacOS.app with the new screen resolution and Myth II will run correctly.
Switching from MacOS.app to Mac OS X Server
Switching from MacOS.app to Mac OS X Server using command-return is not allowed during startup of MacOS.app. Attempts to do so prior to the Finder starting up will be ignored.
Locked files not owned by current user
MacOS.app runs the MacOS in a multiuser environment. Native MacOS runs in a single user environment. In the Mac OS X Server environment a user must be the owner of a file in order to unlock it. If you try to move a locked file or delete a locked file, owned by someone else in the underlying file system, you will get an "access privileges" error. You can workaround this limitation in several ways. 1) use the chown command to change the owner of the file 2) shutdown MacOS.app and login to the system as the owner of the file, then start up MacOS.app again 3) do the move/rename in a terminal window as root or after doing a su to the owner of the file.
Disk Icons
Disks formatted with 3rd party utilities and utilizing 3rd party drivers may appear on the desktop with a different icon than they would under the native Mac OS. For example, a removable Zip or Jaz disk may appear on the desktop as a generic hard drive icon.
Disk First Aid
The version of Disk First Aid currently shipping will not function correctly when its target is a disk accessed via Shared mode. You can run the Mac OS X 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.
Desktop Rebuild For Shared Mode Volumes
Desktop rebuilds on some volumes mounted in shared mode may take longer than the same rebuilds in native MacOS. It is recommended that if you must rebuild your DesktopDB, you do it in native MacOS or in MacOS.app using Exclusive mode. In fact, a rebuild of the DesktopDB in shared mode does not actually delete the old DesktopDB files (although it appears from the progress dialog that it does), so repair of any damaged entries may not be as complete as would be the case in Exclusive mode or in Native Mac OS.
MacOS Crashes After Improper Shutdown
There is a problem that only happens when running with Mac OS System 8.5 or 8.5.1, in which MacOS.app crashes on startup after being improperly shut down. This is a side effect of putting up the "Your Macintosh was improperly shut down" dialog and will be fixed in a future release of Mac OS. The workaround to this problem is to uncheck the "Shut Down Warning" checkbox in the General Controls control panel. Note that if you do this, not only will there no longer be a warning dialog after crashes, but Disk First Aid will not be automatically run in such cases. You should run Disk First Aid to check the integrity of your file system after all improper shutdowns. There is a Mac OS X Server version of Disk First Aid (DiskFirstAid.app) that can be run on volumes shared with Mac OS X Server. In order for Disk First Aid in MacOS.app to run on a volume, it must be mounted in "Exclusive" mode (see the Disk Access Modes section). Or you can boot into native Mac OS and run Disk First Aid on the volume in question.
Runtime Performance
The runtime performance of MacOS.app is sensitive to other processes running on the Mac OS X Server, especially if these other processes consume the majority of "CPU" time. These types of processes are known as "CPU-bound" or "CPU-intensive" processes. The runtime performance of MacOS.app is highest when these types of processes are not running in Mac OS X Server.
File System Performance
In this release, Shared disk mode may be slower than other modes for some operations. If this is a concern, consider switching disk access modes or using disk images (which are always accessed in Exclusive mode). Disk access modes are discussed in detail in the "Disk Access Modes" section. Shared mode performance is expected to improve significantly in future releases.
NMI (Non-Maskable Interrupt)
On native Mac OS, using Command-Power to generate a NMI invokes the installed debugger (MacsBug) or invokes MicroBug if no debugger is installed. MicroBug is not currently supported in MacOS.app, so Command-Power with no debugger installed is ignored. When a debugger is installed, you may occasionally have to use Command-Power more than once to invoke the debugger. A current version of MacsBug is provided in the Apple Extras folder. Older versions are not compatible.
Mac OS X Server Workspace Logout
When logging out of Mac OS X Server with MacOS.app running, MacOS.app will come to the foreground with a dialog informing the user of the steps to safely shut down MacOS.app. The Workspace logout will be stopped. Upon shut down of MacOS.app, the user will again have to select Logout from the Workspace File menu. If MacOS.app was started from a shell window, it is not registered with the Mac OS X Server, so it will simply be killed during the logout process. This is why we don't recommend starting MacOS.app this way. Also note that if MacOS.app has gone through a restart since being launched by the Workspace, the process IDs for MacOS.app will have changed and the Workspace will not be able to contact it to initiate the safe shutdown dialog. This will also result in MacOS.app being killed during the logout process.
Sparse Virtual Memory
If Mac OS X Server runs out of disk space for virtual memory when MacOS.app is trying to allocate sparse virtual memory for an application, Mac OS will likely crash. This problem will be addressed in a future version of Mac OS X Server.
Aliases on Removable Disks
Mac OS has a limitation that sometimes causes aliases created on removable disks to fail when they are taken to a machine other than the one on which they were created. Because running MacOS.app is much like taking your disks created under native Mac OS and moving them to a different machine, this bug may manifest itself even though you did not physically move your disks to a different machine. This problem will be addressed in a future version of Mac OS.
Disk Copy Disk Images
Starting with Disk Copy version 6.3.3, it is possible to mount Disk Copy disk images from a Shared volume. However, it is not possible to create a disk image from an existing disk which is being accessed via Shared mode (i.e., using either of the "Create Image from Folder..." or "Create Image from Disk..." items in the "Image" menu of Disk Copy). If you are using an older version of Disk Copy to mount a disk image, or you are trying to create a disk image file from an existing disk, you will need to set that disk volume to be accessed via Exclusive mode. See the "Disk Access Modes" section for more information.
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
There are two kinds of "Disk Initialization": low-level formatting is device-specific and only need to be performed once for the life of the device, whereas high-level formatting simply writes an empty filesystem onto a device that already has a low-level format. The Finder's "Erase disk..." menu option usually only performs a high-level format, except for floppies, where it also causes a low-level format to be performed. The low-level formatting and partitioning of SCSI and ATA/IDE drives is performed by the Drive Setup application.
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
Read-only disk images can be shared via NFS by instances of MacOS.app running on different machines, but read/write images must not be shared or image corruption will result. Note that startup disk images (StartupDisk.img) are always read/write. In the future these rules will be enforced by MacOS.app when NFS advisory locking (rpc.lockd) is available in Mac OS X Server; but for now don't try it. The sharing of all volume types works fine via Personal File Sharing and AppleShare.
Floppy Disk Can Prevent Startup
Floppy drives have traditionally been treated specially in the Mac OS startup process; the Mac OS always looks for a bootable floppy before attempting to start up from the disk chosen via the Startup Disk control panel. Originally, this was done in order to make it possible to start up a Macintosh with a floppy in case of hard disk corruption. Consequently, the Mac OS attempts to eject any non-bootable floppy that it finds in the drive during startup. MacOS.app inherits this behavior, but, unlike the native Mac OS, can be prevented from doing so by Mac OS X Server applications that may have files open on the floppy, not allowing it to be ejected from the drive. If this happens, MacOS.app will be unable to start up. If you would like to share files from a floppy between Mac OS X Server applications and MacOS.app applications, you should insert the floppy after starting up MacOS.app. Alternatively, you could eject it before launching MacOS.app and reinsert it after MacOS.app has started up.
Removable Media - Insertion and Ejection
When inserted, HFS(+) disks may take longer to mount in the Finder if accessed in Exclusive mode rather than in Shared mode. The extra delay results from the fact that HFS(+) disks are automatically mounted by Mac OS X Server and then need to be unmounted on behalf of MacOS.app in preparation for being mounted in Exclusive mode. This extra step essentially doubles the time required to mount a disk and may be noticeable - especially with slow media like floppy disks.
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
The Mac OS X Server permissions model is enforced on volumes accessed in shared mode. The way permissions are enforced differs for HFS and HFS+ volumes, due to differences in their ability to store permission information. HFS volumes are unable to store permission information and therefore permissions have to be synthesized whenever they are needed. The permissions for the volume's mount point are used as the starting point for this synthesis (with appropriate differences for files versus folders). Moreover, when Mac OS X Server starts up, it mounts local volumes, setting the owner of these volumes to be root and the group to "macos". MacOS.app runs with an effective group id of "macos". By default, the macos group is set up to allow read/write access. Thus any user running MacOS.app will have access to all files and folders on HFS volumes mounted in shared mode.
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
The R1.1 version of Mac OS X Server supports UNIX symbolic links in the Workspace. However, MacOS.app does not understand symbolic links on volumes mounted in shared mode. When a symbolic link is seen by the Finder or any other application in MacOS.app, the underlying file system always resolves the link. This would be like always resolving a MacOS alias. This behavior is not normal in a MacOS environment, so you may run into unpredictable results if you try to use symbolic links on volumes that are accessed in shared mode. One symptom you may see is a folder that does not contain any items or fewer items than there should be. If you must use symbolic links on volumes accessed by MacOS.app in shared mode, you may want to place the links in a well known directory (a folder called "symlinks", for example). Alternatively, name the symbolic link so it appears at the end of directory when sorted by name (zMyLink, for example). This problem will be fixed in a future version of Mac OS X Server.
Sound Input /Output
When MacOS.app starts up, it uses Mac OS X Server's sound preferences to initially set volume, balance, and mute levels. Changes to these preferences in MacOS.app will also change Mac OS X Server's preferences. While MacOS.app is running, changes to Mac OS X Server sound preferences will not change MacOS.app sound preferences.
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
Video capture is not currently supported.
Special Hardware Support
Some applications that require special hardware support, such as the Apple Video Player, will not work correctly under the BlueBox. These applications fail during startup and incorrectly post dialogs suggesting they could work if extensions are added to the System Folder.
Using Localized Disk Images
When starting up on the localized disk images available with MacOS.app, the default keyboard setting while running in Mac OS may differ from the keyboard setting in the Workspace. In Mac OS, this can be changed using the Keyboard control panel. Refer to the "Using different languages" section of Mac OS Help - available from the Help menu in the Finder.
Copy and Paste Between Mac OS and Mac OS X Server
Applications are advised to always use the Scrap Manager to access the Scrap. Direct scrap access may not behave correctly.
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.
System Folder Pieces
Just as with any Mac OS system, when applications are installed, they sometimes install resources into the System Folder on the startup volume. If you later change the startup volume or System Folders, those applications which require resources located in the System Folder, may not work as desired. In order for these applications to run correctly, you must either run the installer or manually move the appropriate pieces to the startup volume System Folder.
Serial
Serial is not supported in this release of MacOS.app; applications attempting to open either port will receive a notInitErr (-900). A future release of MacOS.app will have serial support.
Printing
Because serial is not yet supported, attempting to print to a serial-attached printer will hang MacOS.app.
Mouse Acceleration
MacOS.app uses Mac OS X Server's cursor acceleration for its own, so use Mac OS X Server's mouse preferences to configure cursor acceleration for MacOS.app. The Mac OS Mouse control panel will have no affect on cursor acceleration.
Video
Switching between Mac OS X Server and Mac OS can only happen at SystemTask() time. If Mac OS is hung, running a game which doesn't call SystemTask() or WaitNextEvent(), or sitting in MacsBug, you can't switch. You can still use Command-Shift-Q to force MacOS.app to quit. If this does not work, then the Mac OS X Server part of MacOS.app is hung and you will have to either telnet in from another machine and kill the MacOS.app process, or do a hard reboot of Mac OS X Server.
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
Multiple monitors are now supported. MacOS.app does not support display repositioning (via the Monitors control panel). If you try it anyway, you will have problems. To undo your changes, remove the "Display Preferences" file from the Preferences folder in the System Folder, and restart MacOS.app.
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
Direct ADB access is not supported. Applications that read directly from ADB devices and expect mouse ADB events will not work.
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
To change the date, time, or time zone, use Mac OS X Server's Preferences.app, rather than the Mac OS Date & Time control panel. Changes to the date, time, or time zone using the Mac OS control panel will be ignored. Other features of this control panel, such as date and time formats and the menu bar clock, are fully supported.
Canceling the "Copying StartupDisk.img" Dialog
If the "Copying StartupDisk.img" dialog is cancelled when MacOS.app is not in the foreground (i.e., the dialog is front most, 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.
SCSI Based Printers
MacOS.app does not support printing to the LaserWriter SC, or any other SCSI-based printer that requires the LaserWriter SC 7.0.1 driver.
Apple Software
The Mac OS Setup Assistant will allow the user to configure a local (serial) printer. If you do this and attempt to print to this printer, Mac OS will hang (see "Printing", above).
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.6 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
MacBench 4.0 crashes since it attempts to access hardware that is not supported by MacOS.app. MacBench 3.0 works correctly and MacBench 5.0 works with the exception of the problem noted previously in the paragraph entitled MacBench 5.0.
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 or later, 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.