Application Compatibility

To avoid UAC prompts for applications on launch, there exists a manifest file which contains key information on the privileges. Many times, these manifest files are present along with the executable in the same directory. For example: Altair.exe will have a manifest file called Altair.exe.manifest in the same directory. There can also be cases where the manifest is embedded in the exe itself. In this case, identifying the launch condition for this exe involves a lot of research.

Just a quick heads-up in case this affects anyone else besides me.

I have a scripted deployment for Windows 2000 servers. It operates doing a PXE boot in DOS mode, copies the install files from the depot and runs the install.

All worked well, until I moved the depot to a 64-bit Windows machine. It turns out, the DOS mode network client doesn't seem to play nicely with 64 bit Windows.

The internal version number for Windows Vista is 6.0. The GetVersion function returns this version number. The problem is, some applications will return a higher version number. This means trouble. Learn how to steer clear, here.

A shim, in the software world, is a thin piece of code we wedge between Windows and an application to solve compatibility problems. The following are some specific examples of Microsoft's ACT (Application Compatibility Toolkit) Shims and where they come in handy.

In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, all services run in the same session as the first user who logs on to the console. This session is called Session 0. Running services and user applications together in Session 0 poses a security risk because services run at elevated privilege and therefore are targets for malicious agents who are looking for a means to elevate their own privilege level.

As an initiative to increase system stability, predictability and reliability, Windows Resource Protection (WRP) is designed to protect a Windows system in a read-only state. This will affect specific files, folders, and registry keys. Updates to protected resources are restricted to the OS trusted installers, such as Windows Servicing. This enables components and applications that ship with the OS to be better protected from the impact of other applications and administrators.