Ada Tutor Web Site Shutting Down
John Herro
Unfortunately, my Web site www.adatutor.com (formerly
members.aol.com/adatutor), will be closing down. If your Web site has
a link to my site, it will no longer be good.
Those interested in an example of Ada 95 programming can download
the free program at my other Web site, www.bible73.com, which will
remain operational.
- John Herro
Thomas Løcke
> Webmasters:
> Unfortunately, my Web site www.adatutor.com (formerly
> members.aol.com/adatutor), will be closing down. If your Web site has
> a link to my site, it will no longer be good.
Hi John,
Thanks for the notice. I've cleared away the links we had to
adatutor.com at the Ada-DK website.
--
Thomas Lųcke
Email: tl at ada-dk.org
Web: http//:ada-dk.org
http://identi.ca/thomaslocke
Brad Cantrell
Perhaps you would consider putting AdaTutor under some type of open
source license, one that would allow you to maintain ownership and be
a maintainer but allow others to distribute and make their own
versions of. I dont know much about open source licenses but I think
Creative Commons is a popular option.
There have been a lot of great interactive Ada tutorials that have
been lost because the owner lost interest. Your tutorial is the best
out there, its helped me to understand Ada, Id like to see its
development continued.
John Herro
Brad,
Good idea. Actually, the source code is included in the archive.
Anyone who has downloaded it may now modify it, use it, and distribute
it for free, disregarding the shareware notices. Anyone may also make
it available on a Web site, etc. If you do so, please post that the E-
address and postal address in the program are old, but that I said
it's OK to use the program for free and disregard the shareware
notices. Anyone who wants a copy of the program may e-mail me at the
address shown at www.adatutor.com (not the gmail address from which
I'm posting this), and I'll send a copy.
Thanks for your comment that my tutorial is the best out there.
Unfortunately, the program is rather obsolete, covering only through
Ada 95, but it's better than nothing.
- John
qunying
I feel the same as Brad that your tutorial is the best out there.
Thank you for your effort and provided it as a shareware and now open
it.
Would like to confirm is version 4.01 the latest?
John Herro
Thanks for your kind words! Yes, 4.01 is the latest. Now that my
program is in the public domain, I'd like to see someone translate it
from DOS to HTML, so it will run in a Web browser rather than a
command window. Also, perhaps someone could update it for versions of
Ada later than Ada95.
- John
Rugxulo
On May 5, 7:29 am, John Herro <johnhe...@gmail.com> wrote:
>
> Thanks for your kind words! Yes, 4.01 is the latest. Now that my
> program is in the public domain, I'd like to see someone translate it
> from DOS to HTML, so it will run in a Web browser rather than a
> command window. Also, perhaps someone could update it for versions of
> Ada later than Ada95.
DJGPP is still barely creaking along, even with GCC 4.5.2 (including
GNAT), FreeDOS too (2040 coming soon!), but they have very very few
testers. I know I'm beating a dead horse here, but you could always
run FreeDOS under JPC (Java) in a browser. Someone correct me, but are
there any better DOS Ada compilers that are still updated??? (Would be
surprised.)
P.S. Challoner ftw! ;-)
Randy Brukardt
news:e9ff6294-9947-495e...@v8g2000yqb.googlegroups.com...
>
> DJGPP is still barely creaking along, even with GCC 4.5.2 (including
> GNAT), FreeDOS too (2040 coming soon!), but they have very very few
> testers. I know I'm beating a dead horse here, but you could always
> run FreeDOS under JPC (Java) in a browser. Someone correct me, but are
> there any better DOS Ada compilers that are still updated??? (Would be
> surprised.)
Better, dunno. Janus/Ada 95 (32-bit only) would be updated if anyone wanted
it, but no one has asked. (It's still in our pricelists.)
But a better question is why would you want to use a new compiler? Is there
anything inportant that you can do in DOS that you can't do in a Windows
console program or a standard Linux program? The main reason for compiling a
DOS program would be so that you don't have to change anything about,
including the DOS specific stuff. In that case, you're best off sticking
with the same compiler that it was built with, why make more work by
introducing a new set of bugs.
(We occassionally get requests for absolutely ancient compiler versions, for
someone that needs to make a tiny change in some old program. Not long ago,
I needed to dig up a 1985 version of Janus/Ada for someone. The cool thing
was that I tried running it to make sure I'd copied it uncorrupted [an issue
because it copied from 25 year old floppies], and it worked fine on a modern
Windows XP machine. I knew there was a reason that we were really careful
about following the OS rules back in the day...)
Randy.
Fritz Wuehler
> anything inportant that you can do in DOS that you can't do in a Windows
> console program or a standard Linux program?
Yes, since DOS runs on very low spec hardware with almost no RAM, if you can
compile to that environment from Ada you can make very nice small machines
for different purposes- embedded, etc. And Ada is SO much better than the
typical languages found in DOS it's a shame not to have it available.
[I didn't read the OP since google groups are filtered upstream from me]
> I knew there was a reason that we were really careful about following the
> OS rules back in the day...)
Excellent! Now if the OS itself would only follow the rules we would be ok!
;-)
Rugxulo
On May 5, 4:12 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> Better, dunno. Janus/Ada 95 (32-bit only) would be updated if anyone wanted
> it, but no one has asked. (It's still in our pricelists.)
Updated how? (A quick glance at the 2005 standard seems more
complicated regarding changes than initially implied.) Well, I'm not a
customer (and don't know Ada), so I guess that rules me out. ;-)
I'd assume it's "good enough" for the few that use DOS commercially
these days. (I assume you probably are more geared towards businesses
than home users.)
The only significant DOS Ada app I know of (which is probably my
fault, not Ada's) is Gautier's 3D engine (used GNAT):
http://sites.google.com/site/rugxulo/eng3d018.zip?attredirects=0
> But a better question is why would you want to use a new compiler?
Why not? :-) No, seriously, I was only responding to the OP's claim
that Ada95 is obsolete and that his tutorial was in DOS (hence, old)
and needed to be updated. I don't even know what compiler he used for
it originally.
> Is there anything inportant that you can do in DOS that you can't do
> in a Windows console program or a standard Linux program?
Sure, run in DOS! :-))
(self-modifying code? direct hardware access? run in less than 10 MB
of RAM? call the BIOS?)
> The main reason for compiling a
> DOS program would be so that you don't have to change anything about,
> including the DOS specific stuff.
Sure, assuming there is any DOS-specific stuff, which I know is
sometimes unavoidable, but doing that almost defeats the purpose of a
portable HLL.
> In that case, you're best off sticking
> with the same compiler that it was built with, why make more work by
> introducing a new set of bugs.
Well, bugs will always exist, even with the best of intentions and
strictest preparations.
> (We occassionally get requests for absolutely ancient compiler versions, for
> someone that needs to make a tiny change in some old program. Not long ago,
> I needed to dig up a 1985 version of Janus/Ada for someone. The cool thing
> was that I tried running it to make sure I'd copied it uncorrupted [an issue
> because it copied from 25 year old floppies], and it worked fine on a modern
> Windows XP machine. I knew there was a reason that we were really careful
> about following the OS rules back in the day...)
Yes, that's the ideal, software that still runs for many years in the
future. The DPMI standard helped that a lot. For sure, DOS lived a
long, long time.
Unfortunately, Windows has gone downhill (in DOS support) since XP,
and 64-bit completely kills it. (XP Mode is only for business
editions, not home users.) You'll have to use DOSBox or VirtualBox
(preferably with VT-X) or else switch to Linux for DOSEMU. (Well, you
could run FreeDOS natively, but I doubt most will consider that.)
Randy Brukardt
Hi,
>On May 5, 4:12 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> Better, dunno. Janus/Ada 95 (32-bit only) would be updated if anyone
>> wanted
>> it, but no one has asked. (It's still in our pricelists.)
>Updated how? (A quick glance at the 2005 standard seems more
>complicated regarding changes than initially implied.)
Just recompiled and tested. It might need some runtime updates, but probably
not a lot. All of our Ada 95/2005/2012 technology is from a common codebase,
so building the DOS version just means selecting the right configuration and
recompiling. (And lots of testing and probably a bit of debugging.)
The biggest problem with it is that the DOS extender we used didn't work
with NT and afterwards. (It actually works precisely once, then you have to
reboot before it will work again. Not very practical.)
> Well, I'm not a
> customer (and don't know Ada), so I guess that rules me out. ;-)
> I'd assume it's "good enough" for the few that use DOS commercially
> these days. (I assume you probably are more geared towards businesses
> than home users.)
I don't think we have any DOS customers anymore; they've all moved to
Windows console mode or to other OSes.
> The only significant DOS Ada app I know of (which is probably my
> fault, not Ada's) is Gautier's 3D engine (used GNAT):
> http://sites.google.com/site/rugxulo/eng3d018.zip?attredirects=0
>> But a better question is why would you want to use a new compiler?
>
>Why not? :-) No, seriously, I was only responding to the OP's claim
>that Ada95 is obsolete and that his tutorial was in DOS (hence, old)
>and needed to be updated. I don't even know what compiler he used for
>it originally.
If I remember right, his tutorial uses a DOS display program. That looked
old when it was new. ;-)
>> Is there anything inportant that you can do in DOS that you can't do
>> in a Windows console program or a standard Linux program?
>
>Sure, run in DOS! :-))
>
>(self-modifying code? direct hardware access? run in less than 10 MB
>of RAM? call the BIOS?)
Self-modifying code: Not with Janus/Ada (no self-modifying code there). We
wanted it to be reproducible and somewhat secure. Direct hardware access - I
suppose, but is that an advantage? Or a security nightmare waiting to
happen? Same with "call the BIOS". Run in less than 10 MB of RAM - I think
there are Linux flavors that can do that. The Ada programs are pretty small
for any of the OSes (so that's about the OS footprint).
>> The main reason for compiling a
>> DOS program would be so that you don't have to change anything about,
>> including the DOS specific stuff.
>
>Sure, assuming there is any DOS-specific stuff, which I know is
>sometimes unavoidable, but doing that almost defeats the purpose of a
>portable HLL.
It was pretty much impossible to do anything interesting without doing
something DOS specific. That's actually true of pretty much every OS target,
simply because of the different nature of file names on each platform.
>> In that case, you're best off sticking
>> with the same compiler that it was built with, why make more work by
>> introducing a new set of bugs.
>
>Well, bugs will always exist, even with the best of intentions and
>strictest preparations.
Exactly.
>> (We occassionally get requests for absolutely ancient compiler versions,
>> for
>> someone that needs to make a tiny change in some old program. Not long
>> ago,
>> I needed to dig up a 1985 version of Janus/Ada for someone. The cool
>> thing
>> was that I tried running it to make sure I'd copied it uncorrupted [an
>> issue
>> because it copied from 25 year old floppies], and it worked fine on a
>> modern
>> Windows XP machine. I knew there was a reason that we were really careful
>> about following the OS rules back in the day...)
>
>Yes, that's the ideal, software that still runs for many years in the
>future. The DPMI standard helped that a lot. For sure, DOS lived a
>long, long time.
I think 1985 was well before DPMI, and probably was before expanded and
extended memory, too. This probably was a basic 640K compiler (I don't think
we even had 640K in our machines at the time - our original IBM PC/XT
started with 256K, and I think the Seattle Computer 10 MHZ 8086 [much faster
than the PC] had about that as well).
>Unfortunately, Windows has gone downhill (in DOS support) since XP,
You could have just left out the parenthetical remark, and you still would
have been right. ;-)
>and 64-bit completely kills it. (XP Mode is only for business
>editions, not home users.) You'll have to use DOSBox or VirtualBox
>(preferably with VT-X) or else switch to Linux for DOSEMU. (Well, you
>could run FreeDOS natively, but I doubt most will consider that.)
That's one of the reasons I'm not moving most of my work to Windows 7
anytime soon. I still use a number of DOS programs regularly, including a
circa 1986 programming editor.
Randy.
Rugxulo
On May 11, 7:45 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:291504a4-ec55-45f1...@m10g2000yqd.googlegroups.com...
>
> >On May 5, 4:12 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> >> Better, dunno. Janus/Ada 95 (32-bit only) would be updated if anyone
> >> wanted
> >> it, but no one has asked. (It's still in our pricelists.)
> >Updated how?
>
> Just recompiled and tested. It might need some runtime updates, but probably
> not a lot.
What for? Improvements or just to remove the bitrot?
> All of our Ada 95/2005/2012 technology is from a common codebase,
> so building the DOS version just means selecting the right configuration and
> recompiling. (And lots of testing and probably a bit of debugging.)
Ah, testing, the biggest time waster. Luckily, Ada has a public test
suite.
> The biggest problem with it is that the DOS extender we used didn't work
> with NT and afterwards. (It actually works precisely once, then you have to
> reboot before it will work again. Not very practical.)
Was it a special homebrew one or one of the popular ones licensed?
(What brand name?) Well, either way, I'm not surprised. Half the time
the extenders were buggy, but the other half was due to XP limitations
and bugs. (BTW, I assume you meant close/reopen the DOS window, but if
you meant reboot the computer/OS, that's worse! Ugh.)
> > Well, I'm not a
> > customer (and don't know Ada), so I guess that rules me out. ;-)
> > I'd assume it's "good enough" for the few that use DOS commercially
> > these days. (I assume you probably are more geared towards businesses
> > than home users.)
>
> I don't think we have any DOS customers anymore; they've all moved to
> Windows console mode or to other OSes.
If NT support is buggy, and since XP has been ubiquitous since 2001,
I'm not too surprised. Then again, DOS isn't cool anymore, and people
want (native support for) Unicode, 64-bit, GUIs, Win32 API
(multimedia), etc.
> >> But a better question is why would you want to use a new compiler?
>
> >Why not? :-) No, seriously, I was only responding to the OP's claim
> >that Ada95 is obsolete and that his tutorial was in DOS (hence, old)
> >and needed to be updated. I don't even know what compiler he used for
> >it originally.
>
> If I remember right, his tutorial uses a DOS display program. That looked
> old when it was new. ;-)
Well, I blindly assumed he meant some of the code itself was DOS
specific, but who knows, I haven't checked (probably should).
> >> Is there anything inportant that you can do in DOS that you can't do
> >> in a Windows console program or a standard Linux program?
>
> >Sure, run in DOS! :-))
>
> >(self-modifying code? direct hardware access? run in less than 10 MB
> >of RAM? call the BIOS?)
>
> Self-modifying code: Not with Janus/Ada (no self-modifying code there). We
> wanted it to be reproducible and somewhat secure.
I don't blame you, but people do it! (Of course new cpus run it very
slowly, so it's not recommended anyways, assuming the OS even allows
it!)
> Direct hardware access - I suppose, but is that an advantage?
Only if you need it (some do, most don't). DOS doesn't really support
graphics in the API (unless you count the BIOS or VBE), so you have to
do stuff yourself. Sound support is the real killer (esp. with non-SB
cards these days)!
> Or a security nightmare waiting to happen? Same with "call the BIOS".
People always find a way to breach security anyways. But yeah, DOS has
pretty much none anyways, always "root". :-)
> Run in less than 10 MB of RAM - I think
> there are Linux flavors that can do that. The Ada programs are pretty small
> for any of the OSes (so that's about the OS footprint).
Most Linuxes aren't geared towards low RAM, esp. nowadays (2.6
kernel). The lightweight ones usually only target 128 MB on up. So I
kinda disagree that Linux can fill that niche (though it doesn't
matter too much these days with tons of RAM, it's just frustrating
when the OS hogs so much, we always seem to need more and more). 128
MB just doesn't cut it these days (I tried!).
> It was pretty much impossible to do anything interesting without doing
> something DOS specific. That's actually true of pretty much every OS target,
> simply because of the different nature of file names on each platform.
If you used old Allegro (or if SDL was supported on DOS), it would be
okay. At least, I assume that's what "interesting" means. (Some people
like purely academic things like calculations, compilers, etc. But
most just want flashy games or GUIs or whatnot.)
> >> I needed to dig up a 1985 version of Janus/Ada for someone. The cool
> >> thing
> >> was that I tried running it to make sure I'd copied it uncorrupted [an
> >> issue
> >> because it copied from 25 year old floppies], and it worked fine
>
> >Yes, that's the ideal, software that still runs for many years in the
> >future. The DPMI standard helped that a lot. For sure, DOS lived a
> >long, long time.
>
> I think 1985 was well before DPMI, and probably was before expanded and
> extended memory, too. This probably was a basic 640K compiler (I don't think
> we even had 640K in our machines at the time - our original IBM PC/XT
> started with 256K, and I think the Seattle Computer 10 MHZ 8086 [much faster
> than the PC] had about that as well).
Right, sorry, I knew that. Though there were 286 extenders by then,
but the 386 didn't even come out until 1986 or so (and took a while to
get adopted). Real EMS existed, of course, as did XMS, but it was
fairly rare. Even in 1994, my new PC only had 4 MB of RAM! My, how
times have changed. :-O
But yeah, VCPI (386+) was 1986, DPMI (286 or 386) was 1990. And I hear
that SCP-8086 could use the full 1 MB (unlike IBM's 640 kb). I assume
this means yours was a multi-pass compiler (a la Wirth's old M2M /
Modula-2). But maybe not, perhaps you crammed a lot into "256K" (Ada83
only probably made it easier).
> >Unfortunately, Windows has gone downhill (in DOS support) since XP,
>
> You could have just left out the parenthetical remark, and you still would
> have been right. ;-)
More or less, yes. I know MS thinks XP is old and wants to deprecate
it, but it seemed fine to me. But I'm sure some fringes had various
complaints about it that only Vista or 7 solved. I'm not Windows-y
enough to know, honestly. (But I do think they charged too much for
Vista -> 7 ["minor"] upgrade.)
> >and 64-bit completely kills it. (XP Mode is only for business
> >editions, not home users.) You'll have to use DOSBox or VirtualBox
> >(preferably with VT-X) or else switch to Linux for DOSEMU. (Well, you
> >could run FreeDOS natively, but I doubt most will consider that.)
>
> That's one of the reasons I'm not moving most of my work to Windows 7
> anytime soon. I still use a number of DOS programs regularly, including a
> circa 1986 programming editor.
I'm surprised, honestly, most people spit on the idea of (still) using
DOS software. But not me! ;-) Windows 7 32-bit probably (somewhat)
works for DOS, as I know Vista 32-bit barely did (some bugs, DPMI
registry hack needed, no full screen gfx).
Though I wonder at using such an old editor, but I know people like
what they like, so I can't complain. (Text editors are a dime a dozen
but none do everything, not even Emacs or VIM. Check out http://www.texteditors.org
sometime for a laugh.)
Georg Bauhaus
> On May 11, 7:45 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Then again, DOS isn't cool anymore.
Has DOS ever been cool? I mean cool? Rather, adopting DOS seems quite
frankly the most far reaching mistake that computer dependent
industry has committed, the consequences being loss of both
software quality and---far worse---a collective loss of any knowledge
of what quality software might be!
>> Or a security nightmare waiting to happen? Same with "call the BIOS".
>
> People always find a way to breach security anyways. But yeah, DOS has
> pretty much none anyways, always "root". :-)
Is DOS's privilege system different from what you get with
typical µ targets?
OTOH, this all has little to do with Ada Tutor web site
shutting down. ;-)
Rugxulo
On May 12, 9:44 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 12.05.11 15:28, Rugxulo wrote:
>
> > On May 11, 7:45 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > Then again, DOS isn't cool anymore.
>
> Has DOS ever been cool? I mean cool?
At one time, it was very very popular and available on almost all home
PCs. Lots and lots of commercial DOS games were produced, and most of
these are still sold (e.g. Gog.com). Many DOSes and emulations exist,
actually, so somebody thought it was worth keeping (if not you,
obviously).
> Rather, adopting DOS seems quite
> frankly the most far reaching mistake that computer dependent
> industry has committed,
Why, because of the dependency on the evil BIOS? Or because it made MS
our evil overlords?
DOS was used because of the extremely low RAM of the day (16 to 64 kb,
I think) on the original IBM PC. Well, and also CP/M-86 wasn't ready,
so they just used the cheap clone with identical API called PC-DOS (MS-
DOS).
> the consequences being loss of both
> software quality and---far worse---a collective loss of any knowledge
> of what quality software might be!
Not true. Quality software can be written on any OS. "A poor carpenter
blames his tools." Many successful things have been written for DOS,
not the least of which are Lotus 123, MS Word, Turbo C++, Turbo
Pascal, Wolfenstein 3D, Doom, Quake, and a bunch of ports of GNU
tools.
> >> Or a security nightmare waiting to happen? Same with "call the BIOS".
>
> > People always find a way to breach security anyways. But yeah, DOS has
> > pretty much none anyways, always "root". :-)
>
> Is DOS's privilege system different from what you get with
> typical µ targets?
It's just minimal, meaning it's not all baked into the kernel, for
good or bad. You can add layers to it, of course.
> OTOH, this all has little to do with Ada Tutor web site
> shutting down. ;-)
Well, I was primarily pointing out that Ada is still supported for DOS
(barely) via GNAT/DJGPP. Then I was discussing compatibility re:
Janus' old 32-bit DOS offering. Hey, it's probably the most traffic
you've had re: Ada usage for DOS in years!
Adam Beneschan
> > Rather, adopting DOS seems quite
> > frankly the most far reaching mistake that computer dependent
> > industry has committed, the consequences being loss of both
> > software quality and---far worse---a collective loss of any knowledge
> > of what quality software might be!
>
> Not true. Quality software can be written on any OS. "A poor carpenter
> blames his tools." Many successful things have been written for DOS,
> not the least of which are Lotus 123, MS Word, Turbo C++, Turbo
> Pascal, Wolfenstein 3D, Doom, Quake, and a bunch of ports of GNU
> tools.
Seems right. Actually, I find Georg's assertion puzzling. The
quality of software has to do with the experience of the people
writing it, and with the design principles (or lack of) that the
software developers apply or fail to apply. Carefulness is a factor,
of course. The choice of language is a smaller factor, but as we know
on c.l.a a language can help support or hinder good software design
principles. Hardware limitations can be a small factor, since it's
harder to write good quality software when your memory space is
limited. The choice of OS seems to be one of the least important
factors of all. It's really hard for me to imagine how the choice of
DOS versus other operating systems available at the time (or
potentially available) could have any significant impact on software
quality at all.
-- Adam
tmo...@acm.org
in the air and pretended it didn't exist. So I got out my old Janus DOS
compiler and, accessing disk sectors via the BIOS, was able to copy
almost everything.
More generally, hardware is simple - a few pages would tell you
everything you needed to know about, say, DMA. Today you need to learn
a massive library even to do a simple thing, and then spend a lot of time
discovering what the docs left out or lied about. I suspect programmers
today spend much more time gathering information and much less time
creating programs.
Simon Wright
For everyone's info:
If you follow the instructions, Adatutor builds just fine on Mac OS X
with GCC 4.6.0.
A couple of minor glitches at runtime (in a Term window):
(a) I had to rewrite USERDATA.TXT to use the Unix LF line ending instead
of the supplied CRLF.
(b) The window started out black-on-black, not so legible, so I suggest
producing a new USERDATA.TXT containing
122
7
0
0
for starters. 'S' (or, I think, 's') changes screen colours.
(c) Lots of references on help screens etc to John Herro! Clearly no
longer valid.
NB, I've only gone as far as the second screen, may be more CRLF issues
later on.
Georg Bauhaus
> On May 12, 10:40 am, Rugxulo<rugx...@gmail.com> wrote:
>
>>> Rather, adopting DOS seems quite
>>> frankly the most far reaching mistake that computer dependent
>>> industry has committed, the consequences being loss of both
>>> software quality and---far worse---a collective loss of any knowledge
>>> of what quality software might be!
>>
>> Not true. Quality software can be written on any OS. "A poor carpenter
>> blames his tools." Many successful things have been written for DOS,
>> not the least of which are Lotus 123, MS Word, Turbo C++, Turbo
>> Pascal, Wolfenstein 3D, Doom, Quake, and a bunch of ports of GNU
>> tools.
That's a fine fallacy. Many successful things have been
written for X, therefore X must be good. (Think of char*.)
Even when qualities can only be attributed to the efforts of
very good carpenters tackling knot-holes and cracks in warped
material. The "argument" omits the detail that many successful
things---and sometimes the very same things---have been written
for other OSs, too. And it omits technical scales for measuring
the qualities of technical systems such as operating systems.
At these points comparison can start, and at these points one can
actually grade OSs on a good-bad scale.
MS Word on DOS is one example. It has qualities which I have
had to learn and to explain to a few uninitiated. It has been
a major headache for many, many users of DOS computers.
ESC - transfer - load:
it takes a computer savvy person to actually understand and explain
what these notions are referring to. Yet MS sold it to the masses
They wouldn't need to write software for the masses' skill level.
The masses got used to the qualities of programs like MS Word.
In part because they did not have to pay for the software.
It was expensive to train people to use these programs
effectively.
But the masses accepted the qualities of these programs.
Mastering the programs was a moderate challenge; you could compete
with your peers. Run for MS Word mastery...
They have even built a "co-operative" multitasking graphical
Windows(TM) system on top of DOSs, yes. But suppose an Acorn Archimedes
computer had cost 1K less and that MS had not been the marketing agency
that had understood how to win cheap and sell their stuff to
office equipment suppliers. Would you still be arguing
that DOS is the good foundation? And RISC OS not a good foundation?
DOS was cheap. Technically superior solutions tended to be more
expensive at the time of purchase.
Industry was already looking at different solutions when IBM,
allegedly, wanted to sell terminals that were in need of an operating
system. Bill and Steve went to see them...
If this is true, then, obviously, industry would have chosen
differently if the choice had been by technical qualities.
> Seems right. Actually, I find Georg's assertion puzzling. The
> quality of software has to do with the experience of the people
> writing it, and with the design principles (or lack of) that the
> software developers apply or fail to apply.
The perception of operational qualities of an OS by its users
is important, too, as are the expectations that DOS has shaped.
Certainly programmers need gain experience with a specific OS.
They invest time in learning how to program a system. Then,
they want to build the well crafted software that Rugxulo has
listed. Has DOS been the better foundation among the
alternatives? Even among the simple systems?
With Tom Moran's comment in mind:
- Is DOS simple to use? Give someone an MS-DOS manual.
If they had not had prior CS training, they will end up in
despair asking neighbors for help about what it all means.
Give some kid an iPad and watch. Granted, the system is much
more capable than a DOS PC, but most concepts are deliberately
kept simple, as simple as Microsoft Bob was to be.
- Is DOS simple to program? INT 16#13# etc. being simple once you
get the idea does not mean that solutions built around interrupts
will be simple constructions. I also think that this foundation of DOS
amasses a large amount of interrupt function documentation, just like
the function libraries of alternative systems do.
And every now and then, the fine DOS hiding solutions of the
Turbo brand mentioned would remind you of the rather primitive
qualities of DOS style OSs: soft rebooting the entire system when
testing just one program that was *not* the operating system.
- More than once I had to give up a floppy or hard disk whose
FAT got shot. The BIOS would help with reading out relevant
sectors; but if the dangling pointer had hit the right sector,
no BIOS would help, A few companies were flourishing because
they provided forensic analysis and repair; had DOS had a
quality file system, PC Tools, Norton, etc. would have had
a different business plan.
But people got used to the idea that disk file storage can have
binary qualities: you can loose everything on a medium if part
of it is wrecked, or else everything is mostly fine.
A file system of different qualities means a shift in likelihood:
with more redundancy, is is more likely are that you only loose
a few files and not an entire file system. Slightly higher
cost, higher quality file system.
> The choice of OS seems to be one of the least important
> factors of all. It's really hard for me to imagine how the choice of
> DOS versus other operating systems available at the time (or
> potentially available) could have any significant impact on software
> quality at all.
For one thing, DOS effectively ruled out a number of design
patterns: you need something on top of DOS in order to
operate(!) these patterns. Such as programmable auxiliary
tasks doing background work.
I think that DOS successfully persuaded parts of the industry
that being simple implies being cheap. But DOS PCs are more
cheap than simple.
Adam Beneschan
wrote:
>
> For one thing, DOS effectively ruled out a number of design
> patterns: you need something on top of DOS in order to
> operate(!) these patterns. Such as programmable auxiliary
> tasks doing background work.
I may respond to other parts of the post, but... you do remember that
this was originally for an 8088 processor, right? Not a Pentium. I
may be wrong, but my recollection was that a lot of the task/process
functionality of the chip was added to the series later (80286?), and
wasn't present in the 8086/8088. It may not have been good enough to
support virtual addressing/paging, either, I don't know. I know it
didn't have straight 32-bit addressing. So please, before you bash
DOS too much and talk about what a mistake it was to choose it, please
consider that this may have been the best anyone could have done
within the hardware constraints. You can't really judge what should
have happened in 1980 based on the technology we have available in
2011.
-- Adam
tmo...@acm.org
> > operate(!) these patterns. =A0Such as programmable auxiliary
> > tasks doing background work.
It's true DOS didn't directly support multitasking. It also didn't
include TCP/IP or touch screens or GPUs... But you could, and did,
roll your own. We had cooperative multi-tasking and virtual memory
for code on a Motorola 6800 (two zeros, not three) in 1977 (pre-DOS).
> I may respond to other parts of the post, but... you do remember that
> this was originally for an 8088 processor, right? Not a Pentium. I
> may be wrong, but my recollection was that a lot of the task/process
> functionality of the chip was added to the series later (80286?), and
> wasn't present in the 8086/8088. It may not have been good enough to
> support virtual addressing/paging, either, I don't know.
Yes, the 286 added a bunch of fancy stuff for secure multi-tasking,
but MS didn't use it. Their great contribution was a piece of hardware
in every PC to turn off protection.
Georg Bauhaus
Extending the set of examples of how people rolled their own,
- Minix is a more elaborate OS for the IBM PC (with Intel 8088),
- Coherent OS is, too.
If I understand correctly, then a TI MSP430 is not much
different in some respects. You get a number of operating systems
for it, including 湣/OS-II which can also run on a Zilog Z80.
I'm mentioning these because, with some effort, you get
software whose qualities differ from DOS's.
Paul Colin Gloster
|--------------------------------------------------------------------------|
|"[..] |
| |
|DOS was used because of the extremely low RAM of the day (16 to 64 kb, |
|[..] |
| |
|[..]" |
|--------------------------------------------------------------------------|
All IBM PCs had much more RAM than 64 kilobytes. A Commodore 64 had 64
kilobytes and cost circa 10% as much as an IBM PC. Some Sinclair ZX81s
and Sinclair ZX Spectrums (also branded as Timex instead of Sinclair)
had 16 kilobytes of RAM and cost circa 1% and circa 3% as much as an
IBM PC, respectively.
Frank J. Lhota
IBM PCs did have more than 64 KB, but they still suffered from severe
memory limits. Memory provides an excellent example of Moore's law: in
the 1980's, memory was an order of magnitude more expensive than it is
now. Some PC's were equipped with as little as 256 KB low memory (that
is, memory for the OS and applications).
Granted, many early mainframes had even tighter memory constraints, but
many of these platforms could alleviate the memory shortage somewhat by
using temporary disk space. The first PC's could not take this approach
because disk space was even more limited than memory. The first PCs had
no hard disk. Instead, they used low-density single-sided 5 1/4"
floppies with a capacity of 180 KB.
MS-DOS has a lot of annoying limitations. But it is hard to imagine
anyone doing something much better given the constraints of the platform
that DOS was designed for.
--
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"
"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Wizard from "Tooter Turtle"
Dmitry A. Kazakov
> MS-DOS has a lot of annoying limitations. But it is hard to imagine
> anyone doing something much better given the constraints of the platform
> that DOS was designed for.
RSX-11M. I used to work with another guy on a 64K machine: two editor
sessions, two FORTRAN-IV compilers, two linkers. I must admit, that was
tough, but when we got 128K, there was no problem anymore.
When first PCs came equipped with 640K it was a shock to me how this "huge"
amount of memory was wasted. For example, at the same time a 1MB VMS
machine was used to support 6 interactive LSE-users.
(These days I cannot compile some Ada programs under Windows 32-bit XP
because GNAT runs out of the 2GB memory limit! (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Rugxulo
On May 12, 5:17 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 5/12/11 8:24 PM, Adam Beneschan wrote:
>
> > On May 12, 10:40 am, Rugxulo<rugx...@gmail.com> wrote:
>
> They have even built a "co-operative" multitasking graphical
> Windows(TM) system on top of DOSs, yes. But suppose an Acorn Archimedes
> computer had cost 1K less and that MS had not been the marketing agency
> that had understood how to win cheap and sell their stuff to
> office equipment suppliers. Would you still be arguing
> that DOS is the good foundation? And RISC OS not a good foundation?
>
> DOS was cheap. Technically superior solutions tended to be more
> expensive at the time of purchase.
PC-DOS was available first. CP/M-86 and UCSD Pascal came later and
cost more. And PC-DOS even supported a similar API as CP/M! 8086 was
8080-translatable too. And 16-bit beat 8-bit any day, considered a big
improvement. The PCs at the time just didn't have RAM for all these
fancy OSes we see now. (Apple Macintosh GUI w/ mouse didn't appear
until 1984.) When you have much less than a meg, anything will do: you
just want to get work done. Besides, DOS v1 was way different and
worse than v3.3 or especially DOS v5 (1991).
Your argument is that DOS was inferior, which may be (somewhat) true.
But any OS that people can sell software attracts developers. So to
them, money is money. The same is true today, they will plod through
all kinds of pains in order to earn a living. (I've heard the PS3 is a
pain to program, but I don't know personally.) The Wii is the weakest
of the three modern console by far, but it sold the best.
> With Tom Moran's comment in mind:
>
> - Is DOS simple to use? Give someone an MS-DOS manual.
> If they had not had prior CS training, they will end up in
> despair asking neighbors for help about what it all means.
>
> Give some kid an iPad and watch. Granted, the system is much
> more capable than a DOS PC, but most concepts are deliberately
> kept simple, as simple as Microsoft Bob was to be.
They're both the same, more or less. If you don't program a computer
yourself, everything has to be pre-made for you, a canned solution. So
it depends entirely on what is available. Clearly the iPad/iPod craze
is more about pre-made apps than rolling your own. If you want to
design your own hardware to do everything you need (no more, no less),
it'll end up quirky like Forth. But designing a one-size-fits-all like
Windows turns into a huge bloated behemoth (for good or bad) trying to
cater to 6 billion potential customers (who love to complain). Yeah,
works great if you don't mind 1+ GB of RAM (seems ridiculous, but I
guess I'm getting old, heh).
> - More than once I had to give up a floppy or hard disk whose
> FAT got shot. The BIOS would help with reading out relevant
> sectors; but if the dangling pointer had hit the right sector,
> no BIOS would help, A few companies were flourishing because
> they provided forensic analysis and repair; had DOS had a
> quality file system, PC Tools, Norton, etc. would have had
> a different business plan.
FAT is primitive, yes, and I do think DOS needs newer file systems.
FreeDOS-32 (mostly stalled) has worked on LEAN, and others exist that
would probably be somewhat better (more or less), e.g. HPFS. Even
FAT32's VFAT hacks are still patented (ugh). But anyways, the point is
that it was all an improvement at the time it was created. It's much
easier to implement FAT16 than ext2, esp. with the 1 MB limit. Of
course, nowadays anybody would reasonably create a 32-bit driver (even
under DOS) with nobody complaining. But at the time, back in the day,
that wasn't reasonable.
And by the way, there are two FATs, so ideally both wouldn't be
corrupted. And yes, obviously, you should back it up if it's that
fragile (and various tools exist that do such). Your point seems to be
"Something bad can happen, therefore it sucks." While I agree it's not
perfectly ideal, sometimes you have to take the initiative and fix or
workaround things yourself.
> A file system of different qualities means a shift in likelihood:
> with more redundancy, is is more likely are that you only loose
> a few files and not an entire file system. Slightly higher
> cost, higher quality file system.
FAT32, due to higher capacity, is much harder to cache in RAM. MS
themselves claim this as a reason for their arbitrary limits (32 GB?)
on FAT32 creation on newer Windows (though some debate these claims).
My point is that FAT16 is leaner due to inherently being smaller.
Sure, you trade off some features, but that's to keep the footprint
low.
Face it, things like Solaris' ZFS needs gigs of RAM to run reasonably,
which is why we haven't all switched to it. (And it's not GPL-
friendly, which is the only reason Linux hasn't adopted it. Bah,
license incompatibility has slowed progress.)
> For one thing, DOS effectively ruled out a number of design
> patterns: you need something on top of DOS in order to
> operate(!) these patterns. Such as programmable auxiliary
> tasks doing background work.
TSRs? :-) Novell DR-DOS 7 had true multitasking, but it needed a
386. The 286 could only do task switching (a la MS' DOSSHELL).
Desqview had a version that sorta worked on 8086, but once the 286
came out, most people stayed away from anything else.
Part of the problem is high cost of software, so people want all their
old (expensive) stuff to still work. So Bill Gates calls the 286
"braindead" for not effectively supporting switching to real mode
(e.g. for OS/2 1.x) for DOS stuff. The 386 fixed this with V86 mode,
which is one of the reasons Win 3.0 was a big success (not to mention
DPMI).
> I think that DOS successfully persuaded parts of the industry
> that being simple implies being cheap. But DOS PCs are more
> cheap than simple.
Is Linux simple? Is Linux cheap? What about Windows? Mac OS X? I'm not
sure any of those are truly cheap or easy to use. Yet that's what
we've got. In some ways, I consider all these advanced features
useless if nobody can understand how to use them. :-(
Rugxulo
(I know this isn't directly Ada-related anymore, but please indulge
me, I won't take this too much further. Hey, it's better than spam or
flames, right?)
On May 13, 2:25 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 5/13/11 12:40 AM, Adam Beneschan wrote:
>
> > On May 12, 3:17 pm, Georg Bauhaus<rm.dash-bauh...@futureapps.de>
> > wrote:
>
> >> For one thing, DOS effectively ruled out a number of design
> >> patterns: you need something on top of DOS in order to
> >> operate(!) these patterns. Such as programmable auxiliary
> >> tasks doing background work.
>
> > I may respond to other parts of the post, but... you do remember that
> > this was originally for an 8088 processor, right? Not a Pentium.
> > You can't really judge what should have happened in 1980 based on the
> > technology we have available in 2011.
Correct, please read these below for more technical info:
http://dosmandrivel.blogspot.com/
http://www.patersontech.com/dos/
BTW, Wirth (et al.) ported Modula-2 to the IBM PC way back in 1983-4
via M2M-PC. This was multi-pass and thus ran in 64 kb of RAM. Even his
later ('80s) Oberon System was ridiculously low on RAM, which is
anathema to todays "gigs of RAM" mentality. His "Plea for Lean
Software" (1995) obviously fell on deaf ears. I've never heard him
comment on AMD64 and the plethora of gigs we all have now. Now, don't
get me wrong, it's impossible to complain about *having* that much
RAM, only that a). we don't need it, and b). software still is never
satisfied, always eating more and more. Heh, it's funny to think that
even the XBox 360 or iPad 2 only have 512 MB of RAM. (What does latest
iPod have, 256 MB? I think so, but I forget.) Eventually everything
will have to have 20 GB or "it sucks"!
Well, my point is this: if people survived 20-30 years ago with much,
much less, why can't we (today)??? I don't think DOS is perfect, but I
do think its software should be preserved, and compatibility to
actually run it (or other OS binaries) would be nice, esp. without
needing literally billions of bytes of RAM.
EDIT: This is all just way off-topic, sorry! But hey, I noticed
yesterday that somebody ported DOSBox (portable C/C++ x86 emulator,
SDL) to pure Java, and it runs (DOS original) Doom (1993, 386 pmode,
Watcom + DOS/4GW ... used self-modifying code, he says, ick) full-
speed! http://jdosbox.sourceforge.net/
> Extending the set of examples of how people rolled their own,
> - Minix is a more elaborate OS for the IBM PC (with Intel 8088),
> - Coherent OS is, too.
Did they exist in 1982?? I don't think Minix did, and also Minix was
not free either (though admittedly cheaper than some of the other
choices). Besides, last I checked, Minix 2.0.2 was the last to truly
run on 8086, and that release is (I think) circa 1998. In other words,
if it wasn't available at the same time, it doesn't compare.
> If I understand correctly, then a TI MSP430 is not much
> different in some respects. You get a number of operating systems
> for it, including µC/OS-II which can also run on a Zilog Z80.
>
> I'm mentioning these because, with some effort, you get
> software whose qualities differ from DOS's.
There was also OS/2, which was the intended successor of DOS and
Windows. MS and IBM collaborated during 1987 to 1991 on the 1.x series
(16-bit pmode, 286). Eventually it didn't work out, esp. since Win 3.0
was a big success and clashed with the IBM mentality. But even Win 3.x
eventually became 386 only, which led the way to Win9x (which still
ran atop DOS). Only with Win XP (2001) did MS really drop DOS
completely for home users (though emulation still existed due to 386's
V86 mode). But MS even now calls XP "old and deprecated"!! And AMD64
is the borg to assimilate everything else (sigh, no V86 mode, but VT-X
helps).
It's not that there is no progress, just it has good and bad qualities
and takes a long time. It's just one of my pet peeves that everything
old is automatically "good for nothing". For some reason, only the
latest/greatest is approved ... until it becomes old hat, then it's
tossed aside like garbage, even when it works!
Georg Bauhaus
> Well, my point is this: if people survived 20-30 years ago with much,
> much less, why can't we (today)??? I don't think DOS is perfect, but I
> do think its software should be preserved, and compatibility to
> actually run it (or other OS binaries) would be nice, esp. without
> needing literally billions of bytes of RAM.
Preservation and compatibility is where standards will help.
In the long run, they lead to more portable programs.
Alas, the belief system of entrepreneurs includes the golden rule
that in the long run we (the rational actors) are all dead. I.e.,
our co-entrepreneurs have sold something to customers before
we could. Therefore, we must produce the fastest,
cheapest programs, and quickly. Hence, software either relies on OS's
bells and whistles, or uses clunky libraries or frameworks,
is written duct tape style, drops abstraction,
and cannot easily be adapted to a new operating systems.
Am I wrong? At least as regards NGOs' software production?
In the long run, it does seem possible to recompile SNOBOL-4 programs,
Scheme programs, or Ada programs, even some C programs without making
many changes. If many changes mostly concern presentational
style of user I/O, not desired "computational" functions (if there is
one besides making an audiovisual impression) we should have
abstractions for the functions in the design of programs. Then, DOS
or gLitzOS is just a choice.
I guess that, given an Algol compiler, we might simply feed it a
50 years old program and run the executable. I cannot suppose
that Cobol programs reflecting much domain knowledge are dropped,
or even gradually replaced. In fact, the Microfocus compilers will
produce Java byte code, no need to make old programs run on virtual
machines that execute Cobol byte code.
(I think the banks are using VMs for some VMS programs, at least
until these will have been completely ported to contemporary
platforms.)
What is the fraction of DOS programs that you could just
recompile?
Since we cannot hope that time-to-market gets lower
priority, and since both appearance and price do matter,
application programmers can't survive the way normal
application programmers did 20-30 years ago.
Unless retro style changes the situation :-)
>> Extending the set of examples of how people rolled their own,
>> - Minix is a more elaborate OS for the IBM PC (with Intel 8088),
>> - Coherent OS is, too.
>
> Did they exist in 1982??
AFAICT, Coherent was ported to 8088 in 1983.
Minix came later, the book being published in 1987.
> It's not that there is no progress, just it has good and bad qualities
> and takes a long time. It's just one of my pet peeves that everything
> old is automatically "good for nothing". For some reason, only the
> latest/greatest is approved ... until it becomes old hat, then it's
> tossed aside like garbage, even when it works!
There was a time when DOS on an IBM PC was considered the latest/greatest.
So was Ada. Frankly, I'd rather have Ada preserved than DOS.
Randy Brukardt
>On May 11, 7:45 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> "Rugxulo" <rugx...@gmail.com> wrote in message
>>
>> news:291504a4-ec55-45f1...@m10g2000yqd.googlegroups.com...
>>
>> >On May 5, 4:12 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> >> Better, dunno. Janus/Ada 95 (32-bit only) would be updated if anyone
>> >> wanted
> >> it, but no one has asked. (It's still in our pricelists.)
>>Updated how?
>>
>> Just recompiled and tested. It might need some runtime updates, but
>> probably
>> not a lot.
>
>What for? Improvements or just to remove the bitrot?
To bring it to the same level of support as the rest of our compilers, of
course. If no one wants new features, we'd be happy to send them the old
one...
>> All of our Ada 95/2005/2012 technology is from a common codebase,
>> so building the DOS version just means selecting the right configuration
>> and
>> recompiling. (And lots of testing and probably a bit of debugging.)
>
>Ah, testing, the biggest time waster. Luckily, Ada has a public test
>suite.
Testing Ada compilers is easy (it's been automated for years). Fixing
problems uncovered is not so easy.
>> The biggest problem with it is that the DOS extender we used didn't work
>> with NT and afterwards. (It actually works precisely once, then you have
>> to
>> reboot before it will work again. Not very practical.)
>
>Was it a special homebrew one or one of the popular ones licensed?
Dunno if it was popular, but it was licensed. Something called "Ergo"
(Pharlap was too expensive to license; the compiler output would work them
as well, especially good for embedded systems and the like.)
>(What brand name?) Well, either way, I'm not surprised. Half the time
>the extenders were buggy, but the other half was due to XP limitations
>and bugs. (BTW, I assume you meant close/reopen the DOS window, but if
>you meant reboot the computer/OS, that's worse! Ugh.)
No, I meant reboot. The extender does something to the global selector map
such that subsequent runs fail. It's possible that XP would work better (I
never tried it on XP), but on NT and Windows 2000 it required a reboot after
each run before you could run another program with it. It didn't cause any
other problems (you didn't have to reboot if you didn't want to run some
other program).
When I reported the problem to the vendor, their response was to go out of
business. :-) Of course, we didn't have to spend any more money on
maintenance after that, and since it worked great on Windows 95 and 98, we
continued to use it well transitioning to all Windows. Once we moved most of
our desktops to Windows 2000, we moved the development to Windows itself. (I
think we were pretty much the last DOS customer we had anyway.)
...
...
>> I think 1985 was well before DPMI, and probably was before expanded and
>> extended memory, too. This probably was a basic 640K compiler (I don't
>> think
>> we even had 640K in our machines at the time - our original IBM PC/XT
>> started with 256K, and I think the Seattle Computer 10 MHZ 8086 [much
>> faster
>> than the PC] had about that as well).
>
>Right, sorry, I knew that. Though there were 286 extenders by then,
>but the 386 didn't even come out until 1986 or so (and took a while to
>get adopted). Real EMS existed, of course, as did XMS, but it was
>fairly rare. Even in 1994, my new PC only had 4 MB of RAM! My, how
>times have changed. :-O
>
>But yeah, VCPI (386+) was 1986, DPMI (286 or 386) was 1990. And I hear
>that SCP-8086 could use the full 1 MB (unlike IBM's 640 kb). I assume
>this means yours was a multi-pass compiler (a la Wirth's old M2M /
>Modula-2). But maybe not, perhaps you crammed a lot into "256K" (Ada83
>only probably made it easier).
Our original compilers ran on Z80 CP/M systems -- in as little as 48K of
memory. Even I can't imagine doing that today, and I know that we did it...
Obviously, we put as much on disk as we could, but since the disks were
floppies, that wasn't a perfect solution either.
The Seattle S-100 system had two 1.2M floppies. They were more practical
than early hard disks, because you had unlimited storage. I usually kept one
disk for the OS, compiler, basic tools, and commonly shared files, and the
other disk had the source code and object files for whatever program or part
of a program I was working on. Lots of disk swapping, but otherwise worked
great.
>> >Unfortunately, Windows has gone downhill (in DOS support) since XP,
>>
>> You could have just left out the parenthetical remark, and you still
>> would
>> have been right. ;-)
>
>More or less, yes. I know MS thinks XP is old and wants to deprecate
>it, but it seemed fine to me. But I'm sure some fringes had various
>complaints about it that only Vista or 7 solved. I'm not Windows-y
>enough to know, honestly. (But I do think they charged too much for
>Vista -> 7 ["minor"] upgrade.)
I don't want to have to learn a new interface every couple of months, which
is the Google approach to software. (We can move buttons around anytime we
want.) Sadly, people like Firefox are trying to copy that brain-damaged
approach. (Firefox 4 seems to have moved things mostly for the sake of being
different. It took me a couple of days to figure out where "Organize
Bookmarks" and "Reload page" had gone. Grumble.
...
>> That's one of the reasons I'm not moving most of my work to Windows 7
>> anytime soon. I still use a number of DOS programs regularly, including a
>> circa 1986 programming editor.
>
>I'm surprised, honestly, most people spit on the idea of (still) using
>DOS software. But not me! ;-) Windows 7 32-bit probably (somewhat)
>works for DOS, as I know Vista 32-bit barely did (some bugs, DPMI
>registry hack needed, no full screen gfx).
>
>Though I wonder at using such an old editor, but I know people like
>what they like, so I can't complain. (Text editors are a dime a dozen
>but none do everything, not even Emacs or VIM. Check out
>http://www.texteditors.org
>sometime for a laugh.)
Reasons: familar (to me at least) keyboard interface, no mouse fru-fru,
optional rectangle marking (great for editing text in columns), find/replace
in any selection (including rectangles), list view for find (shows all
matches at once, great for finding stuff when you aren't sure what you're
looking for), convinient macro facilities (by recording).
Disadvantages: DOS :-), limited window size (80x25 isn't always big enough),
limited fonts (whetever you can adjust the console window to show), little
integration with Ada, bugs cause crashes (but of course I know what not to
do, so it those only happen when I'm careless).
I'd build a replacement using Claw and Ada if I had time, but I wonder if
the result would really work as well.
Randy.
Randy Brukardt
news:3bae2d75-31b0-4a88...@z7g2000prh.googlegroups.com...
...
>Seems right. Actually, I find Georg's assertion puzzling. The
>quality of software has to do with the experience of the people
>writing it, and with the design principles (or lack of) that the
>software developers apply or fail to apply. Carefulness is a factor,
>of course. The choice of language is a smaller factor, but as we know
>on c.l.a a language can help support or hinder good software design
>principles. Hardware limitations can be a small factor, since it's
>harder to write good quality software when your memory space is
>limited. The choice of OS seems to be one of the least important
>factors of all. It's really hard for me to imagine how the choice of
>DOS versus other operating systems available at the time (or
>potentially available) could have any significant impact on software
>quality at all.
Considering that DOS really didn't do anything other than provide a
bootstrap mechanism, simple file system, and program loader, it's hard to
blame it for anything. Put a well-designed Ada system on top and it was as
reliable as any other OS I've worked on. Put junk on top, well, the OS isn't
going to stop it from being junk!
Randy.
-- Adam
Randy Brukardt
news:4dcc5c75$0$6891$9b4e...@newsspool2.arcor-online.net...
...
> MS Word on DOS is one example. It has qualities which I have
> had to learn and to explain to a few uninitiated. It has been
> a major headache for many, many users of DOS computers.
> ESC - transfer - load:
> it takes a computer savvy person to actually understand and explain
> what these notions are referring to. Yet MS sold it to the masses
> They wouldn't need to write software for the masses' skill level.
> The masses got used to the qualities of programs like MS Word.
> In part because they did not have to pay for the software.
I don't think MS-Word was ever available on plain MS-DOS. You might be
thinking of Wordstar or Wordperfect (separate programs by other companies
that had many fans).
Anyway, you are getting to my pet peeve here: an OS has absolutely nothing
to do with the quality of the user experience. No one outside of programmers
should be using an OS at all! What matters to the ordinary user is the
programs running on top of the OS.
Stuff like GUIs have nothing whatsoever to do with the OS and should not be
considered part of it. Perhaps it makes sense to *sell* these things as a
bundle, but they don't have much too do with the OS.
Randy.
Randy Brukardt
...
>> - More than once I had to give up a floppy or hard disk whose
>> FAT got shot. The BIOS would help with reading out relevant
>> sectors; but if the dangling pointer had hit the right sector,
>> no BIOS would help, A few companies were flourishing because
>> they provided forensic analysis and repair; had DOS had a
>> quality file system, PC Tools, Norton, etc. would have had
>> a different business plan.
>
>FAT is primitive, yes, and I do think DOS needs newer file systems.
But it was ways better that the floppy file system in CP/M, especially the
original everything is stored in 128 byte blocks file system!
And floppies fail often. And sometimes they fail so you can't read the
directory. You have to expect that, and I don't think any file system could
really protect against that (RAM backup makes no sense for floppies, since
their whole advantage is the ability to change them and move them).
In any case, it's silly to look at DOS, designed around 1980, and make
assumptions about it based on what we can do today with a 5000 times more
memory and a processor that is 5000 times faster.
Randy.
Adam Beneschan
>
> > On May 12, 10:40 am, Rugxulo<rugx...@gmail.com> wrote:
>
> >>> Rather, adopting DOS seems quite
> >>> frankly the most far reaching mistake that computer dependent
> >>> industry has committed, the consequences being loss of both
> >>> software quality and---far worse---a collective loss of any knowledge
> >>> of what quality software might be!
>
> >> Not true. Quality software can be written on any OS. "A poor carpenter
> >> blames his tools." Many successful things have been written for DOS,
> >> not the least of which are Lotus 123, MS Word, Turbo C++, Turbo
> >> Pascal, Wolfenstein 3D, Doom, Quake, and a bunch of ports of GNU
> >> tools.
>
> That's a fine fallacy. Many successful things have been
> written for X, therefore X must be good. (Think of char*.)
> Even when qualities can only be attributed to the efforts of
> very good carpenters tackling knot-holes and cracks in warped
> material. The "argument" omits the detail that many successful
> things---and sometimes the very same things---have been written
> for other OSs, too. And it omits technical scales for measuring
> the qualities of technical systems such as operating systems.
That argument is itself a fallacy, because it's a strawman. We
weren't arguing that DOS is "good". At least I wasn't. Rather, I was
trying to argue that DOS's goodness or badness can't be blamed for
poor quality of software written for it; you claimed that it did, but
you haven't made a case.
I've been in the programming business for 35 years and have worked on
a number of different platforms---different OS's, different
processors, and using different languages. And in every case, I've
seen both good quality and horrible quality software. The good
quality software is written by programmers with both understanding of
what it takes to produce good quality software, and an attitude that
makes them willing to spend the extra effort needed to produce it.
Programmers that lack one of these aren't going to write good quality
software. And changing the OS that the programmer is working with
isn't going to change that. A good programmer isn't going to suddenly
write bad code because he has to work on a worse OS. I can imagine
that, in some cases, the lack of certain features may make it a little
more difficult to accomplish certain things; but a programmer with the
knowledge and attitude needed to write quality software will cope,
perhaps by setting up a building block of some sort (such as a
subroutine or some other tool) to make up for the lost feature. (Most
of the software I've written just needs file I/O anyway.) And
clearly, if a programmer does not have the knowledge needed to write
quality software, or has a careless attitude, moving to a better
quality OS is not going to rectify this at all. (A better programming
language *can* help somewhat, I think, although I've certainly seen
plenty of hack code written in Ada.) This is what I've seen in my
years in this business. That's why the idea that adopting DOS
resulted in "loss of software quality" just makes no sense to me.
One argument you seemed to make was that DOS lowered users'
expectations, and that led to lower quality software. I don't think
this makes sense either. First of all, you cited Minix (based on
Unix) as an example of a higher-quality OS you would have preferred.
However, whatever advantages Unix has, user-friendliness is not one of
them. And it makes no sense to me that a user who types in "copy
a.txt b.txt" to copy a file would have lower expectations but that
making him type "cp a.txt b.txt" would suddenly lead her to demand
higher-quality software. But second, the PC came on the market right
about the time the public was ready for something like that, and
suddenly lots of people were buying home computers and they needed
software. So whatever came out first would have been what they used.
Whatever poor-quality software might have been out there was probably
because it was written quickly and carelessly because there wasn't
anything else available. I don't think DOS had anything to do with
that. The situation would have been the same regardless of what OS
was picked for the PC.
So to sum up the points you made:
(1) "adopting DOS seems quite frankly the most far reaching mistake
that computer dependent industry has committed": as you pointed out
later, Coherent OS wasn't available until 1983 and Minix not until
1987---and I think it's likely no one would have spent the effort on
those if the PC hadn't already become wildly popular. Anyway, since
there wasn't much out there in 1981, I don't think you can call it a
"mistake"---and especially not the colossal mistake you want to
portray it as---unless you can suggest a better course of action they
could have taken---and what would that be? Put the PC back on the
shelf and bury it until someone wrote a better OS for it?
(2) a consequence of adopting DOS is "loss of ... software quality":
see above, I don't think this is true.
(3) a consequence of adopting DOS is "a collective loss of a knowledge
of what quality software might be". Ummm ... this just seems silly.
Software quality has been improving, research into how to improve
software quality has been continuing, so a statement like this seems
more like a hyperbolic rant than a serious criticism.
Anyway, I think that's all I'll say on this.
-- Adam
Yannick Duchêne (Hibou57)
>> Is there anything inportant that you can do in DOS that you can't do
>> in a Windows console program or a standard Linux program?
>
> Sure, run in DOS! :-))
>
> (self-modifying code? direct hardware access? run in less than 10 MB
> of RAM? call the BIOS?)
limit of 1MB.
--
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]
Yannick Duchêne (Hibou57)
> Most Linuxes aren't geared towards low RAM, esp. nowadays (2.6
> kernel).
Just to know, what would you suggest as an OS really targeting low specs ?
(and as much as possible, coming with an Ada compiler)
Yannick Duchêne (Hibou57)
écrit:
> It's really hard for me to imagine how the choice of
> DOS versus other operating systems available at the time (or
> potentially available) could have any significant impact on software
> quality at all.
>
> -- Adam
Yannick Duchêne (Hibou57)
> TSRs? :-) Novell DR-DOS 7 had true multitasking, but it needed a
> 386. The 286 could only do task switching
task switching" ? Did you meant preemptive vs cooperative ?
Yannick Duchêne (Hibou57)
a écrit:
> Anyway, you are getting to my pet peeve here: an OS has absolutely
> nothing
> to do with the quality of the user experience.
think of IPC, clipboard, and the likes. You rarely use a single
application only, you typically use two or three, which will have to
communicate in some way. The environment (if not strictly the OS), matters
here.
Yannick Duchêne (Hibou57)
> A few years ago an NTFS disk became corrupted and Windows stuck its
> nose
> in the air and pretended it didn't exist. So I got out my old Janus DOS
> compiler and, accessing disk sectors via the BIOS, was able to copy
> almost everything.
> More generally, hardware is simple - a few pages would tell you
> everything you needed to know about, say, DMA. Today you need to learn
> a massive library even to do a simple thing, and then spend a lot of time
> discovering what the docs left out or lied about.
I agree :( and I feel that's a design mistake
> I suspect programmers
> today spend much more time gathering information and much less time
> creating programs.
I suspect no programmers of widely used systems (Windows, Linux kernel,
MySQL, and so on) understand the whole of these systems (another matter
too). May be that's one of the reason of these permanent increases of
resources consumption ?
Yannick Duchêne (Hibou57)
a écrit:
>> Ah, testing, the biggest time waster. Luckily, Ada has a public test
>> suite.
>
> Testing Ada compilers is easy (it's been automated for years).
Vinzent Hoefler
> Le Tue, 10 May 2011 23:36:59 +0200, Rugxulo <rug...@gmail.com> a écrit:
>>> Is there anything inportant that you can do in DOS that you can't do
>>> in a Windows console program or a standard Linux program?
>>
>> Sure, run in DOS! :-))
>>
>> (self-modifying code? direct hardware access? run in less than 10 MB
>> of RAM? call the BIOS?)
> Run in less than 1MB. Natively, it could not access memory beyond the
> limit of 1MB.
That's not entirely accurate. Not even speaking of EMS or XMS, first there
was the HMA, which added almost 64K (anyone remember A20?), then the big
real (aka. unreal) mode was "invented". 32-Bit addressing required, but
you could access the full 4 GB under native DOS. Good ol' times where I
still knew every single interrupt or port address and it's purpose. ;)
Vinzent.
--
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
-- Waldi Ravens
Vinzent Hoefler
> Le Thu, 12 May 2011 15:28:34 +0200, Rugxulo <rug...@gmail.com> a écrit:
>> Most Linuxes aren't geared towards low RAM, esp. nowadays (2.6
>> kernel).
> And what about the glibc...
>
> Just to know, what would you suggest as an OS really targeting low specs ?
> (and as much as possible, coming with an Ada compiler)
That depends on the application. If you need fancy GUIs, you're probably out
of luck (well, QNX seem to do quite ok when I still knew it a bit), but for
the usual embedded (real-time) control stuff there are some choices.
Rugxulo
On May 13, 7:03 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> news:c31b2969-0e79-44c6...@z13g2000prk.googlegroups.com...
>
> >On May 11, 7:45 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> >> "Rugxulo" <rugx...@gmail.com> wrote in message
>
> >>news:291504a4-ec55-45f1...@m10g2000yqd.googlegroups.com...
>
> >> >On May 5, 4:12 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> >> The biggest problem with it is that the DOS extender we used didn't work
> >> with NT and afterwards. (It actually works precisely once, then you have
> >> to reboot before it will work again. Not very practical.)
>
> >Was it a special homebrew one or one of the popular ones licensed?
>
> Dunno if it was popular, but it was licensed. Something called "Ergo"
Fairly popular, I've definitely heard of it, but I don't have any
experience with it, personally. There are so many extenders, all with
quirks, even ones that stick to the DPMI "standard". Hence, I'm not
surprised that using one extender (even built-in to the OS) works
better than separately.
> No, I meant reboot. The extender does something to the global selector map
> such that subsequent runs fail. It's possible that XP would work better (I
> never tried it on XP),
Doubt it, 2k and XP were almost identical in most ways re: DOS
emulation. You'd have to ask the resident DJGPP expert (CWS) if he
knew anything about it. Unlikely he remembers that far back, but he
seems to know all the quirks of DPMI vs. WinNT! But if it's a bug in
NTVDM, there's no chance of fixing it. :-(
> When I reported the problem to the vendor, their response was to go out of
> business. :-) Of course, we didn't have to spend any more money on
> maintenance after that, and since it worked great on Windows 95 and 98, we
> continued to use it well transitioning to all Windows. Once we moved most of
> our desktops to Windows 2000, we moved the development to Windows itself. (I
> think we were pretty much the last DOS customer we had anyway.)
It's sad to me that modern Windows can't (or won't) run any older
stuff like OS/2 or DOS binaries (or even Win16) anymore.
> I don't want to have to learn a new interface every couple of months, which
> is the Google approach to software. (We can move buttons around anytime we
> want.) Sadly, people like Firefox are trying to copy that brain-damaged
> approach.
Unity? Gnome 3? KDE 4? MS Office ribbon? It's like people can't wait
to invent yet another "better" (but incompatible) way of doing things.
> >Though I wonder at using such an old editor, but I know people like
> >what they like, so I can't complain.
>
> Reasons: familar (to me at least) keyboard interface, no mouse fru-fru,
> optional rectangle marking (great for editing text in columns), find/replace
> in any selection (including rectangles), list view for find (shows all
> matches at once, great for finding stuff when you aren't sure what you're
> looking for), convinient macro facilities (by recording).
>
> I'd build a replacement using Claw and Ada if I had time, but I wonder if
> the result would really work as well.
Nah, you can probably find a good existing replacement. Most people
would say just use GNU Emacs or VIM. Even JED, JOE, FTE are all good.
Personally, it sounds like the one I use might suit your needs, and
it's even portable and p.d. See TDE : http://adoxa.110mb.com/tde/index.html
Rugxulo
On May 14, 8:52 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Fri, 13 May 2011 22:12:37 +0200, Rugxulo <rugx...@gmail.com> a écrit:> TSRs? :-) Novell DR-DOS 7 had true multitasking, but it needed a
> > 386. The 286 could only do task switching
>
> Pease, what difference do you see between "true multitasking" and "only
> task switching" ? Did you meant preemptive vs cooperative ?
Rugxulo
Hmmmm, that wasn't quite what I meant. See below:
http://en.wikipedia.org/wiki/Computer_multitasking
http://en.wikipedia.org/wiki/DR-DOS
"DR DOS 6.0 also includes a task-switcher named TASKMAX, supporting
the industry standard task-switching API to run multiple applications
at the same time. In contrast to Digital Research's Multiuser DOS
(successor of Concurrent DOS in the multi-user products line), which
would run DOS applications in pre-emptively multitasked virtual DOS
machines, the DR DOS 6.0 task switcher would freeze background
applications until brought back into the foreground. While it runs on
x86-machines, it is able to swap to XMS memory on 286+ machines."
Rugxulo
On May 13, 3:12 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> Part of the problem is high cost of software, so people want all their
> old (expensive) stuff to still work. So Bill Gates calls the 286
> "braindead" for not effectively supporting switching to real mode
> (e.g. for OS/2 1.x) for DOS stuff. The 386 fixed this with V86 mode,
> which is one of the reasons Win 3.0 was a big success (not to mention DPMI).
http://en.wikipedia.org/wiki/80286
"This limitation led to Bill Gates famously referring to the 80286 as
a "brain dead chip",[5] since it was clear that the new Microsoft
Windows environment would not be able to run multiple MS-DOS
applications with the 286."
5. ^ Microprocessors: A Programmer's View, Robert B. K. Dewar and
Matthew Smosna, New York: McGraw-Hill, 1990, ISBN 0-07-016638-2
Wait a minute, I don't even know Ada (yet), but is this the same
Robert Dewar known from it?? Funny stuff. (A quick search shows that
he dropped off comp.lang.ada about 9 years ago.) :-)
Niklas Holsti
> Wait a minute, I don't even know Ada (yet), but is this the same
> Robert Dewar known from it?? Funny stuff. (A quick search shows that
> he dropped off comp.lang.ada about 9 years ago.) :-)
But he did not abandon the Ada world, quite the opposite. Quoting from
http://www.adacore.com/home/company/exec_team/: "Dr. Robert Dewar is
co-founder, President and CEO of AdaCore and Emeritus Professor of
Computer Science at New York University."
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Randy Brukardt
news:op.vvg56igtule2fv@douda-yannick...
Le Sat, 14 May 2011 02:03:06 +0200, Randy Brukardt <ra...@rrsoftware.com>
a écrit:
>>> Ah, testing, the biggest time waster. Luckily, Ada has a public test
>>> suite.
>>
>> Testing Ada compilers is easy (it's been automated for years).
>ACATs or something else ?
ACATS plus our own in-house test suite. The setup mostly dates from the
mid-1980s (once we had large enough hard disks to contain complete test
runs), many of the tests are newer of course.
Randy.
Randy Brukardt
>Le Sat, 14 May 2011 02:17:03 +0200, Randy Brukardt <ra...@rrsoftware.com>
>a écrit:
>> Anyway, you are getting to my pet peeve here: an OS has absolutely
>> nothing to do with the quality of the user experience.
>Formally, may be the OS (say, the kernel) don't, but the environment do:
>think of IPC, clipboard, and the likes. You rarely use a single
>application only, you typically use two or three, which will have to
>communicate in some way. The environment (if not strictly the OS), matters
>here.
Sure, the environment has an effect on the usability. But as you see with
Linux, the environment has little to do with the OS itself (it seems to
change frequently for Linux). As I said, it might make sense for marketing
reasons to treat these as the same thing, but it should be possible to
consider the OS separately from the environment.
Randy.
Paul Colin Gloster
|--------------------------------------------------------------------|
|"[..] |
| |
|[..] |
|[..] it's impossible to complain about *having* that much |
|RAM, only that a). we don't need it, and b). software still is never|
|satisfied, always eating more and more. [..] |
|[..] |
| |
|[..]" |
|--------------------------------------------------------------------|
I am not able to store every desirable number in a look-up table
because with gigabytes of RAM I still have too little memory.
Paul Colin Gloster
|----------------------------------------------------------------------|
|"[..] |
| |
|Face it, things like Solaris' ZFS needs gigs of RAM to run reasonably,|
|which is why we haven't all switched to it. [..] |
|[..] |
| |
|[..]" |
|----------------------------------------------------------------------|
ZFS is dangerous. For example, "Re: ZFS pool question",
Thu, 25 Dec 2008 12:59:32 +0000,
news:Pine.WNT.4.64.0812251153260.11884@abril
Do not use ZFS.
Yannick Duchêne (Hibou57)
>> I don't want to have to learn a new interface every couple of months,
>> which
>> is the Google approach to software. (We can move buttons around anytime
>> we
>> want.) Sadly, people like Firefox are trying to copy that brain-damaged
>> approach.
>
> Unity? Gnome 3? KDE 4? MS Office ribbon? It's like people can't wait
> to invent yet another "better" (but incompatible) way of doing things.
made of HTML+CSS+JS (sorry, but JS here is unavoidable). This is not well
suited for application with kind of real-time feed-back requirements, but
that should be good enough for many thing (as long as communication via
sockets, between the UI and the core application, is not a trouble… this
also intensively consume serialization/deserialization). To be honest,
another drawback, is also the keyboard support (that's a real nightmare to
properly handle the keyboard in a browser).
Yannick Duchêne (Hibou57)
<0439279208b62c95...@t-domaingrabbing.de> a écrit:
> That's not entirely accurate. Not even speaking of EMS or XMS, first
> there
> was the HMA, which added almost 64K (anyone remember A20?), then the big
> real (aka. unreal) mode was "invented". 32-Bit addressing required, but
> you could access the full 4 GB under native DOS. Good ol' times where I
> still knew every single interrupt or port address and it's purpose. ;)
controller port). That was not so much handy, as this required a kind of
memory bank switching, just like the one there use to be on even older
computers (I learned it later, I was too much young at that time). Native
DOS was still 16 bits.