RFC1740 日本語訳
1740 MIME Encapsulation of Macintosh Files - MacMIME. P. Faltstrom, D.Crocker, E. Fair. December 1994. (Format: TXT=31297 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Patrik Faltstrom
Request for Comments: 1740 Royal Institute of Technology
Category: Standards Track Dave Crocker
Brandenburg Consulting
Erik E. Fair
Apple Computer Inc.
December 1994
Network Working Group Patrik Faltstrom Request for Comments: 1740 Royal Institute of Technology Category: Standards Track Dave Crocker Brandenburg Consulting Erik E. Fair Apple Computer Inc. December 1994
MIME Encapsulation of Macintosh files - MacMIME
MIME Encapsulation of Macintosh files - MacMIME
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
Abstract
This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non- Macintosh systems access to data in standardized formats.
This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non- Macintosh systems access to data in standardized formats.
2. Introduction
2. Introduction
Files on the Macintosh consists of two parts, called forks:
Files on the Macintosh consists of two parts, called forks:
Data fork: The actual data included in the file. The Data
fork is typically the only meaningful part of a
Macintosh file on a non-Macintosh computer system.
For example, if a Macintosh user wants to send a
file of data to a user on an IBM-PC, she would only
send the Data fork.
Data fork: The actual data included in the file. The Data fork is typically the only meaningful part of a Macintosh file on a non-Macintosh computer system. For example, if a Macintosh user wants to send a file of data to a user on an IBM-PC, she would only send the Data fork.
Resource fork: Contains a collection of arbitrary attribute/value
pairs, including program segments, icon bitmaps,
and parametric values.
Resource fork: Contains a collection of arbitrary attribute/value pairs, including program segments, icon bitmaps, and parametric values.
Additional information regarding Macintosh files is stored by the Finder in a hidden file, called the "Desktop Database".
Additional information regarding Macintosh files is stored by the Finder in a hidden file, called the "Desktop Database".
Because of the complications in storing different parts of a Macintosh file in a non-Macintosh filesystem that only handles consecutive data in one part, it is common to convert the Macintosh file into some other format before transferring it over the network.
Because of the complications in storing different parts of a Macintosh file in a non-Macintosh filesystem that only handles consecutive data in one part, it is common to convert the Macintosh file into some other format before transferring it over the network.
Faltstrom, Crocker & Fair [Page 1] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 1] RFC 1740 MIME-based Mac files December 1994
The two styles of use are [APPL90]:
The two styles of use are [APPL90]:
AppleSingle: Apple's standard format for encoding Macintosh files
as one byte stream.
AppleDouble: Similar to AppleSingle except that the Data fork is
separated from the Macintosh-specific parts by the
AppleDouble encoding.
AppleSingle: Apple's standard format for encoding Macintosh files as one byte stream. AppleDouble: Similar to AppleSingle except that the Data fork is separated from the Macintosh-specific parts by the AppleDouble encoding.
AppleDouble is the preferred format for a Macintosh file that is to be included in an Internet mail message, because it provides recipients with Macintosh computers the entire document, including Icons and other Macintosh specific information, while other users easily can extract the Data fork (the actual data) as it is separated from the AppleDouble encoding.
AppleDouble is the preferred format for a Macintosh file that is to be included in an Internet mail message, because it provides recipients with Macintosh computers the entire document, including Icons and other Macintosh specific information, while other users easily can extract the Data fork (the actual data) as it is separated from the AppleDouble encoding.
2. MIME format for Apple/Macintosh-specific file information
2. MIME format for Apple/Macintosh-specific file information
2a. APPLICATION/APPLEFILE
2a. APPLICATION/APPLEFILE
MIME type-name: APPLICATION
MIME subtype name: APPLEFILE
Required parameters: none
Optional parameters: NAME, which must be a "value" as
defined in RFC-1521 [BORE93].
Encoding considerations: The presence of binary data will
typically require use of
Content-Transfer-Encoding: BASE64
Security considerations: See separate section in the document
Published specification: Apple-single & Apple-double [APPL90]
Rationale: Permits MIME-based transmission of
data with Apple/Macintosh specific
information, while allowing general
access to non-specific user data.
MIME type-name: APPLICATION MIME subtype name: APPLEFILE Required parameters: none Optional parameters: NAME, which must be a "value" as defined in RFC-1521 [BORE93]. Encoding considerations: The presence of binary data will typically require use of Content-Transfer-Encoding: BASE64 Security considerations: See separate section in the document Published specification: Apple-single & Apple-double [APPL90] Rationale: Permits MIME-based transmission of data with Apple/Macintosh specific information, while allowing general access to non-specific user data.
2b. MULTIPART/APPLEDOUBLE
2b. MULTIPART/APPLEDOUBLE
MIME type-name: MULTIPART
MIME subtype name: APPLEDOUBLE
Required parameters: none
Optional parameters: NAME, which must be a "value" as
defined in RFC-1521 [BORE93].
Encoding considerations: none
Security considerations: See separate section in the document
Published specification: Apple-single & Apple-double [APPL90]
Rationale: Permits MIME-based transmission of
data with Apple/Macintosh specific
information, while allowing general
access to non-specific user data.
MIME type-name: MULTIPART MIME subtype name: APPLEDOUBLE Required parameters: none Optional parameters: NAME, which must be a "value" as defined in RFC-1521 [BORE93]. Encoding considerations: none Security considerations: See separate section in the document Published specification: Apple-single & Apple-double [APPL90] Rationale: Permits MIME-based transmission of data with Apple/Macintosh specific information, while allowing general access to non-specific user data.
Faltstrom, Crocker & Fair [Page 2] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 2] RFC 1740 MIME-based Mac files December 1994
2c. Detail specific to MIME-based usage
2c. Detail specific to MIME-based usage
Macintosh documents do not always need to be sent in a special
format. Those documents with well-known MIME types and
non-existent or trivial resource forks can be sent as regular
MIME body parts, without use of AppleSingle or AppleDouble.
Macintosh documents do not always need to be sent in a special format. Those documents with well-known MIME types and non-existent or trivial resource forks can be sent as regular MIME body parts, without use of AppleSingle or AppleDouble.
Documents which lack a data fork must be sent as AppleSingle.
Documents which lack a data fork must be sent as AppleSingle.
Unless there are strong reasons not to, all other documents
should normally be sent as AppleDouble. This includes documents
with non-trivial resource forks, and documents without
corresponding well-known MIME types.
Unless there are strong reasons not to, all other documents should normally be sent as AppleDouble. This includes documents with non-trivial resource forks, and documents without corresponding well-known MIME types.
It may be valuable in some cases to allow the user to choose one
format over another, either because he disagrees with the
implementor's definition of "trivial" resource forks, or for
reasons of his own.
It may be valuable in some cases to allow the user to choose one format over another, either because he disagrees with the implementor's definition of "trivial" resource forks, or for reasons of his own.
3. AppleSingle
3. AppleSingle
An AppleSingle, version 2 file, is sent as one consecutive stream of bytes. The format is described in [APPL90] with a brief summary in Appendix A. The one and only part of the file is sent in an application/applefile message.
An AppleSingle, version 2 file, is sent as one consecutive stream of bytes. The format is described in [APPL90] with a brief summary in Appendix A. The one and only part of the file is sent in an application/applefile message.
The first four bytes of an AppleSingle header are, in hexadecimal: 00, 05, 16, 00.
The first four bytes of an AppleSingle header are, in hexadecimal: 00, 05, 16, 00.
The AppleSingle file is binary data. Hence, it may be necessary to perform a Content-Transfer-Encoding for transmission, depending on the underlying email transport environment. The safest encoding is Base64, since it permits transfer over the most restricted channels.
The AppleSingle file is binary data. Hence, it may be necessary to perform a Content-Transfer-Encoding for transmission, depending on the underlying email transport environment. The safest encoding is Base64, since it permits transfer over the most restricted channels.
Even though an AppleSingle file includes the original Macintosh
filename, it is recommended that a name parameter be included on the
Content-Type header to give the recipient a hint as to what file is
attached. The value of the name parameter must be a "value" as
defined by RFC-1521 [BORE93]. Note that this restricts the value to
seven-bit US-ASCII characters.
Even though an AppleSingle file includes the original Macintosh filename, it is recommended that a name parameter be included on the Content-Type header to give the recipient a hint as to what file is attached. The value of the name parameter must be a "value" as defined by RFC-1521 [BORE93]. Note that this restricts the value to seven-bit US-ASCII characters.
3a. AppleSingle example
3a. AppleSingle example
Content-Type: application/applefile; name="Computers-1/2-93"
Content-Type: application/applefile; name="Computers-1/2-93"
[The AppleSingle file goes here]
[The AppleSingle file goes here]
4. AppleDouble
4. AppleDouble
Faltstrom, Crocker & Fair [Page 3] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 3] RFC 1740 MIME-based Mac files December 1994
An AppleDouble, version 2, file is divided in two parts:
An AppleDouble, version 2, file is divided in two parts:
Header: including the Macintosh resource fork and desktop
information and
Data fork: containing the Macintosh data fork.
Header: including the Macintosh resource fork and desktop information and Data fork: containing the Macintosh data fork.
The AppleDouble format is described in [APPL90] with a brief summary in Appendix B.
The AppleDouble format is described in [APPL90] with a brief summary in Appendix B.
The AppleDouble file itself is sent as a multipart/appledouble MIME body-part, which may have only two sub-parts. The header is sent as application/applefile and the data fork as whatever best describes it. For example, is the data for is actually a GIF image, it should be sent as image/gif. If no appropriate Content-Type has been registered for the data type, it should be sent as an application/octet-stream.
The AppleDouble file itself is sent as a multipart/appledouble MIME body-part, which may have only two sub-parts. The header is sent as application/applefile and the data fork as whatever best describes it. For example, is the data for is actually a GIF image, it should be sent as image/gif. If no appropriate Content-Type has been registered for the data type, it should be sent as an application/octet-stream.
The first four bytes of an AppleDouble header are, in hexadecimal: 00, 05, 16, 07.
The first four bytes of an AppleDouble header are, in hexadecimal: 00, 05, 16, 07.
The AppleDouble header is binary data. Hence, it may be necessary to perform a Content-Transfer-Encoding for transmission, depending on the underlying email transport environment. The safest encoding is Base64, since it permits transfer over the most restrictive channels.
The AppleDouble header is binary data. Hence, it may be necessary to perform a Content-Transfer-Encoding for transmission, depending on the underlying email transport environment. The safest encoding is Base64, since it permits transfer over the most restrictive channels.
Even though an AppleDouble file includes the original Macintosh filename, it is recommended that a name parameter be included on the Content-Type header of both the header and data parts of the AppleDouble file to give the recipient a hint as to what file is attached. The value of the name parameter must be a "value" as defined by RFC-1521 [BORE93]. Note that this restricts the value to seven-bit US-ASCII characters.
Even though an AppleDouble file includes the original Macintosh filename, it is recommended that a name parameter be included on the Content-Type header of both the header and data parts of the AppleDouble file to give the recipient a hint as to what file is attached. The value of the name parameter must be a "value" as defined by RFC-1521 [BORE93]. Note that this restricts the value to seven-bit US-ASCII characters.
4a. AppleDouble example
4a. AppleDouble example
Content-Type: multipart/appledouble; boundary=mac-part
Content-Type: multipart/appledouble; boundary=mac-part
--mac-part
Content-Type: application/applefile; name="My-new-car"
--mac-part Content-Type: application/applefile; name="My-new-car"
[The AppleDouble header goes here]
[The AppleDouble header goes here]
--mac-part
Content-Type: image/gif;
--mac-part Content-Type: image/gif;
[The data fork goes here]
[The data fork goes here]
--mac-part--
--mac-part--
Faltstrom, Crocker & Fair [Page 4] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 4] RFC 1740 MIME-based Mac files December 1994
5. References
5. References
BORE93 Borenstein N., and N. Freed, MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies, RFC 1521, Bellcore,
Innosoft, September 1993.
BORE93 Borenstein N., and N. Freed, MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1521, Bellcore, Innosoft, September 1993.
APPL90 AppleSingle/AppleDouble Formats for Foreign Files
Developer's Note, Apple Computer, Inc., 1990
APPL90 AppleSingle/AppleDouble Formats for Foreign Files Developer's Note, Apple Computer, Inc., 1990
6. Security Considerations
6. Security Considerations
To the extent that application/applefile facilitates the transmission of operating-system sensitive data, it may open a door for easier relaxation of security rules than is intended either by the sender of the administrator of the sender's system.
To the extent that application/applefile facilitates the transmission of operating-system sensitive data, it may open a door for easier relaxation of security rules than is intended either by the sender of the administrator of the sender's system.
7. Acknowledgements
7. Acknowledgements
Thanks to all of the people on the ietf-822 list who have provided much meaningful input for this document. Some of them must though be remembered by name, because they have almost crushed my mailbox with a very nice and interesting debate:
Thanks to all of the people on the ietf-822 list who have provided much meaningful input for this document. Some of them must though be remembered by name, because they have almost crushed my mailbox with a very nice and interesting debate:
Johan Berglund, Steve Dorner, David Gelhar, David Herron, Lee
Jones, Raymond Lau, Jamey Maze, John B. Melby, Jan Michael
Rynning, Rens Troost and Peter Svanberg.
Johan Berglund, Steve Dorner, David Gelhar, David Herron, Lee Jones, Raymond Lau, Jamey Maze, John B. Melby, Jan Michael Rynning, Rens Troost and Peter Svanberg.
10. Authors' Addresses
10. Authors' Addresses
Patrik Faltstrom Department of Numerical Analysis and Computing Science Royal Institute of Technology S-100 44 Stockholm Sweden
Patrik Faltstrom Department of Numerical Analysis and Computing Science Royal Institute of Technology S-100 44 Stockholm Sweden
EMail: paf@nada.kth.se
EMail: paf@nada.kth.se
Dave Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086
Dave Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086
EMail: dcrocker@mordor.stanford.edu
EMail: dcrocker@mordor.stanford.edu
Erik E. Fair
Erik E. Fair
Faltstrom, Crocker & Fair [Page 5] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 5] RFC 1740 MIME-based Mac files December 1994
Engineering Computer Operations Apple Computer Inc.
Engineering Computer Operations Apple Computer Inc.
EMail: fair@apple.com
EMail: fair@apple.com
Faltstrom, Crocker & Fair [Page 6] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 6] RFC 1740 MIME-based Mac files December 1994
Appendix A. The AppleSingle format
Appendix A. The AppleSingle format
In the AppleSingle format, a file's contents and attributes are stored in a single file in the foreign file system. For example, both forks of a Macintosh file, the Finder information, and an associated comment are arranged in a single file with a simple structure.
In the AppleSingle format, a file's contents and attributes are stored in a single file in the foreign file system. For example, both forks of a Macintosh file, the Finder information, and an associated comment are arranged in a single file with a simple structure.
An AppleSingle file consists of a header followed by one or more data entries. The header consists of several fixed fields and a list of entry descriptors, each pointing to a data entry. Each entry is optional and may or may not appear in the file.
An AppleSingle file consists of a header followed by one or more data entries. The header consists of several fixed fields and a list of entry descriptors, each pointing to a data entry. Each entry is optional and may or may not appear in the file.
AppleSingle file header:
AppleSingle file header:
Field Length
Field Length
Magic number 4 bytes Version number 4 bytes Filler 16 bytes Number of entries 2 bytes
Magic number 4 bytes Version number 4 bytes Filler 16 bytes Number of entries 2 bytes
Entry descriptor for each entry:
Entry descriptor for each entry:
Entry ID 4 bytes Offset 4 bytes Length 4 bytes
Entry ID 4 bytes Offset 4 bytes Length 4 bytes
Byte ordering in the file fields follows MC68000 conventions, most significant byte first. The fields in the header file follow the conventions described in the following sections.
Byte ordering in the file fields follows MC68000 conventions, most significant byte first. The fields in the header file follow the conventions described in the following sections.
Magic number
This field, modelled after the UNIX magic number feature,
specifies the file's format. Apple has defined the magic number
for the AppleSingle format as $00051600 or 0x00051600.
Magic number This field, modelled after the UNIX magic number feature, specifies the file's format. Apple has defined the magic number for the AppleSingle format as $00051600 or 0x00051600.
Version number
This field denotes the version of AppleSingle format in the event
the format evolves (more fields may be added to the header). The
version described in this note is version $00020000 or
0x00020000.
Version number This field denotes the version of AppleSingle format in the event the format evolves (more fields may be added to the header). The version described in this note is version $00020000 or 0x00020000.
Filler
This field is all zeros ($00 or 0x00).
Filler This field is all zeros ($00 or 0x00).
Number of entries
This field specifies how many different entries are included in
Number of entries This field specifies how many different entries are included in
Faltstrom, Crocker & Fair [Page 7] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 7] RFC 1740 MIME-based Mac files December 1994
the file. It is an unsigned 16-bit number. If the number of
entries is any number other than 0, then that number of entry
descriptors immediately follows the number of entries field.
the file. It is an unsigned 16-bit number. If the number of entries is any number other than 0, then that number of entry descriptors immediately follows the number of entries field.
Entry descriptors
Entry descriptors
The entry descriptor is made up of the following three fields:
The entry descriptor is made up of the following three fields:
Entry ID: an unsigned 32-bit number, defines what the entry is.
Entry IDs range from 1 to $FFFFFFFF. Entry ID 0 is
invalid.
Offset: an unsigned 32-bit number, shows the offset from the
beginning of the file to the beginning of the entry's
data.
Length: an unsigned 32-bit number, shows the length of the
data in bytes. The length can be 0.
Entry ID: an unsigned 32-bit number, defines what the entry is. Entry IDs range from 1 to $FFFFFFFF. Entry ID 0 is invalid. Offset: an unsigned 32-bit number, shows the offset from the beginning of the file to the beginning of the entry's data. Length: an unsigned 32-bit number, shows the length of the data in bytes. The length can be 0.
Predefined entry ID's
Predefined entry ID's
Apple has defined a set of entry IDs and their values as follows:
Apple has defined a set of entry IDs and their values as follows:
Data Fork 1 Data fork
Resource Fork 2 Resource fork
Real Name 3 File's name as created on home file
system
Comment 4 Standard Macintosh comment
Icon, B&W 5 Standard Macintosh black and white icon
Icon, Colour 6 Macintosh colour icon
File Dates Info 8 File creation date, modification date,
and so on
Finder Info 9 Standard Macintosh Finder information
Macintosh File Info 10 Macintosh file information, attributes
and so on
ProDOS File Info 11 ProDOS file information, attributes and
so on
MS-DOS File Info 12 MS-DOS file information, attributes and
so on
Short Name 13 AFP short name
AFP File Info 14 AFP file, information, attributes and so
on
Directory ID 15 AFP directory ID
Data Fork 1 Data fork Resource Fork 2 Resource fork Real Name 3 File's name as created on home file system Comment 4 Standard Macintosh comment Icon, B&W 5 Standard Macintosh black and white icon Icon, Colour 6 Macintosh colour icon File Dates Info 8 File creation date, modification date, and so on Finder Info 9 Standard Macintosh Finder information Macintosh File Info 10 Macintosh file information, attributes and so on ProDOS File Info 11 ProDOS file information, attributes and so on MS-DOS File Info 12 MS-DOS file information, attributes and so on Short Name 13 AFP short name AFP File Info 14 AFP file, information, attributes and so on Directory ID 15 AFP directory ID
Apple reserves the range of entry IDs from 1 to $7FFFFFFF. The
rest of the range is available for applications to define their
own entries. Apple does not arbitrate the use of the rest of the
range.
Apple reserves the range of entry IDs from 1 to $7FFFFFFF. The rest of the range is available for applications to define their own entries. Apple does not arbitrate the use of the rest of the range.
Appendix B. The AppleDouble format
Appendix B. The AppleDouble format
Faltstrom, Crocker & Fair [Page 8] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 8] RFC 1740 MIME-based Mac files December 1994
The AppleDouble format uses two files to store data, resources and attributes. The AppleDouble Data file contains the data fork and the AppleDouble Header file contains the resource fork.
The AppleDouble format uses two files to store data, resources and attributes. The AppleDouble Data file contains the data fork and the AppleDouble Header file contains the resource fork.
The AppleDouble Data file contains the standard Macintosh data fork with no additional header. The AppleDouble Header file has exactly the same format as the AppleSingle file, except that it does not contain a Data fork entry. The magic number in the AppleDouble Header file differs from the magic number in the AppleSingle Header file so that an application can tell whether it needs to look in another file for the data fork. The magic number for the AppleDouble format is $00051607 or 0x00051607.
The AppleDouble Data file contains the standard Macintosh data fork with no additional header. The AppleDouble Header file has exactly the same format as the AppleSingle file, except that it does not contain a Data fork entry. The magic number in the AppleDouble Header file differs from the magic number in the AppleSingle Header file so that an application can tell whether it needs to look in another file for the data fork. The magic number for the AppleDouble format is $00051607 or 0x00051607.
The entries in the AppleDouble Header file can appear in any order; however, since the resource fork is the entry that is most commonly extended (after the data fork), Apple recommends that the resource fork entry to be placed last in the file. The data fork is easily extended because it resides by itself in the AppleDouble Data file.
The entries in the AppleDouble Header file can appear in any order; however, since the resource fork is the entry that is most commonly extended (after the data fork), Apple recommends that the resource fork entry to be placed last in the file. The data fork is easily extended because it resides by itself in the AppleDouble Data file.
Appendix C. applefile.h
Appendix C. applefile.h
This is an example of a header file for the language C which can be used when parsing the data in either an AppleSingle file or AppleDouble header.
This is an example of a header file for the language C which can be used when parsing the data in either an AppleSingle file or AppleDouble header.
The file is written by Lee Jones. Distribution is unlimited.
The file is written by Lee Jones. Distribution is unlimited.
/* applefile.h - Data structures used by AppleSingle/AppleDouble
* file format
*
* Written by Lee Jones, 22-Oct-1993
*
* For definitive information, see "AppleSingle/AppleDouble
* Formats for Foreign Files Developer's Note"; Apple Computer
* Inc.; (c) 1990.
*
* Other details were added from:
* Inside Macintosh [old version], volumes II to VI,
* Apple include files supplied with Think C 5.0.1,
* Microsoft MS-DOS Programmer's Reference, version 5, and
* Microsoft C 6.00a's dos.h include file.
*
* I don't have ProDOS or AFP Server documentation so related
* entries may be a bit skimpy.
*
* Edit history:
*
* when who why
/* applefile.h - Data structures used by AppleSingle/AppleDouble * file format * * Written by Lee Jones, 22-Oct-1993 * * For definitive information, see "AppleSingle/AppleDouble * Formats for Foreign Files Developer's Note"; Apple Computer * Inc.; (c) 1990. * * Other details were added from: * Inside Macintosh [old version], volumes II to VI, * Apple include files supplied with Think C 5.0.1, * Microsoft MS-DOS Programmer's Reference, version 5, and * Microsoft C 6.00a's dos.h include file. * * I don't have ProDOS or AFP Server documentation so related * entries may be a bit skimpy. * * Edit history: * * when who why
Faltstrom, Crocker & Fair [Page 9] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 9] RFC 1740 MIME-based Mac files December 1994
* --------- --- ------------------------------------------
* 22-Oct-93 LMJ Pull together from Inside Macintosh,
* Developer's Note, etc
* 26-Oct-93 LMJ Finish writing first version and list
* references
* 06-Feb-94 EEF Very minor cleanup
*/
* --------- --- ------------------------------------------ * 22-Oct-93 LMJ Pull together from Inside Macintosh, * Developer's Note, etc * 26-Oct-93 LMJ Finish writing first version and list * references * 06-Feb-94 EEF Very minor cleanup */
/* Following items define machine specific size (for porting). */
/* Following items define machine specific size (for porting). */
typedef char xchar8; /* 8-bit field */ typedef char schar8; /* signed 8-bit field */ typedef unsigned char uchar8; /* unsigned 8-bit field */ typedef short xint16; /* 16-bit field */ typedef unsigned short uint16; /* unsigned 16-bit field */ typedef long xint32; /* 32-bit field */ typedef long sint32; /* signed 32-bit field */ typedef unsigned long uint32; /* unsigned 32-bit field */
typedef char xchar8; /* 8-bit field */ typedef char schar8; /* signed 8-bit field */ typedef unsigned char uchar8; /* unsigned 8-bit field */ typedef short xint16; /* 16-bit field */ typedef unsigned short uint16; /* unsigned 16-bit field */ typedef long xint32; /* 32-bit field */ typedef long sint32; /* signed 32-bit field */ typedef unsigned long uint32; /* unsigned 32-bit field */
/* REMINDER: the Motorola 680x0 is a big-endian architecture! */
/* REMINDER: the Motorola 680x0 is a big-endian architecture! */
typedef uint32 OSType; /* 32 bit field */
typedef uint32 OSType; /* 32 bit field */
/* In the QuickDraw coordinate plane, each coordinate is
* -32767..32767. Each point is at the intersection of a
* horizontal grid line and a vertical grid line. Horizontal
* coordinates increase from left to right. Vertical
* coordinates increase from top to bottom. This is the way
* both a TV screen and page of English text are scanned:
* from top left to bottom right.
*/
/* In the QuickDraw coordinate plane, each coordinate is * -32767..32767. Each point is at the intersection of a * horizontal grid line and a vertical grid line. Horizontal * coordinates increase from left to right. Vertical * coordinates increase from top to bottom. This is the way * both a TV screen and page of English text are scanned: * from top left to bottom right. */
struct Point /* spot in QuickDraw 2-D grid */
{
xint16 v; /* vertical coordinate */
xint16 h; /* horizontal coordinate */
}; /* Point */
struct Point /* spot in QuickDraw 2-D grid */ { xint16 v; /* vertical coordinate */ xint16 h; /* horizontal coordinate */ }; /* Point */
typedef struct Point Point;
typedef struct Point Point;
/* See older Inside Macintosh, Volume II page 84 or Volume IV
* page 104.
*/
/* See older Inside Macintosh, Volume II page 84 or Volume IV * page 104. */
struct FInfo /* Finder information */
{
OSType fdType; /* File type, 4 ASCII chars */
OSType fdCreator; /* File's creator, 4 ASCII chars */
struct FInfo /* Finder information */ { OSType fdType; /* File type, 4 ASCII chars */ OSType fdCreator; /* File's creator, 4 ASCII chars */
Faltstrom, Crocker & Fair [Page 10] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 10] RFC 1740 MIME-based Mac files December 1994
uint16 fdFlags; /* Finder flag bits */
Point fdLocation; /* file's location in folder */
xint16 fdFldr; /* file 's folder (aka window) */
}; /* FInfo */
uint16 fdFlags; /* Finder flag bits */ Point fdLocation; /* file's location in folder */ xint16 fdFldr; /* file 's folder (aka window) */ }; /* FInfo */
typedef struct FInfo FInfo;
typedef struct FInfo FInfo;
/*
* Masks for finder flag bits (field fdFlags in struct
* FInfo).
*/
/* * Masks for finder flag bits (field fdFlags in struct * FInfo). */
#define F_fOnDesk 0x0001 /* file is on desktop (HFS only) */ #define F_maskColor 0x000E /* color coding (3 bits) */ /* 0x0010 /* reserved (System 7) */ #define F_fSwitchLaunch 0x0020 /* reserved (System 7) */ #define F_fShared 0x0040 /* appl available to multiple users */ #define F_fNoINITs 0x0080 /* file contains no INIT resources */ #define F_fBeenInited 0x0100 /* Finder has loaded bundle res. */ /* 0x0200 /* reserved (System 7) */ #define F_fCustomIcom 0x0400 /* file contains custom icon */ #define F_fStationary 0x0800 /* file is a stationary pad */ #define F_fNameLocked 0x1000 /* file can't be renamed by Finder */ #define F_fHasBundle 0x2000 /* file has a bundle */ #define F_fInvisible 0x4000 /* file's icon is invisible */ #define F_fAlias 0x8000 /* file is an alias file (System 7) */
#define F_fOnDesk 0x0001 /* file is on desktop (HFS only) */ #define F_maskColor 0x000E /* color coding (3 bits) */ /* 0x0010 /* reserved (System 7) */ #define F_fSwitchLaunch 0x0020 /* reserved (System 7) */ #define F_fShared 0x0040 /* appl available to multiple users */ #define F_fNoINITs 0x0080 /* file contains no INIT resources */ #define F_fBeenInited 0x0100 /* Finder has loaded bundle res. */ /* 0x0200 /* reserved (System 7) */ #define F_fCustomIcom 0x0400 /* file contains custom icon */ #define F_fStationary 0x0800 /* file is a stationary pad */ #define F_fNameLocked 0x1000 /* file can't be renamed by Finder */ #define F_fHasBundle 0x2000 /* file has a bundle */ #define F_fInvisible 0x4000 /* file's icon is invisible */ #define F_fAlias 0x8000 /* file is an alias file (System 7) */
/* See older Inside Macintosh, Volume IV, page 105.
*/
/* See older Inside Macintosh, Volume IV, page 105. */
struct FXInfo /* Extended finder information */
struct FXInfo /* Extended finder information */
{
xint16 fdIconID; /* icon ID number */
xint16 fdUnused[3]; /* spare */
schar8 fdScript; /* scrip flag and code */
schar8 fdXFlags; /* reserved */
xint16 fdComment; /* comment ID number */
xint32 fdPutAway; /* home directory ID */
}; /* FXInfo */
{ xint16 fdIconID; /* icon ID number */ xint16 fdUnused[3]; /* spare */ schar8 fdScript; /* scrip flag and code */ schar8 fdXFlags; /* reserved */ xint16 fdComment; /* comment ID number */ xint32 fdPutAway; /* home directory ID */ }; /* FXInfo */
typedef struct FXInfo FXInfo;
typedef struct FXInfo FXInfo;
/* Pieces used by AppleSingle & AppleDouble (defined later). */
/* Pieces used by AppleSingle & AppleDouble (defined later). */
struct ASHeader /* header portion of AppleSingle */
{
/* AppleSingle = 0x00051600; AppleDouble = 0x00051607 */
struct ASHeader /* header portion of AppleSingle */ { /* AppleSingle = 0x00051600; AppleDouble = 0x00051607 */
Faltstrom, Crocker & Fair [Page 11] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 11] RFC 1740 MIME-based Mac files December 1994
uint32 magicNum; /* internal file type tag */
uint32 versionNum; /* format version: 2 = 0x00020000 */
uchar8 filler[16]; /* filler, currently all bits 0 */
uint16 numEntries; /* number of entries which follow */
}; /* ASHeader */
uint32 magicNum; /* internal file type tag */ uint32 versionNum; /* format version: 2 = 0x00020000 */ uchar8 filler[16]; /* filler, currently all bits 0 */ uint16 numEntries; /* number of entries which follow */ }; /* ASHeader */
typedef struct ASHeader ASHeader;
typedef struct ASHeader ASHeader;
struct ASEntry /* one AppleSingle entry descriptor */
{
uint32 entryID; /* entry type: see list, 0 invalid */
uint32 entryOffset; /* offset, in octets, from beginning */
/* of file to this entry's data */
uint32 entryLength; /* length of data in octets */
}; /* ASEntry */
struct ASEntry /* one AppleSingle entry descriptor */ { uint32 entryID; /* entry type: see list, 0 invalid */ uint32 entryOffset; /* offset, in octets, from beginning */ /* of file to this entry's data */ uint32 entryLength; /* length of data in octets */ }; /* ASEntry */
typedef struct ASEntry ASEntry;
typedef struct ASEntry ASEntry;
/* Apple reserves the range of entry IDs from 1 to 0x7FFFFFFF.
* Entry ID 0 is invalid. The rest of the range is available
* for applications to define their own entry types. "Apple does
* not arbitrate the use of the rest of the range."
*/
/* Apple reserves the range of entry IDs from 1 to 0x7FFFFFFF. * Entry ID 0 is invalid. The rest of the range is available * for applications to define their own entry types. "Apple does * not arbitrate the use of the rest of the range." */
#define AS_DATA 1 /* data fork */
#define AS_RESOURCE 2 /* resource fork */
#define AS_REALNAME 3 /* File's name on home file system */
#define AS_COMMENT 4 /* standard Mac comment */
#define AS_ICONBW 5 /* Mac black & white icon */
#define AS_ICONCOLOR 6 /* Mac color icon */
/* 7 /* not used */
#define AS_FILEDATES 8 /* file dates; create, modify, etc */
#define AS_FINDERINFO 9 /* Mac Finder info & extended info */
#define AS_MACINFO 10 /* Mac file info, attributes, etc */
#define AS_PRODOSINFO 11 /* Pro-DOS file info, attrib., etc */
#define AS_MSDOSINFO 12 /* MS-DOS file info, attributes, etc */
#define AS_AFPNAME 13 /* Short name on AFP server */
#define AS_AFPINFO 14 /* AFP file info, attrib., etc */
#define AS_DATA 1 /* data fork */ #define AS_RESOURCE 2 /* resource fork */ #define AS_REALNAME 3 /* File's name on home file system */ #define AS_COMMENT 4 /* standard Mac comment */ #define AS_ICONBW 5 /* Mac black & white icon */ #define AS_ICONCOLOR 6 /* Mac color icon */ /* 7 /* not used */ #define AS_FILEDATES 8 /* file dates; create, modify, etc */ #define AS_FINDERINFO 9 /* Mac Finder info & extended info */ #define AS_MACINFO 10 /* Mac file info, attributes, etc */ #define AS_PRODOSINFO 11 /* Pro-DOS file info, attrib., etc */ #define AS_MSDOSINFO 12 /* MS-DOS file info, attributes, etc */ #define AS_AFPNAME 13 /* Short name on AFP server */ #define AS_AFPINFO 14 /* AFP file info, attrib., etc */
#define AS_AFPDIRID 15 /* AFP directory ID */
#define AS_AFPDIRID 15 /* AFP directory ID */
/* matrix of entry types and their usage:
*
* Macintosh Pro-DOS MS-DOS AFP server
* --------- ------- ------ ----------
* 1 AS_DATA xxx xxx xxx xxx
* 2 AS_RESOURCE xxx xxx
* 3 AS_REALNAME xxx xxx xxx xxx
/* matrix of entry types and their usage: * * Macintosh Pro-DOS MS-DOS AFP server * --------- ------- ------ ---------- * 1 AS_DATA xxx xxx xxx xxx * 2 AS_RESOURCE xxx xxx * 3 AS_REALNAME xxx xxx xxx xxx
Faltstrom, Crocker & Fair [Page 12] RFC 1740 MIME-based Mac files December 1994
Faltstrom, Crocker & Fair [Page 12] RFC 1740 MIME-based Mac files December 1994
*
* 4 AS_COMMENT xxx
* 5 AS_ICONBW xxx
* 6 AS_ICONCOLOR xxx
*
* 8 AS_FILEDATES xxx xxx xxx xxx
* 9 AS_FINDERINFO xxx
* 10 AS_MACINFO xxx
*
* 11 AS_PRODOSINFO xxx
* 12 AS_MSDOSINFO xxx
*
* 13 AS_AFPNAME xxx
* 14 AS_AFPINFO xxx
* 15 AS_AFPDIRID xxx
*/
* * 4 AS_COMMENT xxx * 5 AS_ICONBW xxx * 6 AS_ICONCOLOR xxx * * 8 AS_FILEDATES xxx xxx xxx xxx * 9 AS_FINDERINFO xxx * 10 AS_MACINFO xxx * * 11 AS_PRODOSINFO xxx * 12 AS_MSDOSINFO xxx * * 13 AS_AFPNAME xxx * 14 AS_AFPINFO xxx * 15 AS_AFPDIRID xxx */
/* entry ID 1, data fork of file - arbitrary length octet string */
/* entry ID 1, data fork of file - arbitrary length octet string */
/* entry ID 2, resource fork - arbitrary length opaque octet string;
* as created and managed by Mac O.S. resoure manager
*/
/* entry ID 2, resource fork - arbitrary length opaque octet string; * as created and managed by Mac O.S. resoure manager */
/* entry ID 3, file's name as created on home file system - arbitrary
* length octet string; usually short, printable ASCII
*/
/*エントリーID3、ホームファイルシステムに作成されるファイルの名前--任意の*長さ八重奏ストリング。 通常短くて、印刷可能なASCII*/
/* entry ID 4, standard Macintosh comment - arbitrary length octet
* string; printable ASCII, claimed 200 chars or less
*/
/*エントリーID4、標準のマッキントッシュコメント--任意の長さの八重奏*ストリング。 200の雑用であると主張された印刷可能なASCIIか、より少ない*/
/* This is probably a simple duplicate of the 128 octet bitmap
* stored as the 'ICON' resource or the icon element from an 'ICN#'
* resource.
*/
/、*これはたぶん'ICON'リソースかアイコン要素として'ICN#'*リソースから保存された128八重奏ビットマップ*の簡単な写しです。 */
struct ASIconBW /* entry ID 5, standard Mac black and white icon */
{
uint32 bitrow[32]; /* 32 rows of 32 1-bit pixels */
}; /* ASIconBW */
struct ASIconBW/*エントリーID5、標準のMacが黒くして、アイコン*/を空白にする、uint32 bitrow[32]、; 32 1ビットの画素*/の/*32の行、。 /*ASIconBW*/
typedef struct ASIconBW ASIconBW;
typedef struct ASIconBW ASIconBW。
/* entry ID 6, "standard" Macintosh color icon - several competing
* color icons are defined. Given the copyright dates
* of the Inside Macintosh volumes, the 'cicn' resource predominated
* when the AppleSingle Developer's Note was written (most probable
* candidate). See Inside Macintosh, Volume V, pages 64 & 80-81 for
/*エントリーID6、「標準」のマッキントッシュカラーアイコン--数個の競争*カラーアイコンが定義されます。 *AppleSingle DeveloperのNoteが(最もありえそうな*候補)に書かれたとき、Insideマッキントッシュボリュームに関する著作権登録年紀*を考えて、'cicn'リソースは勝ちました。 Insideマッキントッシュ(Volume V)が64と80-81を呼び出すのを確実にしてください。
Faltstrom, Crocker & Fair [Page 13] RFC 1740 MIME-based Mac files December 1994
Macファイル1994年12月のMIMEベースのFaltstrom、クロッカー、およびFair[13ページ]RFC1740
* a description of 'cicn' resources.
*
* With System 7, Apple introduced icon families. They consist of:
* large (32x32) B&W icon, 1-bit/pixel, type 'ICN#',
* small (16x16) B&W icon, 1-bit/pixel, type 'ics#',
* large (32x32) color icon, 4-bits/pixel, type 'icl4',
* small (16x16) color icon, 4-bits/pixel, type 'ics4',
* large (32x32) color icon, 8-bits/pixel, type 'icl8', and
* small (16x16) color icon, 8-bits/pixel, type 'ics8'.
* If entry ID 6 is one of these, take your pick. See Inside
* Macintosh, Volume VI, pages 2-18 to 2-22 and 9-9 to 9-13, for
* descriptions.
*/
* 'cicn'リソースの記述。 * * System7と共に、アップルはアイコンファミリーを紹介しました。 それらは以下から成ります。 * 大きい..32×32..アイコン..ビット..画素..タイプ..小さい..16×16..アイコン..ビット..画素..タイプ..大きい..32×32..色..アイコン..ビット..画素..タイプ..小さい..16×16..色..アイコン..ビット..画素..タイプ..大きい..32×32..色..アイコン..ビット..画素..タイプ..小さい..16×16..色..アイコン..ビット..画素..タイプ * エントリーID6がこれらの1つであるなら、好きなものを選んでください。 *記述に関してInside*マッキントッシュ、Volume VI、2-18〜2-22ページ、および9-9を9-13に見てください。 */
/* entry ID 7, not used */
中古の*/ではなく、/*エントリーID7
/* Times are stored as a "signed number of seconds before of after
* 12:00 a.m. (midnight), January 1, 2000 Greenwich Mean Time (GMT).
* Applications must convert to their native date and time
* conventions." Any unknown entries are set to 0x80000000
* (earliest reasonable time).
*/
/*回は「(グリニッジ標準時)のグリニッジ標準時に午前12時の(真夜中)と、2000年1月1日に以前、後*について秒数であると署名される」aとして保存されます。 * 「アプリケーションはそれらのネイティブの日時*コンベンションに変えなければなりません。」 どんな未知のエントリーも0×80000000*(時間妥当な最も前半)に設定されます。 */
struct ASFileDates /* entry ID 8, file dates info */
{
sint32 create; /* file creation date/time */
sint32 modify; /* last modification date/time */
sint32 backup; /* last backup date/time */
sint32 access; /* last access date/time */
}; /* ASFileDates */
struct ASFileDates/*エントリーID8、ファイルは*/とインフォメーションの日付を入れます。sint32は/*最後の変更日付/時間*/sint32バックアップ; /*最後のバックアップ日付/時間*/sint32アクセス; /*最後のアクセス日付/時間*/を作成します;*/sint32が変更する/*ファイル作成日付/時間;。 /*ASFileDates*/
typedef struct ASFileDates ASFileDates;
typedef struct ASFileDates ASFileDates。
/* See older Inside Macintosh, Volume II, page 115 for
* PBGetFileInfo(), and Volume IV, page 155, for PBGetCatInfo().
*/
/*は、より古いInsideマッキントッシュ、Volume II、*PBGetFileInfo()のための115ページ、およびVolume IV、PBGetCatInfo()のための155ページを参照します。 */
/* entry ID 9, Macintosh Finder info & extended info */
struct ASFinderInfo
{
FInfo ioFlFndrInfo; /* PBGetFileInfo() or PBGetCatInfo() */
FXInfo ioFlXFndrInfo; /* PBGetCatInfo() (HFS only) */
}; /* ASFinderInfo */
/*エントリーID9、マッキントッシュFinderインフォメーション、および拡張インフォメーション*/struct ASFinderInfo FInfo ioFlFndrInfo; /*PBGetFileInfo()かPBGetCatInfo()*/FXInfo ioFlXFndrInfo;/*PBGetCatInfo()(HFS専用)*/。 /*ASFinderInfo*/
typedef struct ASFinderInfo ASFinderInfo;
typedef struct ASFinderInfo ASFinderInfo。
struct ASMacInfo /* entry ID 10, Macintosh file information */
{
struct ASMacInfo/*エントリーID10、マッキントッシュファイル情報*/
Faltstrom, Crocker & Fair [Page 14] RFC 1740 MIME-based Mac files December 1994
Macファイル1994年12月のMIMEベースのFaltstrom、クロッカー、およびFair[14ページ]RFC1740
uchar8 filler[3]; /* filler, currently all bits 0 */
uchar8 ioFlAttrib; /* PBGetFileInfo() or PBGetCatInfo() */
}; /* ASMacInfo */
uchar8フィラー[3]。 /*フィラー、現在すべてのビット0*/uchar8 ioFlAttrib。 /*PBGetFileInfo()かPBGetCatInfo()*/、。 /*ASMacInfo*/
typedef struct ASMacInfo ASMacInfo;
typedef struct ASMacInfo ASMacInfo。
#define AS_PROTECTED 0x0002 /* protected bit */ #define AS_LOCKED 0x0001 /* locked bit */
#定義、AS_PROTECTED0×0002/*の保護されたビット*/#はAS_LOCKED0×0001/*のロックされた噛み付いている*/を定義します。
/* NOTE: ProDOS-16 and GS/OS use entire fields. ProDOS-8 uses low
* order half of each item (low byte in access & filetype, low word
* in auxtype); remainder of each field should be zero filled.
*/
/*注意: ProDOS-16とGS/OSは全体の分野を使用します。 ProDOS-8は半分の低い*オーダー各個条(アクセスとfiletypeの低バイト、auxtypeの少ない単語*)を使用します。 それぞれの分野の残りはいっぱいにされたゼロであるべきです。 */
struct ASProdosInfo /* entry ID 11, ProDOS file information */
{
uint16 access; /* access word */
uint16 filetype; /* file type of original file */
uint32 auxtype; /* auxiliary type of the orig file */
}; /* ASProDosInfo */
struct ASProdosInfo/*エントリーID11、ProDOSはuint16アクセス; /*アクセス単語*/uint16 filetype; /*ファイルが元のファイル*/uint32 auxtype; origファイル*/の/*補助のタイプにタイプする情報*/をファイルします。 /*ASProDosInfo*/
typedef struct ASProdosInfo ASProdosInfo;
typedef struct ASProdosInfo ASProdosInfo。
/* MS-DOS file attributes occupy 1 octet; since the Developer Note
* is unspecific, I've placed them in the low order portion of the
* field (based on example of other ASMacInfo & ASProdosInfo).
*/
/*MS-DOSファイル属性は1つの八重奏を占領します。 Developer Note*が「非-特定」であるので、私は*分野(他のASMacInfo&ASProdosInfoに関する例に基づいている)の下位の部分にそれらを置きました。 */
struct ASMsdosInfo /* entry ID 12, MS-DOS file information */
{
uchar8 filler; /* filler, currently all bits 0 */
uchar8 attr; /* _dos_getfileattr(), MS-DOS */
/* interrupt 21h function 4300h */
}; /* ASMsdosInfo */
struct ASMsdosInfo /* entry ID 12, MS-DOS file information */ { uchar8 filler; /* filler, currently all bits 0 */ uchar8 attr; /* _dos_getfileattr(), MS-DOS */ /* interrupt 21h function 4300h */ }; /*ASMsdosInfo*/
typedef struct ASMsdosInfo ASMsdosInfo;
typedef struct ASMsdosInfo ASMsdosInfo。
#define AS_DOS_NORMAL 0x00 /* normal file (all bits clear) */ #define AS_DOS_READONLY 0x01 /* file is read-only */ #define AS_DOS_HIDDEN 0x02 /* hidden file (not shown by DIR) */ #define AS_DOS_SYSTEM 0x04 /* system file (not shown by DIR) */ #define AS_DOS_VOLID 0x08 /* volume label (only in root dir) */ #define AS_DOS_SUBDIR 0x10 /* file is a subdirectory */ #define AS_DOS_ARCHIVE 0x20 /* new or modified (needs backup) */
#定義..0×00..正常..ファイル..ビット..クリアする..定義..0×01..ファイル..読書..単に..定義..0×02..隠しファイル..示す..定義..0×04..システムファイル..目立つ..定義..0×08..ボリュームラベル..単に..根..定義..0×10..ファイル..サブディレクトリ..定義..アーカイブ..0×20..新しい..変更..必要..バックアップ
/* entry ID 13, short file name on AFP server - arbitrary length
* octet string; usualy printable ASCII starting with
* '!' (0x21)
/*エントリーID13、AFPサーバに関する短いファイル名--任意の長さ*八重奏ストリング。 *'!'から始まるusualyに印刷可能なASCII(0×21)
Faltstrom, Crocker & Fair [Page 15] RFC 1740 MIME-based Mac files December 1994
Macファイル1994年12月のMIMEベースのFaltstrom、クロッカー、およびFair[15ページ]RFC1740
*/
*/
struct ASAfpInfo /* entry ID 12, AFP server file information */
{
uchar8 filler[3]; /* filler, currently all bits 0 */
uchar8 attr; /* file attributes */
}; /* ASAfpInfo */
struct ASAfpInfo/*エントリーID12、AFPサーバファイル情報*/uchar8フィラー[3]; /*フィラー、現在すべてのビット0*/uchar8 attr;/*ファイル属性*/。 /*ASAfpInfo*/
typedef struct ASAfpInfo ASAfpInfo;
typedef struct ASAfpInfo ASAfpInfo。
#define AS_AFP_Invisible 0x01 /* file is invisible */ #define AS_AFP_MultiUser 0x02 /* simultaneous access allowed */ #define AS_AFP_System 0x04 /* system file */ #define AS_AFP_BackupNeeded 0x40 /* new or modified (needs backup) */
#定義、AS_AFP_Invisible0×01/*ファイルが目に見えない*/#、がAS_AFP_BackupNeeded0×40/*新しい状態でSystem0×04/*システムファイル*/#が定義するAS_AFP_を定義するか、または変更された*/#バックアップを(必要とする)が許容されたAS_AFP_MultiUser0×02/*同時アクセスを定義するということである、*/
struct ASAfpDirId /* entry ID 15, AFP server directory ID */
{
uint32 dirid; /* file's directory ID on AFP server */
}; /* ASAfpDirId */
struct ASAfpDirId/*エントリーID15、AFPサーバディレクトリID*/、uint32 dirid、; AFPサーバ*/の上の/*ファイルのディレクトリID、。 /*ASAfpDirId*/
typedef struct ASAfpDirId ASAfpDirId;
typedef struct ASAfpDirId ASAfpDirId。
/*
* The format of an AppleSingle/AppleDouble header
*/
struct AppleSingle /* format of disk file */
{
ASHeader header; /* AppleSingle header part */
ASEntry entry[1]; /* array of entry descriptors */
/* uchar8 filedata[]; /* followed by rest of file */
}; /* AppleSingle */
AppleSingle/AppleDoubleヘッダー*/ struct AppleSingle /*の形式がフォーマットするファイル*/の残りでASHeaderヘッダー; /*AppleSingleヘッダーパート*/ASEntryエントリー[1]; エントリー記述子*//*uchar8 filedata[]の/*配列; /*が続いたディスクファイル*/の/**。 /*AppleSingle*/
typedef struct AppleSingle AppleSingle;
typedef struct AppleSingle AppleSingle。
/*
* FINAL REMINDER: the Motorola 680x0 is a big-endian architecture!
*/
/**最終確認: モトローラ680x0はビッグエンディアンアーキテクチャです! */
/* End of applefile.h */
applefile.h*/の/*終わり
Faltstrom, Crocker & Fair [Page 16]
Faltstrom、クロッカー、およびフェア[16ページ]
一覧
スポンサーリンク
