Home > Articles


  • Print
  • + Share This

3.3. Running applications

Supporting Windows 95 does not only mean supporting the operating system itself; it also means supporting applications that will be used with Windows 95. Even though we can't even begin to talk about every application that will run in a Windows 95 environment, we can talk about how to support applications in a general sense. In doing so, we can break it down to three types of applications:

  • MS-DOS applications

  • Windows 16-bit (Win16) applications

  • Windows 32-bit (Win32) applications

3.3.1. Virtual machines

The Windows 95 architecture is implemented through the use of virtual machines. A virtual machine (VM) is a way that Windows 95 can trick the application that is running on a computer with full access to all of that computer's resources. If you have two applications running and they are in separate VMs, they think they have an entire computer all to themselves.


A virtual machine is the simulation of an entire computer's resources that is accomplished by an operating system.

There are two basic types of VMs. The first type is called a system virtual machine (system VM). In Windows 95 contains one, and only one, System VM. All the base components of Windows 95 run inside the system VM, including the interface, GDI, and kernel. Also, all Win16 applications and Win32 applications run in this system VM.

However, all Win16 applications share the same memory address space. The main reason for this is backward compatibility. Some Win16 applications transfer information to each other by the way of this shared address space. Because they share memory with each other, they all have access to each other's information.

Win32 applications are independent from one another because each Win32 application runs in its own separate memory address space. Take a look at Figure 3.7. This does not mean that Win32 applications cannot share information. Instead, they use the more advanced object linking and embedding (OLE) capability to share information.

Figure 3.7. The system virtual machine.

The other type of VM is an MS-DOS VM. Each MS-DOS application runs in its own separate MS-DOS VM (see Figure 3.8). The reason behind this should be clear already. Think about it: before there was Windows, all we had was MS-DOS. Back in those days, we couldn't run two MS-DOS applications at once. This mainly was because MS-DOS applications were written with the idea that they would have the full control over the computer's resources. If you remember back to my definition of a VM, you'd see that the way we give an MS-DOS application the full control that it wants is to run it in its own VM.

Figure 3.8. The MS-DOS virtual machine.


You will almost definitely be asked to identify the number of virtual machines in a given scenario on the exam. For example, if you were running three 16-bit applications, two 32-bit applications, and three MS-DOS applications; how many virtual machines are in use? The correct answer would be four virtual machines: one system virtual machine for the Windows applications and one for each MS-DOS application.

3.3.2. Processes and threads

Understanding applications means understanding how the actual processing happens. In understanding how the process happens, think for a minute about what a process is. Think of a process as a project that an application wants to accomplish. In order to complete a project, you can break the project down into smaller tasks, the faster you can accomplish those smaller tasks, the faster the project is completed. If a process were a project, we would call those smaller tasks threads.

So simply, a process comprises at least one thread, and a thread is a unit of code to be executed. As long as you understand that basic terminology, understanding the different applications is a breeze.

Let's talk about how Windows 95 uses these processes and threads. Windows 95 has a way that it controls these processes and threads through what is defined as a message passing model. A message could consist of some function such as an interrupt (click of a mouse) or information to be transferred. These messages are used to send information from the application to the rest of the system, whether it is from one program to another, to the processor, or to the screen.

These messages are passed through one of several message queues. These message queues are similar to a print queue. If you print something out, you have to wait until earlier print jobs are done before you see your latest printout. Likewise, messages in the same message queue have to wait to be processed until earlier messages are processed.

The number of message queues that you have is directly proportionate to how many and what types of applications you have running.

MS-DOS applications do not use a message queue because they are not designed for message passing.

Because all Win16 applications share a common address space, they all share the same message queue. All threads of code to be executed from these applications have to go through one message queue. Therefore, if one Win16 application becomes hung up for some reason, it clogs the message queue and prevents any other Win16 applications from responding. Once the hung up application has been terminated, the message queue resumes with the next message in line. In Figure 3.9, you see two Win16 applications running. See how they all share the same message queue?

Win32 applications are a different breed all together. Not only does each application run in its own separate memory address space, but every thread of code gets its own message queue. Also in Figure 3.9 you will see two Win32 applications running. These applications can send multiple threads simultaneously, each thread having its own message queue.

Figure 3.9. TheWindows 95 message queue.

3.3.3. Windows 95 internal

Windows 95 consists of many components, but the three main components are the User, Kernel, and graphical device interface (GDI). Each of theses core components consists up of two DLLs, on which is 16-bit and the other is 32-bit. This means that Windows 95 has 16-bit code as a main part of the operating system.

The reason for this was to ensure backward compatibility and better performance. It keeps the older 16-bit code where needed for backward compatibility, but has newer 32-bit code for increased performance.

The kernel, which handles most virtual memory functions, I/O services, and task scheduling is predominately 32-bit to ensure the main core of Windows 95 is fast and reliable.

The GDI takes care of anything that is placed on the screen. Because graphics are nothing more than complex calculations, most of them became 32-bit in Windows 95, but some portions of the code that are smaller functions, such as window management, remained 16-bit for compatibility with older applications.

The User portion manages keyboard, mouse, and other input or output devices. Most aspects of the User portion is still in 16-bit code.

Because you have both 16-bit and 32-bit portions of code that compose the Windows 95 operating system, how do these devices communicate with each other? The kernel provides a service called thunking to translate between 16-bit and 32-bit code.

3.3.4. 32-bit versus 16-bit applications

So far, we've talked about Win32 and Win16 applications in how they use the message queues, memory address spaces, and such. Let's contrast the two by talking about the difference between preemptive and cooperative multitasking. Multitasking is defined as being able to accomplish more than one task at a time. In Windows, it means that we can run more than one application at a time, but there are two ways of multitasking: preemptive and cooperative.


In a multitasking environment, threads are assigned a priority. They are then executed in the order of the priority that they hold. With preemptive multitasking, each thread is run for a preset amount of time, or until another thread with a higher priority comes along. This prevents one thread from taking control of the processor and keeping it all to itself.

Because Win32 applications run in their own separate memory address space and MS-DOS applications run in their own separate MS-DOS VM, they are preemptively multitasked in Windows 95.


With cooperative multitasking, a thread can control the processor until the processor is done with it. The program that is sending the thread controls how long the thread has control of the processor and when it should relinquish it. Therefore, a Win16 application that is not well written can attempt to take total control of the system.

Win16-based applications are the only applications that are cooperatively multitasked in Windows 95.


Win32 applications are multithreaded. A single Win32 application can send multiple threads, simultaneously to the processor to be processed. When you couple that with the idea that each Win32 thread has its own message queue, you can see how these applications can do more, faster. Therefore, Win32 applications can be preemptively multitasked. They can all send out multiple threads at the same time to be processed.

Unlike Win32 applications, Win16 applications can kick out only one thread at a time. Also keep in mind that all Win16 applications running in Windows 95 share the same message queue; therefore, they have to wait on one another. This is why Win16 applications are cooperatively multitasked. They must cooperate with each other when sending out threads from the message queue.

Figure 3.10 can give you an overview of how the whole process works.

Figure 3.10. Multiprocessing in Windows 95.

3.3.5. Running MS-DOS applications

All Windows-based applications have information stored in the executable file of the program that tells Windows what resources it needs, how much memory it needs, and other attributes about the program.

MS-DOS applications do not have this type of information, however. You can modify the behavior of MS-DOS applications by pulling up the property sheet for that application. In order to obtain the property sheet of an application, right-click on the EXE file in the Windows Explorer and select Properties.

The property sheet will consist of several tabs that I will explain. Once you've modified the information in the property sheet, a program information file (PIF) is created automatically. By default, the file created uses the same name of the executable file and has PIF for the extension. Any time you execute that application, the information stored in the PIF will be set for that application.


The PIF must reside in the same directory as the executable (EXE) file. You can create more than one PIF for the same program and therefore different settings. Simply copy the PIF and rename it. When you want to execute the program, simply double-click on the PIF, not the EXE. If you use a shortcut to execute the program, make sure the shortcut points to the PIF and not the EXE.

Figure 3.11 shows the first tab, the General tab, of the property sheet for a MS-DOS application. As you can see, this tab is common to all files in Windows 95 and contains pretty basic information.

Figure 3.11. The MS-DOS Properties Sheet, General tab.

The Program tab contains information such as the Command Line, the Working Directory, and Shortcut Keys if applicable (see Figure 3.12). Also on this tab, you can specify that a certain batch file run prior to the execution of the application. At the bottom, you see two buttons, one titled Advanced and the other Change Icon. I think that Change Icon is self-explanatory, but I will cover the Advanced button toward the end of this section.

The Font tab is the next tab in line. In Figure 3.13, you see that you can change the size and style of font used in the program. Need I really say anything more?

The Memory property sheet lets you tightly control the memory on an application. I've come across several instances where someone was trying to run an MS-DOS application and was having difficulty. The user simply assumed that the application wouldn't run in Windows 95 and gave up. With a little tweaking here, you can run many applications that you may have thought wouldn't. Keep in mind that these settings are only for that specific application and not for the entire machine. This basically sets up the memory configuration for the MS-DOS VM. Figure 3.14 shows a picture of this tab.

Figure 3.12. The MS-DOS Properties Sheet, Program tab.

Figure 3.13. The MS-DOS Properties Sheet, Font tab.

The Conventional memory setting specifies how much conventional memory is required for this application to run. I have yet to come across an instance where Auto hasn't worked.

Figure 3.14. The MS-DOS Properties Sheet, Memory tab.

The Initial Environment setting specifies how much memory you would like to set aside for COMMAND.COM or settings in batch files such as SET variables. SET variables are things like the PATH statement, TEMP folder, and the like.

You should check the Protected check box if you do not wish the information stored in memory for this application to be paged to the hard disk. Be prepared for a performance drop if you select this option.

The Expanded (EMS) memory setting is where we did some tweaking. This setting specifies how much expanded memory you want to limit this application to. If you set it at Auto, the sky's the limit. Some applications have difficulty when they can't see the limit. If so, set this to 8MB (8,192K).

The Extended (XMS) memory setting is like the expanded memory setting. This is where you set a limit as to how much extended memory you are going to allow this application to have. Auto is the setting where there is no limit. If you have to tweak the expanded memory setting, there's a pretty good chance you'll have to tweak this one. Once again, set it to 8,192K if the application doesn't like the Auto setting.

DPMI stands for DOS protected-mode interface. This is also a maximum setting. Unlike the previous settings, Auto does not leave it as no limit. If you leave it on Auto, Windows will specify a setting based on the machine's current configuration.

In Figure 3.15 you'll see the Screen tab. This tab is also relatively basic. The settings at the bottom, Fast ROM emulation and Dynamic memory allocation, usually throw most people off.

Figure 3.15. The MS-DOS Properties Sheet, Screen tab.

The Fast ROM emulation is checked by default. When checked, it allows the program to use the ROM drivers in protected mode. This can increase video performance by speeding up the rate in which the program can write information to the screen. If your program has difficulty writing to the screen, try removing the check mark in this box.

As for Dynamic memory allocation, with the check mark on (default), it allows the program to control the amount of memory set aside for displaying graphics. Make sure this check mark is on if the program frequently switches between graphics and text. Remove the check mark if you are running Windows on a machine with very little RAM. This will allow Windows to manage the memory and allocate to the program as Windows sees appropriate.

The Misc tab (see Figure 3.16), contains all the misfit settings not appropriate for other tabs. Once again some settings here are self-explanatory.

Idle sensitivity is how long you want Windows 95 to wait before it suspends (pauses) the application for inactivity. If you have an application that appears to be idle but isn't, Windows will suspend it. This causes some MS-DOS applications to crash. If so, set this to its lowest level.

The Quick Edit mouse setting allows for cutting and pasting inside an MS-DOS program when the program is running in a window. Deselect this option if the MS-DOS application uses a mouse.

Figure 3.16. The MS-DOS Properties Sheet, Misc tab.

Exclusive mode locks the mouse inside the MS-DOS application window. If your MS-DOS program uses a mouse and you run the application in a window, you'll find this option handy. If the mouse cursor loses synchronization when you move it in and out of the application window, select this option. It can be a little frustrating at first.

The Windows shortcut keys area at the bottom of this window specifies which Windows 95 shortcut keys are enabled in this program. If your MS-DOS application uses any of these shortcut keys, deselect them here so that the keystroke stays within the program instead of going to Windows 95.

Using MS-DOS mode

Let's go back to the Program tab. Clicking on the Advanced button on the bottom pulls up a dialog box similar to Figure 3.17.

Some MS-DOS programs are written to detect whether they are running in a Windows environment. These programs react differently depending on whether they are running in Windows or in an MS-DOS environment. If you would like to hide the Windows environment from the MS-DOS program, place a check mark in the first setting.

The next setting, if checked, will allow Windows to determine whether you should use MS-DOS mode for this particular application. This setting is checked by default. (These figures are greyed out in the figure because I have selected to run in MS-DOS mode.)

Figure 3.17.

The Advanced Program Settings dialog box.

If your program will absolutely not run in Windows 95, you can choose to run it in MS-DOS mode. Most examples that I can come up with are games. I do have a couple of games (yes I believe in having fun, too) that require MS-DOS mode. Not sure what MS-DOS mode is? Allow me to explain.

Say you specify that you would like for a particular program to run in MS-DOS mode. When you execute that program, Windows 95 shuts down and the computer restarts in MS-DOS mode (Windows 95 is not loaded). The program then executes automatically. When you exit the program, the machine restarts in Windows 95.

Once you have specified that your machine starts in MS-DOS mode, you have two choices of how to configure the machine for that application. Looking once again at Figure 3.17, you see that I have already specified that this program run in MS-DOS mode. The two choices that you have are these: Use current MS-DOS configuration and Specify a new MS-DOS configuration.

If you choose the Use current MS-DOS configuration , the default settings of the computer will be used. If you choose the Specify a new MS-DOS configuration, you can specify any CONFIG.SYS and AUTOEXEC.BAT settings in the provided boxes. With this option you can specify specific settings on a program by program basis. You can even take it a step further and create several PIFs for one application and specify different settings in each PIF.

I have actually put MS-DOS mode to use in a dual-boot configuration with Windows 3.11. The customers needed to use both Windows 3.11 and Windows 95 environments.

Windows 95 was their predominate environment, but they wanted a quick and easy way to drop completely out of Windows 95 and into Windows 3.11.

With the machine installed with Windows 3.11 and Windows 95 in separate directories (so changing one wouldn't in any way affect the other), we created a shortcut on the desktop. The shortcut's command line pointed to the WIN.COM of Windows 3.11. We configured it to start in MS-DOS mode with specific CONFIG.SYS and AUTOEXEC.BAT settings.

When they wanted to drop down to Windows 3.11, they simply double-clicked the shortcut icon. The machine reboots and starts in Windows 3.11. After they're done with Windows 3.11, they simply exit Windows. The machine reboots again and starts back up into Windows 95.

By default, a check mark is placed in the Warn before entering MS-DOS mode setting. This option, upon executing the program, will display the message in Figure 3.18.

Figure 3.18. The MS-DOS Mode warning.

3.3.6. When an application goes bad

When the term crashed application is used, it usually means different things to different people. For those of us who are familiar with Windows 3.x, it usually means the appearance of the infamous general protection fault error message. For others, it may mean the application no longer responds to keystrokes or mouse clicks. Well, in actuality, both are correct.

General Protection Faults

A general protection fault (GP fault) is not a thing of the past with the creation of Windows 95, but you will see fewer of them. A GP fault basically occurs when a program attempts to violate system integrity. This is classified as an application failure. The way Windows 95 handles applications that attempt to violate system integrity depends on what type of application it is.

If an MS-DOS application fails, a GP fault error appears. Clicking OK will terminate the program. The program that fails is the only program affected by the failure because MS-DOS applications run in their own separate VM.

When a Win16 application fails, a GP fault error message appears stating which application has failed. Until this application is terminated, all other Win16 applications stop responding. If you remember from 3.3.3, Win16 applications are cooperatively multitasked. Once the failed application terminates, all other Win16 applications resume.

Win32 applications are a little different. Because they each run in their own separate memory address space (3.3.3), they don't affect other applications when they fail. A GP fault error message is displayed notifying you what program failed.

Hanging an application

No, I am not talking about getting the noose out for those notorious applications. I'm talking about when an application stops responding to the system. Most people think that because the application that they have in the foreground has hung up, Windows 95 is hung up as well: this is a fallacy. Usually this results in the user pressing Ctrl-Alt-Del being about 30 times at an alarmingly fast rate or just as badly reaching for the infamous power button. These actions are not warranted because there is an easier (and safer) way.

Pressing Ctrl-Alt-Del once (and only once) will perform a local restart. Despite what the name might imply, the computer does not restart In fact, it pulls up the Close Program dialog box. This box will inform you which program has hung up by placing the words Not Responding next to it. To terminate the program, simply click on it, and click the End Task button.

Program Resources

When you terminate an Winapplication, what happens to the resources? Well, that depends on whether the application is an MS-DOS–based, 16-bit Windows, or a 32-bit Windows application.

When you terminate an MS-DOS-based application, its virtual machine is also terminated. This returns all resources to the system.

If the application is a 16-bit Windows application, things are a little more complicated. The 16-bit Windows applications may use resources without Windows 95 being aware of them. Additionally, they may also use resources that other 16-bit Windows applications are using because all 16-bit applications share the same memory address space. Therefore, when you terminate a 16-bit Windows application, the resources that it was using are not returned to the system until all 16-bit applications are no longer running. Once the last 16-bit application is closed, all resources are returned to the system.

With 32-bit Windows applications, things are tracked more closely. When a 32-bit Windows application is terminated, its resources are returned to the system.

In Windows 3.x, 16-bit applications many times crashed the computer because Windows 3.x was 16-bit. Windows NT has a capability to run 16-bit applications in their own separate memory address space so that they do not affect other applications or resources.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020