How To Use a File Created by an Apple Macintosh in Windows 2000, Windows NT, or Windows XP

This article was previously published under Q147438
This article has been archived. It is offered "as is" and will no longer be updated.
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.
Microsoft Windows 2000, Windows NT, or Windows XP 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 servers. Windows 2000, Windows NT, or Windows XPServer 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 server, SFM presents the files as though they were native to Macintoshcomputers. Likewise, when PC clients connect to the shared directory, theWindows server presents the files as though they were native to PCcomputers.

The file system used by the Macintosh Operating System is very differentfrom file systems supported by Windows 2000, Windows NT, or Windows XP. As a result, file naming conventions and the structure of files differ considerably between these two systems. This article shows how SFM and Windows work together to hide some of these details, and explains how Win32 applications can properly handle files native to Macintosh clients.
File Server for Macintosh (FSM), which is part of SFM, allows Windows andMacintosh clients to create and open files on the same share by presentingthe files to the clients with the naming conventions used by theiroperating systems. That is, regardless of which client actually created afile, it appears as a Macintosh file to Macintosh clients and a Windowsfile to Windows clients.

File Names

Some file names cannot be represented exactly when viewed by applicationsfrom both Macintosh and Windows systems because the Macintosh and Windowsoperating systems use different code pages to represent character stringsand different file naming conventions. File Server for Macintosh works withNTFS to preserve the file semantics used by both systems by translatingillegal characters in file names so that both Macintosh and Windows clientsmay access the same files.

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

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

When a Macintosh client gains access to a file created by a Windows clientand that file doesn't follow the Macintosh file-naming standards, FSM mapsthe invalid characters into the equivalent characters in the Macintosh codepage. The Macintosh client will then see the file with substitutedcharacters in its name.

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

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

File Structures

Windows platforms represent files differently from the Macintosh OperatingSystem. File Server for Macintosh handles these differences so thatMacintosh clients see files as though they were native to Macintoshcomputers, and Windows clients see them as being native to Windowsplatforms. This section explains how files are represented on bothoperating systems and how FSM handles them.

Windows platforms do not define the structure or interpretation of anyfile'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 theydon't have any higher-level organization. Win32 applications running onWindows can create files with multiple streams on NTFS volumes only.However, as a general rule, they should not create files with multiplestreams because they will be "flattened" when copied to volumes with theFAT file system.

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

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

As far as the Macintosh Operating System is concerned, the content of thedata fork is unstructured and is subject to interpretation by applications.The resource fork has a definite structure imposed by the MacintoshOperating System and is used for file management purposes. The followingdiagram shows how a file created by a Macintosh is structured:
            +--------File--------+            |                    |            V                    V       +------------+      +------------+       |            |      |            |       |    Data    |      |  Resource  |       |    Fork    |      |    Fork    |       |            |      |            |       +------------+      +------------+				
When a file created by a Macintosh is stored on a Windows server, it isstored in a single file that contains a stream for each fork. When Windows-based applications gain access to a file created by a Macintosh client,File Server for Macintosh presents only the data fork because the data forkis the equivalent of the representation of files on Windows platforms.Windows-based applications may not access the resource fork.

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

Design Recommendations for Win32 Applications

Some Win32-based applications running on a Windows server need to managefiles that were created by Macintosh clients. Although File Server forMacintosh presents files as each type of client expects to use them,applications that manage files must do so correctly to preserve the filenames and structure for Macintosh clients. This section presents the fourmost important design guidelines that you should follow to handle filesproperly.
  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 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 2000, Windows NT, or Windows XP 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 torepresent strings and their representation on the display (glyphs). BecauseWin32 and Macintosh systems use different code pages, some extended ASCIIcharacters on one system are not representable on screen in exactly thesame way on the other. For example, on the Macintosh, the glyph forcharacter code 0xBD is the Greek Omega character while in the Windows ANSIcode 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.)
Windows Platforms use two different file systems -- the Protected-Mode FileAllocation Table (FAT) file system and the New Technology File System(NTFS). These file systems have similar naming conventions, and differmainly in which characters are illegal. The naming conventions listed belowapply to both FAT and NTFS unless specifically noted.
  • 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.
"Inside Macintosh: Files," copyright 1992 Apple Computer, Inc.

"Services For Macintosh," Microsoft Windows NT Server productdocumentation.

"File Systems," Microsoft SDK overview.
3.51 3.50 4.00 SFM Mac fork

Article ID: 147438 - Last Review: 02/24/2014 08:24:10 - Revision: 4.2

  • Microsoft Win32 Application Programming Interface
  • kbnosurvey kbarchive kbhowto kbapi kbkernbase kb3rdparty kbfileio KB147438