Chapter 27 - Windows Compatibility and Migration

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This chapter begins with a discussion of interoperating with Windows 3.x, and it describes what does and does not get migrated upon upgrading to Windows NT Workstation 4.0. After this comes a discussion of the compatibility of the 16-bit Windows subsystem with Windows 3.x applications and the restrictions on applications running under it. This chapter also explains in detail how the 16-bit Windows subsystem is implemented.

Next, the chapter describes compatibility with Windows NT 3.51.

Finally, this chapter presents a discussion of upgrading Windows 95 to Windows NT Workstation 4.0. Also included is an explanation of issues of compatibility, reliability, and security within a mixed operating system environment that includes Windows NT and Windows 95.

Compatibility with Windows 3.x

Windows NT provides a straightforward upgrade from any Windows 3.x operating system. The 16-bit Windows subsystem includes a layer that emulates MS-DOS, and a Win16-on-Win32 (WOW) layer that emulates the functionality of Windows 3.1 and 16-bit API stubs. Win16 applications can run in their own or in a shared memory space.

Interoperating with Windows 3.x

If a previous version of Windows (Windows 3.x, Windows for Workgroups) is installed on your computer, and you want to run your installed applications from both the previous version of Windows and from Windows NT, then install Windows NT in the same directory as the previous version of Windows. This allows Windows NT to configure the Windows environment based on the existing environment and allows Windows NT to support the features of currently installed applications.

Note For information about interoperating with Windows 95, see "Compatibility with Windows 95" later in this chapter.

When the first logon occurs on the newly-installed Windows NT computer, the system migrates Reg.dat and portions of the various .ini files from the previous version of Windows to the Registry in Windows NT. See the following section "What is Migrated at the First Logon" for a complete list. The status of each step in the migration is recorded in the Application Log, which can be viewed with Event Viewer. For more information about Event Viewer, see Chapter 9,"Monitoring Events," of Microsoft Windows NT Server Concepts and Planning

The first time new users log in, Windows NT presents a dialog box that lets them select the parts of the previous version of Windows to migrate into the Windows NT environment. The users can select whether to migrate the .ini files and/or the Program Manager .grp files to the Registry. If the users cancel the dialog box and would later like to migrate the files, they must delete the following keys from the Registry and then log off and log back into Windows NT:

HKEY_CURRENT_USER \Windows 3.1 Migration Status

HKEY_LOCAL_MACHINE \SOFTWARE \Windows 3.1 Migration Status

Refer to Part 5, "Windows NT Registry," for information on the Registry and its entries.

Note The per-user dialog box and migration option do not happen for the Administrator, Guest, and System user accounts.

If users choose to migrate the .ini files, then each time they log into Windows NT, the system reads the Win.ini file and the System.ini file and stores the information in the Registry. When the user logs off from Windows NT, the system updates the Win.ini file and the System.ini file with any changes made to the environment. This keeps the configuration of Windows NT and the previous version of Windows synchronized with each other.

If Windows NT is not installed in the same directory as the previous version of Windows, then configuration changes made under one version of Windows are not available to the other version. The same is true if you install Windows 3.x after installing Windows NT.

If you install an application under Windows 3.x after installing Windows NT, that application would not be available in Windows NT. You can reinstall the application under Windows NT (into the same directory into which it is installed under Windows3.x). Or, you can delete the two Windows 3.1 Migration Status registry keys mentioned earlier in this section, and then remigrate the settings by logging on again.

Regardless of where Windows NT is installed, changes made to the Desktop or to the arrangement of the Program Groups are not synchronized with the previous version of Windows.

Note Setup installs TrueType font and font header files in *%SystemRoot%*SYSTEM\FONTS. Be careful not to delete the TrueType files from this directory. These files are used by Windows NT 32-bit applications as well as 16-bit applications. For more information on the TrueType font and font header files included with Windows NT, refer to Chapter 8, "Fonts."

What Is Migrated at the First Logon

The following items are migrated to the Registry when the first logon occurs on a newly-installed Windows NT computer:

All OLE information kept in the Windows 3.x registry (Reg.dat)
The following sections and variables from the Win.ini file and stored in HKEY_CLASSES_ROOT:

[Compatibility]

[Embedding] (except SoundRec, Package, and PBrush)

[Fonts]

[FontSubstitutes]

[Windows]
DeviceNotSelectedTimeout
Spooler
TransmissionRetryTimeout

When Each User First Logs On

The following sections describe what is and what is not migrated when each user first logs on.

What Is Migrated

The following items are migrated the first time new users log in, if they select to migrate the .ini files and the .grp files. This per-user migration does not happen for the usernames Administrator, Guest, and System.

The following sections and variables from the Win.ini file:

[Windows]

CursorBlinkRate

BorderWidth

ScreenSaveTimeOut

ScreenSaveActive

KeyboardSpeed

KeyboardDelay

Beep

SwapMouseButtons

DoubleClickSpeed

DoubleClickHeight

DoubleClickWidth

MouseThreshold1

MouseThreshold2

MouseSpeed

SnapToDefaultButton

Spooler

DeviceNotSelectedTimeout

TransmissionRetryTimeout
The following sections from the Control.ini file:

[Color Schemes]

[Current]

[Custom Colors]

[Patterns]

[Screen Saver.Marquee]

[Screen Saver.Mystify]

[Screen Saver.Stars]
The following section from the Winfile.ini file:

[Settings]
The entire Viewer.ini file.
The entire Ntbackup.ini file.
The entire Clock.ini file.
The entire Schdpl32.ini file.
The following section from the System.ini file:

[Drivers]

What Is Not Migrated

Persistent shares and users from Windows for Workgroups.
Default domain and user ID from Windows for Workgroups or the Lanman.ini file.
Per-user profiles maintained by the WINLOGIN add-on product for Windows for Workgroups.
Any changes that users have made to their Accessories, Games, Main, and Startup groups in Windows 3.x. These groups are not migrated because their names match the names of 32-bit Windows NT Start menu groups.
MS-DOS drive letters. If you have FAT partitions and HPFS or NTFS partitions on a computer that dual-boots MS-DOS and Windows NT, use Disk Administrator to assign drive letters to your non-FAT partitions. Begin with the first drive letter after the one that MS-DOS assigns to your last FAT partition. This ensures that the FAT partition drive letters are the same for both systems and that any migrated path names are valid.
The options Auto Arrange, Minimize on Run, and Save Settings on Exit from the Progman.ini file.
Font information for character-mode command windows.
The Language and Keyboard settings in the International applications.
The default screen saver (Scrnsave.exe) in the [BOOT] section of the System.ini file. 16-bit screen savers are ill-behaved under Windows NT.
The [Settings] section from the Winfile.ini file.
All 16-bit Windows 3.x Program Manager group files listed in the Progman.ini file. If a group name (contained in the group file, not the actual .grp filename) matches the name of a 32-bit Windows NT Personal or Common Start menu group, then that 16-bit group will not be migrated (for example, Accessories, Games, Main, and Startup). Each group is migrated "as is."
The Country setting in the international applications.

Running Win16 Applications

The 16-bit Windows subsystem runs 16-bit Windows-based applications, which you can launch from My Computer, Windows NT Explorer, or from the command prompt. There are no user-visible distinctions between 16-bit and 32-bit Windows-based applications.

Restrictions on Win16 Applications

This section describes the few restrictions that apply to running applications under the 16-bit Windows subsystem:

All MS-DOS functions except task-switching APIs (application programming interface functions) are supported.
Block mode device drivers are not supported. (Block devices are not supported, so MS-DOS IOCTL APIs that deal with block devices and SETDPB functions are not supported.)
Interrupt 10 function 1A returns 0; all other functions are passed to read-only memory (ROM).
Interrupt 13 calls that deal with prohibited disk access are not supported.
Interrupt 18 (ROM BASIC) generates a message that says ROM BASIC is not supported.
Interrupt 19 will not reboot the computer, but will cleanly terminate the current virtual DOS machine (VDM).
Interrupt 2F dealing with the DOSKEY program call outs (AX = 4800) is not supported.
Microsoft CD-ROM Extensions (MSCDEX) functions 2, 3, 4, 5, 8, E, and F are not supported.
The 16-bit Windows subsystem on an x86 computer supports Enhanced mode applications; it does not, however, support 16-bit VXDs (virtual device drivers). The subsystem on a non-x86 computer emulates the Intel 40486 instruction set, which lets the computer run Enhanced mode applications, such as Visual Basic®, on RISC computers.

Terminating the Subsystem

If an ill-behaved application locks up the 16-bit Windows subsystem, you can terminate the subsystem.

To terminate the 16-bit Windows subsystem

Press CTRL+SHIFT+ESC to display Task Manager.
Click the Applications tab.
Click to select the application.
Click End Task.

If the application does not respond, an additional dialog box appears giving you the option to wait or to end the task.

Implementation of the Subsystem

The following sections describe the 16-bit Windows subsystem.

VDM Structure

The 16-bit Windows subsystem is implemented as a virtual MS-DOS machine (VDM) with a layer that emulates Windows 3.1 functionality. By default, 16-bit Windows-based applications run in a single VDM, a multithreaded Win32 process in which each application runs in its own thread. Windows NT preemptively multitasks the VDM with respect to other processes but cooperatively multitasks the Win16 apps with respect to each other.

Each Win16 and MS-DOS application can, however, run in its own private address space, thus protecting it from other Win16 programs. This allows Windows NT to preemptively multitask all operating system services and all applications.

To run each Win16 application in its own VDM

Right-click the Start button.
Click Open.
Locate the Win16 application, and click to select it.
Click Properties on the File menu.
Click the Shortcut tab.
Select the Run In Separate Memory Space check box.
Click OK.

The following diagram shows the 16-bit Windows subsystem VDM. A description of each layer follows.

Cc768131.xwr_z01(en-us,TechNet.10).gif

Figure 27.1 16-bit Windows Subsystem VDM

The 16-bit MS-DOS emulation layer contains all the information to emulate BIOS calls and tables. Some 16-bit Windows applications depend upon BIOS calls, because 16-bit Windows is built on top of MS-DOS.

The Windows 3.1 emulation layer provides the functionality of the Windows 3.1 kernel and 16-bit API stubs. A 16-bit application cannot call a 32-bit API routine. When an application calls a 16-bit API routine, that call is made to a stub routine, which in turn calls a 32-bit API routine. The 32-bit API routine performs the required action, and the result is transformed back into the format expected by the 16-bit API stub, which returns the result to the application. The transformation between 16-bit and 32-bit formats is known as thunking and is carried out by the 32-bit WOW translation layer. (WOW stands for Win16-on-Win32.)

16-bit Windows-based applications use the memory from 640K to 16 MB for their own purposes.

Windows NT does not support 16-bit device drivers that have unrestricted access to hardware (character-mode device drivers that do not depend on special hardware are supported). A secure and robust multitasking operating system cannot let user-level applications talk directly with the hardware because they could completely bypass security and crash the system. (There are exceptions to this, however; refer to "Restrictions on Win16 Applications," earlier in this chapter). The VDM contains a layer of virtual device drivers (VXDs) that allow the sharing of hardware and provide the necessary functionality in a way that is consistent with the design of Windows NT.

The 32-bit MS-DOS emulation layer is for the DOS Protect Mode Interface (DPMI) and 32-bit memory access. This layer replaces calls made to the MS-DOS-level functions for extended and expanded memory with Windows NT memory calls. Windows NT then makes the appropriate conversions so that the 16-bit application sees segmented memory as it normally would.

For Windows NT running on a non-x86 computer, the Instruction Execution Unit emulates the Intel 80486 instruction set, which lets the computer run the binary application.

On an x86 computer, the Instruction Execution Unit acts as a trap handler, capturing instructions that cause hardware traps and transferring control to the code that handles them. A VDM (such as the 16-bit Windows subsystem) on an x86 computer supports Enhanced mode applications; it does not, however, support 16-bit VXDs (virtual device drivers).

Input Queue

Under Windows NT, each application has its own input queue. This eliminates lockups due to programs halting the queue. Under Windows 3.x, all applications receive input from the same queue. As in Windows 3.x, the 16-bit Windows-based subsystem provides just one input queue. A 16-bit Windows application can lock up the subsystem by halting the queue. This does not affect any 32-bit applications running under Windows NT, as they each have their own input queue.

If, however, you run each Win16 application in its own VDM, each application is then treated by Windows NT as a Win32 application, and each has its own input queue.

Scheduling

Within a VDM, threads are scheduled cooperatively. Because Win16 applications running in a single VDM share memory, a single input queue, and are scheduled cooperatively, an ill-behaved application can cause the subsystem to lock up. This will not affect the rest of Windows NT, because Windows NT treats the VDM as a whole just like any other 32-bit application. Each VDM is scheduled preemptively along with all of the other 32-bit applications. Running each Win16 application in its own private address space causes it to be preemptively multitasked.

Files Used

The following are the principal files used by the 16-bit Windows subsystem:

File	Purpose
Ntvdm.exe	The main loader for a VDM.
Wowexec.exe	Provides the Windows 3.1 emulation for the VDM. The first time you launch an MS-DOS or Win16 application, the WOWEXEC program is loaded, making that VDM the 16-bit Windows subsystem.
Wow32.dll	Provides the DLL portion of the Windows 3.1 emulation layer. When you use the PViewer utility to look at running NTVDM processes, you can identify the one that is the 16-bit Windows subsystem by Wow32.dll being listed in its memory detail.
Autoexec.nt Config.nt	Used to boot the files necessary for running 16-bit Windows applications. The Autoexec.nt and Config.nt files are usually in the \SYSTEM32 directory, but you can change this location by using _Default.pif. Windows NT creates the Autoexec.nt file from the Autoexec.bat file and creates the Config.nt file from scratch. It writes comments to the Autoexec.bat and Config.sys files that describe the .NT versions. Refer to the Windows NT System Guide for more information.

Communication with Other Subsystems

An application running under the 16-bit Windows subsystem can communicate with applications in other subsystems (as well as with 32-bit applications running under Windows NT) through the usual mechanisms of Object Linking and Embedding (OLE), Dynamic Data Exchange (DDE), and named pipes.

Compatibility with Windows NT 3.51

When you upgrade from Windows NT 3.51 to 4.0, your user profile is converted. However, because of the changes to the user interface between 3.51 and 4.0, some of the settings do not migrate. If you are working in a mixed environment that includes both 3.51 and 4.0, you will have a separate user profile for each version. Changes made to one won't be reflected in the other.

Compatibility with Windows 95

It would be impossible to satisfy the broad range of home and business computer needs, as well as technology constraints, with a single operating system. For example, "complete reliability" and "real-mode device driver support" are mutually exclusive features that cannot be built into a single operating system. In response to these challenges, Microsoft's strategy is to provide a family of operating systems. Using both Windows 95 and Windows NT in a single network environment, today's corporation gets the best of flexibility, reliability, compatibility, and security.

Upgrading from Windows 95 to Windows NT 4.0

Because of differences in their respective registries and in hardware device support, no automatic upgrade path from Windows 95 to Windows NT Workstation currently exists. An upgrade path is planned for the next release of Windows NT Workstation.

You can manually upgrade from Windows 95 to Windows NT by installing Windows NT in a separate directory. No system or application settings will be migrated, and you will need to reinstall each application after Windows NT is installed. You should then delete the Windows 95 directory, although this step is optional.

A dual boot (giving the user a choice of operating systems on startup) is not recommended and is not supported. Windows NT does not support all the device drivers that Windows 95 does. A few Windows 95 device drivers require direct access the hardware, such as sound cards, video, scanners, hard disk, and so on. In Windows NT, only the Hardware Abstraction Layer (HAL) of the microkernel has access to the hardware. Where the application vendor has not provided the necessary driver for Windows NT, those device drivers aren't supported. Windows NT also does not support Virtual Device Drivers (VXDs), such as multimedia titles, games, and memory management applications.

Both Windows NT and Windows 95 support long filenames.

For more information about running a mixed environment including Windows NT and Windows 95 computers, see Chapter 4 "Planning For A Mixed Environment."

Registry Incompatibility

The registries in Windows NT and Windows 95 use different file formats and are structured differently, rendering the two incompatible for migrating system and application settings. For example, although both systems support roaming user profiles (desktop settings that follow users, by means of their user accounts, from computer to computer), users accessing both Windows 95 and Windows NT computers need two user profiles. Changes made to one will not affect the other. For more information, see Chapter 3, "Managing User Work Environments," in Microsoft Windows NT 4.0 Server Concepts and Planning.

System Reliability and Performance Comparison

Windows NT protects all of its operating system code by locating it in either kernel mode (or Ring 0 of the Intel protection model) or in protected subsystems in user mode (or Ring 3), each of which runs in its own address space. Thus, all Windows NT operating system code and data are protected from applications.

Applications, which run in user mode, have access only to their own address spaces. To communicate with system services, an application must utilize specific application programming interfaces (APIs) to convert their threads from user to kernel mode. In order for the application to regain control of the threads, they must be converted back to user mode. Thus, applications have no access to the memory of the subsystems and cannot interfere with the operating system or its support of other applications.

For more information about kernel and user mode, see "Kernel Mode and User Mode" in Chapter 5, "Windows NT 4.0 Workstation Architecture."

Windows 95 locates most of its operating system components in kernel mode, but its system services DLLs (GDI, GDI32, KERNEL, KERNEL32, USER, USER32) run in user mode for the purposes of enhanced performance as well as for backward compatibility with MS-DOS and Windows 3.x applications and device driver software, etc. An ill-behaved application can gain access to and write to operating system memory and crash the system. For more information about Windows 95 architecture, see Windows 95 Resource Kit.

Running Win16 and DOS Applications

Both Windows 95 and Windows NT run Win16 and DOS applications along with the Win32 applications developed to run on Win32 operating systems. The two systems handle Win16 applications differently, and generally Windows NT is the recommended operating system for computers that run both types of applications.

Windows 95 uses cooperative multitasking with Win16 applications. Cooperative multitasking allows an application to voluntarily pass CPU access to another application when the message input queue is empty. Because of this, a Win16 application that fails to check the queue can halt the system for all Win16 applications. Win32 applications that are running should not be affected because the Win16 apps are preemptively multitasked with respect to other processes.

Windows 95 runs Win16 applications as a single multithreaded process in a shared address space. Windows 95 system services DLLs (GDI, GDI32, KERNEL, KERNEL32, USER, USER32) are mapped into the address space of each process. These components, as mentioned earlier, run in user mode. This makes the operating system vulnerable to applications which might write to memory belonging to the operating system.

The system services DLLs in Windows 95 each have a Win32 and a Win16 component. The system is designed to use Win32 code wherever it improves performance without sacrificing application compatibility and uses Win16 code where Win32 code would increase memory requirements without improving performance. Consequently, in Windows 95 both Win16 and Win32 applications require some thunking (translation) between 16-bit and 32-bit threads.

Additionally, the Win16 code in Windows 95 is nonreentrant, whereas Win32 code is reentrant. Reentrant code can be interrupted and resume unharmed, and it can be shared by different threads executing different lines of the same code. The nonreentrant code in Windows 95 would be vulnerable to Win32 threads, except for a flag (called Win16Mutex) that prevent threads from accessing code another thread is using to execute. Consequently, performance of even Win32 applications is slower when Win16 applications are running.

Windows NT can run each Win16 and MS-DOS application in its own private address space within a Win32 application called a Virtual DOS Machine (VDM), thus protecting it from other Win16 programs. This allows Windows NT to preemptively multitask all operating system services and all applications. For a more detailed description of preemptive multitasking and scheduling, see Chapter 5, "Windows NT Workstation Architecture."

DOS applications run well on both systems, running in separate VDMs, but in Windows 95—because some memory is available to all virtual machines—DOS applications can crash the system. In Windows NT, no operating system memory is available to processes outside of kernel mode.

For details about how Windows NT handles Win16 and MS-DOS applications, see "Implementation of the Subsystem" earlier in this chapter. For details about how Windows 95 handles Win16 applications, see the Windows 95 Resource Kit.

Security

Windows NT Workstation was designed with built-in security features. For example, the secure logon screen, invoked by pressing CTRL+ALT+DEL, prevents Trojan Horse programs from simulating an operating system's logon screen and capturing user names and passwords.

Windows 95 was also designed with built-in security, but its security is less restrictive. For example, Windows 95 lets you log in to the local computer without a user account. (To log into a Windows NT computer you must enter a user name and password that already exists on the machine.)

The Windows NT file system, NTFS, provides a range of file protections, which can be set on a per-file or per-directory basis, and user permissions that can be set on a per-user or per-group basis. In addition, NTFS enables an administrator to protect portions of the registry from intentional or inadvertent changes to system settings.

Windows 95 supports share-level and user-level security for peer resource sharing which are measurably less restrictive than the file-level user permissions in Windows NT. Share-level security requires that anyone wanting access to the share must supply the correct password. With user-level security, a request to access a shared resource is passed through a security provider (either a Windows NT Server or NetWare server, utilizing system policies) which grants or denies the request.

The two systems have a notable difference in user permissions:

On Windows 95, if a user belongs to a group that has access to a resosurce, the user has access to the resource, even if the user belongs to another group that does not have access.
On Windows NT 4.0, if a user belongs to a group that does not have access to a resource, the user does not have access, even if the user belongs to another group that does have access.

For most effective security, critical resources should always be shared from Windows NT computers.

Each user's Recycle bin on a Windows NT Workstation computer is secure, provided the bin is on an NTFS drive or partition. Windows 95 doesn't support NTFS.

For more information about security in Windows NT see Chapter 6, "Windows NT Workstation Security." For more information about security in Windows 95, see the Windows 95 Resource Kit.

Remote Administration

Windows NT provides powerful tools for remotely managing a mixed environment network. For a detailed description, see "Remote Administration" in Chapter 4, "Planning for a Mixed Environment."

Feature Comparison

Because of the difference in their missions, Windows NT and Windows 95 support different types of additional features. An organization that includes both operating systems gains the best that computing has to offer. The following sections compares these features.

DCOM support

COM (Component Object Model) is the basis of OLE. COM is the standard by which software components can make use of or be used by one another, integrating features among disparate applications. For example, a user can include an illustration created with one application in a document created with another application. By linking the illustration in the document to the illustration's source file, the document's illustration is updated as its source file is edited and the link between the two is updated.

Distributed Component Object Model is network OLE—that is, COM with a longer "wire." DCOM is a new technology built into Windows NT 4.0 Workstation that enables software components to work with each other across a network or across the Internet. It is a fast transport for distributed applications built with COM. Existing COM applications can use DCOM. They will require only minor modification to a system's configuration, but none to the application code itself. The programming model is identical to ActiveX technologies, so integration is seamless.

With DCOM, indirect connection (a client connecting to a server to connect to another server) is eliminated. After the pointer is established at the target server, DCOM allows the pointer to be given to the client enabling direct client/server communication.

DCOM eliminates the need for objects to implement the communication protocols for accessing remote objects. DCOM centrally handles the communication for all objects.

Windows 95 plans DCOM support in the near future but currently runs DCOM applications as COM applications.

Plug and Play

Windows 95 supports Plug and Play, and Windows 95 applications must be aware of on-the-fly configuration changes.

Windows NT does support static configuration changes, but it is not aware of on-the-fly configuration changes for this release.

File Compression

NTFS provides file compression as part of the user interface, whereas Windows 95 relies on a separate utility for compression. By right-clicking on a file within an NTFS partition and then clicking Properties, the user can select the Compressed check box on the General tab to reduce the size of the file by about 50 percent.

Multimedia APIs

Windows NT supports a series of direct application programming interfaces (APIs) to promote Windows as a platform for game developers and for multimedia-based training. These DirectX APIs—DirectDraw, DirectPlay, and DirectSound—give developers a standard set of services that make game development quicker and easier.

DirectX was introduced with Windows 95. The functions are implemented differently in Windows NT 4.0 than in Windows 95 due to the inaccessibility of the hardware on a Windows NT computer.

DirectDraw for Windows NT supports a 32-bit API for accelerated drawing. It allows an application to manipulate video memory easily and take advantage of the capabilities of different types of video hardware without becoming device-dependent. It enables digital video playback to take advantage of several types of hardware support that are included in advanced graphics adapters.

The Windows NT 4.0 implementation of DirectDraw does not communicate directly with the hardware. (This is in contrast to Windows 95 DirectDraw). All functions are mediated by GDI. DirectDraw can emulate functions by reducing them into simpler tasks, much as GDI does for its clients.

DirectSound utilizes accelerated sound hardware features without requiring the application to query the hardware or program specifically. DirectSound takes advantage of on-card memory, sound mixing (for example, the sound of the crowd mixed with the sound of the announcer mixed with the crack of the bat in a baseball-game application), hardware mixing, and hardware sound-buffer memory.

The DirectSound API provides direct control of audio hardware and is designed to enable 3-D audio support in games. Direct sound runs in emulation mode for Windows NT 4.0 Workstation. API calls are converted to the existing APIs at runtime.

Platform support

Windows 95 is designed for Intel ISA. It runs on x86, Pentium, and Pentium Pro computers. Windows NT supports Intel ISA, Alpha, R4X00, and PowerPC. Windows NT also supports multiprocessor environments with symmetric multiprocessing. Windows 95 supports single processor only.