Jump to content

Virtual CD-ROM switching utility

Edit links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 74.192.84.101 (talk) at 06:44, 23 September 2013 (→External links: adding see also section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Virtual-CDROM switching-utilities are computer software applications used to properly enable USB-connected devices, usually by disabling virtualized optical (CD-ROM) drives; the latter are sometimes presented to the host PC by various non-CD-like devices.[1] The reason the USB-connected device enables a virtual-optical-drive in the first place is usually as a means of auto-installing device driver software. However, the particular auto-installation mechanism used by the device can sometimes interfere with actual device operation, if the device firmware (or device driver software) does not properly support the exact OS version installed on the host-PC. USB-connected printers and USB-connected modems are typical examples of products that sometimes utilize virtual-optical-drives for easy driver-installation; see also usb flash memory sticks which utilize virtual-optical-drives for other purposes, which can need virtual-CDROM disabling-utilities.

Note that the virtual optical drive being discussed here is generated by device-firmware, intended to interact with an upstream host-PC running a normal OS; this use-case is quite different from the scenario where a containing hypervisor-OS is generating a virtual optical drive, intended to interact with a contained guest-OS. The hypervisor often installs a specialized device-driver into the guest-OS, which simulates the existence of a virtual-optical-drive, and keeps the guest-OS from directly interacting with *any* underlying hardware. The guest-OS thinks it is interacting with a physical drive, but in fact it is interacting with the emulation-layer of the (logical) hypervisor-OS. With device-generated virtual-optical-drives, the firmware of the device instead relies on a generic device-driver which is already installed in the upstream-OS, and simulates the existence of a virtual-optical-drive in such a way that the upstream-OS thinks it is interacting with a physical drive, but in fact it is interacting with emulation-layer of the (physical) device-firmware, as opposed to a physical optical drive.

General background

USB-based devices are detected by the USB-driver-subsystem on the host-PC when the device is inserted, via USB enumeration; next, the OS and the USB-connected device engage in a protocol where the device tells the PC what the device does -- or is capable of -- or simply is. Many devices tell the host-PC exactly what they are (a printer says it is a printer and a usbkey says it is a usbkey). However, in some cases the device will tell the host-PC that it is more than one thing: a printer which has an SD slot might say it is a printer-class device, and simultaneously also say it is a mass-storage-class device, which allows the host-PC to interact with the printer's SD slot, as well as with the print-engine of the device. In this fashion, you can plug in one usb-cable to the host-PC, and it will 'see' multiple devices: in this case a printer-device, and an SD-reader-device.

One could imagine accomplishing a similar feat by taking a usb-based printer (no SD slot), and a separate usb-based SD cardreader (with a separate USB cable), then plugging both the printer and the cardreader into a USB hub; when the upstream cable of the USB hub is plugged into the host-PC, it will detect both the cardreader-device (as mass-storage-class) and also the printer-device (as printer-class). When devices contain other devices, such as a printer with an SD slot, they can tell the host-PC that they will be acting as multiple logical USB-based devices. Note that the internal wiring of the printer with the SD slot need not actually be USB-style physical cabling (i.e. with an integrated internal USB-style hub), as long as the printer acts like a USB-based printer, and the integrated SD slot acts like a USB-based cardreader, from the perspective of the host-PC. Some devices actually do contain an integrated USB-hub, but it is often cheaper to wire the printer to the SD slot more directly (and can permit more functionality -- i.e. in this case the printer which is wired directly to the SD slot could print digicam images stored on an inserted SD even when the host-PC was powered off and/or the printer's USB-cable was disconnected).

Specific use-case. The meaning of the term 'virtual' (in the phrase virtual-CDROM switching-utility) implies that there is actually no physical CDROM drive, something like the virtual burner devices but read-only rather than read-write, and therefore furthermore that there is no physical CDROM media, but instead some sort of special CD-like partition or special sort of CD-like ISO file. The explanation for why such things happens is somewhat complex; bear with your wikipedia editors, please. In the particular sorts of device hardware which sometimes necessitate virtual-CDROM switching-utilities, the device again tells the PC that it is more than one thing, or at least, is capable of more than one type of operation. The following list of hypothetical devices will consider USB-based printers, as a concrete example which will help explain the scenarios when switching-utilities are used, and when they are not.

  • Device acts normally at all times, but requires initial installation of driver-software from physical media. In the case of printer#1 with an SD slot, mentioned above, the device told the PC that it was both a printer-class device, and simultaneously a mass-storage-class device; the host-PC will thus see two logical USB-based devices, even though there is only one USB cable. The first time they plug in printer#1 to a particular host-PC, the enduser is on their own when installing the device-drivers for printer#1 (which will allow them to actually print something from the host-PC). The manufacturer of printer#1 might include an SD card in the box, which has the device-drivers for printer#1 on it, but usually they would just send a CDROM for that purpose since those are cheaper.
  • Device acts as usbkey-plus-simultaneously-normal. Consider now printer#2 which has some internal flash-NAND chips, and contained on those chips are device-drivers for the printer-hardware. When such a device is first plugged into a particular host-PC, it might claim to be both a printer-class device (with no drivers yet installed), and also a mass-storage-class device (using the generic USB-MSC-device-driver which ships with the operating system of the host-PC). Then, the enduser could navigate to the printer's storage, figure out how to get the printer's device-drivers installed from the storage-location into the main OS of the host-PC (usually by double-clicking the device-driver filename), and finally be able to utilize the printer properly (opening up a web page and telling the browser to print it on paper via the new printer#2). This is still a considerable number of steps, and therefore subject to various sorts of human error.
  • Device acts as optical-plus-simultaneously-normal. The hardware of printer#3 is identical to that of printer#2, with the device having some internal flash-NAND where the printers-drivers are stored, waiting to be installed. However, the device firmware is written quite differently, because instead of telling the host-PC that it provides a physical printer-class device and a logical mass-storage-class device, printer#3 actually tells the host-PC that it provides a physical printer-class device and an emulated (aka virtual) CD-drive-class device. This is not really true; printer#3 contains no physical parts of a normal optical drive, nor does it contain physical CDROM media. It has an internal usbkey (flash-NAND chip), just like printer#2 did. The first time printer#3 is plugged into a new host-PC, the advantage gained by telling the host-PC it is both a printer and a virtual CD-drive (with a virtual CD-media inside) is as follows: the host-PC sees the printer-class-device, and sees it does not have the proper device-drivers yet installed for that printer. The host-PC also sees a (virtual) CDROM, already inserted into (virtual) optical drive. No special device-driver is needed; the OS already provides a generic device-driver able to operate all optical drives, whether physical or virtual ones. The final piece of the puzzle: there is a special file called autorun.inf stored on the (virtual) CDROM media that printer#3 presents to the host-PC. By convention, the standard[citation needed] behavior of the OS when the enduser inserts a physical CDROM containing an autorun.inf file in the top-level directory is to open the textfile, and execute the specified application, which is also stored on the CDROM media. This default behavior of the OS was codified for devices like printer#1, which come with a physical driver-CD in the box, that the enduser would physically insert, the first time they wanted to use printer#1 with a new host-PC. At the end of the day, printer#3 does not need a physical driver-CD, because it contains a virtual driver-CD. The host-PC does not need an optical drive; the firmware of printer#3 conjures up a virtual-optical-drive. The steps for the enduser are now reasonably simplified: when they plug in the printer for the first time, they get an error-message ('printer detected but no device driver found') in one popup dialog box, and in another popup window they see that autorun.inf is executing an application which installs the necessary device-driver, automatically. (Depending on operating system configuration, the enduser might have to click OK to permit the autorun.inf to execute, and might have to enter a sysadmin password.)
  • Device acts as optical-then-normal. The hardware of printer#4 is again identical (to printer#3 and printer#2), with internal flash-NAND containing the manufacturer-supplied device-drivers for the printer. The firmware of printer#4 is nearly identical to printer#3, and tells the host-PC that it is capable of acting as a printer-class-device, plus also tells the host-PC that it is capable of acting as a virtual-optical-drive-class device (with virtual-CDROM-media inserted and autorun.inf stored thereon). However, to avoid the confusing error message popup window that printer#3 generates ('printer detected but no device driver found' shortly followed by 'device driver for printer installed'), the operation of the firmware in printer#4 is sequential, rather than simultaneous. By default, when you connect the USB-cable from printer#4 to a host-PC for the first time, printer#4 tells the host-PC that it is capable of acting as a virtual-optical-drive ... and makes no mention of the fact that it is also capable of acting as a printer(!). The host-PC uses the generic optical-drive-device-driver to access the virtual-optical-drive provided by printer#4, notices the virtual-CD-media which printer#4 has virtually inserted into the virtual-optical-drive, mounts the filesystem (as a drive-letter or a mountpoint) to make the contents of the virtual-CD-media visible to the OS, reads the autorun.inf, and executes the provided installer-application (optionally prompting the enduser for confirmation and/or permission depending on OS security-settings). Then and only then, after the printer-device-driver is correctly installed on the host-PC, and the printer-device-driver is loaded into the OS of that host-PC, the final step occurs: a special command (which varies based on manufacturer and is not[citation needed] standardized) is sent from the printer-device-driver to the printer, which tells it to enable the (off-by-default) printer-class-device USB profile. Under the hood, this latter step is accomplished[citation needed] by the printer-firmware emulating a USB-hotplug; effectively, the firmware of printer#4 tells the host-PC that a printer-class-device has logically just been plugged in (even though physically it has been plugged in all along). Usually, the printer-device-driver software running on the host-PC will also instruct the virtual-CD-media to virtually eject itself, and instruct the virtual-optical-drive to virtually un-hotplug itself. At the end of the day, the operation of printer#4 is dramatically simplified for the typical enduser: they plug it into their host-PC for the first time, wait a few seconds while the printer installs the proper device-drivers, and then start using the printer. No searching for physical CDROMs, no messing with manually installing driver-software, no hunting the internet for a safe place to download the appropriate driver-software, no confusing error messages, no muss, no fuss: printer#4 just works. If they get a new PC, printer#4 still just works: it contains all the software that is needed, and installs that software automagically.

Generalized use-case. As of 2013 there are many types of devices that function like printer#4, where when you first plug the USB-connector of the device into a host-PC, it tells the host PC that it is a virtual-optical-drive (only), and refuses to function as a printer until and unless the correct printer-device-driver software is installed (because the printer-device-driver software is what sends the special command to the printer-firmware telling it to disable the virtual-optical-drive and enable the printer-class device profile). Printer#4 is a type of virtual-CD-first-then-switch-to-printer-mode device, aka optical-then-normal. There are also several broadband modems (from Huawei and Option and other manufacturers) which work like this: when you plug them in, they pretend to be a virtual-optical-drive, and cannot be switched into internet-modem mode until and unless the proper modem-device-driver software is correctly installed onto the host-PC (or until and unless a virtual-CDROM switching-utility is installed on the host-PC). By way of contrast, these types of optical-then-normal devices are not the only sort: there are a number of devices which act like printer#3, which can be thought of as optical-plus-simultaneously-normal devices (e.g. StartKey fka U3 is an example device-category which looks like a usbkey but has firmware which uses a virtual-optical-drive to load virtual-CD-media containing autorun.inf which then performs portable application management functions).

Problems with optical-then-normal devices.

The approach of adding virtual-optical-drive to auto-install software device-drivers (on 3G or storage devices or printers) has several problems. This approach ships outdated software drivers, burned into the device-firmware (or if the manufacturer's firmware-creation infrastructure is compromised this approach can even ship viruses). Having device-drivers built directly into the hardware-device is often not even necessary: up-to-date drivers are built into the operating system directly, or available from the website of the operating system vendor (Windows Update, Apple Store, Red Hat Network, CentOS.org repo, Ubuntu repo, Debian repo, or similar). Furthermore, many USB devices follow a generic standard, such as USB HID for keyboards/mice/similar, and USB MSC for storage devices, which means that hardware-model-specific device-drivers are not necessary, since likely there is already a standardized generic device-driver built right into any recent operating system, Windows or otherwise. (In the particular case of 3G modems, Linux implements the USB standard in such a way that all 3G devices appear as USB serial ports, which can then be controlled[citation needed] via the de facto standard Hayes AT command-set. Similarly, all USB MSC devices appear to Linux as regular storage-devices.)

Some[who?] would argue that optical-then-normal also raises the overall cost of the device. However, support costs and warranty returns due to customer confusion are more expensive than initial firmware development, in general. If suitable firmware can be written reasonably cheaply, and the end result is an easy-to-use device which reduces the number of helpdesk tickets and product returns, then writing the firmware in optical-then-normal fashion can lower the overall-lifetime costs of developing the product. This is especially true if the firmware infrastructure can be applied to new products, like the optical-then-normal mechanism, which is not specific to any particular type of hardware-device. The main goal[citation needed] of manufacturers who build devices that are designed like printer#4 is to make life easier for the enduser. This is accomplished by making life harder for the firmware authors, who work at the manufacturer of the printer/modem/whatever: to minimize device-driver-installation-hassles for the enduser, the device firmware must be quite complex. There are quite a few tasks that are mandatory.


  • by default, hide the printer-class / modem-class / whatever-class functionality
  • in cases when the host-OS already has the device-driver installed, unhide when instructed to


  • otherwise, pretend to be a virtual-optical-drive
  • pretend to insert virtual-CD-media
  • provide an ISO 9660 / UDF filesystem
  • write the autorun.inf, store it in the right place



Of course, this approach will only work if the enduser is only going to use the device with those *specific* 64-bit operating systems. In order to support other OSes, the firmware author has quite a bit more work to do. Also remember that there is tension between how much money the firmware-project will save the manufacturer in the long run (by reducing support costs), and how much money the firmware-project will cost the manufacturer in the short run (paying the firmware-developer and the firmware testing department -- but also hurting time to market which can significantly harm product sales). Here are the optional tasks, which might increase sales to a larger percentage of the userbase, but might also cost more than they are worth, if the additional userbase is too tiny to justify the driver-development costs, or more importantly, if the driver-development is difficult (buggy drivers cause expensive support calls and warranty returns).



  • write the 32-bit / 64-bit setup.app executable that installs Mac device-drivers, and figure out how to autorun them (without breaking Windows).
  • write the 32-bit device-driver software using ARM compilation for Apple's iOS devices that have USB, if they can act as upstream hosts (versus downstream-only)
  • write the 64-bit foo.app device-driver software using X86-64 compilation for Apple's OSX 10.4/10.5/10.6/10.7/10.8/10.9/etc
  • write the 32-bit foo.app device-driver software using IA-32 compilation for Apple's OSX 10.4/10.5/10.6
  • write the 64-bit foo.app device-driver software using PPC64 compilation for Apple's OSX 10.0/10.1/10.2/10.3/10.4/10.5
  • write the 32-bit foo.app device-driver software using PPC compilation for Apple's OSX 10.0/10.1/10.2/10.3/10.4/10.5
  • write the 32-bit foo.app device-driver software using PPC compilation for Apple's Classic Mac OS 8.5/9


  • write the noarch setup.sh executable that installs Linux device-drivers, and figure out how to get the various distros to autorun, or at least automount (without breaking either Mac or Windows), as well as working around any distro-specific shell quirks and conforming to distro-specific directory layout.
  • write the 32-bit foo.rpm / foo.deb / foo.tgz / foo.apk device-driver software using ARM compilation for Linux kernel 3.x (cf Android 4.x)
  • write the 64-bit foo.rpm / foo.deb / foo.tgz device-driver software using x86-64 compilation for Linux kernel 3.x
  • write the 32-bit foo.rpm / foo.deb / foo.tgz device-driver software using i386/i686 compilation for Linux kernel 3.x
  • write the 64-bit foo.rpm / foo.deb / foo.tgz device-driver software using ppc64 compilation for Linux kernel 3.x
  • write the 32-bit foo.rpm / foo.deb / foo.tgz device-driver software using ppc compilation for Linux kernel 3.x
  • write the 32-bit foo.deb / foo.tgz device-driver software using mips compilation for Linux kernel 3.x
  • write the 64-bit foo.deb / foo.solaris device-driver software using sparc64 compilation for Linux kernel 3.x
  • write the 64-bit foo.rpm device-driver software using s390x compilation for Linux kernel 3.x
  • write the 64-bit foo.rpm / foo.deb device-driver software using itanium64 compilation for Linux kernel 3.x
  • rewrite much of the device-driver software and repackage it in various forms for all the compilation modes for Linux kernel 2.6.x series (cf Android 2.x/3.x)
  • rewrite some of the device-driver software and repackage it in various forms for all the compilation modes for Linux kernel 2.4.x series (cf RHEL 4 thru 2015)
  • rewrite a few of the device-driver software and repackage it in various forms for all the compilation modes for Linux kernel 2.2.18+ series (very rare in 2013)


  • write the noarch setup.sh executable that installs BSD device-drivers, and figure out how to get the various flavors to autorun, or at least automount (without breaking either Linux or Mac or Windows), as well as working around any distro-specific shell quirks and conforming to distro-specific directory layout.
  • write the 64-bit foo.tgz device-driver software using x86-64 compilation for Free/Open/Net/Dragonfly/PC/Ghost/MidnightBSD
  • write the 32-bit foo.tgz device-driver software using i386/i686 compilation for Free/Open/Net/Dragonfly/PC/Ghost/MidnightBSD
  • write the 32-bit foo.tgz device-driver software using ARM compilation for Free/Open/NetBSD
  • write the 64-bit foo.tgz device-driver software using ppc64 compilation for Free/Open/NetBSD
  • write the 32-bit foo.tgz device-driver software using ppc compilation for Free/Open/NetBSD
  • write the 64-bit foo.tgz device-driver software using ultrasparc compilation for Free/Open/NetBSD
  • write the 32-bit foo.tgz device-driver software using mips compilation for Free/OpenBSD
  • write the 64-bit foo.tgz device-driver software using itanium64 compilation for FreeBSD


This is already quite a long list, and most device-manufacturers will be fiscally incapable of supporting anything like this number of CPU architectures and operating system flavors. However, the list above is hardly complete -- it only mentions relatively popular operating systems, with currently-active target architectures, that provide full USB support. Writing device-drivers for OSes that natively support generic USB, but do not natively support USB MSC, adds considerable difficulty, since the firmware author must supply -- via some out of band mechanism like physical CDROM media included in the box with the device -- the necessary OS-specific versions of the USB drivers which support the USB MSC device class, over and above the device-specific driver effort. This can seriously raise the lifetime cost of support; furthermore, the size of the userbase for these older systems is extremely limited (there are no up-to-date security patches for any of them).

  • write the 16-bit setup.exe application that installs that device-driver, and figure out how to point autorun.inf at multiple places
  • write the pseudo-32-bit foo.vxd device-driver software using the DLL approach for Microsoft Windows 95/98/ME
  • write the 32-bit foo.drv device-driver software using the Windows NT specific approach for Microsoft Windows NT3/NT4
  • write the 32-bit foo.app device-driver software using PPC compilation for Apple's Classic Mac OS 7/8.4


Writing device-drivers to support operating systems that do not even natively support generic USB adds extreme difficulty, since usually it would be necessary to include USB interface hardware in the box, in many cases along with floppy disks for the device-driver software. That said, note that some of these architectures *are* currently supported (as of 2013) by modern operating systems, such as the 68k and VAX ports of OpenBSD, which still receive security-patches.


In practice, because supporting non-recent and non-Windows OSes requires time and money, manufacturers of devices sometimes decide only to support recent versions of Windows (or in some cases only to 'officially' support them in theory but in practice help some customers get some other OSes or some older versions of Windows somewhat working). In cases where the manufacturer does provide official support for non-recent-Windows OSes, there is usually still a line drawn concerning which exact platforms are officially supported (the decision tends to be made based on market-share of the OS in question amongst the target segment the manufacturer is seeking), and driver-support may not be complete (missing features / slow to release / buggy / etc). Many devices advertise support for just Windows. Plenty of devices advertise support for Windows and OSX. Not as many devices advertise support for Windows plus OSX plus genericLinuxSlashUnix. Very few devices advertise support only for OSX. Vanishingly few devices advertise support solely for LinuxSlashUnix.

Network effects in the world of device-drivers. The situation outlined above is an example of the network effect: given four technically-competitive systems, for sake of this example say Windows 8 / OSX 10.8 / Linux 3.8 / OpenBSD 8.8, each of which has 25% of the market share now, what will happen over the next ten years? Assume that hardware vendors will produce products that will maximize their profits, and that each vendor produces a new product once per year. Other things being equal, we would expect that a decade from now, none of the OSes would have changed their market share by much. In practice, other things are not equal, and even small difference in the short run can result in big changes over time. Assume that it is slightly cheaper to produce drivers for Win8, because more firmware engineers know how to do it already. The first year, the difference is hardly going to be noticeable: from 25 25 25 25 shares over to 28 24 24 24 shares, say. But the next year, that slight advantage from the previous year is compounded: writing the Win8 driver gives the manufacturer access to 28% of the userbase, at around the same cost as writing an OpenBSD driver, which only gives them access to 24% of the userbase. Thus, the following year the shares have become 34 22 22 22. The same decision-process as last time: Win8 looks better and better! 46 18 18 18, and then the process becomes runaway-exponential, with Win8 quickly gobbling up all the userbase, and the other technically-competitive systems left out in the cold, simply due to more people using the de facto standard.

In an alternative scenario, imagine OSX 10.8 produces slightly higher profits (ROI) that first year for the device-manufacturers; the next year, as long as it still produces slightly higher profits, more and more manufacturers will flock to the platform. However, this alternative is not as convincing: high profit usually means high prices. You can see the lack of a network-effect generated by high profit margins in real life: iOS for the iPhone was a high-profit platform, and with no lower-cost competition, quickly exploded to prominence. However, once the BSD-licensed userland and the GPL-licensed Linux kernel of Android became available, iOS quickly was overtaken, and continues to fall out of favor; Android has become the de facto standard for smart phones, despite starting out slow. The lead of Android is not insurmountable, however, because there is more to the market than smart phones, so a wealthy competitor might attempt to become the low-cost leader.

For smart-phone hardware, Android (and Linux kernel 3.x) is currently the low-cost leader, with the network effects (Android-specific device drivers + Android-specific apk packaging + Android-specific app store + business relationship between Google and handset OEMs + business relationship between handset OEMs and mobile carriers) all heavily reinforcing that lead. For PC desktop and laptop hardware, a recent version of Windows is currently the low-TCO leader, with various network effects (Windows-specific device drivers + Windows-specific .EXE/.MSI/.DOCX/GDI/WFC/etc fileformats + Windows-specific software application market + low-cost sysadmins + business relationship between Microsoft and system OEMs + business relationship between system OEMs and retail outlets) again heavily reinforcing that lead.

Specific workarounds for virtual-optical-drive problems.

Although manufacturers of optical-then-normal devices are primarily[citation needed] trying to make life simpler for the typical enduser, because there are limits to how much time and effort the firmware-authors at the manufacturer can devote to supporting non-recent-Windows-version operating systems, in turn because the world of device drivers for computer peripherals is heavily influenced by network effects, the end result is that manufacturers make life somewhat easier for the typical enduser... as long as they are running the latest version of Windows and don't mind buggy device firmware... but simultaneously make life extremely difficult for atypical endusers, especially those running any other operating system. Optical-then-normal devices are effectively a form of hardware lock-in, by this line of reasoning. Therefore, in addition to purportedly providing the benefit of simplicity to the typical enduser, optical-then-normal devices also have several insidious side-effects:

  • forcing endusers to crossgrade from their non-Microsoft OS to the most recent Windows version
  • forcing endusers to upgrade their older version of Windows to the latest version
  • forcing endusers to abandon their older system for a newer one (cf the Connector Conspiracy with regard to cpu socket / ram slots / peripheral connectors / power connectors / etc).

Endusers that wish to keep using older versions of Windows have little recourse. Without the source code to the low-level portions of the operating system, where device drivers for printers and modems operate, there is not much they can do, even if they are technically savvy, and even if they are willing to devote the time and effort required to overcome the simplistic-simplicity roadblocks that the optical-then-normal approach to device-firmware puts in their way.

Endusers that are running Linux distros or BSD variants have more opportunity to overcome such problems, because they do have access to the source code of their OS kernel, and to the open-source drivers for their platform. It is for these use-case scenarios that the virtual-CDROM switching-utility was invented. Even if the device firmware assumes the enduser is running a recent flavor of Windows, it is possible for a technically savvy enduser to reverse-engineer the procedure which is required for the Windows device-driver-software to command the device-firmware to enable normal functionality (and usually to disable virtual-optical-drive functionality as well). Once that is accomplished, a regular Linux or BSD device-driver for a generic printer or a generic modem can typically[citation needed] be utilized to work with the underlying optical-then-normal device, which has now been properly placed into normal-mode (despite not successfully installing the Windows device-drivers on the host-PC).

Details of the virtual-optical-drive workarounds.

Several new USB devices (especially high-speed wireless WAN equipment) have their Microsoft Windows device drivers onboard; when plugged in for the first time they act like a USB flash drive and start installing the device driver from there. After that (and on every consecutive plugging) this device driver switches the mode internally, the storage device vanishes (in most cases), and a new device (like a USB modem) shows up. The problem with most USB 3G modems is they have two modes. In one mode they are a USB flash drive and in the other mode they are a modem. Typically they only ship with Windows device drivers, sometimes Mac device drivers as well. In any case, they seemingly seldom, if ever, ship with Linux device drivers. What normally happens with Windows is the device starts up as a USB flash drive, the hardware drivers are installed and then they are responsible for "switching" the device in to modem mode so you can use it. This "switch" is done via some codes, specific to the device, which controlling software can pass as a command to switch from disk to modem mode.

A virtual CD-ROM switching utility is a mode switching tool for controlling "flip flop" (multiple device) USB gear. The virtual CD-ROM switching utility (running on host-PC with a Linux or BSD as the operating system) manages the mode-switching of the device, converting it from disk-mode to modem-mode (and usually when switching into modem-mode the program also disconnects the disk-mode , since read-only Windows-specific device-drivers are not useful on a Linux/BSD/OSX system). After switching the device into modem-mode, typical virtual-CDROM switching-utilities will go ahead and configure the modem for use, creating a modem port aka serial device (on Linux systems this might be /dev/ttyUSB0) for the network manager application.[2]

Authors of virtual-CDROM switching-utility software need to figure out the specific control-sequence that will cause a particular family of device-firmware to perform the mode-switching operation. This control-sequence is not standardized[citation needed], and never[citation needed] documented by the device manufacturers. Thus, typically the approach used is for the programmers of the utility in question to boot into a recent version Windows -- one supported by the hardware device in question -- and monitor the low-level operations that occur when the device is installed, and when the Windows device-driver invokes the mode-switching operation of the device-firmware. Libre tools to accomplish this task exist; with USB-sniffing programs and libusb, it is possible to eavesdrop on the communications between the Windows device-driver and the device-firmware, and then to isolate the command or action which performs the mode-switching. The vendor-ID and the device-ID of the model are already known, since they are conveyed to every operating system, by devices which properly implement the USB protocol. Thus, once the specific mode-switching command-sequence is identified, reproducing the same command-sequence from a virtual-CDROM switching-utility running inside Linux or BSD variants is straightforward.[3]

Specific optical-then-normal device families. There is a chipset[vague] from Qualcomm for wireless WAN modems which provides Windows-only device-driver auto-installation via the optical-then-normal mechanism. The Wireless WAN (WWAN) gear maker Option calls this feature "ZeroCD (TM)". The new USB WWAN modem devices manufactured by Option pretend to be a CD-ROM device, which holds the needed Windows device driver to use the WWAN modem. During the USB enumeration process, the firmware of the WWAN modem announces that it acts as a virtual CD-ROM optical drive device (vendor name ZOPTION and device-name ZERO-CD). When a device uses the ZeroCD method means that it behaves as a USB CD-ROM when first connected, with a virtual CD-ROM inserted with the Windows device drivers and related Cosmote control program. Once the Windows device drivers are installed, a special USB command is sent to the device to “switch” it to modem mode.[4]

Specific virtual-CDROM switching-utilities for various OSes.

  • Some 3G devices, for instance from Huawei[5], support complete disabling of the Virtual CD-ROM; this is an example of a manufacturer-provided[citation needed] virtual-CDROM switching-utility.
  • Ozerocdoff is a solution to switch off Option's ZERO-CD, and allow the their modem-hardware to be a used as a modem.[5] Ozerocdoff temporarily disables ZeroCD for USB WWAN modems manufactured by Option.
  • USB_ModeSwitch is another virtual-CDROM switching-utility. From version 1.0.3 upwards there is a simple framework for integrating the switching with udev (the device manager) to make it fully automatic.[3]
  • Switch2modem is designed for switching a 3G USB modem. The program works under OpenSolaris.[6]
  • Fetch (aka huaweiAktBbo.c) is the source code for a utility which can be compiled to re-create the USB communication which is used in Windows.[7]
  • The virtual CD-ROM on U3-compatible devices (optical-plus-simultaneous-normal) can be removed using the u3-tool utility. Note that, unlike the optical-then-normal utilities discussed above, the virtual-optical-drive shipped by Sandisk and their licensees on various usbkeys does not actually prevent use of the usbkey in the normal fashion, so the u3-tool to turn off the U3-provided virtual-optical-drive is not necessary to make proper use of the hardware device. That said, removing the U3-generated virtual-optical-drive frees up some storage-space on the usbkey in question, and keeps the virtual-optical-drive from automounting when the usbkey is plugged in.

Long-term solutions

Standardize the control-sequence. If the mechanism for enabling and disabling logical USB devices was standardized, such that during device-enumeration the device-firmware could indicate to the host-OS which logical sub-devices were intended to be enabled by default, and which logical sub-devices were intended to be disabled until driver-software was properly installed, generic USB class drivers that ship with the operating system could properly handle the optical-then-normal mechanism (without reverse-engineering). Furthermore, this type of generic enable-disable framework could permit the operating system to handle power-management of subsystems in fine-grained detail, especially if the standard specifies power states rather than merely enable-or-disable. For instance, powering down the printhead portion of a multi-function printer device when the user is scanning but not printing, or shutting down the fax-circuit when the device is not connected to a phone line (or when the enduser has specified that they will not be receiving faxes but only sending them).

Release documentation for hardware devices. A related problem is general lack of availability of libre drivers for devices; this problem essentially boils down to lack of detailed device documentation from the manufacturer.[6] The cost-benefit-analysis performed by the hypothetical manufacturer in our example above, who must consider whether paying their firmware-developer and their driver-developer and their QA-team to develop device-drivers for older OSes or for rare CPU architectures is fiscally wise, assumes that the device-manufacturer will be paying for the work, and taking on the burden of support. If technical documentation on how the device worked was available, without requiring NDA paperwork, and without being encumbered by software patents, then the work to write the device drivers for non-mainstream operating systems, and non-mainstream CPU architectures, would effectively cost the manufacturer nothing. Documenting their device in detail is a necessary part of writing the device drivers that the manufacture is already paying for; releasing that documentation to the international libre developer community, so that additional drivers for the hardware can be written, should arguably cost the manufacturer nothing, and conceivably would boost their device-sales considerably (especially if their device is the only one which works on a given OS flavor or CPU architecture).

Standardize internet device-driver repository access. Even if a device driver for (to pick an unlikely example) MS-DOS 6.22 is written someday, that works with the FooModemXL from BazCorp, that does not mean that they device driver will therefore be available from within the FooModemXL itself. Only device-drivers that were written and fully tested when the device was manufactured, and approved by the manufacturer, will be stored on the device-firmware. However, that does not mean that the device firmware cannot help a hypothetical enduser, who is attempting to install the FooModemXL onto their MS-DOS-6.22-based 80486 laptop that they maintain for sentimental reasons. Although the device-drivers actually stored inside the FooModemXL itself will not include the community-written device driver that works with MS-DOS 6.22, there is no reason that the FooModemXL firmware cannot include a forward-looking pointer to where such drivers might be located. This can be implemented as a URL, in a reasonably straightforward fashion. If the FooModemXL attempts to install device-drivers and fails, it can direct the enduser to the website which archives official and unofficial device drivers for the product. This website might be owned by the manufacturer, something like drivers.BazCorp.com/FooModemXL, with a forum system where interested developers can post links to their device-drivers and firmware-mods and such. However, the website might also be run by a federation of manufacturers, such as drivers.usb.org?vid=0x123&did=0x321 -- there is already[7] an existing product-search function at the USB Implementer's website, which could be expanded to encompass device-driver software as well. ("Lists are maintained by USB-IF members themselves and USB-IF does not take responsibility for contents.") Operating system vendors already provide a service for downloading device-drivers specific to their OS, such as the packages.ubuntu.com -- there are also many OS-specific third-party sites, such as rpm.pbone.net and download.cnet.com/windows/drivers and driverguide.com, which can search for apps or drivers across some set of operating systems. Independent websites are preferable, because they can be maintained at no cost to the original manufacturer, and because the original manufacturer of the device is not liable for any problems; furthermore, if the original manufacturer goes out of business, drivers available from a third-party website will remain available.

Replace optical-then-normal device firmware with internet-then-normal device firmware. If a standard third-party website for device-drivers emerges, it makes sense that the device-firmware should eventually begin to rely directly on that site for supplying device-driver software to the operating system. Rather than burning just the device-drivers for a recent-Windows-version into the flash-NAND, the manufacturer can burn the URL of the driver-download website into the flash-NAND, and the generic USB driver on the operating system can check the driver-search portion of the website in question, download a driver (or a driver update) based on sysadmin-configured rules when one is available, and in general make the device work automagically for almost *all* endusers, not just those running a recent-Windows-flavor. There are cases where the device-driver-search will fail, and the enduser will see an error message from their OS, informing them that stable drivers for their hardware do not yet exist. Ideally, the operating system would be smart enough to know what sort of guest-OSes it could support, and also search for device-drivers that would allow the device to function temporarily from inside a virtual machine (using USB-passthrough to permit the guest-OS to directly interface with the hardware in question which is unsupported by the original hypervisor-OS). In cases where automagic search-and-install failed, it would be helpful if the device manufacturer were to print a standard message physically on the outside of their device -- as well as in the device's user manual and product-webpage and so on -- giving the URL of the standard driver site.

See also

  • Floppy_disk_hardware_emulator, circuit board which tricks the FDC chip on host-PC into thinking a physical floppy drive containing a physical floppy disc is attached, when in fact flash-NAND is being used instead
  • Virtual_drive_(disambiguation), for the wide variety of different sorts of 'virtual' drives that exist
  • Disk_image_emulator[8], information has since been deleted from live wikipedia articles
  • Disk image, discusses virtual-(optical)-drives in general, with the emphasis on read-write virtual-burners rather than read-only virtual-CDROM-drives
  • CDemu, for a particular virtual-optical-drive implementation (which however runs inside a Linux OS rather than inside device-firmware)
  • [9], other virtual-optical-drive implementations (usually OS-based mounters like CDemu)

References

  1. ^ USB_modeswitch Virtual CD-ROM switching utility
  2. ^ "Installing 3G USB Modems On Linux".
  3. ^ a b "USB_ModeSwitch - Activating Switchable USB Devices on Linux".
  4. ^ zerocd | StoiloBlog: everyday administration adventures
  5. ^ Debian package ozerocdoff in sid
  6. ^ Getting the Telecom T-Stick working under OpenSolaris
  7. ^ NSLU2-Linux - HowTo / AddUsb3gModem browse
Retrieved from "https://en.wikipedia.org/w/index.php?title=Virtual_CD-ROM_switching_utility&oldid=574145765"