Date: Wed, 07 Oct 1998 14:18:49 +0100
From: Matthias Paul <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
Subject: Re: DR-DOS suggestions
To: opendos AT delorie DOT com
Message-id: <22E5E4104B5@reze-1.rz.rwth-aachen.de>
Organization: Rechenzentrum RWTH Aachen
X-Mailer: Pegasus Mail v3.22
Reply-To: opendos AT delorie DOT com

On 1998-10-01 Guti wrote:

>              Implementation of the SERIAL command for allowing 
>              the user to change or view the serial number            
>              of his disks.

I think, the first step should be to add displaying of the serial-
number to the corresponding commands like DIR etc. Maybe a special 
option to LABEL or FORMAT could do the same job without a need for 
a new completely new utility.

>              PASSWORD command should include a warning for 
>              preventing the protection of itself with a password 
>              (doing that, the password could not be removed unless 
>              you have it in a disk).

Though this might be useful, it is not actually necessary. 
Mind, that you can implicitely give passwords in the directory
path spec, for example:

 PASSWORD password.exe /R:hello
 PASSWORD[.exe];hello /N

or (assuming you are using COMMAND.COM):

 MD c:\secret;world <-- Password set implicitly, 
                        similar to "PASSWORD /P:"
 CD c:\secret;world
 COPY c:\autoexec.bat c:\secret;world\autoexec.bat;safe <-- Password 
                           set implicitly, similar to "PASSWORD /R:" 
 DIR c:\secret;world\*.* TYPE c:\secret;world\autoexec.bat;safe
 DEL c:\secret;world\autoexec.bat;safe
 CD ..
 RD c:\secret;world

Of course, you can also use the PASSWORD command. Mind that since 
DR-OpenDOS 7.02+ the kernel accepts passwords prepended by one or two 
semicolons for better 4DOS compatibility. However, COMMAND.COM still 
does not generally accept two semicolons. 4DOS, on the other hand, 
usually will accept passwords only with two semicolons in front of it 
(because a single semicolon is used for include lists), and newer LFN-
supporting issues might even need to frame the whole expression in 
"quotes" (than only using a single semicolon). There are a few more 
oddities in 4DOS password support, however any further improvement is 
now up to JP Software.

>              Renaming DR-DOS system files from IBMBIO.COM and 
>              IBMBDOS.COM to DRBIOS.COM and DRBDOS.COM for avoiding 
>              problems with installed PC-DOS, and be more coherent 
>              with DR-DOS philosophy (like in version 6). 

The names have been changed to IBMBIO.COM and IBMDOS.COM for 
compatibility reasons (some software tests for the presence of 
these files). Changing this back might now also cause additionally 
compatibility problems with DR DOS 3 - 6.

You probably seem to need this because you want to dual-boot DR-DOS 
7.02 with PC DOS 7.

However, since DR DOS 6.0 there is an easy solution to this problem 
using the "SYS /DR:ext" option, whereby "ext" is an alternative file 
extension of the IBMBIO.COM, IBMDOS.COM, and [D]CONFIG.SYS files. If 
you use this option, SYS will create a boot sector, that will load the 
IBMBIO.<ext> file, and the IBMBIO.<ext> file will also be patched so 
that it loads the IBMDOS.<ext> file and proceeds a [D]CONFIG.<ext> 
file (the [[O]D]CONFIG.<ext> feature has only been with DR-OpenDOS 
7.02, but is no longer with DR-DOS 7.02). Hence it is easy to install 
DR-DOS 7.02 using something like "SYS /DR:702" not conflicting with 
the PC DOS file names that cannot be changed this way.

BTW. The SYS /DR:ext option is one of several reasons, why it is
*not* a good idea to compress the kernel files like IBMBIO.<ext> using
a 3rd party compressor like COMPACK. Though it might work in a few
cases, it will just don't work in all and you're always risking to
crash the system - even if it appears to work in the first place.
The IBMBIO.COM is only 24 Kb now (compare this to the size of the
MS-DOS files), and using a more sophisticated compression algorithm
it might be possible to further shrink this downto 19-20 Kb. However,
as long as it is not necessary, there is no reason to make all this
effort. AFAIK the two decompression engines make up less than 200 
bytes code size (not resident), so there is not a large gain to 
achieve when stripping them out.

Anyway, it might still be difficult to dual-boot DR-DOS and PC DOS
even when using "SYS /DR:ext". This is, where LOADER comes in, as it
allows to boot PC DOS (or almost any other OS) through the standard
boot sector [F1] while DR-DOS is booted via [F2+] using a BOOT.LST
file like:

 IBMBIO.702 S [5] Caldera DR-DOS 7.02

The new DR-DOS 7.03 BETA SYS utility, that can be downloaded from
Caldera's web site now makes it much easier to install DR-DOS
without destroying the "standard boot sector", which is used to
boot PC DOS (previously you usually had to SYS the partition several
times booting the different OSes). Assuming you have MS-DOS or
PC DOS installed you can manually install DR-DOS by just running at
the C:\> prompt:

 LOADER boot.lst

and than use the *new* SYS utility (given the floppy a: contains a
bootable DR-DOS 7.02 system):

 c:\drdos\updates\SYS a:\ c: /DR:702 /L /C

If SYS still catches the wrong command processor, you should copy it
manually and edit the SHELL[HIGH] directive in the [D]CONFIG.ext file.

Afterwards you can select your OS any time you boot up the machine.

>              TaskMgr should implement multitasking for 8086+ and 
>              not only task switching. Anyway it should be optimized 
>              in speed and memory consumed.

Though it is possible in theory to do multitasking on a 8086 CPU (see 
MP/M, CCP/M, or DOS Plus for example), this kind of multitasking 
would have no means for hardware-virtualization or memory protection 
etc. (a 386+ CPU is needed for this). Only 100% well-behaving DOS 
programs would run in such an environment, and since there are almost 
no non-trivial applications that are 100% well behaving in these 
terms, such a system would (today) be of no use in a commercial 
sense. However, you still have task switching. 
On the other hand, due to different concepts and APIs something 
like this might work for other environments than DOS, like GEOS 
for example. Even if GEOS runs on DR-DOS this is beyond the scope 
of DR-DOS  TASKMGR, and is handled inside of the "application"
GEOS, which is the operating environment for native GEOS applications.

>              Related with above, what about including the old 
>              DesqView 2.70 from Quarterdeck? (www.qdeck.com) 

Recalling some tests I did at Novell DOS times, DESQview (non-X 
issues) also run under DR-DOS' EMM386. Any DESQview expert listening?

>              Include in DR DOS the great 2M utility (from Ciriaco
>              Garcia de Celis -Grupo Universitario de Valladolid-) 
>              it will be a good idea; specially if DR DOS FORMAT 
>              command could handle 2M disks. 

Yes, I agree with this one. However, I don't know, if Ciri would want
it to be included (and integrated) with DR-DOS...

 Matthias
 
-------------------------------------------------------------------
Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web  : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
------------------------------------------------------------------- 
Caldera Digital Research Systems/OpenLinux: http://www.caldera.com/
-------------------------------------------------------------------