Microsoft MS-DOS CD-ROM Extensions
Questions and Answers
23 March, 1990

Q: Does the /V option to MSCDEX actually cause a message to be displayed? I can't make it do anything. I use:
	MSCDEX /D:CDDRV /V /M:8

A: Yes, a series of statistics are displayed. MSCDEX uses INT 10 function 0eH to write to the console, so if for some reason you are trapping this or have software that captures this and doesn't display bios output to the screen the information will not appear. All screen output uses this function so if any output appears on the screen after loading MSCDEX, it is not clear why this additional information does not appear.

Newer versions (2.0 and above) use the DOS write handle call for output which will fix problems of I/O redirection of this output.

As it turned out, the machine that had this problem was not a strict IBM-compatible machine and did not emulate a PC at the BIOS level. Consequently, the messages written with INT 10h were not displayed.

Q: Is it normal for MSCDEX to hang the system if an error is returned by a driver's IOCTL function? Wouldn't an error message be better?

The only ioctl calls sent to the driver in version 1.01 are to request the device header address and media check. Media check calls will never hang no matter what is returned so long as the driver returns. Illegal values may not do what you want but it won't hang. Request device header address may hang if the driver fails to set error conditions correctly as DOS expects them as DOS will return from the ioctl call without error. MSCDEX will then assume the bogus return values are correct and jump to a random location.

Q: Does MSCDEX do anything that should preclude its working in a non-IBM-clone machine?

A: Except for the INT 10 problem mentioned earlier, no. If you can identify any problems whatsoever,  we would be happy to learn about it, but as yet we have heard of no other problems.  If your machine runs MS-DOS version 3.X or 4.X, it should be capable of running the Extensions correctly.  As for driver/drive-controller compatability problems, that may be another matter. We do not guarantee anything about these because we do not write the device drivers or design the hardware interface boards and cannot make any claims concerning them. It is up to the drive manufacturer or device driver writer to do this kind of compatability testing.

Q: Based on what I read in the spec, I decided to support only HSG type addressing which seems to be allowed by the IOCTLI function #6 (Device Status). I return 4 bytes of 00h if that function is called. I would have thought that would be one of the first calls MSCDEX would make (after "Find Header") but so far it hasn't called the status function. How will MSCDEX know enough not to use Red Book addressing if it doesn't check status first?

A: In version 1.01, ioctl function #6 is not called although it is called by MSCDEX starting with version 2.00. Since all device drivers must support some default functionality and as MSCDEX only uses the basic default now (only High Sierra addressing for example), it wasn't a problem that it didn't call this function to find out about non-default features that were supported.

Some software is being written that controls audio on a CD-ROM that expects Red Book Addressing and checks the device status to see that it is supported. The conversion algorithms are fairly simple and code fragments are provided.

Q: Can you provide more info on how the READ/WRITE device control string should work. Does the read device bytes command get information that was written by the write device control string?

A: At present, there are very few people that use this command. There are a couple other features that are either used only in special instances or not at all at present. This is not to say that they won't be used at some later time.

   The purpose of these commands was to allow a standard way of delivering commands that were not specified in the CD-ROM device driver spec to the drive. For example, sending SCSI command strings and reading the responses from the drive. This function is deliberately open-ended and vague because it was intended to provide a catch-all mechanism for application programs to communicate requests or request data in ways that were not specified by the device driver spec. For application programs to use these functions they have to know the driver supports these functions and also how to communicate with that specific drive. The mechanism would let the driver do what it does best and worry about which ports and interrupts to use. This relieves the application program from these details and allow it to deal with controlling the device at a higher level.

   Right now, if the driver does not support these functions, it should return an error for Unknown Command. One could test whether these two function were supported this way. Note: if there are commands which you feel should be supported by the device driver specification, please communicate them to us and we will consider adding them if they are of sufficient general interest.

Q: Would it be possible for me to get a sample source file for a driver?

A: Yes. Licensees are given source code to device drivers for:

	SONY - complete

	HITACHI - missing two modules. These are owned by Hitachi so we
	  cannot supply them, though Hitachi will.

	PHILIPS - this driver communicates with the LMS CD-ROM driver 
	  supplied by LMS.

Q: How can an application access CD-ROM drives that are subunits of one driver? The IOCTL calls do not take an argument for subunit. MSCDEX seems to handle this OK since when I do a directory of each CD-ROM in turn it accesses the correct drive. I do not see any clean way for an application to, for example lock the door on CD-ROM drive G: which is the third drive handled by the driver.

A: Requests all have a sub-unit field in the request header. Commands that one would expect to be directed to a specific drive, such as open door, are targeted at a particular drive through the use of the sub-unit field.

Q:  What is the current release version number of MSCDEX? The version I have is version 1.01 that is marked EVALUATION COPY. When can I get a final release version of it? Also will that final version include the changes to do all I/O through MSDOS (i.e. no INT 10h).

A: The most recent released version is version 2.20. You can purchase this from a number of licensees including all drive manufacturers. A Microsoft MS-DOS CD-ROM Extensions availability list is available. Versions 2.00 and up use MS-DOS for I/O and do not use the Bios for writing.

Q: Why doesn't MSCDEX allow IOCTL access via the drive letter (i.e. DOS func. 44h subfunc. #4,5), as if the CD-ROM were a normal drive. I understand that the driver is not a block device, but this is being handled already in some way since you allow a user to perform file I/O to a CD-ROM making it appear to be a block device. It would seem that all that would be necessary to accomplish this is to intercept IOCTL calls in the same way that file access calls are being intercepted.

A: MSCDEX doesn't presently hook int 21h, which is what this would involve. It's doubtful that this will change. It's not that much more difficult to open the file and send an IOCTL to the handle. File access calls are not caught at an INT 21h level but are caught from within DOS at another interface. CD-ROM drives are far more like network drives than traditional MS-DOS FAT file structure block drives and their drivers. For example, try to FORMAT a CD-ROM drive and you'll see. Part of all this prevents IOCTL's to the drive letter from being directed to the appropriate driver.

Q: Why not allow access to the PLAY, STOP and SEEK functions via the INT 2Fh entry point as is allowed for READ LONG. This would be much simpler than requiring the application to locate the driver header and then find the STRATEGY entry point and create request control blocks etc. This is a lot of code to start the music playing!

A: It's preferable to see future MS-DOS versions that provide standard extensions to the application program interface for audio/video control (new int 21h calls). The reason we haven't included play, etc. in the int 2Fh interface is to avoid loading down MSCDEX with additional functionality that most people don't use. Your suggestion would only move that code from the CD-playing program into MSCDEX. It makes your program smaller at the expense of making MSCDEX larger. As time goes on, this may change and some of the functionality may move into the int 2Fh interface. In the meantime, you can contruct device driver requests and use MSCDEX to send them to the driver through the Send Device Driver Request function request.

Q: Shouldn't the specification eliminate the need for the application to OPEN the driver by name? This is especially important in systems where the driver creates a new driver header for each CD-ROM drive. As it is, MS-DOS allows so few file handles to be open simultaneously that requiring applications to open even more is very bad.

A: Simply close the driver handle after you have located the device header. You no longer need to communicate through DOS to control it, so free the handle and make it available for other programs to use. With version 2.10, it is no longer necessary to OPEN the device driver in order to communicate with it. Applications can communicate with the device driver using Send Device Driver Request.

Q: Have you considered adding an addressing mode for the PLAY AUDIO function that would allow the application to specify the PLAY address by TNO instead of block number or min/sec/frame?

A: This has been considered but has not been added to avoid complicating the device drivers unnecessarily. At the moment, most CD-ROM drives are used without audio so our intent was to put what was needed for audio support in the audio playing software. In addition, we chose to keep the interface simple to leave more latitude for changes to the OS/2 API that may include newer data types like audio and video. Nonetheless, more extensive audio support may be added in the future. In the meantime, audio playing software has the extra overhead of reading the audio table of contents and interpreting the tracks itself.

Q: Why is there no CLOSE TRAY function in the driver spec? The CD-ROM drive we are using (Toshiba SCSI) has this capability but I see no way to use it via the Extensions. Why allow the user to OPEN it without allowing him to close it?

A: A close tray command has been added.

Q: It seems that there should be bits in the Device Status word to indicate whether a driver supports Reading/Writing device control strings.

A: Reading and writing device control strings was put in as a catch-all for anything that was missed so that application programs could send specific commands through the device driver to the device if they understood the device and knew how to communicate to it. A manufacturers CD-ROM diagnostic program would be an example of a program that might choose to communicate with the drive in this way. If the driver does not support these functions, it should return an error. One can test whether these two function are supported by testing if the error returned is for Unknown Command. 

Q: In the spec, treatment of the BUSY bit in the status word with regard to the PLAY AUDIO function seems to assume only one CD-ROM drive. What happens when the user has two or more drives each of which want to be playing music? How does the application tell whether the desired drive is busy? It would seem better to use some of the bits in the upper word of Device Status to indicate BUSY for each drive, perhaps allowing 8 or 16 drives.

A: Requests all have sub-unit numbers associated with them. A request for service from one sub-unit may report that the drive is busy at the same time another sub-unit was not busy. The sub-unit field is used to distinguish requests between the drives supported by the driver. The busy bit serves as an indication of drive status for the sub-unit the request is for.

Q: If a CD-ROM file is opened in write-only mode, no error occurs.

A: True. The same happens on a floppy drive with a write-protect tab on it.  If you do have a handle to a CD-ROM file in open_for_write mode, as soon as you attempt to write, you will get an error. The correct model is to duplicate the behavior of a file that has been set READ-ONLY. Read-only files return error_access_denied if you try to open them in open_for_write or open_for_both modes. MSCDEX has been changed to duplicate this behavior.
       
Q: What other non-MSDOS calls are issued by MSCDEX besides INT 10h?
A:
	INT 2Fh - dos callbacks
	INT 67h	- expanded memory
	INT 10h - all INT 10h calls went away with version 2.00 which uses DOS write handle  instead.

Q: Why does MSCDEX do the READ LONG PREFETCH call after it has done a DEVICE CLOSE call? Is this intentional?

A: MSCDEX version 1.X never issued device open or close. These were issued by DOS as part of driver initialization. MSCDEX version 2.00 now issues device open calls and will precede the prefetch call.

Q: In the device driver spec, it says that if more than one unit is supported by the driver that this field should be set to the number of units. I suspect that this is wrong since this is not a block device. As far as I can see, this field should only ever be set to one since each unit will actually have its own header with its own unique name.

A: CD-ROM device drivers are a hybrid of block and char device drivers and are not technically legal as one or the other. Block drivers make some assumptions about the media format that aren't meaningful for CD-ROM and don't have a read call that can deal with CD-ROM's large data space. They were made as char devices with some additional calls and rules. One of the changes that was made for CD-ROM device drivers was to allow multiple sub-units for the device so the treatment of this field is correct as specified even though CD-ROM device drivers are character device drivers.

   If one has more than one CD-ROM drive, one can approach supporting them from several ways. One could have separate device drivers for each drive and load one per drive, have a single driver with multiple device headers, or have a single driver with one device header that supports sub-units. This last method is borrowed from block drivers. For the case that the drives and drive commands are all the same, using sub-units will allow you to distinguish between which drive receives which command. The alternatives clutter DOS up with drivers or device headers. Sub-units may not be legal character device driver fields but conceptually, they're the right thing. Since CD-ROM device drivers could not be block drivers and had to be char device drivers, some liberties were taken with the specification to merge the best of both specifications.
   
Q: Is there any support through MSCDEX for WRITE LONG? I have a need for this to support a CD mastering system. I would like to be able to treat a WORM drive as a CD-ROM and allow writing to the drive once to create a master and then be able to test it out by using it as CD-ROM to verify that our data has been correctly stored in "High Sierra" format.

A: Such a call exists. It only serves to define a standard interface for CD-ROM device drivers that are running over re-writable media - such as a CD mastering system. It is in the driver specificiation starting with version 2.00 of the CD-ROM Extensions.

Q: How important is it that I should support RAW mode access in my driver? What would this typically be used for?

A: This is something that is gaining in importance. Several drives support reading in raw mode. Since drives and their command capabilities are hardware dependent, you would know based on the capabilities of your hardware if you were capable of supporting it. This function was added for completeness. A standard way was needed to define how to get at the 288 bytes of EDC/ECC if drives allowed access and to have an avenue prepared if people found useful applications that would not use EDC/ECC where they wanted the additional space (such as gracefully degrading low-fidelity audio or graphics). It will be useful for copying audio information or for audio systems that will want to be able to manipulate audio tracks. Many people have expressed interest in having this capability.

Q: In the structure for the UPC Code function, "The UPC/EAN code (last 4 bits are zero)". Does this mean the low order or high order 4 bits?

A: This is less ambiguous if you read Red Book under mode-2 of the Q-channel info. This is now clarified in the UPC Code call. It should be the low nibble of byte 7. Red Book specifies that MSB comes out first so the high nibble will contain the 13th nibble of the UPC code and the 14th nibble will be zero.
   Unfortunately, scanning for the UPC code is time consuming especially if it is done by the software. This is due to the design of the q-channel in Red Book. It's a pity because this could be a useful number to verify the correct disc has been inserted. Most CD-ROMs do not have a UPC code or have it zeroed out. The same seems to be true for CD-audio as well. We believe that CD-ROM drives should scan for the UPC code as they read the Table of Contents when initializing from power up or a new disc. If the hardware does not do this, the UPC code has to be scanned by polling the q-channel which may occasionally miss the UPC code.

Q: It would be nice if the device driver spec included a list of what types of disk access functions would and would not work so that users could get an idea of what utilities and applications will and will not work with the extensions.

A: The device driver specification describes just what is necessary for writing a CD-ROM device driver. The information you would like concerning things such as INT 25h/26h not supported as well as the behavior CHKDSK/FORMAT/etc belongs and is mentioned in the MSCDEX overview.

Q: If I have a low priority request and if the system has time, can the prefetch request read into and transfer the data into a transfer address?

A: We have looked at this for some time but the bottom line is that asynchronous I/O under DOS is very difficult to support in all cases. It is difficult for MSCDEX or the CD-ROM device driver to know that the transfer address is still valid because DOS never notifies MSCDEX or the device driver if the requesting process was been terminated. The request runs the risk of writing over another program. The best approach now is if the driver wants to, it can reserve internal buffer space for data from the disc and put prefetched data there. Then it can copy the data to the read transfer address once the read request finally arrives. Alternately, some of the caching or prefetching can reside in the CD-ROM controller or in the drive itself. The CD-ROM XA device driver appendix though allows a mechanism for reading files asynchronously although this requires a CD-ROM XA drive and imposes burdens for the application to notify the driver when the process halts and to move data .

Q: Is there any status indication that a prefetch transfer has occurred or some interaction with the read long command?

A: There is no way to tell if a prefetch request was successful or the state of it. The prefetch simply provides a hint to the driver and the read request later is the request that finally takes delivery of the data.

Q: Read (ioctl input) When audio is playing, can location of head move?

A: I'm not entirely sure what you mean by this question but I will attempt to answer a couple different ways and hope I provide the information you need.
   While audio is playing, the head is moving on the CD. If the driver receives a command asking where the head is, the driver should ask the drive where the head is presently positioned and report that. So as audio is playing, an application program that is controlling the audio can monitor the progress of audio playback and can either synchronize actions with the audio or report the present location to the user. For example, a program to play audio discs would be able to report the present track number and time elapsed on the computer monitor much like a CD-audio player reports things on its LED display. If the driver is sent a command that requires the movement of the head or a change in the state of the machine (SEEK, READ, INITIALIZE, PLAY AUDIO etc.) then the audio will be interrupted so that the drive can perform the new request.  If the drive receives a command for status or some other function that does not require the head to be moved or the state of the machine to change, then audio play should continue.

Q: Are the parameters of Audio Disk Info and Audio Track Info BCD or binary?

A: The parameters were vaguely specified in the device driver spec. The spec has been clarified. They are as follows:

- Audio Disk Info
        binary	Lowest Track Number (1-99)
        binary	Highest Track Number (1-99)
        red book	Starting point of lead-out track

- Audio Track Info
        binary	Track Number (1-99)
        red book	Starting point of track
        as is	Track control information

The track control information is not a BCD or Binary number like the track number. The byte contents as it appears on the disc should be carried through unmodified by the driver and is interpreted according to the Philips/Sony Red Book standard.

Q: Are the parameters for the Audio Q-channel info BCD or binary?

A: The parameters are as follows:

- Audio Q-Channel Info
        as is	Control and ADDR byte
        as is	Track Number
        as is	Point or Index (X)

        red book	MIN/SEC/FRAME
        zero	ZERO
        red book	AMIN/ASEC/AFRAME or PMIN/PSEC/PFRAME

The notes on when to convert from BCD to red book addresses for MIN/SEC/FRAME, AMIN/ASEC/AFRAME and PMIN/PSEC/PFRAME is already fairly clear in the spec. The other fields are passed through as is from the disc. For additional information, see the two code samples AUDIO.C and AUDIO.ASM.

Q: Must we support read sub-channel info and the read upc code?

A: No. It is not necessary that these be supported. At the present time and in the forseeable future, MSCDEX will not be issuing these commands though some applications may wish to.

- Read Sub-Channel Information

At the present time, nobody is using channels P or R through W. The read sub-channel command was added to provide a standard way to specify access to these channels in the event that they are used and to specify in one way or another access to all information on a CD-ROM. The error detection or correction for information in these channels is not as good as it is for data returned from READ commands. There are existing standards for P, R-W channel use and this command could be used to access this information once discs abiding by these standards become more common.

- Read UPC Code

This command is conceivably much more useful. It is advised that it be supported so that application software can exactly identify the CD-ROM in the drive. This may be a consideration for audio software that wishes to try to identify inserted audio discs (if the UPC code is present) or for software that is specifically tied to a version of a CD-ROM. Unfortunately, the standard does not specify a specific location for this information so that unless the hardware reads it on disc initialization as we recommend, the device driver must poll the q-channel and hope that it locates it. See also the sample code in AUDIO.ASM.

Q: My driver seems to work ok except that whenever I connect to a sub-directory and do a directory, I am suddenly back in the root directory again. What's going wrong?

A: What is most likely happening is the driver is returning an incorrect value for MEDIA CHECK and MSCDEX thinks that the disc is changing all the time. When this happens, MSCDEX rereads the volume descriptors and pathtable and reinitializes what it knows about the disc and changes the current working directory back to root as if the drawer had been opened, the disc removed, and then reinserted. This will be accompanied with a larger amount of disc activity than one would expect for a simple directory scan. Fixing the driver to return the correct value when asked for a media check will correct this behavior.

Q: What is the best way for my application to know if the disc has changed since it was last accessed?

A: Use the DOS function find first and look for the volume id. When the disc has been read and MSCDEX has already initialized the internal information it keeps for each disc, this is a relatively inexpensive operation. The information is in memory and the disc does not have to be touched, so checking the volume id is very quick. Only if the disc has been changed does the disc have to be touched. This operation takes considerably longer than if the disc was not changed but even so, this has to be done anyway because MSCDEX has to read and initialize what it knows about the new disc so it can report the volume id correctly so the application can know if the disc in the drive is the one that it is looking for.

Q: When I do a directory, the first couple filenames are either duplicated or they are random characters. What might cause this?

A: The problem comes from having the incorrect bytes in the file identifier field for the first two directory entries. The first directory entry in each directory file is supposed begin with a copy of the directory record for that directory file followed by a copy of the directory record for the parent directory (also known as '.' and '..' on Unix or MS-DOS). The filename or directory identifier is supposed to be 1 byte long and the contents are supposed to be 0 for the first directory entry and 1 for the second directory entry. This is discussed in clause 6.8.2.2 of the ECMA standard or the ISO-9660 proposal. Several places on the disc in question, you have a 1 where there should be a 0 and in one directory, the file identifier consists of 0x8A which is why DIR in that directory begins with an "e". Incorrectly formatted discs will not be handled by the extensions correctly. This is why it is a good idea to test your disc image using MSCDEX before you press a disc to make sure your data is formatted correctly and as MSCDEX expects it.

Q: I have a directory file that is 4Kb long but when I do a DIR in that directory, it is slower than usual and random filenames are printed out. I can tell by watching the device driver commands that MSCDEX is asking for sectors far beyond the end of the directory. I can see how this might account for the random filenames but why is it scanning so far?

A: Problems such as this result from having with multi-sector directory files that include empty sectors in the directory file. The High Sierra specification does not allow you to have empty directory sectors at the end or to have gaps in the middle. The problem stems from the fact that your directory length is too long. For example, for the disc in question, the root directory begins at sector 28 and its length is 4096 bytes but the second sector is completely blank (all 0's). This confuses MSCDEX because it does not expect to see empty sectors.

   Because LEN_DR of what would be the first directory entry in sector 29 is 0, MSCDEX thinks that there are no more entries in that sector. When it reaches the end of the entries in each sector, MSCDEX rounds its offset up to the start of the next sector:
	offset += (SECTOR_SIZE - 1);
	offset &= ~(SECTOR_SIZE - 1);
Since the offset did not changed when scanning sector 29 (there were no entries in this sector to increment the offset) the above rounding algorithm does not change the offset (2048 in, 2048 out). This is why MSCDEX continues reading beyond the end of the directory file at sector 29 because the offset did not grow past the directory length. MSCDEX continues reading blank sectors (sectors 29 through 49 are all blank) until it reaches the first non-blank sector.

It looks like what you are attempting to do is implement updatable High Sierra and you want to allocate the directory space ahead of time and fill it in later as needed. The format you are using though is not valid High Sierra and also incurs the cost of reading the blank directory sectors at the end of every directory. Instead, you should record the correct High Sierra directory length in the directory length field for that directory (in this case 2Kb). What remains is finding a place to store the value which tells how many blocks have been reserved for each directory file. There are a number of places this can be done, either in system/application use fields in the directory record, in an XAR, or in a separate file either inside or outside the High Sierra  directory structure. The first is the easiest approach to take.

Be aware thought that CD-I may have plans to use the system use field in the directory record so you may want to investigate Philips' plans to make sure whatever scheme you use meshes well with what CD-I has in mind. The CD-ROM XA specification includes methods for mediating use of the System Use fields in the directory entry that you should look into. MSCDEX will ignore the system use or application use information recorded so you can store what you'd like in the form you like (ascii or binary). You may also want a final pass over the directory hierarchy before mastering to remove extraneous information from the directory record.

Q: I noticed that Function Request 0 Get Number of CD-ROM drive letters may not always return unambiguous results. Suppose I start the network first and use one of the drive letters for a network drive (F:). When I start the Extensions, it will begin assigning drive letters after the last used drive letter (C: on my machine).  If I have 4 CD-ROM drives on my system, they will be assigned drive letters D:, E:, G:, and H:. Function 0 returns 4 in BX for the number of CD-ROM drives and 3 in CX for drive letter D: correctly. But as you can see, the CD-ROM drives do not use contiguous drive letters so I cannot deduce from what this function returns that drive F: is not a CD-ROM drive.

A: That is correct. This is why function 0Dh Get CD-ROM drive letters was added. To get an unambiguous list of CD-ROM drives, use this function or use function 0Bh CD-ROM Drive Check to tell if a drive letter is for a CD-ROM drive.

Q: Is it possible to do an absolute read using the Extensions.  I am trying to read mode 2 (uncooked) data using Function Request 8 Absolute Read. I use a normal device I/O to turn off error correction and perform a read but all I get back is 2048 bytes of data instead of the full 2356 bytes. Is there another way in Int 2F to get the data uncooked?

A: Not at present. If you want to get at the data including error correction code, you will have to communicate directly with the device driver. The Extensions provides the Send Device Driver Request mechanism for communicating with the device driver.

Q: Is it possible to access a non-High Sierra disc with the Extensions using an absolute disc read?

A: One can use either the extensions to read a non-High Sierra disc using INT 2Fh or one can communicate directly with the device driver to do this. The device driver itself makes no distinction between High Sierra and non-High Sierra discs so it can be used to read them although the burden of file system translation and reading then falls on the application talking to the driver. The INT 2Fh Absolute Read function simply packages the request to read and sends it directly to the driver and returns the result.

Q: What we have done is, in AUTOEXEC.BAT, first loaded the MS-DOS CD-ROM Extensions and then the MS-NET software. The error message is "Redirector already installed". The network software is then not loaded.  We are using MS-NET 1.1 in an HP product called ThinLAN. Any hints as to what they should try next?

A: MSCDEX is a CD-ROM "redirector". It hooks into DOS the same way the network redirector does to get requests for file access to files that are not on local hard/floppy disks. As far as DOS is concerned, CD-ROM drives look just like network drives. DOS passes all file accesses through the redirector interface to the network redirector which in turn sends file access requests out over the net. MSCDEX splices itself in front of the network redirector and takes requests belonging to CD-ROM drives and passes the rest to the network redirector.

The problem is that the network redirector code assumes that there will only be one redirector installed (itself) whereas MSCDEX does not make this assumption. If the network redirector is installed after MSCDEX (before it in the interrupt chain), it will process all requests from DOS and never pass any CD-ROM requests through to MSCDEX. For this reason, MSCDEX has to be installed after the network redirector (before it in the interrupt chain) and so MSCDEX prevents the network redirector from installing afterwards to ensure this. Since you installed MSCDEX first, the network believes a redirector is already installed so it does not install itself which is what you are seeing. In order to install both, simply install your network software first and MSCDEX second and you're set.

Q: CHKDSK, ASSIGN, and SUBST report that the CD-ROM is a network disc. Why is this?

A: From the above explanation, you understand that to DOS, the CD-ROM drives look like network drives. The programs CHKDSK, ASSIGN, and SUBST check the same fields DOS does and think the same thing. There is no way to get around this.

Q: RENAME gives error message "Duplicate file name or File not found" instead of something that makes sense such as "Access denied" or "Can't rename CD-ROM files".

A: The error message is coming from the code for RENAME and not MSCDEX.  The error condition is being returned correctly but the error code returned by version 1.01 is correct according to DOS documentation. The problem seems to be that there are two error codes for access denied - 5 and a special one 65 which is error_net_access_denied which is returned by the network redirector when it has a problem. MSCDEX version 2.00 and up returns error code error_net_access_denied and so RENAME now reports "Access denied".