Monday 2 November 2009, 8:30 AM
Adobe Reader in the Enterprise
This week I had the pleasure of working with some of the Microsoft Premier Field Engineers (PFE's) in an effort to further understand some of the application compatibility issues that might occur when sequencing for Microsoft App-V (formerly SoftGrid).
Quickly, the topic turned to compatibility issues surrounding Folder Redirection as this appeared to pose a serious compatibility problem for Adobe.
A quick scan of the web, raised a number of forum posting where numerous IT personnel could not get Acrobat or Reader 9 deployed to C# debugging and "file not found" issues.
For a few samples look here:
http://thinmaillist.blogspot.com/2008/08/thin-re-watch-out-with-adobe-acrobat_9472.html
http://www.adobeforums.com/webx/.59b5c03a
It looks like there were some pretty drastic solution paths explored here, especially for Citrix deployments. Yikes... I am really glad that I don't have to do this stuff anymore...
Before I dive too deep into the Adobe deployment problems, let's have a little introduction to Microsoft's Folder Redirection .
The idea of re-directing user local data folders onto the network was introduced with Windows XP and is defined as, "the automated re-routing of I/O (operations) from local standard folders to use a different, storage elsewhere on the network". Translated, this means that some standard user folders (i.e. My Pictures, My Documents) are redirected to store your files on a network server. This greatly increases the chances that your files (and Pictures) will get backed up in the laptop being nicked or knackered.
Windows Vista uses folder re-direction on the following directories; Contacts, Desktop, Documents, Downloads, Favorites, Music, Videos, Pictures, Searches, AppData, Links, Saved Games.
If your browser has a spell checker AppData would appear with a red underline, which is appropriate as the AppData folder is one which caused us and to my great surprise, Adobe quite a lot of trouble.
Through our trouble-shooting exercise it became Adobe Reader and Acrobat 9 were attempting to write user specific data to the AppData folder. This is fine and according to the Microsoft logo application development specifications, this is OK.
So, in an enterprise environment, a user will logon to their desktop or laptop and if their IT department has done their job, the AppData folder will be redirected to something like; \\servername\region\department\username\AppData
And, here is the big issue. As folder re-direction takes place prior to logon- the user will not have any mapped drives. So, the fully qualified path to the final resting place on the target server for AppData will be a UNC path.
Hint: It will be a UNC path.
As you can probably guess where I am going here;
Adobe Acrobat 9 and Adobe Reader can not store their AppData files onto a UNC path. After a little debugging through their code, it appears that there is a failure to "read from left to right" and correctly parse the full path.
Hence, the file not found, app crashes and C# debugger errors that present themselves to users upon application start-up.
So, I did little more digging and loading Flash and version 6,7 and 8 of Adobe Reader. All of these packages use the redirected folder "AppData" in the same way - and I am sure that they will experience the same issue.
I will write more on the Adobe issues in forthcoming posts. And, there will be plenty to write about as it looks like there are over 400 application level conflicts between Adobe Reader 9 and Acrobat 9.
References:
Folder Redirection has a brief mention here: http://en.wikipedia.org/wiki/Folder_redirection
Monday 19 October 2009, 5:35 AM
Windows Operating Systems = Bloatware
There has been a lot going on. I've been trying out CTP 2011 “Quebec” from Microsoft, its basically Windows 7 Embedded. Now I know how various OEMs have been able to demo Windows 7 on all the netbooks that suddenly popped up. Consider the Windows 7 Embedded CTP to be like a "live-DVD" type of installation tool and you'll have the basic idea. If you take out pieces of Win7 that you don't need or want, you can lighten the OS load considerably. The smallest image with some networking I was able to make was about 500 MB. More on that later.
Win 7 Embedded is an oxymoron like jumbo shrimp. The OS is so freaking fat that it really doesn't make much if any sense to use it as an “embedded” operating system. As a touch screen enabled bistro table “information appliance” yeah, I'll buy that idea. Something to put inside a handheld or portable device? No and no way. Putting it in netbooks with Intel Atoms, or Via C7's maybe, they'd be slow. Windows XP though would be a better choice, and Win XP Embedded even better.
I suspect that a large amount of the fat in Win 7 comes from supporting old, really OLD applications. As an example I found edlin.exe in the system32 directory. That in itself was funny since the original edlin was a 16 bit LINE editor in MSDOS. It pre-dates edit.exe, another MSDOS editor, also in the system32 directory. Adding notepad.exe and write.exe makes 4 text editors in one folder. Is that really necessary?.
(Before you jump me, yes I know edlin.exe is still in XP Pro etc. When was the last time you HAD to use edlin? Did you really want to?)
There are runtime packages for C, C+, C++, VB5 and VB6, old MFC etc some of them pre-date Win95. ODBC database connectors for Access 95/97 databases, dBase3, and Paradox. Support for OS2, its limited but there.
Iexpress.exe, an application-installer-packager from the Windows 3.1 era also has an system32 “update”.
Most of the Win7 fat though is semi-hidden in plain-sight. Portions of the operating system have to be written in such a way to support either the old applications directly or through the application compatibility add-ons Microsoft has patched onto the various versions of Windows. Ntvdm and wow (Windows on Windows) are examples of application patching, hosting or shims embedded into Windows. I appreciate the fact that Microsoft wants to support everything they have ever released (except maybe MS Bob!) but come on, can't that stuff be supported in a download and only on the users' systems that need it?
Since Microsoft has stopped supporting MSDOS, Win 3.1 & 3.11, and WIn9X directly, why continue to support them in the new operating systems?
Hook Application Compatibility into Windows Update and use that to download the appropriate packages to support the old stuff the user has to continue using. There already is a side-by-side mechanism setup for the DLL hell of previous Windows NT versions. Something similar can be done for the old stuff, especially the 16 bit stuff.
How about MS making their Virtual PC software into something that does the legacy support? Its an extension of the idea of Virtual XP Pro stuff going to be done in WIn7.
Think of all the plug-ins that users have to download when they go web-surfing all over the Internet. Its not like the users don't already download most of the junk on their computers already.
Most of the people I have had to fix their home computers don't make back-ups and lose their installation disks so when they go out and buy the latest version of Windows Whatever, they end up buying new software anyway. This new software seldom needs MSDOS and 16bit Windows support. So why leave it in the OS as part of the piles of detritus that hardly ever gets executed?
If you want another argument to remove this un-needed dross, think of system security. All of this old compatibility software sitting on the system has a very large and exposed surface to malware writers. At present most of the compatibility software hasn't been used much to attack the host 32 bit system but its an attack vector waiting to happen. If the software wasn't there reliably on every Windows system that would be one less way to hack into or around system security. In other words, the 16 bit legacy software is not on the system UNLESS the user downloads a compatibility package, until then it wouldn't present itself as such a tempting target for future malware. If the malware guys can't count on it being there for use then its not a viable means of attack.
Friday 16 October 2009, 9:08 AM
Microsoft App-V: Helpful Tools
I wanted to mention a rather useful tool that have recently come from Microsoft.
As quoted by one of the TechNet blogs;
"The Microsoft Installer (MSI) Utility for Microsoft Application Virtualization, a utility for SoftGrid Application Virtualization solution that bridges the gap between traditional physical control of installed applications and the new paradigm of virtual applications."
This means that you can now load MSI packages into SoftGrid environments and not have to "Sequence" or convert them to SoftGrid (SFT) packages before deployment. This would allow an organization to utilize their existing SMS environment and "dilute" their application management efforts through supporting two different application management formats.
Have a read:
http://blogs.technet.com/softgrid/archive/2007/09/11/microsoft-unveils-plans
-for-the-msi-utility-for-microsoft-virtualization-at-vmworld.aspx
And the official source:
http://www.microsoft.com/presspass/features/2007/sep07/09-11virtualization.mspx
This makes sense as the SoftGrid SFT file format was riddled with Open Source/GPL software and the compression algorithm was written by a lovely French chap who detested Microsoft - hardly the recipe for a thriving format for M$. I am not too sure that this is going to work for more difficult/complex applications. However, it may help with some of the rapid proto-typing required to get a SoftGrid (aka MAV) environment off the ground and get some applications sequenced quickly, ready for testing (i.e. thrashing).
Monday 12 October 2009, 11:18 AM
IE8: Another Application Compatibility Platform
Getting applications to work on Vista or Windows Server 2008 is not the only compatibility issue that you may encounter. One additional "platform" that you may not have considered is the security and application compatibility restrictions that have introduced as part of the update Microsoft's Internet Explorer - IE8.
These ideas got me thinking about the IE8 compatibility question(s). More specifically,
1) Have new security restrictions been introduced?
2) What features and functionality are no longer available?
3) Are there recent Microsoft updates or patches that may cause an issue with IE8?
4) Are there any new compatibility issues that are specifically relevant to Windows 7 and Server 2008?
It does not take long to work through the IE 8 release notes, the accumulated IE8 support documentation and with a little help from friends who have deployed IE8 to highlight some of the potential security and compatibility issues including;
Deprecated API's
Does you application reference any API's or functionality from these groups?
• DirectAnimation
• Channel Definition Format (CDF)
• Gopher Protocol
Deprecated Features
Does your application rely on any of the following functionality?
• XBM Image format
• Telnet Protocol
• Gopher Protocol
• SSL Version 1.x
• Scriptlet MIME Types
IE8 Signed Controls
Internet Explorer 7 allows for ActiveX controls to be signed and therefore allow for greater privileges and access to local machine file system. Some intranet environments may require that all controls are now signed. To deploy to these environments, you need to ensure all of your ActiveX controls that rely on the IE engine are signed.
IE8 Safe for Scripting Controls
Managing ActiveX controls in an secure enterprise environment is a difficult balancing act. IE8 allows for an additional level of security with the CATID_SafeForScripting and the CATID_SafeForInitializing component category registry settings. These settings allow your IE8 applications to fully use the ActiveX scripting model
IE8 ActiveX Pre-Approved CLSID
Due to the increased security restrictions available in IE8, ActiveX objects (DLL's) may not install correctly due to lack of sufficient permissions. Adding the unique identifier of an ActiveX control to the pre-approved list of ActiveX controls will allow the application component to install successfully. As recommend in Microsoft's (ActiveX Security: Improvements and Best Practices - see references) you should not employ this option if;
- Your ActiveX control was not designed to use pages served from the Internet (as opposed to your intranet)
- Your ActiveX control is downloaded to the target machine
- Your control is solely intranet based (you should use Active Directory Group Policy objects instead)
References:
Microsoft IE8 Release Notes
http://msdn.microsoft.com/en-us/ie/aa740486.aspx
Security and Compatibility in Internet Explorer 7
http://msdn.microsoft.com/en-us/library/ms649488.aspx
Finding Security Compatibility Issues in Internet Explore
http://msdn.microsoft.com/en-us/library/bb250493.aspx
ActiveX Security: Improvements and Best Practices
http://msdn.microsoft.com/en-us/library/bb250471.aspx
Monday 5 October 2009, 10:34 AM
API Calls that break under Windows 7
As mentioned in the Microsoft Compatibility tool-kit, the Developer cookbook and Microsoft Developer Network (MSDN - see references below) there is a section called "Safe Exception handling" under Windows 7 that refers to the deprecation (end of support and removal from the operating system) for two Application Programming Interfaces (API's) under Windows 7 and Windows Server2008.
These two API calls (IsBadReadPtr and IsBadWritePtr) relate to the handling of pointer to the global memory stack used by Windows. These API calls are used ensure that a particular pointer (or memory handle) is properly committed to the Windows Heap stack. Meaning that the code in question has not cased a corruption in the Windows swap file or memory stack. These calls were intended for debugging purposes and known affectionately as "CrashMyApplication" and "CrashMyApplicationAndMyMemory" respectively as they had a very common habit of crashing an application under debug and trace conditions.
Microsoft has removed support for the two API's for security reasons and Windows 7 and Windows 2008 Server will no longer support these API's. It is possible to determine if these calls are included in shipped software but unless the application is tested thoroughly and all functionality is tested, it is impossible to determine if these calls are actually employed and potentially could cause a compatibility issue. However, there is a rough an ready way to determine if these calls are actively employed in an application. If the application works under the following operating systems, then these calls are not being used;
· Windows 2K (all service packs)
· Windows XP SP1 and SP2
· Windows 2000 Advanced Server
· Windows 2003 Server
The IsBadReadPtr and isBadWritePtr API calls really translate to very old applications that related to Windows 9x and NT4 systems. If your applications are currently running normally (i.e. without frequent and continuous crashes) then your application is very unlikely to actively employ these (now deprecated) API calls.
Simply scanning an application for references to these API's would produce serious over-reporting without actually demonstrating that these calls are likely to be used in a production environment (i.e. not a developer testing or debugging mode). To generate an accurate assessment of these API related issues, you will need to ensure that you are scanning the IAT table for files (EXE's and DLL's) that are actually going to be installed on the target platform.
Once done, you should see relatively few instances of this particular application compatibility issue across your application portfolio.
For further reading, please have a loo at the following links;
IsBadReadPtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366713.aspx
IsBadWritePtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366716.aspx
Thursday 1 October 2009, 4:42 PM
My point of view on ... google Wave
in answer to zdnet : Link
Google wave is the missing real time brick in the communication tools on the Internet.
- we add "long time" information, like shared folders, FTP, file hosting service etc., for important information which needed to be kept
- we add "medium and short time" information, like e-mail or instant messaging, for information with a short lifetime
- we have google wave nom, for "real time" information which can be promoted to long time information by publishing a wave
Thursday 1 October 2009, 7:11 AM
6 Laws of Application Compatibility
There is much in the news about migrating to Windows 7 recently. Of prime concern is application compatibility which when simply put means getting applications to work on the target desktop or server environment. There is a lot of complexity in getting applications working - whether on Windows XP or Windows 7 or the recently released Windows Server 2008.
And this is where I think there is some general confusion. Application compatibility is not simply about getting applications to function or work correctly on an Operating system such as Windows 7. Unfortunately, you more work to do. Getting applications to work really means getting the application to work on the target platform which involves the following;
1. Ensuring Operating System (e.g. Windows 7 ) compatibility
2. Ensuring the availability of the complete and correct versions of middleware
3. Ensuring that applications do not conflict with each other (on install and un-install)
4. Ensuring that user environment is correctly setup and available
Breaking the application compatibility question into these four layers delivers a fundamental step change in the understanding and resolution of application compatibility issues. No longer can we just get one application to work on a desktop, we need to get several or even tens of applications to successfully install, update and un-install without breaking other applications. We now have large, complex and constantly changing middleware layers (Java, Crystal Reports, ODBC) that applications depend upon.
Adding to the confusion, differing applications may require different versions of middleware components or worse, may ship from the software vendors with incomplete ("middleware fragments") dependencies which may allow the application in question to function but may prevent another application from working or even installing successfully. Viewing application compatibility with these four layers in mind requires a paradigm shift; to the Platform Integrity model which takes into account all of the requirements to successfully install, use and maintain applications.
To further this goal, we have developed the "AOK Laws of Application Compatibility" which include;
1. Enable the installation package to install successfully
2. Provide the application the required privileges and security access levels
3. Ensure that the required dependencies (middleware) are available and complete
4. Ensure that applications do not conflict with each other on installation, updating/patching or un-installation
5. Ensure that the user environment is correctly configured
6. Ensure that future changes/patches/updates do not adversely affect any of the four layers; the OS, the Middleware layer, Applications or the User Environment
When you follow these guidelines, your chances of successfully developing, deploying and maintaining your application portfolio are significantly increased; today and when dealing with future changes.
Wednesday 23 September 2009, 1:48 PM
From the Source's Mouth
A complaint I've made once or twice, Linux is getting bloated has now been confirmed from the source:
http://news.cnet.com/8301-13505_3-10358024-16.html
Linus Torvald's says so too. (At least as reported by CNet. I tried to find the original quote. Probably only available through Conference proceedings.)
One of the biggest advantages of Linux is that you don't get trapped into one distro or version as with Windows. If you want a smaller footprint OS, you can find a Linux version that's a LOT smaller than Windows.
Tuesday 22 September 2009, 2:27 PM
Ageing Applications and Windows 7 Compatibility
I still maintain that most applications will work under Windows 7 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 Windows 7
2-4 year-old application - 90% will be compatible with Windows 7
4-7 year-old application - 80% will be compatible with Windows 7
8 years and older applications - 50% will be compatible with Windows 7
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 Windows 7. 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 Windows 7 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 Windows 7.
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).
Monday 21 September 2009, 7:40 AM
Application Compatibility: A Starter for Ten
OK, so we had a nice (but brief) Introduction to the problem of application compatibility on Windows XP and Windows 7. So where do we go from here? And, what help is out there right now?
Microsoft has done a pretty good job of trying to manage application compatibility issues since Windows 2000 with the introduction of the Application Compatibility Tool-kit (now at version 5 for Windows 7) which is available here: www.microsoft.com/technet/desktopdeployment/appcompat/toolkit.mspx
In addition, Microsoft offers some pretty in-depth advice for software developers on how to ensure that your application will comply with the Logo certification program. You can find the latest version here that details the requirements for Windows Windows 7 and Windows 2003: http://msdn.microsoft.com/certification/appspec.asp
There are plenty of other, more detailed resources including:
Low-level System Compatibility located at: http://www.microsoft.com/whdc/system/Windows 7/default.mspx
and Developer Best Practices for working in a least privileged environment: http://msdn2.microsoft.com/en-us/library/aa480150.aspx
And my favorite is the Developers Story - Compatibility cookbook is located here: http://msdn2.microsoft.com/en-us/library/aa480152.aspx
This is the THE bible for getting applications working under Windows 7, working through the security restrictions with Windows XP Service Pack (XPSP2). This rather lengthy document details not only what the issues are, but provides some clues as to what is causing the problems. As GI Joe said, "Knowing the problem, is half the problem."
Previous
