System Changes Affecting Application Support

The following sections describe how system changes affect 16-bit and 32-bit applications and MS-DOS – based applications.

Windows 95 changes the system configuration files, as described in Chapter 6, "Setup Technical Discussion." The following changes affect application suuport:

Support for Win32-Based Applications

Applications that use Win32 APIs and are designed for Windows 95 can take full advantage of all Windows 95 performance enhancement features. Win32-based applications feature several benefits over Win16-based applications, including preemptive multitasking, Win32 APIs, long filename support, separate message queues, and memory protection. Each Win32-based application runs in its own fully protected, private address space, preventing it from causing the operating system or other applications to fail and preventing interference from errors generated by other applications. An added benefit is that you can manage files from the Open dialog box in Win32-based applications.

To support preemptive multitasking, the Windows 95 kernel schedules the time allotted for running applications. This results in smoother concurrent processing and prevents any one application from using all system resources without permitting other tasks to run. (An exception is when you run an MS-DOS – based application in MS-DOS Mode, which gives the application exclusive use of system resources.) Win32-based applications can implement threads to improve the level of detail at which they can take advantage of multitasking.

Under Windows 3.1, the operating system passes control to another task, allowing that task to be scheduled cooperatively, at the point when an application checks the system message queue. In this case, if an application doesn't check the message queue on a regular basis, or if the application stops and thus prevents other applications from checking the message queue, the system keeps other tasks suspended until the errant application is ended. Under Windows 95, each Win32-based application has its own message queue and thus is not affected by how other tasks access message queues.

Resources allocated for each Win32-based application tracked on a per-thread basis are automatically freed when the application ends. If an application stops responding, you can press ctrl+alt+del to display the Close Application dialog box, and then close the unresponsive application without affecting other running tasks.

To make the most of Windows 95, your applications should:

Win32-based applications that run under Windows NT will run well under Windows 95 if the application does not use any Windows NT-specific APIs (such as those for security) or if it has been designed to run under both Windows 95 and Windows NT.

Support for Win16-Based Applications

Win16-based applications designed for Windows 3.1 run under Windows 95 without modification. Windows 95 ensures that any Win16-based application runs on a 4-MB (or greater) computer as well as or better than it did under Windows 3.1. In addition, the performance of Win16-based applications is improved because it can use operating system services provided by the 32-bit system components of Windows 95, including 32-bit device driver components and 32-bit subsystems.

Windows 95 provides the same system resources to both Win32-based and Win16-based applications, but Win16-based applications cannot take advantage of preemptive multitasking. Win16-based applications share memory, a common input queue, and a common message queue, and their processes are scheduled cooperatively.

Win16-based applications benefit from preemptive multitasking of other system components, including the 32-bit print and communications subsystems and improvements made in system robustness and protection for the Windows 95 system kernel.

Because all Win16-based applications run in the same virtual machine (VM), an errant application can cause other Win16-based applications to fail, but shouldn't adversely affect Win32-based applications. However, the improvements made to overall system-wide robustness significantly increase the system's ability to recover from an errant application and improved cleanup of the system lessens the likelihood of application errors. Windows 95 tracks resources allocated by Win16-based applications and uses the information to clean up the system after an application exits or ends abnormally, thus freeing up unused resources that the rest of the system can use. If an application does fail, you can press CTRL+ALT+DEL to display the Close Application dialog box, and then close the unresponsive application without affecting other running tasks, as described in "Closing Failed Programs" earlier in this chapter.

Note

Win16-based applications cannot use long filenames. The Windows 95 file system should preserve long filenames while you use a Win16-based application to edit files. However, you will lose long filenames if you copy files from within existing Win16-based applications such as user interface replacements.

Support for MS-DOS – Based Applications

Windows 95 includes many improvements over Windows 3.1 for running MS-DOS– based applications, including better printing support and improved capabilities for running hardware-intensive applications such as games.

As with Windows 3.1, each MS-DOS – based application runs in its own virtual machine (VM), which allows multiple 8086-compatible sessions to run on the CPU. This, in turn, allows existing MS-DOS – based applications to run preemptively with the rest of the system. The use of virtual device drivers (VxDs) provides common regulated access to hardware resources. Each application running in a VM appears to run on its own individual computer; this allows applications that were not designed for multitasking to run concurrently with other applications.

VMs are protected from each other, and from other running applications. This prevents errant MS-DOS – based applications from overwriting memory that is occupied or used by system components or other applications. If an MS-DOS – based application attempts to access memory outside its address space, the system notifies the user and ends the MS-DOS – based application.

One of the major difficulties MS-DOS – based applications had in the VMs in earlier versions of Windows was insufficient conventional memory space. By the time MS-DOS – based device drivers, TSR applications, and networking components were loaded with Windows, there often wasn't enough conventional memory left to allow the MS-DOS – based application to load or run. Windows 95 provides 32-bit, protected-mode driver components that replace many 16-bit, real-mode device driver and TSR counterparts, improving overall system performance and using no conventional memory. The memory savings with protected-mode components can be significant. For example, a computer using only Windows 95 protected-mode components would save more than 225K of conventional memory over the amount used by real-mode networking software, drivers for a mouse and SCSI CD-ROM drive, and SMARTDrive.