TMPLee@DOCKMASTER.NCSC.MIL (05/11/89)
Thanks to whoever answered my question. (Its several messages ago so I've forgotten.) Just to make sure, I interpret that to mean that none of the ProSel utilities will work on GS/OS 5.0 -- I sure hope Glen Bredon is one of those getting a Beta test version. Or that Apple will come out with as useful a set of utilities. (I haven't even seen a GS/OS technical reference yet, much less studied it -- I didn't know it was generally available.) TMPLee@Dockmaster.ncsc.mil
mattd@Apple.COM (Matt Deatherage) (05/12/89)
In article <890511155647.191181@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes: >Thanks to whoever answered my question. (Its several messages ago so >I've forgotten.) Just to make sure, I interpret that to mean that none >of the ProSel utilities will work on GS/OS 5.0 -- I sure hope Glen >Bredon is one of those getting a Beta test version. Or that Apple will >come out with as useful a set of utilities. (I haven't even seen a >GS/OS technical reference yet, much less studied it -- I didn't know it >was generally available.) > >TMPLee@Dockmaster.ncsc.mil I didn't say that at all, or much of anything like it. ProDOS 8 will not deal with extended files. Extended files are only present on ProDOS disks through the ProDOS FST in GS/OS. They may be present under any version of GS/OS, since the first one had them as well. Any utility running under ProDOS 8 will not be able to operate normally with extended files. Any utility running under GS/OS can deal normally with extended files, but many of them don't. It is all up to the application author. It has nothing to do with "GS/OS 5.0", which doesn't really exist (the version of GS/OS on Apple IIgs System Software 5.0 is GS/OS version 2.1). It has to do with ProDOS 8 vs. GS/OS, and how the applications were written. ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that AppleLink PE: Matt DTS GEnie: AIIDTS | Apple Computer, Inc., or any of its CompuServe: 76703,3030 | subsidiaries, in whole or in part, Usenet: mattd@apple.com | have any opinion on any subject." UUCP: (other stuff)!ames!apple!mattd | "So there." -----------------------------------------------------------------------------
farrier@Apple.COM (Cary Farrier) (05/12/89)
In article <890511155647.191181@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.NCSC.MIL writes: >[...] (I haven't even seen a >GS/OS technical reference yet, much less studied it -- I didn't know it >was generally available.) There is a two volume GS/OS Reference set published probably by Addison/Wesley, but I am not sure. Contact your local Apple dealer to find out the specifics. Cary Farrier
lwv@n8emr.UUCP (Larry W. Virden) (05/12/89)
Actually, there have been updates to prodos 8 cat.doctor so that this prodos 8 program CAN handle extended files from Prodos 8. No, I dont know what he did. There have been other such updates being made over the last few months. Obviously someone running prodos 8 has the potential of running into these files - what happens when you download a .bny/.shk and find that it contains one of the buggers? Note - if you are the author of any prodos disk manipulation type program such as listing files, catalogs, shrinking files, etc you should be prepared to adequately handle said files. I tried to copy a disk recently which contained one of these forked files. I was using System Disk 4.0 and its copy mechanism - it said "no way!"... -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 n8emr!lwv@cis.ohio-state.edu (Internet) 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) The world's not inherited from our parents, but borrowed from our children.
stevef@pro-nucleus.UUCP ("Steven J. Freitas") (05/16/89)
Network Comment: to #514 by pnet01!crash!apple.com!mattd Well, something I'd like to know is whether P8 will be patched so that it could access more than 32 meg per volume? It seems that this aspect of upgrade has been forgotten in the midst of the recent developments. UUCP: crash!pnet01!pro-sol!pro-nucleus!stevef ARPA: crash!pnet01!pro-sol!pro-nucleus!stevef@nosc.mil INET: stevef@pro-nucleus.cts.com ProLine: stevef@pro-nucleus ALPE: SteveAdept
farrier@Apple.COM (Cary Farrier) (05/18/89)
In article <8905161922.AA00955@crash.cts.com> pnet01!pro-sol!pro-nucleus!stevef@nosc.mil writes: >Network Comment: to #514 by pnet01!crash!apple.com!mattd > >Well, something I'd like to know is whether P8 will be patched so that it >could access more than 32 meg per volume? It seems that this aspect of upgrade >has been forgotten in the midst of the recent developments. It hasn't been forgotten, because the 32Mb limitation is a limitation imposed by the file structure ProDOS uses. The limitation is because the ProDOS filing system uses a word to identify block numbers, and 65535 blocks = 32Mb. If this were to be changed, then the new volumes would not be readable by older versions. Cary Farrier
jazzman@claris.com (Sydney R. Polk) (05/19/89)
From article <8905161922.AA00955@crash.cts.com>, by stevef@pro-nucleus.UUCP ("Steven J. Freitas"):
> Network Comment: to #514 by pnet01!crash!apple.com!mattd
>
> Well, something I'd like to know is whether P8 will be patched so that it
> could access more than 32 meg per volume? It seems that this aspect of upgrade
> has been forgotten in the midst of the recent developments.
>
> UUCP: crash!pnet01!pro-sol!pro-nucleus!stevef
> ARPA: crash!pnet01!pro-sol!pro-nucleus!stevef@nosc.mil
> INET: stevef@pro-nucleus.cts.com ProLine: stevef@pro-nucleus
> ALPE: SteveAdept
It is impossible with ProDOS to acces more than 32 meg of space on a
volume because addressed in ProDOS can only address that much. Period.
GSOS doesn't have this limitation because it has more bits allocated
for disk blocks internally.
32 Meg in 512 K blocks requires 7 bits, which means that the block
address can be stored in one byte. The other bit is used for something
like marking a block as used or some nonesuch. ProDOS 8 uses only one
byte for addresses, so it cannot access more than 32 meg. This is so
ingrained into the OS that a patch is basically impossible.
GS/OS uses more than one byte for block addresses, so doesn't have the 32
Meg limitation.
--
Syd Polk | Wherever you go, there you are.
jazzman@claris.com | Let the music be your light.
GO 'STROS! | These opinions are mine. Any resemblence to other
GO RICE! | opinions, real or fictitious, is purely coincidence.dlyons@Apple.COM (David Lyons) (05/19/89)
In article <10173@claris.com> jazzman@claris.com (Sydney R. Polk) writes: [...] >It is impossible with ProDOS to acces more than 32 meg of space on a >volume because addressed in ProDOS can only address that much. Period. > >GSOS doesn't have this limitation because it has more bits allocated >for disk blocks internally. Not exactly. GS/OS doesn't have a 32 Meg limitation because it supports file systems other than the ProDOS file system. The ProDOS file system is still limited to 32M, even under GS/OS. To use a volume larger than 32M, you need an FST (File System Translator) other than the ProDOS FST (PRO.FST in the *:System:FSTs folder). The only FSTs available under System Disk 5.0 are for character devices (not relavent here), ProDOS, High Sierra (for CD-ROM drives), and AppleShare. The High Sierra FST supports reading only--you can't write to a CD these days. So the AppleShare FST is the only one that currently lets you have read/write access to volumes larger than 32M, and you need an AppleShare server running on an AppleTalk network to use it. >32 Meg in 512 K blocks requires 7 bits, which means that the block >address can be stored in one byte. The other bit is used for something >like marking a block as used or some nonesuch. ProDOS 8 uses only one >byte for addresses, so it cannot access more than 32 meg. This is so >ingrained into the OS that a patch is basically impossible. (#define blunt TRUE) This makes almost no sense. (#undef blunt) The 32M limit is built into the format of the information on a ProDOS disk. The most important limit is that 2 bytes (16 bits) are used for block numbers, and blocks are 512 bytes. 65536 * 512 bytes = 32M. The bitmap consists of 1 bit for each block, which is 1 block for every 2M on the disk. >GS/OS uses more than one byte for block addresses, so doesn't have the 32 >Meg limitation. GS/OS allows 4 bytes (32 bits) for block numbers, and blocks can be pretty big, too. Again, there may be smaller limits imposed by particular device drivers and File System Translators. >Syd Polk | Wherever you go, there you are. >jazzman@claris.com | Let the music be your light. >GO 'STROS! | These opinions are mine. Any resemblence to other >GO RICE! | opinions, real or fictitious, is purely coincidence. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
samt@pro-europa.cts.com (Sam Theis) (05/21/89)
Network Comment: to #2540 by pnet01!crash!trout.nosc.mil!pnet01!pro-nucleus!stevef Don't expect either P8 nor the GS/OS ProDOS FST to be changed to access more than 32Meg volumes. Sam
prw@meccts.MECC.MN.ORG (Paul Wenker) (05/23/89)
In article <8905211958.AA07179@crash.cts.com> pnet01!pro-nsfmat!pro-europa!samt@nosc.mil writes: >Network Comment: to #2540 by pnet01!crash!trout.nosc.mil!pnet01!pro-nucleus!stevef > >Don't expect either P8 nor the GS/OS ProDOS FST to be changed to access more >than 32Meg volumes. > >Sam I don't know about the ProDOS FST, but the AppleShare FST works just fine with our 320 meg server volume. It shows 159450K used and 157710K available. -Paul Wenker UUCP: prw@mecc.mn.org -MECC, Advanced Development