ECDP communicates with the SCSI drive via your controller card's ASPI driver. ASPI is a protocol originally promoted by Adaptec that provides a card independant method for communicating with a SCSI controller. Supposedly, this lets the program use any SCSI card on the market that supplies such an ASPI driver; I can't vouch for how well that works for anything but the Adaptec 2940W, but you can ask Incat about compatibility problems if you're using another type of card.
Windows 95 supplies fancy new 32-bit device drivers for all the SCSI cards it supports, and happily those drivers speak ASPI as well. If you've still using an older ASPI driver installed to support your devices under DOS, Win 95 will continue to use it instead; you really should ditch those old 16-bit drivers by removing the references from your CONFIG.SYS and use these new ones instead (by default, the Win 95 install will leave your old drivers, even though it doesn't need them). If you do that, you can get rid of the reference to MSCDEX from your AUTOEXEC.BAT as well and the system will automatically load the new and improved version of that as well.. In any case, installing ECDP in Win 95 was quick and didn't even require a reboot.
Windows NT doesn't support ASPI normally. What ECDP does is install an ASPI compatibility layer over top of the SCSI drivers that NT does have. Reboot once, and the ASPI driver is transparent to you but lets ECDP operate. As a random note, if you're using NT 3.51, I highly recommend using the latest NT Service Pack from Microsoft; I had a couple of odd SCSI problems that cleared themselves up nicely after patching everything with service pack #3.
After installing the latest version of Easy-CD Pro 95 (V1.1.410 at this writing, unless they've come out with another one while I've been typing), running the software pops up a box stating what CD-R drives the program found and then moves to the main program interface. ECDP revolves around documents referred to as projects; each project contains information about what type of CD you're making, what parameters to use, and where the files involved are sitting at. This project interface means that you can create a CD, save the project file, then create another copy later by running the program again. This is assuming you haven't moved any of the files referenced around since your burnt the original. The program interface has everything labeled clearly enough on the menus, along with a somewhat cryptic icon toolbar that I ignored. You can only have one project opened at once. The manual should be only considered a brief introduction to the program, as it appears quite out of date and incomplete. Skim it to get an overview of the program, but be prepared to spend an hour or two reading through all the on-line help to get the real story on how everything currently works. I highly recommend reading all of the nested help items first before you start wasting your money burning bad CDs.
Aftering choosing to create a new project, a dialog box appears asking what type of CD you want to create. Normal choices are making a data CD-ROM, a Red Book style audio CD (called a CD-DA), or a mixed mode CD with some data and some audio. There are some variations on these basic themes, including support for the CD-XA format (which is used for Photo CDs and CD- I). There are also some items related to dealing with ISO 9660 image files. An image file is an exact copy of data on a CD, with the sectors laid exactly like they will be written to the CD. One reason to make an ISO 9660 image is that it takes care of all the layout overhead beforehand, which means you don't need nearly as fast of a system to write the data to CD. I hear that there are programs that let you test an image like this as if it were a real CD without actually burning a copy, but don't ask me to remember where I saw that tidbit of information at. We won't be talking about ISO 9660 images anymore here, because they are strictly an organizational method for data CDs that have lots of files on them, making them a useless concept for audio CDs.
ECDP flawlessly copied all the data CD-ROMs I threw at it without incident. There may be data it can't copy, but I don't know how you could pull that off and still have a CD that could be read in everyone's drive; I'm sure someone is working on the problem.
In fact, data CDs in general didn't cause me any problems. The interface for creating them works on a drag-and-drop metaphor. Run a copy of Windows File Manager, select the files, and drag them into ECDP's data window. There are a number of options to configure as far as what file names are supported that affect what computers can read your data CD, and some other general configuration information. It's all fairly simple for your usual data CD. The only complicated function is the reparent one, which lets store things in a different directory then the one they started at (it didn't work quite like I thought it did, and I ended up creating one bogus CD because of it). But overall, data CDs were smooth sailing; after all, that's what most people are buying the drives for, so you'd expect that process to be well debugged, well documented, and reliable . Audio CDs were another story. First time I copied one, I played it back and it worked great. Excellent, I thought; two more copies of other irreplacable CDs followed, they both seemed fine as well. Until, that is, the first time I listened to one all the way through. It was one of those concept albums where the tracks flow into each other without normal fades and such. Well, between every track, the music stopped for a bit! There were two seconds of silence between every track, ruining the whole continuity of the the CD. This segue killer was certainly not something I could live with.