Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Windows 2000 and 16-Bit Applications

DZone's Guide to

Windows 2000 and 16-Bit Applications

It’s been a long time since 16-bit applications were commonplace. Nevertheless, there may still be instances in which you want to run a 16-bit application on a 32-bit OS.

· Integration Zone
Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

It’s been a long time since 16-bit applications were commonplace. Nevertheless, even in the 21st century, there may still be instances where you want to run an old 16-bit application on a 32-bit OS such as Windows 2000.

When trying to run 16-bit applications on Win2000, it’s important to know that not every such application will run correctly, as Win2000 does not provide a native 16-bit environment. Rather, they run in an environment that attempts to emulate the original 16-bit OS. Because Win2000 changed the rules regarding how applications can function in order to improve overall system reliability, programs that try to communicate directly with hardware (a common practice of the era) or use virtual drivers (which have a .VXD extension) won’t work with Win2000 at all. Games and many utilities are good examples of programs that will probably be incompatible with Win2000 (or later versions, for that matter).

Let’s look at how Win2000 accommodates 16-bit applications. To run 16-bit software, Win2000 relies on two built-in software components, one of which is the NTVDM (NT Virtual DOS Machine).

The NTVDM is a 32-bit Windows application that emulates an Intel 486 PC running MS-DOS (version 5.0, as it happens), and it’s the underpinning of any 16-bit DOS or Windows application. When you run a DOS application in Win2000, the NTVDM starts and provides a complete emulated environment for the application to run in. The NTVDM itself is treated like any other 32-bit Windows application, and it’s preemptively multitasked, which means the OS ensures each application gets its fair share of the processor’s attention. This is in contrast to cooperative multitasking, which relies on each individual application to yield the CPU after its allocated time has elapsed.

When you run multiple DOS applications in Win2000, each one runs in its own NTVDM with its own dedicated operating environment and memory space. (Incidentally, this is the same way DOS applications run in 16-bit versions of Windows.) Because each DOS application is thus segregated from other DOS applications and the OS, a problem with an individual application can’t cause other programs or the OS to fail.

The number of NTVDMs that can run simultaneously is limited only by the amount of RAM you have installed, and though the maximum amount of memory that DOS can address is only 1MB, each NTVDM may consume more or less than that.

Windows on Windows

When dealing with 16-bit Windows applications, things are a little different. When you launch a 16-bit Windows application, Win2000 still uses the NTVDM as its foundation. Next, another component referred to as WOW (Windows on Windows) is loaded, which adds additional layers that emulate Windows 3.1 and allow 16-bit applications to function. As with a DOS application, the 16-bit Windows application’s operating environment, consisting of the NTVDM, WOW, and the application, is run as a 32-bit application and preemptively multitasked alongside other programs running on the system.

Whereas multiple 16-bit DOS applications are always isolated from each other by Win2000, things are a little different if you run two or more 16-bit Windows applications. By default, these applications will run within the same NTVDM and WOW environment. Therefore, all the 16-bit applications running in the environment are cooperatively multitasked, and access to the CPU is managed by the applications themselves rather than the operating system. This is identical to the way 16-bit applications are multitasked when run natively on 16-bit versions of Windows.

The downside to cooperative multitasking is that should one application have a problem, it will very likely undermine all other running applications. This is why a problem with an application in 16-bit Windows OSes often caused other programs, if not the entire system, to crash. (Because Win2000 isolates the 16-bit environment, failure of a 16-bit application can’t destabilize the overall system, but it can cause other 16-bit apps running with it to fail.)

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

Topics:
integration ,windows 2000 ,applications

Published at DZone with permission of Hamid Rayane. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}