Need DOS 6.22 (Not OEM)
Harald Leland
Some years ago I bought an expensive simulation program which ran under Win
3.11
and Win32S\W32S.386.
When I converted to Win98 I lost the possibility to use this program.
To avoid buying the iven more expensive Win 98 - version, I bought "System
Commander
Deluxe" from V Communication, for multiple operating system on a single PC.
All worked well until I first tried to install DOS 6.22 on the the new
bootable partition.
Then I discovered that my OEM-version of DOS 6.22 demanded a clean
installation and
treatened to delete the existing DOS.
Therefore, I ask if anyone knows where I can get or buy a normal version of
DOS 6.22 ?
Microsoft Norway has removed the program from stock a long time ago.
Harald Leland
hle...@online.no
D. McKirahan
IO.SYS, and COMMAND.COM) to your bootable partition and then just (extract
and) copy the rest of the MS-DOS 6.22 files...
Note all three are READ-ONLY and the first two are HIDDEN. You may have to
use ATTRIB to change these begore and after copying.
--D. McKirahan
DMcKi...@attbi.com
"Harald Leland" <hle...@online.no> wrote in message
news:yybc8.6060$%m1.1...@news4.ulv.nextra.no...
Matthias Paul
> Some years ago I bought an expensive simulation program which ran under
> Win 3.11 and Win32S\W32S.386.
> [...]
> Therefore, I ask if anyone knows where I can get or buy a normal version
> of DOS 6.22 ?
MS-DOS is not longer available in any commercial form (except for
the bundled MS-DOS 7.10 and 8.0 version in Windows 98SE and ME
packages, of course).
You may have luck (?) to buy a second-hand copy somewhere, or
alternative use IBM´s PC DOS 2000 instead, which can be seen as
kind of an improved and more bug-fixed version of MS-DOS 6.22.
It is still available from IBM online stores.
However, why not just use DR-DOS 7.03 instead? It is 99% compatible
with PC DOS/MS-DOS, has no problems to run Windows, and provides
much more powerful memory management than found in the other DOSes,
as well as many other features and useability enhancements.
You can buy it from Lineo (USA) or LinuxLand (Germany), or, if
you need it only for personal non-profit use, you can download
and legally use it for free. Check out
http://www.drdos.org
http://www.drdos.net
http://www.drdos.com
ftp://ftp.lineo.com
Greetings,
Matthias
PS. If you have to, then cross-post rather than multi-post, please.
Modern news clients will only have to download one copy of a
cross-post, and will also mark a post as read, once one out
of several identical copies was read. This is not possible,
when you multi-post them...
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
Outsider
>
...snipped
> with PC DOS/MS-DOS, has no problems to run Windows, and provides
> much more powerful memory management than found in the other DOSes,
> as well as many other features and useability enhancements.
>
> You can buy it from Lineo (USA) or LinuxLand (Germany), or, if
> you need it only for personal non-profit use, you can download
> and legally use it for free. Check out
I have heard that DR-DOS 7.03 has serious bugs and version 7.02 is
the one to get. What do you know about that?
--
Outsider
Matthias Paul
> I have heard that DR-DOS 7.03 has serious bugs and version 7.02 is
> the one to get. What do you know about that?
:-) No, DR-DOS 7.03 has not significantly more "serious" bugs than can
be found in other DOSes. It is only, that alternative implementations
sometimes show hidden problems in applications or even other operating
systems, which went unnoticed so far, because the conditions when they
occur are unusual in those environments. Often they are triggered by
new features unknown elsewhere. Actually, most problems users run into
can be tracked down to real (obvious???) bugs or at least shortcomings
and oversights in application and driver software, not in the underlaying
OS. It is sad irony, that alternative implementations often get the
bad image as being "buggy", because many 3rd party developers only
test their products in very narrow environments, or simply because
users don´t know it any better: The fallacy is "When A works on B and
not on C, C must be the culprit.", although a careful analysis will
often (not always) identify A, sometimes even B as the cause of a problem.
As one of the developers, I recommend to use DR-DOS 7.03, which has
countless small improvements over 7.02, unless you would actually run
into one of the very few new problems. In those cases, 7.02 might be
a better choice, but not in general. DR-DOS 7.03 is the best (released)
DR-DOS you can get (so far).
What you probably heard of is actually a minor issue - not even a bug
in its true sense - in the DR-DOS 7.03 FDISK, which happens to create
partitions smaller than 128 Mb with a sub-optimal cluster size - as
you probably know, the DR-DOS FDISK also formats partitions in one go.
This quirk slipped in when FAT32 support was added, and, no question,
it is sub-optimal, but it is completely valid in terms of DOS standards.
DR-DOS fills out the BPB correctly and /would/ other OSes use this
information in accordance to their own specifications, no problem
should have ever occured.
The problem, however, is that partitions of this logical cluster layout
can exploit what I would call a bug (or serious oversight) in *MS*-DOS
and *PC* DOS, which can - under rare circumstances - cause them (*not*
DR-DOS) to destroy the partition created by DR-DOS when attempting
to write to it. DR-DOS has no problems using these partitions, but
this might be an issue in a multi-boot scenario.
There are at least four easy means how you can avoid the scenario:
Either do not create partitions smaller than 128 Mb, or if you do,
patch the OEM label in the boot record of this partition from
"DRDOS 7" to "IBM 3.3". This will make MS-DOS/PC DOS think,
the partition was created by IBM´s PC DOS 3.3 (which is the format
used by DR-DOS) and they will work with the partition without any
problems. Alternatively, you can use the MS-DOS/PC DOS FORMAT
to re-format the partition once they have been created with the
DR-DOS FDISK, or you can patch the DR-DOS FDISK to a different
OEM label. Or use a different partitioning program right from
the start, but unfortunately the MS-DOS/PC DOS FDISK provides
only a fraction of the flexibility the DR-DOS FDISK gives you.
As it turned out, the OEM label is not at all don´t care for
MS-DOS, PC DOS, and OS/2 (I´m not sure about NT). These OSes use
the OEM label and version (which must be in a specific format
to be recognized "nnnnnx.y") to decide which values in the BPB
should be trusted on and which other values should be ignored.
Presumably this is to work around bugs in very old issues of the
MS-DOS/PC DOS and OS/2 FDISK, which really did not fill out the
BPB correctly. At least I have no other "reasonable" explanation
for implementing such a nightmare of a quirk - after all, the very
reason the BPB exists is to provide the OS the values it needs to
access a volume properly... I will hereby assume, that their
engineering only tried to work around problems in their own
software, and not to deliberately break 3rd party software...
Anyway, the problem is that the non-standard (but valid as per spec)
OEM label used by DR-DOS will cause MS-DOS/PC DOS to /ignore/ the
/valid/ entries and recalculate invalid values from other given
/valid/ values and thereby they do not recognize that the partition
has a cluster size different from the default cluster size the
MS-DOS/PC DOS FDISK and older issues of DR-DOS FDISK would have used.
Note, that this problem is not related to DR-DOS as is and can also
happen when using 3rd party formatting software. The next issue
of RBIL will probably have a detailed discussion of these OEM label
quirks under INT 19h.
There´s another problem with the "?????IHC" OEM label for floppy
volume tracking, Microsoft introduced with Windows 4.00+ in
Windows 95+.
This can cause floppies formatted with 3rd party formatting software
(like - but in no way limited to - those formatted under DR-DOS)
to become inaccessable after the first use under the Windows GUI.
Even a simply "DIR A:" without the write-protection lever in the
read-only position will *modify* the OEM label in the BPB, and
will cause Windows to no longer recognize the floppies any more,
so that they will appear as having a sector fault (which they
don´t have).
I can only imagine how many millions of floppies with their original
software have been thrown away as having "bad sectors", while the
problem was only, that Windows had silently patched the OEM label
to something it no longer recognized itself...
The remedy for this problem is to add a number of values to the
registry (which will be published on http://www.drdos.org very soon).
There are actually a few minor new bugs in DR-DOS 7.03, however,
they are really small, and 99% of the users will never see them,
and they have no serious impact on the system as the OEM label
issues.
It is unfortunate that the really simple fixes for these problems
have never been uploaded, but that´s a different story and does
not make DR-DOS 7.03 a bad product as is.
All this has already been discussed in this forum not so long ago on
2001-10-31 under the (very misleading) subject "Re: good EMS/XMS/RAM
driver for MS-DOS ??????". You may remember this, as you took part in
that thread. For further details, please also check the "DR-DOS mailing
list" <ope...@delorie.com> archives at http://www.delorie.com, in
particular the long thread "Bugs in DR-DOS 7.03" 2001-10-31/2002-02-12),
and the forthcoming RBIL62. In case developers are worried and need
some more detailed background info, please feel free to contact
me directly.
Greetings,
Matthias
xby
> On 2002-02-18, Harald Leland wrote:
>
>
> PS. If you have to, then cross-post rather than multi-post, please.
> Modern news clients will only have to download one copy of a
> cross-post, and will also mark a post as read, once one out
> of several identical copies was read. This is not possible,
> when you multi-post them...
Is it possible to cross-post through google? If so, how?
Outsider
>
> On 2002-02-20, "Outsider" wrote:
>
> > I have heard that DR-DOS 7.03 has serious bugs and version 7.02 is
> > the one to get. What do you know about that?
>
> :-) No, DR-DOS 7.03 has not significantly more "serious" bugs than can
> be found in other DOSes.
> As one of the developers, I recommend to use DR-DOS 7.03, which has
> countless small improvements over 7.02, unless you would actually run
> into one of the very few new problems. In those cases, 7.02 might be
> a better choice, but not in general. DR-DOS 7.03 is the best (released)
> DR-DOS you can get (so far).
...snipped
> There愀 another problem with the "?????IHC" OEM label for floppy
> volume tracking, Microsoft introduced with Windows 4.00+ in
> Windows 95+.
> This can cause floppies formatted with 3rd party formatting software
> (like - but in no way limited to - those formatted under DR-DOS)
> to become inaccessable after the first use under the Windows GUI.
...snipped
> I can only imagine how many millions of floppies with their original
> software have been thrown away as having "bad sectors", while the
> problem was only, that Windows had silently patched the OEM label
> to something it no longer recognized itself...
I would say this is intentional from Microsoft's side and an example
of M$ cruel coding practices.
> The remedy for this problem is to add a number of values to the
> registry (which will be published on http://www.drdos.org very soon).
>
> There are actually a few minor new bugs in DR-DOS 7.03, however,
> they are really small, and 99% of the users will never see them,
> and they have no serious impact on the system as the OEM label
> issues.
...snipped
> All this has already been discussed in this forum not so long ago on
> 2001-10-31 under the (very misleading) subject "Re: good EMS/XMS/RAM
> driver for MS-DOS ??????". You may remember this, as you took part in
> that thread.
Thanks for jogging my memory. I went back and read the thread.
This is the specific dialog that worried me about v. 7.03:
#> Yes, DR-DOS is excellent. However, Version 7.03 has some unresolved
#> issues ('bugs'). For instance, the BATCH pre-processor is noticeably
#> broken.
#
#What do you mean by "BATCH pre-processor" here? Probably COMMAND.COM...
#Which feature do you think is broken and in which way? I悲 like to
#learn more about this.
Since batch programming is what I do, I'd like to know specific
details on the above if any are available.
BTW, thanks for the detailed information and references, I saved your
entire message for future reference.
--
Outsider
Charles Dye
<Matthi...@post.rwth-aachen.de> wrote:
>:-) No, DR-DOS 7.03 has not significantly more "serious" bugs than can
>be found in other DOSes. It is only, that alternative implementations
>sometimes show hidden problems in applications or even other operating
>systems, which went unnoticed so far, because the conditions when they
>occur are unusual in those environments. Often they are triggered by
>new features unknown elsewhere. Actually, most problems users run into
>can be tracked down to real (obvious???) bugs or at least shortcomings
>and oversights in application and driver software, not in the underlaying
>OS.
In all the years I've been using DR DOS and Novell DOS, I've
occasionally identified bugs or quirky behavior in the command
shell and other bundled utilities, but only discovered *one* bug
in the kernel proper -- and that one is quite trivial.
FindFirst / FindNext under DR DOS return files with the Hidden
attribute, even when the Hidden bit was not specified in the
attribute mask passed to FindFirst. This behavior almost
certainly has to do with DR DOS's password protection of files;
passworded files are automatically Hidden by the kernel. However,
FindFirst / FindNext always returns matching Hidden files, whether
password protected or not. A program which calls these API
functions under DR DOS should perhaps check the password status of
each Hidden file returned, to determine whether or not it "should"
have been returned. Aside from this very minor incompatibility,
DR DOS is extremely MS-DOS compatible. In some ways, DR DOS 7.0x
is more MS-DOS compatible than MS-DOS 7.1 itself; things like FCB
calls still function correctly....
I suspect that the vast bulk of reported compatibility problems
with DR DOS probably have to do, not with DOS itself, but with
the rather ambitious memory manager.
> [re: the FDISK bug, four years old this week
> and still no fix available from Caldera!]
>
>What you probably heard of is actually a minor issue - not even a bug
>in its true sense - in the DR-DOS 7.03 FDISK, which happens to create
>partitions smaller than 128 Mb with a sub-optimal cluster size - as
>you probably know, the DR-DOS FDISK also formats partitions in one go.
>This quirk slipped in when FAT32 support was added, and, no question,
>it is sub-optimal, but it is completely valid in terms of DOS standards.
My strong recommendation, if a DOS partition is intended to be
used by multiple operating systems, is that it should be created
under MS-DOS 5 or 6.xx or IBM DOS 5 or later, using the FDISK and
FORMAT which ship with those versions. Unfortunately, both
Caldera's *and* Microsoft's current shipping FDISKs are capable of
creating FAT16 volumes which are unusable under other versions of
DOS -- though for completely different reasons. (Caldera's because
of its incorrect calculation of cluster sizes, coupled with
Microsoft's undocumented use of the OEM label; Microsoft's because
of the new LBA partition types.)
--
Charles Dye ras...@highfiber.com
Matthias Paul
> This is the specific dialog that worried me about v. 7.03:
>
>|> Yes, DR-DOS is excellent. However, Version 7.03 has some unresolved
>|> issues ('bugs'). For instance, the BATCH pre-processor is noticeably
>|> broken.
>|
>| What do you mean by "BATCH pre-processor" here? Probably COMMAND.COM...
>| Which feature do you think is broken and in which way? I´d like to
>| learn more about this.
>
> Since batch programming is what I do, I'd like to know specific
> details on the above if any are available.
At present I am not aware of a single problem with DR-DOS 7.03
COMMAND.COM´s batch processing, whatever he actually meant by
"BATCH pre-processor"...
Unfortunately, the OP made no attempts to further explain or support
his claim, so his comment was not very useful at all. I think, we
should try to stick to proven or at least proveable and hopefully
reproducable facts instead of spreading vague rumours.
There have been a number of shell enhancements with 7.02 and 7.03
(most noteably the addition of support for long filenames, a few
new pseudo environment variables for an improved compatiblity with
4DOS, a few new commands and options, and a few fixes in heap/stack
management), but nothing that should have broken older general features
IMO. Also, most of these changes have occured with 7.02, not 7.03,
so I really don´t know, what the OP might have talked about...
Anyway, I doubt that all of the undocumented tricks discussed
in alt.msdos.batch and other batch groups, which are sometimes
only based on mere sideeffects of a particular implementation,
will work with the DR-DOS COMMAND.COM, and I don't think it would
be a good idea trying to support them, because they are really
no features of MS-DOS COMMAND.COM, but more or less random effects...
Most of the more traditional tricks used with MS-DOS COMMAND.COM
are supported in DR-DOS COMMAND.COM, however.
But if you are interested, why don´t you just download DR-DOS 7.03
and try it out yourself? You can get it from http://www.drdos.org
and http://www.drdos.net or directly from Lineo´s FTP server
ftp://ftp.lineo.com. There is no problem to create a multi-boot
with MS-DOS 6.22 or other DOSes. DR-DOS ships with LOADER, so
you can easily select the OS each time you boot. So, you don´t
have to give up you other DOS or Windows version and still learn
about DR-DOS´ much more advanced features at the same time...
Outsider
>
...snipped
> This is the specific dialog that worried me about v. 7.03:
>
> #> Yes, DR-DOS is excellent. However, Version 7.03 has some unresolved
> #> issues ('bugs'). For instance, the BATCH pre-processor is noticeably
> #> broken.
I take it since you have not responded that you don't know of
any particulars in this regard - or if there are any.
--
Outsider