Date: Fri, 25 Sep 1998 17:18:48 +0100 From: Matthias Paul Subject: Re: Suggestions for DR-DOS To: opendos AT delorie DOT com Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de Message-id: <11156891AC4@reze-1.rz.rwth-aachen.de> Organization: Rechenzentrum RWTH Aachen Precedence: bulk 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: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html ------------------------------------------------------------------- Caldera Digital Research Systems/OpenLinux: http://www.caldera.com/ -------------------------------------------------------------------