By and large, Windows tries to remain as backwards-compatible as possible from version to version, but every now and then a set of changes comes along with the power to really disrupt things, e.g., the removal of all 16-bit app compatibility in Windows.
Both the client and server editions of Windows 8 have a few changes that can make current application compatibility a challenge. And not all of these challenges can be properly confronted by admins; some of them will need to be dealt with by the original application authors.
Most of the changes are explained in a newly updated document called the “Windows and Windows Server Developer Preview Compatibility Cookbook,” which examines all major app-compatibility obstacles for the current edition of Windows provides some solutions and workarounds.
Here’s a rundown of some of the most crucial application-compatibility issues to be aware of.
System version numbers. Yes, this old bugaboo is back in a slightly different form. Older applications which insist on a specific version of Windows may bomb, as Windows 8 reports itself as version 6.2. Such apps can be installed using Windows’s existing shims for overriding version-number reporting (e.g., the “Compatibility” tab in the app shortcut), but if you’re an app developer you should be that much more cautious about how you check version numbers. Microsoft recommends using the VerifyVersionInfo function in a sensible way (use “greater than,” not “equal to,” a given version number).
Headless server apps. This is one of the more major changes, since newer versions of Windows Server — Server Core, mainly — are designed to run not only headless but without a GUI at all. The GUI can be uninstalled in low-resource environments (for instance, a heavily-shared virtual machine) or to reduce the overall attack surface on the server.
Some server applications, however, may not run in a GUI-less setting. Any command-line version of an application should run fine, but anything that presents a GUI to the end user may not work at all. There is, at this time, no way to “wrap” a GUI application so that it behaves normally without a GUI.
If you’re planning on running any application in a Server Core, you should test it to make sure it behaves as expected without the GUI. If it doesn’t, and you have some power over how the app is written, you’ll need to read up on migrating existing code to Server Core and learn about which portions of the Win32 API and the .NET CLR are supported by Core.
.NET framework. Windows 8 features .NET 4.5 as part of its default installation bundle, butnot .NET 3.5. If you have anything that has been built explicitly to use 3.5 — not just standalone apps, but websites written for that edition of .NET — you’ll need to add that earlier edition of .NET by hand. Fortunately this doesn’t pose any major compatibility problems, since all the different editions of .NET run side by side. The Microsoft document has some notes on how to add .NET Framework 3.5 without triggering an automatic request for it from Windows Update.
Word has it that .NET 4.5 is actually part of the Windows RunTime (WinRT) APIs that allow developers to create applications using the new “Metro” look (less crucial for servers) and uses a sandboxed programming model to quickly create programs for Microsoft’s Windows Store, among other things. If you intend to write or upgrade server apps for Windows 8, and you already know C# or C++, it shouldn’t be hard to get up to speed with WinRT, but that’s something worth exploring in its own article.
4K disk sectors. This may sound more like a hardware issue than an application issue, but it still deserves some mention here. Newer disks aimed at the server market now use 4K sectors instead of the old 512-byte sectoring scheme. 4K sector drives, called “Advanced Format” drives, can do some strange things to applications that expect 512-byte sectors. This despite the fact that many 4K drives come with a backwards-compatibility extension to emulate 512-byte sectors (“512e”). Windows 8 adds a new API for querying file sector sizes to get around this, and also makes changes to the fsutil command-line tool for making volume size queries in scripts.
Unsigned kernel-mode drivers. If you have any applications, whether third-party or crafted in-house, that use kernel-mode drivers, Windows Server has been secured all the more against using kernel-mode drivers as a source of malware. The biggest changes involve kernel-mode drivers for devices that use the unified extensible firmware interface (UEFI) Secured Boot function, which protects the machine against malware that injects itself into the pre-boot environment. UEFI Secure Boot is optional for servers but recommended. If you want to take advantage of UEFI Secure Boot on servers, you’re best off having kernel-mode drivers signed by some trusted certification authority. Otherwise, you’ll have to disable Secure Boot.
Windows Management and Scripting 