Re: ProDOS...

[dempson@actrix.gen.nz (David Empson)]

Roy and/or Janet Miller <millers@inetnebr.com> wrote:

> Phoenyx wrote:
> >
> > My comment about the P8 compatibility is still valid, just as David's is.
> > Any new or upgraded OS would loose 80 to 90 percent compatibility with
> > system applications due to the way the ProDos/Apple II system is designed.
> 
> But would a full implementation of SOS do that?

SOS would be no better than any other non-ProDOS operating system.

ProDOS implements a subset of the calls available on a full SOS system.
I've never seen any programming documentation for SOS, but my
understanding is that ProDOS allows for nearly all the SOS support for
file I/O on block devices.  SOS also has full support for character
devices (such as serial and parallel ports), unlike ProDOS.

I believe that ProDOS uses the same call numbers and similar parameters
to the corresponding SOS calls, which makes it relatively easy for the
author of an application to support both operating systems (///
EZ-Pieces and AppleWorks being the best example of this).

> Since P8 is only a cut down version of SOS?

ProDOS is a functional subset of SOS, but as far as I know, the memory
organisation and application protocol interfaces are different.

SOS was designed around the architecture of the Apple III, including its
special extended memory architecture.  ProDOS was designed to squeeze
into the limitations of the Apple II.

> One thing that SOS does that I would like to see in P8 is the
> ability to utilize more than 128K as user memory.

This is due to the extended memory architecture provided by the Apple
/// hardware.  In effect, it can directly address more than 64 KB
without requiring bank switching techniques.

The Apple II has no such specialised hardware, and uses complex bank
switching techniques to access more than 64 KB.  The 16 KB language card
area (hidden behind the 12 KB of ROM) was the first such method,
followed by the 64 KB auxiliary memory of the Apple IIe.

Third-party memory expansion cards extended the auxiliary memory concept
by providing a multi-bank version of it.  Unfortunately, this is rather
difficult to manage.

> Wouldn't it be nice to see all P8 programs have that kind of data without
> having to use RAM disks?

The multi-bank memory architecture doesn't allow for this sort of thing
without each application being written specially to use it.

> > I know that many don't agree with the GPL concept for Apple software or
> > hardware for that matter.
>
> Just so that I am sure I know what you are talking about, please give a
> concise statement of GPL, and why wouldn't people agree with it for the II.

As I understand it, the fundamental principle of the GPL is that if you
use any GPL'ed code in a program you write and distribute, you must make
any derived source code available.

This doesn't necessarily mean that you have to distribute the entire
source code of your program, only the parts that are derived from a
GPL'ed source.  I'm not sure how this works in a monolithic program (it
might require the source for the entire program to be distributable),
but a modular program with GPL'ed code only in certain modules would
only require distribution of the source for those modules.

There is no requirement that the source code be given away free of
charge.

As for why this might be a bad idea: some people are fundamentally
opposed to any forced distribution of their source code.  I don't see
any problem with this in cases where the majority of the program was
derived from a GPL'ed source, but the license still applies even if the
GPL'ed source only makes up a small proportion of the code.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P O Box 27-103, Wellington, New Zealand