Geek School: Learning Windows 7 - Managing Applications
Compatibility Issues with Older Games on Windows 7
Have you encountered difficulties running classic games designed for older operating systems, such as Windows 95, on your Windows 7 system while other programs function normally? The reason for this behavior is a common one, and we will provide both an explanation and potential remedies.
Understanding why these compatibility problems arise is key to resolving them. Older software often relies on system components and functionalities that have been altered or removed in newer versions of Windows.
Previous Articles in the Geek School Series
For those seeking a more comprehensive understanding of Windows 7, we recommend reviewing earlier installments of this Geek School series:
- Introducing How-To Geek School: An overview of the series' objectives.
- Upgrades and Migrations: Guidance on upgrading to and migrating data to Windows 7.
- Configuring Devices: Instructions for setting up and managing hardware devices.
- Managing Disks: Information on disk partitioning and management within Windows 7.
These articles provide a foundational knowledge base for effectively utilizing Windows 7's features.
Further articles are planned for release in the coming weeks, offering in-depth coverage of various Windows 7 topics. We will continue to expand on these concepts and provide practical solutions.
Understanding Application Incompatibility
A frequent cause of applications ceasing to function correctly stems from a Windows functionality known as Windows File Protection. This feature was initially introduced with the release of Windows Vista.
As its name suggests, Windows File Protection is designed to safeguard essential system files from unauthorized replacement.
This protection is achieved by altering the security Access Control List (ACL) associated with the file. Only the TrustedInstaller user is granted complete access, ensuring that only authorized processes, such as Windows Updates, can modify these critical files.
In Windows 7, this feature underwent a renaming process and became known as Windows Resource Protection, but its core function remained consistent.
The Role of Security and Directory Changes
Improvements to system security also contribute significantly to application incompatibility issues. A prime example is User Account Control (UAC), which was not present in earlier versions of Windows prior to Vista.
Furthermore, alterations to the directory structure, particularly within User Profiles, introduced in Windows Vista, caused disruptions for many applications originally developed for older Windows environments.
To mitigate these problems, the implementation of symbolic links – sometimes referred to as Junction Points in older Windows versions – was undertaken. These links redirect requests from the original file locations to their new counterparts.
Ensuring Application Compatibility
It's not uncommon for an application to exhibit incompatibility with a specific operating system. However, this doesn't automatically preclude its execution. Initially, determining whether an application is incompatible with Windows 7 is crucial. This can be achieved by accessing the Control Panel and navigating to the Programs section.
Within this section, locate and click the hyperlink labeled "Run programs made for previous versions of Windows."
Subsequently, expand the advanced settings and deselect the option for automatic error correction. Then, proceed by clicking "Next."
Click the "Browse" button to locate the executable file you are attempting to run, and then click "Next."
Upon completion of the scan, review the detailed information provided.
The results will highlight any identified issues. While the messages may not always be entirely informative, they confirm potential difficulties in running the application.
Leveraging Compatibility Mode
If an application was originally designed for an older Windows version, utilizing compatibility mode can often replicate the necessary environment. To access this feature, right-click the program's executable and select "Properties" from the resulting context menu.
Then, navigate to the "Compatibility" tab.
Within this tab, you can specify the desired operating system environment by checking the appropriate box and selecting the target OS from the dropdown menu.
Exploring the Application Compatibility Toolkit
A comprehensive exploration of the Application Compatibility Toolkit is beyond the scope of this discussion. However, one particularly useful tool warrants attention: the Internet Explorer Compatibility Test Tool. This tool allows you to assess the compatibility of your local intranet sites with upcoming releases of Internet Explorer. Begin by launching the tool.
Next, click the "Enable" button.
Upon opening Internet Explorer, a small clipboard icon will appear in the status bar. Clicking this icon will display a message indicating that the browser is currently evaluating compatibility. Simply continue browsing your webpages as usual. Once finished, close Internet Explorer.
The tool's findings regarding compatibility issues with the browsed webpages will then be displayed. You can save this report and forward it to the relevant developers.
Restricting Application Execution
Having addressed the management of applications we permit to run, let's now turn our attention to controlling those we wish to prevent. A technique for limiting software execution within our systems involves employing a software restriction policy (SRP). Typically implemented through Active Directory and Group Policy, we will demonstrate its configuration on a standalone machine.
It’s important to note that software restriction policies are machine-specific, not user-specific. To initiate policy creation, open the Group Policy Management Editor and navigate to the following path:
Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies
The initial step involves creating a new policy. This is accomplished by right-clicking within the console and selecting "New Software Restriction Policies."
Next, proceed to the Security Levels section. Here, three distinct security levels are available.
- Disallowed – By default, no software is permitted to run; only explicitly allowed programs will execute.
- Basic User – Software not requiring administrative privileges is allowed to run.
- Unrestricted – All software runs, with the exception of programs explicitly denied.
To designate Unrestricted as the default, right-click on it and select the appropriate option.
Now, transition to the Rules section to add a new restriction rule. Four rule types are available for implementation.
- Hash – Verifies executables against a list of prohibited hash values.
- Certificate – Leverages digital certificates to prevent application execution.
- Path - Blocks applications based on their complete file path.
- Zone – Utilizes alternate data streams to determine the file's origin and block it accordingly.
For this demonstration, a hash rule will suffice.
Click the Browse button and select the following file:
C:\Windows\System32\mspaint.exe
After applying the rule, attempt to launch Paint to observe the restriction in action.
Preventing Automatic Application Startup
A common tactic employed by malicious software developers is to configure code for automatic execution upon system startup. A readily available tool for managing startup items is MSConfig. Launch it by pressing the Windows + R keys to open the Run dialog, then type "msconfig" and press Enter.
Upon opening MSConfig, switch to the Startup tab. Here, you can easily disable programs that launch automatically by simply unchecking their corresponding boxes.
However, developers have devised methods to conceal items from MSConfig, causing them to appear only within the registry. Two registry locations allow the addition of startup items:
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Entries within the HKEY_LOCAL_MACHINE hive execute for all users on the system, while those in HKEY_CURRENT_USER execute only for the current user.
Homework
A common inquiry arises regarding the incompatibility of 16-bit applications with the 64-bit editions of Windows 7. This stems from fundamental architectural differences between the two systems.
The x64 versions of Windows 7 do not provide the necessary Windows on Windows (WOW64) subsystem components required to emulate a 16-bit environment. Consequently, applications designed for older 16-bit architectures cannot function correctly.
Understanding the Issue
Historically, 16-bit applications were prevalent in earlier versions of Windows. However, modern 64-bit operating systems prioritize performance and security, leading to the removal of 16-bit support.
Attempting to run a 16-bit application on an x64 system typically results in an error message indicating the program is not compatible with the current version of Windows.
Users encountering this issue should consider alternative solutions, such as virtualization or upgrading to a 64-bit equivalent of the application, if available.
Don't miss our upcoming Geek School installment on Monday. We will then explore the administration of Internet Explorer settings.
Should you have any questions, feel free to reach out to me on Twitter @taybgibb, or simply post a comment below.
Related Posts
Touchscreen on Windows PC: Do You Need It?
Find Lost Windows or Office Product Keys - Easy Guide
Windows 10 Setup: Express vs. Custom - What's the Difference?
Manage Accessibility Features in Windows 10 - A Comprehensive Guide
Windows 10 Start Menu: A Comprehensive Guide
