💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › Languages.Programming › GSOS.… captured on 2023-01-29 at 04:47:51.
-=-=-=-=-=-=-
Subj: GS/OS long pathname handling 88-10-16 15:31:42 EST
From: Dave Lyons Msgs: 41 (89-03-15)
Under GS/OS, class 1 pathnames have a two-byte length count, and prefixes can be as
long as 8000 characters! The old days of fixed-length pathname buffers and allowing
64 characters on the screen for displaying a prefix were a lot simpler.
I want to come up with a good collection of C routines to make life easier. Without
one, people (including me) are likely to skimp out and take shortcuts, like limiting
pathnames to, say, 256 characters. Eventually I'd be sorry if I did that. (Somebody
would turn up who WANTED an 8K prefix for some unimaginable reason.)
So here's a rough idea of what I have in mind:
The basic object type being manipulated is a Path. This is an abstract data type
(ADT) that should be accessed only through the routines in this package. Internally
it will be a handle to a variable-sized block, the most interesting part of which
would be space for a GS/OS pathname. The handles would be locked only when
necessary, and there would be a LockCount to keep track of how many pointers to the
path are being used--the handle is unlocked when the LockCount gets back down to
zero.
Path NewPath(unsigned length)
creates a new Path with the specified length; returns NIL if
there's trouble (and _toolErr specifies the error)
void DisposePath(Path p)
void SetPathLen(Path p,unsigned newLength)
unsigned GetPathLen(Path p)
char *PathAddr(Path p)
returns a pointer to the pathname; call UnlockPath when the
pointer will not be used any more
char *ResultPathAddr(Path p)
returns a pointer to the path buffer's size count; use this
when a GS/OS call will return a pathname; call UnlockPath when
the pointer will not be used any more
void UnlockPath(Path p)
(internally, decreases LockCount for the path and unlocks its
handle if the count is zero)
void AppendPathText(Path p,char *text,unsigned length)
appends the specified text onto a path
void AppendPathC(Path p,char *c_string)
void AppendPathP(Path p,char *pascal_string)
[What about Prepend versions of the above? Useful? (I know, "prepend" isn't a
word.)]
[There should probably be 6 conversion routines to go from any of a Path or C-string
or P-string to any other.]
void TruncatePath(Path p,unsigned length,unsigned Where)
Truncates a path to a max length specified, putting "..." in
place of the truncated text; Where specified whether the
truncation happens at the LEFT, MIDDLE, or RIGHT of the
path. Yes, truncating in the middle is actually a useful
thing to do...lets you see what volume and what specific
file or directory you're working with.
That's enough for now--your additions (and maybe simplifications?) are requested!
--Dave Lyo
Subj: Hello?? 88-10-18 02:15:47 EST
From: Dave Lyons
Gee, the enthusiasm is underwhelming.
Should I interpret this as apathy or complete approval of my rough specs?
Will anybody besides me *use* this package if I impelement it and put it in the p.d.?
Subj: Re: GS/OS long pathname handling 88-10-18 20:02:24 EST
From: HyperDyne
I'm personally not too concerned about long pathnames, as, in the case of the 8K
prefix, it would, assuming 32 character long filenames on some HFS device, still take
OVER 200 folders deep worth of clicking before such a prefix could exist. And a user
typing in a pathname even over 100 characters long in any environment seems unlikely
to say the least. In that respect, perhaps Apple has here a solution looking for a
problem, since it seems unlikely that you would ever ever everfind a user insane
enough to try to use a pathname or prefix that is over 255 characters (16 folders or
MORE deep on a ProDOS volume!).
As for CD-roms and VERY LARGE VOLUMES, the use of folders starts to break down simply
because long (and deeply nested) folders are even more unwieldy then those old
fashioned CP/M 'flat' directories. I think resources and other 'hidden' data that
the user can manage but normally would ignore by working with a single file is the
real solution here, as there is no clutter, and everything can be moved at once in a
single (user appearent) file operation to a new folder.
--Dave
Subj: Re: GS/OS long pathname handling 88-10-18 20:10:00 EST
From: AFL Floyd
Dave,
I *would* use such routines. I agree that the only way to deal with these long
pathnames is to insert an "..." and create a shorter pathname when displaying it.
This was how I planned to handle it. After all, you would need a word processor to
view an 8000 byte pathname!
Your going to probably have plenty of time to do it, because I don't think we'll be
seeing pathnames of this length for a long time.
As far as your algorithm for "fitting" a pathname into a set length, I would use the
last directory and file name on one end, and the volume name, and as many directories
from that point that would fit into the desired length minus the "..." in the front.
Pretty simple actually.
Floyd
Subj: Re: GS/OS long pathname handling 88-10-19 19:27:10 EST
From: HyperDyne
Floyd: My appoligies, I was not objecting to the idea of the routines themselves, or
the way they would display pathnames too long to fit on the screen. The only point I
was really trying to make is that perhaps such routines were 'overkill', just as up
to 8K prefix's are overkill, since no sane human would ever (except possibly very
deliberatly, and even then, with a lot of patience) come close to pushing a pathname
that long, or even longer than 255 characters, in any ordinary situation.
Where pathnames can easily grow too long to be shown directly (I've thought of some
situations where verticle stacking for each subdir name with indention would also
look good), I do agree a simple standard way to handle this would be very useful, and
like the '...' (shades of VMS?).
Dave
Subj: Re: GS/OS long pathname handling 88-10-19 19:50:33 EST
From: Dave Lyons
Dave S--Human fingers aren't the only things that generate pathnames. Consider a
'copy' command under GS/OS trying to copy a subdirectory structure--the internal
operations on pathnames need to be able to handle the longest pathname of any file in
the structure being copied.
Certainly 8K pathnames is a bit excessive. But what about 1K? 512 characters? 256?
128? I wouldn't feel too safe with a 200-character limit. I actually can't come up
with any length that seems "safe" that I want to use for lots of statically-allocated
pathname buffers.
--Dave L
Subj: Re: GS/OS long pathname handling 88-10-20 10:42:07 EST
From: AFL Floyd
Dave S,
No need to apoligize, my message was in response to Dave L's message. :)
You guys should get a name like 'Floyd', I don't have any problems with people
confusing me with someone else. :)
Floyd
Subj: Re: GS/OS long pathname handling 88-10-20 20:51:45 EST
From: AFA Parik
nah, get a name like Parik, I have yet to have my name
confused...:-)
Subj: Re: GS/OS long pathname handling 88-10-20 22:06:01 EST
From: Matt DTS
Yeah, Parik, except maybe confused with a dish made of pumpkin and yogurt...
--Matt
(oh yeah - :-)
Subj: Re: GS/OS long pathname handling 88-10-21 10:21:32 EST
From: MikeW50
I have to agree that at least certain kinds of software should handle path names all
the way out to their full length. I was a bit hesitant until it was pointed out that
optical disks may have very long path names to structure all of their data.
In any case, handling long path names with a subroutine library is only one way to do
it. There are several others. Here's the ones I've thought about, along with some
of the major pros and cons:
1. A subroutine library.
I don't know what to do with htis one. It seems like swatting flies with a hammer.
Maybe some comments on what routines mught actually be in the library would help.
2. As a general method, on any call that returns a path, you can point the output
string at a four byte area that looks like this:
dc i'4,0'
After making the call, you expect a $4F (buffer too small) error, but GS/OS returns
the size of the buffer needed as the 2nd word. You then call your favorite memory
manager to allocate a buffer, and make the call again.
OK, it's messy, and it also involves two calls every time. It does, however, work
without wasting space. As a modification:
3. Call your favorite memory manager to get a default sized buffer, then make the
call. If the call fails, dispose of the first buffer, allocate another of the proper
size, and make the call again.
This method is faster than the first if the buffer is chosen to be 128, 256 or
whaterver - large enough so it is rare that the second call will be made. It takes
more code space, though, and you are likely to waste space on the original buffer.
To summ it up, this method is faster than the first, but takes more memory,
both code and data.
Any comments?
Oh, of course in assembly language, the dirty work would definitely be in a macro.
Reguardless of which of the above methods is used, the programmer would still only
have to type a single macro to do a GS/OS call.
Mike Westerfield
Subj: Re: GS/OS long pathname handling 88-10-21 20:03:56 EST
From: Dave Lyons
Mike, an outline of my idea of the functions in a subroutine library for pathname
handling was in msg #1. Yesterday I implemented a first draft of the thing, based
fairly closely on that. The general method of repeating a call with a bigger buffer
still applies. I think it's going to be worth it to *not* deal with handles and
things directly, but to let the library do it. (I'll let you know as soon as I
integrate the thing into the infant Davex 16!)
One thing I'm planning to add to my current package is StartTempPaths and
DisposeTempPaths--this would provide a way for the main level of a program to
automatically get rid of path buffers allocated by subroutines, freeing the
subroutines from deallocating them explicitly when they exit abnormally due to GS/OS
errors. (Davex 16 would call DisposeTempPaths before processing a new command and
StartTempPaths before calling a command-handling routine.)
Subj: Re: GS/OS long pathname handling 88-10-21 21:02:34 EST
From: TMH2
Implement it! A subroutine library is a suitable method until the systemSW weenies
at You-Know-Where decide that run-time libraries would be useful.
T. Mike Howeth
(You-Know-Where is a trademark of You-Know-Who).
Subj: Re: GS/OS long pathname handling 88-10-23 12:33:11 EST
From: JSchober
hehehe... Floyd's got it even worse than just Floyd... it's Floyd Zink... now THAT'S
a name no one will forget!! ;)))
Ditto "Parik Rao". :)
On the more serious side of things, I think displaying LONG pathnames in the form
".../most-nested-dir/myfile" would be pretty nice. Dave S' idea of display staggered
pathnames downwards is nice, but takes up a lot of space (screen-wise).
Subj: Re: GS/OS long pathname handling 88-10-23 19:17:36 EST
From: HyperDyne
RE: Joe;
Yes, it does. The program I used that in was a 'whereis'/'filefind' utility for
CMD/16 which goes through all subdir's to find a file you only remember the name of.
I chose to do that because I thought it would be best to show the entire path, as the
user is already uncertain as to where that file is.
--Dave
Subj: Re: GS/OS long pathname handling 88-10-24 14:28:20 EST
From: MikeW50
Run-Time Libraries:
Who needs them? That's what tools are, after all. The main problem with run time
libraries is the hastle of dealing with a version of the library that doesn't match
the version of the program. To solve that, you need to institute some form of
version number and set up the library so the entry point to a given subroutine does't
change when the versin of the library changes. Gee, that sounds like a tool handler
to vector the call to the proper spot and a version call in each library... Gee,
that sounds like a tool... Gee, whay not just use tools & user tools? Gee, I think
we already _HAVE_ run time libraries!
Clean Up - I like the idea of a single clean up call for disposing of temp path
names. I agree about not wanting to mess around with the memory manager and handles
directly, which is why we have a memory management unit we use in programs that need
lots of small, fixed location pieces of memory. If we didn't have the memory
management unit, I think a subroutine library would be essetial for dealing with
GS/OS strings. As it is, we can deal with it using macros. (I think - we'll see!)
Mike Westerfield
Subj: RTLs + status report 88-10-24 19:57:12 EST
From: Dave Lyons
Well, one limitation run-time libraries don't have that user tools do is that user
tools belong completely to the current application. CDAs/etc can't use user
toolsets--if they try they will eventually break, I betcha (consider what would
happen under a MultiFinder type of environment, where the system would switch between
different sets of user tools when different application windows came to the front).
Anyway--the first draft of my longpath routines is working okay (in C). Need to test
out a few remaining routines and add the temporary path business. Will post specs +
code in a couple of days.
Subj: Re: RTLs 88-10-24 22:18:09 EST
From: TMH2
RTLs also do not have quite as big a problem in the 'unique-ness' arena as user
tools, either. Numbering conflicts (with user tools) are much more likely than are
naming conflicts between RTLs.
Z^\GGGGGGGGGGGGGGGGGGG\_
Z R
Z T. Mike Howeth II N
Z Dallas, Texas N
Z (TMH2) V
Z B Q
ZO WVWVWVWVWVWVWVWVP_
Subj: user tool numbering 88-10-24 23:35:01 EST
From: Dave Lyons
True, although an application always has control over what toolset numbers it chooses
to use; assuming people are bright enough to write their toolsets so that they work
as *any* toolset number, it's not a big problem.
(Writing a tsnum-independent toolset isn't too hard--just a matter of keeping the
function code on entry and manipulating it into an error code number when necessary,
and extracting the toolset number from the function number if you want to feed it to
SetWAP or GetWAP. The function number is guaranteed to be in the X register when one
of your toolset's functions gets control.)
--Dave Lyons
Subj: Re: GS/OS long pathname handling 88-10-25 11:17:30 EST
From: MikeW50
Mike, that's the classiest signature block I've ever seen. Are you using a macro
processor to write it?
Mike Westerfield
Subj: Re: GS/OS long pathname handling 88-10-25 17:27:37 EST
From: JSchober
Dave... Re: stacking directory paths downwards. Aha! For a FINDFILE utility. Yes,
then since you'd be using the screen for almost nothing else, I DO like the idea of
staggering your path down the screen. Go for it!! :)
Mike... Great job with that signature! Really looked nifty. :)
--Joe
Subj: prefix 0 can't be long 88-10-25 23:52:10 EST
From: Dave Lyons
Since prefix #0 is still limited to 64 characters under GS/OS (right?), it doesn't
work too well as a "current directory" in a GS/OS command shell.
This is a problem that it I want to deal with in Davex 16, and it seems to me that
eventually Standard File needs to deal with it, as well as other GS/OS command
shells.
One idea would be to use a nonzero prefix as the "current directory". For example,
Davex 16 could use prefix #8 as your current directory, and it could automatically
add "8/" [or "8:"] to the beginning of any partial pathname. (And prefix 8 would be
printed for a prompt.)
This will work nicely for commands internal to the shell, and for commands written
specifically for Davex 16. But other commands (EXE files) written for APW or
whatever won't know about that convention, and they'll expect prefix 0 to be what the
user considers the "current directory". Further, Davex 16 has no way to determine
which command-line arguments correspond to pathnames for generic disk-based commands;
if it *did* then it could simply put 8/ onto the beginning of the appropriate
arguments.
8000 characters may be a little much even for a prefix on a CD ROM, but 64 is not
enough!
Davex could keep prefix 0 set to the same value as prefix 8 whenever possible; should
it simply refuse to run generic EXE files when prefix 8 is longer than 64 characters?
(Same for S16 files?)
Your insights will be appreciated. (Your confirmations that my above description of
the mess is correct will also be appreciated, but to a slightly smaller degree. :)
--Dave
Subj: Re: GS/OS long pathname handling 88-10-27 10:00:17 EST
From: MikeW50
Profix 0 is not limited in length to 64 characters by GS/OS (as far as I know), but
none of the command shells have been updated for full support to GS/OS. Once this is
done, you should be able to have a prefix 0 up to the 8K limit currently imposed by
the ProDOS FST.
Mike Westerfield
Subj: prefix 0 length? 88-10-27 21:08:35 EST
From: Dave Lyons
Oh! Well, that changes things a lot, doesn't it? I betcha I'm still using the
class-0 call to set the prefix, and I shouldn't be. Now, what happens when a class-0
Get_Prefix tries to get a prefix longer than 64 characters?
Subj: Re: GS/OS long pathname handling 88-10-27 22:33:16 EST
From: Matt DTS
Nope. To my knowledge, the old prefixes (0 through 7 and maybe *) are limited to 64
characters in length, even with class 1 calls.
(They really have to be, because all the class 0 calls expect a p-string [length
byte] in return, and GS/OS won't do "editing" on the prefix for you if it's longer
than 255 characters. Therefore, that old P16 limitation is still there.)
--Matt
Subj: Re: GS/OS long pathname handling 88-11-01 17:22:59 EST
From: MikeW50
I haven't tried it, but the GS/OS docs list class 1 calls for both Get_Prefix and
Set_Prefix. I assume that means you can use paths longer than 64 characters. If
not, long path names on GS/OS are singularly useless, since the user would have to
type any portion of a path name that is longer than 64 characters anytime the file is
accessed.
Mike Westerfield
Subj: Re: GS/OS long pathname handling 88-11-02 00:44:05 EST
From: Dave Lyons
Mike, prefixes 0-7 are limited to 64 chars, but that *doesn't* mean that the user
will always have to type all but the first 64 characters of a pathname--the
application can provide a working-directory concept without simply using prefix 0 to
impelement it.
Of course, this raises interesting problems for something like a command shell which
has to be able to run generic EXE files that expect prefix 0 to be what the user sees
as the working directory.
There are at least two possible solutions to this mess (each requiring changes to
GS/OS) that are getting tossed around right now, and I hope to see one of them
impelemented on the next system disk.
--Dave L
Subj: Re: GS/OS long pathname handling 88-11-03 17:01:15 EST
From: MikeW50
Dave is right. I talked with some of the folks at Apple. The problems they are
trying to avoid by restricting the first 8 prefixes to 64 characters are real, but
certainly cause many other problems as well. They can be solved, and I am reasonably
confident that this problem will not effect the user by the next release of ORCA.
Mike Westerfield
Subj: first beta release in library 88-11-22 21:49:15 EST
From: Dave Lyons
I've uploaded the first beta release, including source code, into the ADV library
under Source Code. (Haven't checked to see if it's been released yet.)
Let me know what you think of it.
Subj: It's released 88-11-23 16:55:10 EST
From: AFL Jim
'nuf said.
Subj: Disable directory cacheing 88-11-24 10:17:26 EST
From: AFL Floyd
I don't think it is possible to disable the directory cacheing feature. If you don't
want to use the benefits of GS/OS, you might want to go back to using P16. :)
Floyd
Subj: second beta release 89-02-16 21:52:02 EST
From: Dave Lyons
If anybody hasn't noticed it, the second beta release of my LongPath package (with C
source) is available in the Souce Code section of the library.
Subj: Re: BlockMove vs. memcpy 89-03-06 23:46:07 EST
From: Coach101
I noticed that you use BlockMove instead of the "C" function
memcpy. Personal preference or is BlockMove faster/better etc.?
Subj: BlockMove and memcpy() 89-03-07 21:46:09 EST
From: Dave Lyons
I really don't know which one is faster. I used BlockMove only because I knew the
parameters without looking them up.
Subj: BlockMove 89-03-09 12:59:44 EST
From: MikeW50
I don't know about memcpy, but block move is not particularly fast.
Mike Westerfield
Subj: BlockMove efficiency 89-03-09 19:45:01 EST
From: Dave Lyons
Last time I checked, BlockMove did the actual work using MVN or MVP, so it ought to
be reasonably fast. There is a considerable amount of overhead, though, so it may
not be a good choice for copying _small_ amounts of data.
Subj: Re:Some Comments 89-03-12 13:12:33 EST
From: Coach101
I have converted to using the _longpath_ package and have
a couple of questions and comments.
1) In _PathSeparator_ the _for_ loop that controls
the searching of the characters in the path name
is coded with an end test of "i<=len". I think
that this should be "i<len" since "i" is
zero-based and "len" is one-based.
2) In a number of places references are made to
elements of the path structure when the structure
is not necessarily locked down. By way of
example, in GetPathSize the expression
"(*p)->pathsize-4" is used on a path that is not
necesarily locked. I am not sure what conditions
can cause memory to be re-arranged, but if memory
were to be re-arranged between the instructions that
generate the pointer to the path and the
instructions that reference the pointer, then an
incorrect value could be returned. I suspect
that this is safe at the present time since I
think memory cannot be re-arranged during an
interrupt (which is, I think, the only thing that
could interrupt the flow of instructions) but
will this always be true in the future (what will
the rules be if a "multi-finder" comes along,
etc.).
3) In _UnlockPath_ the path lock count is
unconditionally decremented. If _UnlockPath_ is
called with the lock count already at zero (a
program error for sure) then the package would in
the future perform all sorts of operations on an
unlocked path thinking it was locked. How about
proctecting the programmer a little by not
decrementing lock count if it is already zero.
4) SysFailMgr is a rather strong response to an
error in a program. Some method of reporting
errors back to the caller would be nicer in the
program development/debug cycle. I would prefer
to post some error message from within my code
saying what error occurred and what my code was
trying to do when it got the error than ending up
with a reboot (which I think is what SysFailMgr
gets me).
Subj: good suggestions 89-03-12 23:13:26 EST
From: Dave Lyons
Thanks for the comments, Coach.
I'll have to look at the code to check out the PathSep loop. If it's wrong, I'll fix
it.
The references like (*p)->pathsize are okay even if p is not locked. It is
guaranteed for all time that memory will not be compacted or purged during an
interrupt. If there is ever a MultiFinder, presumably it will work like it does on
the Mac and steal control during GetNextEvent calls.
I think I'll take your suggestion for UnlockPath and have it do no harm if it's
called too many times.
I agree that causing a system death is a bit drastic, but I don't see an alternative
that I'm convinced is better. Returning an error to the caller is the most obvious
thing to do, but typically the caller may _not_ check for the error code! The fatal
errors are in response to passing fried Paths to the routines; in cases like
out-of-memory, errors are returned to the caller in _toolErr.
One thing that could be done easily is to add something like
InstallPathError(procPtr) to let the calling routine specify a procedure for the
LongPath package to call if it wanted to report more information on an error. That
would be okay if the program still wanted the error to be fairly fatal...it wouldn't
leave an easy way out for the main program in general.
Subj: Block Move 89-03-13 15:36:41 EST
From: MikeW50
Dave, either we looked at different versions of the memory manager (quite possible),
or one of us was napping (also quite possible, at least in my case). I remember
block move using a loop to move the bytes. The loop moved one byte at a time, and I
think it incremented pointers to find the various bytes. Using mvn would be tough,
since block move supports moves across bank boundaries. Still, it could be done.
Mike Westerfield
Subj: BlockMove 89-03-14 03:26:39 EST
From: Dave Lyons
Well, I have Memory Manager v2.2, (ROM 01 + System Disk 4.0, but the Block Move code
being used is in ROM). I just popped into Nifty List, typed
"BlockMove
#L
and got as far as the E116A4 vector that it calls to do the actual work. At that
point it does some stuff that I haven't bothered figuring out, and eventually builds
either MVN $wxyz RTL or MVP $wxyz RTL on the stack, & calls them. Presumably this
happens more than once for a BlockMove that crosses a bank boundary. Maybe I'll
trace through it and see after I'm logged off.
[Some people complain that there isn't enough entertainment software for the
GS...they're wrong! All you _really_ need to be entertained is a machine-level
debugger, hundreds of K of system software to step through, and a lack of anything
resembling sanity. :-) That reminds me...will have to step through some SANE
routines sometime. I guess I'm just easily entertained.]
Subj: how BlockMove works 89-03-15 04:41:56 EST
From: Dave Lyons
Well, I tried it, and it worked as expected. I did a BlockMove from $06FF00 to
$06FF80, length = $018000, and it did the following MVP calls: $0808, 0708, 0707,
0707, 0607, 0606. It built and called them one at a time, in that order.
Subj: Napping or Versions? 89-03-15 14:57:15 EST
From: MikeW50
Well, I'm glad to see it doing the move that way, whether it is a recent change or
not. If I ever get energetic, I may have to do some benchmarks comparing the memory
manager calls to the subroutine I use for block moves.
By the way, Dave, if you want to stay sane, keep away from SANE. ;)
Mike Westerfield
Subj: Object Module Format 88-06-19 00:12:41 EST
From: AFA Gary J Msgs: 4 (88-06-19)
Can anyone tell me if PIF (permanant initialization files) and TIF (temporary
initialization files) should be created in Object Module Format like regular ProDOS
16 applications? (I assume so, but need to be sure!)
Subj: Re: Object Module Format 88-06-19 10:30:12 EST
From: AFL Jim
According to The Programmer's Introduction to the Apple IIGS (Addison-Wesley
Publishing, page 266), Temporary Initialization Files (TIF, type $B7) and Permanent
Initialization Files (PIF, type $B6) are loaded and executed just like IIGS
applications except they must end with an RTL instead of a ProDOS QUIT call. TIF
files are removed from memory after they're run. PIF files are not removed from
memory, they must not be in special memory and they can't permanently allocate any
direct bank/stack space. Both types of files are run automatically at system startup
before any other applications if they're in the SYSTEM.SETUP subdirectory. I guess
that means they should be written, compiled and linked just like applications.
Subj: Permanent init files 88-06-19 20:26:51 EST
From: Mensch72
PIF's are indeed just like applications except there are a few rules. First, yes,
since the system loader loads them, they need to be in OMF . Second, they can use
tools, as long as they shut down anything they start up. Third, they can not allocate
any direct page storage unless they throw it away before the RTL. Most important,
permanent init files can never be loaded into banks $00,$01,$e0,$e1 nor can they
leave any space allocated in those blocks ( except for master pointers ). Also, if
you are going to create a permanent init file, you are most likely going to use
interupts, ( to call you program in memory ) if that is the case, you may want to
brush up on what you can and can't do during an interupt.
Jim
Subj: Re: Object Module Format 88-06-19 23:57:26 EST
From: AFA Gary J
Thanks for the info! I have created a TIF file that works, so I must have done it
right! Thanks for the help.
Gary
Subj: Directory Limitations - 3.5 Dsk 88-12-03 12:32:48 EST
From: MicR Msgs: 8 (88-12-06)
I just replaced my IIc wih a IIc Plus and it has a 3.5 Drive.
I"m trying to consolidate many 5.25 disk files (many of which are small) to a 3.5
disk. Ive used 300 blocks (lots left) - but I cant believe it - the OS only supports
51 directory entries - this is a ridiculous limitation for these diskettes. I would
use subdirectories (which might solve te problem) but a lot of software does not use
subdrectories well. I dont even know if Appleworks does?
Are there any patches to make directories larger or better ways?????
Thanks ahead of time...
Mic
Subj: Re: Directory Limitations-ProDOS 88-12-03 13:39:02 EST
From: BCS Al
To be more accurate, this is a limitation of ProDOS, not a 3.5" disk as you imply in
the subject heading.
Any way, you should be using sub-directories, period. If you could put 100's of files
into the root directory, we'd be back in the DOS 3.3 days.
Good use of subdirectories will make your life much easier, believe me. Being able to
group like files together makes finding files easier and faster than if you had
dozens of of files in the root directory.
If AppleWorks is your main application, I would suggest getting PathFinder from JEM
Software. This AppleWorks patch allows AppleWorks to cruise through subdirectories.
It's a great program.
Subj: ProDOS root directory size limit 88-12-03 13:39:40 EST
From: Dave Lyons
Subdirectories are by far the best way around the 51-file limit for the main
directory of a ProDOS disk. Subdirectories are limited in size only by available
disk space.
It's true that some software doesn't make it convenient to use subdirectories; that's
unfortunate. AppleWorks makes you type pathnames rather than selecting
subdirectories from a list, which is yucky but not too time-consuming once you
practice it a bit.
Note that AppleWorks doesn't deal with large directories well, either! I don't
remember the limit (it depends on what version & what patches you have), but once you
exceed it AppleWorks will typically print some garbage on the screen and HANG just
after seeming to load a new file with no problems.
Now, there _is_ a utility around ALPE somewhere [may have been in top 10; can't
remember for sure] called VDE--Volume Directory Expander. However--as far as I can
tell, the author never tested it with ProDOS 8. While it does successfully add more
blocks onto the main directory and link them so that ProDOS can use the extra blocks,
ProDOS 8 does _not_ let a program's CATALOG command read past the first 51 files! So
VDE lets you put more than 51 files there, but you'll never see the extra ones in a
catalog listing unless you're using the disk on an Apple IIgs running GS/OS instead
of ProDOS 8.
--Dave Lyon
Subj: Re: Directory Limitations - 3.5 88-12-04 13:33:40 EST
From: CecilFret
There is no way to extend the 51 file limit. Use subdirectories. I don't agree the
51 limit is ridiculous. I rarely exceed the 51 limit before running out of data
space. Compared to 51 on ProDOS to 120 something on DOS 3.3, 51 does seem small.
Even the so-called great blue machine called the PC has limits on its root directory
entries. Providing more entries chews up disk space and under a very large majority
of conditions will be wasted because you will fill the disk with information before
you run out of directory space.
Fortunately, if you go to subdirectories, there is no limit to the number of entries.
Granted it would be a pain but create a subdirectory the same name as your disk.
Then you can load this subdirectory up to your heart's content.
Subj: Re: Directory Limitations - 3.5 88-12-04 20:20:05 EST
From: JSchober
Righto, Cecil. Besides, you probably can't put more than 51 decent sized applications
on a 3.5" disk... and if you're storing data files instead of applications, just
create a subdirectory called DATA or something...
Even when you start using a hard disk, you'd think the limit would cause you
problems, but it doesn't... you simply put NO application files in the root
directory. On my hard disk, for example, I have in the root directory PRODOS, PROSEL,
PROSEL.SYSTEM, PRODOS16, the FINDER.xxxxx files, followed by 37 subdirectories. Works
great! :)
--Joe
Subj: Re: Directory Limitations - 3.5 88-12-04 21:16:02 EST
From: RTAFT
All you really need for the //c+ to boot properly is ProDOS, and a SYSTEM file in the
main directory. The rest of the disk can be one large subdirectory. That's what I did
with this software I'm using now. There is no limit to the size of your
subdirectory...except the size of your disk.
Rick Taft
Subj: Re: Directory Limitations - 3.5 88-12-06 21:23:29 EST
From: DennisDoms
I tried the "add volume directory blocks" trick several years ago; as I recall, I
quickly ran into problems with several programs that expected (at most) 4 volume
directory blocks, including BASIC.SYSTEM...
One note about putting all files in one subdirectory: the subdirectory is (usually)
managed as a sequential list, and that means if you try to access a file at the end
of the list it takes the OS longer to find it than one at the beginning. If you want
to see the effect, try a program like:
10 D$=CHR$(4)
15 ?D$;"CREATE A"
20 FOR I = 1 TO 200
30 PRINT "Saving file #";I
40 PRINT D$;"SAVE A/FILE.";I
50 NEXT I
and see how the program slows as it approaches the 200th file. (Then you write the
program to DELETE all the useless files <grin>.)
Many disk utilities may have a "file buffer" limit for managing subdirectory entries,
too. A notable example is AppleWorks, which only reaches (maybe) about the first 130
files it finds in the working directory.
With more files (as with anything else) comes more responsibilities. <sigh>
Subj: deleting directories 88-12-06 23:11:42 EST
From: Dave Lyons
Actually you don't need to write a program to delete all the files out of a
directory...if you're using Davex you can just "delete =", or you can delete the
whole directory by name (it computes the total size of everything in the directory
and asks for permission to delete it).
Subj: Finding drives 88-12-21 20:44:53 EST
From: Clayburn Msgs: 6 (89-01-02)
Does anyone know how GS/OS recognizes the different types of drives.
Clay
Subj: DInfo and Volume calls 88-12-21 22:28:11 EST
From: AFL Jim
Clay,
To get information about the types of devices connected to the IIGS system, you'd use
the GS/OS DInfo call ($202C). This call returns the device name, characteristics of
the device (such as if the media is removable, format allowed, etc.), the total
blocks handled by the device, the slot number, the unit number within the slot, the
version of the device driver, a device ID (which tells you if the drive is an Apple
5.25, ProFile 5Mb, SCSI, RAM Disk, ROM Disk , etc), some information on partitioned
devices, and possibly some extended information.
To find out about all the devices connected, you'd call DInfo starting with device 1,
device 2, etc. until you get a parameter out of range error from GS/OS. Once you have
all of the device names, you can make a GS/OS Volume call ($2008) with each device
name to get the name of the volume mounted on each device. The Volume call is similar
to the old ProDOS-8 Online call, but it requires the device name as its input and
only returns information on one volume at a time.
Chapter 5 of the GS/OS Reference, Volume 1 gives all of this information and more.
Jim Luther
Subj: Re: Finding drives 88-12-22 20:14:23 EST
From: Clayburn
Thanks Jim for the information
Clay
Subj: Re: Finding drives 89-01-01 19:36:09 EST
From: Pbear2
HELP!
I am trying to download the ACU I get to downloading the ACU folder (GS version) and
the prefix will not set. I have called A-link and I have not gotten any help that
works. I have followed all instructions and I get no where. How do I get this program
on
my 5.25 formatted disk?
Subj: Re: Finding drives 89-01-02 02:08:41 EST
From: ScottG25
Is your disk initialized in Prodos format? If so, just hit RETURN when selecting the
prefix from a file information block. As I recall, the button didn't work in my GS
version, either.
Subj: ACU Online Support 89-01-02 15:25:38 EST
From: AFL Jim
ACU is supported online in the Apple II Utilities Forum. Floyd Zink, ACU's author is
the Forum Leader for that forum. Use the keyword, AUT, to get there quickly (press
open-apple-K, then type AUT and return).
Jim
Subj: GS/OS FST Files (Creating) 88-12-30 03:35:27 EST
From: LanTech1 Msgs: 7 (89-01-29)
I was wondering if anyone had any information on how to create a GS/OS FST file.....
I am interested in creating a few operating system files, yet I have no Idea where I
can find any information on creating them.
Subj: Re: GS/OS FST Files (Creating) 88-12-30 10:21:13 EST
From: AFL Jim
I doubt you'll find the information you'd need to write one because Apple has stated
that they won't be publishing FST specs. Apple wants to have control of writing all
FSTs.
Subj: Re: GS/OS FST Files (Creating) 88-12-30 19:56:30 EST
From: SamT2
Volume 2 of the GS/OS Reference is supposed to have info on FSTs.
Subj: Re: GS/OS FST Files (Creating) 88-12-30 22:58:39 EST
From: Dave Lyons
Is it? Last I heard, Apple was _not_ going to release enough info to actually write
an FST: the reason is that they don't want to guarantee all the things about GS/OS
itself that FSTs need to know. In other words, new versions of all FSTs may need to
be released with each new version of GS/OS, as I understand it.
(At least, this is my interpretation of what Steve Glass said at an ADV chat a couple
months ago. I don't remember his actual words--but somebody could dig up the
transcript easily enough....)
Subj: Re: GS/OS FST Files (Creating) 89-01-01 16:59:12 EST
From: AFA Parik
They're going to release information on FSTs in that what comes OUt of them (Option
lists, etc) but not information on writing them.
I did get a basic idea however of what FSTs are generally made up of, if you are
REALLY determined to write one, a good start would be sourcing out the character FST
(very small), you can see the basic format. Of course, anything you write may or may
not work, and Apple will definitely frown on and curse you...:)
Subj: Re: GS/OS FST Files (Creating) 89-01-27 03:44:01 EST
From: AndyBoy1
Some thoughts & notes:
We aren't publishing 'how to write FST's' for a number of reasons. FST's are -very-
complex and although they are separately loaded modules, they are really very
integrated pieces of GS/OS. As mentioned before, FST's can and will change from one
system disk to the next (better and better, of course!)
Also, we take measure in the responsibility of writing FST's. They are crucial to
data integrity, and we are very concerned about this issue. No FST goes out the door
without rigorous testing. (I know, Pro.FST has a 31st day problem)
BTW: GS/OS Ref, Vol 2, is how to write drivers. We do support and encourage 3rd
party drivers, because GS/OS has many features (like caching) which, when used by the
drivers, can greatly increase IO speed.
--Andy Stadler
Apple II System Software
Subj: Re: GS/OS FST Files (Creating) 89-01-29 23:05:28 EST
From: Matt DTS
Andy's got it, natch.
You need more proof that OS integrity is at stake? Consider what would happen if six
people all wrote DOS 3.3 FSTs, each handling GS/OS extended characteristics in a
different way, and then Apple tried to release one. Whose would it work with, if
any?
There's a very big opportunity for people to make the OS almost unusable that way
which we're trying to avoid, on top of all the other more technical reasons which are
equally valid.
--Matt
Subj: requesting ProDOS filetypes 89-01-09 21:59:00 EST
From: Dave Lyons Msgs: 4 (89-06-20)
Someone not on ALPE asked me how to request a ProDOS filetype; the address to write
to may have been posted here before, but I don't see it.
Subj: Re: requesting ProDOS filetypes 89-01-10 00:59:11 EST
From: AFL Jim
To request a filetype and auxtype, you should write to:
Apple II Developer Technical Support
20525 Mariani Avenue
Mail-stop 51-T
Cupertino, CA 95014
Attn: Apple II Filetype Registration
Subj: Re: requesting ProDOS filetypes 89-01-29 23:17:42 EST
From: Matt DTS
Yes, that's it exactly.
Please, PLEASE folks don't send me mail on here requesting filetypes. I use ALPE
from home, and don't have the filetypes database here, nor any way to assure that
your email will ever get answered at all. Please send in that letter, or use
AppleLink Apple Edition or MCI Mail to "AIIDTS" for filetype requests, and I'll be
happy to fill 'em if possible.
--Matt
Subj: New address for Apple II DTS 89-06-20 22:41:48 EST
From: Dave Lyons
We're moving to new building effective next Tuesday, June 27, 1989, so here's the new
address (only the mail stop is different).
To request a ProDOS filetype/auxiliary type assignment, write to:
Apple II Developer Technical Support
20525 Mariani Avenue, MS: 75-3A
Cupertino, CA 95014
ATTN: Apple II Filetype Registration
Be sure to explain what the files will be used for so DTS can assign an appropriate
filetype.
See About Apple II File Type Notes in the software library for more information.
--Dave Lyons, Apple II Developer Technical Support
Subj: GS/OS Formating Call 89-02-08 21:35:09 EST
From: JimLaz Msgs: 7 (89-02-13)
Help, being that I'm still holding off buying the beta version of the GS/OS ref vol
1, I need to know how to format a disk in ProDOS 4:1 and 2:1 interlieves. The call
format and any other information needed would be most apprieciated.
JimLaz
Subj: Re: GS/OS Formating Call 89-02-09 01:36:46 EST
From: AFL Jim
Jim,
I can't really type in all the information you'll need to make the GS/OS Format call
here. Besides knowing how to make the Format call, you'd need to know how to make the
GS/OS DInfo call so you can find the device name of the device to be formatted. I
suggest you go ahead and get the GS/OS Reference manual in beta format if you need to
make GS/OS calls. In the meantime, the ProDOS 16 Format call should take care of you.
Jim Luther
Subj: fmt-ing w/ different interleaves 89-02-09 19:22:46 EST
From: Dave Lyons
Yup, just do a regular old ProDOS 16 formatting call, and the user will get a dialog
asking for the file system and interlave desired.
Subj: Re: GS/OS Formating Call 89-02-09 22:20:08 EST
From: JimLaz
Okay, that's what I did and was surprised by the dialog box! So now I only have to
tell the user which interlieve <--whatever to use. Still would be nice to do it
without making the user do anything (the program I'm working on is for very novice
users).
JimLaz
P.S. I'm even more against getting the beta draft now since they upped the price $10
since Apple took over APDA. I ordered Gary B Little's GS/OS book in hoping it'll
suffice until the final reference manuals come out.
Subj: Re: GS/OS Formating Call 89-02-10 02:14:35 EST
From: Dave Lyons
As far as I know, there is no way for a program to do a format and specify the
interleave. You _can_ specify the file system for the format (I assume it has to
correspond to an FST installed in the system). In that case there is on user
interaction, and the _default_ interleave is used. (Right?)
Subj: Re: GS/OS Formating Call 89-02-11 01:56:05 EST
From: Matt DTS
Right. I think.
It's been a while since I looked into this (like "before GS/OS was released"), but I
know you can use a device specific control code to "GetFormatOptions". You may be
able to "SetFormatOptions" to set the default interleave used when you specify the
"requested_filesysid" in the Format call.
But I'll have to go read my draft of Volume 2 to find out for sure, and that's surely
not what JimLaz wanted (to have to buy TWO beta drafts, one which isn't quite there
but almost is any minute now).
--Matt
Subj: Re: GS/OS Formating Call 89-02-13 16:16:58 EST
From: MikeW50
Actually, a program _can_ specify the interleave. The version of ORCA we are working
on now has a flag to do that.
Mike Westerfield
Subj: Ques. about GS/OS & P16 loader 89-02-11 18:06:47 EST
From: BrianG19 Msgs: 37 (89-03-10)
Can somebody answer this question?:
I am using Merlin 8/16 to write a rather long GS application. The relocatable object
file that is created by Merlin is divided into 2 segments which are both about 30K
long. My problem is that every once and a while, when the Loader loads the program,
it puts the two segments in different banks and the program crashes, because all my
subroutines are called with JSR, not JSL. Is there any way to tell the loader to
load the whole thing into the same bank? (i.e use the "kind" field?) I do not have
any of the bit settings for the "kind" or other fields, so I dont know what is and is
not possible. Help....
-Brian Greenstone (BrianG19)
Subj: Re: Ques. about GS/OS & P16 load 89-02-11 21:29:56 EST
From: Dave HDS
First of all, programs should never be designed to load in specific banks. Bank
allocation will always be different on different machines (everyone will have
different D/A's in memory, etc). The memory manager may also need to move blocks
into different banks as needed, so it's quite possible that a given bank will not
always prove to be free even on an individuals system depending on what has been
executed and what it did. GS/OS will also allocate memory as files are opened
wherever memory is available for work buffers.
All 65816 code is bank aligned. This means that it doesn't really directly need to
know or care what bank it happened to have been loaded and is now executing in. The
system loader will find whatever bank happens to have enough free space to hold each
segment and place it there (relocating your code within the bank as needed since in
many cases only part of a bank may actually be available).
When you have code that is broken down into multiple segments, the system loader
places each segment into it's own bank and then modifies any calls (JSL's) so that
they now point to the correct routine in the far bank. In some cases, if the
segments are small enough, and there is a large enough space in a single bank, all
the segments of a given program may find themselves in the same bank, but one should
never, ever count on this.
I am not too familair with Merlin/16 and the Extended Linker they provide for
constructing large model (multi load segment) code, but I suspect your problem are
those jsr's you are using for calling code in the second segment. This would of
course ONLY work if both segments were loaded together in the same bank. I would
suggest reviewing how Merlin constructs multisegment load files and how you should be
coding external references to routines and data structures that will exist in a
different segment. You may not only need to be using JSL's for your calls, but also
xxxL instructions if you refer to any data held in onther segments or load the data
bank register with the bank address of your other segment from the bank address (high
word) of an external label that is in that other segment and then refer to it
directly. You can then do a PHK PLB sequence to restore the bank register to your
current segment when you need to access data that is part of the first segment.
I remember hearing from people at Apple Developer Services that more mistakes and
errors are reported to them by people incorrectly constructing and accessing
data/routines in multi-segment applications than all other problems combined, so your
certainly not alone...
Dave
Subj: Re: Ques. about GS/OS & P16 load 89-02-12 11:45:17 EST
From: BrianG19
But Im not making the code "bank specific" its just that the entire program is VERY
modularized and each segment needs to call routines in the other segment, but the
code is very "time" dependant, and I dont have the cycles to waste by doing JSL's and
then having to set the data bank for each call and then resetting it upon return.
There's a big difference between:
JSR xxxx
xxx rts
and
JSL xxxxxx
xxxxxx phd
phk
pld
pld
rts
I need the time, really, so is there any way to make the loader load both segments
into the same bank? It usually does it, but once and a while it uses 2 banks.
Also, when I do a PHK, does it push 3 or 4 bytes on the stack. Same with JSL, 3 or
4?
-Brian
Subj: multi-segment applications 89-02-12 17:35:13 EST
From: Dave Lyons
PHK pushes ONE byte onto the stack. That was the easiest answer.
The only acceptable way to get two segments to load into one bank is to NOT HAVE TWO
SEGMENTS. Put the code from both into a SINGLE segment, and that segment will load
into the same bank as itself. :) I'm not familiar with the Merlin linker, but I'm
very surprised it _lets_ you JSR into another segment; the APW/ORCA linker complains
at that point.
It is _not_ necessary to always change the B register when you call a subroutine in
another segment. Consider putting your data all in ONE segment; I don't know how
Merlin handles, this but in APW/ORCA you can have lots of separate PRIVATE DATA
segments w/ the same "load name" (?) and the linker will put them all together. It's
slick. You could leave B pointing at that the whole time.
Subj: Re: Ques. about GS/OS & P16 load 89-02-12 20:30:41 EST
From: Dave HDS
The problem with the Merlin Linker, Dave, is that it only links in 8 bit mode. The
object files it used are in Merlin's form of old Apple REL. This means that when you
code calls to external routines (labels labeled as external), Merlin DOES NOT at
assembly time know if those labels are for routines that will be linked together in a
single segment or if they are for routines that will reside in a seperate segment.
The Merlin Linker, from I recall, allows you to specify which Merlin LNK code modules
will be in which segments, so you can put two or more object files into the first
segment and then specify more in additional segments as well.
The Merlin Linker has one limitation it inherits from Apple's REL format, however: It
cannot construct a single program (in 8 bit mode) or program segment (for
multisegment OML's) that is larger than 32K.
In regards to Brian's original problem; I could only suggest that you try putting all
your timming criticle routines as well as all the routines that directly call them
into one segment and the remainder of your program (and possibly all common
variables/data storage workspace) into that second segment. Putting all your data in
a single segment means you only need to set the data bank register once when your
program is started and can then leave it alone.
Dave
Subj: Re: Ques. about GS/OS & P16 load 89-02-13 16:14:01 EST
From: MikeW50
It might also be worth considering a switch to ORCA or APW, which would prevent all
of these problems. First, you can create single segments up to 64K in length.
Second, and perhaps more important, ORCA or APW would have told you that your program
had an error, since they DO keep track of what segment labels are in, and issue a
warning if you try to access a label in another bank using absolute addressing.
Mike Westerfield
Subj: What I did 89-02-13 20:17:05 EST
From: BrianG19
Well, Merlin 8/16's Linker.XL only allows ~32K segments, so I couldnt merge it into
one, and the program is too modularized to put "timing critical" routines into the
external segment, so what I did was to simply use JSL's and accept the timing loss.
It was a bitch! I spent 8 straight hours modifying 20,000 lines of code and testing
it, but it was worth it, b/c the program works w/o a glitch now. No bugs whatsoever.
I would have switched to APW, but 20,000 lines of incompatible code is not a good
idea, and Merlin 8/16 is really a much better system as long as you plan on using
only 65816 and not C shells or the like.
-Brian
Subj: "No bugs whatsoever" :-) 89-02-13 21:44:09 EST
From: Dave Lyons
"No bugs whatsoever" is a dangerous belief! It's much safer to believe that there
lots of bugs you haven't found. Be sure to force all your segments to load into
_different_ banks and check that things don't get trashed in the wrong bank.
I had a program with "no bugs" for several months, and one day a little segment I
didn't realize I even had got loaded into a different bank from the stuff I
_intended_ to have in the same segment, and the system went south quickly.
In other cases, I've had programs fail to set the B register & _work_ most of the
time, just because the data getting trashed (at the right address in the wrong bank)
didn't happen to be anything critical.
Another kind of bug is one that will make your program incompatible with future
system software. To find those you need to understand all the rules and the
assumptions your program makes.
Again, the point is that "no bugs" is not something you can determine through
_testing_ alone.
Subj: Re: Ques. about GS/OS & P16 load 89-02-20 15:28:31 EST
From: AFA Parik
I've got a question (not related to this one in any way :), sometimes when I run
programs that are being tested or in the middle of being written (ie, BUGGGY!!!) they
do something to memory which disconnects my hard drives [CMS SD60s connected to CMS
SCSI card]. I do a option-OA-control-esc-shift-reset, it goes into self test mode,
I do a oa-cntrl-reset and get back into Orca. When I do a SHOW UNITS, or a CAT /CMS
or whatever, the volume doesn't exist! Slot 7 & 6 just "disconnected" themselves.
My question is WHY? If i turn off the computer and turn it back on, everything is
FINE. But I thought going into self test mode is the same thing! What could my
programs be doing that would just disconnect the firmware until powerdown...
Subj: disappearing SCSI devices 89-02-20 21:54:20 EST
From: Dave Lyons
Parik, first of all the "real" self test keystroke combination is
Apple-Option-Ctrl-Reset. No need for Shift or ESC.
If the CMS SCSI card is like the Apple SCSI card, there's RAM on the card that gets
initialized at power up. If a program runs amok and trashes something there, doing a
self test isn't enough: the card has no way to know you did a self test.
Subj: Re:Lost Drives 89-02-21 03:36:41 EST
From: Mark TMM
Also if the program flips the wrong softswitches it may turn off access to peripheral
card ROM space. I just now thoght of this because the same thing has happened to me.
I would think that your reset routine should work but it didn't for me.
Writing to $e0/c006 should turn on card rom access as opposed to internal rom. I
have not tried this yet but will the next time it occurs.
Subj: losing drives--softswitches 89-02-21 19:51:04 EST
From: Dave Lyons
Well, the softswitches should all be reset during an Apple-Ctrl-Reset. That
shouldn't be a problem unless your Battery RAM settings have been wiped out.
Subj: Re: Ques. about GS/OS & P16 load 89-02-22 01:20:05 EST
From: AFA Parik
It would seem like the softswitches, but I tried that already before and no go. I
thought perhaps writing something to the CMS firmware would mess it up. I can tell
its doing SOMETHING to the firmware because you hear the mysterious