Last-Minute Glitch Holds Up Windows XP SP3

An anonymous reader sends word that Microsoft Windows XP SP3, which had been scheduled to hit the Web today, was pulled back at the last minute. SP3 apparently broke a Microsoft application, Microsoft Dynamics Retail Management System. Their solution is to set up a filter to make sure that no system running the affected software will get automatically updated; once the filter is in place, SP3 will be released to the Web. A fix for the incompatibility will follow.

Curious

[TubeSteak]

You'd think Microsoft would test Service Packs against all Microsoft products while the SPs are still in Alpha or Beta.

well done

[geekoid]

they caught an error and patched it for everyone else while working on it.

This can happen to any patch that rolls out. It's when it's not caught that we should complain.

No, I am NOT an apologist.

Re:An insider report...

[Anonymous Coward]

You're not funny.

I'd recommend that you keep your day job, but chances are you're not very good at that, either.

What else will break?

[blunte]

Makes you wonder what software will break that they didn't test...

I suppose we owe thanks to the early adopters out there for testing all our updates.

Now you know why your corporate IT department is so reluctant to update software and OSs.

Re:XP SP3 = "Vista Migration Plan"

[petermgreen]

Windows XP still has just under 6 years of support left (just under a year of mainstream support left, then another 5 years of extended support).

It seems you are confusing the end of support with the end of retail and big brand OEM availibility.

I'm not suprised

[EmbeddedJanitor]

Firstly, the type of organisation using retail management systems tend to be conservative and not bleeding edge because downtime costs money. They would not be playing with beta SP releases and would not be seeing problems.

Secondly, Microsoft is not one monolithic entity, as many believe, but a group of different business units. The DRMS folk aren't going to drop their current activities to check whether a different business unit's updates work.

Thirdly, so what! Why not ship it anyway with a release note saying "Don't use with DRMS!". SP2 broke some MS developer tools and that did not stop them shipping it. Some organisations had to wait months for updates before they could migrate to SP2.

Re:Curious

[Romancer]

That is what alpha and beta testing is supposed to address. It's not unreasonable to expect that during the beta testing of a piece of software that they would try and make sure it was compatable with at least the software packages they sell.

And secondly, this is what happens when software isn't sectioned off from the os and contained with reasonable restrictions and documented APIs. This would be a really simple thing for them if they even stuck to their own standards. How would if break another application if they had communicated a set of standards to both departments on how to program properly. Or even built an OS that contained programs to a reasonable level and didn't always throw crap into the OS directory. /rant

Re:well done

[machxor]

But if you RTFA you'll see that they did not patch the installer. They "patched" Windows Update to not provide you with the installer for XP SP3 if it detects MS DRMS. There have been no changes that prevent a MS DRMS user from downloading the SP3 installer exe and running it. "To help protect our customers, we plan to put filtering in place shortly to prevent Windows Update from offering both service packs to systems running Microsoft Dynamics RMS. Once filtering is in place, we expect to release Windows XP SP3 to Windows Update and Download Center"

Re:Curious

[JebusIsLord]

Windows File Protection only protects a static list of files installed by Windows. To quote MS:

"All SYS, DLL, EXE, and OCX files that ship on the Windows CD are protected. True Type fonts--Micross.ttf, Tahoma.ttf, and Tahomabd.ttf--are also protected."
http://www.microsoft.com/whdc/archive/wfp.mspx#E3F [microsoft.com]

DLL hell still very much exists, as I fight with at work all the time doing application packaging. Typically things like incompatible crystal reports dlls are an issue. Typically and end-user will end up with dozens of different versions of the same DLL in different installation directories, often installing to both %system% and %programfiles%. The next program installed registers it's copy, breaking the old application. App isolation works sometimes, but sometimes it also unfortunately breaks the hell out of things. WFP couldn't even help if it DID apply to these files. .NET thankfully fixed this with the global assembly cache, but that doesn't apply to the win32 world.

Back on topic, it sounds like they DID catch this during testing; which is why it's being delayed! Nice catch, MS. It isn't like we need SP3 direly, right now.

Anyhow,

Re:Curious

[revlayle]

Say what you will about MS and .NET.... .NET (as the parent says) certainly has reduced DLL hell *significantly* Also, it has become increasingly easier to "zip up a folder" of a managed app, unzip to another system and run without a single problem (unless there are hard paths in the app's config file that a well done app will detect and will 1) fix or 2) interactive ask the user "hay where is this?"). As long as you have the correct .NET runtime (which isn't anything different from any other runtime library). COM: nightmare, in fact I found COM worse than just dealing with windows DLL modules in a C/C++ app.