Here's some lengthy info about how the "Serial Driver" works. Hopefully this can clear up some confusion, or serve as a reference for future questions.
When you run the Teensyduino installer on Windows (and you don't click the button to skip driver install), or the stand-alone Serial Installer, it adds an INF file to Windows.
This INF is only needed for USB Serial to work. Since Teensy is not natively USB Serial, you can still reprogram it without the INF. All programming by Teensy Loader is done using HID protocol, not Serial. The HID drivers are built into Windows and automatically recognize all HID devices. You can even use the Arduino Serial Monitor if Teensy is programmed with any of the Tools > USB Type options that don't have "Serial", since it emulates a serial connection using HID in those modes. The INF is only needed to use the Arduino Serial Monitor when Teensy is programmed with Tools > USB Type set to an option with "Serial", and to use other software than communicates with COM ports.
All Arduino brand boards communicate as Serial. USB Serial has much higher bandwidth than HID It's also widely used by lots of other software. For these reasons, the Tools > USB Type menu defaults to "Serial", and of course the installer attempts to add the INF file (unless you click the button to skip installing it).
Even though we're calling this a "driver", the INF file is really just text-only instructions to Windows, to tell it with drivers to load. The actual drivers are USBSER.SYS and SERENUM.SYS, which are files from Microsoft included in all copies of Windows. Unfortunately, more precise terminology to distinguish between the actual executable driver code and mere text-only instructions regarding which driver to use does not seem to exist. Normally, this distinction is a subtle point people don't need to know, but if you're trying to understand strange issues seen on Windows, it can be important to understand the details.
Many USB serial devices exist in the world. If you're used to only Windows, you might believe they're all different, since each seems to require its own driver. However, there are only 3 widely used protocols/drivers: CDC-ACM, Prolific, and FTDI. The later 2 are semiconductor manufacturers who make dedicated USB to Serial converter chips, which have their own proprietary communication protocols created by those 2 companies. CDC-ACM is an open standard published by the USB Implementers Forum, Inc (USB-IF, the non-profit group which publishes official USB standards).
When your computer detects a new USB device (called "enumeration" in USB lingo), several small blocks of data (called "descriptors") are read. The first descriptor contains numbers to identify the device. The most familiar of these are the Vendor ID and Product ID. For products with their own specific drivers, like the FTDI and Prolific chips, these are meant to be used.
Three less familiar numbers in the main device descriptor are Class, Subclass and Protocol. When a device uses one of the
many standard device class protocols, these numbers are meant to identify the device by the communication protocol it uses, rather than who made it. For example, HID devices uses Class=3, with the other numbers either zero or certain values if very specific keyboard and mouse data are used. Class=2 is defined by the Communication Device Class (CDC)
specification. With CDC, Subclass=2 and Protocol=1 refers to Abstract Control Model (ACM), which is a generic serial device, which would use "AT commands" if connected to a modem. Teensy and nearly all software-implemented USB Serial devices use the CDC-ACM protocol, as defined in this official standard from the USB-IF.
Windows, Linux and Macintosh have all long provided the drivers for CDC-ACM devices. On Widows, the actual driver is USBSER.SYS. The Linux kernel developers and Apple's engineers decided to closely follow the USB standards practice. When a device is detected with Class=2, Subclass=2, Protocol=1 (indicating CDC-ACM), they load their driver automatically. Microsoft, unfortunately, only loads drivers automatically for just a few standard USB classes (HID, Mass Storage). Even through CDC is among the oldest USB standards and USBSER.SYS has existed since Windows 98SE & 2000, Windows does not ship with an INF that causes USBSER.SYS to load automatically. Microsoft expects each vendor to ship an INF file and installer program, even if they're merely using standard protocols like CDC-ACM that only require Microsoft's on "in box" (automatically included as part of Windows) driver.
Microsoft recommends writing INF files to use the Vendor ID and Product ID numbers. Nearly everyone copies the same INF (or one of a small collection) and merely changes these 2 numbers and the string for their company name and product name. Microsoft calls this "Hardware-Id" matching. When Windows searches all its INFs to figure out which driver to load, a Hardware-Id match is the highest priority, so publishing an INF this way guarantees the driver you want will load for your specific device, and the strings from its INF will appear in the Windows Device Manager.
Early in Teensy's development (late 2008), I decided to try "Compatable-Id" matching, which uses the Class, Subclass and Protocol numbers instead of Vendor ID and Product ID. Matching this way allows a single INF to match to USB Serial regardless of the Product ID number. It also allows composite (multi-function) devices to match automatically, which specifying which of the multiple interfaces is serial. Since 2008, I have planned to someday create far more USB types. I've also dreamed, since early on, to create a GUI-based tool (and far more flexible USB code on the Teensy side) that lets you pick nearly any combination of those many interfaces. I still want to eventually do this someday, and Compatable-Id matching is much better way than publishing an INF with a huge list of ID and interface number combinations, which would need to be updated as the code develops.
Of course, a downside to Compatable-Id matching in the Teensy USB Serial INF file is the possibility of matching to other non-Teensy devices. In nearly all cases, they just work, because it is a standard USB protocol published by the USB-IF and it's merely loading Microsoft's own USBSER.SYS driver.
Because Hardware-Id matching is at a higher priority as Windows searches for the driver to load, simply installing the original vendors INF or driver will override the Teensy INF with Compatable-Id. Well, at least it will on a Windows system that's working correctly.
Still, occasionally I hear requests for a way to remove the "driver" Teensyduino installs. The easiest and safest way is to follow this
Adafruit tutorial to show hidden devices. Then you can right-click to remove the device, and check the option to completely remove the driver files. Letting the Windows Device Manager do the work is the safest way.
The dangerous way involves finding the .INF in the hidden c:\windows\inf folder. The exact text to search inside the files is:
Code:
%DEVNAME%=DriverInstall,USB\Class_02&SubClass_02&Prot_01
Simply find the .INF file(s) with this text and delete them and any related file (eg, a file with the same name but different extension, like .PNF). Unfortunately, Windows automatically renames the files as it installs them to this directory, so you can't simply look for a specific name. It'll be different on each unique Windows system.
The installer uses the WIN32 function SetupCopyOEMInf to install the INF. I've seen documentation on Microsoft's site for SetupUninstallOEMInf. So far, it seems to be unsupported by the MinGW tools I use to create the installer. I'm hopeful it will someday become supported, so I'll be able to make an uninstaller that calls this WIN32 function.