P.S. Where can I download MacQForth?
The problem is that the Mac tends to create a fork on every
file that it handles--whether it needs one or not, and whether
you like it or not.
Since it obviously has no difficulty synthesizing a default
fork whenever it wants to, I can't imagine why it bothers to
actually attach one to the file until it is *actually needed*
to store something non-default about it!
In the past, I've used UNFORKIT to rather hamhandedly remove
the resource fork from ProDOS files that have been "forked"
by a Mac.
I'm not a Mac user, so perhaps someone here has a foolproof
method for keeping files "in transit" on a Mac from attracting
forks. ;-)
-michael
NadaPong: Network game demo for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Yes, try "UNFORKIT".
Willi
Since the file was originally a zip file open it up on your Powerbook
and see what the contents of the file are. Shrinkit can't handle zip
files, even if you change the name from qforth.zip to qforth.shk it's
still a Zip file. You might find that the zip file contains usable
disk images.
Dean
On Dec 21, 4:00 pm, Dean wrote:
> Since the file was originally a zip file
Oops, missed that the file Dietmar is working with is a '.ZIP'
file. I don't know where it came from but there are QForth '.SHK'
files in the "unsorted" directory on the Asimov site.
Willi
I don't know about "foolproof" but I believe that at least with older
versions of Mac OS it was possible to preserve a downloaded file in an
"unforked" state for transfer to a ProDOS disk for an 8-bit Apple II.
The trick is to make sure the Mac file type and creator codes are ones
which can be represented on ProDOS. There is a mapping between the Mac
creator/filetype and the ProDOS filetype/auxtype. If the Mac
creator/filetype cannot be represented, then MacOS creates an extended
file so it can store the Mac directory metadata.
The best way to do this is to ensure the Mac creator is 'pdos' and the
filetype is one which maps to a ProDOS filetype or filetype/auxtype.
The original mapping system (used by Apple File Exchange) has a "Hex
ASCII" Mac filetype with space padding, e.g. 'FF ' to represent a
ProDOS filetype but no auxiliary type.
The later mapping system (used by ProDOS File System Extension) has a
Mac filetype of 'p' followed by a binary encoded single byte ProDOS
filetype and two byte auxiliary type. This makes it rather hard to type
and to read.
Some common types can also be translated, e.g. 'TEXT' will map to ProDOS
filetype $04, so in the case of a ShrinkIt file, the easiest solution is
to use a Mac creator/filetype of pdos/TEXT, which will map to a ProDOS
filetype of $04 and auxtype of $0000, and will not require an extended
file. It should be possible to open this with 8-bit unshrink utilties.
(Of course, in this case the OP is dealing with a Zip file, which is a
separate issue - they would need an 8-bit unzip utility rather than
ShrinkIt.)
As I was using a IIgs and didn't have much access to Macs around the
same time, this problem never bothered me much. If I was using Macs
then, the GS/OS tools would have been fine with an extended file. It was
only ProDOS-8 which couldn't cope with extended files.
--
David Empson
dem...@actrix.gen.nz
No, they are not Zip-files. The author of QForth (http://
www.geocities.com/oneelkruns/qforth.html) says:
"These are ShrinkIt archives, change the extension to '.shk' once
downloaded!"
He saves the files as ShrinkIt but names them as .zip. ???
Probably because most browsers (didn't) know what to do with
SHK files.
I have the same problem with UNFORKIT0.1.SHK.
BTW: ResEdit says that the files have no resource fork.
yes, they are SHK's renamed to zip. I downloaded them,
renamed them to .shk, opened with Ciderpress, converted
to DSK image, and they work...
send me an email aiiadict at gmail dot com and I'll send
you the DSK images if you want
Rich
> I have the same problem with UNFORKIT0.1.SHK.
> BTW: ResEdit says that the files have no resource fork.
The resource fork isn't the problem - there is no resource fork, as you
have observed.
It is the fact that the Mac wants to retain the Mac-specific directory
information (particularly the file type and creator), and in order to do
this, it has to create an extended file on a ProDOS volume. ProDOS-8
can't read these (but GS/OS has no problem with them).
This issue can be avoided if the Mac creator and file type are set to
values which can be represented in the ProDOS directory. In this case,
the Mac doesn't need to create an extended file.
A simple solution is to use a Mac utility program (e.g. ResEdit's Get
File Info, if I remember right) to set the Mac creator to 'pdos' and
filetype to 'TEXT' before trying to copy the file to a ProDOS volume.
See my earlier post for more details.
--
David Empson
dem...@actrix.gen.nz
Yes, changing to creator pdos and filetype TEXT before copying to the
PRODOS volume works!
Thank you very much!
The QForth '.SHK' files on the Asimov site are the older version
2.2. So, if you want the latest and greatest, access the Geocities
URL mentioned in a prior message.
Willi
You hadn't mentioned before that the author titled them with .zip but
said they needed to be changed to .shk to open. So another
possibility, if you have a GS emulator on your Mac, use ADFS Carbon to
open up your hard disk image for the GS, import the qforth1.zip into
the hard disk image, fire up your GS emulator and then in the GS
change the end of the file name from .zip to .shk and use either
Shrinkit or Shrinkit GS to open up the archive and save it to a disk
image which you can then transfer to your real Apple II.
Dean
In fact, ShrinkIt doesn't care what type or suffix a file has if
you put it into "all files" mode (Open Apple-A). It will happily
open anything if it actually *is* a ShrinkIt file inside.