How To Use a File Created by an Apple Macintosh in Windows NT

• Microsoft Win32 Application Programming Interface (API) included with Microsoft Windows NT, versions 3.5, 3.51, 4.0

NOTE: Some products mentioned in this article are manufactured by vendors independent of Microsoft; we make no warranty, implied or otherwise, regarding these products' performance or reliability.

SUMMARY

Windows NT Server has a set of services named "Services For Macintosh (SFM)" that allow Apple Macintosh computers to transparently gain access to shared files and printers that reside on Windows NT servers. Windows NT Server also allows PC clients to gain access to these same shared files and printers. When Macintosh clients connect to a shared directory on a Windows NT server, SFM presents the files as though they were native to Macintosh computers. Likewise, when PC clients connect to the shared directory, the Windows NT server presents the files as though they were native to PC computers.

The file system used by the Macintosh Operating System is very different from file systems supported by Windows NT. As a result, file naming conventions and the structure of files differ considerably between these two systems. This article shows how SFM and Windows NT work together to hide some of these details, and explains how Win32 applications can properly handle files native to Macintosh clients.

MORE INFORMATION

File Server for Macintosh (FSM), which is part of SFM, allows Windows and Macintosh clients to create and open files on the same share by presenting the files to the clients with the naming conventions used by their operating systems. That is, regardless of which client actually created a file, it appears as a Macintosh file to Macintosh clients and a Windows file to Windows clients.

File Names

Some file names cannot be represented exactly when viewed by applications from both Macintosh and Windows systems because the Macintosh and Windows operating systems use different code pages to represent character strings and different file naming conventions. File Server for Macintosh works with NTFS to preserve the file semantics used by both systems by translating illegal characters in file names so that both Macintosh and Windows clients may access the same files.

Regardless of which type of client creates a file, NTFS stores its file name on disk in UNICODE format. When a Macintosh client creates a file on a share, FSM translates characters in the file name that are invalid on NTFS into equivalent characters in the user-defined range of the UNICODE character set so that the file name is legal on NTFS.

When a Macintosh client uses a file that it or another Macintosh client created on an NTFS share, it will see the original name. File Server for Macintosh maps the characters on disk from the UNICODE user-defined range back into their original Macintosh-specific characters.

When a Macintosh client gains access to a file created by a Windows client and that file doesn't follow the Macintosh file-naming standards, FSM maps the invalid characters into the equivalent characters in the Macintosh code page. The Macintosh client will then see the file with substituted characters in its name.

UNICODE-enabled Win32 applications will see file names with characters in the user-defined space and can open them without a problem. Windows-based applications that use the ANSI character set will see a second mapping from the user-defined UNICODE characters to the ANSI default character -- the question mark (?). Because the question mark is also a wild-card character on Windows platforms, Windows applications that use the ANSI character set will not be able to open these files.

NTFS will automatically generate short file name equivalents for long file names created by both Macintosh and Win32 clients so that 16-bit Windows and MS-DOS clients can gain access to them. The rules for automatic short name generation are the same as Windows NT uses any time a long file name is created on disk.

File Structures

Windows platforms represent files differently from the Macintosh Operating System. File Server for Macintosh handles these differences so that Macintosh clients see files as though they were native to Macintosh computers, and Windows clients see them as being native to Windows platforms. This section explains how files are represented on both operating systems and how FSM handles them.

Windows platforms do not define the structure or interpretation of any file's content; applications can impose any structure on the content. Except for a very limited case, all files consist of a single stream (linear sequence) of bytes. These files are called "flat" because they don't have any higher-level organization. Win32 applications running on Windows NT can create files with multiple streams on NTFS volumes only. However, as a general rule, they should not create files with multiple streams because they will be "flattened" when copied to volumes with the FAT file system.

Because Win32 platforms can use different file systems, the maximum file size depends on which file system is used. Files on the Protected-Mode FAT file system may have a maximum size of 2 gigabytes (GB). On NTFS, the largest file can be 17 billion GB long (2 to the 64th power bytes). Only Win32 applications running on Windows NT can access the full range of files larger than 2 GB.

The Macintosh Operating System uses files consisting of two linear sequences of bytes known as forks. The data fork is used to store the file's data and corresponds to a file created by a Win32 platform. The resource fork is used to store information about the file, such as its icon or the fonts used in it. Every file has both forks, but either or both may be empty.

As far as the Macintosh Operating System is concerned, the content of the data fork is unstructured and is subject to interpretation by applications. The resource fork has a definite structure imposed by the Macintosh Operating System and is used for file management purposes. The following diagram shows how a file created by a Macintosh is structured:

            +--------File--------+
            |                    |
            V                    V
       +------------+      +------------+
       |            |      |            |
       |    Data    |      |  Resource  |
       |    Fork    |      |    Fork    |
       |            |      |            |
       +------------+      +------------+

The Macintosh Operating System allows files and volumes to be as large as 2 GB.

Design Recommendations for Win32 Applications

Some Win32-based applications running on a Windows NT server need to manage files that were created by Macintosh clients. Although File Server for Macintosh presents files as each type of client expects to use them, applications that manage files must do so correctly to preserve the file names and structure for Macintosh clients. This section presents the four most important design guidelines that you should follow to handle files properly.

1. Handle file names with UNICODE strings. This can be done either by making the application completely UNICODE-enabled or by explicitly calling the UNICODE versions of the file APIs. (UNICODE APIs end with a "W" as in CopyFileW.)

   Win32 applications that use file names of files created by Macintosh clients must use UNICODE strings to prevent problems in translating characters that are unique to the Macintosh. Because file names are stored on disk in UNICODE, when a UNICODE application uses them, the file name the application sees is identical to that stored on the disk. The application can find, copy, or move the file without forcing its name to be translated.

   Non-UNICODE Windows-based applications that retrieve and then store files by name (example operations include find, copy, and move) will force file names to be translated from UNICODE to ANSI and then back to UNICODE. During the first part of the translation, characters in the UNICODE user-defined space are mapped to their nearest equivalents in the ANSI code page. In the second part, the ANSI characters are written back out to disk. This process results in a file name that may not exactly match the original because the ANSI characters written are the results of the mapping, not the original characters.

2. Don't copy files created by Macintosh clients to volumes that have the FAT file system. The FAT file system does not support multiple streams, so the file will be flattened; that is, its resource fork will be lost.

3. Don't copy or rename files created by Macintosh clients from Windows 95, Win32s, or Windows 3.x clients. When these clients connect to the Windows NT server through a redirected drive letter or UNC name, they gain access to shared files through the clients' disk I/O systems. The problem with these clients is that their disk I/O systems do not support multiple file streams, so the files they save will be flattened, as described in guideline 2.

   To allow Windows 95, Win32s, and Windows 3.x clients to gain access to files created by Macintosh clients, the server should provide an RPC server or service to handle requests. The RPC server or service should then use the UNICODE file APIs as described in guideline 1.

4. Ensure that Win32-based applications running under Windows NT do not create files larger than 2 GB because Macintosh clients won't be able to use them.

File Name Reference

A code page is a mapping of the numerical bytes (character codes) used to represent strings and their representation on the display (glyphs). Because Win32 and Macintosh systems use different code pages, some extended ASCII characters on one system are not representable on screen in exactly the same way on the other. For example, on the Macintosh, the glyph for character code 0xBD is the Greek Omega character while in the Windows ANSI code page, it is character symbol for "1/2."

The Macintosh Operating System uses the following file naming conventions:

• File and folder (directory) names may be up to 31 characters long; full pathnames are not limited to 260 characters (as they are on Win32 platforms).
• The colon (:) is used as a path separator.
• File and folder names may use any characters except the colon, which is the path separator. Characters such as ?, *, \, and / are perfectly legal in Macintosh file names.
• Although the Macintosh Operating System preserves the case of all file names, it does not distinguish between file names by case. (That is, file and folder names are not case-sensitive.)

• File and directory names may be up to 255 characters long on FAT file systems and 256 characters on NTFS. Full pathnames may be up to 260 characters long.
• The backslash (\) is the path separator.
• File and directory names on the Protected-Mode FAT file system may consist of letters, digits, spaces, and these characters:

  $%'-_@~`!{}()#&+,;=[].

  Note that periods are allowed in file and directory names, as long as they are accompanied by other characters. For example, .text is perfectly legal.

  On NTFS, file and directory names may consist of any character except the following characters:

  "/\*?<>|:

• Although file and directory names are not case-sensitive, their case is preserved.

REFERENCES

"Inside Macintosh: Files," copyright 1992 Apple Computer, Inc.

"Services For Macintosh," Microsoft Windows NT Server product documentation, copyright 1985-1994 Microsoft Corporation.

"File Systems," Microsoft Win32 SDK overview, copyright 1985-1986 Microsoft Corporation.