MS Server 2008 will be the last Windows OS to support 16-bit applications
Share on Twitter.
Get the most reliable SMTP service for your business. You wished you got it sooner!
June 24, 2015
This is your final migration push for Microsoft's ecosystem 16-bit applications. Windows Server 2008 x86
is the last MS server operating system to support them. You've been warned.
Of course if you really want to push it to the next 'low-cost level, you can simply upgrade
from Server 2003 to Server 2008 and buy yourself a few more years, but just remember that extended
support for MS Server 2008 runs out in 2020. That's less than five years away.
And worse, the migration won't be smooth either. There are a whole bunch of little things
that don't quite work well with 16-bit applications under Server 2008. Printing is one of them, especially
under Remote Desktop Services.
Of course there are some workarounds for pretty much everything, but be prepared to spend a lot of
time trying to find them. It won't be easy.
Just remember that because your application simply appears to be a 32-bit application with a
Win32 GUI and that the front dressing looks like a 32-bit Windows application doesn't mean it is.
Lots of 32-bit applications call 16-bit components, especially in applications that were written
between 1996 and 2000.
If you have any reason to doubt that your seemingly 32-bit application might not be entirely 32-bit,
there is a simple way to check this.
Simply install the application on a clean, unpatched Server 2008 x64. It will either work or it
won't. It will be a fast yes or no, no doubt about that.
For your information, the chances of a true 32-bit application which works on a fully patched Server 2003 R2 SP2 system
not working on a clean, unpatched Server 2008 x64 are slim to none.
You might get a small glitch about dependencies, but that's not the same as it "not working".
You should install the relevant additional applications and then try again.
If your 32-bit application still refuses to work on an x64 copy of Server 2008 then the chances
are that it's calling some piece of 16-bit code somewhere. Start asking the app developers specific
questions and they might guide you on the correct path.
There are some practical steps to be taken in dealing with 16-bit applications. For the most part,
these steps also apply to non 16-bit applications, but for reasons we'll discuss later, you're very
unlikely to need to worry as much about those.
The easiest way to figure out how to handle them is by using virtualization. You can snapshot VMs
after every change, making them rolling back to a previous state a rather easy step.
If you can't use virtualization (for example, your application needs to talk directly to a hardware
controller because it drives some important code) then it's time to invest in some imaging tools.
Symantec Ghost is a good example but there are others as well. If you are migrating 16-bit applications
to a newer version of Windows you may need to start by installing Server 2008 x86. Do not update it.
Simply install your application and port over any relevant data, configurations, etc.
If you can get some help from the developers of the application in identifying how to copy your data
and configurations from one system to another, that would be nice for you. If not, be prepared for a
lot of trial and error. And, what ever you do, make sure to document everything-- we can't stress that
point enough. Lots can go wrong in cases such as these.
Once you have your application up and running on your Server 2008 x86 installation, double check
your documentation to make 100 percent certain you know how to migrate things around.
For now, reformat the server's drive and perform the migration again, this time without all
the trial and error steps noted above.
At this point in time, you should be more comfortable in moving the data and configuration for your
application from one server to another.
You should also have a clean, working installation on a non-updated server as well. Take a snapshot
of this server (if it is in a VM) or a ghost image (if it is on a dedicated server).
Remember that you'll need this known good configuration later. Next, perform all security updates
for Server 2008, but none of the optional updates. Just the security updates themselves.
Then make sure you test your applications thoroughly. If they no longer work then reload the known
good (clean) image and install the security updates in batches.
Install them in blocks of ten, starting at lower numbered KB patches (older) and working your way towards
the newer ones. Then again, test the application thoroughly after each block.
Once you find a block that breaks things, uninstall the last batch of 10 patches and install them
one at a time until you find the one that breaks your application.
Write the KB (security bulletin) down for later use and don't install that patch. Continue patching
in blocks of ten at a time and then test them after each block.
Every time you find a security patch that breaks things, write it down, don't install that patch and
keep going. It sounds like a tedious process but this might fix your issue. You just need some patience
Then, continue on through all the remaining "critical" security patches that are not updates and are not
Internet Explorer. After everything else is said and done, try installing Internet Explorer updates.
Internet Explorer security patches are the most likely to break everything horribly, so if nothing
has gone wrong until now, you aren't out of the woods yet...
If you have made it through all the security patches without things breaking, congratulations! If not,
it's time to sit down with all the KB numbers of your patches and figure out what's broken.
Once you've figure out the workarounds for any security patches that are causing you issues, we strongly
recommend resetting your system to your original "known good" installation.
Rerun your patches carefully, applying whatever hotfixes or workarounds are required in the proper
sequence. This will generate a new known good system where you have not uninstalled any patches
or otherwise done any trial and error.
Then, take a new master image of your system. Make several copies and make sure at least one copy
lives offsite. Also make sure a copy of your documentation for a clear rebuild lives offsite as
well, just in case.
Make sure that other people in your organization know where that offsite location is and have access
to it, if something should happen to you.
The "how to build from ground zero" is especially important if you are installing this on raw hardware as
opposed to VMs. Backup images don't tend to clone well from one set of hardware to another.
If you're still using 16-bit applications to talk to hardware then the chances are that the hardware
you're using is a bit difficult, and replacement parts might not be exactly the same anymore.
Your task may one day rest on your ability to reinstall this all from scratch, and thus on the documentation
you make during this migration can be a real life saver. Good luck with your changes.
Just to be clear, Server 2008 is getting a bit older, even though it still has almost 5 more years to
go. It's your last choice for those 16-bit applications, but if you have to use it, install third party
As always, additional layers of security are extremely important. Anti-malware, a better firewall
and an intrusion detection system are all good plans. After you're done, you guessed it: test, document,
Source: Sun Hosting, Windows Dedicated Server Division.
Get the most dependable SMTP server for your company. You will congratulate yourself!
Share on Twitter.