Apple-2-Tools
/
nulib2
mirror of https://github.com/fadden/nulib2.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Transfer nulib.com web site to github 

The full site, in all its FrontPage-generated glory.
This commit is contained in:
Andy McFadden 2014-12-21 10:37:29 -08:00
commit eceb8f7038
120 changed files with 10929 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md Normal file
View File

@ -0,0 +1,2 @@
The gh-pages branch contains the NuLib2 web site. This is accessible as
https://fadden.github.io/nulib2/, or http://nulib.com/.

23
_borders/_vti_cnf/top.htm Normal file
View File

@ -0,0 +1,23 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|06 Feb 2000 09:07:24 -0000
vti_extenderversion:SR|4.0.2.7802
vti_nexttolasttimemodified:TR|06 Feb 2000 09:06:47 -0000
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|23 Dec 1999 21:42:47 -0000
vti_shadowfiles:VX|
vti_filesize:IR|825
vti_title:SR|Shared Top Border
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_backlinkinfo:VX|
vti_cacheddtm:TX|06 Feb 2000 08:07:24 -0000
vti_cachedlinkinfo:VX|
vti_cachedsvcrellinks:VX|
vti_cachedtitle:SR|Shared Top Border
vti_cachedbodystyle:SR|<body>
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|false
vti_botnavbits:SW|SHUB

21
_borders/top.htm Normal file
View File

@ -0,0 +1,21 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Shared Top Border</title>
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Border" content="none">
</head>
<body>
<p align="center"><font size="6"><strong><!--webbot bot="Navigation"
s-type="banner" s-rendering="graphics" S-Orientation B-Include-Home B-Include-Up U-Page S-Target startspan --><!--webbot bot="Navigation" endspan i-checksum="0" --></strong></font><br>
<!--webbot bot="Navigation" s-type="siblings" s-orientation="horizontal"
s-rendering="graphics" b-include-home="TRUE" b-include-up="TRUE" U-Page S-Target startspan --><!--webbot bot="Navigation" endspan i-checksum="0" --></p>
<hr>
</body>
</html>

24
_vti_cnf/bugs.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_timecreated:TR|15 Jan 2000 06:19:33 -0000
vti_timelastmodified:TR|31 Mar 2004 17:37:51 -0000
vti_shadowfiles:VX|
vti_filesize:IR|3954
vti_title:SR|Bugs & Features
vti_metatags:VR|HTTP-EQUIV=Content-Language en-us HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.8912
vti_backlinkinfo:VX|index.htm bugs.htm
vti_nexttolasttimemodified:TR|19 Mar 2003 17:33:03 -0000
vti_modifiedby:SR|fadden
vti_cacheddtm:TX|31 Mar 2004 16:37:52 -0000
vti_cachedlinkinfo:VX|K|bugs.htm H|mailto:fadden@fadden.com
vti_cachedsvcrellinks:VX|FKUS|bugs.htm NHUS|mailto:fadden@fadden.com
vti_cachedtitle:SR|Bugs & Features
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

22
_vti_cnf/index.htm Normal file
View File

@ -0,0 +1,22 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_timecreated:TR|22 Dec 1999 22:47:10 -0000
vti_timelastmodified:TR|19 Feb 2007 23:13:28 -0000
vti_filesize:IR|9646
vti_title:SR|NuLib Home Page
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 HTTP-EQUIV=Content-Language en-us GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document description Home\\ page\\ for\\ NuLib,\\ NuLib2,\\ NufxLib,\\ ShrinkIt,\\ and\\ NuFX\\ (SHK)\\ archives keywords nulib,\\ nulib2,\\ nufxlib,\\ shk,\\ sdk,\\ bxy,\\ bse,\\ shrinkit,\\ nufx,\\ apple,\\ apple2,\\ emulator
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.8912
vti_backlinkinfo:VX|
vti_nexttolasttimemodified:TR|19 Sep 2005 05:42:45 -0000
vti_shadowfiles:VX|
vti_modifiedby:SR|fadden
vti_cacheddtm:TX|19 Feb 2007 23:13:28 -0000
vti_cachedlinkinfo:VX|H|downloads/index.htm H|nulib2-manual.htm H|nufxlibapi.htm H|bugs.htm H|library/index.htm H|nulib2-manual.htm H|nufxlibapi.htm H|http://www.faddensoft.com/ciderpress/ H|http://www.faddensoft.com/ H|http://www.fadden.com/ H|http://sourceforge.net S|http://sourceforge.net/sflogo.php
vti_cachedsvcrellinks:VX|FHUS|downloads/index.htm FHUS|nulib2-manual.htm FHUS|nufxlibapi.htm FHUS|bugs.htm FHUS|library/index.htm FHUS|nulib2-manual.htm FHUS|nufxlibapi.htm NHHS|http://www.faddensoft.com/ciderpress/ NHHS|http://www.faddensoft.com/ NHHS|http://www.fadden.com/ NHHS|http://sourceforge.net NSHS|http://sourceforge.net/sflogo.php
vti_cachedtitle:SR|NuLib Home Page
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|false
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|false

24
_vti_cnf/nufxlibapi.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_timecreated:TR|24 Dec 1999 08:11:12 -0000
vti_timelastmodified:TR|19 Feb 2007 23:15:03 -0000
vti_shadowfiles:VX|
vti_filesize:IR|110697
vti_title:SR|NufxLib API
vti_metatags:VR|HTTP-EQUIV=Content-Language en-us HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.8912
vti_backlinkinfo:VX|nufxlibapi.htm index.htm
vti_nexttolasttimemodified:TR|19 Feb 2007 22:35:33 -0000
vti_modifiedby:SR|fadden
vti_cacheddtm:TX|19 Feb 2007 23:15:03 -0000
vti_cachedlinkinfo:VX|K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm H|library/FTN.e08002.htm H|library/nufx-addendum.htm H|library/FTN.e08002.htm K|nufxlibapi.htm H|library/nufx-addendum.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm K|nufxlibapi.htm H|http://www.fadden.com/ H|http://www.nulib.com/
vti_cachedsvcrellinks:VX|FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FHUS|library/FTN.e08002.htm FHUS|library/nufx-addendum.htm FHUS|library/FTN.e08002.htm FKUS|nufxlibapi.htm FHUS|library/nufx-addendum.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm FKUS|nufxlibapi.htm NHHS|http://www.fadden.com/ NHHS|http://www.nulib.com/
vti_cachedtitle:SR|NufxLib API
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

24
_vti_cnf/nulib2-manual.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_timecreated:TR|16 Jan 2000 22:42:13 -0000
vti_timelastmodified:TR|19 Feb 2006 02:02:53 -0000
vti_shadowfiles:VX|
vti_filesize:IR|33618
vti_title:SR|NuLib2 Manual
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.8912
vti_backlinkinfo:VX|nulib2-manual.htm index.htm
vti_nexttolasttimemodified:TR|19 Feb 2006 02:02:22 -0000
vti_modifiedby:SR|fadden
vti_cacheddtm:TX|19 Feb 2006 02:02:53 -0000
vti_cachedlinkinfo:VX|K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm K|nulib2-manual.htm H|http://www.nulib.com/ H|http://www.zlib.org/ K|nulib2-manual.htm H|library/nulib2-preserve.htm H|library/nulib2-preserve.htm K|nulib2-manual.htm H|http://www.fadden.com/ H|http://www.nulib.com/
vti_cachedsvcrellinks:VX|FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm FKUS|nulib2-manual.htm NHHS|http://www.nulib.com/ NHHS|http://www.zlib.org/ FKUS|nulib2-manual.htm FHUS|library/nulib2-preserve.htm FHUS|library/nulib2-preserve.htm FKUS|nulib2-manual.htm NHHS|http://www.fadden.com/ NHHS|http://www.nulib.com/
vti_cachedtitle:SR|NuLib2 Manual
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

18
_vti_pvt/_vti_cnf/_x_todo.htm Normal file
View File

@ -0,0 +1,18 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|31 Jan 2000 05:53:17 -0000
vti_timelastmodified:TR|31 Jan 2000 05:53:17 -0000
vti_filesize:IR|578
vti_title:SR|Active To Do List
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=utf-8
vti_extenderversion:SR|4.0.2.5526
vti_backlinkinfo:VX|
vti_cacheddtm:TX|31 Jan 2000 04:53:18 -0000
vti_cachedlinkinfo:VX|
vti_cachedsvcrellinks:VX|
vti_cachedtitle:SR|Active To Do List
vti_cachedbodystyle:SR|<body>
vti_cachedhasbots:BR|false
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|false

18
_vti_pvt/_vti_cnf/_x_todoh.htm Normal file
View File

@ -0,0 +1,18 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|31 Jan 2000 05:53:17 -0000
vti_timelastmodified:TR|31 Jan 2000 05:53:17 -0000
vti_cacheddtm:TX|31 Jan 2000 05:53:18 -0000
vti_filesize:IR|580
vti_cachedlinkinfo:VX|
vti_cachedsvcrellinks:VX|
vti_cachedtitle:SR|To Do List History
vti_title:SR|To Do List History
vti_cachedbodystyle:SR|<body>
vti_cachedhasbots:BR|false
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|false
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=utf-8
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|

23
_vti_pvt/_x_todo.htm Normal file
View File

@ -0,0 +1,23 @@
<html><head>
<META version="1">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><TITLE>Active To Do List</TITLE>
</head><body>
<H1>Active To Do List</H1>
<TABLE BORDER=1>
<tr>
<td><b>Number</b></td>
<td><b>Task</b></td>
<td><b>Pri</b></td>
<td><b>Author</b></td>
<td><b>Created By Tool</b></td>
<td><b>Created On</b></td>
<td><b>Modified On</b></td>
<td><b>Completed</b></td>
<td><b>Modified By</b></td>
<td><b>Assigned To</b></td>
<td><b>Link To</b></td>
<td><b>Magic</b></td>
<td><b>Description</b></td>
</tr>
</TABLE>
</body></html>

23
_vti_pvt/_x_todoh.htm Normal file
View File

@ -0,0 +1,23 @@
<html><head>
<META version="1">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><TITLE>To Do List History</TITLE>
</head><body>
<H1>To Do List History</H1>
<TABLE BORDER=1>
<tr>
<td><b>Number</b></td>
<td><b>Task</b></td>
<td><b>Pri</b></td>
<td><b>Author</b></td>
<td><b>Created By Tool</b></td>
<td><b>Created On</b></td>
<td><b>Modified On</b></td>
<td><b>Completed</b></td>
<td><b>Modified By</b></td>
<td><b>Assigned To</b></td>
<td><b>Link To</b></td>
<td><b>Magic</b></td>
<td><b>Description</b></td>
</tr>
</TABLE>
</body></html>

2
_vti_pvt/botinfs.cnf Normal file
View File

@ -0,0 +1,2 @@
vti_encoding:SR|utf8-nl
C\:\\Program Files\\Common Files\\Microsoft Shared\\Web Server Extensions\\40\\bots\\vinavbar\\vinavbar.inf:VW|vinavbar

2
_vti_pvt/bots.cnf Normal file
View File

@ -0,0 +1,2 @@
vti_encoding:SR|utf8-nl
vinavbar:VW|C:\\\\Program\\ Files\\\\Common\\ Files\\\\Microsoft\\ Shared\\\\Web\\ Server\\ Extensions\\\\40\\\\bots\\\\vinavbar\\\\vinavbar.inf vinavbar E I info N C:\\\\Program\\ Files\\\\Common\\ Files\\\\Microsoft\\ Shared\\\\Web\\ Server\\ Extensions\\\\40\\\\bots\\\\vinavbar\\\\fp4Avnb.dll

BIN
_vti_pvt/deptodoc.btr Normal file
View File

Binary file not shown.

BIN
_vti_pvt/doctodep.btr Normal file
View File

Binary file not shown.

14
_vti_pvt/linkinfo.cnf Normal file
View File

@ -0,0 +1,14 @@
vti_encoding:SR|utf8-nl
http\://www.zlib.org/:nulib2-manual.htm library/nufx-addendum.htm
http\://sources.redhat.com/bzip2/:library/nufx-addendum.htm
downloads/nulibdist.tar.gz:downloads/index.htm
http\://www.faddensoft.com/:index.htm
http\://www.fadden.com/:nulib2-manual.htm library/nulib2-preserve.htm nufxlibapi.htm index.htm library/nufx-addendum.htm
http\://www.faddensoft.com/ciderpress/:downloads/index.htm index.htm
mailto\:fadden@fadden.com:bugs.htm
http\://www.nulib.com/:nulib2-manual.htm library/nulib2-preserve.htm nufxlibapi.htm library/nufx-addendum.htm
http\://www.fadden.com/dl-apple2/:library/index.htm
http\://sourceforge.net/projects/nulib2/:downloads/index.htm
http\://sourceforge.net/sflogo.php:downloads/index.htm index.htm
http\://sourceforge.net:index.htm
downloads/nulib2_win32.zip:downloads/index.htm

28
_vti_pvt/service.cnf Normal file
View File

@ -0,0 +1,28 @@
vti_encoding:SR|utf8-nl
vti_casesensitiveurls:IX|0
vti_textextensions:SX|.txt.
vti_featurelist:VX|vti_ACAll vti_ServiceMarkUrlDirBrowse vti_ServiceMarkUrlDirExec vti_ServiceMarkUrlDirScript vti_ServerEmailTransport vti_ServerIndexServer vti_ServerASP
vti_httpdversion:SX|FrontPage DBW
vti_ignorekeyboard:IR|0
vti_navbuttonuplabel:SR|Up
vti_dependenciesood:IR|1
vti_webservertype:SR|diskweb
vti_categories:VR|Travel Expense\\ Report Business Competition Goals/Objectives Ideas Miscellaneous Waiting VIP In\\ Process Planning Schedule
vti_navbuttonnextlabel:SR|Next
vti_approvallevels:VR|Content\\ Review Legal\\ Review Code\\ Review Manager\\ Review
vti_timecreated:TR|22 Dec 1999 22:47:08 -0000
vti_extenderversion:SR|4.0.2.2717
vti_navbuttonprevlabel:SR|Back
vti_borderdefault:SR|t
vti_longfilenames:IX|1
vti_welcomenames:VX|index.htm index.html default.htm default.html welcome.htm welcome.html home.htm home.html
vti_insecureserverurl:SR|file://
vti_disableautoimgsizeexts:SX|.asp
vti_oldestcompatibleversion:SR|2.0.0.0
vti_restartmanual:IX|0
vti_defaultcharset:SR|windows-1252
vti_defaultlanguage:SR|en
vti_publishmetainfokeys:VR|vti_assignedto vti_approvallevel vti_categories vti_description
vti_autorecalc:IX|1
vti_htmlextensions:SX|.htm.html.shtml.shtm.stm.htt.htx.asp.alx.asa.
vti_navbuttonhomelabel:SR|Home

0
_vti_pvt/service.lck Normal file
View File

1
_vti_pvt/services.cnf Normal file
View File

@ -0,0 +1 @@
/

11
_vti_pvt/structure.cnf Normal file
View File

@ -0,0 +1,11 @@
3.0.0.507
1008
1000,index.htm,0,NuLib Home Page,0,945985133,1
vti_globalpage:BW|true
1001,downloads/index.htm,0,NuLib Downloads,1000,947902101,0
1003,library/index.htm,0,NuLib Library,1000,949192642,0
1007,nulib2-manual.htm,0,NuLib2 Manual,1000,948062548,0
1002,nufxlibapi.htm,0,NufxLib API,1000,946023114,0
1004,bugs.htm,0,Bugs & Features,1000,950147319,0
1005,library/nufx-addendum.htm,0,NuFX Addendum,1003,948051434,0
1006,library/nulib2-preserve.htm,0,ProDOS Attribute Preservation,1003,948076779,0

80
bugs.htm Normal file
View File

@ -0,0 +1,80 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Bugs &amp; Features</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong>Bugs &amp; Features</strong></font><br>
<nobr>[&nbsp;<a href="index.htm">Home</a>&nbsp;]</nobr> <nobr>[&nbsp;<a href="downloads/index.htm">NuLib&nbsp;Downloads</a>&nbsp;]</nobr> <nobr>[&nbsp;<a href="library/index.htm">NuLib&nbsp;Library</a>&nbsp;]</nobr> <nobr>[&nbsp;<a href="nulib2-manual.htm">NuLib2&nbsp;Manual</a>&nbsp;]</nobr> <nobr>[&nbsp;<a href="nufxlibapi.htm">NufxLib&nbsp;API</a>&nbsp;]</nobr> <nobr>[&nbsp;Bugs&nbsp;&amp;&nbsp;Features&nbsp;]</nobr></p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<p align="left">&nbsp;</p>
<p align="left">Skip down to the bottom for the <a href="#todo"> list of suggested
features</a>.</p>
<p align="left">NuLib2 and NufxLib will always have the same version number for
the time being, because they're being distributed together.&nbsp; It's less
confusing that way.</p>
<p align="left">&nbsp;</p>
<h2 align="left">Known Bugs - NufxLib v2.0</h2>
<p align="left">None so far.</p>
<p align="left">&nbsp;</p>
<h2 align="left">Known Bugs - NuLib2 v2.0</h2>
<p align="left">None so far.</p>
<p align="left">&nbsp;</p>
<h2 align="left">Reporting New Bugs</h2>
<p align="left">Some good things to include in a bug report:</p>
<ul>
<li>
<p align="left">What version of NuLib2 and NufxLib are you using?</li>
<li>
<p align="left">What compile options were used (NuLib2 shows this at the top
of the usage screen; just type &quot;nulib2&quot;)?</li>
<li>
<p align="left">What operating system are you running?&nbsp; What version?</li>
<li>
<p align="left">Did you build it yourself or get a binary from a web
site?&nbsp; Did you make any changes?&nbsp; What compiler did you use?</li>
<li>
<p align="left">What exactly do you have to do to make the bug occur?&nbsp;
(If it's a NuLib2 problem, list the command, and preferably where I can find
a copy of the archive or the files involved.&nbsp; If it's a NufxLib
problem, all of the above, plus a sequence of Exerciser commands that make
the bug happen.)</li>
</ul>
<p align="left">It's difficult to fix a bug if it isn't repeatable or if it only
occurs on an operating system I don't have access to.&nbsp; The more obscure
your circumstances, the more details you will need to provide.</p>
<p align="left">Please use the github issue tracker to file bugs.</p>
<p align="left">&nbsp;</p>
<h2 align="left"><a name="todo">Product &quot;To Do&quot; List</a></h2>
<p>For the NuLib2 application:</p>
<ul>
<li>Extract files to AppleDouble format.&nbsp; This would allow UNIX
AppleShare servers like netatalk to serve up extracted files immediately,
and preserve all file attributes.</li>
<li>Support .2MG disk images automatically when adding and extracting.</li>
<li>Add BinSCII support.</li>
<li>Need some regression tests.</li>
</ul>
<p>For NufxLib:</p>
<ul>
<li>Add native resource fork support (for systems like Mac OS and GS/OS).</li>
<li>Ought to store empty directories.</li>
<li>Make name-comparison sensitivity (for get-by-name and duplicate checking)
configurable.</li>
<li>Need a complete set of regression tests.</li>
</ul>
<p align="left">&nbsp;
<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

4
downloads/_vti_cnf/gsnulib.shk Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|31 Jan 2000 05:35:38 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|downloads/index.htm

24
downloads/_vti_cnf/index.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_timecreated:TR|23 Dec 1999 21:39:46 -0000
vti_timelastmodified:TR|19 Feb 2007 23:57:54 -0000
vti_filesize:IR|4569
vti_title:SR|NuLib Downloads
vti_metatags:VR|HTTP-EQUIV=Content-Language en-us HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.8912
vti_backlinkinfo:VX|index.htm
vti_nexttolasttimemodified:TR|19 Feb 2007 23:53:31 -0000
vti_shadowfiles:VX|
vti_modifiedby:SR|fadden
vti_cacheddtm:TX|19 Feb 2007 23:57:54 -0000
vti_cachedlinkinfo:VX|H|http://www.faddensoft.com/ciderpress/ H|nulibdist.tar.gz H|http://sourceforge.net/projects/nulib2/ S|http://sourceforge.net/sflogo.php H|nulib2_win32.zip H|nulib325.tar.gz H|nulib_win32.zip H|nulib-tb.zip H|gsnulib.shk H|../library/index.htm
vti_cachedsvcrellinks:VX|NHHS|http://www.faddensoft.com/ciderpress/ NHUS|downloads/nulibdist.tar.gz NHHS|http://sourceforge.net/projects/nulib2/ NSHS|http://sourceforge.net/sflogo.php NHUS|downloads/nulib2_win32.zip FHUS|downloads/nulib325.tar.gz FHUS|downloads/nulib_win32.zip FHUS|downloads/nulib-tb.zip FHUS|downloads/gsnulib.shk FHUS|library/index.htm
vti_cachedtitle:SR|NuLib Downloads
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

3
downloads/_vti_cnf/nufxdll-dev-202.zip Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|10 Mar 2004 21:56:34 -0000
vti_extenderversion:SR|4.0.2.7802

3
downloads/_vti_cnf/nufxdll-dev-203.zip Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|11 Oct 2004 22:43:46 -0000
vti_extenderversion:SR|4.0.2.7802

4
downloads/_vti_cnf/nufxdll-dev-210.zip Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Sep 2005 05:34:35 -0000
vti_extenderversion:SR|4.0.2.8912
vti_backlinkinfo:VX|

4
downloads/_vti_cnf/nulib-tb.zip Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|16 Jan 2000 20:55:18 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|downloads/index.htm

3
downloads/_vti_cnf/nulib2_101_win32.zip Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|23 May 2000 00:54:24 -0000
vti_extenderversion:SR|4.0.2.5526

4
downloads/_vti_cnf/nulib2_110_win32.zip Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|11 Oct 2002 23:01:26 -0000
vti_extenderversion:SR|4.0.2.5526
vti_backlinkinfo:VX|

4
downloads/_vti_cnf/nulib2_200_win32.zip Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Mar 2003 02:47:06 -0000
vti_extenderversion:SR|4.0.2.6513
vti_backlinkinfo:VX|

4
downloads/_vti_cnf/nulib2_201_win32.zip Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|16 Oct 2003 22:59:04 -0000
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|

4
downloads/_vti_cnf/nulib2_202_win32.zip Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|10 Mar 2004 21:43:56 -0000
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|

3
downloads/_vti_cnf/nulib2_203_win32.zip Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|11 Oct 2004 22:30:28 -0000
vti_extenderversion:SR|4.0.2.7802

3
downloads/_vti_cnf/nulib2_210_win32.zip Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Sep 2005 05:31:47 -0000
vti_extenderversion:SR|4.0.2.8912

3
downloads/_vti_cnf/nulib2_211_win32.zip Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Feb 2006 01:54:21 -0000
vti_extenderversion:SR|4.0.2.8912

3
downloads/_vti_cnf/nulib2_220_win32.zip Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|20 Feb 2007 00:45:59 -0000
vti_extenderversion:SR|4.0.2.8912

4
downloads/_vti_cnf/nulib325.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|07 Jun 1998 05:06:02 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|downloads/index.htm library/index.htm

4
downloads/_vti_cnf/nulib_win32.zip Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|16 Jan 2000 21:01:54 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|downloads/index.htm

3
downloads/_vti_cnf/nulibdist-100.tar.gz Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 May 2000 01:04:30 -0000
vti_extenderversion:SR|4.0.2.5526

3
downloads/_vti_cnf/nulibdist-101.tar.gz Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|23 May 2000 00:46:16 -0000
vti_extenderversion:SR|4.0.2.5526

4
downloads/_vti_cnf/nulibdist-110.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|11 Oct 2002 22:59:56 -0000
vti_extenderversion:SR|4.0.2.5526
vti_backlinkinfo:VX|

4
downloads/_vti_cnf/nulibdist-200.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Mar 2003 02:47:00 -0000
vti_extenderversion:SR|4.0.2.6513
vti_backlinkinfo:VX|

4
downloads/_vti_cnf/nulibdist-201.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|16 Oct 2003 22:59:04 -0000
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|

4
downloads/_vti_cnf/nulibdist-202.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|10 Mar 2004 21:38:18 -0000
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|

3
downloads/_vti_cnf/nulibdist-203.tar.gz Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|11 Oct 2004 22:25:22 -0000
vti_extenderversion:SR|4.0.2.7802

3
downloads/_vti_cnf/nulibdist-210.tar.gz Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Sep 2005 05:31:43 -0000
vti_extenderversion:SR|4.0.2.8912

3
downloads/_vti_cnf/nulibdist-211.tar.gz Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Feb 2006 01:54:39 -0000
vti_extenderversion:SR|4.0.2.8912

3
downloads/_vti_cnf/nulibdist-220.tar.gz Normal file
View File

@ -0,0 +1,3 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|19 Feb 2007 23:46:00 -0000
vti_extenderversion:SR|4.0.2.8912

BIN
downloads/gsnulib.shk Normal file
View File

Binary file not shown.

84
downloads/index.htm Normal file
View File

@ -0,0 +1,84 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>NuLib Downloads</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong>NuLib Downloads</strong></font><br>
<nobr>[&nbsp;<a href="../index.htm">Home</a>&nbsp;]</nobr> <nobr>[&nbsp;NuLib&nbsp;Downloads&nbsp;]</nobr> <nobr>[&nbsp;<a href="../library/index.htm">NuLib&nbsp;Library</a>&nbsp;]</nobr> <nobr>[&nbsp;<a href="../nulib2-manual.htm">NuLib2&nbsp;Manual</a>&nbsp;]</nobr> <nobr>[&nbsp;<a href="../nufxlibapi.htm">NufxLib&nbsp;API</a>&nbsp;]</nobr> <nobr>[&nbsp;<a href="../bugs.htm">Bugs&nbsp;&amp;&nbsp;Features</a>&nbsp;]</nobr></p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<p>&nbsp;</p>
<p><b><font color="#008000">Hey!</font></b>&nbsp; If you're looking for a GUI &quot;ShrinkIt for Windows&quot;, take a look at <a href="http://ciderpress.sourceforge.net/">CiderPress</a>, which uses NufxLib to access ShrinkIt archives.</p>
<h2>NuLib2 and NufxLib</h2>
<p>Source code and Win32 binaries are available for download from
<a href="https://github.com/fadden/nulib2">github</a>. Click on
the "releases" link.</p>
<p>NuLib2 and NufxLib are packaged together.&nbsp; Instructions for
building them are included with the sources.&nbsp; Version 2.2.2 has been built
and tested on the following systems:</p>
<ul>
<li>[x86 MSVC++2013] Windows 7</li>
<li>[x86] Ubuntu 14.04 (gcc 4.8.2)</li>
</ul>
Earlier versions have also been tested on:
<ul>
<li>[x86 MSVC++6.0] Windows XP SP2</li>
<li>[x86] Fedora Core 4 (gcc 4.0)</li>
<li>[x86] Darwin (Mac OS X)</li>
<li>[x86 MSVC++6.0] Windows 2000 Professional SP4</li>
<li>[x86 MSVC++6.0] Windows XP Professional SP1, SP2</li>
<li>[x86 MSVC++6.0] Windows 98SE</li>
<li>[x86 DJGPP] Windows 98SE</li>
<li>[x86 MSVC++6.0] Windows NT 4 Server</li>
<li>[x86] Linux (Debian 2.2)</li>
<li>[x86] Linux (Red Hat 5.x, 6.0. 6.1, 7.3, 8.0, 9.0, FC3, FC4)</li>
<li>[x86] Solaris 7, 8</li>
<li>[x86] FreeBSD (4.7-RC and 4.8)</li>
<li>[x86] OpenBSD 2.5 and 2.6</li>
<li>[x86] BeOS 4.5.2</li>
<li>[PPC - G4] Mac OS X 10.2 SERVER Edition</li>
<li>[PPC - RS/6000] Linux 2.2 (Debian 3.0)</li>
<li>[PPC - xlc] AIX 4.3</li>
<li>[PPC - mwerks] BeOS 4.5.2</li>
<li>[Alpha] Linux 2.2 (Debian 3.0)</li>
<li>[AMD64] Linux 2.4 (SuSE 8 ES on Opteron)</li>
<li>[Sparc - R220] Sun Solaris 8</li>
<li>[Sparc] SunOS 4.1.4</li>
<li>[Sparc - SunPro C] Solaris 2.6</li>
<li>[Sparc] Solaris 7</li>
<li>[CerfCube SA1110] Linux 2.4 (Debian 3.0)</li>
</ul>
<h2>NuLib &quot;Classic&quot;</h2>
<p>The original NuLib has been ported to many different systems.&nbsp; Version
3.2.5 is functionally similar to v3.2.4, but the source code and documentation
were cleaned up by Devin Reade, making it easier to build.&nbsp; NuLib2 is
generally superior, but NuLib does have the advantage of running under 16-bit MS-DOS
and GS/OS.</p>
<p>Documentation is included with the sources and binaries.</p>
<p>Source code:</p>
<ul>
<li><a href="nulib325.tar.gz">NuLib v3.2.5 source code</a> (113K .tar.gz)</li>
</ul>
<p>Binaries:</p>
<ul>
<li><a href="nulib_win32.zip">Win32 (Visual C++) port of NuLib v3.2.4</a> (67K
zip)</li>
<li><a href="nulib-tb.zip">Tom Baker's 16-bit MS-DOS (Borland C) port of NuLib
v3.0.3</a> (57K zip)</li>
<li><a href="gsnulib.shk">IIgs shell port of NuLib v3.2.2</a> (84K shk)</li>
</ul>
Source code for older versions of the original NuLib are available in the <a href="../library/index.htm">library</a>.
<p>&nbsp;<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

BIN
downloads/nufxdll-dev-202.zip Normal file
View File

Binary file not shown.

BIN
downloads/nufxdll-dev-203.zip Normal file
View File

Binary file not shown.

BIN
downloads/nufxdll-dev-210.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib-tb.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_101_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_110_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_200_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_201_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_202_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_203_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_210_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_211_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib2_220_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulib325.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulib_win32.zip Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-100.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-101.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-110.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-200.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-201.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-202.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-203.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-210.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-211.tar.gz Normal file
View File

Binary file not shown.

BIN
downloads/nulibdist-220.tar.gz Normal file
View File

Binary file not shown.

167
index.htm Normal file
View File

@ -0,0 +1,167 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta http-equiv="Content-Language" content="en-us">
<title>NuLib Home Page</title>
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Border" content>
<meta name="description"
content="Home page for NuLib, NuLib2, NufxLib, ShrinkIt, and NuFX (SHK) archives">
<meta name="keywords"
content="nulib, nulib2, nufxlib, shk, sdk, bxy, bse, shrinkit, nufx, apple, apple2, emulator">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<h1 align="center">NuLib Home Page</h1>
<p align="center"><u><b>Shortcuts</b></u><br>
go to the <a href="downloads/index.htm">downloads</a> area<br>
read the <a href="nulib2-manual.htm"> NuLib2 manual</a><br>
see the <a href="nufxlibapi.htm">NufxLib library API</a> documentation<br>
<a href="bugs.htm">report a bug</a> in NufxLib or NuLib2<br>
check <a href="library/index.htm">the library</a> for old programs and misc docs</p>
<p>&nbsp;</p>
<p>This is the home page for NuLib, NuLib2, NufxLib, and various items related
to ShrinkIt and NuFX archives.</p>
<p>&nbsp;</p>
<h2>What is NuLib?</h2>
<p>NuLib is a disk and file archive program, similar in principle to PKZIP.&nbsp; Instead of ZIP
archives, it manipulates NuFX archives, which are usually identified with
&quot;.SHK&quot;, &quot;.SDK&quot;, or &quot;.BXY&quot;.</p>
<p>The &quot;.SHK&quot; file extension is derived from ShrinkIt, the de facto
archiving standard for Apple II computers.&nbsp; Both NuFX and ShrinkIt were developed by Andy Nicholas,
and were initially released in January of 1989.</p>
<p>In mid-1989, while a sophomore in college, I started playing around
with the file format.&nbsp; My goal was to write a simple program that could
list the contents of a NuFX file.&nbsp; I had recently finished my first class
on C programming, and wanted a small project to play around with.&nbsp; I never
intended to go any further with it than just being able to list files.</p>
<p>Three name changes (NuView to NuARC to CShrink to NuLib) and more than three
years later, NuLib was a full-featured archiver, and the code had finally settled down to where it could be left
alone.&nbsp; Except for a major overhaul by Devin Reade in late 1996, NuLib
hasn't changed much since.</p>
<h2>What is NuLib2?</h2>
<p>NuLib was functional, but had a number of flaws.&nbsp; It couldn't handle
resource forks, it was clumsy to use with BXY (ShrinkIt wrapped in Binary II)
archives, it used more memory than it needed to, and some features -- notably
the archive integrity test -- were entirely broken.&nbsp; Due to generally poor
architecture, it was difficult to fix problems and add features.</p>
<p>NuLib2 is a replacement for NuLib.&nbsp; It does pretty much everything the
original NuLib did, and adds a number of new features.&nbsp; NuLib2 is
distributed as source code, under the terms of the BSD License.</p>
<p>The <a href="nulib2-manual.htm">NuLib2 manual</a> has a quick comparison of
the two programs.</p>
<p>One additional &quot;feature&quot; of NuLib2: it was built on top of NufxLib.</p>
<h2>What is NufxLib?</h2>
<p>NufxLib is a NuFX file archive manipulation library.&nbsp; Unlike most other
compression library products, NufxLib goes beyond extracting and listing files.&nbsp;
Full support for additions, deletions, and renaming of archived files is
supported, with a transaction-oriented interface for maximum efficiency and
reliability.</p>
<p>A thorough description of the library's features and interface is available <a href="nufxlibapi.htm">here</a>.&nbsp;
NufxLib is distributed as source code under the terms of the BSD License.</p>
<p>Possible uses for NufxLib:</p>
<ul>
<li>Command-line applications like NuLib2.</li>
<li>GUI applications like <a href="http://www.faddensoft.com/ciderpress/">CiderPress</a>,
which can isolate ShrinkIt code in a DLL.</li>
<li>Automatic handling of .SHK archives in Apple II emulators and 2IMG
converters.</li>
<li>Possible inclusion of NuFX support in mainstream applications like WinZip.</li>
<li>Embedded applications, such as a filesystem driver that transparently
unpacks NuFX archives (a la &quot;zipfolders&quot;).</li>
</ul>
<h2>Why did I do this?</h2>
<p>In late 1997, I cranked up my Apple IIgs for the first time in a long
while.&nbsp; It failed to boot.&nbsp; The old 100MB hard drive had seized up
from &quot;stiction&quot;.&nbsp; A friend of mine and I managed to resurrect
that drive and a second 80MB hard drive that had also seized up, but it was
clear the drives' days were numbered.</p>
<p>I replaced the old ones with a new 2GB drive, which was the smallest I could
find in retail stores at the time.&nbsp; It occurred to me then that it would be
useful, as well as prudent, to have a complete file archive of the contents of
my hard drive.&nbsp; GS/ShrinkIt was capable of constructing such a thing, but
couldn't extract from it because the archive was too large.&nbsp; YankIt and NuLib could do the extraction, but
were too clumsy to be useful.</p>
<p>I resolved to write a program that could handle these archives.&nbsp; I
thought it would be best to write it as a Win32 GUI application.&nbsp; However,
I also wanted a better version of NuLib for UNIX.&nbsp; The NuLib sources are a
pile of dung, so adding the features I wanted would be most easily accomplished
by rewriting the whole thing from scratch.</p>
<p>Around the middle of 1998, I started fleshing out the API for something I
called &quot;NufxLib&quot;.&nbsp; The library would do all the hard work for
both command line and GUI applications, and perhaps would be embedded into Apple
II emulators as well, allowing seamless access to ShrinkIt-compressed disk
images.</p>
<p>For the next 1.5 years, I would occasionally pick up the project and then
leave it alone for weeks at a time.&nbsp; This continued until I left a big
company for a small startup, and knew that my free time was about to evaporate
entirely.&nbsp; I decided to finish up what I could and make it available.&nbsp;
Version 1.0 was released in May of 2000.</p>
<p>In December of 2002, I decided it was time to learn how to write Windows
software.&nbsp; Learning a new system is easier when you're working with
something you know, so I decided to use NufxLib as the foundation of a Win32
application.&nbsp; The result, CiderPress, is available from the <a href="http://www.faddensoft.com/">faddenSoft</a>
web site.</p>
<h2>Visible Changes in v1.1</h2>
<p>New stuff in NufxLib v1.1:</p>
<ul>
<li>Support for SQueeze and LZC compression.&nbsp; NufxLib now fully supports
all compression formats described in the NuFX specification.</li>
<li>Support for zlib &quot;deflate&quot; compression and libbz2 BWT
compression as extensions to the
NuFX standard.</li>
<li>Compression code may be disabled to reduce the size of the library.&nbsp;
A new &quot;feature test&quot; interface allows applications to determine
which methods are supported.</li>
<li>The &quot;launder&quot; program has been updated to allow selection of the
compression format to convert to.&nbsp; (&quot;Launder&quot; converts all
files and disks in an archive from one compression format to another.)</li>
</ul>
<p>New stuff in NuLib2 v1.1:</p>
<ul>
<li>Support for listing, testing, and extracting files from Binary II archives.</li>
<li>New &quot;-z&quot; flag to use &quot;deflate&quot; or &quot;bzip2&quot;.</li>
<li>Extended help output with &quot;-h&quot; command.</li>
</ul>
<h2>Visible Changes in v2.0</h2>
<p>Version 2.0 is actually a rather small release.&nbsp; Some changes in NufxLib broke
binary compatibility, so it was necessary to increment the major version.</p>
<p>New stuff in NufxLib v2.0:</p>
<ul>
<li>Can be built as a Windows DLL.</li>
<li>NufxLib no longer tries to free memory allocated by the application (a
callback is used instead).</li>
<li>A high-ASCII text stripper is now available (useful for DOS text files and
Merlin 8 source code).</li>
</ul>
<p>New stuff in NuLib2 v2.0:</p>
<ul>
<li>Filename comparisons are now case-insensitive.</li>
<li>Can be built with NufxLib in a DLL.</li>
<li>Changed handling of reserved names like &quot;AUX&quot; so that the
original names are better preserved.&nbsp; This creates filenames with
&quot;%00&quot; in them, which could confuse older versions of NuLib2 (e.g.
&quot;nulib2 -ae %00aux&quot; will not work well in v1.x).</li>
<li>Files are now added with ':' as the pathname separator, regardless of
OS.&nbsp; Win32 handling now recognizes both '/' and '\' as path separators.</li>
<li>Disk images extracted with &quot;-ee&quot; now have &quot;.PO&quot; add to
their filenames.&nbsp; This should make it easier to load them in an Apple
II emulator.</li>
</ul>
<h2>Future Directions</h2>
<p>The code appears to be stable, so I'm going to leave it alone for a while.&nbsp;
If you're interested in developing applications with NufxLib, send a message to
fadden -at- fadden.com.</p>
<hr>
<p>NuLib, NuLib2, and NufxLib were written by <a href="http://www.fadden.com/">Andy
McFadden</a>.&nbsp; Please see the documentation for each product to
see a list of contributors.</p>
</body>
</html>

107
library/Crc16.c.txt Normal file
View File

@ -0,0 +1,107 @@
/*
* Compute 16-bit CRCs.
*
* Adapted from code in NuLib, http://www.nulib.com/.
*/
#include <assert.h>
/* define this if you want a table-based lookup */
#define CRC_TAB
#ifdef CRC_TAB
/*
* updcrc macro derived from article Copyright (C) 1986 Stephen Satchell.
* NOTE: First srgument must be in range 0 to 255.
* Second argument is referenced twice.
*
* Programmers may incorporate any or all code into their programs,
* giving proper credit within the source. Publication of the
* source routines is permitted so long as proper credit is given
* to Stephen Satchell, Satchell Evaluations and Chuck Forsberg,
* Omen Technology.
*/
/*#define updcrc(cp, crc) ( crctab[((crc >> 8) & 255)] ^ (crc << 8) ^ cp)*/
#define updcrc(cp, crc) ( (crctab[((crc >> 8) & 0xFF) ^ cp] ^ (crc << 8)) & 0xFFFF)
/* crctab calculated by Mark G. Mendel, Network Systems Corporation */
const unsigned short crctab[256] = {
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6,
0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de,
0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485,
0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d,
0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc,
0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823,
0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b,
0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12,
0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41,
0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70,
0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78,
0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f,
0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067,
0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e,
0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256,
0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c,
0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634,
0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab,
0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3,
0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92,
0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9,
0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0x0cc1,
0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8,
0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0
};
#endif
/*
* Calculate CRC on a region. Pass in seed (which can be an initial
* value -- typically zero -- or the result of an earlier computation),
* and the pointer and length of the buffer to compute on.
*
* A CRC is the result of a mathematical operation based on the
* coefficients of a polynomial when multiplied by X^16 then divided by
* the generator polynomial (X^16 + X^12 + X^5 + 1) using modulo two
* arithmetic.
*
* This routine is a slightly modified verison of one found in:
* _Advanced Programming Techniques for the Apple //gs Toolbox_
* By Morgan Davis and Dan Gookin (Compute! Publications, Inc.)
*
* This can either calculate the CRC bit-by-bit or use a table.
* Depending on CPU architecture, one may be dramatically faster than
* the other.
*/
unsigned short
CalcCRC16(unsigned short seed, const unsigned char* ptr, int count)
{
unsigned short CRC = seed;
#ifndef CRC_TAB
int x;
assert(sizeof(unsigned short) == 2); /* I think this is assumed */
#endif
do {
#ifndef CRC_TAB
CRC ^= *ptr++ << 8; /* XOR hi-byte of CRC w/dat */
for (x = 8; x; --x) /* Then, for 8 bit shifts... */
if (CRC & 0x8000) /* Test hi order bit of CRC */
CRC = CRC << 1 ^ 0x1021; /* if set, shift & XOR w/$1021 */
else
CRC <<= 1; /* Else, just shift left once. */
#else
CRC = updcrc(*ptr++, CRC); /* look up new value in table */
#endif
} while (--count);
return (CRC);
}

344
library/FTN.e00001.htm Normal file
View File

@ -0,0 +1,344 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>FTN.e00001</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong></strong></font><br>
</p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<h2>Apple II FTN - AppleSingle File</h2>
<p><a href="index.htm">Back to nulib.com library</a></p>
<hr><pre>
Apple II
File Type Notes
_____________________________________________________________________________
Developer Technical Support
File Type: $E0 (224)
Auxiliary Type: $0001
Full Name: AppleSingle File
Short Name: AppleSingle File
Revised by: Matt Deatherage January 1991
Written by: Matt Deatherage March 1989
Files of this type and auxiliary type contain a file in AppleSingle format.
Changes since March 1990: Added information about AppleSingle version 2.0.
_____________________________________________________________________________
AppleSingle is one of two standards (the other is AppleDouble) put forth by
Apple Computer, Inc. for representing files on foreign file systems while
preserving all attributes of the file's home system on file systems that do
not support the same attributes.
Experience indicated that a single format would be inadequate to cover all
cases. Two closely related formats, however, can serve most needs. Although
the primary impetus for developing these formats is storing extended files
(files with both resource and data forks) on file systems that do not support
the notion of two forks, the proposed formats are general enough that theycan be
used to represent a file from any file system on any other file system.
AppleSingle keeps all attributes and the contents of both forks in a single file
in the foreign file system, and this Note describes this file format.
AppleDouble keeps the data fork as a separate file from the file attributes and
the resource fork, and is described in the File Type Notes for File Type $E0,
Auxiliary Types $0002 and $0003.
AppleSingle is intended to be used primarily as a storage format, especially for
cases where you must store an extended file on a foreign file system and later
reconstruct the extended file. AppleDouble is more appropriate for applications
where the users of the foreign file system might want to modify the contents of
the file. Since most applications keep file data in the data fork, AppleDouble
format saves the contents of the data fork in one file.All other file
attributes, including the resource fork, are kept in a separate file.
Reasons for Using AppleSingle
There are several reasons for supporting an interchange format between file
systems. Perhaps the most germane is one of the least obvious: handling
extended files on foreign file systems which do not support extended files.
For example, the ProDOS FST in GS/OS can create an extended file on a ProDOS
disk. However, ProDOS 8 is unable to operate on the file, since it sees itas
having an unsupported storage type. If a telecommunications program or other
utility capable of transferring files is operating under ProDOS 8 andattempts to
receive an extended file, it is unable to create the file.
At this point, the application could use READ_BLOCK and WRITE_BLOCK commands,
along with a knowledge of the ProDOS file system, to create the file on its own.
However, this is strongly discouraged. The ProDOS file system format for
extended files is not documented and could change in the future. In addition,
the program could be running on a eight-bit system. If the disk is only used on
an eight-bit system, the extended files would not only be unwanted, but also
unremovable without using the disk on an Apple IIGS or later system running
GS/OS.
However, if the application is aware of the AppleSingle format, it canquickly
store an extended file in AppleSingle, leaving the conversion back to the
extended file to GS/OS, or another operating system. This is the recommended
way for ProDOS 8 applications to create and handle extended files. Useeither
AppleSingle or AppleDouble.
AppleSingle Format
An AppleSingle file contains a header followed by data. The header consists of
several fixed fields and a list of entry descriptors, each pointing to an entry.
Apple defines the following standard entries: Data Fork, Resource Fork, Real
Name (name in the home file system), Comment, Icon and File Info. Each entry is
optional, so it may not appear in the file.
Note: All numeric entries, including entries representing ProDOS data
structures (such as file type and auxiliary type) are Reverse
ordered. This is provided so any host CPU can attempt to
interpret entries in the header without having to know the
standard byte-ordering of the home file system. Therefore, in
this Note you see descriptive entries like &quot;Rev. 4 Bytes.&quot; This
serves as a reminder that all header fields are stored high byte
first, even though the notation Bytes does not imply any specific
ordering in other File Type Notes.
Also note that ASCII strings are not stored in reverse order, just non-ASCII
constants.
The Header:
Magic Number Rev. Long The Magic Number field is modeled after
the feature in UNIX. It is intended to be
used in whatever way the foreign file
system distinguishes a file as AppleSingle
format. See the section &quot;Identifying
AppleSingle Files.&quot; The Magic Number for
AppleSingle format is $00051600, which is
stored reverse as $00 $05 $16 $00 (reverse
of normal 65816/6502 order).
Version Number Rev. Long The version of AppleSingle format, in case
the format evolves (more fields may be
added to the header). The version
described here is $00010000, stored
(reverse) as $00 $01 $00 $00.
Home File System 16 Bytes A fixed-length, 16-byte ASCII string not
preceded by a length byte, but possibly
padded with blanks. Apple has defined
these values:
ProDOS $50726F444F5320202020202020202020
Macintosh $4D6163696E746F736820202020202020
MS-DOS $4D532D444F5320202020202020202020
Unix $556E9878202020202020202020202020
VAX VMS $56415820564D53202020202020202020
Apple welcomes suggestions for other file
systems that should be included in this
list.
Number of entries Rev. Word Tells how many different entries are
included in the file. This unsigned
reverse word may be zero. If it is non-
zero, then that number of entry
descriptors immediately follows this
field.
For Each Entry:
Entry ID Rev. Long Identifies the entry. Apple has defined
the following Entry IDs and their values:
1 = Data Fork
2 = Resource Fork
3 = Real Name (The file's name in the home
file system)
4 = Comment* (standard Macintosh comment)
5 = Icon, B&amp;W* (standard Macintosh black
and white icon)
6 = Icon, Color* (reserved for Macintosh
color icon)
7 = File Info (file attributes,dates, etc.)
9 = Finder Info* (standard Macintosh
Finder Info)
Entry IDs marked with asterisks (*) are
not used for most files created under
ProDOS or GS/OS. Furthermore, icon
entries probably do not appear in most
files since they are typically stored as a
bundle in the application file's resource
fork on the Macintosh. Apple reserves the
range of Entry IDs from $0 to $7FFFFFFF
for future use. The rest of the range is
available for other systems to define
their own entries. Apple does not
arbitrate the use of the rest of the
range.
Descriptions of the standard entries are
given below.
Offset Rev. Long An unsigned reverse long which indicates
the byte offset from the start of the file
to the start of the entry.
Entry Length Rev. Long An unsigned reverse long which indicates
the length of the entry in bytes. The
length may be zero.
Standard Entries:
The Real Name Entry:
The Real Name entry indicates the file's original filename in the host file
system. This is not a Pascal or C string; it is just ASCII data. The length is
indicated by the Entry Length field for the Real Name entry.
The File Info Entry:
The File Info entry (Entry ID = 7) is different for each home file system. For
ProDOS files, the entry is 16 bytes long and consists of the creationdate and
time and the modification date and time in ProDOS 8 (ProDOS 16/class zero GS/OS)
form, the access word, a two-byte file type and four-byte auxiliary type. This
is detailed in standard format below, along with defined FileInfo entries for
some other file systems.
ProDOS:
Create Date Rev. 2 Bytes Creation date packed into standard
ProDOS 8 format.
Create Time Rev. 2 Bytes Creation time packed into standard
ProDOS 8 format.
Modification Date Rev. 2 Bytes Modification date packed into
standard ProDOS 8 format.
Modification Time Rev. 2 Bytes Modification time packed into
standard ProDOS 8 format.
Access Rev. Word The file's access. This may be used
directly in ProDOS 16 or GS/OS calls; only
the low byte is significant to ProDOS 8.
File Type Rev. Word The file type of the original file. Only
the low byte is significant to ProDOS 8.
Auxiliary Type Rev. Long The auxiliary type of the original file.
Only the low word is significant to ProDOS
8.
Note: Although the ProDOS Access field, File Type and Auxiliary Type are
the same length as found in ProDOS 16 and GS/OS structures, the
Create and Modification Dates and Times are stored in two-byte
(albeit byte-reversed) ProDOS 8 format, not eight-byte Apple IIGS
format.
Macintosh:
Create Date Rev. Long Unsigned number of seconds between
January 1, 1904, and the creation time of
this file.
Modification Date Rev. Long Unsigned number of seconds between
January 1, 1904, and the last modification
of this file.
Last Backup Date Rev. Long Unsigned number of seconds between
January 1, 1904, and the last backup time
of this file.
Attributes Rev. Long 32 boolean flags. Once the bytes are
unreversed, bit zero is the locked bit and
bit one is the protected bit.
MS-DOS:
Modification Date Rev. 4 Bytes MS-DOS format modification date.
Attributes Rev. 2 Bytes MS-DOS attributes.
Unix:
Create Date/Time Rev. 4 Bytes Unix creation date and time.
Last Use Date/Time Rev. 4 Bytes Unix time for the last
time this file was used.
Last Mod. Date/Time Rev. 4 Bytes Unix time for the last
time this file was modified.
The Finder Info Entry:
The Finder Info entry (Entry ID = 9) is for files where the host file system is
Macintosh. It consists of 16 bytes of Finder Info followed by 16 bytes of
Extended Finder Info. These are the fields ioFlFndrInfo followed by
ioFlXFndrInfo, as described in Inside Macintosh, Volume IV-183. Newlycreated
files have zeroes in all Finder Info subfields. If you are creating an
AppleSingle file whose home system is Macintosh, you may zero all unknown
fields, but you may want to set the fdType and fdCreator subfields.
The Entries:
The entries themselves follow the header field and the entry descriptors.The
actual data representing each entry must be in a single, contiguous block. The
offset field in that entry's descriptor points to it. The entries could appear
in any order, but since the data fork is the entry that is most commonly
extended, Apple strongly recommends that the data fork always bekept last in the
file to facilitate its extension. Apple also recommends that those entries that
are most often read, such as Real Name, File Info (and Finder Info if present)
be kept as close as possible to the header tomaximize the probability that a
read of the first few blocks of the file retrieves these entries.
It is possible to have holes in the file (unused space between entries). To
find the holes, you must take the list of entry descriptors and sort theminto
increasing offset order. If the offset field of an entry is greater than the
offset plus the length of the previous entry (sorted), then a hole exists
between the entries. You can make use of such holes; for example, if afile's
comment is ten bytes long, you could create a hole of 190 bytes after the
comment field to easily allow for the comment to later expand to its maximum
length of 200 bytes. Because an AppleSingle file may contain holes, you must
find each entry by getting its offset from its entry descriptor, not by assuming
that it begins after the previous entry.
Byte ordering in file header fields follows 68000 convention, and each header
field has been so noted by the Reverse operator.
Identifying AppleSingle files
As this is an interchange format, from a ProDOS directory entry there is no way
to guarantee which files are AppleSingle files. Apple has allocated File Type
$E0, Auxiliary Type $0001 for files which are AppleSingle files. We strongly
encourage ProDOS 8 and GS/OS applications to use this file type and auxiliary
type assignment when creating AppleSingle files.
AppleSingle files which do not have file type $E0 and auxiliary type $0001can
most easily be identified by opening them and attempting to interpret them. If
they are not AppleSingle files, the Magic Number is not contained in the first
four bytes of the file. The chances that the file would begin with those four
bytes and not be an AppleSingle file, on a purely random basis,are 4,294,967,295
to 1. The chances that both the Magic Number and the Version bytes would be the
same in a non-AppleSingle file are roughly 1.8 x 10^19 to 1.
About AppleSingle 2.0
AppleSingle 2.0 is a revision to the original AppleSingle specification
described in this Note. AppleSingle 2.0 comes closer to the ideal of an
interchange format by allowing file information for multiple file systems in the
same AppleSingle file.
AppleSingle 2.0 basically replaces the File Info entry (ID = 7) with a File
Dates entry (ID = 8) and one or more host file system entries, such as a
Macintosh File Info entry (ID = 10), a ProDOS File Info entry (ID = 11), or an
MS-DOS File Info entry (ID = 12). Information on these entries and AppleSingle
2.0 can be found in the AppleSingle/AppleDouble Formats for Foreign Files
Developer's Note, available from APDA, AppleLink, and the Developer CD series.
Further Reference
_____________________________________________________________________________
o Inside Macintosh, Volume IV
o ProDOS 8 Technical Reference Manual
o GS/OS Reference
o AppleSingle/AppleDouble Formats for Foreign Files Developer's Note
</pre><hr>
<address>This document is Copyright by Apple Computer, Inc.</address>
<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

462
library/FTN.e000023.htm Normal file
View File

@ -0,0 +1,462 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>FTN.e000023</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong></strong></font><br>
</p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<h2>Apple II FTN - AppleDouble File</h2>
<p><a href="index.htm">Back to nulib.com library</a></p>
<hr><pre>
Apple II
File Type Notes
_____________________________________________________________________________
Developer Technical Support
File Type: $E0 (224)
Auxiliary Types: $0002 &amp; $0003
Full Name: AppleDouble Header File (Auxiliary Type $0002)
AppleDouble Data File (Auxiliary Type $0003)
Short Name: AppleDouble Header (Auxiliary Type $0002)
AppleDouble Data (Auxiliary Type $0003)
Revised by: Matt Deatherage November 1990
Written by: Matt Deatherage March 1989
Files of these types and auxiliary types contain file data in AppleDouble
format.
Changes since March 1990: Added information about AppleDouble 2.0.
_____________________________________________________________________________
AppleDouble is one of two standards (the other is AppleSingle) put forth by
Apple Computer, Inc. for representing files on foreign file systems while
preserving all attributes of the file's home system on file systems that do not
support the same attributes.
Experience indicated that a single format would be inadequate to cover all
cases. Two closely related formats, however, can serve most needs. Although
the primary impetus for developing these formats is storing extended files
(files with both resource and data forks) on file systems that do not support
the notion of two forks, the proposed formats are general enough that theycan be
used to represent a file from any file system on any other file system.
AppleDouble keeps the data fork as a separate file from the file attributes and
the resource fork, and this Note describes this file format. AppleSingle keeps
all attributes and the contents of both forks in a single file in the foreign
file system, and is described in the File Type Note for File Type$E0, Auxiliary
Type $0001.
AppleSingle is intended to be used primarily as a storage format, especially for
cases where you must store an extended file on a foreign file system and later
reconstruct the extended file. AppleDouble is more appropriate for applications
where the users of the foreign file system might want to modify the contents of
the file. Since most applications keep file data in the data fork, AppleDouble
format saves the contents of the data fork in one file.All other file
attributes, including the resource fork, are kept in a separate file.
Reasons for Using AppleDouble
There are several reasons for supporting an interchange format between file
systems. Perhaps the most germane is one of the least obvious: handling
extended files on foreign file systems which do not support extended files.
For example, the ProDOS FST in GS/OS can create an extended file on a ProDOS
disk. However, ProDOS 8 is unable to operate on the file, since it sees itas
having an unsupported storage type. If a telecommunications program or other
utility capable of transferring files is operating under ProDOS 8 andattempts to
receive an extended file, it is unable to create the file.
At this point, the application could use READ_BLOCK and WRITE_BLOCK commands,
along with a knowledge of the ProDOS file system, to create the file on its own.
However, this is strongly discouraged. The ProDOS file system format for
extended files is not documented and could change in the future. In addition,
the program could be running on a eight-bit system. If the disk is only used on
an eight-bit system, the extended files would not only be unwanted, but also
unremovable without using the disk on an Apple IIGS or later system running
GS/OS.
However, if the application is aware of the AppleDouble format, it canquickly
store an extended file in AppleDouble, leaving the conversion back to the
extended file to GS/OS, or another operating system. This is the recommended
way for ProDOS 8 applications to create and handle extended files. Useeither
AppleSingle or AppleDouble.
AppleDouble Format
AppleDouble consists of two files, an AppleDouble Header File and an AppleDouble
Data File. The AppleDouble Header file contains a headerfollowed by data. The
header consists of several fixed fields and a list of entry descriptors, each
pointing to an entry. Apple defines these standardentries: Resource Fork, Real
Name (name in the home file system), Comment, Icon and File Info. Each entry is
optional, so it may not appear in the file. Wealso define the new entry Data
Pathname, pointing to the pathname of the AppleDouble Data File. The Header
File has exactly the same format as an AppleSingle file, except it has no data
fork entry. The AppleDouble DataFile consists of just the data fork of the
file, with no extra header at all.
Note: All numeric entries, including entries representing ProDOS data
structures (such as file type and auxiliary type) are Reverse
ordered. This is provided so any host CPU can attempt to
interpret entries in the header without having to know the
standard byte-ordering of the home file system. Therefore, in
this Note you see descriptive entries like &quot;Rev. 4 Bytes.&quot; This
serves as a reminder that all header fields are stored high byte
first, even though the notation Bytes does not imply any specific
ordering in other File Type Notes.
Also note that ASCII strings are not stored in reverse order, just non-ASCII
constants.
The Header in the Header File:
Magic Number Rev. Long The Magic Number field is modeled after
the feature in UNIX. It is intended to be
used in whatever way the foreign file
system distinguishes a file as AppleDouble
format. See the section &quot;Identifying
AppleDouble Files.&quot; The Magic Number for
AppleDouble format is $00051607, which is
stored reverse as $00 $05 $16 $07 (reverse
of normal 65816/6502 order).
Version Number Rev. Long The version of AppleDouble format, in case
the format evolves (more fields may be
added to the header). The version
described here is $00010000, stored
(reverse) as $00 $01 $00 $00.
Home File System 16 Bytes A fixed-length, 16-byte ASCII string not
preceded by a length byte, but possibly
padded with blanks. Apple has defined
these values:
ProDOS $50726F444F5320202020202020202020
Macintosh $4D6163696E746F736820202020202020
MS-DOS $4D532D444F5320202020202020202020
Unix $556E9878202020202020202020202020
VAX VMS $56415820564D53202020202020202020
Apple welcomes suggestions for other file
systems that should be included in this
list.
Number of entries Rev. Word Tells how many different entries are
included in the file. This unsigned
reverse word may be zero. If it is non-
zero, then that number of entry
descriptors immediately follows this
field.
For Each Entry:
Entry ID Rev. Long Identifies the entry. Apple has defined
the following Entry IDs and their values:
1 = Data Fork
2 = Resource Fork
3 = Real Name (The file's name in the home
file system)
4 = Comment* (standard Macintosh comment)
5 = Icon, B&amp;W* (standard Macintosh black
and white icon)
6 = Icon, Color* (reserved for Macintosh
color icon)
7 = File Info (file attributes,dates, etc.)
9 = Finder Info* (standard Macintosh
Finder Info)
Entry IDs marked with asterisks (*) are
not used for most files created under
ProDOS or GS/OS. Furthermore, icon
entries probably do not appear in most
files since they are typically stored as a
bundle in the application file's resource
fork on the Macintosh. Apple reserves the
range of Entry IDs from $0 to $7FFFFFFF
for future use. The rest of the range is
available for other systems to define
their own entries. Apple does not
arbitrate the use of the rest of the
range.
Descriptions of the standard entries are
given below.
Offset Rev. Long An unsigned reverse long which indicates
the byte offset from the start of the file
to the start of the entry.
Entry Length Rev. Long An unsigned reverse long which indicates
the length of the entry in bytes. The
length may be zero.
Standard Entries:
The Real Name Entry:
The Real Name entry indicates the file's original filename in the host file
system. This is not a Pascal or C string; it is just ASCII data. The length is
indicated by the Entry Length field for the Real Name entry.
The File Info Entry:
The File Info entry (Entry ID = 7) is different for each home file system. For
ProDOS files, the entry is 16 bytes long and consists of the creationdate and
time and the modification date and time in ProDOS 8 (ProDOS 16/class zero GS/OS)
form, the access word, a two-byte file type and four-byte auxiliary type. This
is detailed in standard format below, along with defined FileInfo entries for
some other file systems.
ProDOS:
Create Date Rev. 2 Bytes Creation date packed into standard
ProDOS 8 format.
Create Time Rev. 2 Bytes Creation time packed into standard
ProDOS 8 format.
Modification Date Rev. 2 Bytes Modification date packed into
standard ProDOS 8 format.
Modification Time Rev. 2 Bytes Modification time packed into
standard ProDOS 8 format.
Access Rev. Word The file's access. This may be used
directly in ProDOS 16 or GS/OS calls; only
the low byte is significant to ProDOS 8.
File Type Rev. Word The file type of the original file. Only
the low byte is significant to ProDOS 8.
Auxiliary Type Rev. Long The auxiliary type of the original file.
Only the low word is significant to ProDOS
8.
Note: Although the ProDOS Access field, File Type and Auxiliary Type are
the same length as found in ProDOS 16 and GS/OS structures, the
Create and Modification Dates and Times are stored in two-byte
(albeit byte-reversed) ProDOS 8 format, not eight-byte Apple IIGS
format.
Macintosh:
Create Date Rev. Long Unsigned number of seconds between
January 1, 1904, and the creation time of
this file.
Modification Date Rev. Long Unsigned number of seconds between
January 1, 1904, and the last modification
of this file.
Last Backup Date Rev. Long Unsigned number of seconds between
January 1, 1904, and the last backup time
of this file.
Attributes Rev. Long 32 boolean flags. Once the bytes are
unreversed, bit zero is the locked bit and
bit one is the protected bit.
MS-DOS:
Modification Date Rev. 4 Bytes MS-DOS format modification date.
Attributes Rev. 2 Bytes MS-DOS attributes.
Unix:
Create Date/Time Rev. 4 Bytes Unix creation date and time.
Last Use Date/Time Rev. 4 Bytes Unix time for the last
time this file was used.
Last Mod. Date/Time Rev. 4 Bytes Unix time for the last
time this file was modified.
The Finder Info Entry:
The Finder Info entry (Entry ID = 9) is for files where the host file system is
Macintosh. It consists of 16 bytes of Finder Info followed by 16 bytes of
Extended Finder Info. These are the fields ioFlFndrInfo followed by
ioFlXFndrInfo, as described in Inside Macintosh, Volume IV-183. Newlycreated
files have zeroes in all Finder Info subfields. If you are creating an
AppleDouble file whose home system is Macintosh, you may zero all unknown
fields, but you may want to set the fdType and fdCreator subfields.
The Data Pathname Entry:
The Data Pathname entry (Entry ID = 100) is defined for the first time inthis
Note. It consists of a class one GS/OS input string noting the pathname of the
AppleDouble Data File as originally created:
Path Length Rev. Word The length of the pathname.
Pathname Bytes ASCII pathname of the AppleDouble Data File
when created.
For strategies on using this segment (or not using it) to find theAppleDouble
Data File, see the section &quot;Finding the AppleDouble Data File.&quot;
The Entries in the Header File:
The entries themselves follow the header field and the entry descriptors.The
actual data representing each entry must be in a single, contiguous block. The
offset field in that entry's descriptor points to it. The entries could appear
in any order, but since the data fork is the entry that is most commonly
extended, Apple strongly recommends that the data fork always bekept last in the
file to facilitate its extension. Apple also recommends that those entries that
are most often read, such as Real Name, File Info (and Finder Info if present)
be kept as close as possible to the header tomaximize the probability that a
read of the first few blocks of the file retrieves these entries.
It is possible to have holes in the file (unused space between entries). To
find the holes, you must take the list of entry descriptors and sort theminto
increasing offset order. If the offset field of an entry is greater than the
offset plus the length of the previous entry (sorted), then a hole exists
between the entries. You can make use of such holes; for example, if afile's
comment is ten bytes long, you could create a hole of 190 bytes after the
comment field to easily allow for the comment to later expand to its maximum
length of 200 bytes. Because an AppleDouble file may contain holes, you must
find each entry by getting its offset from its entry descriptor, not by assuming
that it begins after the previous entry.
Byte ordering in file header fields follows 68000 convention, and each header
field has been so noted by the Reverse operator.
The AppleDouble Data File
The AppleDouble Data File is simply the data fork of the original file contained
in a file of its own. You may create it with a File Type and Auxiliary Type
assignment best suited to it, if desired. For example, if the program creating
the AppleDouble Data File knows that the data fork contains strictly ASCII text,
it could create the file with File Type $04 (Text File) so that other
applications can deal with it accordingly.
If the creating program wishes to make no assumptions about the content ofthe
data fork, it is encouraged to create the AppleDouble Data File with filetype
$E0 and auxiliary type $0003. This identifies the file as an AppleDoubleData
File.
Identifying AppleDouble Files
As this is an interchange format, from a ProDOS directory entry there is no way
to guarantee which files are AppleDouble files. Apple has allocated File Type
$E0, Auxiliary Type $0002 for files which are AppleDouble Header Files, and File
Type $E0, Auxiliary Type $0003 for files which are AppleDouble Data Files. We
strongly encourage ProDOS 8 and GS/OS applications to use these file type and
auxiliary type assignments when creating AppleDouble files.
AppleDouble files which do not have file type $E0 and auxiliary type $0002 or
$0003 can most easily be identified by opening them and attempting to interpret
them. If it is not an AppleDouble Header File, the Magic Number is not
contained in the first four bytes of the file. The chances that the file would
begin with those four bytes and not be an AppleDouble Header File, on a purely
random basis, are 4,294,967,295 to 1. The chances that both the Magic Number
and the Version bytes would be the same in a non-AppleSingle file are roughly
1.8 x 10^19 to 1.
Finding the AppleDouble Data File
Since the AppleDouble Data File can be stored anywhere, with any file typeand
auxiliary type, a program may have to make an effort to find it. Werecommend
the following steps:
1. If the Data Pathname segment exists, use that pathname. If the
path specified in the segment does not exist, extract the file
name from the end of the pathname and look in the current
directory for that file name.
2. If Step 1 does not find the file (or if the Data Pathname segment
does not exist), perform the appropriate Home File System
algorithm (described below) to generate the name of the
AppleDouble Data File from the AppleDouble Header File.
3. If none of the file names generated in Step 2 are found, ask the
user where the AppleDouble Data File is located.
Filename Conventions:
Apple proposes the following standard for identifying AppleDouble Header File
names and AppleDouble Data File names from the file's real name.
ProDOS:
To generate the AppleDouble Data File name, use character substitution or
deletion to remove illegal characters, and use truncation if necessary to
reduce the length of the name to two characters less than the maximum file
name length. This would be a maximum of 13, since the maximum file name
length is 15.
To generate the AppleDouble Header File name, prefix the AppleDouble DataFile
name with the characters &quot;R.&quot; (uppercase R period).
For example, the file name &quot;This is a Foo File&quot; could translate to an
AppleDouble Data File Name of &quot;THIS.IS.A.FOO.&quot; The AppleDouble Header File
name would then be &quot;R.THIS.IS.A.FOO.&quot;
Unix:
To generate the AppleDouble Data File name, use character substitution to
replace any illegal characters with an underscore (_). Since different Unix
systems have different requirements on maximum file name length, do not
explicitly truncate the name to a specific length. Rather, allow the
truncation to be done by the Unix functions create(), open(), etc.
To generate the AppleDouble Header File name, A/UX (Apple's implementation of
Unix for Macintosh computers) prefixes a percent sign (%) to the AppleDouble
Data File name. If necessary, truncate the last character to keep the file name
within the legal length range. Other Unix systems may prefix adirectory name
(e.g., &quot;.AppleDouble/&quot;) to the AppleDouble Data File name to create the name of
the AppleDouble Header File. In this scheme, all AppleDouble Header Files
corresponding to AppleDouble Data files are kept together in a single
subdirectory.
MS-DOS:
To generate the AppleDouble Data File name, use character substitution or
deletion to remove illegal characters, and use truncation if necessary to
reduce the length of the name to eight characters. Then add the MS-DOS
extension that is most appropriate to the file (such as &quot;TXT&quot; for a pure text
file).
To generate the AppleDouble Header File name, add the extension &quot;.ADF&quot; to the
eight-character file name.
In any instance, most programs probably wish to display the names being used
for both AppleDouble files, so that the user may keep track of them on disk.
AppleDouble name derivations will be defined for all other file systems of
interest. This allows applications running on the foreign file system (and
users as well) to see easily which files are AppleDouble pairs.Knowledgeable
users, if they know the derivation, could rename or move the files so as to
preserve the connection between the two. However, there is no guaranteed way to
prevent one file of the pair from being inconsistently renamed, moved, or
deleted.
About AppleDouble 2.0
AppleDouble 2.0 is a revision to the original AppleDouble specification
described in this Note. AppleDouble 2.0 comes closer to the ideal of an
interchange format by allowing file information for multiple file systems in the
same AppleDouble file.
AppleDouble 2.0 basically replaces the File Info entry (ID = 7) with a File
Dates entry (ID = 8) and one or more host file system entries, such as a
Macintosh File Info entry (ID = 10), a ProDOS File Info entry (ID = 11), or an
MS-DOS File Info entry (ID = 12). Information on these entries and AppleDouble
2.0 can be found in the AppleSingle/AppleDouble Formats for Foreign Files
Developer's Note, available from APDA, AppleLink, and the Developer CD series.
Further Reference
_____________________________________________________________________________
o Inside Macintosh, Volume IV
o ProDOS 8 Technical Reference Manual
o GS/OS Reference
o AppleSingle/AppleDouble Formats for Foreign Files Developer's Note
</pre><hr>
<address>This document is Copyright by Apple Computer, Inc.</address>
<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

255
library/FTN.e00005.htm Normal file
View File

@ -0,0 +1,255 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>FTN.e00005</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong></strong></font><br>
</p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<h2>Apple II FTN - DiskCopy disk image</h2>
<p><a href="index.htm">Back to nulib.com library</a></p>
<hr><pre>
Apple II
File Type Notes
_____________________________________________________________________________
Developer Technical Support
File Type: $E0 (224)
Auxiliary Type: $0005
Full Name: DiskCopy disk image
Short Name: DiskCopy disk image
Written by: Matt Deatherage, Dave Lyons &amp; Steve Christensen May 1992
Files of this type and auxiliary type contain disk images from Apple's
DiskCopy program on the Macintosh.
_____________________________________________________________________________
DiskCopy is a program written by Steve Christensen of Apple Computer, Inc.,
for internal use in duplicating and distributing 3.5&quot; floppy disks. Because
of its utility in distributing disk images on the Macintosh, DiskCopy is used
in several Apple developer products even though DiskCopy is not an official
Apple product and is not supported as such.
Since the monthly Developer CD Series discs contain many DiskCopy disk images,
and since the AppleShare and HFS FSTs in System Software 6.0 and later
automatically translate DiskCopy files (HFS file type dImg and creator dCpy)
to Apple II file type $E0 and auxiliary type $0005, the format is provided
here for your utility use only. Apple does not guarantee that files not
generated by DiskCopy will work with DiskCopy.
DEFINITIONS
DiskCopy uses a simple checksum algorithm to help insure data integrity for
archived disk images. The algorithm for generating the 32-bit checksum is as
follows:
Initialize checksum to zero
For each data REVERSE WORD:
Add the data REVERSE WORD to the checksum
Rotate the 32-bit checksum right one bit (wrapping bit 0 to bit 31)
The following 65816 assembly language routine calculates a DiskCopy checksum.
It's not a speedy operation--it takes about 12 seconds to calculate the
checksum on an 800K disk image. Anyone finding an assembly routine that can
perform this task in under 5 seconds may apply for their IIgs Certificate of
Deityship, as documented in the File Type Note for file type $B6.
(Oh, by the way, any entries have to be under 1K in size--the following
routine is 88 bytes. So don't think unwinding loops is your ticket to fame
and fortune.)
****************************************************************************
*
* Compute checksum for DiskCopy data
*
* v1.2 by David A. Lyons, 18-May-92
*
* MPW IIgs assembly format
*
* Inputs on stack:
* Push pointer to data (long)
* Push size of data (long) (Must be even!)
* JSL CalcChecksum
* STA TheChecksum+2
* STX TheChecksum
*
* Output:
* Checksum in A and X (bytes +0 and +1 in X, bytes +2 and +3 in A)
* (The inputs have been removed from the stack)
*
****************************************************************************
CalcChecksum PROC
phd ;save caller's direct page reg
lda #0
pha
pha ;push initial checksum value (zero)
tsc
tcd
checksum equ 1
oldD equ checksum+4
theRTL equ oldD+2
dataSize equ theRTL+3
dataPtr equ dataSize+4
*** Set dataSize to -(dataSize/2)-1 so we can count up by one
*** (instead of down by two) to see when we're done
lda &lt;dataSize+2
lsr a
eor #$ffff
sta &lt;dataSize+2
lda &lt;dataSize
ror a
eor #$ffff
sta &lt;dataSize
ldy #0
nextWord inc &lt;dataSize
bne moreData
inc &lt;dataSize+2
beq noMoreData
moreData
*** Get next 16-bit word from the data buffer
lda [&lt;dataPtr],y
xba ;swap to 65816 byte order
*** Add the data word to the checksum
clc
adc &lt;checksum
sta &lt;checksum
bcc noCksumRoll
inc &lt;checksum+2
noCksumRoll
*** Rotate the 32-bit checksum right one bit, wrapping bit 0 into bit 31
lda &lt;checksum+2
lsr a
ror &lt;checksum
bcc bit0was0
ora #$8000 ;if we rotated a 1 out of bit 0,
bit0was0 sta &lt;checksum+2 ; then set bit 31
*** Advance to the next word and go back for more
iny
iny
bne nextWord ;go back for more data
inc &lt;dataPtr+2
bra nextWord ;go back for next bank of data
noMoreData pla
xba
tay
pla
xba
tax ;pull checksum into YX (put in 68000
order)
pld ;restore caller's direct page reg
lda 2,s
sta 2+8,s
lda 1,s
sta 1+8,s
pla
pla
pla
pla ;discard input values
tya
rtl
EndP
END
The following definition is used in this document in addition to those defined
for all Apple II file types:
Checksum A 32-byte quantity calculated using the previously-defined
algorithm. When these are contained in the file, they are in
REVERSE order.
FILE STRUCTURE
All of the information for a DiskCopy disk image is in the data fork. The
resource fork usually contains Macintosh resources (in Macintosh resource fork
format), including vers resources listing the checksums. This allows
Macintosh users to use the Macintosh Finder's "Get Info..." function to
quickly examine the checksums.
The File Format
Because this is a native Macintosh file format, all the multi-byte constants
are stored in Reverse order.
diskName (+000) 64 Bytes A Pascal String containing the name of the
disk. This field takes 64 bytes
regardless of the length of the String.
dataSize (+064) Rev. Long The number of bytes (not blocks) of user
data. User data is the 512 bytes of each
block that a normal block-reading command
returns.
tagSize (+068) Rev. Long The number of bytes of tag data. Tag data
is the extra 12 bytes of "scavenger"
information present on 400K and 800K
Macintosh disks. Apple II operating
systems always leave these bytes zeroed,
and they're not present on 720K or 1440K
disks. If there are no tag bytes, this
field will be zero.
dataChecksum (+072) Checksum Checksum of all the user data on the disk.
The checksum algorithm is called for the
entire disk, not on a block-by-block or
sector-by-sector basis. This is in
Reverse order (most significant byte
first).
tagChecksum (+076) Checksum Checksum of all the tag data on the disk.
If there is no tag data, this should be
zero. This is in Reverse order (most
significant byte first).
diskFormat (+080) Byte 0 = 400K
1 = 800K
2 = 720K
3 = 1440K (all other values are reserved)
formatByte (+081) Byte $12 = 400K
$22 = >400K Macintosh (DiskCopy uses this
value for all Apple II disks not
800K in size, and even for some of
those)
$24 = 800K Apple II disk
private (+082) Rev. Word Must be $0100. If this field is not
$0100, the file may be in a different
format.
userData (+084) dataSize Bytes
The data blocks for the disk. These are
in order from block zero through the end
of the disk.
tagData (+xxx) tagSize Bytes The tag data for this disk, starting with
the tag data for the first block and
proceeding in order. This field is not
present for 720K and 1440K disks, but it
is present for all other formats even if
all the data is zeroes.
Further Reference
_____________________________________________________________________________
o GS/OS Reference
</pre><hr>
<address>This document is Copyright by Apple Computer, Inc.</address>
<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

537
library/FTN.e08000.htm Normal file
View File

@ -0,0 +1,537 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>FTN.e08000</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong></strong></font><br>
</p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<h2>Apple II FTN - Binary II File</h2>
<p><a href="index.htm">Back to nulib.com library</a></p>
<hr><pre>
Apple II
File Type Notes
_____________________________________________________________________________
Developer Technical Support
File Type: $E0 (224)
Auxiliary Type: $8000
Full Name: Binary II File
Short Name: Binary II File
Written by: Matt Deatherage July 1989
Files of this type and auxiliary type contain other files with their
attributes encoded in Binary II format.
_____________________________________________________________________________
Binary II is a widely used and accepted standard for keeping file attributes
with files as they are transferred, usually by modem or other form of
telecommunication. Files that are known Binary II files should be written to
disk with file type $E0 and auxiliary type $8000 as a clear indication to
other programs that the file contains files with Binary II specifications.
Binary II was developed by Gary B. Little, author of the Point-To-Point
communication's product and author of several Apple II reference books. He is
also Apple's Product Manager for third-party Development Tools and Languages.
Gary welcomes your comments and suggestions on the Binary II standard at the
following address:
Gary B. Little
3304 Plateau Drive
Belmont, CA 94002
AppleLink: LITTLE
AppleLink--Personal Edition: GaryLittle
CompuServe: 70135,1007
GEnie: GARY.LITTLE
Why Binary II?
Transferring Apple II files in binary form to commercial information services
and bulletin boards (referred to in this Note as &quot;hosts&quot;) can be, to put it
mildly, a frustrating exercise. Although most hosts are able to receive a
file's data in binary form (using protocols such as XMODEM), they don't
receive the file's all-important attribute bytes. All the common Apple II
file system, notably the ProDOS file system, store the attributes inside the
disk directory, not inside the file itself.
The ProDOS attributes are the access code, file type code, auxiliary type
code, storage type code, date of creation and last modification, time of
creation and last modification, the file size, and the name of the file
itself. Under GS/OS, the same parameters exist for other file systems as well
as file system-specific information and two-forked file information. It is
usually not possible to use a ProDOS file's data without knowing the file's
attributes (particularly the file type, auxiliary type, and size). Therefore,
ProDOS files uploaded in binary format to a host are useless to those who
download them. The same is true for DOS 3.3 and Pascal files.
Many Apple II communication programs use special protocols for transferring
file attributes during a binary file transfer, but none of these protocols
have been implemented by hosts. These programs are only useful for exchanging
files with another Apple II running the same program.
Without a standard like Binary II, the only acceptable way to transfer an
Apple II file to a host is to convert it into ASCII text before sending it.
Such a text file would contain a listing of an AppleSoft program, or a series
of Apple II monitor commands (e.g., 300:A4 32). Someone downloading a file
can convert it to binary form using the AppleSoft EXEC command.
The main disadvantage of this technique is that the text version of the file
is over three times the size of the original binary file, making it expensive
(in terms of time and money) to upload and download. It is also awkward, and
sometimes impossible, to perform the binary-to-text or text-to-binary
conversion.
The solution to the problem is to upload an encoded binary file which contains
not just the file's data, but the file's attributes as well. Someone
downloading such a file can then use a conversion program to strip the
attributes from the file and create a file with the required attributes.
This Note describes such a format: Binary II. The description of the format
is detailed for the purpose of allowing software developers to implement it in
Apple II communication programs.
What Binary II is Not
Binary II is not an archival or compression standard. It is designed to be a
simple method to keep the attributes normally in a disk file's directory entry
with the file as it is transferred. Although multiple files may be placed
together with Binary II, this is a matter of convenience for telecommunication
programs.
A true archival standard must be designed as such, with the capability to
manipulate files within the archive as well as linking them together
(compressed or uncompressed) for transfer. NuFX (documented in Apple II File
Type Note for File Type $E0, Auxiliary Type $8002) is a good example of a
robust, full-featured Apple II archival standard.
Binary II is primarily designed to be added to and subtracted from files &quot;on-
the-fly&quot; by telecommunication programs. Binary II files should only be found
on disks when they are transferred by a telecommunication program that does
not have Binary II capabilities, in which case a separate utility (such as
Binary Library Utility by Floyd Zink, Jr.) must be used to extract the files.
Telecommunication programs should be able to transfer files without Binary II
processing, however, they should support Binary II processing as a default.
The Binary II File Format
The Binary II form of a standard file consists of a 128-byte file information
header followed by the file's data. The data portion of the file is padded
with nulls ($00 bytes), if necessary, to ensure the data length is an even
multiple of 128 bytes.
The file information header contains four ID bytes, the attributes of the file
(in ProDOS 8 form), and some control information.
The structure of the header is as follows:
+000 ID Bytes 3 Bytes These three bytes are always $0A $47 $4C
for identification purposes, so programs
may recognize Binary II files as they are
received.
+003 Access Code Byte ProDOS 8 access byte.
+004 File Type Byte ProDOS 8 file type.
+005 Aux Type Word ProDOS 8 auxiliary type.
+007 Storage Type Byte ProDOS 8 storage type value.
+008 File Size Word The size of the file in 512-byte blocks.
+010 Mod. Date 2 Bytes Date of modification, in ProDOS 8
compressed format.
+012 Mod. Time 2 Bytes Time of modification, in ProDOS 8
compressed format.
+014 Create Date 2 Bytes Date of creation, in ProDOS 8
compressed format.
+016 Create Time 2 Bytes Time of creation, in ProDOS 8
compressed format.
+018 ID Byte Byte A fourth ID byte. This must always be
$02.
+019 Reserved Byte Reserved, must be set to zero.
+020 EOF 3 Bytes The end-of-file value for the file (low
byte first).
+023 File Name String Pascal string containing the ASCII
filename or partial pathname of this file
in ProDOS 8 format. The string cannot be
longer than 64 characters.
If the File Name String is a filename and not a partial pathname, then the
following optional parameter may be supplied:
+039 Native Name String Pascal string containing the
ASCII value of the native filename. This
string may not be longer than 48
characters, and will not be present if the
length byte of File Name (+023) is larger
than 15 ($0F). If this field is
specified, the File Name field must
contain a filename, not a partial
pathname.
+088 Reserved 21 Bytes Reserved. These bytes must be set to zero
for future compatibility.
+109 GAux Type Word The high word of the file's GS/OS
auxiliary type.
+111 GAccess Byte The high byte of the file's GS/OS access
word.
+112 GFile Type Byte The high byte of the file's GS/OS
file type.
+113 GStorage Byte The high byte of the file's GS/OS storage
type.
+114 GFile Size Word The high word of the GS/OS file's
size in 512-byte blocks.
+116 GEOF Byte The high byte of the file's GS/OS EOF
value.
+117 Disk Space Long The number of 512-byte disk blocks
the files inside the BinaryÊII file will
occupy after they've been removed from the
BinaryÊII file. (The format of a Binary
II file containing multiple files is
described later in this Note.) If the
number is zero, the creator of the Binary
II file didn't bother to calculate the
space needed. This value must be placed
in the file information header for the
first file inside the Binary II file; it
can be set to zero in subsequent headers.
A downloading program can inspect Disk
Space and abort the transfer immediately
if there isn't enough free space on the
disk.
+121 OS Type Byte This value indicates the native operating
system of the file:
$00 ProDOS or SOS
$01 DOS 3.3
$02 Reserved
$03 DOS 3.2 or DOS 3.1
$04 Apple II Pascal
$05 Macintosh MFS
$06 Macintosh HFS
$07 Lisa Filing System
$08 Apple CP/M
$09 Reserved (returned by the GS/OS
Character FST)
$0A MS-DOS
$0B High Sierra (CD-ROM)
$0C ISO 9660 (CD-ROM)
$0D AppleShare
Note this list is slightly different (in
the first three entries) from the standard
GS/OS file system ID list. A GS/OS
communication program should not place a
zero in this field unless the file's
native file system truly is ProDOS. The
file's native file system is returned in
the file_sys_id parameter from the
GetDirEntry call.
+122 Native File Type
Word This has meaning only if OS Type is non-
zero. If so, it is set to the actual file
type code assigned to the file by it's
native operating system. (Some operating
systems, such as MS-DOS and CP/M, do not
use file type codes, however.) Contrast
this with the File Type at +004, which is
the closest equivalent ProDOS file type.
The Native File Type is needed to
distinguish files which have the same
ProDOS file type, but which may have
different file types in their native
operating system. Note that if the file
type code is only one byte long (the usual
case), the high-order byte of Native File
Type is set to zero.
+124 Phantom File Flag
Byte This byte indicates whether a receiver of
the Binary II file should save the file
which follows (flag is zero) or ignore it
(flag is non-zero). It is anticipated
that some communication programs will use
phantom files to pass non-essential
explanatory notes or encoded information
which would be understood only by a
receiver using the same communication
program. Such programs must not rely on
receiving a phantom file, however, since
this would mean they couldn't handle
Binary II files created by other
communication programs. Phantom Files may
also be used to pass extended file
attributes when available.
The first two bytes in a phantom file must
contain an ID code unique to the
communication program, or a universal
identifier concerning the contents of the
phantom file. Developers must obtain ID
codes from Gary Little to ensure
uniqueness (see the beginning of this Note
for his address). Here is a current list
of approved ID codes for phantom files
used by Apple II communication programs:
$00 $00 ASCII text terminated with a
zero byte.
$00 $01 Point-to-Point
$00 $02 Tele-Master Communications
System
$00 $03 ProTERM
$00 $04 Modem MGR
$00 $05 CommWorks
$00 $06 MouseTalk
$01 $00 Option_list data (see later in
this Note).
The ID bytes are the first two bytes of
the phantom file.
+125 Data Flags Bit 7: 1 = file is compressed
Flag Byte Bit 6: 1 = file is encrypted
Bits 5-1: Reserved
Bit 0: 1 = file is sparse
A Binary II downloading program can
examine this byte and warn the user that
the file must be expanded, decrypted or
unpacked. The person uploading a Binary
II file may use any convenient method for
compressing, encrypting, or packing the
file but is responsible for providing
instructions on how to restore the file to
its original state.
+126 Version Byte This release of Binary II has a version
number of $01.
+127 Number of Files to Follow
Byte An appealing feature of Binary II is that
a single Binary II file can hold multiple
disk files, making it easy to keep a group
of related files &quot;glued&quot; together when
they're sent to a host. This byte
contains the number of files in this
Binary II file that are behind it. If
this is the first file in a Binary II file
containing three disk files, this byte
would be $02. The second disk file in the
same Binary II file would have a value of
$01 in this parameter, and the last would
have value $00. This count tells the
Binary II downloading program how many
files are remaining. If any phantom files
are included, they must be included in
this count.
Filenames and Partial Pathnames
You can put a standard ProDOS filename or a partial pathname in the file
information header (but never a complete pathname). Don't use a partial
pathname unless you've included, earlier in the Binary II file, file
information headers for each of the directories referred to in the partial
pathname. Such a header must have its &quot;end of file position&quot; bytes set to
zero, and no data blocks for the subdirectory file must follow it.
For example, if you want to send a file whose partial pathname is
HELP/GS/READ.ME, first send a file information header defining the HELP/
subdirectory, then one defining the HELP/GS/ subdirectory. If you don't,
someone downloading the Binary II file won't be able to convert it because the
necessary subdirectories will not exist.
Note: GS/OS communication programs must use the slash (/) as the
pathname's separator in any partial pathname it puts in the
header. Since GS/OS's standard separator is the colon (:), a
conversion may be necessary.
Filename Convention
Whenever a file is sent to a host, the host asks the sender to provide a name
for it. If it's a file in Binary II form, the name provided should end in
.BNY so its special form will be apparent to anyone viewing a list of
filenames. If the file is compacted (using the public-domain Squeeze
algorithm) before being converted to Binary II form, use a .BQY suffix
instead. If the file is a NuFX archive, use the suffix .BXY.
Identifying Binary II Files
You can determine, while transferring, if a file is in Binary II form by
examining the ID bytes at offsets +000, +001, +002 and +018 from the beginning
of the file. They must be $0A, $47, $4C and $02, respectively.
Once Binary II files are identified, you can use the data in the file
information header to create and open a ProDOS file with the correct name and
attributes, transfer the file data in the Binary II file to the ProDOS file,
set the ProDOS file size, then close the ProDOS file. You would repeat this
for each file contained inside the Binary II file.
Note: The number of 128-byte blocks following the file information
header must be derived from the EOF attribute for the file.
Calculate the number by dividing the EOF by 128 and adding one to
the result if EOF is not 0 or an exact multiple of 128. However,
if the file information header defines a subdirectory (the file
type is $0F), simple create the subdirectory file. Do not open it
and do not try to set its size.
Ideally, all this conversion work will be done automatically by a
communication program during file transfer. If not, a separate conversion
program (such as the previously mentioned Binary Library Utility, or BLU) must
be used to do this for you.
Option_List Phantom Files
GS/OS will return, when asked, an option_list for files on many file calls.
The option_list consists of a Word buffer length (which must be at least $2E),
followed by a Word number of bytes GS/OS put in the buffer, a Word GS/OS file
system identification, and the given number of bytes of FST-specific
information (minus two; the count GS/OS returns includes the file system
identifier).
Option_list values are FST specific and contain values important to the native
file system but not important to GS/OS. For AppleShare, the option_list
contains Finder Information, parent directory identification, and access
privileges. This information should be transferred with files.
Binary II uses a phantom file with identifier $01 $00 to indicate an
option_list. When this phantom file is seen, the contents should be used as
the option_list for the file that immediately follows this file in the
Binary II file. The other attributes of the phantom file must be set to the
same values as those for the file immediately following (the file for which
the phantom file contains the option_list). The EOF for the phantom file must
be the size of the option_list + 2, and the file size must be adjusted
accordingly to account for the phantom file ID bytes.
When receiving a Binary II file, the contents of this phantom file should be
used as option_list input on a GS/OS SetFileInfo call.
If the GS/OS option_list returns a total of two bytes (just the file_sys_ID),
there is no FST-specific information, and the option_list phantom file may
safely be omitted.
The format of the option_list phantom file is as follows:
+000 Phantom ID 2 Bytes The identifying bytes $01 $00.
+002 List Size Word The length of the bytes in the
option_list, starting with the file system
ID (the next word).
+004 FileSysID Word A GS/OS (not Binary II) file_sys_ID for
the volume on which the file was stored.
+006 List Bytes Bytes The bytes of the option list.
There should be (List Size) of them,
counting the previous word (FileSysID).
Extended File Considerations
Extended files contain two logical segments: a data fork and a resource fork.
These files can be created and manipulated by GS/OS, but not by ProDOS 8 or
any other Apple II operating system.
When a GS/OS-based communication program sends an extended file, it must send
it in the AppleSingle file format, preceded by a Binary II file information
header. (Such a program could easily convert an extended file to AppleSingle
format on the fly.) The Binary II header must contain the attributes of the
AppleSingle file (including a file type of $E0 and an auxiliary type of $0001)
and the &quot;storage type code&quot; field must be $01. (The EOF positions for the
data fork and resource fork of the extended file appear in an entry in the
AppleSingle file header, not in the Binary II header.)
The AppleSingle format is described in Apple II File Type Note for File Type
$E0, Auxiliary Type $0001.
A GS/OS-based communication program that receives an AppleSingle file can
easily convert it on the fly to the extended file it defines. ProDOS 8-based
communication programs can only save the AppleSingle file to disk because it's
not possible (nor is it encouraged to attempt) to create extended files with
ProDOS 8 (without using block-level calls); a GS/OS based utility program is
needed to convert the AppleSingle file to its extended form.
DOS 3.3 Considerations
With a little extra effort, you can also convert DOS 3.3 files to Binary II
form. This involves translating the DOS 3.3 file attributes to the
corresponding ProDOS attributes so that you can build a proper file
information header.
o Set the name to one that adheres to the stricter ProDOS naming
rules and put its length at +023 and the name itself at +024 to
+038. Note that the name must be a simple filename and not a
pathname. The actual DOS 3.3 filename must be placed at +039
(length) and +040 to +087 (name). (DOS 3.3 actually restricts
filenames to 30 characters.)
o Set the ProDOS file type, auxiliary type and access to values
which correspond to the DOS 3.3 file type:
DOS 3.3 ProDOS ProDOS ProDOS
File Type File Type Auxiliary Type Access
__________________________________________________
$00 (T) $04 $0000 $E3
$80 (*T) $04 $0000 $21
$01 (I) $FA $0C00 $E3
$81 (*I) $FA $0C00 $21
$02 (A) $FC * $E3
$82 (*A) $FC * $21
$04 (B) $06 ** $E3
$84 (*B) $06 ** $21
$08 (S) $06 $0000 $E3
$88 (*S) $06 $0000 $21
$10 (R) $FE $0000 $E3
$90 (*R) $FE $0000 $21
$20 (A) $06 $0000 $E3
$A0 (*A) $06 $0000 $E3
$40 (B) $06 $0000 $E3
$C0 (*B) $06 $0000 $21
__________________________________________________
* Set the auxiliary type for an A file to the
memory address from which the program was saved.
This is usually $0801.
** Set the auxiliary type for a B file to the
value stored in the first two bytes of the the
file (this is the default load address).
o Set the storage type code to $01.
o Set the size of file in blocks, date of creation, date of
modification, time of creation and time of modification all to
$0000.
o Set the end-of-file position to the length of the DOS 3.3 file, in
bytes. For a B file (code $04 or $84), this number is stored in
the third and fourth bytes of the file. For an I file (code $01
or $81) or an A file (code $02 or $82), this number is stored in
the first and second bytes of the file.
o Set the operating system type to $01.
o Set the native file type code to the value of the DOS 3.3 file
type code.
Attribute bytes inside a DOS 3.3 file (if any) must not be included in the
data portion of the Binary II file. This includes the first four bytes of a B
(Binary) file, and the first two bytes of an A (AppleSoft) or I (Integer
BASIC) file.
Further Reference
_____________________________________________________________________________
o GS/OS Reference
o ProDOS 8 Technical Reference Manual
o Apple II File Type Note, File Type $E0, Auxiliary Type $0001
o Apple II File Type Note, File Type $E0, Auxiliary Type $8002
o Apple II Miscellaneous Technical Note #14, Guidelines for
Telecommunication Programs
</pre><hr>
<address>This document is Copyright by Apple Computer, Inc.</address>
<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

966
library/FTN.e08002.htm Normal file
View File

@ -0,0 +1,966 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>FTN.e08002</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong></strong></font><br>
</p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<h2>Apple II FTN - ShrinkIt (NuFX) document</h2>
<p><a href="index.htm">Back to nulib.com library</a></p>
<h3>NOTE to CRC-16 seekers:</h3>
<p>Looks like a lot of people are hitting this page while looking for a CRC-16
algorithm. That's not what this page is about. If you want a CRC-16
implementation in C, try <a href="Crc16.c.txt">this one</a>.
If you want one in 6502 assembly, skip down to the end of this document.
<p>
<hr><pre>
Apple II
File Type Notes
_____________________________________________________________________________
Developer Technical Support
File Type: $E0 (224)
Auxiliary Type: $8002
Full Name: NuFile Exchange Archival Library
Short Name: ShrinkIt (NuFX) document
Revised by: Andy Nicholas and Matt Deatherage July 1990
Written by: Matt Deatherage July 1989
Files of this type and auxiliary type contain NuFX Archival Libraries.
Changes since July 1989: Rewrote major portions to reflect Master Version
$0002 of the NuFX standard.
_____________________________________________________________________________
Introduction
NuFX is a robust, full-featured archival standard for the Apple II family.
The standard, as presented in this Note, allows for full archival of ProDOS
and GS/OS files while keeping all file attributes with each file, as well as
providing necessary archival functions such as multiple compression schemes
and multiple archival implementations of the same standard. NuFX is
implemented in the application ShrinkIt, a free archival utility program for
enhanced IIe, IIc and IIgs computers. (Versions for earlier Apple II models
are also available.)
The NuFX standard was developed by Andrew Nicholas for Paper Bag Productions.
Comments or suggestions on the NuFX standard, or comments and suggestions on
ShrinkIt are welcome at:
Paper Bag Productions
8415 Thornberry Drive East
Upper Marlboro, MD 20772
Attn: NuFX Technical Support
America Online: ShrinkIt
GEnie: ShrinkIt
CompuServe: 70771,2615
History
The Apple II community has always lacked a well-defined method for archiving
files. NuFX is an attempt to rectify the situation by providing a flexible,
consistent standard for archiving files, disks, and other computer media.
Although many files are archived using the Binary II standard (see Apple II
File Type Note, File Type $E0, Auxiliary Type $8000), it was not designed as
an archival standard and its continued use as such creates problems. More
people are using Binary II as an archival standard than as a way to keep
attributes with a file when transferred, and this use is causing the original
intent of Binary II to become lost and unused.
NuFX, developed as an archival standard for the days of GS/OS, allows:
o Filenames longer than 64 characters (GS/OS can create 8,000-
character filenames).
o A convenient way to add to, remove from, and work on an archive.
o Including GS/OS files which contain resource forks.
o Including entire disk images.
o Including comments with a file.
o A convenient way to represent a file compressed or encrypted by a
specific application.
o A true archive standard. Binary IIs original intent was to make
transfer of Apple II files from local machines to large
information services possible; otherwise, a file's attribute
information would be lost. Use of Binary II to archive files
rather than simply maintain their attributes stretches it beyond
its original intent.
Adding all of these features to the existing Binary II standard would be
nearly impossible without violating the existing standard and causing a great
deal of confusion. Although Binary II is flexible, it is simply unable to
address all of these concerns without alienating existing Binary II extraction
programs.
To provide some differentiation between standards and provide a better
functioning format, this Note presents a new standard called NuFX (NuFile
eXchange for the Apple II; pronounced new-F-X). NuFX fixes the problems that
Apple IIgs users would soon be experiencing as other filing systems become
available for GS/OS. NuFX attempts to stem a set of problems before they have
a chance to develop. NuFX provides all of the features of Binary II, but goes
further to allow the user the ultimate in flexibility, usefulness and
performance.
Additional Date/Time Data type:
Date/Time (8 Bytes):
+000 second Byte The second, 0 through 59.
+001 minute Byte The minute, 0 through 59.
+002 hour Byte The hour, 0 through 23.
+003 year Byte The current year minus 1900.
+004 day Byte The day, 0 through 30.
+005 month Byte The month, 0 through 11 (0 = January).
+006 filler Byte Reserved, must be zero.
+007 weekDay Byte The day of the week, 1 through 7 (1 = Sunday).
The format of the Date/Time field is identical to that described for the
ReadTimeHex call in the Apple IIgs Toolbox Reference Manual.
Implementation
Figure 1 illustrates the basic structure of a NuFX archive.
| First Record | Next Record |
_______________|_______________________|_______________________|
| Master Header | Header | Data | Header | Data |
|_______________|________|______________|________|______________|
Figure 1-NuFX Archive Structure
A single master header block contains values which describe the entire archive
(those with knowledge of structured programming may consider them archive
globals). Each of the succeeding header blocks contains only information
about the record it precedes (consider each an archive local).
Each header block is followed by a list of threads, which is followed by the
actual threads. The data for each thread may be a data fork, resource fork,
message, control sequence for a NuFX utility program, or almost any kind of
sequential data.
Possible Block Combinations:
The blocks must occur in the following fashion:
Master Header Block containing N entries
Header Block
Threads list:
filename_thread (16 bytes)
message_thread (16 bytes)
data thread (16 bytes)
.
.
.
filename_thread's data (filename_thread's comp_thread_eof # of bytes)
message_thread's data (message_thread's comp_thread_eof # of bytes)
data_thread's data (data_thread's comp_thread_eof # of bytes)
.
.
.
Next Header Block (notice no second Master Header block)
Threads list (message, control, data or resource)
.
.
.
Nth Header Block
Threads list (message, control, data or resource)
Master Header Block Contents
+000 nufile_id 6 Bytes These six bytes spell the word &quot;NuFile&quot; in
alternating ASCII (low, then high) for
uniqueness. The six bytes are $4E $F5 $46
$E9 $6C $E5.
+006 master_crc Word A 16-bit cyclic redundancy check
(CRC) of the remaining fields in this
block (bytes +008 through +047). Any
programs which modify the master header
block must recalculate the CRC for the
master header. (see the section &quot;A Sample
CRC Algorithm&quot;) The initial value of this
CRC is $0000.
+008 total_records Long The total number of records in this
archive file. It is possible to chain
multiple records (files or disks)
together, as it is possible to chain
different types of records together (mixed
files and disks).
+012 archive_create_when
Date/Time The date and time on which this archive
was initially created. This field should
never be changed once initially written.
If the date is not known, or is unable to
be calculated, this field should be set to
zero. If the weekday is not known, or is
unable to be calculated, this field should
be set to null.
+020 archive_mod_when
Date/Time The date of the last modification to this
archive. This field should be changed
every time a change is made to any of the
records in the archive. If the date is
not known, or is unable to be calculated,
this field should be set to zero. If the
weekday is not known, or is unable to be
calculated, this field should be set to
null.
+028 master_version
Word The master version number of the NuFX
archive. This Note describes
master_version $0002, for which the next
eight bytes are zeroed.
+030 reserved 8 Bytes Must be null ($00000000).
+038 master_eof Long The length of the NuFX archive, in
bytes. Any programs which modify the
length of an archive, either increasing it
or decreasing it in size, must change this
field in the master header to reflect the
new size.
Header Block Contents:
Following the Master Header block is a regular Header Block, which precedes
each record within the NuFX archive. A cyclic redundancy check (CRC) has been
provided to detect archives which have possibly been corrupted. The only time
the CRC should be included in a block is for the Master Header and for each of
the regular Header Blocks. The CRC ensures reliability and data integrity.
+000 nufx_id 4 Bytes These four bytes spell the word &quot;NuFX&quot; in
alternating ASCII (low, then high) for
uniqueness. The four bytes are $4E $F5
$46 $D8.
+004 header_crc Word The 16-bit CRC of the remaining
fields of this block (bytes +006 through
the end of the header block and any
threads following it). This field is used
to verify the integrity of the rest of the
block. Programs which create NuFX
archives must include this in every
header. It is up to the discretion of the
extracting program to check the validity
of this CRC. Any programs which might
modify the header of a particular record
must recalculate the CRC for the header
block. The initial value for this CRC is
zero ($0000).
+006 attrib_count Word This field describes the length of
the attribute section of each record in
bytes. This count measures the distance
in bytes from the first field (offset
+000) up to and including the
filename_length field. By convention, the
filename_length field will always be the
last 2 bytes of the attribute section
regardless of what has preceded it.
+008 version_number
Word Version of this record. If version_number
is $0000, no option_list fields are
present. If the version_number is $0001
option_list fields may be present. If the
version_number is $0002 then option_list
fields may be present and a valid CRC-16
exists for the compressed data in the data
threads of this record. If the
version_number is $0003 then option_list
fields may be present and a valid CRC-16
exists for the uncompressed data in the
data threads of this record. The current
version number is $0003 and should always
be used when making archives.
+010 total_threads Long The number of thread subrecords
which should be expected immediately
following the filename or pathname at the
end of this header block. This field is
extremely important as it contains the
information about the length of the last
third of the header.
+014 file_sys_id Word The native file system identifier:
$0000 reserved
$0001 ProDOS/SOS
$0002 DOS 3.3
$0003 DOS 3.2
$0004 Apple II Pascal
$0005 Macintosh HFS
$0006 Macintosh MFS
$0007 Lisa File System
$0008 Apple CP/M
$0009 reserved, do not use (The
GS/OS Character FST returns
this value)
$000A MS-DOS
$000B High Sierra
$000C ISO 9660
$000D AppleShare
$000E-$FFFF Reserved, do not use
If the file system of a disk being
archived is not known, it should be set to
zero.
+016 file_sys_info Word Information about the current filing
system. The low byte of this word (offset
+016) is the native file system separator.
For ProDOS, this is the slash (/ or $2F).
For HFS and GS/OS, the colon (: or $3F) is
used, and for MS-DOS, the separator is the
backslash (\ or $5C). This separator is
provided so archival utilities may know
how to parse a valid file or pathname from
the filename field for the receiving file.
GS/OS archival utilities should not
attempt to parse pathnames, as it is not
possible to build in syntax rules for file
systems not currently defined. Instead,
pass the pathname directory to GS/OS and
attempt translation (asking the user for
suggestions) only if GS/OS returns an
&quot;Invalid Path Name Syntax&quot; error. The
high byte of this word is reserved and
should remain zero.
+018 access Flag Long Bits 31-8 reserved, must be zero
Bit 7 (D) 1 = destroy enabled
Bit 6 (R) 1 = rename enabled
Bit 5 (B) 1 = file needs to be
backed up
Bits 4-3 reserved, must be zero
Bit 2 (I) 1 = file is invisible
Bit 1 (W) 1 = write enabled
Bit 0 (R) 1 = read enabled
+022 file_type Long The file type of the file being archived.
For ProDOS 8 or GS/OS, this field should
always be what the operating system
returns when asked. For disks being
archived, this field should be zero.
+026 extra_type Long The auxiliary type of the file being
archived. For ProDOS 8 or GS/OS, this
field should always be what the operating
system returns when asked. For disks
being archived, this field should be the
total number of blocks on the disk.
+030 storage_type Word For Files: The storage type of the
file. Types $1 through $3 are standard
(one-forked) files, type $5 is an extended
(two-forked) file, and type $D is a
subdirectory.
file_sys_block_size
Word For Disks: The block size used by the
device should be placed in this field.
For example, under ProDOS, this field will
be 512, while for HFS it might be 524.
The GS/OS Volume call will return this
information if asked.
+032 create_when Date/Time The date and time on which
this record was initially created. If the
creation date and time are available from
a disk device, this information should be
included. If the date is not known, or is
unable to be calculated, this field should
be set to zero. If the weekday is not
known, or is unable to be calculated, this
field should be set to zero.
+040 mod_when Date/Time The date and time on which this record was
last modified. If the modification date
and time are available from a disk device,
this information should be included. If
the date is not known, or is unable to be
calculated, this field should be set to
zero. If the weekday is not known, or is
unable to be calculated, this field should
be set to zero.
+048 archive_when Date/Time The date and time on which
this record was placed in this archive.
If the date is not known, or is unable to
be calculated, this field should be set to
zero. If the weekday is not known, or is
unable to be calculated, this field should
be set to zero.
The following option_list information is only present if the NuFX version
number for this record is $0001 or greater.
+056 option_size Word The length of the FST-specific
portion of a GS/OS option_list returned by
GS/OS. This field may be $0000,
indicating the absence of a valid
option_list.
A GS/OS option_list is formatted as follows:
+000 buffer_size
Word Size of the buffer for GS/OS to
place the option_list in, including
this count word. This must be at
least $2E.
+002 list_size
Word The number of bytes of information
returned by GS/OS.
+004 file_sys_ID
Word A file system ID word (see list
above) identifying the FST owning
the file in question.
+006 option_bytes
Bytes The bytes returned by the FST.
There are (buffer_size - 6) of them.
The option_list contains information specific to native file systems that
GS/OS doesn't normally use (such as true creator_type, file_type, and access
privileges for AppleShare). Other FSTs released in the future will follow
similar conventions to return native file system specific parameters in the
option_list. Information in the option_list should always be copied from file
to file.
The value option_size in the NuFX header is the value of list_size minus two.
Immediately following the option_size count word are (list_size - 2) bytes.
To pass these values back to the destination file system, construct an
option_list with a suitably large buffer_size, a list_size of the NuFX
option_size + 2, the file_sys_id of the source file, and the FST-returned
option_bytes.
+058 list_bytes Bytes FST-specific bytes returned in an
option_list. These are the bytes in the
GS/OS option_list not including the FST ID
word. There are option_size of them. If
option_size is an odd number, one zero
byte of padding is added to keep the block
size an even number.
Because the attributes section does not have a fixed size, the next field must
be found by looking two bytes before the offset indicated by attrib_count
(+006).
+attrib_count - 2
filename_length
Word Obsolete, should be set to zero. In
previous versions of NuFX, this field was
the length of a file name or pathname
immediately following this field.
To allow the inclusion of future
additional parameters in the attributes
section, NuFX utility programs should rely
on the attribs_count field to find the
filename_length field.
Current convention is to zero this field
when building an archive and put the file
or pathname into a filename thread so the
record can be renamed in the archive.
Archival programs should recognize both
methods to find a valid file name or
pathname.
+attrib_count
filename Bytes Filename or partial pathname if
applicable. If this is a disk being
archived, then the volume_name should be
included in this field. If a volume name
is included in this field, a separator
should not be included in, or precede the
name. If a volume name is not available,
then this field should be zeros.
If a partial pathname is specified, the
directories to which the current pathname
refers need not have preceded this
particular record. The extraction program
must test each referenced directory
individually. If the directory in
question does not exist, the extracting
program should create it.
Any utility which extracts file from a
NuFX archive must not assume that this
field will be in a format it is able to
handle. In particular, extraction
programs should check for syntax
unacceptable to the operating system under
which they run and perform whatever
conversions are necessary to parse a legal
filename or pathname. In general, assume
nothing. (GS/OS programs should pass the
filename or pathname directly to GS/OS,
and only attempt to convert the name if
GS/OS returns an &quot;invalid pathname syntax&quot;
error.)
Both high and low ASCII values are valid
but may not mean the same to each file
system (for example, all eight bits are
significant in AppleShare pathnames while
only seven are significant in ProDOS
pathnames).
Threads
Thread Records are 16-byte records which immediately follow the Header Block
(composed of the attributes and file name of the current record) and describe
the types of data structures which are included with a given record. The
number of Thread Records is described in the attribute section by a Word,
total_threads.
Each Thread Record should be checked for the type of information that a given
utility program can extract. If a utility is incapable of extracting a
particular thread, that thread should be skipped (with the exception of
extended files under ProDOS 8, which should be dearchived into AppleSingle
format, or both threads should be skipped). If a utility finds a redundancy
in a Thread Record, it must decide whether to skip the record or to do
something with that particular thread (i.e., if a utility finds two
message_thread threads it can either ignore the second one or display it.
Likewise, if a utility finds two data_thread threads for the same file, it
should inspect the thread_kind of each. If they match, it can either
overwrite the first thread extracted, or warn the user and skip the second
thread).
Thread records can be represented as follows:
+000 thread_class Word The classification of the thread:
$0000 message_thread
$0001 control_thread
$0002 data_thread
$0003 filename_thread
+002 thread_format Word The format of the data within the thread:
$0000 Uncompressed
$0001 Huffman Squeeze
$0002 Dynamic LZW/1 (ShrinkIt
specific)
$0003 Dynamic LZW/2 (ShrinkIt
specific)
$0004 Unix 12-bit Compress
$0005 Unix 16-bit Compress
+004 thread_kind Word Describes the kind of data within
the thread.
thread_kind must be interpreted on the basis of thread_class. See the table
below for the currently defined thread_kind interpretations:
class $0000 class $0001 class $0002 class $0003
----------- ---------------- --------------------- -----------
kind $0000 ASCII text create directory data fork of file filename
kind $0001 see below undefined disk image undefined
kind $0002 see below undefined resource fork of file undefined
+006 thread_crc Word For version_number $0003, this field
is the CRC of the original data before it
was compressed or otherwise transformed.
The CRC-16's initial value is set to $FFFF.
+008 thread_eof Long The length of the thread when uncompressed.
+012 comp_thread_eof
Long The length of the thread when compressed.
Class $0000 with kind $0000 is obsolete and should not be used.
Class $0000 with kind $0001 has a predefined comp_thread_eof and a thread_eof
whose length may change. This way, a certain amount of space may be allocated
when a record is created and edited later.
Class $0000 with kind $0002 is a standard Apple IIgs icon. comp_thread_eof is
the length of the icon image; thread_eof is ignored.
Class $0003 with kind $0000 has a predefined comp_thread_eof and a thread_eof
whose length may change. After this record is placed into the archive, the
thread_eof can be changed if the name is changed, but the length of the name
may not extend beyond the space allocated for it, comp_thread_eof.
A thread_format of $0001 indicates Huffman Squeeze. NuFX's Huffman is the
same Huffman used by ARC v5.x, SQ and USQ, the source of which is publicly
available and was originally written by Richard Greenlaw. The first word of
the thread data is the number of nodes followed by the Huffman tree and the
actual data. This is also the same algorithm decoded by the Apple II version
of USQ written by Don Elton. The C source to this is widely available.
A thread_format of $0002 indicates a special variant of LZW (LZW/1) used by
ShrinkIt. The first two bytes of this thread are a CRC-16 of the uncompressed
data within the thread. This CRC-16 is initialized to zero ($0000). The third
byte is the low-level volume number used by the eight-bit version of ShrinkIt
to format 5.25&quot; disks. The fourth byte is the run-length character used to
decode the rest of the thread. The data which comprises the compressed file
or disk immediately follows the RLE character.
When ShrinkIt compresses a file, it reads 4096-byte chunks of the file until
it reaches the file's EOF. The last 4096-byte chunk is padded with zeroes if
the file's length is not an exact multiple of 4096. Compressing a disk is
also done by reading sequential blocks of 4096-bytes.
Each 4K chunk is first compressed with RLE compression. The RLE character is
determined by reading the fourth byte of the thread. The RLE character which
is used by most current versions of ShrinkIt is $DB. A run of characters is
represented by three bytes, consisting of the run character, the number of
characters in the run and the character in the run. If the 4K chunk expands
after being compressed with RLE then the uncompressed 4K chunk is passed to
the LZW compressor. If the 4K chunk shrinks after being compressed with RLE
then the RLE-compressed image of the 4K chunk is passed to the LZW compressor.
ShrinkIt's LZW compressor individually compresses each 4K chunk passed to it
by using variable length (9 to 12 bits) codes. The way that ShrinkIt's LZW
compressor functions is almost identical to the algorithm used in the public
domain utility Compress. The first code is $0101. The LZW string table is
cleared before compressing each 4K chunk. If the compressed chunk increases
in size, then the previous 4K chunk (which may be run-length-encoded or just
uncompressed data) is written to the file.
The first word of every 4K chunk is aligned to a byte boundary within the file
and is the length which resulted from the attempt at compressing the chunk
with RLE. If the value of this word is 4096, then RLE was not successful at
compressing the chunk. A single byte follows the word and indicates whether
or not LZW was performed on this chunk. A value of zero indicates that LZW
was not used, while a value of one indicates that LZW was used and that the
chunk must first be decompressed with LZW before doing any further processing.
To decompress a file, each 4K chunk must first be expanded if it was
compressed by LZW. If the 4K chunk wasn't compressed with LZW, then the word
which appears at the beginning of each chunk must be used to determine if the
data for the current chunk needs to be processed by the run-length decoder.
If the value of the word is 4096, then run-length decoding does not need to
occur because the data is uncompressed.
If the word indicates that the length of the chunk after being decompressed by
LZW is 4096-bytes long, then no run-length decoding needs to take place. If
value of the word is less than 4096 then the chunk must be run-length decoded
to 4096 bytes.
There are four varying degrees of compression which can occur with a chunk: it
can be uncompressed data. It can be run-length-encoded data without LZW
compression. It can also be uncompressed data on which RLE was attempted (but
failed) and then was subsequently compressed with LZW. Or, finally, the chunk
can be compressed with RLE and then also compressed with LZW.
A thread_format of $0003 indicates a special variant of LZW (LZW/2) used by
ShrinkIt. The first byte is the low-level volume number used by the eight-bit
version of ShrinkIt to format 5.25&quot; disks. The second byte is the run-length
character used to decode the rest of the thread. The data which comprises the
compressed file or disk immediately follows the second byte of the thread.
The format of LZW/2 is almost the same as LZW/1 with a few exceptions. Unlike
LZW/1, where the LZW string table is automatically cleared before each 4K
chunk is processed, the LZW string table used by LZW/2 is only cleared when
the table becomes full, indicating a change in the redundancy of the source
text. Not clearing the string table almost always yields improved compression
ratios because the compressor's dictionary is not being depleted every 4K and
larger strings are allowed to accumulate. The clear code used by ShrinkIt is
$100. Whenever the decompressor sees a $100 code, it must clear the string
table.
The string table is also cleared when the compressor has to &quot;back track&quot;
because a 4K chunk became larger. Whenever a chunk that is not compressed by
LZW is seen by the decompressor, the LZW string table must be cleared. Bits
0-12 of the first word of each chunk in a LZW/2 thread indicate the size of
the chunk after being compressed with RLE. The high bit (bit 15) indicates
whether or not LZW was used on the chunk. If LZW was not used (bit 15 = 0),
the data for the chunk immediately follows the first word. If LZW was used
(bit 15 = 1), a second word which is a count of the total number of bytes used
by the current chunk follows the first word. The mark of the next chunk can
be found by taking the mark at the beginning of the current chunk and adding
the second word to it, using that as an offset for a ProDOS 8 or GS/OS SetMark
call. This is not normally necessary because the next chunk is processed
immediately after the current chunk.
This second word is an improvement over LZW/1 because if a chunk becomes
corrupted, but the second word is valid, the next chunk can be found and most
of the file recovered. The second word is not needed (and not present) when
LZW is not used on the chunk because the first word is also a count of the
number of bytes which follow that word.
A thread_format of $0004 indicates that a maximum of 12 bits per LZW code by
Compress was used to build this thread. The actual thread data contains
Compress's usual three-byte signature, the third byte of which contains the
actual number of bits per LZW code that was actually used. The number of bits
may be less than or equal to 12. Optimally, this requires (at 12 bits) a 16K
hash table to decode and should be used only for transferring to machines with
limited amounts of memory. The C source to Compress is in the public domain
and is widely available.
A thread_format of $0005 indicates that a maximum of 16 bits per LZW code by
Compress was used to build this thread. The actual thread data contains
Compress's usual three-byte signature, the third byte of which contains the
actual number of bits per LZW code that was actually used. The number of bits
may be less than or equal to 16. Optimally, this requires (at 16 bits) a 256K
hash table to decode. The C source to Compress is in the public domain and is
widely available.
If a control_thread indicates that a directory should be created on the
destination device, the path to be created must take the form of a ProDOS
partial pathname. That is, the path must not be preceded with a volume name.
For example, /Stuff/SubDir is an invalid path for this control_thread, while
SubDir/AnotherSubDir is valid.
If a control_thread indicates that a path is to be created, all subdirectories
that are contained in the pathname must be created.
control_thread threads will eventually be used to control the execution of
utility programs by allowing them to create, rename, and delete directories
and files and to move and modify files. A form of scripting language will
eventually be able to allow utility programs to perform these actions
automatically. control_thread threads will allow extraction programs to
perform operations similar to those of the Apple IIgs Installer, allowing
updates to program sets dependent on such things as creation or modification
dates and version numbers.
Extra Information
If the file system of a particular disk is not known, the file_sys_id field
should be set to zero, the volume name should also be zeroed, and all the
other fields pertaining only to files should be set to zero.
If the file system of a particular disk is known, as many of the fields as
possible should be filled with the correct information. Fields which do not
pertain to an archived disk should remain set to zero.
If an entire disk is added to the archive without some form of compression
(i.e., record_format = uncompressed), then the blocks which comprise the disk
image must be added sequentially from the first through the last block. Since
there will be no character included in the data stream to mark the end or
beginning of a block, extraction programs should rely on the
file_sys_block_size field to determine how many bytes to read from the record
to properly fill a block.
Some Useful Thread Algorithms:
The beginning of the thread records can be found with the following algorithm:
Threads := (mark at beginning of header) + (attrib_count) +
(filename_length)
The end of the thread records can be found with the following algorithm:
endOfThreads := Threads + (16 * total_threads)
The beginning of a data_thread can be found with the following formula:
Data Mark := endOfThreads + (comp_thread_eof of all threads in the thread
list which are not data prior to finding a data_thread)
The beginning of a resource_thread may be found with the following algorithm:
Resource Mark := endOfThreads + (comp_thread_eof of all threads in the
thread list which are not data prior to finding a
resource_thread)
The next record can be found using the following algorithm:
Next Mark := endOfThreads + (comp_thread_eof of each thread)
The file name and its length can be found with the following algorithm:
if (filename_length &gt; 0)
then
length of filename is filename_length;
filename is found at attrib_count;
else
look through list of threads for a filename_thread;
if you find one, then length of filename is thread_eof;
if you don't find one, then you don't have a filename.
Directories
Directories are handled almost the same way that normal files are handled with
the exception that there will be no data in the thread which follows the
entry. A Thread Record must exist to inform a utility that a directory is to
be created through the use of the proper control_thread value.
Directories do not necessarily have to precede a record which references a
directory. For example, if a record contains Stuff/MyStuff, the directory
Stuff need not exist for the extracting program to properly extract the
record. The extracting program must check to see if each of the directories
referenced exist, and if one does not exist, create it. While this method
places a great burden on the abilities of the extraction program, it avoids
the anomalies associated with the deletion of directories within an archive.
A Sample CRC Algorithm
Paper Bag Productions provides the source code to a very fast routine which
does the CRC calculation as needed for NuFX archives. The routine makeLookup
needs to be called only once. After the first call, the routine doByte should
be called repeatedly with each new byte in succession to generate the
cumulative CRC for the block. The CRC word should be reset to null ($0000)
before beginning each new CRC.
This is the same CRC calculation which is done for CRC/Xmodem and Ymodem. The
code is easily portable to a 16-bit environment like the Apple IIgs. The only
detrimental factor with this routine is that it requires 512 bytes of main
memory to operate. If you can spare the space, this is one of the fastest
routines Paper Bag Productions knows to generate a CRC-16 on a 6502-type
machine.
The CRC word should be reset to $0000 for normal CRC-16 and to $FFFF before
generating the CRC on the unpacked data for each data thread.
*-------------------------------
* fast crc routine based on table lookups by
* Andy Nicholas - 03/30/88 - 65C02 - easily portable to nmos 6502 also.
* easily portable into orca/m format, just snip and save.
* Modified for generic EDAsm type assemblers - MD 6/19/89
X6502 turn 65c02 opcodes on
*-------------------------------
* routine to make the lookup tables
*-------------------------------
makeLookup
LDX #0 zero first page
zeroLoop STZ crclo,x zero crc lo bytes
STZ crchi,x zero crc hi bytes
INX
BNE zeroLoop
*-------------------------------
* the following is the normal bitwise computation
* tweeked a little to work in the table-maker
docrc
LDX #0 number to do crc for
fetch TXA
EOR crchi,x add byte into high
STA crchi,x of crc
LDY #8 do 8 bits
loop ASL crclo,x shift current crc-16 left
ROL crchi,x
BCC loop1
* if previous high bit wasn't set, then don't add crc
* polynomial ($1021) into the cumulative crc. else add it.
LDA crchi,x add hi part of crc poly into
EOR #$10 cumulative crc hi
STA crchi,x
LDA crclo,x add lo part of crc poly into
EOR #$21 cumulative crc lo
STA crclo,x
loop1 DEY do next bit
BNE loop done? nope, loop
INX do next number in series (0-255)
BNE fetch didn't roll over, so fetch more
RTS done
crclo ds 256 space for low byte of crc table
crchi ds 256 space for high bytes of crc table
*-------------------------------
* do a crc on 1 byte/fast
* on initial entry, CRC should be initialized to 0000
* on entry, A = byte to be included in CRC
* on exit, CRC = new CRC
*-------------------------------
doByte
EOR crc+1 add byte into crc hi byte
TAX to make offset into tables
LDA crc get previous lo byte back
EOR crchi,x add it to the proper table entry
STA crc+1 save it
LDA crclo,x get new lo byte
STA crc save it back
RTS all done
crc dw 0000 cumulative crc for all data
The following CRC check is written in APW assembler format for an Apple IIgs
with 16-bit memory and registers on entry.
crcByte start
crc equ $0
crca equ $2
crcx equ $4
crctemp equ $6
sta crca 4
stx crcx 4
eor crc+1 on entry, number to add to CRC 4
and #$00ff is in (A) 3
asl a 2
tax 2
lda crc16Table,x 5
and #$00ff 3
sta crcTemp 4
lda crc-1 4
eor crc16Table,x 5
and #$ff00 3
ora crcTemp 4
sta crc 4
lda crca 4
ldx crcx 4
rts cycles = 59
;
; CRC-16 Polynomial = $1021
;
crc16table anop
dc i'$0000, $1021, $2042, $3063, $4084, $50a5, $60c6, $70e7'
dc i'$8108, $9129, $a14a, $b16b, $c18c, $d1ad, $e1ce, $f1ef'
dc i'$1231, $0210, $3273, $2252, $52b5, $4294, $72f7, $62d6'
dc i'$9339, $8318, $b37b, $a35a, $d3bd, $c39c, $f3ff, $e3de'
dc i'$2462, $3443, $0420, $1401, $64e6, $74c7, $44a4, $5485'
dc i'$a56a, $b54b, $8528, $9509, $e5ee, $f5cf, $c5ac, $d58d'
dc i'$3653, $2672, $1611, $0630, $76d7, $66f6, $5695, $46b4'
dc i'$b75b, $a77a, $9719, $8738, $f7df, $e7fe, $d79d, $c7bc'
dc i'$48c4, $58e5, $6886, $78a7, $0840, $1861, $2802, $3823'
dc i'$c9cc, $d9ed, $e98e, $f9af, $8948, $9969, $a90a, $b92b'
dc i'$5af5, $4ad4, $7ab7, $6a96, $1a71, $0a50, $3a33, $2a12'
dc i'$dbfd, $cbdc, $fbbf, $eb9e, $9b79, $8b58, $bb3b, $ab1a'
dc i'$6ca6, $7c87, $4ce4, $5cc5, $2c22, $3c03, $0c60, $1c41'
dc i'$edae, $fd8f, $cdec, $ddcd, $ad2a, $bd0b, $8d68, $9d49'
dc i'$7e97, $6eb6, $5ed5, $4ef4, $3e13, $2e32, $1e51, $0e70'
dc i'$ff9f, $efbe, $dfdd, $cffc, $bf1b, $af3a, $9f59, $8f78'
dc i'$9188, $81a9, $b1ca, $a1eb, $d10c, $c12d, $f14e, $e16f'
dc i'$1080, $00a1, $30c2, $20e3, $5004, $4025, $7046, $6067'
dc i'$83b9, $9398, $a3fb, $b3da, $c33d, $d31c, $e37f, $f35e'
dc i'$02b1, $1290, $22f3, $32d2, $4235, $5214, $6277, $7256'
dc i'$b5ea, $a5cb, $95a8, $8589, $f56e, $e54f, $d52c, $c50d'
dc i'$34e2, $24c3, $14a0, $0481, $7466, $6447, $5424, $4405'
dc i'$a7db, $b7fa, $8799, $97b8, $e75f, $f77e, $c71d, $d73c'
dc i'$26d3, $36f2, $0691, $16b0, $6657, $7676, $4615, $5634'
dc i'$d94c, $c96d, $f90e, $e92f, $99c8, $89e9, $b98a, $a9ab'
dc i'$5844, $4865, $7806, $6827, $18c0, $08e1, $3882, $28a3'
dc i'$cb7d, $db5c, $eb3f, $fb1e, $8bf9, $9bd8, $abbb, $bb9a'
dc i'$4a75, $5a54, $6a37, $7a16, $0af1, $1ad0, $2ab3, $3a92'
dc i'$fd2e, $ed0f, $dd6c, $cd4d, $bdaa, $ad8b, $9de8, $8dc9'
dc i'$7c26, $6c07, $5c64, $4c45, $3ca2, $2c83, $1ce0, $0cc1'
dc i'$ef1f, $ff3e, $cf5d, $df7c, $af9b, $bfba, $8fd9, $9ff8'
dc i'$6e17, $7e36, $4e55, $5e74, $2e93, $3eb2, $0ed1, $1ef0'
end
Further Reference
_____________________________________________________________________________
o ProDOS 8 Technical Reference Manual
o GS/OS Reference
o Apple IIgs Toolbox Reference Manual
o Apple II File Type Note, File Type $E0, Auxiliary Type $8000
o Apple II Miscellaneous Technical Note #14, Guidelines for
Telecommunication Programs
o &quot;A Technique for High-Performance Data Compression,&quot; T. Welch,
IEEE Computer, Vol. 17, No.6, June 1984, pp. 8-19.
</pre><hr>
<address>This document is Copyright by Apple Computer, Inc.</address>
<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

353
library/Lesson9.htm Normal file
View File

@ -0,0 +1,353 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Hacking Data Compression - Lesson 9</title>
<meta name="Microsoft Border" content="t, default">
</head>
<body bgcolor="#FFFFFF" text="#000000"><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p align="center"><font size="6"><strong></strong></font><br>
</p>
<hr>
</td></tr><!--msnavigation--></table><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<h2>Hacking Data Compression - Lesson 9</h2>
<p><a href="index.htm">Back to nulib.com library</a></p>
<hr><pre>
Hacking Data Compression Lesson 9 NuFX and ShrinkIt
By Andy McFadden
GEnie A2Pro Apple II University - Copyright (C) 1992 GEnie
This week's lesson is about the de facto archiving standard for the
Apple II world: NuFX, as implemented by ShrinkIt and GS/ShrinkIt.
There are a variety of other programs, like ][+ ShrinkIt,
Auto-Unshrink, NuLib, NuPak, and YankIt, but they all handle the same
archive format.
The information covered here will be of interest to people who want to
write software that works with NuFX archives. If you're only
interested in general data compression, you can probably skip this
one.
-=O=- ShrinkIt
Back in the Olden Days, the format for storage and transmission of
data was Binary II (abbreviated &quot;BNY&quot;, and occasionally referred to as
&quot;bunny&quot; format). It arranged things on 128-byte boundaries for the
convenience of terminal programs, and is still used today for that
purpose. Actually, it was primarily meant as a way to retain the
filetype, auxtype, and other goodies associated with a file, much like
MacBinary for the Macintosh, but it also worked okay as an archive
format.
What made it Really Cool was the Huffman + RLE compressor which was,
well, almost built in to the Binary II Library Utility (BLU). It did
a reasonable job of making things smaller, and in a modest amount of
time. It was called SQueezed compression, which somehow got
abbreviated &quot;.QQ&quot;. Archives with squeezed files in them were &quot;.BQY&quot;.
However, it was really depressing to log onto a UNIX system and watch
UNIX compress crunch files into nothing. So, one fine day, a skinny
little college student named Andy Nicholas, and a taller but still
rather slim guy named Kent Dickey decided it would be a really neat
thing to do LZW on the Apple II.
Since the IIgs and System 4.0 had been released, it was apparent that
the old BNY format was missing a few pieces. Specifically, it had no
clear provision for forked files, file comments, other file systems,
and the expanded size of the stuff that GS/OS was returning in
GetFileInfo calls. So, with some suggestions from a few dozen
Apple II personalities, the NuFX format came into being.
(Sounds pretty dramatic, huh? Hmm, maybe I should write fiction...)
And so it came to pass that ShrinkIt was born. It took a little while
to work all the kinks out, but before long it was recognized that the
program worked faster and packed better than the old SQueezed format.
When Binary II support was added, the fate of BLU and its ilk was
sealed.
One interesting bit of history is that the LZW routines were initially
meant for a program like DDD (Dalton's Disk Disintegrator), i.e. a
*disk* packer which happened to pack files as well. This caused some
interesting twists in the design.
-=O=- Details, Details
The first implementation of LZW was designed around packing a 5.25&quot;
disk using as little memory as possible. The strategy was to grab 4K
chunks (the size of a single track on a 5.25&quot; floppy), put it through
an RLE pass (since tracks were often filled with zeros, this was very
effective), and then an LZW pass. If the RLE or LZW pass failed, it
would be omitted. If both failed, the block was stored without
compression. A few bits at the start of each chunk in the compressed
output held the information.
It turns out that putting a typical file through an RLE pass first
doesn't really do you much good, though it isn't likely to do much
harm. Mostly it just slows things down, unless the file is filled
with a single character. In some cases it can make things slightly
worse, because LZW is encoding the three-byte RLE codes instead of
encoding long strings of zeros with a single 9 to 12-bit symbol. If
more or all of a *disk* track is empty, RLE is a win, but it just
doesn't happen all that often in text files.
The LZW encoder was reset after every 4K of *input*, which meant that
it never had a chance to get completely full, and some of the 12-bit
code space was wasted. However, this limited the maximum height of
the tree considerably. For example, 4K of zeros can be compressed by
a degenerate tree with 91 nodes in it. Since RLE would compress such
a chunk, to get the worst case you have to alternate characters, so
the worst you can get is around 64. This meant that the LZW stack
required well under 100 bytes instead of 4096, and the loss in
compression wasn't too unpleasant.
The other nice feature is that, since the LZW table can't get
completely full, there's no need for explicit (or implicit) table
clears. The whole thing just gets wiped on 4K boundaries.
To find the end of the data, the size of the output was stored.
(Recall there are three ways of knowing when to stop: an explicit stop
character, knowing the size of the input, and knowing the size of the
output.) The LZW code given in lesson 8 used an explicit &quot;end of
file&quot; code because I thought it was more interesting to do it that
way, and because it works on a stream of data (you can't seek back and
write the length bytes on a continuous stream... but since ShrinkIt
knows the data will be &lt; 4K, it can just stuff the bytes in before it
writes to disk).
This scheme was eventually referred to as &quot;LZW-I&quot;, and is still used
by the ][+ and //e versions of ShrinkIt.
-=*=-
When writing GS/ShrinkIt, Andy Nicholas decided to hunker down and do
LZW with table clears and all the fancy nonsense. However, he kept
the 4K boundaries, which made things a bit confusing (and led to a bug
which hung around in GSHK, NuLib, and YankIt until rather recently).
Basically, the input was still read in 4K chunks, and the RLE pass was
still done. As before, the LZW pass was done on either the original
4K or the RLE output, depending on whether or not RLE helped. The
difference was that the table clears were no longer done after the end
of the input. Instead, an explicit table clear code ($100) was sent
whenever the table filled. To avoid having to make a copy of the
table on every chunk, the table was also cleared whenever LZW failed
to compress a piece of the file.
Of course, now the decoder stack had to be 4K, and all the fun with
the table clears had to be added in. The long-lasting bug mentioned
earlier occurred whenever a chunk ended after a table clear plus one
character - if you look at the LZW decoder, you'll see that it grabs
the first character, sets the prefix to that, and then plows onward.
So the decoder was grabbing the first character, reaching the end of
input, and then restarting with the next chunk by grabbing the first
character again. This isn't an issue if you don't chop things into 4K
pieces, which is why you don't see it mentioned in the class stuff.
So, LZW-II has all the advantages of an encoder which doesn't break
the input into pieces, and retains its heritage as a disk compressor.
One nice feature of the &quot;chunking&quot; is that it enables files with tough
spots in them to be compressed better. Suppose you have a file with
three pieces, call them A, B, and C. Let A and C be squishy text-like
substance, while B is essentially random digitized sound. Even if we
get 50% compression in A and C, B could expand by some amount (say,
25%), reducing or even nullifying the compression of A and C. By
storing the tough parts without compression, the only increase in B's
size is the few bits of overhead needed to identify it as
uncompressed.
This slightly anachronistic &quot;chunking&quot; behavior can help significantly
for some kinds of files. By reducing the overhead to only a few bytes
per 4K chunk, ShrinkIt will almost always do better than the simple
LZW encoder given in class. The price is greater complexity in the
compressor and decompressor, and a few bytes of overhead in the file.
If you want to see what effect the improvements had, compress some
files with ShrinkIt and then compress them with GS/ShrinkIt. The
difference tends to be small, which is counter to intuition, since LZW
does poorly at the start.
-=*=-
This section explains the format of the LZW-I and LZW-II compressed
threads. To find out what &quot;threads&quot; are, you'll need to consult the
NuFX file type note.
LZW-I looks like this:
+0 (word) 16-bit CRC for the uncompressed data
+2 (byte) disk volume # (remember, it started as a 5.25 disk packer)
+3 (byte) RLE escape char, usually 0xdb
+4 a series compressed chunks, each built from 4K of input. Each
chunk starts with the following:
++0 (word) size of data after RLE but before LZW (will be 4096
if RLE wasn't used)
++2 (byte) LZW flag - zero if LZW not used
++3 compressed data
So something packed with only RLE would have a size != 4096 and an LZW
flag of zero. LZW only would have a size == 4096 and LZW flag not
equal to zero. RLE+LZW and storing without compression can be
expressed by juggling things. The value at ++0 is used to decide when
the LZW uncompressor should stop.
The CRC is computed on the uncompressed data. If the last piece of
the file doesn't fill an entire 4K chunk, then the rest of the 4K
chunk is filled with zeros. The ENTIRE chunk is compressed, zeros and
all, and the CRC includes the extra zeros.
The actual LZW compression works like it did in class, with the
modifications described earlier. Even though no explicit table clears
are used, the codes begin at $101.
LZW-II looks like this:
+0 (byte) disk volume #
+1 (byte) RLE escape char, usually 0xdb
+2 a series compressed chunks, each built from 4K of input. Each
chunk starts with the following:
++0 (word) size of data after RLE but before LZW (will be 4096
if RLE wasn't used). The hi bit is used as the LZW flag,
i.e. $8000 is ORed in if LZW is used.
++2 (word) if and only if LZW is used, an extra length word is added
here, which gives the total length of the compressed data after
BOTH RLE and LZW.
++2 or
++4 compressed data
The reason for the extra length word is to provide a way to recover
pieces of a file even if one of the chunks has been corrupted. With
LZW-I, there's no way to identify the start of a chunk; with LZW-II,
you can seek from the current chunk header to the next. The value
isn't actually needed by the decompressor. If only RLE is used, then
the size at ++0 will be accurate, so it's omitted from the output.
Notice that there's no CRC included in the header. This is because
the CRC was moved to the thread header. It's computed with an initial
seed of 0xffff (for historical reasons), and is computed on the
original file. It does NOT include the zeros used to pad things to 4K
boundaries.
-=O=- Knowne Implementations of NuFX Programmes
- ShrinkIt (a/k/a &quot;P8 ShrinkIt&quot;). Runs on enhanced //e, //c, IIgs.
Requires 65c02. Packs with LZW-I, unpacks LZW-I and LZW-II.
- GS/ShrinkIt. Runs on IIgs only. Packs with LZW-II, unpacks LZW-I
and II. Also handles several other file formats, including .Z (UNIX
compress) and .ARC.
- ShrinkIt ][+ and UnShrinkIt ][+. Run on any Apple II, including
Apple ][+. One packs, the other unpacks.
- Auto-Unshrink. Runs on any Apple II (?). Sort of a strange
concept, but what the heck. Notable feature is a certain amount of
error recovery for damaged archives (it knows about and will use the
extra length word included for LZW-II).
- NuLib. Shell-based, runs on darn near anything. Packs with LZW-I,
unpacks LZW-I, LZW-II, and UNIX compress (yes Virginia, you can have
files packed with UNIX compress in a ShrinkIt archive... you just
can't unpack them with anything else).
- NuPak. Started out like NuLib and GS/ShrinkIt slammed together at
high speed, but never went anywhere. The $15 shareware fee and the
release of GSHK probably did it in.
- YankIt. Shell-based, IIgs only. Unpacks LZW-I and II, does not
pack at all. Faster (and smaller) than the others.
-=O=- PROGRAM
Being the author of both NuLib and YankIt, you'd figure I'd have some
decent sample source code to give away. However, it shapes up like
this:
- NuLib wasn't so much written as it was &quot;evolved.&quot; It started out as
an archive viewer, and expanded into a rather grotesque archiver. It
looks okay on the outside, but the innards are a mess. Fortunately,
it was written in C.
- YankIt is a cute little bare-bones archive viewer and extractor. It
fit into about 6000 lines of assembly, and took under a month to
design, implement, and test. My original intent was to release the
complete source code with this lesson, but some bugs have been found
and I haven't had the time to fix them, test it, etc, etc.
So, this means I'm going to flake and just point you at some useful
stuff. I'll get the YankIt sources out eventually.
-=*=-
First of all, the definitive reference on the NuFX format is the
filetype note for $e0/8002, which can be found in GEnie's A2Pro
library. The not-quite-so-definitive-anymore reference is in the
article AndyN wrote for the Winter 1990 Call-A.P.P.L.E. The article
also contains a bit of history about NuFX and ShrinkIt.
The NuLib source code, which contains a bug in the stack declaration
(only 100 bytes - correct for LZW-I, but not LZW-II, which should be
4096), can be found in the A2Pro library on GEnie, and on the
cco.caltech.edu anonymous FTP site.
NuLib executables for the IIgs and MS-DOS can also be found on GEnie,
in the appropriate sections. Documentation for the MS-DOS version got
renamed to &quot;NULIB.SHK&quot; or something equally meaningless. The file
comment is also wrong; use &quot;nulib xvt0 nulib.shk&quot; to convert the line
terminators from CR to CRLF. (It says to use &quot;xvt2&quot;, which would
convert CRLF to CRLF - a slightly silly thing to do.) NuLib has a
whole pile of options, and would be a great program if the source code
weren't so ugly.
(Hey, I started it a year after I started learning C, and well before
I figured out how LZW worked... be charitable.)
The YankIt executable can be found in GEnie's A2 section. This
contains the same stack bug found in NuLib, but it's smart enough to
complain about the archive being corrupted and bail without scrubbing
itself. It's got a nice &quot;integrity check&quot; feature which runs through
and uncompresses every file, checking CRCs, but doesn't actually store
them anywhere. NuLib acts like it has a similar feature, but it lies.
GSHK should have a similar feature, but I caught AndyN too close to
the shipping date of v1.1.
Since NuLib and YankIt are shell-based, and I didn't want to add the
code to correctly handle disk archives, they extract disks as a single
file. This can be useful for UNIX and MS-DOS Apple II emulators which
require disk-files. Note that ShrinkIt uses ProDOS sector mapping, so
the disks will work fine for the known UNIX emulators, but not for the
MS-DOS emulator (which expects DOS 3.3 sector ordering). There are
programs available which change the order around.
-=O=- DEEP THOUGHTS
- What are the advantages of writing an archiver which processes
archive entries individually instead of reading them all at once?
(hint: &quot;yankit xv - &lt; file.shk&quot;)
- Is 4096 the optimal size for stopping and checking compression
progress?
- How does ShrinkIt's &quot;checkpoint every 4K&quot; compare to v.42bis? (see
lesson 8 for details on v.42bis)
- Why does ShrinkIt clear the table after a chunk fails to compress
with LZW? What would you have to do to avoid doing so?
-=!=-
</pre><hr>
<address>This document is Copyright by Genie and Andy McFadden</address>
<!--msnavigation--></td></tr><!--msnavigation--></table></body>
</html>

4
library/_vti_cnf/Crc16.c.txt Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|23 Aug 2000 17:09:22 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/ftn.e08002.htm

24
library/_vti_cnf/FTN.e00001.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|31 Mar 2001 23:27:59 -0000
vti_timelastmodified:TR|31 Mar 2001 23:50:31 -0000
vti_shadowfiles:VX|
vti_filesize:IR|18223
vti_title:SR|FTN.e00001
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm
vti_nexttolasttimemodified:TR|31 Mar 2001 23:29:42 -0000
vti_cacheddtm:TX|31 Mar 2001 22:50:30 -0000
vti_cachedlinkinfo:VX|H|index.htm
vti_cachedsvcrellinks:VX|FHUS|library/index.htm
vti_cachedtitle:SR|FTN.e00001
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

24
library/_vti_cnf/FTN.e000023.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|31 Mar 2001 23:27:59 -0000
vti_timelastmodified:TR|31 Mar 2001 23:50:40 -0000
vti_filesize:IR|23942
vti_title:SR|FTN.e000023
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm
vti_nexttolasttimemodified:TR|31 Mar 2001 23:32:29 -0000
vti_shadowfiles:VX|
vti_cacheddtm:TX|31 Mar 2001 22:50:40 -0000
vti_cachedlinkinfo:VX|H|index.htm
vti_cachedsvcrellinks:VX|FHUS|library/index.htm
vti_cachedtitle:SR|FTN.e000023
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

23
library/_vti_cnf/FTN.e00005.htm Normal file
View File

@ -0,0 +1,23 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_timecreated:TR|31 Mar 2001 23:27:59 -0000
vti_timelastmodified:TR|08 Oct 2002 02:13:58 -0000
vti_filesize:IR|10628
vti_title:SR|FTN.e00005
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.5526
vti_backlinkinfo:VX|library/index.htm
vti_nexttolasttimemodified:TR|31 Mar 2001 23:33:44 -0000
vti_shadowfiles:VX|
vti_cacheddtm:TX|08 Oct 2002 02:13:58 -0000
vti_cachedlinkinfo:VX|H|index.htm
vti_cachedsvcrellinks:VX|FHUS|library/index.htm
vti_cachedtitle:SR|FTN.e00005
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

24
library/_vti_cnf/FTN.e08000.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|31 Mar 2001 23:27:59 -0000
vti_timelastmodified:TR|31 Mar 2001 23:50:58 -0000
vti_filesize:IR|28685
vti_title:SR|FTN.e08000
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/old-binary2-spec.htm library/index.htm
vti_nexttolasttimemodified:TR|31 Mar 2001 23:35:11 -0000
vti_shadowfiles:VX|
vti_cacheddtm:TX|31 Mar 2001 22:50:58 -0000
vti_cachedlinkinfo:VX|H|index.htm
vti_cachedsvcrellinks:VX|FHUS|library/index.htm
vti_cachedtitle:SR|FTN.e08000
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

23
library/_vti_cnf/FTN.e08002.htm Normal file
View File

@ -0,0 +1,23 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_timecreated:TR|31 Mar 2001 23:27:59 -0000
vti_timelastmodified:TR|05 May 2002 21:01:30 -0000
vti_filesize:IR|53231
vti_title:SR|FTN.e08002
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|library/old-nufx-spec.htm nufxlibapi.htm library/index.htm library/nufx-addendum.htm
vti_nexttolasttimemodified:TR|31 Mar 2001 23:51:11 -0000
vti_shadowfiles:VX|
vti_cacheddtm:TX|05 May 2002 21:01:30 -0000
vti_cachedlinkinfo:VX|H|index.htm H|Crc16.c.txt
vti_cachedsvcrellinks:VX|FHUS|library/index.htm FHUS|library/Crc16.c.txt
vti_cachedtitle:SR|FTN.e08002
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

24
library/_vti_cnf/Lesson9.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|31 Mar 2001 23:27:59 -0000
vti_timelastmodified:TR|31 Mar 2001 23:42:04 -0000
vti_filesize:IR|16806
vti_title:SR|Hacking Data Compression - Lesson 9
vti_metatags:VR|HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|library/index.htm
vti_nexttolasttimemodified:TR|31 Mar 2001 23:40:39 -0000
vti_shadowfiles:VX|
vti_cacheddtm:TX|31 Mar 2001 23:42:04 -0000
vti_cachedlinkinfo:VX|H|index.htm
vti_cachedsvcrellinks:VX|FHUS|library/index.htm
vti_cachedtitle:SR|Hacking Data Compression - Lesson 9
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

4
library/_vti_cnf/gshk11.sea Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|31 Jan 2000 05:35:38 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm

24
library/_vti_cnf/index.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|Administrator
vti_timecreated:TR|11 Jan 2000 07:01:48 -0000
vti_timelastmodified:TR|08 Oct 2002 02:36:28 -0000
vti_shadowfiles:VX|
vti_filesize:IR|3953
vti_title:SR|NuLib Library
vti_metatags:VR|HTTP-EQUIV=Content-Language en-us HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|library/ftn.e00005.htm library/old-nufx-spec.htm downloads/index.htm index.htm library/ftn.e00001.htm library/ftn.e08000.htm library/ftn.e08002.htm library/old-binary2-spec.htm library/ftn.e000023.htm library/lesson9.htm
vti_nexttolasttimemodified:TR|31 Mar 2001 23:44:18 -0000
vti_cacheddtm:TX|08 Oct 2002 03:36:30 -0000
vti_cachedlinkinfo:VX|H|nufx-addendum.htm H|nulib2-preserve.htm H|FTN.e00001.htm H|FTN.e000023.htm H|FTN.e00005.htm H|FTN.e08000.htm H|FTN.e08002.htm H|Lesson9.htm K|http://www.fadden.com/dl-apple2/ H|old-nufx-spec.htm H|old-binary2-spec.htm H|../downloads/nulib325.tar.gz H|nulib324.tar.gz H|nulib324doc.txt H|nulib303.tar.gz H|nulib22.tar.gz H|nulib21.tar.gz H|nuview.tar.gz H|shrinkit.sdk H|gshk11.sea H|yanksrc.shk
vti_cachedsvcrellinks:VX|FHUS|library/nufx-addendum.htm FHUS|library/nulib2-preserve.htm FHUS|library/FTN.e00001.htm FHUS|library/FTN.e000023.htm FHUS|library/FTN.e00005.htm FHUS|library/FTN.e08000.htm FHUS|library/FTN.e08002.htm FHUS|library/Lesson9.htm NHHS|http://www.fadden.com/dl-apple2/ FHUS|library/old-nufx-spec.htm FHUS|library/old-binary2-spec.htm FHUS|downloads/nulib325.tar.gz FHUS|library/nulib324.tar.gz FHUS|library/nulib324doc.txt FHUS|library/nulib303.tar.gz FHUS|library/nulib22.tar.gz FHUS|library/nulib21.tar.gz FHUS|library/nuview.tar.gz FHUS|library/shrinkit.sdk FHUS|library/gshk11.sea FHUS|library/yanksrc.shk
vti_cachedtitle:SR|NuLib Library
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

25
library/_vti_cnf/nufx-addendum.htm Normal file
View File

@ -0,0 +1,25 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|fadden
vti_timecreated:TR|16 Jan 2000 01:49:15 -0000
vti_timelastmodified:TR|26 Sep 2004 18:51:25 -0000
vti_filesize:IR|34265
vti_title:SR|NuFX Addendum
vti_metatags:VR|HTTP-EQUIV=Content-Language en-us HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.7802
vti_backlinkinfo:VX|nufxlibapi.htm library/index.htm
vti_nexttolasttimemodified:TR|26 Sep 2004 18:47:01 -0000
vti_structuredtm:TR|16 Jan 2000 19:37:14 -0000
vti_shadowfiles:VX|
vti_cacheddtm:TX|26 Sep 2004 18:51:26 -0000
vti_cachedlinkinfo:VX|H|FTN.e08002.htm H|http://www.zlib.org/ H|http://sources.redhat.com/bzip2/ H|http://www.fadden.com/ H|http://www.nulib.com/
vti_cachedsvcrellinks:VX|FHUS|library/FTN.e08002.htm NHHS|http://www.zlib.org/ NHHS|http://sources.redhat.com/bzip2/ NHHS|http://www.fadden.com/ NHHS|http://www.nulib.com/
vti_cachedtitle:SR|NuFX Addendum
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

24
library/_vti_cnf/nulib2-preserve.htm Normal file
View File

@ -0,0 +1,24 @@
vti_encoding:SR|utf8-nl
vti_author:SR|fadden
vti_modifiedby:SR|Administrator
vti_timecreated:TR|16 Jan 2000 19:37:01 -0000
vti_timelastmodified:TR|09 Feb 2003 20:14:39 -0000
vti_shadowfiles:VX|
vti_filesize:IR|18445
vti_title:SR|NuLib2's ProDOS Attribute Preservation
vti_metatags:VR|HTTP-EQUIV=Content-Language en-us HTTP-EQUIV=Content-Type text/html;\\ charset=windows-1252 GENERATOR Microsoft\\ FrontPage\\ 4.0 ProgId FrontPage.Editor.Document
vti_progid:SR|FrontPage.Editor.Document
vti_generator:SR|Microsoft FrontPage 4.0
vti_extenderversion:SR|4.0.2.6513
vti_backlinkinfo:VX|nulib2-manual.htm library/index.htm
vti_nexttolasttimemodified:TR|09 Feb 2003 20:12:14 -0000
vti_cacheddtm:TX|09 Feb 2003 20:14:40 -0000
vti_cachedlinkinfo:VX|H|http://www.fadden.com/ H|http://www.nulib.com/
vti_cachedsvcrellinks:VX|NHHS|http://www.fadden.com/ NHHS|http://www.nulib.com/
vti_cachedtitle:SR|NuLib2's ProDOS Attribute Preservation
vti_cachedbodystyle:SR|<body bgcolor="#FFFFFF" text="#000000">
vti_cachedhasbots:BR|true
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|true
vti_botnavbits:SW|SHUB
vti_borderaggregate:SR|default

4
library/_vti_cnf/nulib21.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|13 Jan 2000 07:49:18 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm

4
library/_vti_cnf/nulib22.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|13 Jan 2000 07:49:18 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm

4
library/_vti_cnf/nulib303.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|13 Jan 2000 07:49:18 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm

4
library/_vti_cnf/nulib324.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|31 May 1998 22:31:04 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm

11
library/_vti_cnf/nulib324doc.txt Normal file
View File

@ -0,0 +1,11 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|05 May 2002 21:07:10 -0000
vti_extenderversion:SR|4.0.2.2717
vti_cacheddtm:TX|13 Jan 2000 07:43:44 -0000
vti_filesize:IR|37824
vti_cachedlinkinfo:VX|
vti_cachedsvcrellinks:VX|
vti_cachedhasbots:BR|false
vti_cachedhastheme:BR|false
vti_cachedhasborder:BR|false
vti_backlinkinfo:VX|library/index.htm

4
library/_vti_cnf/nuview.tar.gz Normal file
View File

@ -0,0 +1,4 @@
vti_encoding:SR|utf8-nl
vti_timelastmodified:TR|13 Jan 2000 07:49:18 -0000
vti_extenderversion:SR|4.0.2.2717
vti_backlinkinfo:VX|library/index.htm

Some files were not shown because too many files have changed in this diff Show More