One of the most common (and yet rarely publicized) issues to affect almost all applications that are over two years old will be Help file compatibility. Microsoft has deprecated all Microsoft Help file formats and components. Meaning, help files are not supported under Windows Vista and definitely will not be supported under Longhorn Server (due H2 2007).
Help files (HLP extension) are the files that include the application specific documentation on usage, troubleshooting and further support options. While not absolutely essential to application functionality they are a key element to the user experience.
In addition to no longer allowing users to read/use Help (HLP) files; the following Help file components are no longer supported under Windows Vista;
Windows.hlp
Winhlp32.hlp
Winhlp32.cnt
Winhelp.cnt
Nocntnt.cnt
Reading the Microsoft knowledge base article (KB917607), Microsoft has the following to say about Help files on Windows Vista,
"The .HLP files that depend on these files may return an error when users try to open them. These files will be available in the future from the Microsoft download center to address compatibility issues. "
When Microsoft "deprecates a component" it effectively does four things;
1) Disable support for that component on the target OS - meaning it will no longer work
2) No longer provide technical support for that component - meaning Microsoft will not help you on this issue
3) Actively encourage you to try other options - i.e. direct to you to a later component
4) Possibly remove support for component dependencies
Following this methodology, Microsoft no longer will "load" a help file and display it's contents. Instead you will receive a message indicating that this functionality is now longer supported and will direct you to a Microsoft knowledge base article detailing the security issues surrounding Help files.
This will cause a number of "Known Issues" when using Help files including;
· Help Macros are disabled
· You cannot access .HLP files that are stored on intranet sites
· Non-interactive user access has been blocked
· Drag-and-drop functionality has been disabled
I am really surprised at this approach. The WinHelp.EXE engine (version 5.0x) under Windows XP SP2 may be a significant security issue so I understand that an upgrade or update is necessary. However, why not include WinHelp.exe (version 6.0) in Windows Vista?
Microsoft makes an update available (version 6.0 of the WinHelp engine) on their knowledge base website (http://www.microsoft.com/downloads/details.aspx?familyid=6EBCFAD9-D3F5-4365-8070-334CD175D4BB&displaylang=en).
So, you can download it and continue using older, "non-compatible" HLP files as long as you like. Hmmm...
Actually, there are two further points. If you need to support any of the following features you also need to add the following registry entries on your target machine.
Allow Help Macros
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinHelp
Value: AllowProgrammaticMacros
Type: DWORD
Unblock .HLP files that are stored on the intranet
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WinHelp
Value: AllowIntranetAccess
Type: DWORD
Friday, 27 June 2008
Thursday, 19 June 2008
Ageing Applications and their respective compatibility
Ageing Applications and Vista Compatibility
I still maintain that most applications will work under Vista and Longhorn (just today re-branded as Windows Server 2008) but by reading this blog you might think that there are quite a few issues. My gut feeling is on application compatibility is will follow a sliding scale of something like:
1 year-old application - 95% will be compatible with Vista
2-4 year-old application - 90% will be compatible with Vista
4-7 year-old application - 80% will be compatible with Vista
8 years and older applications - 50% will be compatible with Vista
What drives these kind of numbers? Not hard-core scientific research but experience with thousands of applications from Windows 3.1, NT4, 2K and Windows XP.
Hence, the reference to "gut feel". That said, these estimates can be backed up by the following events;
1) In 2005 Service Pack 2 (SP2) introduced a majority of the restrictions that are now in place with Windows Vista. Excluding the new UAC functionality, most the local registry, local machine IE restrictions were expected to cause a large issue with corporate applications with the release of SP2 - the reality was the only a small proportion of applications were affected.
2) In 2003, Microsoft released Windows XP with a new driver model and enhanced application compatibility support for legacy applications. This is the big hurdle for most developers (excluding driver developers) - if you got your application working on XP - then you are likely to get most of the application working on Vista and Windows Server 2008. The driver developers had to pretty much start again.
3) From 2001-2002 Vendors starting delivering application installations in the MSI format moving from the early days of a few poorly constructed MSI's (some packages were just Setup.exe's within a single custom action inside an MSI) to the present where roughly 80% of applications are shipped in the MSI format. Note: an install may be released an SETUP.EXE but really is a boot-strap MSI.
4) In 2000, Windows Installer started the installation standardization process that allowed vendors and corporate IT system administrator to rationalize their application management strategies to a single deployment technology (MSI) thus removing two of the primary reasons for application installation failure;
- Non-standard installation technology
- Non-transparent installation logic
It may seem straight-forward but vast majority of application failures are due to poor application installation routines.
5) Most application in use today that were shipped pre-Windows 2000 would have been targeted for Windows NT 4 or 3.51 and may have dependencies on 16-bit components or the NT driver model. These older applications represent the greatest challenge to application compatibility on Windows Vista.
But hey, that's why we can use SoftGrid under Citrix to deliver these legacy apps. No more need for kiosk machines (aka total security liability).
I still maintain that most applications will work under Vista and Longhorn (just today re-branded as Windows Server 2008) but by reading this blog you might think that there are quite a few issues. My gut feeling is on application compatibility is will follow a sliding scale of something like:
1 year-old application - 95% will be compatible with Vista
2-4 year-old application - 90% will be compatible with Vista
4-7 year-old application - 80% will be compatible with Vista
8 years and older applications - 50% will be compatible with Vista
What drives these kind of numbers? Not hard-core scientific research but experience with thousands of applications from Windows 3.1, NT4, 2K and Windows XP.
Hence, the reference to "gut feel". That said, these estimates can be backed up by the following events;
1) In 2005 Service Pack 2 (SP2) introduced a majority of the restrictions that are now in place with Windows Vista. Excluding the new UAC functionality, most the local registry, local machine IE restrictions were expected to cause a large issue with corporate applications with the release of SP2 - the reality was the only a small proportion of applications were affected.
2) In 2003, Microsoft released Windows XP with a new driver model and enhanced application compatibility support for legacy applications. This is the big hurdle for most developers (excluding driver developers) - if you got your application working on XP - then you are likely to get most of the application working on Vista and Windows Server 2008. The driver developers had to pretty much start again.
3) From 2001-2002 Vendors starting delivering application installations in the MSI format moving from the early days of a few poorly constructed MSI's (some packages were just Setup.exe's within a single custom action inside an MSI) to the present where roughly 80% of applications are shipped in the MSI format. Note: an install may be released an SETUP.EXE but really is a boot-strap MSI.
4) In 2000, Windows Installer started the installation standardization process that allowed vendors and corporate IT system administrator to rationalize their application management strategies to a single deployment technology (MSI) thus removing two of the primary reasons for application installation failure;
- Non-standard installation technology
- Non-transparent installation logic
It may seem straight-forward but vast majority of application failures are due to poor application installation routines.
5) Most application in use today that were shipped pre-Windows 2000 would have been targeted for Windows NT 4 or 3.51 and may have dependencies on 16-bit components or the NT driver model. These older applications represent the greatest challenge to application compatibility on Windows Vista.
But hey, that's why we can use SoftGrid under Citrix to deliver these legacy apps. No more need for kiosk machines (aka total security liability).
Sunday, 15 June 2008
This is one of the first Blog entries for the ChangeBASE website and I hope that everyone is a little patient with me. Getting my "writing style" up to the right level will take a little while but I really hope that the topic of application compatibility will be well represented here.
Working with the fine technical people Microsoft it appears that most application compatibility issues will stem from the following issues;
1. Driver incompatibility (Display, Printer peripheral devices)
2. Legacy 16-bit Memory Issues
3. Networking Restrictions
4. Security Restrictions
If you are using specific drivers for DVD writers or relying on TWAIN drivers for your Scanner, you will probably have to get an upgrade from the software vendor. And if you are still dependant on the really old 16-bit applications (poor you) there is a solution for you - it's called SoftGrid but more on that topic later. Network restrictions will cause some applications to behave in unexpected ways, but my belief is that this will be quite a rare occurrence.
Security restrictions under Vista are very similar to those imposed on Windows XP Service Pack 2 (SP2) and will be the root cause of most failed installations and expected behaviors. Which, is great news for us application packagers, deployment engineers, and sysadmins. It means that for the most part, Microsoft has provided (or allowed) work-arounds through Shims (through the Application Compatibility toolkit), registry configurations or through the create of manifest security files.
And, this follows the approach of ChangeBASE on application Compatibility. My feeling is that if we can report on an application compatibility issue; we should be able to fix it - meaning to get that application successfully deployed to the target platform (server or desktop) and get the desired functionality user standard user privileges. Quite a challenge, eh?
Subscribe to:
Posts (Atom)