If both work, generally use the one that takes up less memory.

You're probably thinking of mouse.com, and it was probably the Microsoft driver.

Generally the best driver to use is the one that takes up the least amount of RAM. There are a bunch of them at http://www.mdgx.com/newtip1.htm#CDROM4 . You will also probably want to use SHSUCDX instead of MSCDEX.

Can there be "subtle" incompatibility problems on a mouse or CD driver, or is it always a case of "it either works or it doesn't"?

I don't even know what a "subtle" incompatibility problem would look like with a mouse or CD driver, at least in DOS.

jarreboum wrote:

Can there be "subtle" incompatibility problems on a mouse or CD driver, or is it always a case of "it either works or it doesn't"?

Of course. However the 'small' drivers are for 99% of all applications suitable.
There are edge cases where I have seen e.g. ctmouse fail. I identified this as some initialization problem where loading a classic mouse driver / unloading it again and then load ctmouse makes it work.
I usually use TMOUSE.COM which is internally V3.03 by AmHi Tech Co. and was delivered by a lot of different rather no name brands such as Tianess Enterprise Co Ltd as TMOUSE or to Pan & Lees Industrial Co./STD Electronic International Ltd. as PMOUSE.

For the CD-ROM drivers one has to look at the feature set the driver supports. Usually ISO9660 support is sufficient for general usage. But original drivers support more exotic formats as well like CD-Text, CD-i, Multisession CDs, Photo CDs, Mode 2 Form1/Mode2 Forme 2 sector formats etc. This bloats the TSR.
If you look at the smaller drivers they drop support for such exotic formats.
So if you use e.g. a ATAPI driver from Sony you can expect the driver to support CD-Text as Sony suggested this standard.
Usually it is difficult to get a list of supported features of certain atapi drivers.

One of the "features" that Elianda is referring to where results are definitely not subtle is UDMA support. I don't recall the Win98 SE oakcdrom.sys driver being able to support UDMA for any CD-ROM drive I ever used, and as a result, I had to substitute another manufacturer's driver to get UDMA transfers to work. PIO modes are intolerably slow by comparison, particularly when you are trying to use a DOS-based scheme for a complete system restore after using backup software like Adaptec's Take Two or Norton Ghost.

Well, old drivers usually default to PIO mode to be as compatible as possible. Especially for oakcdrom.sys that is used for by Windows 9x installation.
We had this topic here somewhere else already. Also with early controllers DMA is not impossible. Often even old ISA IDE controllers support MW-DMA2. Interesting is the development that appeared:
Early SCSI CD-ROMs are using simply the DMA features of the SCSI controller.
Early proprietary CD-ROMs have support for DMA as well since the drivers are made to work with the specific controller cards.
Early ATAPI CD-ROMs usually support PIO only since MW-DMA2 would often require a specific ATAPI driver for the used controller card.
Later this appeared indeed. Well known are e.g. the Triones drivers for the Triton chipsets using the PIIX3 southbridge (TRICD.SYS) that support Bus Master DMA. Since from hardware side all the controller appeared as 'Standard PCI IDE Controller' other drivers with support appeared as well.

So if you want to have DMA transfer on 486/386 with the CD-ROM drive it is better to target SCSI or one of the proprietary interfaces. Nethertheless it would be nice to have some list for old IDE controllers that bring a ATAPI driver with DMA support. I don't know any though.

With the latest UDMA capable CD-ROM driver we had some issues on the Win98 Super DVD. It installed also on systems that did not had UDMA support and delivered then wrong data, such that subsequent transfers failed. So we could not load it automatically.

Jorpho wrote:

I don't even know what a "subtle" incompatibility problem would look like with a mouse or CD driver, at least in DOS.

Well, for a mouse it could work, but be slower, or randomly miss ticks resulting in a jerky cursor. On a drive it could read at incorrect speed, or miss parts of the data. Stuff that doesn't prevent the hardware to work, but not give the optimal experience. Sometimes so subtle that the user doesn't notice it straight away? I'm only speaking hypothetically though, maybe the behaviour is entirely binary, do/don't.

UDMA support would fit right there for example, I would have never checked for it. It's good to know which drivers support it and which don't.

I also agree with that elianda said.
And UDMA is rather something I associate with Win XP, perhaps Win98.
In fact, it wasnt't until XP that it worked for me. W98 often used normal MW-DMA (if at all).
Besides, my old DOS rigs can do single-/multi-word DMA at best (no busmastering capable IDE).
Anyway, FreeDOS includes several UDMA drivers, so why not use them if the hardware supports it ?

And about that mouse driver.. There are indeed minor differences, as far as I know (feel free to correct me).
Only later versions of the MS Mouse driver (mouse.*) do work seamlessly in Windows 3.1 DOS boxes.
Also, some mouse drivers do feature a graphical mouse cursor for text mode programs.
Some of them also support different speeds, macros, etc.

I like using cutemouse http://cutemouse.sourceforge.net/

and SHSUCDX http://www.opus.co.tt/dave/utils.htm