Date: Mon, 08 Feb 1999 12:59:50 +0100 From: Matthias Paul Subject: Re: Personal Netware & CD-ROMs To: opendos AT delorie DOT com Message-id: Organization: Rechenzentrum RWTH Aachen X-Mailer: Pegasus Mail v3.22 Reply-To: opendos AT delorie DOT com On Sun, 07 Feb 1999 David Wrede wrote: > i started thinking about it and was > wondering why i couldn't access the CD-ROM on the Pentium from the > 486. After all, they (the drives [ZIP and CD]) both use .SYS > drivers; if i can successfully access one, why not the other? > Any ideas? The way ZIP drives and CD-ROM drives are integrated into the system are completely different. Attaching a ZIP drives (no matter if using the SCSI, IDE, ATAPI, or parallel version) and loading the stack of layer drivers for your configuration will make a so called block device driver available to your system. DOS will than access your ZIP drive through this block driver (represented by a drive letter) very similar to its own embedded drivers for floppies (removable) and harddisk (fixed). This can be done, because physically and logically ZIP drives are not organized that different from other drives. However, if you load the manufacturer s hardware device drivers for your CD-ROM driver (proprietary, IDE, ATAPI, or SCSI) this will be linked into the system as a special variant of so called character device drivers. DOS uses character device drivers to talk to character devices like the console (CON:), the serial (AUX:, COM1:-COM4:) or parallel port (PRN:, LPT1:-LPT3: (LPT4:)), which support a different set of functions to fit their different purpose. While it might sound like a good idea to write a block device driver for your CD-ROM (this has been done for PTS/DOS), for various reasons Microsoft chosed not to do so, and so didn t DRI/Novell/Caldera: Physically and logically CD-ROMs are very different from harddisks (different sector sizes, no FAT system), and the internal block drivers in DOS would not have been able to cope with them. Adding this would have required massive changes to the kernel and the traditional concept of character and block device drivers. This would have implied compatibility problems. Hence, your hardware CD-ROM device driver will only *fake* a character device driver (MSCD001: or similar) to the system to become linked into the kernel without being assigned a drive letter, which would happen for block device drivers (but DOS would not be able to actually talk to this device). A similar trick is also used by many other drivers, like EMM386 etc. However, this special kind of character device driver will have a signature in its header identifying it as a CD-ROM driver, and compared to usual character device drivers it supports a different set of functions which, however, are not called directly by the DOS kernel. If you force DOS to talk to such drives (like TYPE config.sys > MSCD001:) you will only get error messages because the default set of functions is only faked by the driver. To make your CD-ROM drive work, you will have to load another driver implemented as a TSR program: MSCDEX or NWCDEX will be called by the DOS kernel via its so called redirector interface. In contrast to the NETX shell attempt, originally this backend interface was designed to provide easier network access with DOS 3.3+, so you have to think of it as a call out interface at a more abstract level than the FAT file system code in the DOS-BIOS driver in IBMBIO.COM. Using the redirector, the CD-ROM file system and other physical differences are no problem, because these differences will be handled and levelled inside of the MSCDEX/NWCDEX drivers. Mind, networking drives too might have a completely different file system and hardware architecture, but under DOS you will still see them as if they were (almost) standard partitions on a harddisk. Only few restrictions apply to such remote drives, e.g. you cannot FORMAT or FDISK them. Same with CD-ROM drives. To complete the picture, when you load the CD-ROM redirector, you will have to tell it which other device driver it should talk to (/D:MSCD001), and actually, the redirector driver will pass calls downto the special set of functions in the hardware CD-ROM device driver, which was linked into the kernel as a character device driver. In your case, you are loading two drivers hooking the redirector interface (the CD-ROM redirector NWCDEX/MSCDEX which additionally supports the so called CD-ROM extension API, and the network redirector based on VLM). To conclude, you *can* share your CD-ROMs on a PNW server with clients, but you need to load NWCDEX and VLM in the proper order. (Under DR-DOS there is a way to load NWCDEX in CONFIG.SYS (may save you much conventional memory), see my INSTCDEX utility on my web page.) Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------