Windows-specific modems work only under Windows because they are not real modems. They are essentially just digital signal processing (DSP) chips; all the modem functions are accomplished in software that, in most cases, is available only for Windows. This makes them cheaper than real modems by a few dollars, and therefore drives real modems out of the marketplace, which is not pleasant for users of non-Windows platforms who need modems.
But even if you are using Windows and it supports your Windows-specific modem, you still might have some unpleasant surprises:
There has been considerable debate about whether these modems, by demanding realtime service from their host Windows computers, impact performance of Windows and its applications. The answer no doubt depends on many factors: the make and model and configuration of the PC; the exact Windows version; the "modem" chip, the driver and version, and so on.
On a typically equipped PC delivered with Windows 95 and a 56K Windows modem preinstalled (and all the other pieces found on recent-model PCs, including sound card, CDROM, etc), frequent "freezing" of Windows was observed during data transfer over the modem, as well as other disconcerting effects; e.g. keystrokes delivered from the event queue in reverse order, rectangular "holes" in GUI windows, etc.
Morever, its performance as a modem, compared to a real modem, was not good. In a controlled test using a Kermit script (similar to this one) that repeatedly dialed a dedicated (i.e. otherwise idle) terminal-server based 56K modem pool, logged in to a host, uploaded a 100K ZIP file, downloaded the same ZIP file, and logged out, the following results were obtained with the 56K Windows modem:
Calls: 1704 BUSY: 16 NO CARRIER: 2 Other call failures: 14 Complete: 1672 Disconnections: 227 = 13.6%
NO CARRIER indicates the call was answered but the modems failed to negotiate a connection protocol. "Other call failures" include ERROR (the modem failed to read a setup or dialing command correctly) and disconnection immediately after the CONNECT message.
For the calls that were completed and not disconnected, the following throughput was observed (the figures would be lower if disconnected calls were included, since the CPS of a failed transfer is 0):
Uploads Downloads Mean CPS 2426 4979 Minimum CPS 1237 1887 Maximum CPS 2910 5156 Standard Deviation 106 370
When we ran the same script with an external 56K modem on the same PC, we obtained the following results:
Calls: 2112 BUSY: 7 NO CARRIER: 0 Other call failures: 0 Complete: 2105 Disconnections: 0 = 0% Uploads Downloads Mean CPS 2700 4765 Minimum CPS 518 2111 Maximum CPS 3257 5157 Standard Deviation 332 779