Mail Archives: opendos/1998/09/25/11:23:36
On Wed, 23 Sep 1998 Guti wrote:
Very good suggestions, indeed. However here are some comments:
> BUGS
> When reading from one drive, and after some time, writing
> to another, causes to appear the sector not found error on
> the first drive.
I m a bit surprised as so far I ve never seen this occuring. In
IBMBIO.COM there s a two second disk timeout code to aid faulty
media change detection. Can you report your configuration setting,
especially:
Main-BIOS setup: Any floppy and harddisk related stuff.
DR-DOS: DEBLOCK, MULTITRACK, BUFFERS, FASTOPEN. DBLBUF, NWCACHE,
DRIVPARM, DRIVER
Any floppy/disk acceleration/enhancement drivers loaded like
2M, VGAREAD, etc.?
Please try to speed down your machine or floppy/disk configuration.
Try to use CONFIG.SYS DEBLOCK=0. Does this help?
Is the change line support ok for your floppy disk?
> Interrupt 21h service 30h (Get DOS version number), returns
> DOS version (AL, AH) 6.00 and must be 7.02; OEM (BH) 0 and
> 0 is for PC DOS from IBM, so DR DOS must have another OEM
> identificator number.
This is ok, as DR-DOS emulates the PC DOS 6.1 API (for reasons of
compatibility). DR-DOS has its own version check (DR-DOS 7.02 is
actually "Single user nature CP/M-86 version 7.3", hence the BDOS
check returns 1073h). So programs relying on DR-DOS specific
enhancements can use this to ensure they are actually runnig on
DR-DOS.
You can use the new DR-DOS 7.03 BETA SETVER.EXE and IBMDOS.COM files
from Caldera s webpage to change the global or local DOS and BDOS
version numbers reported by DR-DOS:
If you set "SETVER /G=7.02", DR-DOS will report itself as
"PC DOS 7.02" through INT21h/30h. "SETVER /X /G=6.114" will
cause DR-DOS reporting itself as Novell DOS 7.
> SUGGESTIONS
> FASTOPEN and DOSKEY (HISTORY) should be out of the kernel,
> this way users that do not use it, will not have an
> overhead in the system. An the one who want to use them,
> can load them in any moment (like in MS-DOS and PC-DOS).
FASTOPEN:
FASTOPEN is integral part of DR-DOS and cannot be removed.
However, you can disable it by not using FASTOPEN or setting
FASTOPEN=0 in CONFIG.SYS. I recommend to disable FASTOPEN, but not
because of the memory footprint which virtually goes downto nothing
but the data table itself, but because FASTOPEN can be dangerous if
a users doesn t know how it works (and what kind of precautions are
necessary when working with FASTOPEN enabled). However, on systems
without an actual disk cache loaded, it can dramatically speed up
frequent file accesses, so there s still good use for it in some
scenarios.
Please mind that Caldera s implementation is using a very efficient
hash table mechanism. A single reference takes only 2 bytes for
DR-DOS. So settings like FASTOPEN=512 or FASTOPEN=1024 that would
consum several Kilobytes of memory on MS-DOS/PC DOS systems just
use up a few bytes on DR-DOS...
DOSKEY:
You re right in saying that while MS-DOS DOSKEY is an external
driver, DR-DOS implementation is partly part of the kernel, not
the loaded TSR. However, this is for very good reason:
Even the oldest issues of DR DOS more than a decade ago already
had command line history and advanced edit capabilities tightly
built into the console I/O (part of the BIOS), and thereby taking
up very little memory. The corresponding CONFIG.SYS directive
to control this is HISTORY=...
If you specify HISTORY=OFF, IBMBIO.COM will even dynamically
discard the code needed for this.
AFAIK with MS-DOS 6.0, Microsoft introduced the external DOSKEY
utility, which sort of duplicated this history feature, but added
some macro capabilities. With Novell DOS 7 DOSKEY also found
its way into DR-DOS, however, the DOSKEY TSR only contains the
code to handle macros, and leaves history code and command
line editing up to the console I/O in IBMBIO.COM.
The advantage is, that our DOSKEY takes about 1-1,4 Kb, while
MS-DOS needs about 4 Kb, or even something like 7 Kb with newer
issues.
Another advantage is that DR-DOS history implementation not only
works for COMMAND.COM, but for any console driven utilities,
like DEBUG etc. It also has some "intelligent" search facilities,
so that you only have to specify the beginning of a command, and
on the fly it will try to look similar commands up in the history.
(More details can be found in my NWDOSTIP.TXT.)
The bottom line is, it s good as it is, and IMO should not be changed.
> Have you seen PTS-DOS (www.phystechsoft.com)? It has nice features
> that could be implemented in DR DOS.
> For instance, pressing Ctrl-Alt-Del, automatically
> flush all the buffers, and performs a quick reboot
> (similar to those available in QEMM).
Pressing CTRL+ALT+DEL, DR-DOS KEYB already flushes dirty buffers
before rebooting. Having the PNW SERVER loaded, it will also intercept
attempt to reboot and first shutting down the network server.
> IBMBIO.COM can be packed using packers like COMPACK 5.1,
> will be a good idea to distribute it packed (for minimizing
> disk space). (Also could this solve the problem that Mathias
> Paul comments about its size?). I have it packed with COMPACK
> 5.1, and now IBMBIO.COM ocuppies 19K.
While this may work in some cases, IBMBIO.COM, IBMDOS.COM, and
COMMAND.COM are no usual executables that can be compressed like
standard .COM programs. For example using 3rd party compression
you will most probably break anything that directly links into
the kernel files, like "SYS /DR:ext", or my QEMM patch to use 5
instead of 5+3 handles in low memory (and thereby sometimes breaking
Windows). It will also break ROMming facilities (and unfinished
things like Windows 95/98 dual-boot).
> Probably you will get more speed if compile your C/C++
> source code with a newer Borland C/C++ compiler (Eg. version
> 4.52) and not with Borland C/C++ 2.0 (althought the file size
> and the memory requeriments will be increased, this is not
> important because the resident parts of DR DOS are written in
> assembly).
Hm, but usually in the DOS world *size* (even if on disk) counts
before *speed*.
> DISKCOPY, and DISKCOMP may use XMS, EMS, or disk and
> so avoid changing disks when coping or comparing from/to the
> same drive (also aplyable to COPY, MOVE, XCOPY).
AFAIK since a long while DISKCOPY already uses XMS to reduce disk
flipping to a minimum. However, there are cases, where this is
not applicable as it may not work reliable. DISKCOPY then defaults to
buffer in conventional memory.
> HIMEM.SYS ocuppies a lot of memory compared with the
> version shiped int MS DOS 6.22 and in PC DOS 7.0 (about 4
> times more). Try to reduce its size in memory. The easy way
> is reducing and removing the innecessary text messages
> (the startup message: 'HIMEM.SYS 2.32' should be removed,
> so some bytes will be saved, and a prettiest look will be
> obtained).
Yes, I have seen this too. But after further investigating this on a
bunch of 286 machines I also found machines, where DR-DOS HIMEM.SYS
took much lesser memory (about 1/4 ;-) than MS-DOS driver, so this
actually depends on the chipset. However, there might still be room
for improvements for those cases, where DR-DOS HIMEM overlays consum
more.
Any DR-DOS tools startup banners will *not* be kept in the resident
code, instead they are placed in the discarded Init portion of the
drivers. However, some drivers contain special signatures like "HIMEM"
or "EMMXXXX". They are needed for compatibility with some
applications directly snooping within memory for specifically
loaded drivers (e.g. made by Microsoft or Compaq), so
unfortunately they cannot be removed.
> EMM386.EXE is very unstable, and hangs the system
> frequently. (What about releasing some versions of EMM386
> for beta testing?).
Have you already tried the new DR-DOS 7.03 BETA files available
from Caldera s web-page? In particular EMM386 has undergone massive
changes and is much better now.
> Some processes are still a bit slow (reads from disk, memory
> alocation) compared with their competitors. Please spend some
> time optimizing it.
Yes, that s true. However, please keep in mind, that DR-DOS *is*
optimized - for minimal size.
Using FASTOPEN, BUFFERS=x,y, DEBLOCK=FFFF, or using NWCACHE you
can dramatically speed up disk accesses, especially when using
VERIFY=OFF. DR-DOS disk sub-system actually performs full
verification with VERIFY=ON, while this might be (partially)
ignored in other products (at least that s what I ve heard from
various sources).
However, I m sure there will be further improvements... ;-)
> Support for the european 'Euro' currency, like in PC DOS.
Partial support for the Eurocurrency and ISO 28601/ISO8601 already
exists since DR-OpenDOS 7.02 as of December 1997. For countries of
the European Monetary Union just add 21000 to the previously used
country code (example: instead of 31 for Netherlands now use 21031),
and DR-DOS national language support system will support the
Eurocurrency.
The currency will be reported as "(=" (a literal transscription of the
new Eurocurrency symbol). However, with DR-DOS 7.03 this will most
probably be changed to the meanwhile offical "EUR" currency string
for all the codepages not supporting the Eurocurrency symbol.
As the Eurocurrency and the national currencies will coexist for a
few years, it is a requirement to support them *both* at the same
time, hence these two country codes for each affected country (well
actually, there are a few more, read on...).
Having NLSFUNC loaded, you can easily retrieve data and switch between
these codes at runtime. While the actual Eurocurrency problems are
way beyond the scope of the underlaying operating system and can only
be handled inside of the applications (to be updated for Euro
support!), I have discussed this with a few experts and have been
told, these are the major requirements needed in the financial world.
Support for the Euro-symbol itself has *not* the highest priority.
Please mind, that while PC DOS 2000 now duplicates DR-DOS Year-2000
BIOS-fix and somewhat incompatible supports the Euro-symbol in
codepage 850, its NLS system does not allow for semi-simultanous use
of multiple currencies. AFAIK there is not even support for a single
country code with the Eurocurrency.
BTW, if country codes in the range 21xxx would cause problems with
your applications, you can use alternative codes in the range 11xxx,
which are just like the 21xxx codes, but internally use the old xxx
codes. The disadvantage here is that retrieving/switching country data
from within applications might then need special precautions on the
application side, as otherwise the system will fall back to the old
xxx code after a while. Hence you should try to avoid loading NLSFUNC
in these cases.
There are also a few new country codes in the range 20xxx and 10xxx
(currently only for USA=1, UK=44, and Germany=49) which follow
ISO 28601/ISO 8601 for the date format (for global data exchange).
As this "Japanese" date format such as in "1998-09-25" is mantantory
for Germany since May 1996, this was basically added for German
offices and educational institutions (the corresponding standard
is DIN EN 28601). Neither can be found in PC DOS.
The country codes 21049 and 11049 not only support the Eurocurrency
but also the new date format. However, the old country code 49 still
reports the traditional format for backward compatibility.
However, you re right that DR-DOS 7.02 currently lacks support for
the actual Euro-symbol in its fonts and keyboard driver, but I m
quite sure this will change soon. However, I don t think changing
the standard 850 codepage was a good solution for reasons of backward
compatibility. I m working on a compatible solution, but it will
not stop there... ;-)
It might be interesting, that using the new DR-DOS 7.03 BETA
NLSFUNC.EXE (and SETVER.EXE) from Caldera s web-page, you can even
now use the new EGA.CPI and KEYB files from PC DOS 2000 under DR-DOS
(Notably, the new NLSFUNC 4.00 now also works with older issues of
DR DOS downto 6.0).
Detecting a foreign data-base format, NLSFUNC will then load an
advanced file scanner dynamically adapting to the given format.
While for DR-DOS files the new NLSFUNC consumes even less memory than
in previous releases, loading the advanced file scanner it takes just
about 200 bytes more resident code totalling 1,1 Kb, which is still
a fraction of the resident file size of MS-DOS/PC DOS NLSFUNC
(3,5 - 7 Kb). Foreign COUNTRY.SYS and .CPI files (from old DR DOS
issues, from the various Concurrent and Multiuser DOS issues, from
MS-DOS, PC DOS, PTS/DOS, OS/2, and NT) should now all work just as
well with DR-DOS as its own compressed data base files.
This opens DR-DOS for 3rd party solutions...
> And finally the magic suggestion more speed, less memory
> requeriments and more features (impossible?).
Always true. ;-) However, have you realized, that without using
3rd party tools, you can already get typically 3-4 Kb more free
conventional memory using DR-DOS 7.02 (+ 7.03 BETA updates) as
you could with the original Novell DOS?
Bye,
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/
-------------------------------------------------------------------
- Raw text -