Virtual CD-ROM switching utility: Difference between revisions

Revision as of 02:38, 23 September 2013

Revision as of 04:38, 23 September 2013

Line 15:

* 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|date=September 2013}} 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 [[ISO file | 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 [[ISO 9660 | 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|date=September 2013}} 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|date=September 2013}} 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 [[mobile broadband | 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).

Line 23:

==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 [[Stuxnet | 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|date=September 2013}} via the de facto standard [[Hayes]] AT command-set. Similarly, all USB MSC devices appear to Linux as regular storage-devices.)

Some{{who?|date=September 2013}} 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|date=September 2013}} 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.

Line 95:

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 [[68040 | 68k]] and [[VAX]] ports of OpenBSD, which still receive security-patches.

* 16-bit device-drivers software using the older{{citation needed|date=September 2013}} [[DLL]] approach for [[Microsoft Windows]] 3.0/3.1/3.11wfw

* 16-bit foo.exe device-driver software using the [[EXE]] approach{{citation needed|date=September 2013}} for [[MS DOS]] 3.3/4.0/5.0/6.0/6.22[https://en.wikipedia.org/wiki/USB_mass-storage_device_class#MS-DOS]

* write the 32-bit foo.app device-driver software using PPC compilation for Apple's [[Classic Mac OS]] 5/6/7[https://en.wikipedia.org/wiki/PowerBook_3400#CardBus_compatibility]/8[https://en.wikipedia.org/wiki/Power_Macintosh_G3#Upgradability]

* write the 32-bit foo.app device-driver software using 68k compilation for Apple's [[Classic Mac OS]] 1/2/3/4/5/6/7/8.1

Line 117:

==Specific workarounds for virtual-optical-drive problems.==

Although manufacturers of optical-then-normal devices are primarily{{citation needed|date=September 2013}} 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

Line 125:

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|date=September 2013}} 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.==

Line 133:

A virtual CD-ROM switching utility is a mode switching tool for controlling "flip flop" (multiple device) [[Universal Serial Bus|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 <tt>/dev/ttyUSB0</tt>) for the network manager application.<ref name="3g_usb_modems ">{{Cite web|url=http://www.drupaler.co.uk/blog/installing-3g-usb-modems-linux/497|title=Installing 3G USB Modems On Linux}}</ref>

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|date=September 2013}}, and never{{citation needed|date=September 2013}} 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 (computing)|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.<ref name="usb_modeswitch">{{Cite web|url=http://www.draisberghof.de/usb_modeswitch/|title=USB_ModeSwitch - Activating Switchable USB Devices on Linux}}</ref>

'''Specific optical-then-normal device families.''' There is a [[chipset]]{{vague|date=September 2013}} 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.<ref>[http://stoilis.wordpress.com/tag/zerocd/ zerocd | StoiloBlog: everyday administration adventures]</ref>

'''Specific virtual-CDROM switching-utilities for various OSes.'''

* Some 3G devices, for instance from Huawei[http://www.techytalk.info/disable-virtual-cd-rom-drive-with-built-in-software-on-huawei-and-zte-gsm-modem-devices], support complete disabling of the Virtual CD-ROM; this is an example of a manufacturer-provided{{citation needed|date=September 2013}} 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.<ref>[http://packages.debian.org/sid/ozerocdoff Debian package ozerocdoff in sid]</ref> Ozerocdoff temporarily disables ZeroCD for USB WWAN modems manufactured by Option.