Monday 16 November 2009, 5:59 PM
This Crap Site
How utterly stupid - I am ranked #40 in the top 100 - as a member of this site.....
I mean HOW utterly stupid.... I have done sweet FA, I have only rejoined this site after a 3 or 4 year absence.....
And I have only posted about 3 comments so far - and if that is what it takes to become so highly ranked; it really is pathetic.
Monday 16 November 2009, 3:45 PM
Microsoft Security Update: November Patch Tuesday
Apologies for this late update to our core Patch Tuesday update. Here is a summary of the update ....
The November Patch Tuesday update from Microsoft follows the largest patch and security update in Microsoft’s history. This month there are six updates to Office, Active Directory and Microsoft’s Office application suite.
These six updates have a low impact, bar one patch to Excel which may cause compatibility issues for some applications. The main cause for concern here is that Excel is a primary if not essential element to many environments. For example most banking, trading floor and insurance platforms. Therefore any change must be tested rigorously.
Whilst there are few applications in our sample that are affected, the ChangeBASE AOK team recommends that the Excel update (MS09-067) requires particular attention in any environments where there is a significant dependency on this,
We have included a brief snap-shot of some of the results from our AOK Software that demonstrates some of the potential impacts on Microsoft Office deployments with the following picture.
Testing Summary
MS09-063 : : Marginal impact and negligible testing profile
MS09-064 : : Marginal impact and negligible testing profile
MS09-065 : : Marginal impact and negligible testing profile
MS09-066 : : Marginal impact and negligible testing profile
MS09-067 : : Moderate impact and negligible testing profile
MS09-068 : : Marginal impact and negligible testing profile
The full posting of these results can be found on;
http://www.changebase.com/News/NewsPage.aspx?page=20091110-01_PatchTuesday.xml&style=~/Style/PatchTuesday.xsl
Sunday 15 November 2009, 5:13 PM
Marketing Suggestions from an Ambivalent Windows 7 Customer
Part of the work that's been keeping me busy the last few weeks have been involved with evaluating Windows 7 Embedded and/or the final released version of Windows 7 Pro, Ultimate, Business, Supreme (whatever). The ambivalence is because I don't think it buys me much of anything I don't already have with Windows XP Pro or Embedded.
The Quebec CTP 2011 is Windows 7 Embedded and I've been working with it trying to determine if there is anything my company might gain by using it instead of Windows XP Embedded. Not much.
However if Microsoft wanted to truly create something worth buying, they might consider the idea of merging Windows 7 Ultimate-Whatever with the Embedded product and allow customers the option of “building” or compiling images using the Quebec infrastructure. Combine that with a “license” to build up to 5 images, the customer then could put as much or as little as wanted into those 5 systems.
If Microsoft really wanted to make things work well for their stockholders, they would put it on a subscription model, allow customers to download upgrades for a fee to their licensed systems.
The Quebec ISO is practically a live DVD image. It will install itself and put what the customer wants on the system compile. It calls home to the mothership and gets registered. It requires an Internet connection.
Yes the customer of this particular version will need to be more knowledgeable than the typical Joe Sixpack BUT Microsoft does has a fairly high percentage of those since Windows has been around for a long time. I could see it being an attractive package for Windows wonks. It might even boost sales a bit by appealing to the techno-snobs and Windows fanbois. They'll just have to have it.
(You know if you ignore the word Windows, it sounds a lot like Linux, if you get rid of the stockholders.)
Sunday 15 November 2009, 4:35 PM
Karmic Koala Krashes
I've been fairly busy the last few weeks and some of it was because Ubuntu 9.1 served up a unexpected & nasty surprise. It will not load properly on a DELL Dimension 2400 desktop. This particular model is somewhat ancient as computers go BUT it still is a Celeron (P4 class) running at 2.6GHz with 2 GB of RAM. I am loathe to replace it because it has been extremely reliable for over 5 years now. It works about as well as anything with a near 3GHz processor currently available save the dual core CPU's.
I have tried installing 9.1 using two methods. One was the on-line in-place upgrade from 9.04 to 9.1. The other was a full install ISO image. Neither method worked, both crashed on the next boot after installation.
At first I thought it is was an issue related to grub but that wasn't the problem. Increasing RAM size also wasn't the issue. The original 512 MB memory was twice as much as required minimum. One GB of RAM didn't help resolve the issue.
The really annoying thing is that a trashed install of 9.1 kills the previous installs like 9.04 on the same disk. Even selecting previous installs or the recovery options crash.
I suspect the Intel 845 chipset is the issue, in that I've installed Ubuntu 9.1 on later model chipsets and not had any problems. I've backed up a few steps, wiped the drive and re-installed 9.04 on it and everything is running again as well as it was 2 or 3 weeks ago. This particular system is my “server”. Lots of backed-up files on large hard drives. It cannot be unreliable.
The primary reason I have invested so much time and energy into Linux, Ubuntu in particular, is to wean myself and my household off Windows. Especially now. The price for Windows 7 shrink-wrap significantly approaches the price of a new hardware platform. The economics get even worse when talking about buying refurbished computers. Putting Windows 7 Home Premium on a salvaged computer system makes even less sense.
What has been damaged more than anything else is my trust in the Ubuntu programmers and test engineers. I had gotten to the point where I believed that installing anything from Ubuntu was not going to be an issue requiring lots of remedial work. It was stable, able to install on practically anything without crashing. That trust has been severely damaged.
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
Previous
