2000-11-05 08:33:55 +00:00
|
|
|
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# apple: file(1) magic for Apple file formats
|
|
|
|
#
|
|
|
|
0 string FiLeStArTfIlEsTaRt binscii (apple ][) text
|
|
|
|
0 string \x0aGL Binary II (apple ][) data
|
|
|
|
0 string \x76\xff Squeezed (apple ][) data
|
|
|
|
0 string NuFile NuFile archive (apple ][) data
|
|
|
|
0 string N\xf5F\xe9l\xe5 NuFile archive (apple ][) data
|
|
|
|
0 belong 0x00051600 AppleSingle encoded Macintosh file
|
|
|
|
0 belong 0x00051607 AppleDouble encoded Macintosh file
|
|
|
|
|
|
|
|
# magic for Newton PDA package formats
|
|
|
|
# from Ruda Moura <ruda@helllabs.org>
|
2001-04-25 07:41:21 +00:00
|
|
|
0 string package0 Newton package, NOS 1.x,
|
|
|
|
>12 belong &0x80000000 AutoRemove,
|
|
|
|
>12 belong &0x40000000 CopyProtect,
|
|
|
|
>12 belong &0x10000000 NoCompression,
|
|
|
|
>12 belong &0x04000000 Relocation,
|
|
|
|
>12 belong &0x02000000 UseFasterCompression,
|
|
|
|
>16 belong x version %d
|
|
|
|
|
|
|
|
0 string package1 Newton package, NOS 2.x,
|
2000-11-05 08:33:55 +00:00
|
|
|
>12 belong &0x80000000 AutoRemove,
|
|
|
|
>12 belong &0x40000000 CopyProtect,
|
|
|
|
>12 belong &0x10000000 NoCompression,
|
|
|
|
>12 belong &0x04000000 Relocation,
|
|
|
|
>12 belong &0x02000000 UseFasterCompression,
|
|
|
|
>16 belong x version %d
|
|
|
|
|
|
|
|
# The following entries for the Apple II are for files that have
|
|
|
|
# been transferred as raw binary data from an Apple, without having
|
|
|
|
# been encapsulated by any of the above archivers.
|
|
|
|
#
|
|
|
|
# In general, Apple II formats are hard to identify because Apple DOS
|
|
|
|
# and especially Apple ProDOS have strong typing in the file system and
|
|
|
|
# therefore programmers never felt much need to include type information
|
|
|
|
# in the files themselves.
|
|
|
|
#
|
|
|
|
# Eric Fischer <enf@pobox.com>
|
|
|
|
|
|
|
|
# AppleWorks word processor:
|
|
|
|
#
|
|
|
|
# This matches the standard tab stops for an AppleWorks file, but if
|
|
|
|
# a file has a tab stop set in the first four columns this will fail.
|
|
|
|
#
|
|
|
|
# The "O" is really the magic number, but that's so common that it's
|
|
|
|
# necessary to check the tab stops that follow it to avoid false positives.
|
|
|
|
|
|
|
|
4 string O==== AppleWorks word processor data
|
|
|
|
>85 byte&0x01 >0 \b, zoomed
|
|
|
|
>90 byte&0x01 >0 \b, paginated
|
|
|
|
>92 byte&0x01 >0 \b, with mail merge
|
|
|
|
#>91 byte x \b, left margin %d
|
|
|
|
|
|
|
|
# AppleWorks database:
|
|
|
|
#
|
|
|
|
# This isn't really a magic number, but it's the closest thing to one
|
|
|
|
# that I could find. The 1 and 2 really mean "order in which you defined
|
|
|
|
# categories" and "left to right, top to bottom," respectively; the D and R
|
|
|
|
# mean that the cursor should move either down or right when you press Return.
|
|
|
|
|
2001-04-25 07:41:21 +00:00
|
|
|
#30 string \x01D AppleWorks database data
|
|
|
|
#30 string \x02D AppleWorks database data
|
|
|
|
#30 string \x01R AppleWorks database data
|
|
|
|
#30 string \x02R AppleWorks database data
|
2000-11-05 08:33:55 +00:00
|
|
|
|
|
|
|
# AppleWorks spreadsheet:
|
|
|
|
#
|
|
|
|
# Likewise, this isn't really meant as a magic number. The R or C means
|
|
|
|
# row- or column-order recalculation; the A or M means automatic or manual
|
|
|
|
# recalculation.
|
|
|
|
|
2001-04-25 07:41:21 +00:00
|
|
|
#131 string RA AppleWorks spreadsheet data
|
|
|
|
#131 string RM AppleWorks spreadsheet data
|
|
|
|
#131 string CA AppleWorks spreadsheet data
|
|
|
|
#131 string CM AppleWorks spreadsheet data
|
2000-11-05 08:33:55 +00:00
|
|
|
|
|
|
|
# Applesoft BASIC:
|
|
|
|
#
|
|
|
|
# This is incredibly sloppy, but will be true if the program was
|
|
|
|
# written at its usual memory location of 2048 and its first line
|
|
|
|
# number is less than 256. Yuck.
|
|
|
|
|
|
|
|
0 belong&0xff00ff 0x80000 Applesoft BASIC program data
|
|
|
|
#>2 leshort x \b, first line number %d
|
|
|
|
|
|
|
|
# ORCA/EZ assembler:
|
|
|
|
#
|
|
|
|
# This will not identify ORCA/M source files, since those have
|
|
|
|
# some sort of date code instead of the two zero bytes at 6 and 7
|
|
|
|
# XXX Conflicts with ELF
|
|
|
|
#4 belong&0xff00ffff 0x01000000 ORCA/EZ assembler source data
|
|
|
|
#>5 byte x \b, build number %d
|
|
|
|
|
|
|
|
# Broderbund Fantavision
|
|
|
|
#
|
|
|
|
# I don't know what these values really mean, but they seem to recur.
|
|
|
|
# Will they cause too many conflicts?
|
|
|
|
|
|
|
|
# Probably :-)
|
|
|
|
#2 belong&0xFF00FF 0x040008 Fantavision movie data
|
|
|
|
|
|
|
|
# Some attempts at images.
|
|
|
|
#
|
|
|
|
# These are actually just bit-for-bit dumps of the frame buffer, so
|
|
|
|
# there's really no reasonably way to distinguish them except for their
|
|
|
|
# address (if preserved) -- 8192 or 16384 -- and their length -- 8192
|
|
|
|
# or, occasionally, 8184.
|
|
|
|
#
|
|
|
|
# Nevertheless this will manage to catch a lot of images that happen
|
|
|
|
# to have a solid-colored line at the bottom of the screen.
|
|
|
|
|
|
|
|
8144 string \x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F Apple II image with white background
|
|
|
|
8144 string \x55\x2A\x55\x2A\x55\x2A\x55\x2A Apple II image with purple background
|
|
|
|
8144 string \x2A\x55\x2A\x55\x2A\x55\x2A\x55 Apple II image with green background
|
|
|
|
8144 string \xD5\xAA\xD5\xAA\xD5\xAA\xD5\xAA Apple II image with blue background
|
|
|
|
8144 string \xAA\xD5\xAA\xD5\xAA\xD5\xAA\xD5 Apple II image with orange background
|
|
|
|
|
|
|
|
# Beagle Bros. Apple Mechanic fonts
|
|
|
|
|
|
|
|
0 belong&0xFF00FFFF 0x6400D000 Apple Mechanic font
|