kluge@lan.informatik.tu-muenchen.dbp.de (Oliver Kluge) (02/22/89)
Hello ! [I am posting this the second time, because on my site it looks as if Pnews had swallowed this article.] In DOS 3.30 Microsoft put in a new config.sys variable named DRIVPARM. With this variable, it is possible to change the default configuration of the built-in device drivers for floppy disk I/O. DRIVPARM does the same thing DEVICE=DRIVER.SYS does, except that it does not install a new driver but changes the configuration tables of the drivers built-in. DRIVPARM also uses the same syntax that DRIVER.SYS uses. This variable was embedded in all OEM versions of MS-DOS 3.30 and also in IBM's PC-DOS 3.30 (However, IBM did not mention the command in its documentary). A Microsoft representative ensured me this, and it can be proved by using DEBUG: debug ibmbio.com and s 100 ffff 'DRIVPARM' will reveal its presence in the parse table. But due to a bug in Microsoft's DOS 3.30 this variable could not be accessed by the user. Microsoft had already delivered all its OEMs before the bug was detected. Microsoft soon released a patch that would cure this bug. This patch was sent to all Microsoft's OEMs, *including* IBM, as a Microsoft representative told me. Other manufacturers did correct the bug (Hewlett-Packard did it) and documented the new feature. However, IBM seems not to have done it. The new feature isn't documented anywhere (nor does any IBM representative seem to know of it) and IBM sells the version with the bug. I asked Microsoft to send me the patch, but Microsoft strictly refused to do this and told me to ask IBM. IBM told me that they didn't know of any such variable, but it could well be that this variable was an "unsupported feature" meaning I couldn't get the patch (if it existed, as they told me). I am very frustrated about this behaviour of both companies, because I *DO* need this feature (I equipped an IBM XT with a HD floppy controller plus BIOS extension, works fine, except with PC-Tools, which does not recognize HD formats when initializing. It seems PC-Tools asks DOS for floppy drive specs, and DOS cannot know of my controller). What about DOS 4.0? Nobody could tell me, all I know is that Microsoft states it is "implemented in all OEM versions, including IBM's version" (This is denied by IBM). So I do ask here: Does anyone have this patch, or does anyone know where to get it or does anyone have a small program (All "common" programming languages accepted) to do a change in the DOS driver configuration table? ****Please help me!!!!**** Thank you all, Oliver -- TTTU MMMMM kluge%lan.informatik.tu-muenchen.dbp.de@relay.cs.net (CS-NET, ARPA) T U U M M Oliver Kluge, Parallel Computing Lab, \ unido.UUCP (UUCP) T U M M M Technical University Munich, Arcisstr. 21, 8000-Munich 2, W. Germany T UUU M M "Why stop now just when I'm hating it?" Marvin, the paranoid android
w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) (02/26/89)
kluge%lan.informatik.tu-muenchen.dbp.de@relay.cs.net writes:
In DOS 3.30 Microsoft put in a new config.sys variable named
DRIVPARM. With this variable, it is possible to change the
default configuration of the built-in device drivers for
floppy disk I/O. DRIVPARM does the same thing DEVICE=DRIVER.SYS
does, except that it does not install a new driver but changes
the configuration tables of the drivers built-in. DRIVPARM
also uses the same syntax that DRIVER.SYS uses.
This variable was embedded in all OEM versions of MS-DOS 3.30
and also in IBM's PC-DOS 3.30 (However, IBM did not mention the
command in its documentary). A Microsoft representative ensured
me this, and it can be proved by using DEBUG: debug ibmbio.com
and s 100 ffff 'DRIVPARM' will reveal its presence in the parse
table.
But due to a bug in Microsoft's DOS 3.30 this variable could not
be accessed by the user. Microsoft had already delivered all its
OEMs before the bug was detected. Microsoft soon released a patch
that would cure this bug. This patch was sent to all Microsoft's
OEMs, *including* IBM, as a Microsoft representative told me.
Other manufacturers did correct the bug (Hewlett-Packard did it)
and documented the new feature. However, IBM seems not to have
done it. The new feature isn't documented anywhere (nor does any
IBM representative seem to know of it) and IBM sells the version
with the bug.
Here is the fix for PCDOS 3.3 from file PD1:<MSDOS.SYSUTL>DRIVPARM.ARC
which is available from Simtel20. I am NOT the author.
--cut-here--
Patching DOS 3.3 To Use DRIVPARM:
Drivparm can be used with IBM 3.3 and other 3.3 DOS'S! The
following text explains why someone would want to use this and all
of the pains I went thru to get it to work:
First of all I will explain why someone would want to do this. The
only replacement for DRIVPARM is DRIVER.SYS which is external and
has to be loaded. When DRIVER.SYS takes hold it assigns a device
driver for whatever you are using for the next logical drive
available. Example: A well loaded AT class machine with Drive A:
being a 1.2 meg floppy, Drive B: is a 720k 3 & 1/2" drive, A hard
disk which is split into 2 logical drives C: & D:, and Expanded
memory of around a meg for a RAM disk (E:). DRIVER.SYS defined as
DEVICE=DRIVER.SYS /D:1 /F:2 would place drive B: as drive E: or F:
depending on the ram disk. ASSIGN.COM would take care of the drive
calls but DRIVER.SYS and ASSIGN.COM eat memory!
Thats why DRIVPARM is better. It sets up a device definition for
the drive you are installing and does it with less memory used
because it is a internal CONFIG.SYS command that is not loaded.
This patch I will descibe to you will make 1 change to the syntax
of DRIVPARM. Here is old verses new after the patch:
OLD: DRIVPARM=/D:n /F:n etc...
NEW: DRIVPARM=/DD:n /F:n etc...
(Note the extra 'D')
3.3 DOS was setup not to use DRIVPARM because most Computer Co's
were upgrading there BIOS's in AT class machines to set up new
devices in there CMOS Setup Memory. Anything that the SETUP
routine in CMOS could not handle DRIVER.SYS could be loaded and
used instead. After careful examination of the system files of IBM
3.3 DOS I found that DRIVPARM was still embedded in the code of
the IBMBIO.COM hidden file that DOS uses to boot. Stranger yet I
discovered that DOS did read a DRIVPARM=/ in a CONFIG.SYS file but
would not read further than the '/'. I found a way to hook it back
up to read the DRIVPARM command line without the CONFIG.SYS ERROR
being displayed at bootup.
Well Lets Patch 3.3 IBMBIO.COM:
First and MOST IMPORTANT make a work disk by formatting a floppy
with the /s command and also copy DEBUG.COM to it. Make sure your
prompt is A>. Use your favorite utility to change IBMBIO.COM's
attributes so we can read-write to it. Type DEBUG IBMBIO.COM and
press ENTER.
At the - prompt type R and press ENTER
A table will be displayed. Note what CX=nnnn and write this 4 Hex
digit down somewhere.
Now we look for the code to change. Type the following noting that
nnnn is CX= you wrote down: S 100 L nnnn 3C 2F 74 03
Press ENTER and you should get a single line location for the
list. If you get more than 1 line of location double check what
you typed after S 100 L. You should see something similar as this:
????:nnnn
The nnnn is what we looked for. So now type the following using nnnn:
U nnnn
You should get a assembler type listing of code starting at nnnn.
Now look where the hexidecimal code 74 falls near the top of this list.
We need to change this from 74 to EB. My IBM DOS 3.3 had this 74
located at 4E9C. Other 3.3 DOS's will be differ from this. Lets refer
to the location of 74 as xxxx.
Now to change it to EB type the following with xxxx being the location
of YOUR code 74:
E xxxx
It should display 74 and a space and wait for your input. Type EB and
press ENTER.
Now press W at the - prompt and it will save our patch to disk. Then
type Q to quit debug.
Okay, you have made it this far. Now make a CONFIG.SYS file with a text
editor of your choice or COPY CON CONFIG.SYS is just as fast. Use the
syntax of DRIVPARM=/DD:d /F:n. DO NOT FORGET the EXTRA 'D' in the line
you define. DRIVPARM follows the same syntax as DRIVER.SYS in your DOS
manual with the exception that DEVICE= is not required in front of it
and we now have to put 2 'D's in there with this patch.
Now save your CONFIG.SYS and try it out. Make sure your WORK DISK is in
drive A: and reset the computer. If there was a mistake made one of 2
things will happen. It wont boot period or you will get a ERROR IN
CONFIG.SYS FILE message. If no mistakes were made you should get a date
and time prompt. Then test it with the floppy for a while and make sure
that it works with your device defined in DRIVPARM. Then if it is okay
you can format your hard disk from this disk and run from there.
From K. MACY
--cut-here--
--Keith Petersen
Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.0.0.74]
DDN: w8sdz@wsmr-simtel20.army.mil
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdzrde@ukc.ac.uk (R.D.Eager) (02/27/89)
I did post this before, but I fear it got lost....
There is a simple way of making DRIVPARM work, at least on PC-DOS 3.3 (I have
tried it and it works). It is *extremely* baroque, but who cares?
Place three control-A characters (yes, the ASCII value 1) into the line
after the DRIVPARM= bit, before the parameters. If we represent CONTROL-A
as ^A, the line might look like this:
DRIVPARM=^A^A^A/D:n /F:n ... etc
I don't know why it works, but it sure does!
--
Bob Eager
rde@ukc.UUCP
...!mcvax!ukc!rde
Phone: +44 227 764000 ext 7589kluge@lan.informatik.tu-muenchen.dbp.de (Oliver Kluge) (03/02/89)
Hi citizens of netland! This is sort of a summary of the reply I got for my article about the buggy operating system IBM still sells because I can't seriously answer all replies by individual mail. I would like to thank all writing to me ! Especially, I would like to thank Mr. Guenther Ruecker from IBM. He was the only person willing and able to help me, but his company's current policies prevented too much of that. Thanks! + Keith Petersen (w8sdz@wsmr-simtel20.army.mil) sent me a patch description from his archive (written by K. Macy) that would cure the bug. + Harold Shapiro (hs0i+@andrew.cmu.edu) wrote me he switched back from DOS 4.0 to 3.2 because of a bad experience with this. + Steve Ward (ward%cfa@harvard.harvard.edu) wrote about the number of the updated version Microsoft distributed, 3.30A. + Sean Patrick Gallaty (choke@m-net.UUCP) wrote that he thought 3.2 was the only version containing DRIVPARM. + R. D. Eager (rde@ukc.ac.uk) sent to me the most useful solution of the problem: He wrote I should insert three Ctrl-A (01h) in between the '=' and the parameters. ===> I T W O R K S !!! Additionally, I found out that just * O N E * Ctrl-A is actually needed. + Lee Fisher (leefi%microsof.UUCP) from Microsoft wrote I shouldn't expect Microsoft to discuss IBM's IBMBIO.COM adresses. I have to say, I * D O * expect Microsoft to do this. The first time I detected the irregularities, I contacted my dealer. Three months NOTHING happened. So I rang up IBM directly. They told me they couldn't give me any phone number of a technician familiar to such deep diggings. >>> They told me to call Microsoft, because "they wrote it". Of course, Microsoft told me to ask IBM, and so this would have continued until infinity. BTW, IS THERE ANY I B M REPRESENTATIVE, TECHNICIAN OR WHATEVER FROM THE US TO GIVE A STATEMENT??? IS THIS A GOOD MARKETING STRATEGY TO GIVE EXPERIENCED USERS NOT THE * CHANCE * TO HAVE A * B U G * CORRECTED? Yes, I see, DRIVPARM is an unsupported feature, but is that good style to sell buggy operating systems just because the bug is contained in an important, but unsupported feature??????? I'm very disappointed. In the past, IBM did not make such trouble when I wanted technical details. So long ... Oliver -- TTTU MMMMM kluge%lan.informatik.tu-muenchen.dbp.de@relay.cs.net (CS-NET, ARPA) T U U M M Oliver Kluge, Parallel Computing Lab, \ unido.UUCP (UUCP) T U M M M Technical University Munich, Arcisstr. 21, 8000-Munich 2, W. Germany T UUU M M "Why stop now just when I'm hating it?" Marvin, the paranoid android
ppa@hpldola.HP.COM (Paul P. Austgen) (03/03/89)
I thought I saw a later posting that answered your problem. If not, I will send you the Hewlett Packard patch if you want to send me a disc. However, might I suggest, with DOS as cheap as it is, that you maybe just invest in 3.3, which will (should) clear up the problem. With patches like this, the drives sometimes become confused, and there may be incompatibilities with on-board ROM in floppy controllers.