Wonderful ProDOS patch!
Phillip Vandry
namefix. (Author: Tom Larson). It basically patches the P8 kernel and ProDOS
FST to alleviate the file naming restrictions.
It's quite a patch. It changes 21 bytes at various places in a 25K file. This
guy must have worked quite a bit to get it right! And it's certainly very
beneficial.
Why can't I have hyphens or underscores in my filenames? Or commas (used
by RCS, maybe it will get ported)? There's really no good reason for it and
the patch basically removes restrictions.
It seems to work flawlessly too.. It nearly fixes one or ProDOS's two biggest
limitations!
My question is: why have I not seen anything on this? Has nobody heard of it?
Maybe there's a catch and it's really not as good as it seems to be? :-)
-Phil
Matthew Fischer
Phillip Vandry <van...@CAM.ORG> wrote:
>I got my resource central disk and there was a little patch on it called
>namefix. (Author: Tom Larson). It basically patches the P8 kernel and ProDOS
>FST to alleviate the file naming restrictions.
As I understand it, it's still not supposed to allow ":" because it is illegal
in many file systems.
>It seems to work flawlessly too.. It nearly fixes one or ProDOS's two biggest
>limitations!
The version I've seen makes a patch to reject the ":" character, but then it
patches another part of the loop to jump over this test, so it still accepts
":" as legal, even though it's not supposed to.
>My question is: why have I not seen anything on this? Has nobody heard of it?
>Maybe there's a catch and it's really not as good as it seems to be? :-)
Well, Tom Larson posts in the Apple II FidoNet echo, and it's been discussed
there. I mentioned the ":" bug, and he said he'd be releasing a new version
that fixed it. Does the version you have allow ":"s in filenames?
Phillip Vandry
>The version I've seen makes a patch to reject the ":" character, but then it
>patches another part of the loop to jump over this test, so it still accepts
>":" as legal, even though it's not supposed to.
>>My question is: why have I not seen anything on this? Has nobody heard of it?
>>Maybe there's a catch and it's really not as good as it seems to be? :-)
>Well, Tom Larson posts in the Apple II FidoNet echo, and it's been discussed
>there. I mentioned the ":" bug, and he said he'd be releasing a new version
>that fixed it. Does the version you have allow ":"s in filenames?
Ah, OK, well someone asked me to post it here, so I did..
I can't see how it could allow ":" in filenames because this is interpreted as
a separator by GS/OS before the pathname gets to the File system translator
level.
I suppose the P8 version might allow ":", making the file inaccessible to
GS/OS, but I also suppose a patch to fix that would be MUCH more difficult
that the current patch because it would probably involve addition of code,
which can't be done by a patch.
Hey, it's a hack - I'm willing to live with the fact that I should be careful
what files I create (also, filenames with '/' in them, while probably
handled by GS/OS, would be inaccessible in P8)
-Phil
Lim Thye Chean
: I got my resource central disk and there was a little patch on it called
: namefix. (Author: Tom Larson). It basically patches the P8 kernel and ProDOS
: FST to alleviate the file naming restrictions.
: It's quite a patch. It changes 21 bytes at various places in a 25K file. This
: guy must have worked quite a bit to get it right! And it's certainly very
: beneficial.
If this program is a freeware or shareware, do you mind post it in the net
or put it in some ftp sites? Thanks! This definitely sound great!
: -Phil
--
%% GS Lover Loves GS %% Author of Super Magic 3 & Mandelbrot II GS
Lim Thye Chean: Lim is my surname. My name is Thye Chean.
My address: LTC...@ISS.NUS.SG, or 9, College Green, Singapore 1129
Matthew Fischer
Phillip Vandry <van...@CAM.ORG> wrote:
>I suppose the P8 version might allow ":", making the file inaccessible to
>GS/OS, but I also suppose a patch to fix that would be MUCH more difficult
>that the current patch because it would probably involve addition of code,
>which can't be done by a patch.
Yes, I was referring to the ProDOS 8 patch. I haven't used the GS/OS
patch. It's really not all that difficult to fix it. Here is my own
version of the ProDOS/P8 patches to trap the ":" character. (I also
expanded the upper end of the range of permissible characters. Jeff
Brielmaier posted a script to do that a while ago on the FidoNet.)
prodos ,2.0.3,prodos,sys,2000,42e8,0,6
13012,13,5
13017,8,12
13028,240,144
13029,8,210
13031,32,65
13035,97,91
p8 ,2.0.3,p8,sys,2000,42e8,0,6
13012,13,5
13017,8,12
13028,240,144
13029,8,210
13031,32,65
13035,97,91
The "2.0.3" in the first lines could probably be changed to "2.0.x",
but I used "2.0.3" because that's the only version I've tried it with.
Here is my own version of the BASIC.SYSTEM patch. It does the same
thing in essence as Tom Larson's, but it saves a couple of cycles
under certain circumstances. :)
basic.system ,1.5,basic.system,sys,2000,2800,0,3
12552,32,65
13340,4,40
13371,4,9
Michael Stipe
>been discussed there. I mentioned the ":" bug, and he said he'd
>be releasing a new version that fixed it. Does the version you
>have allow ":"s in filenames?
Having just talked with him, here is the deal: As of version 1.6
which was just posted online last night, the prodos8 script does
not allow colons in filenames. The prodos.fst script probably
allows slashes (p8 seperator) although I haven't checked it.
>Hey, it's a hack - I'm willing to live with the fact that I
>should be careful what files I create (also, filenames with '/'
>in them, while probably handled by GS/OS, would be inaccessible
>in P8)
Exactly. You could also create a filename that was all spaces and
make life difficult for people using cli environments, but why?
A future version of the prodos.fst script may screen out slashes
(by modifying the code to check for 0x20 to 0x60 you no longer need
to check 0x30 to 0x39 (numbers) or for periods, plenty o' room :).
Proline: grebben@pro-greens
Internet: gre...@pro-greens.benton-city.wa.us
UUCP: pro-greens.benton-city.wa.us!grebben
Matthew Fischer
Michael Stipe <gre...@pro-greens.benton-city.wa.us> wrote:
>Having just talked with him, here is the deal: As of version 1.6
>which was just posted online last night, the prodos8 script does
>not allow colons in filenames. The prodos.fst script probably
>allows slashes (p8 seperator) although I haven't checked it.
Great! Could you email me a copy of his ProDOS/P8 script and his BASIC.SYSTEM
script? I'm anxious to see how he rewrote the patch and compare it to my
version.
Lim Thye Chean
at least on my system.
Later I found that it required Pro.Fst to be of version 4.1, but the one on
my system 6.0.1 disk is only 4.02! Where do I get the new Pro.fst? How do
I check the version of P8 and Basic.System?
What is that Prodos 8 file there for? The xxx.system (can't remember what
is that xxx's name now)...
Thanks for any answer, I have been looking for something like that for long...
Chris Deschu
Also, it says that it modifies ProDOS 8 2.0.1, and the current is 2.0.3...
I hope the mentioned update addresses these problems too.
--
______________________________________________________________________________
|___ Chris Deschu cde...@nyx.cs.du.edu
_|_|con (215) 791-3596 4804 Bowood Street, Center Valley, PA. 18034-9628
:-)|echnologies is IT in the Lehigh Valley for Apple ][ Consulting and Repairs
j.l.walters
look forward to receiving .SHK files from various sources that they
cannot read/copy/modify?
If so, I think this is a very BAD idea and needs to be rethought. This
is a change to the operating system and as such MUST be looked at by
those that OWN the OS, i.e., Apple Computer. I know it seems that they
have abandoned us, however, just today I saw a post from Dave Lyons so
our friends are still with us.
If it is a GREAT idea then I do believe that Apple (read, our friends),
will somehow come out with a ProDOS 2.0.2 that incorporates these
changes. If they don't, then we should shun anyone/anything trying to
modify our platform into certain chaos.
Kind Regards,
--
Joe Walters att!ihlpm!bird, NW 31-K14 (708) 224-7189
To know, and not to do, is not yet to know
David E A Wilson
>Does this patch mean that those that do not get/accept the patch can
>look forward to receiving .SHK files from various sources that they
>cannot read/copy/modify?
That would indeed be a problem.
>If so, I think this is a very BAD idea and needs to be rethought. This
>is a change to the operating system and as such MUST be looked at by
>those that OWN the OS, i.e., Apple Computer. I know it seems that they
>have abandoned us, however, just today I saw a post from Dave Lyons so
>our friends are still with us.
After you make these changes to your copy of ProDOS 8 it is no longer
ProDOS 8 (perhaps we should call it ProDOS 9?). Why Apple put these
restrictions in ProDOS v1.0 I do not know (unless it was backwards
compatibility with SOS on the Apple /// - in which case why did Apple
restrict SOS (after all the DOS 3.x could always use a wider range of
characters in file names and the Apple /// had a full keyboard with U/LC
support)).
>If it is a GREAT idea then I do believe that Apple (read, our friends),
>will somehow come out with a ProDOS 2.0.2 that incorporates these
>changes. If they don't, then we should shun anyone/anything trying to
>modify our platform into certain chaos.
Apple cannot make these changes as it would make existing Apple & 3rd party
applications unable to access these files with strange names. That is why
the GS/OS ProDOS FST encodes lowercase information in the otherwise unused
version fields.
P.S. v2.0.2 came and went. We are now on v2.0.3.
Dan Brown
bi...@cbnewsd.cb.att.com (j.l.walters) writes:
>If it is a GREAT idea then I do believe that Apple (read, our friends),
>will somehow come out with a ProDOS 2.0.2 that incorporates these
Well, ProDOS is up to version 2.0.3 without those changes... (-:
----------------------------------
Dan Brown, Sysop of pro-newton Internet: da...@pro-newton.cts.com
Above opinions are not those of Mensa, which has no opinions.
GO D++ P+/-P+ C++ L+.5 M++ S+ G+- W+ T R-
Loren Damewood
>Does this patch mean that those that do not get/accept the patch can
>look forward to receiving .SHK files from various sources that they
>cannot read/copy/modify?
We already get oddball names sometimes, when someone uses GSHK to shrink files
on HFS volumes, and you are given the option to rename them, but I don't know
if 8-bit ShrinkIt offers the option. Hmm, time to experiment . . .
>will somehow come out with a ProDOS 2.0.2 that incorporates these
Kinda unlikely, as ProDOS is already up to 2.0.3 . . .
Loren
Matthew Fischer
David E A Wilson <da...@wraith.cs.uow.edu.au> wrote:
>ProDOS 8 (perhaps we should call it ProDOS 9?). Why Apple put these
>restrictions in ProDOS v1.0 I do not know (unless it was backwards
>compatibility with SOS on the Apple /// - in which case why did Apple
>restrict SOS (after all the DOS 3.x could always use a wider range of
>characters in file names and the Apple /// had a full keyboard with U/LC
>support)).
Am I alone in thinking that it's really annoying to type in filenames with
funny punctuation characters in them? I think letters, numbers, and periods
do the job just fine. I realise that the Patch :) increases cross-platform
compatibility, but I know that, given this new capability, people will come
up with Apple-specific files with really bad filenames.
Soenke Behrens
: In article <2g308s$5...@wraith.cs.uow.edu.au>,
: David E A Wilson <da...@wraith.cs.uow.edu.au> wrote:
: >ProDOS 8 (perhaps we should call it ProDOS 9?). Why Apple put these
: >restrictions in ProDOS v1.0 I do not know (unless it was backwards
: funny punctuation characters in them? I think letters, numbers, and periods
Apparently so :) I find underscores particularly attractive, I have to
admit :)
: compatibility, but I know that, given this new capability, people will come
: up with Apple-specific files with really bad filenames.
Yeah, but GSHK let's you rename those ... or unpack to HFS. But you are
right, this could get a Real Problem (tm). But then, the user's will
is his heaven ...
Soenke
--
===========================================================================
Ich habe den Todesloewen gesehen -- er ! Soenke Behrens
wacht vor der Grube der Namenszuege. ! Tumblinger 54/205
(Pieter Gefjon) ! 80337 Muenchen
Lim Thye Chean
: Does this patch mean that those that do not get/accept the patch can
: look forward to receiving .SHK files from various sources that they
: cannot read/copy/modify?
: If so, I think this is a very BAD idea and needs to be rethought. This
: is a change to the operating system and as such MUST be looked at by
: those that OWN the OS, i.e., Apple Computer. I know it seems that they
: have abandoned us, however, just today I saw a post from Dave Lyons so
: our friends are still with us.
Don't you ever received any SHK file using HFS pathname? ShrinkIt will
just tell you that the name is legal, and let you edit the name.
yes, you can read/copy/modify the file.
: Kind Regards,
: --
: Joe Walters att!ihlpm!bird, NW 31-K14 (708) 224-7189
: To know, and not to do, is not yet to know
--
Lim Thye Chean
: Also, it says that it modifies ProDOS 8 2.0.1, and the current is 2.0.3...
: I hope the mentioned update addresses these problems too.
I apply the P8 2.0.1 patch to P8 2.0.3 and it seems to work ok... I am not
sure whether there is any problem with that. But I do like the ability to
name file like abc!@#$. One thing I don't know how to do is: how to you
rename or access a file with space? You can't simply do this say:
rename file.1, file 1
Lim Thye Chean
: Later I found that it required Pro.Fst to be of version 4.1, but the one on
: my system 6.0.1 disk is only 4.02! Where do I get the new Pro.fst? How do
: I check the version of P8 and Basic.System?
I found that the documentation make a mistake! What it really means in 4.01,
not 4.1! Therefore if you use the Pro.fst on System 6, it will work.
I think the namefix uploaded is actually meant for System 6, not 6.0.1.
But I do use it, and really _LOVE_ it! All I want is really have file names
with spaces, not any !@#$%^&, and I now have it. Thanks to the author and
the kind one who uploaded it! And yes, when new version available (I heard
that it is already available elsewhere besides Internet), please please
please upload it!
One less reason to use HFS. :)
Greg Berigan
>I think the namefix uploaded is actually meant for System 6, not 6.0.1.
>But I do use it, and really _LOVE_ it! All I want is really have file names
>with spaces, not any !@#$%^&, and I now have it.
I seem to remember long ago (pre System 6) someone had a patch that
would allow spaces. It merely allowed the period to be made lowercase
and translated it to a space. All applications could still use the file
by having you use the capital version (the period) where there was a
space.
I'd be happy with ProDOS 8 just being able to display all filenames as
GS/OS sees them, including when from BASIC.System you CATALOG a file
server (with the limitation of no non-ascii characters (TM, (C), etc.)).
--
gber...@cse.unl.edu (Greg Berigan)
Be articulate! Your new patience will not show up immediately.
Lim Thye Chean
: ltc...@iss.nus.sg (Lim Thye Chean) writes:
: >I think the namefix uploaded is actually meant for System 6, not 6.0.1.
: >But I do use it, and really _LOVE_ it! All I want is really have file names
: >with spaces, not any !@#$%^&, and I now have it.
: I seem to remember long ago (pre System 6) someone had a patch that
: would allow spaces. It merely allowed the period to be made lowercase
: and translated it to a space. All applications could still use the file
: by having you use the capital version (the period) where there was a
: space.
I redownloaded the program not long ago. But it is not for System 6. But the
ProDOS namefix patch work much better than that program, IMHO.
Within a day, 90% of the files in my harddisk are now in more natural name,
like Beauty & Beast, Crazy 8s.
It is definitely the best thing to happen to ProDOS since GS/OS. Now I am
hoping someone can help to increase the size of the name space... so I can
write Beauty & the Beast seq, or Out of This World.
: I'd be happy with ProDOS 8 just being able to display all filenames as
: GS/OS sees them, including when from BASIC.System you CATALOG a file
: server (with the limitation of no non-ascii characters (TM, (C), etc.)).
Well, you can now do it in namefix.
Soenke Behrens
: hoping someone can help to increase the size of the name space... so I can
: write Beauty & the Beast seq, or Out of This World.
Speaking of GS/OS ... what ever happened to HFS? Do you not use it because
it's slower?
Richard G Sarner
: namefix. (Author: Tom Larson). It basically patches the P8 kernel and ProDOS
: FST to alleviate the file naming restrictions.
or put it in some ftp sites? Thanks! This definitely sound great!
It's freeware. Tom Larson is on the Fido Int'l Apple ][ echo. Namefix was written as a patch to accompany 2qwk! a mailer for qwk mail packets. There is a new version of both available on his host BBS. I'll upload them on cco.caltech.edu after I get them.
---Richard
rsa...@powhatan.cc.cnc.edu
------------------------------------------------------------
To be and not to be. - Zen Shakespere
------------------------------------------------------------
Cum dignitate otium
mfis...@nyx10.cs.du.edu (Matthew Fischer) writes:
Actually, it was a deliberate attempt to make first SOS and then ProDOS look
more Professional.
^^^
The popular operating systems at that time were CP/M and the newly-hatched
MS-DOS, both of which restricted things even further, limiting names to 8 and
9 characters respectively, with a 3-character filetype extension that was (and
still is) the mechanism the OS used to decide what to do with the file. These
two systems have no concept of real file typing the way Apple does it; with an
Apple II or Macintosh, you can change a file's name without changing its type,
but CP/M and MS-DOS don't like that. Rename MUMBLE.EXE, and MS-DOS won't be
able to run it.
Anyway, Apple wanted ProDOS to resemble MS-DOS, which was IBM and therefore a
professional operating system. BWAHAHAHAHAHAHA!!!
-dick binder
--
>>>>> Hic sententiae mihi solo sunt, non Conlegioni Armorum Digitalum. <<<<<
Digital Equipment Corporation DEC Easynet: VORTEX::CALIPH::BINDER
110 Spit Brook Road, ZKO3-3/Y32 uucp: ...!decvax.dec.com!binder
Nashua, NH 03062-9987 Internet: bin...@zk3.dec.com
--
>>>>> Hic sententiae mihi solo sunt, non Conlegioni Armorum Digitalum. <<<<<
Digital Equipment Corporation DEC Easynet: VORTEX::CALIPH::BINDER
110 Spit Brook Road, ZKO3-3/Y32 uucp: ...!decvax.dec.com!binder
Nashua, NH 03062-9987 Internet: bin...@zk3.dec.com
Sheldon Simms
>
>Anyway, Apple wanted ProDOS to resemble MS-DOS, which was IBM and therefore a
>professional operating system. BWAHAHAHAHAHAHA!!!
Interesting theory, what about the fact that SOS existed before MS-DOS?
-Sheldon
--
W. Sheldon Simms | Newt's Friend / Jack Kemp for President
she...@netcom.com | Freedom implies responsibility
-------------------------+--------------------------------------------
Randy Shackelford
>It is definitely the best thing to happen to ProDOS since GS/OS. Now I am
Just keep it away from my machine. I think it's a stupid idea.
>hoping someone can help to increase the size of the name space... so I can
>write Beauty & the Beast seq, or Out of This World.
Sure, as soon as the entire file system is redesigned. Good grief, just use
HFS already.
--
Randy Shackelford "That's right, keep dancing
sh...@pro-ict.cts.com on the minefield"
-Al Bundy
Victoria M Althoff
was CP/M. So SOS looked like CP/M, complete with directory trees, but operated
more like DOS 3.3 on the A][.
Come on, IBM people, admit it: MS-DOS is really just a souped up version of
CP/M, which was out of date by the time the first Apple ][ rolled off the line!
--Dave Althoff, Jr.
(okay, so I'm a LITTLE biased 8-) )
Jim Murphy
sh...@pro-ict.cts.com writes:
>>It is definitely the best thing to happen to ProDOS since GS/OS. Now I am
>
>Just keep it away from my machine. I think it's a stupid idea.
>
>>hoping someone can help to increase the size of the name space... so I
>>can write Beauty & the Beast seq, or Out of This World.
>
>Sure, as soon as the entire file system is redesigned. Good grief, just
>use HFS already.
These are my thoughts exactly. Simply hacking ProDOS so that it seems
to support a character set that is different from its defined set is just
plain stupid. Lots of programs reasonably and rightly assume that ProDOS
file names contain a specific set of characters, and they cannot be
guaranteed to work correctly, given a set of characters they don't expect.
For example, what if a text editor author decided, "I like filetype
$C1 for storing my text files. I don't care if they're supposed to be
pictures, I wanna' use $C1 for text". So, you write a nice letter, and the
text editor happily saves it as filetype $C1. Later, you double-click on
the file, and your paint program runs - and then crashes. It was expecting
a picture, but it found nothing of the sort. This is exactly the same risk
you take when redefining the ProDOS filename charcter set that any
reasonable programmer can see cannot be redefined.
Of course, you can still do as you wish. I just think it's a stupid
hack with far too many problems that haven't been thought out.
Jim Murphy Dr. MacsBug mu...@apple.com
"...never quite said what I wanted to say to you, The Cure
never quite managed the words to explain to you..." Untitled
Frank M. Lin
It is a patch, you do not have to apply it.
> These are my thoughts exactly. Simply hacking ProDOS so that it seems
>to support a character set that is different from its defined set is just
>plain stupid. Lots of programs reasonably and rightly assume that ProDOS
>file names contain a specific set of characters, and they cannot be
>guaranteed to work correctly, given a set of characters they don't expect.
Stupid maybe, but it's an option that will make ProDOS more flexible.
> For example, what if a text editor author decided, "I like filetype
>$C1 for storing my text files. I don't care if they're supposed to be
>pictures, I wanna' use $C1 for text". So, you write a nice letter, and the
>text editor happily saves it as filetype $C1. Later, you double-click on
>the file, and your paint program runs - and then crashes. It was expecting
>a picture, but it found nothing of the sort. This is exactly the same risk
>you take when redefining the ProDOS filename charcter set that any
>reasonable programmer can see cannot be redefined.
I think it's a little different, the orignal valid characters are like
file type $C1, the new valid characters (, space... etc) are like aux
types. Or, more like original invalid characters are like file type
bad blocks, now you use file type bad blocks to store datas. Some
program will not like it...
Anyway, I think it's a cool option patch which you can apply if you like.
> Of course, you can still do as you wish. I just think it's a stupid
>hack with far too many problems that haven't been thought out.
Yeah...
Morgan Davis
>>Sure, as soon as the entire file system is redesigned. Good grief, just
>>use HFS already.
>
> These are my thoughts exactly. Simply hacking ProDOS so that it seems
>to support a character set that is different from its defined set is just
>plain stupid.
For the record, about a million years ago (it seems), I created just
such a patch for ProDOS *and* BASIC.System as part of the ProLine BBS
software we sell. The idea of relaxing the rules for ProDOS file names
is not a new one.
The program that patched ProDOS in memory was called UnixNames, and it
was written before the advent of GS/OS. It allowed ProLine systems to
offer naming schemes consistent with most Unix operating systems. And
since ProLine's Unix-like shell environment is central to the operation
of the whole system, it was pretty useful at the time. (We could have
files like ".login" for example, so the Unix interface was then fairly
consistent, which is important in any user interface).
Fortunately, the patch was written to seek out a particular signature of
instructions in the ProDOS memory space, so it was compatible with many
years worth of upgrades without any modification necessary. It may
still work.
Back when GS/OS was released with the ProDOS FST, ProLine owners who
relied on GS/OS based applications to do disk maintenance ran into
problems. Backups, filesystem checks, optimization, and so on, all met
with errors because of the use of these "unixnames". Operators had to
stay in the patched ProDOS-8 environment to do system maintenance like
this, and that was a major problem since the GS/OS tools were clearly
superior and more desirable to use. Plus, a number of ProDOS-8 programs
simply refused to allow you to access files that didn't have legal names
(AppleWorks for one, important disk utilities like ProSel for another).
It became apparent that having these names was more trouble than it was
worth.
Some time in the late 80's, I completely restructured ProLine to use
only legal, standard ProDOS file names, and have not missed UnixNames as
much as I thought I would. As a result, a lot of good has come of this.
For example, the "ls" command was taught how to work with invisible
files (that is, files with the invisibility bit set). Thus, we don't
have dot files (or "hidden" files) such as ".login" anymore. Instead we
have files like "login" with the invisibility bit set which show up only
with "ls -a".
Anyway, a bit of history. Much water has passed under the bridge since
then, and with it a little experience, insight, and wisdom has been gained.
/\/\ Morgan Davis Group (619/670-0563)
/ /__\ Internet: mda...@crash.cts.com
Phillip Vandry
> These are my thoughts exactly. Simply hacking ProDOS so that it seems
>to support a character set that is different from its defined set is just
>plain stupid. Lots of programs reasonably and rightly assume that ProDOS
>file names contain a specific set of characters, and they cannot be
>guaranteed to work correctly, given a set of characters they don't expect.
Those of us who have installed the patch were aware of the problems it might
cause. If some program crashes because of it, I won't blame the program. I
feel the benefits outweigh the disadvantages (none of which I have
encountered yet!)
The alternative to patching an existing file system is writing a new and
better one (better than ProDOS, better than HFS), something I would gladly
do if I knew how! But since I don't...
-Phil
Wulf Hofbauer
Victoria M Althoff <valt...@magnus.acs.ohio-state.edu> wrote:
>Actually the operating system of choice for the less-enlightened of the time
>was CP/M. So SOS looked like CP/M, complete with directory trees, but operated
>more like DOS 3.3 on the A][.
>
>Come on, IBM people, admit it: MS-DOS is really just a souped up version of
>CP/M, which was out of date by the time the first Apple ][ rolled off the line!
MS-DOS was developped by a small computer manufacturer (I believe it was
Seattle Computer Products) that had developed
an 8086 board (is was called QDOS which means Quick and Dirty OS). They
waited for CP/M 86 to appear, but it took them too long. So they wrote
a crude CP/M-like mini-OS to go along with that board. QDOS never
was a success, but when IBM was in negotiatons with both Digital Research
and Microsoft for an OS to go with the IBM PC, Microsoft bought the
rights on QDOS which was renamed and appeared as MS-DOS soon.
CP/M never had anything like a hierarchical file system (subdirectories).
So it has just about nothing in common with SOS. SOS rather has as far
as I can tell (I don't have an Apple III) some similarity to Unix (though
it's not a multitasking system). ProDOS is essentially a stripped-down
version of SOS.
CP/M is even more primitive than Apple DOS, but has a better machine
language interface. Newer CP/M's (like CP/M 86 or CP/M 68K or CP/M plus)
are only marginally better than CP/M 80 - they are remarkably primitive
and thus CP/M 86 never became a serious competitor for MS-DOS.
- Wulf
--
______________________________________________________
| |
| Wulf Hofbauer | zcaa...@rpool1.rus.uni-stuttgart.de |
| |
Matthias &
[...]
CP/M is even more primitive than Apple DOS, but has a better machine
language interface. [...]
No. Apple DOS 3.x consists of three modules, each with its own calling
interface and each built on top of the layer beneath it: The RWTS
(Read or Write a Track & Sector) containes the hardware drivers for
the (Disk II) disk drives, as its name implied. The File Manager
implements all the operations on files, managing the file system on
the drives and offers this functionality through a rich machine
language interface, which is superior to the one in CP/M (IMHO). The
third layer is the BASIC filing interface, also known as the Control-D
Interpreter, since it handles all the DOS commands on input or PRINTed
after an initial Ctrl-D and maps them onto appropriate File Manager
calls.
- Matthias Kapffer
Brian Tao
>
> Speaking of GS/OS ... what ever happened to HFS? Do you not use it
> because it's slower?
No, because if it screws up, you're SOL until you can find a Mac
that will read the partition map on your HD and have the right tools to
fix up the problem. My RamFAST hiccuped last week and wiped out a
nearly full 32-megabyte partition (contained all my recent downloads, as
well as lots of other data). Rather than restoring from a not-so-recent
backup, I just fired up Prosel-16 and recovered almost all the files.
--
Brian Tao:: ta...@io.org (Internex Online, 416-363-3783, 27 lines, v.32bis)
::::::::::: 90ta...@wave.scar.utoronto.ca (University of Toronto, 9T4)
Brian Tao
>
> The popular operating systems at that time were CP/M and the
> newly-hatched MS-DOS, both of which restricted things even further,
> limiting names to 8 and 9 characters respectively,
MS-DOS is still limited to 8+3...
> Rename MUMBLE.EXE, and MS-DOS won't be able to run it.
On the flip side, an absolute newbie with just a modem and a simple
terminal program with XModem or Kermit can download a self-extracting
version of PKZIP and go from there. We have to fiddle with Binary II,
or changing the file/auxtype (which isn't the most obvious thing a
newbie would do), or using Executioner format, or whatever.
Randy Shackelford
>In article <1994Jan3.1...@Informatik.TU-Muenchen.DE>, Soenke Behrens writes...
>>
>> Speaking of GS/OS ... what ever happened to HFS? Do you not use it
>> because it's slower?
>
> No, because if it screws up, you're SOL until you can find a Mac
>that will read the partition map on your HD and have the right tools to
>fix up the problem. My RamFAST hiccuped last week and wiped out a
Luckily I have one about two feet away from my IIgs so no problem. Right now
I have a 30 mb drive connected to the IIgs, formatted as a single ProDOS
volume. I also have a 105 external which I was hoping I could partition with
one 32 mb ProDOS volume and the rest as HFS and be able to use it with both
machines. I formatted and partitioned it on the Mac then erased the 32 mb
volume and turned it into ProDOS on the IIgs. But when I put it back on the
Mac no volumes appeared. So I repartitioned the 105 as one volume and it
works great with either machine. I was wanting to replace the 30 mb drive but
as it is I have to leave the 30 on the IIgs then chain the 105 to it to use
it. This is fine though but it sure would be neat to just have one drive for
both.
The point I'm making is I prefer using HFS to some hacked up version of the
ProDOS file system. There are some limits in ProDOS which will never go away,
such as the 32 mb volume and 16 mb file size limits and 15 character file
names. So it sure is swell to be able to use a more capable file system.
Wulf Hofbauer
Matthias & <kap...@Informatik.Mathematik.Uni-Mainz.DE> wrote:
>In article <2grk7i$1n...@info2.rus.uni-stuttgart.de> zcaa...@rpool2.rus.uni-stuttgart.de (Wulf Hofbauer) writes:
>
>[...]
>
>No. Apple DOS 3.x consists of three modules, each with its own calling
>interface and each built on top of the layer beneath it: The RWTS
>(Read or Write a Track & Sector) containes the hardware drivers for
>the (Disk II) disk drives, as its name implied. The File Manager
>implements all the operations on files, managing the file system on
>the drives and offers this functionality through a rich machine
>language interface, which is superior to the one in CP/M (IMHO). The
>third layer is the BASIC filing interface, also known as the Control-D
>Interpreter, since it handles all the DOS commands on input or PRINTed
>after an initial Ctrl-D and maps them onto appropriate File Manager
>calls.
Alas, the File Manager isn't documented at all in the DOS manual, so I
guess it's not legal to call it. Also, the FM is not cleanly seperated
from the command parser (ctrl-D interface) - it evaluates at least one
variable in the parser on an error.
To read the directory, you have to make low-level RWTS calls or use the
FM catalog routine, redirecting its output to your own routine. The first
is cumbersome if done correctly, and the latter is a clumsy approach.
It is possible to use the ctrl-D interface from machine language programs,
but in this case you'll have to fake several zero page variables and patch
the error handler vectors of DOS (which are - to my knowledge - not documented
by Apple). Not quite clean, either.
I know, most of what I call "undocumented" is documented. I'm reluctant to
use routines not officially documented by Apple, however. I've seen to much
Apple ][ and ][+ programs not running on other machines because they use
routines internal to the monitor, for example.
Also, DOS is what it says - a disk operating system, but not a real operating
system. For example, character oriented I/O is not part of DOS, so application
programs have to call monitor routines directly or even implement their own
drivers which cause many compatibility problems on different machines. SOS
offered character device support, but ProDOS doesn't either (this is the point
I like least about ProDOS).
Admittedly, CP/M file operations are primitive, but they are officially
documented and usable. Look at the application programs running under CP/M.
Most serious applications I've seen for DOS blindly patch DOS in memory, often
requiring to reboot the machine on termination.
Having written this, I must say that I don't like CP/M at all ;-). But DOS
was conceived as a BASIC extension to access the disk drives and was always
tied to Applesoft or Integer Basic which made it very difficult to write
non-Basic programs. ProDOS is much better (though there are still some
irregularities that don't make sense to me, like not returning the EOF on a
get_file_info call). ProDOS is still the best 8-bit DOS I've had the
opportunity to work with: it is structured cleanly, and offers quite orthogonal
fundamental operations. I never had to think about calling the device drivers,
for example - you don't need to bypass the file system.
Brian Tao
>
> The point I'm making is I prefer using HFS to some hacked up version of
> the ProDOS file system.
So would I, but 99% of us don't have easy and convenient access to a
Macintosh with the right tools to fix HFS problems. Maybe I should pick
up a cheap Mac Plus with Norton/Symantec and pull it out of the closet
only when I need it... ;-)
Chris Deschu
Gee, that sounds familiar :) That's almost exactly what I'm doing, except
I keep the drives on the pus, and access them over personal file sharing.
That way, the mac can keep the drives optimized in the background with
DiskExpress II. Other than that, it makes a nice calculator... One word
of advice though, if you are going to do this, don't use a mac pus, it
makes a lousy file server, and can't handle a 1:1 interleave. Get an
se, or preferably and se/30.
--
______________________________________________________________________________
|___ Chris Deschu cde...@nyx.cs.du.edu
_|_|con (215) 791-3596 4804 Bowood Street, Center Valley, PA. 18034-9628
:-)|echnologies is IT in the Lehigh Valley for Apple ][ Consulting and Repairs
Tom Larson
with the limited naming conventions of ProDOS with non-HFS volumes.
It's not as if I have some vendetta against people using HFS, it's
just that it's stupid to limit your choices if you don't have to.
Any program that lets the operating system judge the validity of
the filename (as any well written program should, to support all
of the foreign filesystems) will work fine. In addition, most
programs that don't are trivial to patch.
>I keep the drives on the pus, and access them over personal
>file sharing.
An interesting, but very slow way to do things.
Internet: tla...@pro-greens.benton-city.wa.us
David E A Wilson
>The whole point of using the patch is so you don't have to suffer
>with the limited naming conventions of ProDOS with non-HFS volumes.
If you are like me running a //e with no Appletalk card HFS is not an option.
I agree that anyone who exports files with nonstandard names (in an archive)
is not doing anyone a favour.