[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .SYSTEM file extensions




In article <Aug08.000811.84406@acs.ucalgary.ca> sbdocker@acs.ucalgary.ca (Sean Brendan Dockery) writes:

>Uh.. Wrong.  :)
Uh, NOT!

>The BASIC.SYSTEM program has to use the ProDOS MLI to load the files
>(that's why they call it an operating system).

DUH!

>BASIC.SYSTEM allocates a 1K intermediate read buffer and donates it to
>ProDOS. BASIC.SYSTEM then does a ProDOS READ call using the auxilliary
>address field of the file as the loading point of the file (which
>happens to be $2000 for all SYS files).

But it's the BI that's doing the read calls.  Prodos could care less if it
is a system file or a basic program or a data file or whatever being loaded.
The BI is doing all the work of specifying what to load and where to load.
It's the BI's responsibility, not Prodos's.  

>The error results from ProDOS finding out that BASIC.SYSTEM's read
>call is going to write over some memory protected by the ProDOS
>bitmap (which ironically is the BASIC.SYSTEM interpreter).

That's because the BI protects that memory in the Prodos bit map.

>So, it *does* indeed matter if the memory is protected by ProDOS.

Minor mis-communication..  The point was that it's not Prodos that protected
the BI space, but rather the BI.  Prodos doesn't know how much total space
a system program may need, so how could it possibly protect it?  Same for if
I wrote a launch utility.  It wouldn't know anything about the memory 
requirements of the programs it launches.

>Just a moot point, but the address of the allocated 1K read buffer is
>$9600.  The BASIC.SYSTEM general purpose buffer (GPB) is relocated
>down 1K to $9200.  This is to give as much room to read in a file as
>possible (as BASIC.SYSTEM doesn't care if the GPB is overwritten).

I'd have to disagree with that.  I've never verified with a system file, 
but for every other type of file the BI won't overwrite any of its buffers, 
including the GPB.  I can't imagine why it'd make an exception.  (Well, I 
CAN, but if the 'No Buffers Available' error when trying to BLOAD something
over the GPB is caused by the same Prodos bitmap error that gives it when
loading a system file, then what's the difference?  (Lessee, does that 
sentence read right...  Yeah, sort of..=)  )

>| >I think that the SHRINKIT.SYSTEM file zeroes all memory usage in the
>| >ProDOS bitmap except for ProDOS itself.  That way when it tries to
>| >load the SHRINKIT file at $2000, the overwrite of BASIC.SYSTEM code is
>| >no longer considered a memory violation.

>| Of course it does!  The Basic.System program no longer 'exists' in memory
>| because it gave up control to another system program.  The BI frees its
>| space in the bitmap (or is supposed to) not the next program that gets 
>| loaded.

>"Of course it does"?  It ain't necessarily so.
>
>I *could* write a program that loads in a file, 1K blocks at a time
>and relocates them as they are loaded.  So, I could be violating
>ProDOS's memory bitmap without ProDOS knowing about it (as I would be
>handling the relocation of code myself).

Yeah, but you're violating Apple's programming guidelines, and thus you 
shouldn't expect your program to remain compatable with Prodos or other
programs.  (I actually do something similar to what you say to make old
DOS 3.3 games run under Prodos.  Of course you have to reboot afterwards
'cuz Prodos has been trashed, but..)

>Just another moot point, but BASIC.SYSTEM does *not* free its space in
>the bitmap.  If it *did*, you would *not* get an error when loading a
>SYS program of $7201 bytes (as was the starting point for this entire
>discussion).  Also if it did, any error you received would be because
>your read call would potentially overwrite ProDOS (as that is the
>first memory block above your loading point that is still marked as
>used in the ProDOS global page.  In essence, it would be an unloadable
>system program.

Then that's a bug in the BI, since that doesn't follow Apple's programming
convention.

>That is completely correct -- just because [I've] never seen them
>doesn't mean they don't exist.  But, did you catch the part where I
>was asking for people to give me examples of any that are?

Yeah.  So ok, I write programs.  I'll write an 'original' program with 
the .SYSTEM name that is longer than that and send it to you.  Will that
satisfy you?  =)  

>I believe that I addressed this issue (in a later message).

Yeah, I saw it..  Too late though..  =)

>I'm still waiting for someone to notify me as to a distributed system
>program that was *originally* named with a .SYSTEM extention that is
>larger than $7200.  That's all I want to know.

See above! 

>I hope that I have responded to all of your concerns. :)

Yup..  Doesn't mean I agree or anything, but ...  =)

> internet: dockery@griffin.cuc.ab.ca
>      -or- sbdocker@acs.ucalgary.ca
>      -or- dockery@pro-calgary.cts.com
> pro-line: dockery@pro-calgary

Michael Foegelle
-- 
   Michael Foegelle  | Call Wunderland BBS! |   foegelle@ccwf.cc.utexas.edu
    University of    | (512) 472-0544  8n1  |   foegelle@utaphy.ph.utexas.edu
   Texas at Austin   | 14.4kbaud, v.32/bis  |   GEnie:   M.FOEGELLE2
  Physics Department | 500 megs on a //e!   |   > Ask me about Columns //e! <