Unix versus CP/M
@robase, Salle multimédia
-----------
"Unix Feedback"
in "Letters" column, BYTE, August 1982, p.20
(Retyped by Emmanuel ROCHE.)
I find that I grow tired of the Unix-versus-CP/M argument,
particularly as it is phrased by people like John Lynn Roseman
(April 1982 BYTE, "Letters", page 22): "Unix is a full-featured
operating system which is widely regarded as the finest ever
written, while CP/M is little more than a program loader." Really?
I defy anybody to take a competent secretary and make him or her a
useful word-processing person on the Unix EX/VI in less time that
it takes to get your work done on the CP/M WordStar system.
And I don't like the crystal-ball predictions and dogma-
before-the-fact apparent in Mr.Roseman's statement: "... we can be
sure that the commercial software which will eventually be
available under Unix will be of higher quality than that found in
the CP/M market." We can?
I direct your attention to an article by Donald Norman that
appeared in DATAMATION magazine all the way back in November 1981
(page 139 and following). It is titled "The Trouble with Unix",
and it hits a number of nails on the head. Although I am fluent in
a number of dialects of a number of languages and in a number of
operating systems, I still haven't found the ultimate anything.
CP/M has a number of serious limitations, but so does Unix (and so
does anything else that I have ever used).
Allow me to paraphrase Norman's conclusions, in which he
states his three most important concepts for system desing: be
consistent, provide the users with a clear idea of what is going
on at all times, and provide mnemonics as aids to us poor humans.
I would add a final imperative: remember the users' context. In
other words, decide what you want to have a given system do, and
for what audience. CP/M is a tremendous environment for single
users doing word processing and data acquisition; BASIC is a
wonderful tool for a wide range of (generally small and one-of-a-
kind) programming tasks; Unix is an amazing tool for some of the
data-intensive work that I sometimes need to do.
But, please, give us a break from the search for a perfect
system for all people for all time. Provide me with information,
tell me (as objectively as possible) about the tools that are
available, and then leave me alone so that I can get my work done.
Jeffrey L. Star
I have some bad news for John Lynn Roseman and the recent
crop of university-type Unix supporters. Unix has been running on
16-bit computers called Digital Equipment Corporation (DEC) PDP-
11s for many years. There have been some other operating systems
for the same machines. Guess which operating system is NOT at the
top of the popularity list?
The most popular operating system on PDP-11 computer large
enough to run Unix is RSTS/E. The primary language used with
RSTS/E is BASIC PLUS, not the "powerful C language". While RSTS/E
is used in the commercial PDP-11 environment, RSX11M is more
popular on the scientific systems. When DEC introduced the VAX11
superminicomputer, it did not select Unix but rather upgraded
RSX11M. I have never even seen an advertisement for a programmer
with Unix or C experience.
This is not meant as a criticism of Unix or C, nor is it
meant to endorse RSTS/E or RSX11M. I would be tempted to write off
RSTS/E as a primitive, crude system except that it is enormously
popular and its users extremely enthusiastic. The marketplace is
different from the university classroom. The needs of the end user
are different from those of the system software developer.
CP/M is a rinky-dink kind of operating system. It does,
however, do most of what most microcomputer users want, with a
minimum of fuss. I have used various operating systems on IBM,
DEC, and Control Data Corporation machines, and I don't feel
neglected or abused by CP/M.
Unix, C, and Pascal may be excellent teaching and development
tools, but they may not be so good for commercial production work.
While we, Old Timers, must be open to new ideas, the new crop of
computer science graduates must keep in mind the difference
between theory and practice. (By the way, what ever happened to
ALGOL?)
Mike Draper
EOF
John Elliott
[quoting an article from 1982]
>I would be tempted to write off
>RSTS/E as a primitive, crude system except that it is enormously
>popular and its users extremely enthusiastic.
*cough* Microsoft Windows *cough*
> Unix, C, and Pascal may be excellent teaching and development
>tools, but they may not be so good for commercial production work.
Funny, that, isn't it? In 2001, Unix and C are widely used in
commercial production work :-)
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Paul Ryan
> with Unix or C experience.
I found that bit rather amusing, it shows how times changed.
Paul
anon...@bogus_address.con
Richard Erlacher
software development environments. Anyone who's attempted to use it
for accomplishing useful work, however, will point up a number of
weaknesses.
Software is sold to run under UNIX, however, because it's too
difficult to fix and maintain if it is developed under UNIX and run
under an OS tailored for the user's convenience. Clear evidence of
this is provided by the software offering to the EDA community. When
vendors are releasing 20+ patches per year to their products, it's not
practical to go across OS boundaries.
Of course, if they were to test and debug their products before
releasing them, much of this effort and inconvenience could be
avoided.
Dick
On Tue, 03 Apr 2001 16:50:46 , j...@seasip.demon.co.uk (John Elliott)
wrote:
Jeffrey L. Susanj
"Richard Erlacher" <ed...@hotmail.com> wrote in message
news:3acdf197...@mindmeld.idcomm.com...
> The impression I've gotten is that UNIX is just about the ultimate in
> software development environments. Anyone who's attempted to use it
> for accomplishing useful work, however, will point up a number of
> weaknesses.
>
> Software is sold to run under UNIX, however, because it's too
> difficult to fix and maintain if it is developed under UNIX and run
> under an OS tailored for the user's convenience. Clear evidence of
> this is provided by the software offering to the EDA community. When
> vendors are releasing 20+ patches per year to their products, it's not
> practical to go across OS boundaries.
>
> Of course, if they were to test and debug their products before
> releasing them, much of this effort and inconvenience could be
> avoided.
>
> Dick
>
>
platforms, such as Star Office, Word Perfect 8 and most GNU tools. However,
what I see as the main attraction of the Linux flavor of UNIX to CP/M users
is that it is Open Source and nothing is hidden as it is in Windows. I use
all three systems but I have the most fun with Linux and CP/M since I can
get down into the guts of either one. If something acts strangely on
Windows it is a mystery to me why and even when I fix the problem it is
usually done by stumbling around in the dark. CP/M and Linux either just
plain work or any problems can be tackled with enough documentation to know
what I am doing.
Jeff S.
Richard Plinston
>
> The impression I've gotten is that UNIX is just about the ultimate in
> software development environments. Anyone who's attempted to use it
> for accomplishing useful work, however, will point up a number of
> weaknesses.
>
> Software is sold to run under UNIX, however, because it's too
> difficult to fix and maintain if it is developed under UNIX and run
> under an OS tailored for the user's convenience. Clear evidence of
> this is provided by the software offering to the EDA community. When
> vendors are releasing 20+ patches per year to their products, it's not
> practical to go across OS boundaries.
The 20+ Patches may have nothing to do with the difficulty of developing
or testing, nor with 'fixing', but may be entirely due to the client
users re-deciding what is convenient.
I develop software for certain users and issue changes or 'patches' that
are entirely related to the client's requirements changing or being
refined, or adding new functionality.
I also have my systems running on DOS, Windows, Unix and Linux with no
change in source code. I develop under MultiUser-DOS (derived from
DRI's DR-MDOS), then copy to Unix for recompile and then run on Unix or
Linux.
anon...@bogus_address.con
On 2001-04-06 jeffrey....@boeing.com said:
>There are a few major applications that are available for multiple
>platforms, such as Star Office, Word Perfect 8 and most GNU tools.
>However, what I see as the main attraction of the Linux flavor of
>UNIX to CP/M users is that it is Open Source and nothing is hidden
>as it is in Windows. I use all three systems but I have the most
>fun with Linux and CP/M since I can get down into the guts of
>either one. If something acts strangely on Windows it is a mystery
>to me why and even when I fix the problem it is usually done by
>stumbling around in the dark. CP/M and Linux either just plain
>work or any problems can be tackled with enough documentation to
>know what I am doing.
The similarity, however, ends there.
LINUX -- like WinDoze -- is a protected-mode, multitasking O.S.,
and therefore requires that you call system API functions in order
to accomplish much of anything. This essentially forces you to
use the C language for writing your software.
And, of course, almost all direct hardware accesses are prohibited.
Even though GAS or NASM can be used to write small utilities or
trivial apps in assembly language, you're still stuck with having
to call system services (INT 80h), or having to call C functions
from outboard object files.
In actual operation, LINUX stuffs the programmer into a standardized
'box' that's just about as confining as a WinDoze 'box.'
Luddite that I am, I personally prefer a real-mode O.S. such as
CP/M or DOS...where the hardware is =directly= accessible to the
programmer. :)
John Elliott
>In actual operation, LINUX stuffs the programmer into a standardized
>'box' that's just about as confining as a WinDoze 'box.'
>
>Luddite that I am, I personally prefer a real-mode O.S. such as
>CP/M or DOS...where the hardware is =directly= accessible to the
>programmer. :)
Just run everything as root the whole time :-)
Richard Plinston
>
> LINUX -- like WinDoze -- is a protected-mode, multitasking O.S.,
> and therefore requires that you call system API functions in order
> to accomplish much of anything. This essentially forces you to
> use the C language for writing your software.
Complete nonsense, software can be written in Perl, Python, Fortran,
PL/I, Cobol, Pascal, Delphi, or about 100 other languages. Any of these
can do system API calls directly or via libraries.
> And, of course, almost all direct hardware accesses are prohibited.
Direct hardware accesses can be done, but on systems that can run more
than one program at a time there is always the potential for two or more
to attempt access, this is why it is best to use some sort of
co-ordintaion mechanism, such as a device driver.
> Even though GAS or NASM can be used to write small utilities or
> trivial apps in assembly language, you're still stuck with having
> to call system services (INT 80h), or having to call C functions
> from outboard object files.
> In actual operation, LINUX stuffs the programmer into a standardized
> 'box' that's just about as confining as a WinDoze 'box.'
Complete nonsense. The programmer can chose whatever 'box' they like.
> Luddite that I am, I personally prefer a real-mode O.S. such as
> CP/M or DOS...where the hardware is =directly= accessible to the
> programmer. :)
In most cases there is no need to bit bang the hardware to do a task, it
is like saying that you prefer a 'mixture control' and 'ignition advance
and retard' on the dashborad your car (I used to have one with these)
because you like to directly access the hardware of your engine.
anon...@bogus_address.con
On 2001-04-07 rip...@Azonic.co.nz said:
>Complete nonsense, software can be written in Perl, Python, Fortran,
>PL/I, Cobol, Pascal, Delphi, or about 100 other languages. Any of
>these can do system API calls directly or via libraries.
That wasn't my underlying point, so perhaps I phrased it badly.
The larger point I was attempting to convey is that with LINUX --
just as with WinDoze -- the 'approved' programming method is to
use calls to the system API...rather than directly accessing
hardware peripherals, or directly calling ROM BIOS functions.
>In most cases there is no need to bit bang the hardware to do a
>task, it is like saying that you prefer a 'mixture control' and
>'ignition advance and retard' on the dashboard [of] your car
>(I used to have one with these) because you like to directly
>access the hardware of your engine.
Yes. That's =precisely= what I'm saying. :) When it comes to
programming, that's my personal preference.
As the French say, 'Chacun a son gout.' ;)
anon...@bogus_address.con
On 2001-04-06 j...@seasip.demon.co.uk (John Elliott) said:
>anonymous@bogus_address.con wrote:
>
> > Luddite that I am, I personally prefer a real-mode O.S. such as
> > CP/M or DOS...where the hardware is =directly= accessible to the
> > programmer. :)
>
>Just run everything as root the whole time :-)
Heh! Good idea, John. <g> But in that case...why even bother to
install LINUX at all? :)
After all, those multi-megabytes of disk space required by LINUX
could be used to hold a whole lotta DOS or CP/M-86 software. ;)
Richard Plinston
>
> The larger point I was attempting to convey is that with LINUX --
> just as with WinDoze -- the 'approved' programming method is to
> use calls to the system API...rather than directly accessing
> hardware peripherals, or directly calling ROM BIOS functions.
And how is this different from CP/M ? CP/M was _designed_ to isolate
the programmer from the underlying hardware by providing a uniform BDOS
API that interfaces to the various hardware items via the BIOS which is
specific to each machine. The 'approved method' under CP/M (and MS-DOS
and most other OSes) is to use the BDOS calls rather than directly
accessing the hardware or directly calling the ROM BIOS.
> Yes. That's =precisely= what I'm saying. :) When it comes to
> programming, that's my personal preference.
Fine, bit bang to your hearts content, but don't criticise other systems
just because bit-banging is unrequired for normal programming and leads
to problems due to more than one program running.
Of course you could always write device drivers as these require
bit-banging.
Richard Plinston
> >
> >Just run everything as root the whole time :-)
>
> Heh! Good idea, John. <g> But in that case...why even bother to
> install LINUX at all? :)
I am not sure how those ideas are related.
> After all, those multi-megabytes of disk space required by LINUX
> could be used to hold a whole lotta DOS or CP/M-86 software. ;)
There seems to be a large shortfall of knowledge here. I have one Linux
machine that doesn't even have a hard disk, it boots off a 1.44 Mb
diskette and will run in 8MByte of memory. It acts as an internet
gateway and runs a web server and several other services (such as
telnet).
The 'multi-megabyte' installs includes a whole lotta software, some of
which CP/M-86 and DOS would only dream about.
CBFalconer
>
... snip ...
>
> In most cases there is no need to bit bang the hardware to do a task, it
> is like saying that you prefer a 'mixture control' and 'ignition advance
> and retard' on the dashborad your car (I used to have one with these)
> because you like to directly access the hardware of your engine.
Very useful to get my old Model A to go ker chug ker chug. You
forgot the starting crank. Don't wrap your thumb around it. And
floorboards were boards. Horns go AooGah.
--
Chuck F (cbfal...@my-deja.com) (cbfal...@XXXXworldnet.att.net)
http://www.qwikpages.com/backstreets/cbfalconer
(Remove "NOSPAM." from reply address. my-deja works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Don Maslin
: Richard Plinston wrote:
:>
: ... snip ...
:>
:> In most cases there is no need to bit bang the hardware to do a task, it
:> is like saying that you prefer a 'mixture control' and 'ignition advance
:> and retard' on the dashborad your car (I used to have one with these)
:> because you like to directly access the hardware of your engine.
: Very useful to get my old Model A to go ker chug ker chug. You
: forgot the starting crank. Don't wrap your thumb around it. And
: floorboards were boards. Horns go AooGah.
Music to my ears, Chuck!
- don
: --
Charles Richmond
>
> Richard Plinston wrote:
> >
> ... snip ...
> >
> > In most cases there is no need to bit bang the hardware to do a task, it
> > is like saying that you prefer a 'mixture control' and 'ignition advance
> > and retard' on the dashborad your car (I used to have one with these)
> > because you like to directly access the hardware of your engine.
>
> Very useful to get my old Model A to go ker chug ker chug. You
> forgot the starting crank. Don't wrap your thumb around it. And
> floorboards were boards. Horns go AooGah.
>
I thought they had electric starters...at least ours did, in th 1950's.
Some other interesting things were: the windshield was flat, and you could
turn it to be horizontal...the gas went in just in front of the windshield.
Running boards were great...every car should have them. Our top speed was
about 50 m.p.h with the four cylinder non-high compression engine. I loved
the long gear shift lever sticking up from the middle of the floorboard...
Because of the law, we added an electric windshield wiper...but only on
the
driver's side...
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Juha Laiho
>anonymous@bogus_address.con wrote:
>> The larger point I was attempting to convey is that with LINUX --
>> just as with WinDoze -- the 'approved' programming method is to
>> use calls to the system API...rather than directly accessing
>> hardware peripherals, or directly calling ROM BIOS functions.
>
>And how is this different from CP/M ? CP/M was _designed_ to isolate
>the programmer from the underlying hardware by providing a uniform BDOS
>API that interfaces to the various hardware items via the BIOS which is
>specific to each machine. The 'approved method' under CP/M (and MS-DOS
>and most other OSes) is to use the BDOS calls rather than directly
>accessing the hardware or directly calling the ROM BIOS.
Hmm.. if I recall correctly, the list of BDOS functions was rather
sparse, so hardware-dependent coding was somewhat hard to avoid.
As examples that I think were missing (please correct, if needed):
- control of the serial port (speed, parity, bit rate)
- standardised interface for talking to cursor-addressable terminals
(i.e. calls for "clear screen", "set cursor position", and the like)
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ UH++++$ UL++++ P++@ L+++ E(-) W+$@ N++ !K w !O
!M V PS(+) PE Y+ PGP(+) t- 5 !X R tv--- b+ !DI D G e+ h--- r+++ y+++
"...cancel my subscription to the resurrection!" (Jim Morrison)
Bruce Morgen
>Richard Plinston <rip...@Azonic.co.nz> said:
>>anonymous@bogus_address.con wrote:
>>> The larger point I was attempting to convey is that with LINUX --
>>> just as with WinDoze -- the 'approved' programming method is to
>>> use calls to the system API...rather than directly accessing
>>> hardware peripherals, or directly calling ROM BIOS functions.
>>
>>And how is this different from CP/M ? CP/M was _designed_ to isolate
>>the programmer from the underlying hardware by providing a uniform BDOS
>>API that interfaces to the various hardware items via the BIOS which is
>>specific to each machine. The 'approved method' under CP/M (and MS-DOS
>>and most other OSes) is to use the BDOS calls rather than directly
>>accessing the hardware or directly calling the ROM BIOS.
>
>Hmm.. if I recall correctly, the list of BDOS functions was rather
>sparse, so hardware-dependent coding was somewhat hard to avoid.
That's true, but what was
more of a factor imo was
the slow hardware of the
CP/M and early DOS eras --
bypassing DOS and BIOS was
necessary to get decent
serial port performance
not only because the API
was so scant (what, not
status calls?), but also
because the OS code often
incurred too much
overhead for all but the
slowest data rates. When
the IBM-PC architecture,
with it's on-bus video
access became predominant,
Lotus made hardware-direct
video coding necessary for
any software that didn't
want to appear pig-slow by
comparison.
>
> As examples that I think were missing (please correct, if needed):
>- control of the serial port (speed, parity, bit rate)
>- standardised interface for talking to cursor-addressable terminals
> (i.e. calls for "clear screen", "set cursor position", and the like)
Z-System took care of the
terminal stuff through its
TCAP facility, and a number
of us took a run at some
enhanced port control
either through Z-System's
IOP segment or with
extended BIOS calls. We
never did agree on a
convention for that, and
we were already well into
the Wintel period with our
old hardware rapidly going
obsolete. Hal Bower is
probably the last guy still
working in that area -- and
he's persistent way beyond
the ken of ordinary
mortals. :-)
Kelli Halliburton
news:tcscm84...@corp.supernews.com...
> Luddite that I am, I personally prefer a real-mode O.S. such as
> CP/M or DOS...where the hardware is =directly= accessible to the
> programmer. :)
Of course, the problem with that is: when the hardware changes, the software
breaks. Or else you have a proliferation of drivers, and with operating
systems like CP/M and DOS, those drivers are probably going to have to be
unique to the requirements of the application, so each app needs its own set
of drivers... ugh.
anon...@bogus_address.con
On 2001-04-08 kell...@crosswinds.not said:
> > Luddite that I am, I personally prefer a real-mode O.S. such as
> > CP/M or DOS...where the hardware is =directly= accessible to the
> > programmer. :)
>
>Of course, the problem with that is: when the hardware changes, the
>software breaks. Or else you have a proliferation of drivers, and
>with operating systems like CP/M and DOS, those drivers are
>probably going to have to be unique to the requirements of the
>application, so each app needs its own set of drivers... ugh.
The solution to THAT is: don't change hardware. :)
CBFalconer
>
> Richard Plinston <rip...@Azonic.co.nz> said:
> >anonymous@bogus_address.con wrote:
> >
> >And how is this different from CP/M ? CP/M was _designed_ to isolate
> >the programmer from the underlying hardware by providing a uniform BDOS
> >API that interfaces to the various hardware items via the BIOS which is
> >specific to each machine. The 'approved method' under CP/M (and MS-DOS
> >and most other OSes) is to use the BDOS calls rather than directly
> >accessing the hardware or directly calling the ROM BIOS.
>
> Hmm.. if I recall correctly, the list of BDOS functions was rather
> sparse, so hardware-dependent coding was somewhat hard to avoid.
>
> As examples that I think were missing (please correct, if needed):
> - control of the serial port (speed, parity, bit rate)
> - standardised interface for talking to cursor-addressable terminals
> (i.e. calls for "clear screen", "set cursor position", and the like)
You could call all the standard bios functions by using an offset
from the address in memory location 0001. I believe cpm3 even
added a bdos function to do this. Things like clear screen could
not be implemented, because the terminal was not necessarily part
of the machine, and might very well not even have a screen.
The standard CON, RDR, PUN, and LST devices could be implemented
in various ways, and did not necessarily HAVE a speed, parity,
etc. They could be configured by the iobyte in location 4, which
allowed each logical device to connect to up to 4 physical
devices. One failing was that this was done in bdos, rather than
through a bios call, which made proper device initialization hard.
Harold Bower
> Z-System took care of the
> terminal stuff through its
> TCAP facility, and a number
> of us took a run at some
> enhanced port control
> either through Z-System's
> IOP segment or with
> extended BIOS calls. We
> never did agree on a
> convention for that, and
> we were already well into
> the Wintel period with our
> old hardware rapidly going
> obsolete.
AMEN! The Z-System TCAP solved many problems, the most recent of which
I tackled was computing timing delay loops for the Flash BIOS
programming algorithms in Dave Brooks' P112 so that it wasn't locked
into a set clock speed, but could be software switched between Crystal
Freq DIV 2 and crystal Freq clock speeds. Many other uses, and that is
why Cam and I relied on it heavily in the ZSDOS and B/P Bios efforts.
> Hal Bower is
> probably the last guy still
> working in that area -- and
> he's persistent way beyond
> the ken of ordinary
> mortals. :-)
<Blush>..you knew this flattery would draw me out... Actually, as
Edison said, invention is 99% perspiration (that's my job) and 1%
inspiration (that's left to smarter people).
Hal
Bruce Morgen
That's why God created
Bridger Mitchell. :-)
What a pleasure is was
working with you guys out
on the last 8-bit frontier
-- most of the younger set
will never know what a
blast we had. Those were
the days, my friend....
Kelsang Dawa
<snip>
> ...Cam and I relied on it heavily in the ZSDOS and B/P Bios efforts.
<snip>
Hi Hal,
I know that you released ZSDOS under the GNU GPL in 1999. I run it on my
P112 board and would like to thank you very much for the fine work that
you and Cam put into it.
Did you ever get around to releasing B/P BIOS under GPL? I thought you
mentioned you might do this sometime.
Thanks
dawa
@robase, Salle multimédia
> Hmm.. if I recall correctly, the list of BDOS functions was rather
> sparse, so hardware-dependent coding was somewhat hard to avoid.
>
> As examples that I think were missing (please correct, if needed):
> - control of the serial port (speed, parity, bit rate)
> - standardised interface for talking to cursor-addressable terminals
> (i.e. calls for "clear screen", "set cursor position", and the like)
Juha,
Since I am a fan of CP/M who is trying to find all the original articles
written by Gary Kildall and computer magazines reviewers, I can give you the
following explanations:
1) The list of BDOS functions is tailored for handling a floppy disk drive.
If you have the curiosity of checking the list of functions of Minix (a Unix
version 7 clone), you will seem how similar to CP/M they are. In both cases,
only about 40 functions are enough to implement a Disk Operating System.
2) All your "examples of things that were missing" assume that you are using
a screen... but the screen became a common device only about 2 or 3 years
AFTER the development of CP/M. In fact, in the DDJ article of 1981, Gary
Kildall explains that, like all the programmers of his time, he was using a
"Teletype ASR-33". (Search on the Internet to see a photo.) This is a kind
of electric typewriter who was a standard for Telex: when computers were
introduced: rather than build something new, they simply used the Telex
terminals available. The Teletype ASR-33 was the last and a "best-seller" of
those.
Many things still used today (for example in MS-DOS and Linux) are, in fact,
the way they are BECAUSE they could only be done a particular way on the TTY
(the common abbreviation (there were lots of abbreviations in Telex
messages) for the Teletype: see the list of "control codes" of the
US-ASCII).
Right now, without any written doc, I am thinking about:
uppercase letters for filename: because the cheapest model of TTY had only
uppercase letters... (The 8+3 filename convention was used by DEC computers:
CP/M was "patterned" after the DECSystem-10 "Monitor" that Gary Kildall
liked. "PIP" was the name of a DEC program. And DDT, too...)
Carriage Return + Line Feed: The TTY, being a typewriter, needed to move the
carriage (containing a "printwheel") back to the start of the line, then to
do a Line Feed to print on a new line (the paper was a roll of paper, not
cut sheet paper, like all Telex machines).
(Inside the TTY, you can set the number of lines of a page: the standard is
66 lines for a "Form Feed".) (You cannot change the 72 columns of text,
however.)
"the Null device": inside the TTY, there is a device used to ask,
automatically, the "name" of the receiving TTY (see the control codes of
ASCII). Most companies were putting their names into this device. It is a
cylinder with 40 rows of 8 "spikes". According to the way you break those
spikes, you get a 40 bytes message. That why the default is 40 null bytes
(00H): this was the standard cylinder sent by a TTY right from factory, with
its "null device" intact.
names of devices: RDR, PUNCH: on the left side of the TTY, there are (most
of the time: there were almost hundreds of models of TTY) a tool used to
punch and read "holes" in a paper tape. Why paper? Because there were no
magnetic storage at that time. When the Telex was developed, it was an
improvement on Morse punchers, themselves an improvement on "audio only"
Morse machines which needed an operator at all time. With a paper tape, all
you had to do was collect the tape from time to time. Telex added a
typewriter to this tape. Those paper tapes were the standard for storing
messages, and later "programs": for instance, the first time that Gary
Kildall and John Torode booted CP/M, it was from a paper tape reader! (The
software had been developed on IBM mainframes and DEC mini-computers.) (A
remark about the standard devices of CP/M: all 5 correspond to the functions
of a TTY: CONIN (keyboard), CONOUT (message printed on the TTY), RDR (the
paper tape reader, later AUXIN), PUN (the paper tape punch, later AUXOUT),
and PRN (you could plug a better quality printer, and keep the TTY for
commands). Notice also how different from Unix "standard input" and
"standard ouput" those devices are. Unix was designed for automatic batch
processing, CP/M is designed to be used interactively, with at least those 5
"logical devices" available.)
Also, the "Intel Hex file format" was directly done to be readable by a TTY.
Finally, I am thinking to "the bell". There is, indeed, a REAL bell (like
those used at front doors in my youth) inside the TTY!
Well, this is already a long message.
Hope this information will have helped you to understand "Good Old" CP/M.
Yours Sincerely,
"French Lurker"
Harold Bower
It is now 'officially' started. I have transferred the pertinent files
into a DOS partition on my main Linux box (after formally converting my
house to a 'Windows-Free' zone) and am beginning to edit the files to
include the GPL clauses. It is slow going because I am trying to
include the latest versions, manual changes, etc. If there is someone
who can host the files, I am planning on the following groupings in
order (release may be slow...):
1. Printable .TXT version of the manual
2. Executable support routines (.COM files for config, tailoring,
utilities, etc - generic)
3. BIOS source versions (individual by version) for:
P112
YASBEC (with extra files for YASMIO and FDC mod in TCJ)
MicroMint SB-180
MicroMint SB-180FX
Ampro Little Board
4. Source for banked ZSDOS2 (including directory hashing for speed) and
clock drivers (courtesy of Bridger Mitchell and his DateStamper
contribution)
5. Source for ZCPR 4.x (courtesy of Jay Sage with RCP extras
integrated)
6. Source for support routines
I am planning on using the DOS .ZIP structure, although I would prefer
the compressed CP/M libraries but anticipate that some might not be able
to extract the necessary to build systems in the first place.
Let me go out on a limb (and maybe get my stuff in gear...finally) by
committing to have the text version of the manual ready (if my venerable
Wordstar7 is up to it) by the end of April. Is there anyone willing to
receive big mail attachments and host the files?
Hal
Juha Laiho
>Juha wrote:
>
>> Hmm.. if I recall correctly, the list of BDOS functions was rather
>> sparse, so hardware-dependent coding was somewhat hard to avoid.
>>
>> As examples that I think were missing (please correct, if needed):
>> - control of the serial port (speed, parity, bit rate)
>> - standardised interface for talking to cursor-addressable terminals
>> (i.e. calls for "clear screen", "set cursor position", and the like)
>
>written by Gary Kildall and computer magazines reviewers, I can give you the
>following explanations:
Thank you -- and for the others who commented on my article.
Some of what you wrote was already familiar for me, but not all.
Like, yes, I have an understanding what the computing world was like
at the time when CP/M appeared. My comment was just to emphasize that
on "current" CP/M systems there are areas where hardware-dependent
coding cannot be avoided, beause there is no API to use. The API does
not necessarily need to be part of the OS kernel (forgive me for talking
in Unix terms; I grew up with CP/M, but have not seen a CP/M machine in
quite a while now), and can still be considered to be a standard API of
the OS (like termcap in Unix).
>2) All your "examples of things that were missing" assume that you are using
>a screen... but the screen became a common device only about 2 or 3 years
>AFTER the development of CP/M.
... APIs can be developed afterwards, too, if needs arise (GSX, anyone?).
If sticking to plain disk operations, then hardware-dependent coding is
not needed, but outside that, need for hw-dep. coding raises its ugly head,
so I still keep my opinion that CP/M somewhat lacks APIs -- even for the
later parts of its own era.
>Many things still used today (for example in MS-DOS and Linux) are, in fact,
>the way they are BECAUSE they could only be done a particular way on the TTY
>(the common abbreviation (there were lots of abbreviations in Telex
>messages) for the Teletype: see the list of "control codes" of the
>US-ASCII).
>
>Right now, without any written doc, I am thinking about:
>uppercase letters for filename: because the cheapest model of TTY had only
>uppercase letters... (The 8+3 filename convention was used by DEC computers:
Yep, it isn't long ago I spent some time explaining a colleague why
he could not have uppercase login names on Unix systems (traditionally
behaving Unixes will switch to all-upcase output seeing an upcase
login name), for the abovementioned reason. Apparently Linux has broken
this tradition, but at least HP-UX still works "the old way".
>"the Null device": inside the TTY, there is a device used to ask,
>automatically, the "name" of the receiving TTY (see the control codes of
>ASCII). Most companies were putting their names into this device. It is a
>cylinder with 40 rows of 8 "spikes". According to the way you break those
>spikes, you get a 40 bytes message. That why the default is 40 null bytes
>(00H): this was the standard cylinder sent by a TTY right from factory, with
>its "null device" intact.
... now, this was something completely new -- and also something I hadn't
properly thought of.
>Notice also how different from Unix "standard input" and
>"standard ouput" those devices are. Unix was designed for automatic batch
>processing, CP/M is designed to be used interactively, with at least those 5
>"logical devices" available.)
Hmm.. certainly interesting point -- and seemingly sensible. Again,
thank you.
About paper terminals.. it certainly was an experience to play "moria"
on a DecWriter IV - but it did work..
Clarence Wilkerson
source files for BIOS's etc for the classics? I have
the Heathkit bios source on my homepage, for example.
I believe I heard of a project to archive the binary contents
of eproms on these, to protect against bitrot.
--
Clarence Wilkerson \ HomePage: http://www.math.purdue.edu/~wilker
Prof. of Math. \ Internet: wil...@math.purdue.edu
Dept. of Mathematics \ Messages: (765) 494-1903, FAX 494-0548
Purdue University, \
W. Lafayette, IN 47907-1395 \
@robase, Salle multimédia
Re-reading my message, I am struck by the fact that I forgot 2 things:
1) the US-ASCII 7-bit codes were taken from the ASR-33 TTY
(the control codes abbreviations are coming from Telex)
2) one "graphics character" is different: On the TTY, there is a
"left arrow" which became "underline" in ASCII.
Well, I hope that I have not forgotten any other thing too obvious.
(Since I use BASIC, I can also say that the line editor commands
were designed to move a "printwheel" carriage. It is also the reason
for using "PRINT" to get output on the screen! An older Programming
Language called FOCAL (FOrmula CALculator) which was used
from the 1965s to the 1975s on DEC PDP-8s used the command
"DISPLAY" (because it used a CRT tube, not a TTY which really
PRINTed on roll paper)...)
Yours Sincerely,
"French Lurker"
CBFalconer
>
> Re-reading my message, I am struck by the fact that I forgot 2 things:
>
> 1) the US-ASCII 7-bit codes were taken from the ASR-33 TTY
> (the control codes abbreviations are coming from Telex)
>
> 2) one "graphics character" is different: On the TTY, there is a
> "left arrow" which became "underline" in ASCII.
The sequence cr,lf is done because it took time for the carriage
to move left, allowed for by the lf action. If reversed (to
lf,cr) the next character would print somewhere in the middle of
the line on the fly, depending on how far right the carriage had
been.
Also a standard prompting sequence was:
cr,lf,dc1 (dc1 also known as xon)
which turned on the tape reader to gobble another record from
tape. If the record ended with "dc3, cr, lf" (dc3 also known as
xoff) the echoing action would turn off the reader just after the
lf.
Similarly dc2 and dc4 turned the punch on and off. By outputting
only non-printing characters to the punch, terminated by a double
rub-out (dc4, rub, rub) (rub = 0xff) you could find a set of 16
characters with unique lower 4 bits, and this allowed transparent
binary tape punching in the midst of a listing. The double rub
made a useful inter-record marker on the tape, and could be used
for fan-folding (about twice, then rip and get the splicing tape).
End of "How to use an ASR33 for all your i/o needs". Next chapter
"Frolicing in tape punch chads"
Hector Peraza
> (Since I use BASIC, I can also say that the line editor commands
> were designed to move a "printwheel" carriage. It is also the reason
> for using "PRINT" to get output on the screen! An older Programming
> Language called FOCAL (FOrmula CALculator) which was used
> from the 1965s to the 1975s on DEC PDP-8s used the command
> "DISPLAY" (because it used a CRT tube, not a TTY which really
> PRINTed on roll paper)...)
Hmmm... wasn't it "TYPE" instead (or just "T")? IIRC FOCAL was
quite TTY-oriented too...
Hector.
Paul Williams
>
> 2) one "graphics character" is different: On the TTY, there is a
> "left arrow" which became "underline" in ASCII.
Not until later. The original ASCII standard, X3.4-1963, has the "up
arrow" and "left arrow" characters.
Charles Richmond
>
> "@robase, Salle multimédia" wrote:
> >
> > Re-reading my message, I am struck by the fact that I forgot 2 things:
> >
> > 1) the US-ASCII 7-bit codes were taken from the ASR-33 TTY
> > (the control codes abbreviations are coming from Telex)
> >
> > 2) one "graphics character" is different: On the TTY, there is a
> > "left arrow" which became "underline" in ASCII.
>
> The sequence cr,lf is done because it took time for the carriage
> to move left, allowed for by the lf action. If reversed (to
> lf,cr) the next character would print somewhere in the middle of
> the line on the fly, depending on how far right the carriage had
> been.
>
characters that needed to be send to the mechanical terminal
*after* the cr/lf... IIRC, these were NUL characters and gave
the mechanism time to complete the carriage return before the
program resumed sending actual data to print.
@robase, Salle multimédia
CBFalconer <cbfal...@my-deja.com> a écrit dans le message :
3AD4686E...@my-deja.com...
Charles,
Thanks for a very knowledgeable addenda.
Also, it can be said that most people using paper tapes were punching
40 null (00H) bytes before and after the program sent by using the
"Null device". This way, the pattern was easily viewed (providing the
begin and the end). (Most people prefered to fold the tape, so as not
to add a cylinder to roll it).
I have heard talks that magnetic media was weakening over time...
Well, paper is well-known to last quite a long time!
(The oldest books known for sure are about 1,000 years old.)
(Also, during the war, Zuse punched old movie rolls which are,
of course, stronger than paper.)
Yours Sincerely,
"French Lurker"
@robase, Salle multimédia
Charles Richmond <rich...@ev1.net> a écrit dans le message :
3AD5E844...@ev1.net...
Yes, at the beginning, you had to "install" your system so that the
terminal would receive characters correctly. Sometimes, it was
done at the level of the OS, sometimes it was done inside the
program. Example: TDL 12K BASIC had a "NULL" command
which allowed to change the number of nulls sent.
Yours Sincerely,
"French Lurker"
@robase, Salle multimédia
Paul Williams <f...@uk.thalesgroup.com> a écrit dans le message :
3AD47902...@uk.thalesgroup.com...
Paul,
I trust you. I only have a later copy of the ASCII standard.
Yours Sincerely,
"French Lurker"
@robase, Salle multimédia
"a tape reader & writer"?
0010 REM"MBFSHL.ATR: A TAPE READER & WRITER
0020 BEGIN
0200 INPUT (0,ERR=200)'CS',"COLUMBIA UNIVERISITY KERMIT TAPE READER AND
WRITE
0200:R",'LF',"(R)ead,(W)rite? ",'CI',X$; IF CTL>1 GOTO 9000
0210 ON INT((POS(X$="RrWw")+1)/2) GOTO 200,800,600
0599 REM"WRITE A TAPE
0600 INPUT"WRITE A TAPE TO SEND TO COLUMBIA UNIVERSITY",'LF',"ENTER FILE
NAME
0600: ",IFILE$;IF CTL>1 CLOSE(3,IND=9);GOTO 9000
0610 CLOSE(4);OPEN(4,ERR=600)IFILE$
0615 FID4$=FID(4); IF ASC(FID4$(10))=4 CLOSE(4);LISTPROGRAM
IFILE$,"TEMP";OPE
0615:N(4)"TEMP" ELSE IF ASC(FID4$(10))>1 GOTO 600
0620 CLOSE(3);OPEN(3)"R0"
0625 IFILE=IFILE+1
0630 IF IFILE=1 CLOSE(3);OPEN(3,SEQ=0)"R0";DIM
OUT$(80);OUT$(1)="VOL1KERMIT";
0630:WRITERECORD(3,TBL=9950)OUT$;CLOSE(3);OPEN(3)"R0"
0640 DIM
OUT$(80);OUT$(1)="HDR1",OUT$(5)=IFILE$,OUT$(22)="KERMIT0001"+STR(IFI
0640:LE:"0000")+"000100 88010 88010 000000"
0650 WRITERECORD(3,TBL=9950)OUT$;CLOSE(3);OPEN(3)"R0"
0660 OUT$(1)="HDR2D0819200300",OUT$(50)="00"
0670 WRITERECORD(3,TBL=9950)OUT$;CLOSE(3);OPEN(3)"R0"
0680 DIM OUT$(8192),OUT0$(0)
0690 READ(4,END=720)R$
0700 A=LEN(R$);IF LEN(OUT0$)+4+A>8192 WRITERECORD(3,TBL=9950)OUT0$;OUT0$=""
F
0700:I; OUT0$=OUT0$+STR(A+4:"0000")+R$;GOTO 690
0720 IF OUT0$>"" WRITERECORD(3,TBL=9950)OUT0$
0730 OUT0$=""
0740 DIM
OUT$(80);OUT$(1)="EOF1"+IFILE$,OUT$(22)="KERMIT0001"+STR(IFILE:"0000
0740:")+"000100 88010 88010
000000";CLOSE(3);OPEN(3)"R0";WRITERECORD(3,TBL=99
0740:50)OUT$
0750
OUT$(1)="EOF2D0819200300";CLOSE(3);OPEN(3)"R0";WRITERECORD(3,TBL=9950)OU
0750:T$
0760 PRINT "END OF FILE ",IFILE$,"..",IFILE
0770 GOTO 600
0799 REM"READ FROM TAPE
0800 INPUT "READ COLUMBIA UNIVERSITY TAPE",'LF',"ENTER STARTING SEQUENCE #
",
0800:SEQ0;IF CTL>1 GOTO 9000
0805 INPUT "ENTER OUTPUT DEVICE/FILE ",OFILE$;IF OFILE$>""
CLOSE(1);OPEN(1)OF
0805:ILE$;LOCK(1,ERR=806) ELSE GOTO 800
0810 CLOSE(3);FLAGP$="";OPEN(3,SEQ=SEQ0)"R0"
0820 DIM R$(8192);READRECORD(3,END=900,TBL=9960)R$
0825 FLAGP$="FOUND"
0829 IF R$(1,4)="VOL1" PRINT (1)R$
0830 IF POS(R$(1,4)="VOL1HDR1HDR2EOF1EOF2",4)>0 PRINT R$;IF R$(1,4)<>"HDR1"
G
0830:OTO 820 ELSE B$=R$,FLAG$="",OP1$="";PRINT SEQ0,;INPUT "..CR TO
CONTINUE,
0830: CTL III=HARDCOPY IT, CTL II TO SKIP ",'CI',*;L=0;IF CTL=2 OP1$="NEXT"
E
0830:LSE IF CTL=3 FLAG$="PRINT";PRINT(1)R$; FI; GOTO 820
0840 IF OP0$>"" IF POS(OP0$=B$)<>5 GOTO 900
0850 IF OP1$="NEXT" GOTO 900
0860 A=NUM(R$(1,4)),A$=R$(1,A);PRINT A$;IF FLAG$="PRINT" PRINT (1)A$(5)
0870 R$=R$(A+1)
0880 L=L+1;IF L>20 IF FLAG$="" INPUT "CR TO CONTINUE,CTL II TO SKIP,CTL III
T
0880:O HARDOPY IT ",'CI',*;L=0;IF CTL=2 OP1$="NEXT";GOTO 900 ELSE IF CTL=3
IF
0880: FLAG$="" FLAG$="PRINT";CLOSE(3);OPEN(3,SEQ=SEQ0)"R0";GOTO 820
0890 IF LEN(R$)>3 GOTO 860
0895 GOTO 820
0900 IF ERR=2 IF FLAGP$="" GOTO 950
0901 IF ERR=5 RETRY ELSE IF ERR<>2 ESCAPE
0905 SEQ0=SEQ0+1,FLAGP$=""
0910 CLOSE(3)
0920 OPEN(3,ERR=950)"R0"
0930 GOTO 820
0950 PRINT "END OF TAPE"
0960 GOTO 800
9949 REM CONVERSION TABLE: B4 ASCII TO STANDARD ASCII
9950 TABLE
7F000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F
9950:202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F4041424
3
9950:4445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666
7
9950:68696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F
9959 REM CONVERSION TABLE: STANDARD ASCII TO B4 ASCII
9960 TABLE
7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9F
9960:A0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C
3
9960:C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E
7
9960:E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
16000 END
CBFalconer
>
> Paul Williams <f...@uk.thalesgroup.com> a écrit dans le message :
> 3AD47902...@uk.thalesgroup.com...
> "@robase, Salle multimédia" wrote:
> >
> > 2) one "graphics character" is different: On the TTY, there is a
> > "left arrow" which became "underline" in ASCII.
>
> Not until later. The original ASCII standard, X3.4-1963, has the "up
> arrow" and "left arrow" characters.
>
BTW, I did get your e-mail and responded. Get yourself a free
e-mail address, yahoo is a viable possibility. e-mail does NOT
belong in newsgroups. If you have a browser you can have an
e-mail address.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> I have heard talks that magnetic media was weakening over time...
> Well, paper is well-known to last quite a long time!
> (The oldest books known for sure are about 1,000 years old.)
> (Also, during the war, Zuse punched old movie rolls which are,
> of course, stronger than paper.)
>
disintegrate in 30 or 40 years. It only costs a little more to make
non-acidic paper, and some book publishers (notably Academic Press)
have been using this.
As for Zuse's old movie film rolls, I fear that most of that was
destroyed in the bombing of Berlin in WWII. Also, much old movie
film was *not* made of acetate, but nitrate...which is *very*
flamable, and I believe *does* disintegrate over time... This is
why fire in a movie theater was considered *so* disasterous. If
the fire reached the place where the films are stored, KA-BOOM!!!
Arndt Oevermann
> Not until later. The original ASCII
> standard, X3.4-1963, has the "up
> arrow" and "left arrow" characters.
It sounds like as similar as the PETSCII from CBM. These characters are
a component of PETSCII instead of caret and underline.
Servus
Arndt
... QWKRR128 - Read 'n' Reply offline with a C=128
___ QWKRR128 V5.10 [R]
Jack Crenshaw
what it's worth.
Neither system, IMO, can claim very impressive lineage. CP/M, as so
many have pointed out,
was developed as a "first" system for floppy disks. I don't think
Kildall ever intended for it to
become the ne plus ultra of OS's. It had the minimum of services
needed to function, that's all.
Unix was developed as a clone of Multics, which was a time-share
system started ca. 1964. Its
heritage (and, to a large part, its structure) is considerably older
than that of CP/M.
_BOTH_ systems were originally designed to work with TTY's and other
printing terminals. That's
why the Unix command line is so terse. It's a credit to both the
design of both systems, and the
ingenuity of those folks who worked with them, that both systems
evolved so far from their
original roots.
CP/M's biggest failing is that it was never intended to support
multitasking. The hardware of the
day didn't support it, either. Nowadays, I think no one would be
satisfied with an OS that didn't
at least support foreground/background tasking. We've talked before
here about Borland's
Modula 2, which very much _DID_ provide a multitasking structure, so
it could be done, but it
was very difficult.
Unix's biggest failing is that it was designed for multi-user
timeshare, and therefore has too _MUCH_
support for multitasking. By that I mean, it is designed around the
concept of multiple users, each'
with his own password, login mechanism, and cost accounting/billing
structure. That kind of thing
is _NOT_ either required or wanted for a desktop system.
Unix's second biggest failing is that it was adopted with open arms by
the C-hacker/guru bunch,
whose motto is, "Never do something the straightforward way when you
can make it obscure."
Having worked with Unix wizards back in the 80's, I can tell you that
there is a certain mystique, a
certain "fraternity" taste to it, that IMO detracts radically from its
usefulness. You end up with
tools that are mostly undocumented, commands that have obscure and
inscrutable names and
command argument structures, and users who are not only proud of that,
but work to keep it that
way. The dictum "read the man page" doesn't do much good if the man
page is incomplete or
doesn't describe the true function. As someone trying to use the
system as a tool, not as an ego
extension, I can't tell you how many times I had to just try things by
trial and error, until I got
something to work. One of the things I discovered about the gurus is
that they know surprisingly
little about the entire system; they tend to only work with one part
of it, and are clueless of the
other parts.
Unfortunately, universities tend to use Unix almost exclusively, teach
OS design using Unix (now
Linux) code as examples, and teach compiler theory out of the Dragon
book. The end result is
that, today, systems programmers come out of school with very little
understanding that there
are _OTHER_ ways to write an OS, besides the Unix way.
For the record, I'm a big supporter of Linux, and am doing my part to
help it replace Windoze.
But I don't think anyone should delude themselves that Linux is some
kind of perfect OS. It
still retains that 1964 architecture.
Look, in the end, an OS is not exactly rocket science. Its only
function is to manage the resources
of the system so that the user does _NOT_ have to bit-twiddle the
hardware to get things done.
In the days when both CP/M and Unix were conceived, this management
meant only a few OS
functions: Open a file, close a file, read a file, write a file, read
a character from the keyboard,
write a character to the screen. That's about it. Oh, yeah ... print
and erase. CP/M does those
functions admirably.
Neither the designers of CP/M or Unix envisioned CRT-based user
interfaces, much less pixel
graphics and mice. With the advent of such devices, the OS has to
manage them too, and face it:
the mechanisms to do so, on both systems, are kludge upon kludge upon
kludge. See the termcap
structure for Unix. Writers of screen editors discovered that CP/M
didn't give them fast enough
access to the screen, so they had to write direct hardware access
software that was customized
for the particular hardware in use. Wordstar did that admirably, and
the fact that Wordstar was
adaptable to so many different computers proves that it's not
impossible to do so. An OS service
that managed the screen would have been infinitely better, but I think
one can still make the
argument that having to customize the editor to the CRT is better,
smaller, faster, and more
reliable than the kludgy layers upon layers of interfaces in something
like Windows. Just reading the
PC BIOS code that goes out to check the CRT type and CRT hardware is
enough to give one nausea. And the less said about X, the better.
Re multitasking: There's no reason why one can't have a simple disk
directory structure and still
support M/T. For that matter, Unix/Linux _DOES_ have a relatively
simple disk structure -- a
fairly straightforward extension of the CP/M approach, to support
multiple directories, big drives,
etc.
I said it in 1980 and I'll say it again, 20 years later: The good OS
for microcomputers has not
been written yet. If I were to start from scratch, I'd _BEGIN_ with a
multitasking kernel, not
unlike that of current RTOS's. I'd add a file structure and I/O
structure that provided only the
most basic of functions like read sector, write sector, etc
(essentially the CP/M BIOS). Then
I'd add the remaining layers on top of those basic ones.
One thing the designers of both systems did right: They made the user
interface (the "shell")
a separate module that could be modified, customized, or replaced. If
only Microsoft were
able to figure out how to do that, instead of claiming that the user
interface won't work without
a web browser <!>.
Jack
Darran Kartaschew
"Jack Crenshaw" <jcr...@earthlink.net> wrote in message
news:3ADF90E2...@earthlink.net...
> Ok, here's my own take on the Unix v. CP/M controversy. Take it for
> what it's worth.
> Re multitasking: There's no reason why one can't have a simple disk
> directory structure and still
> support M/T. For that matter, Unix/Linux _DOES_ have a relatively
> simple disk structure -- a
> fairly straightforward extension of the CP/M approach, to support
> multiple directories, big drives,
> etc.
>
> I said it in 1980 and I'll say it again, 20 years later: The good OS
> for microcomputers has not
> been written yet. If I were to start from scratch, I'd _BEGIN_ with a
> multitasking kernel, not
> unlike that of current RTOS's. I'd add a file structure and I/O
> structure that provided only the
> most basic of functions like read sector, write sector, etc
> (essentially the CP/M BIOS). Then
> I'd add the remaining layers on top of those basic ones.
What ever happened to MP/M II development?
Chewy509
@robase, Salle multimédia
Darran Kartaschew <chew...@ozemail.com.au> a écrit dans le message :
PSOD6.4961$EQ3.1...@ozemail.com.au...
>
> What ever happened to MP/M II development?
>
> Chewy509
>
"Chewy509",
Excuse me, but I had understood that Jack was talking about a single-user OS
providing multi-tasking. And MP/M II (I have the 3 manuals) is a multi-user
multi-tasking OS running on a single Z-80... (In my opinion, this is one of
the most impressive program ever wriiten. I have read that it was possible
to run 8 terminals on a 4 MHz...)
I am not familiar with the history of the various versions of CP/M-86 (whose
genealofy seems to be a zoo), but I think that MP/M II evolved in Concurrent
CP/M, then DOS, then XM, then? (Could someone more knowledgeable write a
summary of the various DRI 16 bit OSes?)
Yours Sincerely,
"French Lurker"
John Elliott
>Neither the designers of CP/M or Unix envisioned CRT-based user
>interfaces, much less pixel
>graphics and mice. With the advent of such devices, the OS has to
>manage them too, and face it:
>the mechanisms to do so, on both systems, are kludge upon kludge upon
>kludge.
There's always Plan9 :-)
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Richard Plinston
> Excuse me, but I had understood that Jack was talking about a single-user OS
> providing multi-tasking. And MP/M II (I have the 3 manuals) is a multi-user
> multi-tasking OS running on a single Z-80...
You don't _have_ to use more than one terminal, you can run it as a
single-user system and multi-task. It is not as effective as
Concurrent- though as the multiple tasks as not separated on the screen,
their output may become mixed.
> (In my opinion, this is one of
> the most impressive program ever wriiten. I have read that it was possible
> to run 8 terminals on a 4 MHz...)
I have an old ICL Model 35, 8085AH2 at 5MHz, that used to run 4 users
with a Cobol accounting system on MP/M II.
> I am not familiar with the history of the various versions of CP/M-86 (whose
> genealofy seems to be a zoo), but I think that MP/M II evolved in Concurrent
> CP/M, then DOS, then XM, then? (Could someone more knowledgeable write a
> summary of the various DRI 16 bit OSes?)
MP/M 1978
MP/M II 1980(?)
MP/M-86 October 1981
MP/M-8/16 mid 1982
Concurrent-CP/M-86 September 1982
Concurrent-DOS (CCP/M 3.2) September 1984
DOS Plus Built from CDOS source tree
1986
Concurrent-PC-DOS (4.x) (?)
DR-DOS 3.4x Built from CDOS source tree
June 1988
Concurrent-DOS XM (5.x) (?) XM used eXtended Memory
Concurrent-DOS (6.x) IBM PC only, used EEMS memory (eg RamPage)
DR-DOS 5 built from CDOS source tree
May 1990
Concurrent-DOS-386 Issue 1 was equivalent to CDOS 6.0,
Issue 2==6.1 (Nov 1987). Issue 3==6.2
DR-Multiuser-DOS 5 CDOS-386 issue 5 renamed because of DR-DOS 5
DR-DOS 6 Departed somewhat from CDOS/DR-MDOS
Aug 1991
DR-Multiuser-DOS 5.1 March 1992
NW-DOS 7 Novell's rewrite
Nov 1993
CCI Gold }
Datapac System Manager } VAR and OEM versions
IMS Real/32 } of CDOS and DR-MDOS
DougDOS }
etc }
Jack Crenshaw
> Excuse me, but I had understood that Jack was talking about a single-user OS
> providing multi-tasking. And MP/M II (I have the 3 manuals) is a multi-user
> multi-tasking OS running on a single Z-80... (In my opinion, this is one of
> the most impressive program ever wriiten. I have read that it was possible
> to run 8 terminals on a 4 MHz...)
>
> I am not familiar with the history of the various versions of CP/M-86 (whose
> genealofy seems to be a zoo), but I think that MP/M II evolved in Concurrent
> CP/M, then DOS, then XM, then? (Could someone more knowledgeable write a
> summary of the various DRI 16 bit OSes?)
MP/M II didn't evolve into DOS, except in the sense that the guys who wrote DOS
(Seattle Software?) copied the CP/M call structure. MP/M became Concurrent
DOS, which became DRDOS, which is the OS that Microsoft shot down using all
kinds of nefarious strategies. That's what originally got them in hot water
with the
antitrust division.
When the PC first came out, you had your choice of PCDOS (later MSDOS),
CP/M 86, or UCSD Pascal. Because PCDOS was much cheaper (free?), most
folks chose it. I don't think CP/M 86 ever worked very well.
If we ended up stuck with MSDOS and such lovely utilities as EDLIN, we have
only ourselves to blame. We had other options.
Well, strike that. _YOU_ guys have only yourselves to blame. I was sticking
with
CP/M at the time <g>.
Jack
Russell Marks
[wrapped]
> Re multitasking: There's no reason why one can't have a simple disk
> directory structure and still support M/T. For that matter,
> Unix/Linux _DOES_ have a relatively simple disk structure -- a
> fairly straightforward extension of the CP/M approach, to support
A straightforward extension of CP/M's approach? You *do* know about
the whole inode thing, right? :-)
(You could also wonder about the timeline-bending I suspect is
required for Unix's approach to be an extension of CP/M's, but I'll
gloss over that.)
-Rus.
Harold F. Bower
[snip]
> only ourselves to blame. We had other options.
>
> Well, strike that. _YOU_ guys have only yourselves to blame. I was sticking
> with
> CP/M at the time <g>.
You're not alone, Jack. I stuck with CP/M (actually Cam Cotrill's and
my ZSDOS) until well after Al Hawley's BBS closed and then some. MSDOS
here was only used (with WordStar 5 and 7) to do the manuals. My
daughters even used CP/M with Wordstar (4) to do their school papers
into the mid-90s.
Hal
Walter Rottenkolber
Jack Crenshaw wrote in message <3AE17DCA...@earthlink.net>...
>"@robase, Salle multimédia" wrote:
>
>MP/M II didn't evolve into DOS, except in the sense that the guys who wrote
DOS
>(Seattle Software?) copied the CP/M call structure. MP/M became Concurrent
>DOS, which became DRDOS, which is the OS that Microsoft shot down using all
>kinds of nefarious strategies. That's what originally got them in hot
water
>with the
>antitrust division.
>
>When the PC first came out, you had your choice of PCDOS (later MSDOS),
>CP/M 86, or UCSD Pascal. Because PCDOS was much cheaper (free?), most
>folks chose it. I don't think CP/M 86 ever worked very well.
>
>If we ended up stuck with MSDOS and such lovely utilities as EDLIN, we have
>only ourselves to blame. We had other options.
>
>Well, strike that. _YOU_ guys have only yourselves to blame. I was
sticking
>with
>CP/M at the time <g>.
>
Stuck with my Kaypro II (modified to 5 MHz.) until three years ago when I
bought a Pc so I could surf the Web. Even so, my Pc, a P II at 233 MHz., now
qualifies as a noble part of my obsolete computer collection.
Walter Rottenkolber
Paul Schlyter
Jack Crenshaw <jcr...@earthlink.net> wrote:
> When the PC first came out, you had your choice of PCDOS (later MSDOS),
> CP/M 86, or UCSD Pascal. Because PCDOS was much cheaper (free?), most
> folks chose it. I don't think CP/M 86 ever worked very well.
>
> If we ended up stuck with MSDOS and such lovely utilities as EDLIN, we
> have only ourselves to blame. We had other options.
>
> Well, strike that. _YOU_ guys have only yourselves to blame. I was
> sticking with CP/M at the time <g>.
the lovely CP/M utility ED ......
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
anon...@bogus_address.con
On 2001-04-22 pau...@saaf.se (Paul Schlyter) said:
>I'm not a big fan of EDLIN, but it certainly was an improvement
>over the lovely CP/M utility ED ......
Heh! Yeah. Isn't ED wonderful? ;) Uff da.
Fortunately, we can write a small text file under CP/M
by doing this:
PIP myfile.txt=CON:
Steve
Then remember (for newbies), you have to close it with ^Z.
-Steve
--
-Steve Walz rst...@armory.com ftp://ftp.armory.com/pub/user/rstevew
-Electronics Site!! 1000 Files/50 Dirs!! http://www.armory.com/~rstevew
Europe Naples, Italy: ftp://ftp.unina.it/pub/electronics/ftp.armory.com
Jack Crenshaw
Do you think we'll _EVER_ get shed of @#@#$ Windoze??? Yesterday, my system
(running Mathcad) must have crashed five or six times, losing everything I hadn't
saved,
each time. I had to reboot twice. The third time, I gave up and went home. Bah!
Someone asked me once, how many times I had corrupted disks back when I was using
CP/M. Answer: _ZERO_, except for one case where the disk was so old, the oxide
layer was peeling off. Ask me how many times Wordstar failed to do exactly what
it
was told to do.
Whenever I had a crash or anything else bizarre using either my Kaypro CP/M
machine,
or its predecessor, a TRS-80 (Level 1), I figured it must surely be a hardware
failure.
And indeed it was -- both times. We would _NEVER_ have tolerated software that
crashed, much less the OS.
The worst part about Windoze, IMO, is that we're bringing up a whole generation of
programmers who think that crashes are inevitable, sort of like hurricanes or the
flu.
Jack
Jack Crenshaw
> Stuck with my Kaypro II (modified to 5 MHz.) until three years ago when I
> bought a Pc so I could surf the Web. Even so, my Pc, a P II at 233 MHz., now
> qualifies as a noble part of my obsolete computer collection.
Good for you, Walter. And I'll bet you're happier for it, too.
I promised myself, long ago, that if Zilog ever came out with a 20MHz Z80, I was
going back to CP/M. Now they have. Maybe I should.
Now, though, I've got a new dream: Build the world's fastest CP/M, for my
533 MHz DEC Alpha <g>.
Jack
Jack Crenshaw
> I'm not a big fan of EDLIN, but it certainly was an improvement over
> the lovely CP/M utility ED ......
How can you say that? It _WAS_ Ed, for all practical purposes. The only
thing
different, that I can think of, was the fact that you didn't have to manually
load the
next block of text.
Jack
Jack Crenshaw
> Jack Crenshaw <jcr...@earthlink.net> wrote:
>
> [wrapped]
> > Re multitasking: There's no reason why one can't have a simple disk
> > directory structure and still support M/T. For that matter,
> > Unix/Linux _DOES_ have a relatively simple disk structure -- a
> > fairly straightforward extension of the CP/M approach, to support
>
> A straightforward extension of CP/M's approach? You *do* know about
> the whole inode thing, right? :-)
Yep. Consider: The Unix root directory has a fixed number of entries.
So did
CP/M. The (base-level) entries have a fixed number of segments. Ditto
for CP/M.
Disk blocks are accessed by block number. Ditto for CP/M. The only
difference,
really (and it is, admittedly, a big one) is that Unix allows a bit flag
to support indirect
addressing. That's how it supports multiple directories and infinitely
large files. It still
strikes me that the two have a lot more in common than Unix and the
horrors of
FAT. As a matter of fact, one could extend CP/M very easily to support
multiple
levels of indirection, using a single unused bit in each block entry.
IOW, each entry in the CP/M FCB becomes an inode with a single bit
change.
Back in the 70's, many minicomputers used a similar mechanism for
indirect jumps
and other memory accesses. Most of them didn't have 64K of RAM, so the
high
bit of the address was unused. Any instruction encountering an address
with high
bit set, took this as an indirect access. It would go bouncing through
RAM, inode-
style, until it found an address without that bit set. See?
> (You could also wonder about the timeline-bending I suspect is
> required for Unix's approach to be an extension of CP/M's, but I'll
> gloss over that.)
I can't comment on that, because I don't know where Gary Kildall got his
idea from.
I think it safe to say that both systems are about as simple and obvious
as they can be, and it's
not necessary to assume that either designer stole from the other.
Jack
Bill Haygood
> "Harold F. Bower" wrote:
>> My daughters even used CP/M with Wordstar (4) to do their school papers
>> into the mid-90s.
I *continue* to use WS4 running on my own z80a emulator (which runs at
just under 90 MHz on my 550 MHz dual Pentium III Caldera OpenLinux
system). I like WS4's ability to move a block of text to the *right*
of another text.
> Do you think we'll _EVER_ get shed of @#@#$ Windoze??? Yesterday, my
> system (running Mathcad) must have crashed five or six times, losing
> everything I hadn't saved, each time. I had to reboot twice. The third
> time, I gave up and went home. Bah!
> The worst part about Windoze, IMO, is that we're bringing up a whole
> generation of programmers who think that crashes are inevitable, sort
> of like hurricanes or the flu.
I agree. I have run some flavor of Linux since August of 1996 and have
yet to see it crash. It probably happens occassionally, but not yet to
me. I now have four machines (5 Pentium CPUs and 1 Celeron) on a home
LAN running "seti@home" all under Caldera OpenLinux. The two dual
processor machines have now run continuously, without a reboot, for 177
days, 12 hours, 54 minutes. Together, the 6 CPUs crank out a minimum of
10 seti@home work units per day.
IMO, an OS crash should happen so infrequently that it should not just
surprise, but rather, astonish.
On those rare occassions when I need to run Win98, I bring it up under
Linux using VMWare. That way, I have both OSes running similtaneously
on the same machine.
During my three years at DRI as a programmer, I owned a Cromemco dual
processor machine (MC 68000 + Z80A). One could switch between CPUs by
issuing a special IOT instruction. **Immediately** after one issued
that instruction, the previous CPU turned off and the new CPU turned
on. So, you had to have code for the new processor ready to execute.
The execution point picked up just after the last instruction executed
by this same CPU when it stopped previously. Since the MC 68000 had
big endian architecture and the Z80A had little endian, it made for
some interesting situations in building code by one CPU for the other
CPU in light of the fact that they both used the same memory address
space. The MC 68000 CPU ran at 8 MHz and the Z80A at 4 MHz; so, I
implemented CP/M-68K for the MC 68000. Under CP/M-68K, I wrote a
program called "z80" which used the MC 68000 BDOS to load a CP/M-80
file, then switched to the Z80A processor for execution (this meant
that I did not have to "emulate" the Z80A). When the "z80" program
initialized, it would insert some special code into the BDOS so
that when the executing Z80A program made a CP/M-80 system call, it
would switch processors and have the MC 68000 CPU execute the system
call under CP/M-68K at 8 MHz. At the conclusion of the system call,
the MC 68000 processor would execute the special IOT causing a switch
back to the Z80A processor. This may sound a bit obtuse, but I had a
lot of fun implementing it and it ran blazingly fast (or so it seemed
at the time). Running under CP/M-68K, one would execute a Z80A
program like this:
A>z80 ws filename.asm
To get things bootstrapped, I wrote assembler macros for the Cromemco
Z80 assembler to produce code for execution by the MC 68000 CPU.
Ah, those were the days, my friend; we thought they'd never end...
If you would like the sources to my z80a (note lower case) emulator,
you can ftp them from:
ftp://ftp.haygood.org/pub/z80.tgz
also recommended:
ftp://ftp.haygood.org/pub/zexall.z80.tgz
and/or
fpt://ftp.haygood.org/pub/zexdoc.z80.tgz
These latter files contain the sources for Frank Cringle's Z80 emulator
validation program. The one called ZEXDOC validates a Z80 emulator
and checks the Intel "documented" flags bits. ZEXALL validates a Z80
emulator and checks all the flags bits (even the "undocumented" ones).
All the source files I wrote in C (no assembly code at all). All the
implementation dependent code I put in "loc.c". You need 'tar' to
unpack these files. I have tested the emulator only under Linux, but
with a C compiler, it should compile under W9x as well. A friend at
the University of Washington write the keyboard/monitor routines for
MSDOS in file "loc.c". At every point, I considered the endian issues.
When I moved the sources from my Amiga (a big endian machine) to my
(then new) IBM Aptiva (a little endian machine) in 1996, they compiled
without changing a single line of the more than 70,000 C statements.
The newly compiled code ran properly on the little endian machine.
If you email me, remove the hex.
Best regards,
Bill
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> Do you think we'll _EVER_ get shed of @#@#$ Windoze??? Yesterday, my system
> (running Mathcad) must have crashed five or six times, losing everything I hadn't
> saved, each time. I had to reboot twice. The third time, I gave up and went home. Bah!
>
> Someone asked me once, how many times I had corrupted disks back when I was using
> CP/M. Answer: _ZERO_, except for one case where the disk was so old, the oxide
> layer was peeling off. Ask me how many times Wordstar failed to do exactly what
> it was told to do.
>
> Whenever I had a crash or anything else bizarre using either my Kaypro CP/M
> machine, or its predecessor, a TRS-80 (Level 1), I figured it must surely be a
> hardware failure. And indeed it was -- both times. We would _NEVER_ have
> tolerated software that crashed, much less the OS.
>
> The worst part about Windoze, IMO, is that we're bringing up a whole generation of
> programmers who think that crashes are inevitable, sort of like hurricanes or the
> flu.
>
is buggy as hell!!! (;-))
IMHO, you can be rid of Windoze *now*... A lot of things that people use
Windoze for
can be done with Linux and Staroffice... Can you get a Mathcad that runs
on Linux???
Have you *really* tried to find such a thing??? For being on the
internet, I use a
Macintosh G4...after I deleted all the Micro$uck bloatware off of it...
I worked with a guy who I *know* had to re-install Windoze NT at least *three*
different times... Each time it took the bulk of an afternoon to do
it...*no* useful
work there...
CBFalconer
>
> Russell Marks wrote:
>
> > Jack Crenshaw <jcr...@earthlink.net> wrote:
> >
> > [wrapped]
> > > Re multitasking: There's no reason why one can't have a simple disk
> > > directory structure and still support M/T. For that matter,
> > > Unix/Linux _DOES_ have a relatively simple disk structure -- a
> > > fairly straightforward extension of the CP/M approach, to support
> >
> > A straightforward extension of CP/M's approach? You *do* know about
> > the whole inode thing, right? :-)
>
> Yep. Consider: The Unix root directory has a fixed number of entries.
> So did CP/M. The (base-level) entries have a fixed number of segments.
> Ditto for CP/M. Disk blocks are accessed by block number. Ditto for
> CP/M. The only difference, really (and it is, admittedly, a big one)
> is that Unix allows a bit flag to support indirect addressing. That's
> how it supports multiple directories and infinitely large files. It
> still strikes me that the two have a lot more in common than Unix and
> the horrors of FAT. As a matter of fact, one could extend CP/M very
> easily to support multiple levels of indirection, using a single
> unused bit in each block entry.
I published a CP/M program to do just that - I think it was called
alias. It created access to the original file under a new name,
and marked both entries R/O. It was dangerous in that if either
name was ever deleted you had to be sure to do a reboot
immediately, or blocks would get "cross-linked"
>
> IOW, each entry in the CP/M FCB becomes an inode with a single bit
> change.
>
> Back in the 70's, many minicomputers used a similar mechanism for
> indirect jumps and other memory accesses. Most of them didn't have
> 64K of RAM, so the high bit of the address was unused. Any
> instruction encountering an address with high bit set, took this as
> an indirect access. It would go bouncing through RAM, inode-
> style, until it found an address without that bit set. See?
That also created infinite loop chains, and much cursing.
--
Chuck F (cbfal...@my-deja.com) (cbfal...@XXXXworldnet.att.net)
http://www.qwikpages.com/backstreets/cbfalconer :=(down for now)
Richard Plinston
>
> Yep. Consider: The Unix root directory has a fixed number of entries.
> So did CP/M.
And so has just about every other disk system. The reason for this is
entirely simple: the data blocks must start somewhere and this becomes a
fixed point when data has been written. The reserved area prior to this
(or in some cases located somewhere else) becomes a fixed size.
> The (base-level) entries have a fixed number of segments. Ditto
> for CP/M.
And so has just about every other disk system (FAT has 1).
> Disk blocks are accessed by block number. Ditto for CP/M.
And so is just about every other disk system. In fact can you name one
that doesn't ?
> The only difference, really (and it is, admittedly, a big one)
> is that Unix allows a bit flag to support indirect addressing.
> That's how it supports multiple directories and infinitely
> large files.
Indirect addressing is not done by a 'bit flag' it is done as a
consequence of the inode system.
Indirect addressing has nothing to do with directories. Unix does not
support 'infinately large files', there is a finite limit.
There are many _actual_ differences including the separation of the file
name entry from the disk block entry, the way free space is recorded,
the way blocks are allocated to the file, just about everything really,
except those items which are common to almost all systems.
> It still
> strikes me that the two have a lot more in common than Unix and the
> horrors of FAT.
FAT is just as 'obvious' as others and shares exactly the same 3
criteria you claimed above (and thus is equally identical).
> As a matter of fact, one could extend CP/M very easily to support
> multiple
> levels of indirection, using a single unused bit in each block entry.
>
> IOW, each entry in the CP/M FCB becomes an inode with a single bit
> change.
One could rewrite any system to become some other system.
> Back in the 70's, many minicomputers used a similar mechanism for
> indirect jumps
> and other memory accesses. Most of them didn't have 64K of RAM, so the
> high
> bit of the address was unused. Any instruction encountering an address
> with high
> bit set, took this as an indirect access. It would go bouncing through
> RAM, inode-
> style, until it found an address without that bit set. See?
You appear to misunderstand 'inodes' entirely. What you are describing
is more like FAT.
> > (You could also wonder about the timeline-bending I suspect is
> > required for Unix's approach to be an extension of CP/M's, but I'll
> > gloss over that.)
>
> I can't comment on that, because I don't know where Gary Kildall got his
> idea from.
Certainly Unix (which preceeded CP/M) did not copy from CP/M and 'extend
it'.
> I think it safe to say that both systems are about as simple and obvious
> as they can be, and it's
> not necessary to assume that either designer stole from the other.
And they are both as simple and obvious as many other different systems
(but then _all_ things are 'simple and obvious' once they are
understood).
Kelli Halliburton
news:3ADF90E2...@earthlink.net...
> I said it in 1980 and I'll say it again, 20 years later: The good OS
> for microcomputers has not
> been written yet. If I were to start from scratch, I'd _BEGIN_ with a
> multitasking kernel, not
> unlike that of current RTOS's. I'd add a file structure and I/O
> structure that provided only the
> most basic of functions like read sector, write sector, etc
> (essentially the CP/M BIOS). Then
> I'd add the remaining layers on top of those basic ones.
>
> One thing the designers of both systems did right: They made the user
> interface (the "shell")
> a separate module that could be modified, customized, or replaced. If
> only Microsoft were
> able to figure out how to do that, instead of claiming that the user
> interface won't work without
> a web browser <!>.
Did you ever try the Amiga OS? I'd be interested to hear your comments about
it given your impressive critique above.
Jack Crenshaw
> I *continue* to use WS4 running on my own z80a emulator (which runs at
> just under 90 MHz on my 550 MHz dual Pentium III Caldera OpenLinux
> system). I like WS4's ability to move a block of text to the *right*
> of another text.
Very cool!!!!
> IMO, an OS crash should happen so infrequently that it should not just
> surprise, but rather, astonish.
Bingo!! The fact that a Windows crash doesn't astonish is madness, IMO.
> To get things bootstrapped, I wrote assembler macros for the Cromemco
> Z80 assembler to produce code for execution by the MC 68000 CPU.
>
> Ah, those were the days, my friend; we thought they'd never end...
Yep. FWIW, I have a Peripheral Technology 68000, with 68020 upgrade.
Haven't run it in years, though. I guess Windows _IS_ my fault <g>.
> These latter files contain the sources for Frank Cringle's Z80 emulator
> validation program. The one called ZEXDOC validates a Z80 emulator
> and checks the Intel "documented" flags bits. ZEXALL validates a Z80
> emulator and checks all the flags bits (even the "undocumented" ones).
>
> All the source files I wrote in C (no assembly code at all). All the
> implementation dependent code I put in "loc.c". You need 'tar' to
> unpack these files. I have tested the emulator only under Linux, but
> with a C compiler, it should compile under W9x as well. A friend at
> the University of Washington write the keyboard/monitor routines for
> MSDOS in file "loc.c". At every point, I considered the endian issues.
> When I moved the sources from my Amiga (a big endian machine) to my
> (then new) IBM Aptiva (a little endian machine) in 1996, they compiled
> without changing a single line of the more than 70,000 C statements.
> The newly compiled code ran properly on the little endian machine.
>
> If you email me, remove the hex.
Does anyone have an emulator that runs Kaypro code? I mean, that emulates
the Kaypro system port?
Jack
Jack Crenshaw
> IMHO, you can be rid of Windoze *now*... A lot of things that people use
> Windoze for can be done with Linux and Staroffice...
Unfortunately, at the office I'm stuck with what they give me, which is currently
plain vanilla Win98 (not SE, not even an SR), soon to become <ugh!> Win2000.
At home, I have a dual-boot system with Windows and Linux. I blush to admit that
I have not once booted Linux in six months. It's a matter of inertia. I have to load up
the utes, climb the learning curve, etc. I have a column due every month, and somehow
learning Linux always gets pushed back.
Can we say, "He has only himself to blame"?
> Can you get a Mathcad that runs on Linux???
Hey, I'd settle for a Mathcad that _RUNS_ without error. But the answer, I think, is
no. AFAIK, Mathcad is unique in that it gives math assistance with a GUI interface.
> Have you *really* tried to find such a thing???
Absolutely.
Jack
Jack Crenshaw
> Jack Crenshaw wrote:
> >
> > Yep. Consider: The Unix root directory has a fixed number of entries.
> > So did CP/M.
>
> And so has just about every other disk system. The reason for this is
> entirely simple: the data blocks must start somewhere and this becomes a
> fixed point when data has been written. The reserved area prior to this
> (or in some cases located somewhere else) becomes a fixed size.
Richard, I didn't say it wasn't simple. In fact, I believe I said it was
entirely
obvious.
> > The (base-level) entries have a fixed number of segments. Ditto
> > for CP/M.
>
> And so has just about every other disk system (FAT has 1).
>
> > Disk blocks are accessed by block number. Ditto for CP/M.
>
> And so is just about every other disk system. In fact can you name one
> that doesn't ?
Um ... excuse me, but Russell's claim was that there is no obvious similarity
between CP/M and Unix. Now you seem ready to argue the exact opposite. Why?
> > The only difference, really (and it is, admittedly, a big one)
> > is that Unix allows a bit flag to support indirect addressing.
> > That's how it supports multiple directories and infinitely
> > large files.
>
> Indirect addressing is not done by a 'bit flag' it is done as a
> consequence of the inode system.
Yep. And the system must know whether an i-node points to the beginning
of a file, or another i-node. The way it does so is an implementation detail.
> Indirect addressing has nothing to do with directories. Unix does not
> support 'infinately large files', there is a finite limit.
Are you just looking for an argument, or what? To most folks, the phrase
"infinitely large files" would be perfectly clear, and would be interpreted as
"as large as the available disk space." You have a problem with that?
> > It still
> > strikes me that the two have a lot more in common than Unix and the
> > horrors of FAT.
>
> FAT is just as 'obvious' as others and shares exactly the same 3
> criteria you claimed above (and thus is equally identical).
Wrong again. The FAT is a chained-entry system. Hence the need for Scandisk.
> One could rewrite any system to become some other system.
Now, _THERE'S_ a really helpful statement. Thanks so much for the insight.
> You appear to misunderstand 'inodes' entirely. What you are describing
> is more like FAT.
Not even close. You need to learn more about how CPU jumps work.
> Certainly Unix (which preceeded CP/M) did not copy from CP/M and 'extend
> it'.
Didn't I just _SAY_ that?
Jack
Jack Crenshaw
> Did you ever try the Amiga OS? I'd be interested to hear your comments about
> it given your impressive critique above.
As a matter of fact, I did. I bought one of the very first Amiga's, which had,
unfortunately,
the pretty horrible and incredibly slow AmigaDOS 1.0. I waited for about a year
for
software to come along for it, but finally tired of waiting and bought a <groan>
PC.
Reading the documentation of the OS and the way it interacted with the hardware,
I
was struck by its beauty. I think if I were writing an OS from scratch, I'd do
it almost
exactly the same way. As I recall, there was only one fixed address in the
entire
machine, the address of the pointer to all other addresses. I also was
impressed by the
linked-list structure at its heart.
IMO, if the hardware had been up to the task, and the developers had had more
time
to get things ready, the Amiga could easily have been a PC-killer. I understand
they are
still used heavily by the folks who make movies, etc. The thing was, my Amiga
only
had one floppy drive -- no HD at all, and was incredibly slow. When the HD
finally did
come out, it was something like $1200.
There must be a special place in Hell for the guy (Steve Jobs?) whose bright
idea it was
to build a PC with only one floppy and no HD.
Short answer to the question: I thought the concept of AmigaDOS was perfect.
They
just ran out of time and resources.
Jack
CBFalconer
>
> Bill Haygood wrote:
>
> > I *continue* to use WS4 running on my own z80a emulator (which runs at
> > just under 90 MHz on my 550 MHz dual Pentium III Caldera OpenLinux
> > system). I like WS4's ability to move a block of text to the *right*
> > of another text.
>
> Very cool!!!!
>
Take a look at textpad. It can move vertical blocks quite
nicely. You have to do a bit of scrambling to find out how
though. It also reformats paragraphs (but won't right justify).
Quite a nice source editor also. Especially useful for printing
text files, because you can control the print fonts and format
independantly from the screen versions.
Bill Marcum
Jack Crenshaw wrote in message <3AEC0B0B...@earthlink.net>...
>
>There must be a special place in Hell for the guy (Steve Jobs?) whose
bright
>idea it was
>to build a PC with only one floppy and no HD.
>
Atari 8-bit computers and then the Amiga. In the early 80s, floppy
drives cost hundreds of dollars and a 10 meg hard drive cost as much
as today's high end PCs. Lots of personal computers then were sold
with one floppy drive, because even that was better than cassette tape.
Axel Berger
RP>FAT is just as 'obvious' as others and shares exactly the same 3
RP>criteria you claimed above (and thus is equally identical).
It is perhaps not politically correct to say so here, but I actually
consider FAT to be an improvement. After all, we are talking a time
when RAM was really scarce. The only way to make the CPM system work is
the way it is actually done, by keeping an allocation map in RAM. On
big disks with not too big allocation blocks - and with an OS designed
to work in as little as 16 kB they had better be small - this is a lot
of RAM taken up. Now you can use FAT entirely on disk. Of course it
takes a lot of time to go looking from the beginning of the FAT every
time to find the free space right at the end - I wonders why no one
ever thought of adding a single flag holding the location of the first
free block - but then you can copy a map of it to RAM like CPM does,
only you don't have to.
--
Tschö wa
Axel
CBFalconer
>
> *Richard Plinston* wrote on Sun, 01-04-29 10:24:
> RP>FAT is just as 'obvious' as others and shares exactly the same 3
> RP>criteria you claimed above (and thus is equally identical).
>
> It is perhaps not politically correct to say so here, but I actually
> consider FAT to be an improvement. After all, we are talking a time
> when RAM was really scarce. The only way to make the CPM system work is
> the way it is actually done, by keeping an allocation map in RAM. On
> big disks with not too big allocation blocks - and with an OS designed
> to work in as little as 16 kB they had better be small - this is a lot
> of RAM taken up. Now you can use FAT entirely on disk. Of course it
On the contrary, the CP/M map takes one bit per block. The FAT
system takes 12, 16, or 32 bits per block. Keeping them in memory
is essential to any reasonable speed.
The CP/M slowdown is on reboot, when the entire directory has to
be read to form the allocation map.
FAT exists because Gates did it that way for his earliest Basic,
which pre-dated general use of CP/M. It is the design of an 18
year old.
Every file system has its plusses and minuses. CP/M is quite safe
when changing floppies because of the allocation map check sum; on
the other hand a floppy change under FAT can destroy everything.
However FAT includes a disk description in the boot sector, and
CP/M does not.
Chewy509
"Kelli Halliburton" <kell...@crosswinds.not> wrote in message
news:9cglpv$49lg$1...@newssvr06-en0.news.prodigy.com...
Bill Haygood
> I worked with a guy who I *know* had to re-install Windoze NT at least *three*
> different times... Each time it took the bulk of an afternoon to do
> it...*no* useful
> work there...
I gave up on Windows 95 after the 33rd re-install into my IBM Aptiva
in 1996.
Bill
Richard Plinston
> > >
> > > Yep. Consider: The Unix root directory has a fixed number of entries.
> > > So did CP/M.
> >
> > And so has just about every other disk system. The reason for this is
> > entirely simple: the data blocks must start somewhere and this becomes a
> > fixed point when data has been written. The reserved area prior to this
> > (or in some cases located somewhere else) becomes a fixed size.
>
> Richard, I didn't say it wasn't simple. In fact, I believe I said it was
> entirely obvious.
No, _I_ said that the reason for the 'similarity' is simple (see
above). Any system that doen't resort to shifting data blocks around
has a fixed size area and thus a 'fixed number of entries'. This is not
a similarity between Unix and CP/M but a similarity of almost _all_ disk
systems.
> > And so is just about every other disk system. In fact can you name one
> > that doesn't ?
>
> Um ... excuse me, but Russell's claim was that there is no obvious
similarity
> between CP/M and Unix. Now you seem ready to argue the exact opposite. Why?
There is no obvious similarity between Unix and CP/M that is not shared
by most other disk systems. The 'similarities' that you claimed are
common to almost all systems and are not unique similarities at all. You
may also want to claim that they are 'similar' because they 'write in
tracks' and 'on disk surfaces'.
> > > The only difference, really
There are dozens of fundemental differences between Unix file systems
and CP/M. It seems that you should be saying: "The only differences
that I know of ...".
> (and it is, admittedly, a big one)
> > > is that Unix allows a bit flag to support indirect addressing.
> > > That's how it supports multiple directories and infinitely
> > > large files.
> >
> > Indirect addressing is not done by a 'bit flag' it is done as a
> > consequence of the inode system.
>
> Yep. And the system must know whether an i-node points to the beginning
> of a file, or another i-node. The way it does so is an implementation
detail.
In all the Unix implementations that I have dealt with inodes do _not_
point to other inodes. You have this quite wrong. Each inode has a
number (usually 10) direct points and then a series of indirect pointers
(usually 3) where the first is a level 1 indirection that points to a
block of file block numbers, the 2nd is a level 2 indirection pointer to
a block of pointers to blocks of pointers to file blocks and so on.
There is no 'inode pointing to inode' at all. There is a mechanism
where several file names can refer to the same inode, and the inode
holds the number of these references, but this has nothing to do with
indirect addressing.
Actually Unix may have several different file systems amd also use
others, such as FAT or FAT32, so there may be systems that work
completely differently from standard Unix.
> Are you just looking for an argument, or what? To most folks, the phrase
> "infinitely large files" would be perfectly clear, and would be interpreted
as
>
> "as large as the available disk space." You have a problem with that?
Unix files are limited to a size that may be considerably less than the
available disk space. Typically this is 16 Gigabyte. Certainly a few
years ago this may have been reasonably claimed as 'limited by disk
size', but this is no longer so. Again for special purposes a file
system may be modified by the implementor to provide different
characteristics.
> > > It still
> > > strikes me that the two have a lot more in common than Unix and the
> > > horrors of FAT.
> >
> > FAT is just as 'obvious' as others and shares exactly the same 3
> > criteria you claimed above (and thus is equally identical).
> Wrong again. The FAT is a chained-entry system. Hence the need for
Scandisk.
The 'three criteria you claimed above' were:
1) >The Unix root directory has a fixed number of entries. So did CP/M.
2) >The (base-level) entries have a fixed number of segments. Ditto
for CP/M.
2> >Disk blocks are accessed by block number. Ditto for CP/M.
FAT does this too, so your 'wrong again' is entirely a result of your
confusion.
In fact none of these 3 imply a chained or otherwise system, FAT simply
has a single 'fixed number of segments' in the base level entry that
represents the start of the chain, Unix has a hierarchical system of
direct and multilevel indirect blocks (multi-tree short chains), and
CP/M has a series of extents. These are 3 completely _different_
mechanisms.
> Hence the need for Scandisk.
All 3 systems have mechanisms that perform the functions of Scandisk (or
its predecessor chkdsk) and all 3 need this as they are all liable to
similar problems, such as cross-linked files. CP/M does a directory
scan whenever a disk is reset to build the free block array and this
could detect cross-links and other problems. Unix has fsck for exactly
the same purpose.
The 'need for Scandisk' is _not_ because it is a 'chained-entry system'
but because it, like CP/M and Unix and many others, has the potential
for errors in the structure.
> > One could rewrite any system to become some other system.
>
> Now, _THERE'S_ a really helpful statement. Thanks so much for the insight.
Your suggestion that CP/M could be 'modifed;' to use a flag bit to get
indirection would actually have to be a complete rewrite (which is what
I was implying). Currently CP/M finds the correct block for a file by
taking the record position required and calculating which 'extent' this
lies in, searching the directory for that (ignoring other extents), and
then retrieving the appropriate block number from the index. If one or
more index prior to this position could be an indirect pointer to a
block of block numbers then the whole system of extents would have to be
discarded. Given that this is a fundemental mechanism (that is
completely different from any in Unix or FAT) then it would be a system
rewrite and all software may have to be rewritten, especially compiler
libraries and all the software compiled with these.
> > You appear to misunderstand 'inodes' entirely. What you are describing
> > is more like FAT.
>
> Not even close. You need to learn more about how CPU jumps work.
And you need to learn inodes.
I care not how your obscure machine does 'jumps' the way you described,
it is certainly nothing like how inodes work.
Actually you may like to explain _which_ computers used the top bit of
an address to flag that this was an 'indirect address'. It seems a
particularly pointless ;-) mechanism. I have worked with machines where
there were _instructions_ that held an address which may be an absolute
address or an indirect address and a flag in the _instruction_ indicated
which this was (as a byproduct of how the instruction set was
constructed). But I cannot see the utility of having an instruction
point to an address that may be the start of a chain of addresses.
Either it is a fixed chain that can be resolved at compile time or the
addresses may change in which case just change the one that the
instruction points to rather than have this point to another one that
may change.
Please explain and illustrate.
Also explain where you got your complete misconception of how inodes
work.
> > Certainly Unix (which preceeded CP/M) did not copy from CP/M and 'extend
> > it'.
>
> Didn't I just _SAY_ that?
No you didn't.
What you _did_ say was:
> Jack Crenshaw <jcr...@earthlink.net> wrote:
>
> > Unix/Linux _DOES_ have a relatively simple disk structure -- a
> > fairly straightforward extension of the CP/M approach, to support
Later you said:
> > it's not necessary to assume that either designer stole from the other.
What _I_ said is that it is _certain_ that Unix did not 'extend' CP/M
and not merely an assumption they didn't.
Michael J. Mahon
<snip>
>Actually you may like to explain _which_ computers used the top bit of
>an address to flag that this was an 'indirect address'. It seems a
>particularly pointless ;-) mechanism. I have worked with machines where
>there were _instructions_ that held an address which may be an absolute
>address or an indirect address and a flag in the _instruction_ indicated
>which this was (as a byproduct of how the instruction set was
>constructed). But I cannot see the utility of having an instruction
>point to an address that may be the start of a chain of addresses.
>Either it is a fixed chain that can be resolved at compile time or the
>addresses may change in which case just change the one that the
>instruction points to rather than have this point to another one that
>may change.
</snip>
In several "early" word-oriented computers, the word size was set
by the required arithmetic range/precision, which was typically
many bits larger than the maximum address size. This situation
invites machine architects to invent uses for the "spare" bits.
One such family of machines was the IBM 701, 704, 709, 7090,
7094 series, which had 36-bit words, and a maximum (in the later
models) address width of 15 bits. (With 6-bit characters, this
gave them an "astronomical" maximum memory size of 192K
characters!)
A "pointer" word was commonly composed of _two_ pointers,
one the low-order 15 bits of the upper 18 bits, and the other
the low-order 15 bits of the lower 18 bits--called the "decrement"
and the "address" fields, respectively. (When McCarthy implemented
LISP on the 709, he naturally used this machine-preferred format
for cells, hence the CAR--Contents of the Address Register, and the
CDR--Contents of the Decrement Register basic LISP selector
functions.)
Since it was so useful to modify addresses in memory and re-use
them as variable pointers, it seemed that it would be useful to allow
a pointer to address (or index) into a table of pointers as well, and
to support this indirection by "indirect addressing" through the first
pointer and then through the second. Since the only simple cases
are 0, 1, and infinity, the "indirect" bit in the pointed-to address was
implemented iteratively, permitting unlimited chains of indirection
to be resolved within a single instruction execution (but, of course,
many memory cycles). This also permitted circular chains, which
caused the instruction address calculation, and therefore the
instruction itself, never to complete. This was a "bad thing" since
interrupts would go unserviced, and even the HALT button would
not stop the machine! The machine could only be recovered by
putting it into single-cycle mode and resetting it.
When later machines were designed, with no fealty to compatibility
with the 7000 series, the designers generally opted to drop the
"infinite" indirection capability for single indirection, signaled not
by the addressed pointer, but by the instruction itself.
There was another similar "chaining" capability in the 7000 series,
and in some others, called the "EXECUTE" instruction. This opcode
would not "complete" until the single instruction its address pointed
to had been executed. You can guess that a chain of XEQ instructions
could be constructed which had all the interesting properties of the
"indirect" bit, including the possibility of the original instruction never
achieving completion.
Although there were relatively few sound applications for indefinite-
level indirection or execution, a friend of mine found an interesting
one. He was doing a set-theoretic computation in which he enumerated
elements and assigned them to equivalence classes under some
transformation. He implemented each element's representation as
either an XEQ instruction pointing to one of its "equivalent" elements,
or, if it were the first element of a new class, a LOAD of the class
number into the accumulator. So every chain of XEQs terminated in
a load of the specific constant that represented its equivalence class.
This removed a loop from what was the inner loop of his search. (Of
course, it didn't _actually_ remove it, since the machine did the
resolution loop in hardware, but it did reduce the time per iteration
to one memory cycle (2 microseconds), which wasn't bad. He
probably could have changed his algorithm to make the pointer
chasing occur once, outside the inner loop, but he was happy with
the speed the way he did it!
BTW, the 360 designers also eliminated iterative Executes, by
generating an exception if an Execute was the target of an Execute.
Of course, none of this is particularly relevant to modern computers,
since both indefinite mechanisms have been consigned to the scrap
heap of computer architecture--particularly since address chaining is
so destructive to modern cache-based machine performance. But
as Don Knuth once said (partially in jest), "There is no problem in
computer science that cannot be solved with another level of
indirection!"
-michael
"In the beginning was the word--and it was the wrong size." Robert Barton
Richard Plinston
> CP/M's biggest failing is that it was never intended to support
> multitasking. The hardware of the day didn't support it, either.
There were several systems that multi-tasked on many different types of
hardware by the time CP/M was developed. Your assertion that 'the
hardware didn't support it' is quite wrong as is amply demonstrated by
the number of different OSes that ran on exactly the same hardware that
CP/M would such as MP/M, PolyMorphic (I have a couple here), Oasis
(later called TheOS, I have some of these too) and BOS.
For example the PolyMorphic was an S100 8080 based machine that ran
several tasks in 48Kb.
> Nowadays, I think no one would be satisfied with an OS that didn't
> at least support foreground/background tasking. We've talked before
> here about Borland's
> Modula 2, which very much _DID_ provide a multitasking structure, so
> it could be done, but it was very difficult.
In what way did Borland's Modula 2 provide multi-tasking ? How would
the user (or program) start a 2nd task ? How did the user select
between tasks.
> Unix's biggest failing is that it was designed for multi-user
> timeshare, and therefore has too _MUCH_
> support for multitasking. By that I mean, it is designed around the
> concept of multiple users, each'
> with his own password, login mechanism, and cost accounting/billing
> structure. That kind of thing
> is _NOT_ either required or wanted for a desktop system.
How many different individuals use your machine ? In many families each
person has their own login in Windows so that they get their own
preferences and desktop setup. In some cases the administrator (father)
sets profiles to limit the users (children) in such things as internet
access. It may be that Windows doesn't provide multiple _concurrent_
users, but multiple users _are_ a requirement of many systems.
Even my TV remote control caters for personal settings for multiple
users. By indicating that I am 'user 1' I get my preferences.
> Unix's second biggest failing is that it was adopted with open arms by
> the C-hacker/guru bunch,
> whose motto is, "Never do something the straightforward way when you
> can make it obscure."
It may be 'obscure' to you, but that make it obscure in any absolute
sense.
> that they know surprisingly
> little about the entire system; they tend to only work with one part
> of it, and are clueless of the other parts.
Whereas you have demonstrated that you are ....
> Neither the designers of CP/M or Unix envisioned CRT-based user
> interfaces, much less pixel
> graphics and mice.
Why do you think this ? Tektronic graphics screens, input tablets and
light pens were around at the time, as were text CRT terminals. Mice
not.
> With the advent of such devices, the OS has to
> manage them too, and face it:
> the mechanisms to do so, on both systems, are kludge upon kludge upon
> kludge. See the termcap structure for Unix.
What is wrong with the termcap structure ? How would you do it ? only
support one type, such as TeleVideo and tell users they can have just
one brand and model ?
> Writers of screen editors discovered that CP/M
> didn't give them fast enough
> access to the screen, so they had to write direct hardware access
> software that was customized for the particular hardware in use.
On CP/M ? How do you 'write direct' to an ADM-3a terminal in a way that
the BIOS doesn't ?
> Wordstar did that admirably,
On CP/M systems ? I think that you are confused.
> the fact that Wordstar was
> adaptable to so many different computers proves that it's not
> impossible to do so.
WordStar for IBM PC/PC-DOS appears to do direct screen writes, but this
version is not configurable for other systems. The version that is
configurable for other terminal types (eg serial terminals) does not do
'direct screen'.
The type of configuring done for each piece of software under CP/M where
the terminal type must be specified, or if it isn't in the list must be
created, shows exactly the advantages of termcap. There the programs
dynamically collect the terminal configuration even if the machine has
several different terminal types.
> An OS service
> that managed the screen would have been infinitely better,
Duh. That's what Termcap is.
> but I think one can still make the
> argument that having to customize the editor to the CRT is better,
Only if the system has a single fixed terminal type. Otherwise you have
to have different configured copies of programs and then ensure the
correct one is run each time. Consider a dial in link, do you only
allow users with the correct terminal to use the system ?
> smaller, faster, and more
> reliable than the kludgy layers upon layers of interfaces in something
> like Windows. Just reading the
> PC BIOS code that goes out to check the CRT type and CRT hardware is
> enough to give one nausea.
The PC-BIOS just checks the motherboard switch setting for mono or CGA,
or for ATs and above the CMOS ROM setting for these or VGA. What
'PC-BIOS code that goes out to check the CRT type' are you imagining
here ?
> Re multitasking: There's no reason why one can't have a simple disk
> directory structure and still support M/T.
You seem to have completely failed to notice that MP/M and Turbo-DOS had
multi-tasking on CP/M file system and this was retained through to about
Concurrent-DOS 5.
In fact multi-tasking and 'a simple disk directory structure' are
completely independent of each other - there is no relationship at all.
> I said it in 1980 and I'll say it again, 20 years later: The good OS
> for microcomputers has not
> been written yet. If I were to start from scratch, I'd _BEGIN_ with a
> multitasking kernel, not
> unlike that of current RTOS's.
In 1980 you seem to completely fail to notice MP/M (which had been
around for a couple of years) which actually did have a kernel 'not
unlike RTOS's'. In fact it retained its essential structure into
Concurrent and into DRI's RTOS range: FlexOS.
There were several 'good OSes' in 1980 that you failed to notice, there
are many more today that also count as 'good'. Most were/are designed
around particular requirements and these may not match what you want.
There never will be _a_ best OS for every purpose, just as there never
will be _a_ best car or _a_ best boat.
Most systems do not require RT features (but it happens that several
do), perhaps you may like to explain _why_ you would use an RTOS kernel.
> I'd add a file structure and I/O
> structure that provided only the
> most basic of functions like read sector, write sector, etc
> (essentially the CP/M BIOS). Then
> I'd add the remaining layers on top of those basic ones.
Yet above you said of layers:
> smaller, faster, and more
> reliable than the kludgy layers upon layers of interfaces
Now you want to have layers upon layers.
> One thing the designers of both systems did right: They made the user
> interface (the "shell")
> a separate module that could be modified, customized, or replaced. If
> only Microsoft were able to figure out how to do that,
Duh. MS-DOS's COMMAND.COM is exactly a copy of the structure that CP/M
had with CCP and this can be 'modified, customised, or replaced' by,
say, 4DOS, the MS-DOS 4.01 menu shell, DRI's GEM, Windows or others.
If only you could have figured that out for yourself.
> instead of claiming that the user interface won't work without
> a web browser <!>.
They just built yet another replacement shell, one that shared code with
IE.
Russell Marks
> Richard Plinston wrote:
>
> > Jack Crenshaw wrote:
[...]
> > > Disk blocks are accessed by block number. Ditto for CP/M.
> >
> > And so is just about every other disk system. In fact can you name one
> > that doesn't ?
>
> Um ... excuse me, but Russell's claim was that there is no obvious similarity
> between CP/M and Unix. Now you seem ready to argue the exact opposite. Why?
That was emphatically *not* my claim. (I don't think I actually made a
claim, just questioned yours.) You said that "Unix/Linux _DOES_ have a
relatively simple disk structure -- a fairly straightforward extension
of the CP/M approach", which I took exception to for two reasons:
- "fairly straightforward extension" isn't true - and inodes, with
their three different levels of indirection IIRC, are merely the
most obvious example of where Unix completely differs from CP/M;
- "extension of the CP/M approach" isn't true - Unix (and, I think,
the basic filesystem structure concept) predates CP/M and as such
the filesystem can hardly be an extension, straightforward or
otherwise.
The Unix and CP/M filesystems do share the absolute basics of a
filesystem, in the sense that they both map filenames to file data in
the end, but comparing them on more than the most superficial level is
a bit questionable IMHO. CP/M has a good, simple filesystem (well,
CP/M 1.4 did, before they kludged it slightly for 2.x and 3.0 :-)) -
Unix also has a good filesystem, but with very different goals, and a
very different approach.
But if you *really* want to see if Unix's filesystem is an extension
of CP/M's or not, you could always ask on alt.folklore.computers and
see what Dennis Ritchie has to say. :-)
> > > The only difference, really (and it is, admittedly, a big one)
> > > is that Unix allows a bit flag to support indirect addressing.
> > > That's how it supports multiple directories and infinitely
> > > large files.
> >
> > Indirect addressing is not done by a 'bit flag' it is done as a
> > consequence of the inode system.
>
> Yep. And the system must know whether an i-node points to the beginning
> of a file, or another i-node. The way it does so is an implementation detail.
But the indirection really is inherent to Unix's inode scheme. I don't
think you could do it with a flag.
And I don't see what this has to do with supporting multiple
directories!
> > You appear to misunderstand 'inodes' entirely. What you are describing
> > is more like FAT.
>
> Not even close. You need to learn more about how CPU jumps work.
I'm probably misunderstanding you, but I don't quite see the
relevance. The indirection being referred to here is one area on disk
referring to another (which may in turn be referring to another,
etc.). I don't think CPU addressing schemes are related, unless I've
missed something.
> > Certainly Unix (which preceeded CP/M) did not copy from CP/M and 'extend
> > it'.
>
> Didn't I just _SAY_ that?
I don't think so. Did you miss the "not"? :-)
-Rus.
Kelli Halliburton
> the basic filesystem structure concept) predates CP/M and as such
> the filesystem can hardly be an extension, straightforward or
> otherwise.
Breakdown in communication -- "extension of the approach used by CP/M" would
probably have been more accurate.
I can say that a 10-speed bicycle built 20 years ago uses an extension of
the approach used by a 1-speed bicycle built yesterday; that doesn't mean
that I thought the older machine twisted time in on itself and copied and
extended the technology of the later machine.
Kelli Halliburton
> available disk space. Typically this is 16 Gigabyte.
34 bits? Can you explain the origin of such a number? 36 bits I would have
understood, given the Honeywell heritage of Unix. 32 bits I also would have
understood. But while 34 is an interesting 'compromise,' it's also unwieldy
for a machine based on 8-bit bytes to deal with.
Kelli Halliburton
point to quibble, though...
"Jack Crenshaw" <jcr...@earthlink.net> wrote in message
news:3AEC0B0B...@earthlink.net...
> As a matter of fact, I did. I bought one of the very first Amiga's, which
> had, unfortunately,
> the pretty horrible and incredibly slow AmigaDOS 1.0. I waited for about
> a year for
> software to come along for it, but finally tired of waiting and bought a
> <groan> PC.
>
> Reading the documentation of the OS and the way it interacted with the
> hardware, I
> was struck by its beauty. I think if I were writing an OS from scratch,
> I'd do it almost
> exactly the same way. As I recall, there was only one fixed address in
> the entire
> machine, the address of the pointer to all other addresses. I also was
> impressed by the linked-list structure at its heart.
>
> IMO, if the hardware had been up to the task, and the developers had had
I thought the hardware was pretty good given the competition. IBM had CGA. I
think EGA came out in 86? Even that wasn't quite up to the challenge. Mac
had monochrome. The Amiga had 4096 colors at 320x400, and 16 at 640x400.
The Mac had 1 channel of digital sound. The PC had the beep. The Amiga had 4
channels of digital sound.
The Mac had a 68000 at 8MHz, but had to do all its own graphics and sound
processing. The PC had the 4.77MHz 8088, and it too had to do all of its own
graphics and "sound" processing. And the AT had the 6MHz 80286. The Amiga
had the 7.16MHz 68000 and had the graphics coprocessor and the blitter to
assist with graphics, and the DMA sound chip.
So what part of the hardware "wasn't up to the task"?
Richard Plinston
>
> > Unix files are limited to a size that may be considerably less than the
> > available disk space. Typically this is 16 Gigabyte.
>
> 34 bits? Can you explain the origin of such a number?
It has nothing to do with 34 bits.
> 36 bits I would have
> understood, given the Honeywell heritage of Unix.
I presume here you are referring to Multics on GE.
> 32 bits I also would have
> understood. But while 34 is an interesting 'compromise,' it's also unwieldy
> for a machine based on 8-bit bytes to deal with.
An inode has 10 direct pointers to disk blocks of (typically) 1kb size
-> first 10Kb of file
The next pointer (in the same inode you understand) points to a block
(1Kb) of 32 bit pointers to data blocks.
256 x 1Kb -> 256Kb of data
Then a 2 level pointer:
256 x 256 x 1Kb -> 64MByte
Then a 3 level pointer:
256 x 256 x 256 x 1Kb -> 16GByte
All with 32 bit block numbers and 1Kb blocks.
Note that the block numbers are 32 bit and so the disk size can be
somewhat larger (by a factor of 256). And then there are 64 bit file
systems.
If, however, as you say, the system is 32bit then this may impose
another limit at 4Gbyte if fseek is to be used as this addresses bytes.
Some file structures, such as some databases, may have limits at 2 Gbyte
for internal reasons.
Different file systems may have different characteristics.
Russell Marks
[I wrote:]
> > - "extension of the CP/M approach" isn't true - Unix (and, I think,
> > the basic filesystem structure concept) predates CP/M and as such
> > the filesystem can hardly be an extension, straightforward or
> > otherwise.
>
> Breakdown in communication -- "extension of the approach used by CP/M" would
> probably have been more accurate.
Well, it wouldn't, because it's still not true (AFAIK). But yes, it
does avoid the timeline problem.
-Rus.
Jack Crenshaw
Marks says...
>
>Jack Crenshaw <jcr...@earthlink.net> wrote:
>
>> Um ... excuse me, but Russell's claim was that there is no obvious similarity
>> between CP/M and Unix. Now you seem ready to argue the exact opposite. Why?
>
>That was emphatically *not* my claim. (I don't think I actually made a
>claim, just questioned yours.) You said that "Unix/Linux _DOES_ have a
>relatively simple disk structure -- a fairly straightforward extension
>of the CP/M approach", which I took exception to for two reasons:
>
>- "fairly straightforward extension" isn't true - and inodes, with
> their three different levels of indirection IIRC, are merely the
> most obvious example of where Unix completely differs from CP/M;
>
>- "extension of the CP/M approach" isn't true - Unix (and, I think,
> the basic filesystem structure concept) predates CP/M and as such
> the filesystem can hardly be an extension, straightforward or
> otherwise.
Russell, both you and Richard seem to take my comment that the
Unix file structure is "a fairly straightforward extension" of CP/M's
to imply a causal relationship, in which CP/M was somehow _COPIED_
by Ritchie and Thompson. That was not my intention, and I think I've
said that about three times now. I hope this clears that point up,
once and for all. We all know that minicomputers came before microcomputers,
which probably explains why Unix predates CP/M. For that matter, most of
us know that mainframes came before minicomputers, which explains why
Multics predates Unix, as well as the pun implied by the Unix name.
Now let's talk about file systems and block numbers.
Since Gary Kildall proposed, and then started writing, an OS for floppy-based
microcomputers about a week after the first 8" floppies became available, I
think it safe to say that the first version of CP/M was about as crude a
system as one would ever write, and was written with no thought for later
extension to hard drives, multiple users, nested directory structures, or any
or the other features normally ascribed to modern DOS's. Nevertheless,
it _IS_ possible to extend the basic file structure of CP/M to emulate many,
if not all, of the nicer features of Unix, including true nested directories,
batch files, shell scripts, aliases, search paths, termcap, etc., etc. For
an example, see any version of Rick Conn's ZCPR or the later, and very
excellent, Z-System.
Personally, I used ZCPR2, which provided most such features in a very small,
simple package. I had my HD partitioned into four logical drives, and each
drive into the usual 16 user areas. I had my own, screen-oriented "browser"
which allowed me to assign a descriptive character string to each of the 64
areas, giving me a rather nice and simple multi-directory structure.
I do agree with you both that, at the bottom-most level, every disk is an
array of blocks, though this is not the _ONLY_ way one could organize it (the
obvious alternative: track/sector). Given that one has chosen to use block
number, rather than track/sector, as the addressing mechanism of choice,
I must agree that it's hardly surprising that both CP/M and Unix use this
mechanism.
With respect to inodes: I stand corrected. I _THOUGHT_ I understood them,
but apparently they've changed since I last looked. Perhaps the difference
is between AT & T's implementation and UC Berkeley's -- I know they are
different. I do recall that, when I first read the description of how the Unix
file system worked, I was struck by how simple it was, and how little of an
extension over CP/M was required to implement it. The inodes that you and
Richard are describing are anything _BUT_ simple. So I am prepared to retract
my statement that the Unix structure is a "straightforward extension of
CP/M," and ameliorate it to only say that it _OUGHT_ to be. More on this
later.
>But the indirection really is inherent to Unix's inode scheme. I don't
>think you could do it with a flag.
Yes, indeed you can. And it would be simpler.
>I'm probably misunderstanding you, but I don't quite see the
>relevance. The indirection being referred to here is one area on disk
>referring to another (which may in turn be referring to another,
>etc.). I don't think CPU addressing schemes are related, unless I've
>missed something.
I think perhaps you did. My story about the minicomputers and indirection was
intended to show the parallel between disk accesses and RAM accesses.
Apparently, I missed the boat, so let me try again.
A memory is a collection of bytes. A disk is a collection of sectors or blocks.
One accesses a byte of memory (or, to keep the analogy closer, a word)
by giving its address. One accesses a block of disk data by giving _ITS_
address. So far, a 1-to-1 correspondence, right? In fact, conceptually
there is no difference from, say, a sector of 128,256, or 512 bytes of data
in RAM, and the same data on disk. Either way, the sector has an address.
Now, suppose I have files that are collections of data, too big for a single
disk block, but still fairly small. The obvious solution is to create a
directory entry with a fixed number of block numbers, a la CP/M. If the file
only takes up, say, one block, then so be it; the others are wasted. The Unix
inode works the same way, right?
But what if the file is too big to be fully described by a set of simple
block numbers? In that case, one has to come up with some mechanism for
supporting multiple sets of such numbers. The CP/M approach was to add yet
another directory entry (thereby enlarging the file, but also burning one
of those precious, fixed number of entries). The Unix approach is to use
indirection. Thus, instead of having a pointer to a disk block, you have a
pointer to another array of pointers. One only need to agree as to what
mechanism one should use to distinguish between a direct and indirect block
address.
Here, it seems to me that the analogy between RAM addresses and disk addresses
is near-perfect, if not exactly so, and that was the point of my little
discourse on indirect memory addresses in minis. Assuming that the mini
has a 16-bit address, but never uses more than 32k of RAM (typical of the minis
of the 70's), you have one address bit to burn. The CPU uses this bit to
determine whether an address is direct or indirect. If the indirection bit
is cleared, the CPU assumes that the address is direct, and goes and fetches
(or writes to) the word addressed by it. If, OTOH, the bit _IS_ set, the
CPU knows to fetch the word addressed, and use _IT_ as the new address. The
process can go on indefinitely, as long as one eventually arrives at a direct
address (if you don't, that's called a bug).
As we've all agreed, the root directory of any file system will almost surely
contain only a fixed number of entries, since one must allocated a certain
structure to the disk when formatting it. The only question is: What do you
do when that fixed number is full? CP/M simply throws up its hands and says,
"Directory full." A system that supports larger files, or multiple directories,
or both, can do so by having the directory entry point to, instead of disk
blocks describing files, disk blocks describing directories, which themselves
point to files or other directories.
In the case of Unix, most folks use it precisely that way. The root directory
(not /root, but /) mostly points to directories, which point to other
directories or files. Similarly, small files can have a simple collection
of block numbers, larger ones a collection of indirect blocks. Each time you
go another level, you get N^2, N^3, N^4, etc. number of addressable blocks.
I was not aware that Unix only allowed three levels of indirection. The
system I described, which is very easy to implement using a single bit, would
allow any number of levels.
>And I don't see what this has to do with supporting multiple
>directories!
See above. Because the root level has a fixed number of entries, one is
pretty much forced into directories, and that rather naturally brings up the
issue of nested directories. From the notion of indirected files, it's
fairly easy to see that a directory, except at the root level, need not be
distinguished from a disk file, except by the kind of data it holds. It can
be put anywhere on the disk, and contain as many entries as it needs to.
On this topic of nested directories, I think it's important to note that there
need be no connection between the structure of data on the disk, and the way
it appears to the user or his applications. To give a trivial example, the
"user areas" of CP/M served only to hide files from DIR, ERA, TYPE, and the
command processor itself. The files were all on the same disk, and in the
same directory (there _IS_ only one), but a DIR would only show the files
with the same user area.
In the same way, one can have directories that _APPEAR_ to be nested but
really aren't; only the search path mechanism determines what's visible and
what isn't. Some years ago, I was working with a homebrew machine running
Peter Stark's SK*DOS (formerly StarDOS). Pete had a flat file structure, and
was getting pressure from his users to support a hierarchical file structure.
He resisted because he saw it as a total rewrite of his file structure. I tried
to suggest that he could accomplish the same thing by simply assigning a
"user area" of, say, 8 bits, and use it to hide the files that weren't in the
current area. That would allow for 256 total directories, which at the time
seemed to me to be enough for most mortals except Bill Gates. All of the
utilities, including the shell, would check the user area byte to determine if
the file were visible. One could, easily enough, add search paths and
hierarchy. I say that with some confidence, since Rick Conn did it.
Admittedly, there are performance issues. If I were implementing a file
structure, I'd want to preload into RAM, the directory pointers for all the
files currently visible, or as many of them as my RAM would allow, just to
avoid having to scan the whole disk and cull all the invisible files.
Which takes us right back to indirection. If I have a pointer to a list of the
currently visible files, I do, in fact, have one of a potentially hierarchical
set of directories. Typically, this pointer would, I expect, point to a simple
disk file, that just happens to have the 'd' attribute set.
I hope this clears things up. If you want to discuss it further, feel free
to post to my email address as well as the group, since I don't pass this
way very often. I ask only that if you use my inbox, you do so with proper
respect for its owner.
Jack
Jack W. Crenshaw
jcr...@earthlink.net
Dave Tweed
> Here, it seems to me that the analogy between RAM addresses and disk addresses
> is near-perfect, if not exactly so, and that was the point of my little
> discourse on indirect memory addresses in minis. Assuming that the mini
> has a 16-bit address, but never uses more than 32k of RAM (typical of the minis
> of the 70's), you have one address bit to burn. The CPU uses this bit to
> determine whether an address is direct or indirect. If the indirection bit
> is cleared, the CPU assumes that the address is direct, and goes and fetches
> (or writes to) the word addressed by it. If, OTOH, the bit _IS_ set, the
> CPU knows to fetch the word addressed, and use _IT_ as the new address. The
> process can go on indefinitely, as long as one eventually arrives at a direct
> address (if you don't, that's called a bug).
But this doesn't give you any fan-out in terms of being able to access
more memory. Each address is still a fixed number of bits.
Each step of indirection in the Unix filesystem adds a few bits to the
number of blocks allowed in a file by indexing a table at each step of
the indirection. With 256 block addresses per block, you get 8 more bits
in the length of the file for each level of indirection. Three levels
gets you more or less to the same limit as the maximum size of the whole
filesystem.
What you're thinking about is less like an indirect bit in a memory
addresss and more like how a forward-mapped MMU implements virtual
memory. Again, a fixed number of levels of indirection gets you to
another system limit, this time on the size of the virtual address
space.
> As we've all agreed, the root directory of any file system will almost surely
> contain only a fixed number of entries, since one must allocated a certain
> structure to the disk when formatting it.
Nope, sorry, completely wrong about Unix. In Unix, directories are just
files too, including the root directory. Inode #1 is a pseudo-file that
"ties up" all of the known bad blocks on the disk so that they don't
appear in the free block list. Inode #2 is the root directory, and it can
grow to be as large as any file on the disk. The rest of the inodes are
ordinary files and directories.
The only fixed-size structure in a Unix filesystem is the inode table
itself, which limits the total number of real files, regardless of which
directories they appear in.
> In the case of Unix, most folks use it precisely that way. The root directory
> (not /root, but /) mostly points to directories, which point to other
> directories or files.
This has nothing to do with disk space management. It's just a way of
organizing the clutter in the namespace.
-- Dave Tweed
Jack Crenshaw
>
>But this doesn't give you any fan-out in terms of being able to access
>more memory. Each address is still a fixed number of bits.
Good point. I was assuming that we'd all understand that each address
points to a block for fan-out. As a matter of fact, the same thing was
true for the minicomputer indirection that I described. Some mechanism
such as an index register or literal offset, was assumed for each level
of indirection. It miust be that way, or else you gain no benefit; you
only exchange one jump for several.
>> As we've all agreed, the root directory of any file system will almost surely
>> contain only a fixed number of entries, since one must allocated a certain
>> structure to the disk when formatting it.
>
>Nope, sorry, completely wrong about Unix. In Unix, directories are just
>files too, including the root directory.
Really? It certainly didn't _USED_ to be that way. I distinctly remember,
reading about it, that the root level has a fixed number of entries.
Better tell Richard and Russell, also, since they both agreed with me on
this.
>This has nothing to do with disk space management. It's just a way of
>organizing the clutter in the namespace.
I agree. So?
Jack
Jack Crenshaw
>
>> [snip...] [snip...] [snip...]
>IMHO, you can be rid of Windoze *now*... A lot of things that people use
>Windoze for
>can be done with Linux and Staroffice... Can you get a Mathcad that runs
>on Linux???
>Have you *really* tried to find such a thing??? For being on the
>internet, I use a
>Macintosh G4...after I deleted all the Micro$uck bloatware off of it...
Here I have to plead a serious case of chronic inertia. I'm trying hard
(completely without success) to get my company to switch over to Linux.
I've also installed it in two machines at home. But I have not yet climbed
the learning curve enough to make the switch.
I write a column every month, and the publisher wants the results written
in Word format. I know, I know, there are Linux apps like StarOffice that
can store the files in Windows format, but if there are any slipups, it means
disaster as far as getting the column to the publisher. Everything has to
work on schedule, or all bets are off. Even when I upgraded from Microsoft
Equation Editor to Mathtype (which is supposed to be compatible), it broke
the files so my editor could no longer read them.
I also lean heavily on Mathcad and Maple and Matlab and Corel Draw, not
to mention Netscape for getting the files uploaded. Again, I can't let go
of Windows until I have Linux working with all the right parts.
Soooo, I keep plodding along, figuring on at least one major Word crash per
column, muttering darkly certain choice Old South voodoo curses against
Bill Gates and his minions of darkness, and hoping against hope that _SOMEDAY_
I'll have made the transition to Linux.
>
>I worked with a guy who I *know* had to re-install Windoze NT at least *three*
>different times... Each time it took the bulk of an afternoon to do
>it...*no* useful
>work there...
Tell me about it. I've often pondered the incredible number of person-hours
we are all wasting, trying to patch and paste bandaids and duct tape onto
Windows, to keep things working. I think it might be an Iraqi plot.
Jack
Jack Crenshaw
>
>Steve Jobs was one of the founders of Apple. Jay Miner designed the
>Atari 8-bit computers and then the Amiga. In the early 80s, floppy
>drives cost hundreds of dollars and a 10 meg hard drive cost as much
>as today's high end PCs. Lots of personal computers then were sold
>with one floppy drive, because even that was better than cassette tape.
>
I understand the reasons and even the economics. I still think it was
a rotten decision. After all, even as early as 1978, many CP/M machines,
not to mention the TRS-80, were running with two floppies. Some with four.
How the heck
is one to copy disks, otherwise? It took a diabolically twisted mentality
to dream up the "Copy A: B:," when there was no B: drive.
Jack
Jack Crenshaw
says...
>
>I don't really take issue with your critique of the OS at all. I do have a
>point to quibble, though...
>
>> IMO, if the hardware had been up to the task, and the developers had had
>
>I thought the hardware was pretty good given the competition. IBM had CGA. I
>think EGA came out in 86? Even that wasn't quite up to the challenge. Mac
>had monochrome. The Amiga had 4096 colors at 320x400, and 16 at 640x400.
I wasn't thinking so much about the base-level hardware as the optional extras,
and not so much the availability as the price. I think anyone who remembers
the origins of the Amiga is well aware that the custom I/O and system chips that
came with it were defining the state of the art.
As you know, the base-level Amiga had only the one floppy, which I just got done
describing as a diabolical idea, and see no reason to change my mind. A second
floppy, like the HD that came along much too late to be of much help, were
outrageously expensive. What I was trying to say was that if the Amiga had come
standard with, at the very least, an HD, things could have been very different.
Jack
Dave Tweed
> Good point. I was assuming that we'd all understand that each address
> points to a block for fan-out. As a matter of fact, the same thing was
> true for the minicomputer indirection that I described. Some mechanism
> such as an index register or literal offset, was assumed for each level
> of indirection. It miust be that way, or else you gain no benefit; you
> only exchange one jump for several.
Actually, there *is* benefit from mere indirection (think about method
pointers in object-oriented design, and inheritance), and there were
mainframe and minicomputers that implemented it exactly as you described,
without indexing at each level.
In fact, I've never heard of a computer that did it with indexing -- do
you have any specific examples? How would you specify a different index
for each level of indirection, and how would you know how many indices
to supply?
> >Nope, sorry, completely wrong about Unix. In Unix, directories are just
> >files too, including the root directory.
>
> Really? It certainly didn't _USED_ to be that way. I distinctly remember,
> reading about it, that the root level has a fixed number of entries.
Again, can you cite a specific example? I've been working with Unix and
Unix-like systems on and off for about 25 years now, and all of the ones
I know of work this way. Why make the root directory "special" if you
don't need to?
-- Dave Tweed
Bill Marcum
Jack Crenshaw wrote in message ...
>I understand the reasons and even the economics. I still think it was
>a rotten decision. After all, even as early as 1978, many CP/M machines,
>not to mention the TRS-80, were running with two floppies. Some with four.
>
>How the heck
>is one to copy disks, otherwise? It took a diabolically twisted mentality
>to dream up the "Copy A: B:," when there was no B: drive.
>
at first, but as the prices came down, people upgraded from one floppy
drive to one floppy + hard drive. You rarely see a computer with two
floppy drives of the same size unless it's a CP/M or similar system or one
of the first MSDOS systems.
Chewy509
> Soooo, I keep plodding along, figuring on at least one major Word crash
per
> column, muttering darkly certain choice Old South voodoo curses against
> Bill Gates and his minions of darkness, and hoping against hope that
_SOMEDAY_
> I'll have made the transition to Linux.
described it as kiddie-ware: a lot of eye-candy, rather big (recent distro's
take about 1gig minimum for a basic workstation), with not much working. And
even though a user of linux for the past 4 years, I had to agree. I've spent
more time trying to get linux to work without crashing than I have with
maintaining my NT box. Don't get me wrong, I think linux is a good thing,
but it must mature a lot before I consider it for replacement for other
commercial OS's.
> >
> >I worked with a guy who I *know* had to re-install Windoze NT at least
*three*
> >different times... Each time it took the bulk of an afternoon to do
> >it...*no* useful
> >work there...
>
> Tell me about it. I've often pondered the incredible number of
person-hours
> we are all wasting, trying to patch and paste bandaids and duct tape onto
> Windows, to keep things working. I think it might be an Iraqi plot.
All OS's have this problem. Yes I've had to reinstall NT several times, but
*never* due to an unsuspected crash. (mainly dumb things I was doing) :)
However, I've also had to build my own Linux distro to get it working just
right. Take for example, I have 2 Voodoo2 cards in SLI. I had to download,
Mesa3d, libSDL, and about 5 other libraries. Modify the configure scripts,
and makefiles, recompile all libraries, and then if I had the application
source recompile it as well. Talk about lost man hours, (about 3 8hr days).
And if any have bugs, well I'm screwed, until a new version of a library is
released. I've *never* had a linux distro work 100% out-of-the-box. However,
I can say that I've had Windows work 100% out-of-the-box. (Only 2-3 times
however). :)
But, getting back to original topic, (this is my Jerry Springer end-of-show
speech) no one OS is better than another, it just depends on selecting the
correct tool for the job. ie, Unix for server, BeOS/Windows/DOS for
workstation, PalmOS/QNX for embedded, etc...
Chewy509...
BTW: Has there been any real innovation in OS development since CP/M days?
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> I've spent
> more time trying to get linux to work without crashing than I have with
> maintaining my NT box. Don't get me wrong, I think linux is a good thing,
> but it must mature a lot before I consider it for replacement for other
> commercial OS's.
>
I have *never* heard of anyone having this problem with Linux...
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Richard Plinston
> >Nope, sorry, completely wrong about Unix. In Unix, directories are just
> >files too, including the root directory.
>
> Really? It certainly didn't _USED_ to be that way. I distinctly remember,
> reading about it, that the root level has a fixed number of entries.
No. It was _always_ that Unix directories were just files. I don't know
what it is that you 'distinctly rememeber', about this or inodes, but it
certainly isn't Unix in any form at all.
My references include complete sets of Unix manuals for various versions
back to 7th edition, various books such as "The Design of the Unix OS"
by MJ Bach, and The Bell System Technical Journal for July-Aug 1978.
This last contains several articles on Unix including those by Ritchie
and Thompson describing early development and implementation.
I suggest that you read _something_ about the subject then you might
realise why no one else considers Unix to be 'like CP/M' as you do.
> Better tell Richard and Russell, also, since they both agreed with me on
> this.
I bet you 'distinctly remember' this as well, but if you look back at
the messages you will find that I only agreed that the 'reservered area'
was a fixed size on many operating systems:
--------------------------------------------------------------------------
> > Yep. Consider: The Unix root directory has a fixed number of entries.
> > So did CP/M.
>
> And so has just about every other disk system. The reason for this is
> entirely simple: the data blocks must start somewhere and this becomes a
> fixed point when data has been written. The reserved area prior to this
> (or in some cases located somewhere else) becomes a fixed size.
--------------------------------------------------------------------------
The fixed size reserved area in all Unix systems is the inode table,
always has been.
Mark Stone
Yes, OS/2.
-Mark
Chewy509
> > BTW: Has there been any real innovation in OS development since CP/M
days?
>
> Yes, OS/2.
Sorry, forgot about that one? Could mention BeOS? Oh, crap, I'm starting to
answer my own questions, again.
Now where's my medication...
Chewy509...
Chewy509
"Charles Richmond" wrote:
> >
> > [snip...] [snip...] [snip...]
> >
> > I've spent
> > more time trying to get linux to work without crashing than I have with
> > maintaining my NT box. Don't get me wrong, I think linux is a good
thing,
> > but it must mature a lot before I consider it for replacement for other
> > commercial OS's.
> >
> Please tell me what you did to cause a properly-installed Linux to
crash...
> I have *never* heard of anyone having this problem with Linux...
>
I've never found a distro that fully supports my machine out of the box.
Either through incompatibilities, and just the wrong config settings.
Re-installing linux 3 times in one day is *not* fun... particularly when
trying to show it off to some associates.
Chewy509...
BTW: No OS is fool-proof, if it exists, I can crash it. (Try reading
directly from the keyboard under linux after disabling IRQ1, linux will
automatically re-enable IRQ1, and process keystrokes, even though my app
takes over the keyboard). Guaranteed to crash it... Also mesa3d/glide isn't
trustworthy either, but is getting better... Also some HDD settings can kill
a ext2fs partition faster than Superman can catch a speeding train...
Lee Hart
> How the heck is one to copy disks, otherwise? It took a diabolically
> twisted mentality to dream up the "Copy A: B:," when there was no B:
> drive.
All the microcomputers I've used could copy disks with only one floppy
drive. They basically read as much of the disk as would fit into memory,
asked you to swap disks, wrote that block of memory to disk, asked you
to swap the disks back, and repeated until done.
Not as convenient as having two drives of course, but it worked just
fine!
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
Russell Marks
> >Nope, sorry, completely wrong about Unix. In Unix, directories are just
> >files too, including the root directory.
>
> Really? It certainly didn't _USED_ to be that way. I distinctly remember,
> reading about it, that the root level has a fixed number of entries.
>
> Better tell Richard and Russell, also, since they both agreed with me on
> this.
When did I do that? None of my posts have even *mentioned* the root
directory.
-Rus.
Richard Plinston
> " of CP/M's
> to imply a causal relationship, in which CP/M was somehow _COPIED_
> by Ritchie and Thompson.
That is because we understand what the word _extension_ means.
It means to add to, taking the original and putting something
more on it.
> That was not my intention, and I think I've said that about
> three times now.
Then use words that indicate what you actually mean.
I, also (and Russell probably), in _actually_ knowing the structure
of both CP/M and Unix, understand the great and fundemental
differences between these and thus simply disagree that there is
any similarity at all beyond what is shared by most other
file systems.
They both may 'extend' some basic fundementals of disk structuring
(use block numbers, have fixed reserved area), as most system do,
but they do so in quite different ways. That is they do when one
compares CP/M and the _ACTUAL_ Unix, rather than what you 'distinctly
remember'.
> "the Unix file structure is a fairly straightforward extension
> of CP/M's"
Is not just wrong because of the word 'extension', it is wrong
because they are quite different systems and you seem to be
comparing CP/M to something that is not Unix at all.
Richard Plinston
> as crude a system as one would ever write,
I don't think so at all. There are many other systems that are
'cruder' than CP/M's file system, for example DFS for the Acorn
BBC computer's MOS operating system. The 3740 file system that
was first with floppies was much cruder too. Many Word Processing
systems and games machines such as Commodore 64 were also
much cruder.
Some file systems only recorded the start block of
the file on disk and its length - the file has to be contiguous.
This has the consequence that only one file at a time could be
created or extended and thus must be the last physical file on the
disk writing into the free space.
Special utilities would 'compress' the disk to recover lost space
from deleted files so that the maximum free space was available.
For the purposes intended (word processing, games, data entry,
saving basic programs) these crude mechanisms were quite adequate.
In fact CP/M's file system is quite sophisticated compared to
these, allowing as it does, several files to be written as
may happen during business applications, deleted space is reusable
directly, files to extend into any free space.
Richard Plinston
You don't know that. Much of CP/M was based on ideas from RT-11
operating system, including some of the file system ideas which on
a PDP-11 ran on hard disks. The RT-11 is the origin of the 8.3
naming system, PIP, DIR and other naming and structure items.
As development of and for CP/M, and in fact of the Intel 8080
development system itself, was done on the PDP-11 it is to
be expected that Gary knew how it worked.
But CP/M file structures work fine on hard disks. I have used
CP/M formatted media up to 160MByte and still have a machine
with an 80MByte CP/M drive.
> multiple users,
* The origin in RT-11 supported multiple concurrent users.
* The later MP/M and CCP/M supported multiple concurrent users
on the identical file system structures.
* CP/M directory is based on USER AREAS,
I say again **USER**AREAS**. Multiple users _are_ supported
directly by CP/M giving them their own areas to store their
individual files. Of course not concurrent users until MP/M.
> nested directory structures, or any
Nested directory structures were not common in the 70s.
> or the other features normally ascribed to modern DOS's.
"Giving no thoughts" to what would be considered 'modern' a decade
or two later would require somewhat more than an average crystal
ball.
Given that he was trying to do something useful in 4Kbytes he was
hardly likely to be concerened with GUIs running with 64K colours
at 1024x960.
In fact CP/M extended quite well into MP/M, Concurrent-DOS-86 and
beyond. MP/M had file sharing and record locking sorted out
properly before DOS was even thought of and then MS got it
wrong when it was added into version 3.x.
> Nevertheless, it _IS_ possible to extend the basic file
> structure of CP/M to emulate many, if not all, of the nicer
> features of Unix, including true nested directories,
Only using a complete rewrite as an 'extension'.
> batch files, shell scripts, aliases, search paths, termcap,
Batch files, shell scripts, and termcap have _NOTHING_ to do
"the basic file structure" of Unix or CP/M. CP/M already had
'batch files, shell scripts' so no 'extension' required, or
didn't you know about SUBMIT ?
Termcap is only an issue where there are different terminal types
on one machine, not an issue for CP/M. It is, in fact, more an
application development issue and not an OS one.
'aliases' are actually a problem a system that is not based on
something like an inode structure. Especially, it makes file
sharing and locking problematical. With Unix the aliasing is
done by having several links to the inode giving several names
referring to one file. As the inode is unique to the data then
this is used to control all accessing and locking and deleting.
With a CP/M like directory where the file name is irretrievably
part of the file (ie the file name and data pointers are in the
same structure) then aliasing presents many difficulties.
For example: if FileB is an alias for FileA where aliasing is
done by FileB pointing to the directory entry of FileA, and FileA
is deleted with a new file FileC being created and this uses
the directory entry vacated by FileA then what is FileB now
an alias of ?
'Search Path' ? What for, you could access your own 'user area'
and the user 0 'common' area (read only). That was a sensible
structure and worked well.