DOCUMENT:Q80901 06-NOV-1999 [win16sdk] TITLE :Windows 3.1 Application Compatibility (part 6 of 7) PRODUCT :Microsoft Windows Software Development Kit PROD/VER:WINDOWS:3.1 OPER/SYS: KEYWORDS:kb16bitonly ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Windows Software Development Kit (SDK) 3.1 ------------------------------------------------------------------------------- SUMMARY ======= Application Compatibility Document for Windows 3.1 -------------------------------------------------- Due to the amount of information in this document, it has been broken into seven pieces. To find all seven pieces of this document and the Windows 3.1 Compatibility Test checklist, query this knowledge base on the words: " prod(winsdk) and 31compattest " (without the quotation marks) Enhanced-Mode Windows --------------------- COMM DRIVER ----------- Performance and functionality of the Windows version 3.1 COMM driver are improved as follows: - COMM.DRV provides its own interrupt handling in enhanced mode. In Windows version 3.0, the virtual communication device (VCD) provided the interrupt routine so that interrupts for Windows applications could be handled at ring 0. In Windows version 3.1, a new function allows COMM.DRV to register its own ring-0 handler, ensuring that all communications code exists in COMM.DRV. The VCD can still support COMM drivers that are compatible with Windows version 3.0 by adding the SYSTEM.INI switch "COMMDRV30=TRUE" in the [386ENH] section. - Both COMM.DRV and VCD read the COMxBASE and COMxIRQ settings in the SYSTEM.INI file to determine the base addresses and IRQs for COM3 and COM4; reading values written into the BIOS data area is no longer required. Although for compatibility these settings are in the [386ENH] section, COMM.DRV also examines them when running in standard mode. - COMM.DRV supports the FIFO on 16550A UARTs. By default, COMM.DRV enables the FIFO if the FIFO is available, but the user can disable the FIFO by using the COMxFIFO setting in the [386ENH] section of the SYSTEM.INI file. - COMM.DRV baud rate is limited only by machine capability, so communication applications need not limit baud rates to 19200. Some users do have hardware capable of faster rates, and they don't like being stuck with an artificial limit. Potential Problem ----------------- Changes to COMM.DRV could affect any application that uses the communications driver. Test ---- You can test most changes to COMM.DRV by sending and receiving data in your application at various baud rates. VIRTUAL PRINTER DEVICE ---------------------- The standard setup no longer includes the virtual printer device (VPD). In Windows version 3.0, the VPD detects contention between multiple VMs attempting to access the same LPT port. To detect contention, VPD traps I/O for LPT ports, which creates too much overhead for devices that use LPT ports, such as network adapters, SCSI adapters, and external hard disks. Windows version 3.1 eliminates the overhead by not installing the VPD. Potential Problem ----------------- Although changes to the virtual printer device installation should not affect applications, Windows version 3.1 cannot detect the rare case of two applications attempting to print through the same port at the same time. VIRTUAL DMA DEVICE ------------------ In Windows version 3.1, VDMAD supports auto-initialize DMA as long as the region being used can be locked and does not have alignment problems. This means that TSRs and device drivers can use auto- initialize DMA with global memory. VDMAD also deals with DMA globally rather than through VM. This means that most global users (network, disk, and so on) no longer need a separate virtual device to coordinate their DMA activity when they set up DMA transfers using hardware interrupts. Finally, all problems in the virtual DMA services implementation have been corrected; relying on private versions of VDMAD is no longer necessary. Potential Problem ----------------- Changes to the VDMAD may affect applications that include their own version of VDMAD. Test ---- If your application has a custom VDMAD, thoroughly test the application with the new VDMAD. Also, be sure that your installation program does not overwrite the device=*VDMAD setting in the SYSTEM.INI file. VIRTUAL TIMER DEVICE -------------------- In Windows version 3.1, the virtual timer device (VTD) does not trap the I/O ports used for accessing the system timer chip. This allows more MS-DOS software to run better in VMs because I/O trapping adds significant overhead. The VTD keeps timing in sync by watching other activity, for example, by counting hardware interrupts that are not passed to the BIOS. Thus, the VTD does not prevent applications from reprogramming the timer to different rates. The TrapTimerPorts setting was added to the SYSTEM.INI file to revert to Windows version 3.0 compatible behavior if problems do occur because of this change. Potential Problem ----------------- Changes to the virtual timer device may affect applications that are not based on Windows. Test ---- Start several other MS-DOS-based applications, and then start your MS-DOS- based application and check for timer problems. If problems arise, set the SYSTEM.INI setting TrapTimerPorts and try the tests again. VIRTUAL DISPLAY DEVICE ---------------------- In Windows version 3.1, the standard virtual display device (VDD) for VGA is modified to demand page video memory. Thus, you can run graphical MS-DOS-based applications in a window or in the background on VGA systems. This VDD must track video memory usage, so it is not compatible with any of the super VGA display drivers that must access more than 256 kilobytes (K) of video memory. To run these display drivers, a user must use either the VDD provided by the display adapter manufacturer or the VDDVGA30.386, which is included with Windows version 3.1. Demand paging of video memory may break TSRs that worked with Windows version 3.0. The difference is that the VDD virtualizes access to video memory; in Windows version 3.0, the display driver had full reign over memory. Potential Problem ----------------- Changes to the video device driver may affect applications that work directly with video memory and TSRs. Test ---- Start your application or TSR in one or more virtual machines, and then switch between virtual machines, watching for problems with the display. FASTDISK (WDCTL) ---------------- FastDisk allows specific virtual devices (currently WDCTL) to access secondary storage devices directly. WDCTL supports Western Digital and compatible controllers. This device speeds up disk activity and allows demand paging of running VMs. Test ---- FastDisk should not affect any applications. Be sure you are running it while testing your application. Additional query words: 3.10 no32bit ====================================================================== Keywords : kb16bitonly Technology : kbAudDeveloper kbWin3xSearch kbSDKSearch kbWinSDKSearch kbWinSDK310 Version : WINDOWS:3.1 ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 1999.