Windows 7 - First Compatibility Catch

An associate proudly announced to me today, "Hah, got one for you! And, I bet its the 1st one!"

 

The chap in question was obviously delighted about something. And judging by our shared past history and the shiny new laptop he pulled out his laptop bag - I thought I was going to see a rather extreme incarnation of an 8 core triple over-clocked 100 Gb RAM super laptop.

 

No, not quite that exciting but still exciting. 

"We"  had found the 1st "in the wild" Windows 7 application compatibility error. And the culprit was a piece of software I use literally ten times a day. I felt a little sheepish  as I could not believe I had not tested this application out on Windows 7 yet.

 

So, the ActiveX control for the remote control software Logmein does not work on Windows 7.

 

Even more embarrassing, I don't know why yet.

 

I just doesn't load - no error messages. No log files and I have not had time to delve into DEBUG mode.

 

Why?  Well, after a quick call to www.logmein.com support,  I was offered some simple instructions to force an "auto-upgrade" to build  3.00.606  from my rather ancient build  of 3.00.395.

 

15 seconds later: I was all joy - now using the latest/best and Windows 7 compatible build and I was off and literally running.... To catch my train. 

MS05-022: Nothing a new version won't fix

I received an automated Microsoft Security Bulletin email over the weekend and was a little surprised about the nature of the change.

 

The update was an update to a Microsoft Update MS05-022- interestingly an update that was released over 3 years ago. And, yes, it was an update to an update. And the offending bit of code is Messenger. The original bulletin referred to Messenger 6.2 (quite a few versions back now).

 

The security bulletin can be found here: http://www.microsoft.com/technet/security/bulletin/ms05-022.mspx

 

This is quite a serious issue as, "An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights."

 

Here is the revision history of this update;

 

• V1.0 (April 12, 2005): Bulletin published        
• V1.1 (May 11, 2005): Bulletin updated with correct file version information for MSN Messenger 6.2        
• V2.0 (January 21, 2009): Bulletin updated. Replaced the download link for MSN Messenger 6.2 with the bulletin link to MS07-054. Users may either use the specific download link in MS07-054 to upgrade, or log on to MSN Messenger service to accept the required upgrade.

 

It looks like there was full version increment to this bulletin as in 2007, this update was released as MS07-054.

 

Why is this important? And, why am I writing about this?

 

Well, our normal pattern/approach  for analysing patches is to determine the updated files or registry settings and determine what configuration settings and dependencies may affect your application portfolio. For example,  the first (and only) update for this year MS09-001 updated a single file SRV.SYS

 

Well, the payload or the files for this update is actually a link to a completely new version of the application.  This security update does not point to a WSU file or Microsoft Hotfix style executable (EXE) but a completely new version of the application. Basically, Microsoft is saying,

 

"There is a security issue here. And, you need to download the latest version"

 

This in itself is not a problem. Vendors do this all of the time. We do it (yes, we do). I guess the challenge here is that you may be using version 6.2 of Messenger and the security update is.... Upgrade to version 8!

 

Well, as my friendly mechanic says, "There is no problem that a new car won't fix." And in this case, the update is a upgrade.

 

 

Windows 7 - 1st in a Series

 

Well, I have been working with the Microsoft teams and busily reviewing the update Windows 7 documentation and it looks like there will be a few compatibility issues with Windows 7 that are in addition to the issues experienced by Vista.

 

In case you missed it, I posted the location of the Microsoft  Application Quality Cookbook you can find it here;

http://code.msdn.microsoft.com/Windows7AppQuality

 

I will be tackling a number of issues over the coming weeks which should cover;

 

• Internet Explorer 8
• Windows 2008 R2 Compatibility
• Deprecated Windows Components
• Driver and Sub-system compatibility

 

In this blog posting I wanted to discuss the removal of Windows Mail from Windows 7. I am not quite sure why  this component was included in Vista but now ALL of the Windows Mail components have now been removed from the current version of Windows 7. Reading from the Microsoft Application Quality Cookbook, it looks like the following actions have been implemented;

 

• All entry points to Windows Mail and Contacts are removed or disabled.
• Any APIs that attempt to launch the main browser UI have been modified to create a silent failure.
• Protocol (mailto, ldap, news, snews, nntp) handlers will not be associated with Windows Mail or Contacts.
• File associations (.eml, .nws, .contact, .group, .wab, .p7c, .vfc) are broken or disabled.
• The Contacts folder is hidden by default so customers will not see it
• APIs are marked as deprecated in MSDN
• The file preview function is removed
• Shell hooks in the right click menu are removed
• The file search function is removed

 

Some of the good news for this update include;

• Publicly documented APIs continue to work as they did in Windows Vista
• Any user files (for example, contact files or messages) remain on the system in the upgrade scenario

 

Microsoft recommends the following advice for handling these issues;

 

• Do not design code that calls the Windows Mail UI API, since it will not work.
• You must find other ways to access the .eml and .nws files.
• Discontinue your reliance on all other Windows Mail APIs.

 

Hmmm... I guess you could always install Outlook....

Microsoft Patch Tuesday for January 2009

As the first and only patch update from Microsoft for the start of the year 2009, we have not detected potential patch impact issues for our testing portfolio. This makes sense as the Microsoft patch relates to the network component SMP which is rarely (if ever used) by applications. As a result, very few applications in use today will ship components that neither affect the contents of the patch MS09-001, nor are applications likely to depend on the primary file updated by this patch (SRV.SYS).

In addition to the standard Microsoft Patch Tuesday, two previous patches were re-released a few hours after the initial Patch Tuesday updates were released. These releases included;

• Microsoft Security Bulletin MS08-072
• Microsoft Security Bulletin MS08-076

The expectations from the ChangeBASE team are that the Microsoft update MSO9-001 is very unlikely to cause OS level or application compatibility issues. In addition, the two update patches had marginal impact on the AOK Application portfolio.

A sample of these results includes;



Testing Summary

• MS09-001: No Impact (both Package level and dependencies) detected across portfolio
• MS08-072: Marginal impact for Office related applications
• MS08-076: No Impact (both Package level and dependencies) detected across portfolio

Patch Name	Total Issues	% of apps Affected	Reboot	Rating	RAG
Microsoft Security Bulletin MS09-001	<1%	<1%	YES	C
Microsoft Security Bulletin MS08-072	<1%	<1%	YES	C
Microsoft Security Bulletin MS08-076	<1%	<1%	YES	I

Legend: 

M = Moderate  I = Important  C = Critical

No Issues Detected Potentially fixable application Impact Serious Compatibility Issue

c. 800 applications were tested against these patches using the ChangeBASE ACL (Application Compatibility Lab)

Security Update Detailed Summary

MS09-001	Vulnerabilities in SMB Could Allow Remote Code Execution (958687)
Description	This security update resolves several privately reported vulnerabilities in Microsoft Server Message Block (SMB) Protocol. The vulnerabilities could allow remote code execution on affected systems. An attacker who successfully exploited these vulnerabilities could install programs; view, change, or delete data; or create new accounts with full user rights. Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed.
Payload	Srv.sys
Impact	Remote Code Execution

MS08-072	Vulnerabilities in Microsoft Office Word Could Allow Remote Code Execution (957173)
Description	This security update resolves eight privately reported vulnerabilities in Microsoft Office Word and Microsoft Office Outlook that could allow remote code execution if a user opens a specially crafted Word or Rich Text Format (RTF) file. An attacker who successfully exploited these vulnerabilities could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Payload	Winword.exe, Wwlib.dll, Msword.olb, Wrd12cnv.dll, Wordcnv.exe
Impact	Remote Code Execution

MS08-076	Vulnerabilities in Windows Media Components Could Allow Remote Code Execution (959807)
Description	This security update resolves two privately reported vulnerabilities in the following Windows Media components: Windows Media Player, Windows Media Format Runtime, and Windows Media Services. The most severe vulnerability could allow remote code execution. If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Payload	Registry settings only
Impact	Remote Code Execution

I take it all back...

I have been corrected. By one  of the Application Compatibility Greats - Chris Jackson.

 

He has pointed me in the right direction and to the new application compatibility guide for Windows 7.

 

The new document titled the, "Windows Application Quality Cookbook" can be found here and is an excellent insight into some of the issues that you may experience with Windows 7;

 

http://code.msdn.microsoft.com/Windows7AppQuality

 

I will review this document and post some thoughts on potential compatibility issues and some remediation measures 1st thing next week.

 

Until then, thanks Chris.

 

And, to the rest of you, happy reading.

Windows 7 freshens while the docs rot

OK - in case you have not yet received your copy of the latest BETA of Windows 7, you only have to wait a few more days. I have been fortunate to receive updated releases from Microsoft for the past little while and I have been really impressed with the stability, build quality and general performance of the BETA version of Windows 7.

 

That said, I am a little surprised at how little things have changed since the release of Windows 7 at the

Microsoft Professional Developers Conference in 2008.  I am using Windows 7 pretty much every day now on one of my test machines and it feels faster than my higher spec main development machine. Windows pop up quicker, the file system in explorer responds quicker and applications load quicker. It feels sharper.

 

That said, I expected some of the pre-release documentation for Windows 7 to be a little better. At present, we have the Windows 7 Developer's guide;

 

Found here:

http://code.msdn.microsoft.com/Win7DeveloperGuide/Release/ProjectReleases.aspx?ReleaseId=1702

 

And the Application Compatibility Cookbook (http://www.microsoft.com/Downloads/details.aspx?FamilyID=69c63073-fe3f-47c3-baa5-b37943afe227&displaylang=en) is now looking a little dated with it's  last update exactly one year ago.

 

It would be great if we could start working on the some of the compatibility issues for Windows 7 now - instead of waiting until July 2009.

 

That said, there is now a tremendous amount of information on Internet Explorer 8 and application compatibility which can be found here:

 

http://msdn.microsoft.com/en-gb/ie/cc405106.aspx

 

Vista - Virtualization for the masses

Well, you thought that virtualization was expensive, involved evaluating  and deploying complex new technologies and possibly new ways of thinking about deployment and maintenance (shock horror).  You may also not be aware that Vista offers a level of virtualization right out of the box. Not the VMWare kind of OS level virtualization or the SoftGrid (App-V) kind of application virtualization - but the simple kind called;

folder and registry re-direction or "Folder and Registry Virtualization".

 

Folder and Registry Virtualization attempts to address the scenarios where an application attempts to write to a "local machine" or security protected area - and Vista automatically redirects the write (and subsequent read) request  to a user portion of the registry or a folder location in the user profile.

 

If you are developer type, you can find out more here: http://msdn.microsoft.com/en-gb/library/bb530198.aspx

 

Virtualization is pretty painless under Vista and is a great technology. However, you need to be aware that you should not rely on Registry and Folder virtualization as Microsoft states;

 

"As virtualization is an interim application compatibility technology, Microsoft intends to remove this form of virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista. As a result it is imperative your application does not take a hard dependency on the presence of virtualization in the system."

 

Microsoft has outline a few scenarios where you may need to disable Virtualization - which can be found here: http://support.microsoft.com/kb/927387

 

I think the biggest "gotcha" is the packaging of applications on Vista . Virtualization may cause duplicate registry and file locations in your target package as part of the snap-shot process. Not a big issue - but you will need a mechanism to checks for these duplicate registry entries and files.

 

Symantec has some great  coverage and demos on Virtualization which can be found here:

http://www.symantec.com/community/article/2665/folder-virtualization-concepts-windows-vista

 

And

http://www.symantec.com/community/article/2665/folder-virtualization-concepts-windows-vista