spike@world.std.com (Joe Ilacqua) (03/06/90)
In article <6673@hydra.gatech.EDU> ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!) writes:
< Considering there are C compilers (well, atleast one) for the Apple II,
<how possible is it to write the "assembly only" sections of unix, and then
<compile the C sources for unix on a Apple II? I know it would require some
<of the heavy dute memory expansions that AE makes for the apple II,
<but still.
The big problem (TM) with porting UNIX (or any
multi-tasking/mulit-user OS) to Apple //s is that no Apple // has
memory management. This means all processes can write all of memory.
Instead of seeing "Segmentation fault (core dumped)", when you run a
program with a bug you'll just crash the system. This also means your
system will never be "secure", you would not want to you such a system
for a BBS.
This doesn't mean it can't be done. MINIX runs on 8086 based
IBM PCs, which don't have memory protection. MINIX, as some have
suggested in the past, might even be the place to start. But if it
was that easy...
Also keep in mind, that when people say "UNIX is highly
portable" they mean "UNIX is highly portable *for* an operating
system". There will be quiet a bit of effort in doing the port.
Someone is bound to say "UNIX ran on PDP-11s which had as
little a 64k". This is true, but it is like saying "Apple // DOS ran
in 16k". So what.
->Spike
--
"The World" - Public Access Unix - +1 617-739-9753 24hrs {3,12,24}00bpstoth@tellab5.tellabs.com (Joseph G. Toth Jr.) (03/07/90)
Just voicing my considerations regarding what I (and I feel most people)
would like to see from a UNIX(tm) type of environment on an Apple //;
1 - Multi-user capabilities is NOT a requirement..
It is my computer, and I have no intention of creating a BBS,
or allowing my kids on another terminal while I am working.
A 1Mhz clock rate is slow enough, and even with an accelerator
the overhead of multi-users is impractical.
2 - The ability to write scripts (cshell like, or others) that are
nestable, to perform complex functions based upon execution
of several executable processes.
2 - pipes for data transfer from one process to another.
3 - I/O re-direction of output to a file, the printer, etc.
4 - Multi-tasking is would be nice, but is not really necessary for an
implementation of pipes and I/O re-direction. These could be handled
by temporarily placing all output on a file (pipes place data on a
temporary file) and input to the next process that is loaded and
executed comes from either the keyboard or the temporary file, possibly
by having the system place the keyboard input in the same temporary
file that would have been read by the process from the pipe.
Nothing is impossible ( almost ;v) ), but is it practicle.
There alre already some shells (Davex, ProSel, ECP8, etc.) that provide
some of the capabilities of unix like shells with with some equivalent
command operations. Yet, none is a complete implementation; ECP8 does
some level of shell script operations but no piping; Davex has some
piping but lacks shell script executions; even HyperC-PROdos and Aztec C
execution shells provide limited shell script execution.
It seems that a combination of ECP8 and Davex could get very close to
allowing for a UNIX like envirnoment.
Now, aside from the problem of the implementation of the UNIX environment;
APPLICATION PROGRAMS.
APPLICATION PROGRAMS.
APPLICATION PROGRAMS.
All current applications should be executable from the unix environment,
however they would take over the machine (there goes multi-tasking).
There would have to be new compilers(et al) tailored to the UNIX environment.
Applications would have to be written to handle the piping and/or I/O
re-direction.
Is it a lot of work? YES, YES, YES
Is it worth it? Maybe, I don't really know.
Can it be done? As I said before... (anything can...)
w;
In article <1990Mar5.234421.396@world.std.com>, spike@world.std.com (Joe Ilacqua) writes:
> In article <6673@hydra.gatech.EDU> ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!) writes:
[omitted] Question regarding feasibility (see above)
> The big problem (TM) with porting UNIX (or any
> multi-tasking/mulit-user OS) to Apple //s is that no Apple // has
> memory management. This means all processes can write all of memory.
> Instead of seeing "Segmentation fault (core dumped)", when you run a
--------------------------------
There are enough single-application programs that do this already.
I know, I know; Why add another layer of complexity to the existing problems..
> program with a bug you'll just crash the system. This also means your
> system will never be "secure", you would not want to you such a system
> for a BBS.
As I said before, how many people plan on generating a BBS just because
the UNIX might be capable of multi-user operation? How many people
plan on allowing multiple sessions on their Apple anyway (I know I don't)?
>
> This doesn't mean it can't be done. MINIX runs on 8086 based
> IBM PCs, which don't have memory protection. MINIX, as some have
> suggested in the past, might even be the place to start. But if it
> was that easy...
Nobody ever asked whether it was easy, the question was feasible.
>
> Also keep in mind, that when people say "UNIX is highly
> portable" they mean "UNIX is highly portable *for* an operating
> system". There will be quiet a bit of effort in doing the port.
The portability of UNIX really only exists in the user interface.
The portability of C code is also a question.
Does anybody who reads comp.sys.apple2 also read the newsgroups that
provide C source code files? Ever notice all the #ifdef's to determine
what code to use for which system and/or compiler?
Portability of UNIX and C is a joke..
And all I want is to have my Apple accept the UNIX form of commands and
provide the UNIX like piping and I/O redirection along with script execution.
Oh, yes; with the applications programs to go with them;
compilers, assemblers, linkers...
an editor - vi, emacs, etc.
cron - to go with my clock to execute jobs at certain times.
Does not even have to be multi-tasked. It could just run when
in the command parser environment and execute tasks in sequence
when no other tasks are active..
etc., etc., etc.
I know it's a pipe dream, totally impracticle, and probably not worth
even 1/1000000 th. the effort (conservative estimate); but, it would be nice.
> Someone is bound to say "UNIX ran on PDP-11s which had as
> little a 64k". This is true, but it is like saying "Apple // DOS ran
> in 16k". So what.
Yet, Why Not...
--
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so | Joseph G. Toth Jr.
seldom understood. Don't FLAME on me, please. | uunet!tellab5!tothrlw@ttardis.UUCP (Ron Wilson) (03/20/90)
In article <2218@tellab5.tellabs.com>, toth@tellab5.tellabs.com (Joseph G. Toth Jr.) writes: >The portability of UNIX really only exists in the user interface. >The portability of C code is also a question. >Does anybody who reads comp.sys.apple2 also read the newsgroups that >provide C source code files? Ever notice all the #ifdef's to determine >what code to use for which system and/or compiler? >Portability of UNIX and C is a joke.. As an experienced developper (and "porter") I can tell you that Unix and C are a heck of lot more portable than anything else. Unix runs on more different hardware than everything else combinded. The C language has been implemented on almost all new systems - with many "old" systems following suit. Granted that Unix and C portablity is overly touted - they ARE the most portable of general purpose systems and languages. True there are languages that are "totally" portable, but these languages are application specific - for example, Informix-SQL is the same on all combinations of OS and software that Informix, Inc supports - nice if that's all you need, but the real world demands more. Yes, porting C programs between systems - even 2 Unix systems - is very difficult. But it's a lot better than porting between 2 different languages, or worse, 2 different OS's.