DRDOS 6.0 any good? (Neanderthal)
Tom Bielecki
He couldn't decided between 6.2 and DRDOS, I can see why, they
are both horrible OS's. I've NEVER seen an OS as neanderthal
like as DOS, and any of the other variants. I'll just stick to unix to
get my work done in what would take EONS if attempted in a DOS
fashioned environment.
Tero Pekka Mustalahti
Actually the neanderthals (Homo sapiens neanderthalensis) had LARGER
brains than we (Homo sapiens sapiens)...Well, I admit, MSDOS is
a terrible OS (but then again, what can you expect from on OS that
was originally designed to run on a 8088 CPU?)
Tero P. Mustalahti
Howard Harvey
You are bringing up two separate subjects here:
1. MSDOS V6.2 VS DRDOS V6.0
There is not a lot between the two OS, other than the fact that DRDOS V6.0
has been out for 2 years! Who copied who? Remember that MSDOS V6.0 was
some 18 months behind DRDOS V6.0 and still didn't get it all right. OK, OK,
I hear you say I am favouring DRDOS - and you're right. I run both OS and
prefer DRDOS. XCOPY and MOVE are both much easier to use, SUPERPCK can be
better optimised, with a manual that gives considerable detail. MSDOS
still doesn't have password protection, nor does it have that very handy
batch command IF DIREXIST ... (The trouble here is that to write a truly
portable batch file requires reduction to the lowest common denominator)
2. xxDOS VS U**X
We are now comparing a memory restricted (RAM and Disk) monitor, which is
really all MSDOS is, with a full blown OS. The facilities of U**X are
quite obviously far better, but it is only in recent times that we could
privately afford a 350MB HDD with restricted hardware options with
appropriately inflated prices. At least LINUX is providing some semblance
of U**X for the masses. Maybe UNIXWARE will do the same thing, but once
again at around 4 times the cost and needing a more powerful PC to support
it. One of these days I will ... ... ...
Howie
and ??DOS VS U**X
Azael Barrera
the installantion/setup of MS-DOS5.0/6.x specific programs. MS is going
all ahead convincing developers to use the 5.0/6.x data structure and
especifically check for version/type of OS with low level routines, so
you have the dilemma... DR DOS 6.0 was originally conceived as 3.31
fully compatiblem, not 5.0. And for one PC which came with DR DOS 6.0
I have had trouble intalling MS Visual C++; Novell sent two patch disks
and... PUF, nada. The same problem. And this is general trend going on
among big developers. MS itself is doing it with high level products (as
compilers, etc.). I heard a similar situation with MASM 6.x/7.x. And who
knows about PowerStation Fortran (here MS stole a trademark of IBM, regarding
the name of some RISC/6000 workstations ?).
I send a very "deep" comment fax to Novell: I don't think they will give a
free copy of 7.0 (as sometimes WordPerfect does, when they had fixed your
problem, even before you called they may give you the software for free).
I guess Novell is having trouble at the management level: the way they
took over Digital Research and fired some key people, hasn't been good for
the future of their DOS/OS at th desktop level.
A.Barrera..
P.S.:I am investigating the possibilities about the IBM PCDOS 6.1 about
compatibiities on MS-DOS 5.0 specific programs. I think is a better product
than DR DOS 6.0 and MS DOS 6.1/.2. At least it will run in a POWER-PC
equiped pc, together with AIX. :=O (wow!)
The Blue Beetle
: I took a brief look at it over at a friends, and was hardly impressed.
True, DOS is no where near UNIX in terms of power and flexibility.
But just for comparing between different versions of DOS, the issue
becomes much simpler. Dump Microsoft DOS. Go with DRDOS 6.0 or Novell DOS
7 (its succesor). Both implement DOS like never before, and Novell DOS 7
now can boast of multitasking, and peer-to-peer networking built-in,
which brings it closer to UNIX :)
*The Blue Beetle*
Team OS/2!
ps - of course, you should try to use OS/2.
Frank Slootweg at CRC
for, but:
> Subject: Re: DRDOS 6.0 any good? (Neanderthal)
Can be, totally unbiased :-), answered with the counter question: Is
Cindy Crawford good looking?
tbie...@tusol.cs.trinity.edu (Tom Bielecki) writes:
> I took a brief look at it over at a friends, and was hardly impressed.
> He couldn't decided between 6.2 and DRDOS, ...
Even while DR DOS 6.0 is more than two years old, and MS-DOS 6.0/6.2
are (relatively) new, DR DOS 6.0 has lots, lots of features which MS-DOS
6.2 does not have. Just have a look in (one of the earlier sections of)
a DR DOS 6.0 manual and judge for yourself. From memory, the most
noticeable ones are the security features, better DISKCOPY/DISKCOMP,
etc.. The only features, I am aware of, which MS-DOS 6.X has, which DR
DOS 6.0 does not have, are a backup utility (other than BACKUP/RESTORE)
and an anti-virus utility. Of course these utilities are included in the
successor of DR DOS 6.0, Novell DOS 7.0.
> I'll just stick to unix to
> get my work done in what would take EONS if attempted in a DOS
> fashioned environment.
Try the MKS Toolkit for ??[ -]DOS from Mortice Kern Systems. It
contains DOS versions of many, many UNIX commands. You can even login
with a password, and, unless you want to, hardly have to know that you
are running on top of DOS, instead of on a UNIX kernel. Highly
recommended.
Frank Slootweg, UNIX support person and PC owner.
Frank Slootweg
> What scares me is the fact that DR DOS 6.0 is having problems to allown
> the installantion/setup of MS-DOS5.0/6.x specific programs. MS is going
> all ahead convincing developers to use the 5.0/6.x data structure and
> especifically check for version/type of OS with low level routines, so
> you have the dilemma... DR DOS 6.0 was originally conceived as 3.31
> fully compatiblem, not 5.0.
*IF* Microsoft is indeed doing that, and *IF* some "developers" follow
that "advice", then you know that you should stay away from the products
of such "developers". If they can not get this compatibility issue
right, then what confidence do you have that the rest of their product
is any good?
I can not come up with one good reason for a program to be able to run
on MS-DOS 5.0/6.X, but not on a 3.3? "clone" like DR DOS 6.0. I doubt
that Microsoft and/or these "developers" can.
I had very little problems using software on DR DOS 6.0, even for
those which were labeled with "Requires MS-DOS 5.0 or higher." or worse.
One problem was solved with a patch from Novell, the other by working
around the application suppliers bug.
Azael Barrera
Frank and others;
Apparently those *IF* are true. Some Setups programs, especially those
from latest versions of MS's themselves are making int21h Funct 3306h calls.
This function is not implemented in 3.3x or DR DOS 5/6, as I understood
after some calls back and forth from Novell and ex-DR people. The normal
calls were on function 30h, and those are handled ok with the patches from
UPD393. Meaning the programs themselves may not present difficulties, but
the Setup program may. Anyway they weren't clear on explaining things.
I just wrote simple routines in assembly to check registers after the calls,
and they were flagged after Setup ran, not after a program I tried.
If anyone has gone deeper on this, please take the podium...
A.B.
P.S.: On win program that was hard to install in DRDOS 'cause of the
Setup/Install issue, now runs happily under DRDOS6/Win3.1
P.S.: I think the next DOS, although still tapping into old 80x86 chips
should come with utilities to directly hook oneself to any net, regardless
of protocol/topology, to operate commands by voice, to fax, to tel-connect
via modem, etc. And have a X full GUI interface. Perhaps may come bundled
with a fax/modem card or a network card (buyer's option) and perhaps both.
Another option could be a card to hook it to the Cable/TV just to be
inclusive on the "Superhighway" bandwagon. Who knows. It won't be just a
DOS anymore..
A.B. (barr...@lamar.colostate.edu)
.
Eyal Doron
>Date: Fri, 21 Jan 1994 10:47:36 GMT
>Subject: Re: Re: DRDOS 6.0 any good? (Neanderthal)
Just be warned that there ARE compatibility problems with DRDOS 6.0. Most
notably, some DOS extenders (Phar-Lap) don't always implement virtual
memory properly under DRDOS. I came across this phenomenon with
MATLAB, which caused me to immediately switch back to MSDOS. For this reason
I would also be VERY wary of Novell-DOS 7, no matter how good it is, unless
all your important DOS applications are rather standard.
Eyal Doron
Frank Slootweg
> Frank and others;
> Apparently those *IF* are true. Some Setups programs, especially those
> from latest versions of MS's themselves are making int21h Funct 3306h calls.
> This function is not implemented in 3.3x or DR DOS 5/6, as I understood
> after some calls back and forth from Novell and ex-DR people. The normal
> calls were on function 30h, and those are handled ok with the patches from
> UPD393. Meaning the programs themselves may not present difficulties, but
> the Setup program may. Anyway they weren't clear on explaining things.
> I just wrote simple routines in assembly to check registers after the calls,
> and they were flagged after Setup ran, not after a program I tried.
>
> If anyone has gone deeper on this, please take the podium...
My DOS programming manual is at home, so I do not know exactly what
these function calls do. However from your wording, it seems that
Microsoft intentionally makes these programs incompatible with DR DOS
6.0, other 3.3[x] versions, and their own MS-DOS 3.3 for that matter. If
so, then you know what not to buy.
Frank Slootweg
> Just be warned that there ARE compatibility problems with DRDOS 6.0. Most
> notably, some DOS extenders (Phar-Lap) don't always implement virtual
> memory properly under DRDOS. I came across this phenomenon with
> MATLAB, which caused me to immediately switch back to MSDOS. For this reason
> I would also be VERY wary of Novell-DOS 7, no matter how good it is, unless
> all your important DOS applications are rather standard.
Yes, I know that there are compatibility problems with DR DOS 6.0. The
question is, who is to blame for that? The developper of the package or the
developper of DR DOS 6.0? For each specific case the answer can be
different.
From my own experience, and what I have seen on the net, in the
majority of cases DR DOS 6.0 is not to blame for the encountered
incompatibilities. This makes me continue to recommend DR DOS 6.0 as a
good, and most of the time better, alternative.
This is the world of open systems. If you buy products from different
companies, then you are the "systems integrator", whether you like it or
not. If you do not like it, then you should buy all your products from
one company, or at least one supplier, with a money-back guarantee if it
does not work.
Frank "My TV doesn't work. It MUST be the power company's fault!" :-)
rov...@oc.nps.navy.mil
>
> From my own experience, and what I have seen on the net, in the
>majority of cases DR DOS 6.0 is not to blame for the encountered
>incompatibilities. This makes me continue to recommend DR DOS 6.0 as a
>good, and most of the time better, alternative.
>
> This is the world of open systems. If you buy products from different
>companies, then you are the "systems integrator", whether you like it or
>not. If you do not like it, then you should buy all your products from
>one company, or at least one supplier, with a money-back guarantee if it
>does not work.
>
I'll second this opinion. I have to run a PC lab with lots of
proprietary models/software, and it *all* has to work together.
MS-DOS 3.3, 4.01, and 5.0 just didn't cut it. DRDOS 6 was a godsend,
solved all the problems, and allowed us even *more* flexibility than
we originally required. I never hesitate to recommend it.
Microsoft does not support open systems for either DOS or Windows.
That, and the fact that their software isn't better than the
comptetition, makes me look elsewhere for software solutions.
P.J. Rovero Internet: rov...@oc.nps.navy.mil
Code OC/Rv Packet: kk1d@k6ly
Naval Postgraduate School
Monterey, CA 93943
Azael Barrera
And the funky thing is that those functions, how they work, are not even in
the DOS manuals one used ot get from MS. It comes described in the MS-DOS
Programmer's Reference Manual, which of course you have to buy from a
bookstore; Dalton/SoftwareETC has it, as well as "fine" bookstores.
And even more funky, I've never seen a DRDOS Programmer's Reference
Manual for that matter (??).
A.B.-
P.S.: Assembly gurus may be laughing with their bellies upside down, they
know...
Mark Aitchison - Physics and Astronomy Computologist
>.... Some Setups programs, especially those
> from latest versions of MS's themselves are making int21h Funct 3306h calls.
Short answer:
DRDOS is about as compatible with MSDOS as any version of MSDOS is compatible
with another. If a program won't run with DRDOS 6 then it employs sneaky (bad)
programming, and probably won't keep working with new versions of MSDOS, and
if anything odd starts happening to the computer that'll be the first
application I tear off it!
Long answer:
This raises questions for program developers - with many flavours of DOS around
(PC-DOS, MS-DOS, DR-DOS, Novell DOS and "DOS compatibility" facilities in OS/2,
NT etc) - what is reasonable to support? My view is "plain vanilla DOS if at
all possible - this means it should run under any PC/MS/DR DOS produced since
version 3 (maybe 2), and not use sneaky tricks like the "list of lists", etc.
The only excuses for being DOS-specific in operation might be where network
software, etc dives into DOS to fool it somehow, and anybody using such
software should be aware of the long-term implications for maintaining systems
with software components that might break in the future - or now if you don't
keep a homogenous fleet of PC's (who does?)! Many administrators, like me,
distrust products that use devious programming methods when there isn't a real
need, and I wish I had a system to test software on that sounds an alarm when
somebody jumps directly into DOS or BIOS, etc. On top of that, programmers that
are pursuaded to deliberately go wrong when some particular manufacturer's
software is found during installation are a tad unethical, methinks.
Installation programs are another matter - I understand the need to configure
software optimally, taking into account memory managers, disk compression, etc.
But this has little to do with the version of the software and a lot to do with
what is loaded in config.sys and the hardware actually there. Very few
installation programs do a good job of detecting all the odd hardware (like
SCSI disk controllers, network cards with RAM in upper memory blocks that might
not be enabled at setup time) and third-party software - like QEMM, Lantastic,
etc. It is very easy to write code that works out the exact version of DOS
(even DRDOS and OS-2), and the BIOS brand/date, but that is not the be-all and
end-all of a good setup program.
>
> P.S.: I think the next DOS, although still tapping into old 80x86 chips
> should come with utilities to directly hook oneself to any net, regardless
> of protocol/topology, to operate commands by voice, to fax, to tel-connect
> via modem, etc. And have a X full GUI interface. Perhaps may come bundled
> with a fax/modem card or a network card (buyer's option) and perhaps both.
> Another option could be a card to hook it to the Cable/TV just to be
> inclusive on the "Superhighway" bandwagon. Who knows. It won't be just a
> DOS anymore..
I tend to agree with you - on the software side look at Linux (free, powerful,
gaining more and more features/compatibility every day), and look at the
compatibility people actually want - there used to be a rule of thumb - "can
the hardware run Lotus 123?" - if so then it will probably be able to run
whatever new software comes out. Nowadays the power applications need so much
hardware that many organisations have to replace PC's quite often, and so tend
to buy hardware and software together and accept that if either changes they
both may need to go - despite wishing they might stay constant long enough to
make the change and learning curve worthwhile. It seems the network is the
most constant thing in large organisations - people might be running DOS 3 +
Windows one day or a Macintosh the next, but it has to be compatible with the
network or it cannot be considered. Of course that is for large organisations,
but the bulk of the buyers are one-offs. For serious computing, my favourite
solution has to be the X windows system you mentioned - the front-end hardware
can remain constant while applications, operating systems and host computers
change as required. The budget can go into beefing up the servers instead of
replacing PC's or motherboards all the time. And two x-terminals (say, VLB
486's running Linux) running MS-Windows programs under Unixware creams a single
486 running NT - much better speed and price per user.
Frank Slootweg
> And even more funky, I've never seen a DRDOS Programmer's Reference
> Manual for that matter (??).
Why would such a manual be needed? After all, DR DOS 6.0 is supposed
to be a ??-DOS 3.3 clone. The DR DOS 6.0 *kernel* (i.e. the two hidden
files, whatever they are called) does not really offer any additional
functionality for a programmer. The only exception might be "large"
(>32MB) partition support. I doubt that a *programmer* would have to
worry about large partition support, and if so, I think (s)he can get
confirmation on it being present from the 3.31 version number which, I
think, the DR DOS 6.0 kernel returns. I don't know if this 3.31
designation is really industry standard or not.
Frank "I really wish I knew what I am talking about!" :-) Slootweg
Michael Gillespie
>>>> And even more funky, I've never seen a DRDOS Programmer's Reference
>>>> Manual for that matter (??).
>>Why would such a manual be needed? After all, DR DOS 6.0 is supposed
>>to be a ??-DOS 3.3 clone. The DR DOS 6.0 *kernel* (i.e. the two hidden
>>files, whatever they are called) does not really offer any additional
>>functionality for a programmer.
That's simply not true. DR DOS 5.0 included power management hooks
(BatteryMAX) and was ROMable! Not so for ??-DOS! DR DOS 5 was the first
DOS to include upper memory management (MemoryMAX) and the ability for
the kernel to load high. It also had configurable CONFIG.SYS management.
It had integral and dynamic SHARE and FASTOPEN functions. Position of
the boot files was no longer fixed to the first available cluster.
DR DOS 6.0 expanded on this and added disk compression. And it did ALL
THIS while maintaining DOS 3.3 compatibility, something Microsoft
forgot. <DOS 3.3 was very stable - probably the best MS version to date>
FS>I don't know if this 3.31 designation is really industry standard
Ver 3.31 was a Compaq development. The ONLY difference between 3.3 and
3.31 is the fact that 3.31 supports 'huge' disk partitions over 32MB.
When the singleuser DR DOS emerged from the Concurrent DOS family, it
was decided that it would emulate the most powerful DOS of the day -
Compaq DOS.
Michael.
---
ş SLMR 2.1c ş The Gray Research Group 204-943-9000 BBS/Fax 204-474-1969
----
Muddy Waters Computer Society Inc. Winnipeg, Manitoba, Canada
(204)943-6507,08,09 (204)942-0227 (204)956-4997 (all nodes USR 16.8K D/S)
Jen Kilmer
>In article <2780...@hpuamsa.neth.hp.com> fra...@hpuamsa.neth.hp.com (Frank Slootweg) writes:
>> I can not come up with one good reason for a program to be able to run
>>on MS-DOS 5.0/6.X, but not on a 3.3? "clone" like DR DOS 6.0. I doubt
>>that Microsoft and/or these "developers" can.
Other than lack of testing on earlier versions/general paranoia, not really.
Windows will run on 3.1 or later. Disk utilities are usually paranoid about
larger than 32M drives on 3.x, due to the - ah - interesting ways in which
this was implemented, dependent on the OEM. The 3.31 implementation is
compatible with the 4/5/6 implementation, however, so should be no problem.
Some programs like to make use of UMBs directly. Microsoft published its
UMB allocation API (it's a simple extension of the int 21h functions
48h, 58h, and 5801h, with the added 5802h & 5803h to find if UMBs are
even on the system).
And the MSDOS team also published the 3306h "real version call" function,
somewhat under protest (we didn't want vendors to use it, and told them
so in the beta, but we knew some had already found it because they
were telling other vendors on the beta forum about it, so....) The call
was added to the kernel to ensure that you couldn't use setver to disable
itself. Yes, it's a pain. The 7 version of PCFORMAT won't run in MSDOS
6.x because 3306h reports 6 - a deliberately inflicted incompatibility.
PCFormat could have relied on 30h (the "old", setver-able call), OR
could have reported that it hasn't been tested in 6, is the user sure
s/he wants to run it?
Oh, and there's the disk utility, which I will not name, which checks 3306h
& if it has a valid result >=5, compares the OEM signature on the drive
with "MSDOS5.0". If it's not "MSDOS5.0", for example, if it's "MSDOS6.0",
this disk utility informs the user that their disk boot sector is corrupted.
Result? MSDOS 6.x's format, sys, and setup all use "MSDOS5.0" as the OEM
signature :-(
>Apparently those *IF* are true. Some Setups programs, especially those
>from latest versions of MS's themselves are making int21h Funct 3306h calls.
Interesting. Which ones?
MSDOS's setup will use 3306h if 30h reports 5 or later (it, and setver,
are the only things in the product that do) to try to ensure that it
isn't set up on something it doesn't understand. Setver it to 4, tho,
and it's peachy.
>This function is not implemented in 3.3x or DR DOS 5/6, as I understood
>after some calls back and forth from Novell and ex-DR people.
According to the MS-DOS Programmer's Reference it was added in 5. (I
also recall it being added...) It is documented as providing the actual
MS-DOS version number rather than the version number set by the SETVER
command for the program.
-jen
--
not speaking for microsoft / and when the sky is falling what do we believe in
je...@microsoft.com / when everything we've learned to trust turns around &
msdos testing / makes a fool of us? well I believe in love. - patti scialfa
Jen Kilmer
>In article <1994Jan21.195025.83323@yuma> barr...@lamar.ColoState.EDU (Azael Barrera) writes:
>>call) is not implemented in 3.3x or DR DOS 5/6, as I understood
>>after some calls back and forth from Novell and ex-DR people.
>
>According to the MS-DOS Programmer's Reference it was added in 5.
More specifically, beta sites were notified of this function in 1990; it
might have made the interrupt list spring of 91 ;) MSDOS 5 was released
June 11 1991, and the Programmer's Reference went on sale that same month.
DR-DOS 6 was not released until November 1991, and DRI has released
several updates. Presumably DRI has chosen not to implement that new
MS-DOS int 21h call.
(FWIW, a quick scan of the opening table in the "Interrupt 21h Functions"
chapter of the 5 ProgRef shows 32h, 68h, 4410h, 4411h, 5802h, 5803h, 4b05h,
and 3306h as added in 5; 6ch, 5fh, 7fh, 46h, 66h, and 5d0ah as added in 4.
The other interrupts, including int 2fh and the new-in-5 task switcher
api, are located in the preceding chapter. The 2nd edition of this
book details the DoubleSpace & MRCI APIs as well.)
I don't know why an apps vendor would choose to drop 3.x compatibility.
And, no offense, but DR-DOS market share currently much less than MSDOS
3.3. From an MS-DOS point of view, however, the fact is that we don't
claim that DR-DOS is compatible with MS-DOS. It is not our job to add
our new apis to their kernel. DRI, now a part of Novell, makes its own
decisions about whether to go beyond 3.3x (1987) compatibility or not.
And if DRI chooses not to support our apis, it's DRI's choice not to be
compatible with apps that use them.
Frank Slootweg
>TO: fra...@hpuamsa.neth.hp.com
>
>
>>>>> And even more funky, I've never seen a DRDOS Programmer's Reference
>>>>> Manual for that matter (??).
>
>>>Why would such a manual be needed? After all, DR DOS 6.0 is supposed
>>>to be a ??-DOS 3.3 clone. The DR DOS 6.0 *kernel* (i.e. the two hidden
>>>files, whatever they are called) does not really offer any additional
>>>functionality for a programmer.
>
>That's simply not true. DR DOS 5.0 included power management hooks
>(BatteryMAX) and was ROMable! Not so for ??-DOS! DR DOS 5 was the first
>DOS to include upper memory management (MemoryMAX) and the ability for
>the kernel to load high. It also had configurable CONFIG.SYS management.
>It had integral and dynamic SHARE and FASTOPEN functions. Position of
>the boot files was no longer fixed to the first available cluster.
>DR DOS 6.0 expanded on this and added disk compression. And it did ALL
>THIS while maintaining DOS 3.3 compatibility, something Microsoft
>forgot. <DOS 3.3 was very stable - probably the best MS version to date>
Apparently I did not make myself clear. Don't get me wrong: I know
that DR DOS has a lot features, which the MS-DOS version of the same era
does not have. I am a DR DOS supporter. You don't have to convince me.
See my earlier responses in this string.
What I was referring to was only the *programmer's* view of the
*kernel* (i.e. DOS function calls). I was not aware of the "power
management hooks" and did not realize the ROMable aspect, but the other
points you mention should not directly concern a programmer. For
example: If the programmer needs memory management functions (EMS, XMS,
etc.) then (s)he should just use these via industry standard methods.
I guess that what I wanted to say is that a good program should run
on:
- MS-DOS 3.3 (or 4.0), if needed with third party add-ons (memory
managers, "big" partitions, etc.).
*AND* on
- MS-DOS 5.0 (or 6.X)
*AND* on
- DR DOS 6.0 (Did 5.0 have EMS, XMS, etc.)
*AND* on
- PC-DOS [insert right revisions]
A bad program would for example check the DOS version, and, if it is
not 5.0 or higher, would assume "This system can't have enough memory,
so let's give up, preferably with a confusing error message.".
Moral: Programmers should use real (de-jure or (de-facto) industry)
standards. If there are no real standards, then they should try to find
a method which works on the largest possible set of OSs. Only if that is
impossible/infeasible, they should go for "largest installed base" (i.e.
MS-DOS with the lowest possible revision).
Jen Kilmer
>TO: fra...@hpuamsa.neth.hp.com
>>>functionality for a programmer.
>
>That's simply not true. DR DOS 5.0 included power management hooks
>(BatteryMAX) and was ROMable! Not so for ??-DOS!
FYI, MS-DOS 3.22 was released to OEMs who wanted a ROMable MS-DOS in
the 80s (between 3.21 and 3.3, as the version would indicate). A ROM
release was also made of MS-DOS 5, which included the APM hooks,
Interlnk (later released in disk-based 6), and PCMCIA support.
-jen
--
not speaking for microsoft -=- je...@microsoft.com -=- msdos testing
"About all you can do in life is be who you are. Some people will love
you for you. Most will love you for what you can do for them, and some
won't like you at all." - from _Venus Envy_, by Rita Mae Brown
Michael Gillespie
JK>FYI, MS-DOS 3.22 was released to OEMs who wanted a ROMable MS-DOS in
>the 80s (between 3.21 and 3.3, as the version would indicate). A ROM
>release was also made of MS-DOS 5, which included the APM hooks,
>Interlnk (later released in disk-based 6), and PCMCIA support.
Thanks for the clarification, but ...
Acknowledged that MS3.22 was available in ROM, but it was DR5 that
introduced the upper memory management 'stuff' _along_with_ ROMability, etc.
These were reasonably major improvements in the context of the time.
And Microsoft didn't respond for some 18-months.
Regards,
Jen Kilmer
>Acknowledged that MS3.22 was available in ROM, but it was DR5 that
>These were reasonably major improvements in the context of the time.
I didn't say that they didn't. At a time when Microsoft had pretty
much kissed off DOS, DRI saw a need & moved to provide a solution.
Not dumb at all.