SP1 breaks iTunes

https://discussions.apple.com/thread/2762816

I know Microsoft devs would never admit it if they did break iTunes with Windows 7 x64 SP1, so I'm not going to bother on that.

I just want to mention that this is why some people can't stand Windows. I'm sure the SP1 authors think it's funny or whatever. I thought it was funny that Parallels for Mac had a Windows 8 installer.

@1____1: Personally, I can't stand iTunes, I detest it with a passion.

Microsoft devs just need to come out and admit it

Given how amazingly poorly written Apple's Windows version of it's applications are, I wouldn't be at all surprised if any update broke them. I also wouldn't be pointing the finger at Microsoft for the mistakes either.

So let's get this straight. You link to a year old thread about a problem with a version of iTunes. And somehow that's Microsoft's problem.

Never mind that reverting to a previous version of iTunes solved the issue. Or that removing the Apple USB driver and have it reinstalled automatically fixed it. Or that the next version of iTunes didn't have any issue (well, *this* particular issue, at least). Or that backup and restore with iTunes are not transactional.

Yes. Obviously those stupid developers at Microsoft are failing at telling those idiots at Apple how to write software. I blame Ballmer for this.

@1____1: DWMT.  This appears to be flame bait.

That was just one of the many threads on the internet about the issue.

I don't use Windows on this particular workstation all too often, and just got SP1 x64 pushed to a workstation which broke iTunes.

I am running the latest iTunes 10.5.2.11 on bare intel i7 based hardware on a dual boot, not virtualized in Parallels. Now I have to run iTunes as root (Administrator) to get it to work. It's most likely a UAC problem with SP1.

iTunes is such a popular and widespread program that it is most likely on the Microsoft QA regression list for any service pack.

Microsoft devs just need to come out and admit it

This doesn't really matter, sorry I mentioned it.

Sorry, your link doesn't work (as Google recently broke common search operators...)

@1____1: Ok, so your theory is that Microsoft released W7 SP1 knowing it would break at least a few iTunes user (either making sure it did or by noticing during testing and keeping silent about that). I can follow you so far.

What I cannot understand is how a Service Pack released in February 2011 (and in public beta since July 2010) could possibly break iTunes 10.5.2.11 which was released just 33 days ago. Care to elaborate?

Not to mention that I run that same version of iTunes (10.5.2.11) on Windows 7 x64 SP1 and it runs just fine (where "fine" is defined as "as good as iTunes gets", anyway).

9 hours ago, Sven Groot wrote

Not to mention that I run that same version of iTunes (10.5.2.11) on Windows 7 x64 SP1 and it runs just fine (where "fine" is defined as "as good as iTunes gets", anyway).

I was on an older version of iTunes at the time of the SP1 install. After it wouldn't launch I checked the Windows application log event viewer and saw no useful information.

I then uninstalled iTunes, Safari, Quicktime, Bonjour, Apple update and every other Apple program on the workstation. I rebooted to clear the libraries out of the memory. I downloaded iTunes x64 from Apple.com and re-installed from scratch as an Admin Windows user. I had the same problem.

I then right clicked the iTunes.exe, clicked the compatibility tab and checked "Run this program as administrator" and chose compatibility mode for Windows 7 and that fixed it.

It was no doubt a UAC problem, but all the user specific files are stored in AppData ( AppData\Local\Apple Computer\iTunes ), and my user has permissions to the iTunes library. I never had a problem with it before SP1.

I wonder how it would have went over if they let QA slide on Photoshop instead....

13 hours ago, PaoloM wrote

Sorry, your link doesn't work (as Google recently broke common search operators...)

http://www.google.com/robots.txt

Look at the robots.txt

Only /? is disallowed. Not /#

So now other search bots can index Google.com results as anchored deep links as long as they follow the HTTP request. Just because Bing has not yet copied that particular feature doesn't mean it's bad until it's cloned by MSFT.

I would say they did that to let bots crawl results and poison the web indexes of other search engines.

The link I posted works fine on any modern browser such as Firefox or Chrome.

23 minutes ago, 1____1 wrote

*snip*

I wonder how it would have went over if they let QA slide on Photoshop instead....

Well I imagine that Adobe would see what had changed in Windows (because they would have had about six months to play with the new version) and made sure their app worked.

It's Apple's job to make sure iTunes works on Windows, not Microsoft's.

@1____1: What has robots.txt to do with anything? Its purpose is to prevent crawlers from indexing public resources; browsers simply ignore the whole thing.

@PaoloM: The link works just fine here (IE9). The only issue I observed is when your location settings cause a redirect to a google server in a different domain (e.g. www.google.it). In that case, the fragment is lost and you wind up on an empty home page. Not sure if that's google's fault or IE's.

Google has changed its query string not to use ?, but rather # anchors, and has not disallowed it in robots.txt.

/ is allowed in Google's robots.txt and all of the queries on Google are now in the / document path because technically, there is no query string.

There's essentially three ways this kind of thing can end up happening.

1. The application (iTunes in this case) depends on undocumented functionality in Windows. Anything that's not in the docs, MS is free to change, and when they do applications that depend on it break.
2. The application depended on behavior that was actually a bug in Windows, and the bug got fixed.
3. Microsoft accidentally introduced a new bug that broke the application.

Only one of those options is actually MS's fault, the other two are the application developer's (in this case Apple's) fault. I have no data on how common number three is, but I do know that number 1 is very, very common (just read Raymond Chen's blog). And MS goes out of their way to insert compatibility shims so that important and popular applications that are guilty of this trangression continue to work even after the undocumented behavior got changed. That's right: Windows contains thousands of application-specific workarounds because the app developers didn't follow the rules.

I'm willing to bet, considering the shoddy quality of Apple's software on Windows, that this is another case of number one.

As for your specific scenario, it's hard to say what's going wrong. iTunes should be able to work without elevation, and it does on my system. The permissions of something have to be set incorrectly (note it doesn't need to be a file or even a registry entry; it could be something as obscure as the activation permissions of a COM+ component). Perhaps you should try using Process Monitor to see if you can spot any failed accesses.

21 hours ago, 1____1 wrote

*snip*

It was no doubt a UAC problem, but all the user specific files are stored in AppData ( AppData\Local\Apple Computer\iTunes ), and my user has permissions to the iTunes library. I never had a problem with it before SP1.

If it's UAC "causing" it, then it would be indicative of a LUA bug in iTunes and not in Windows, as it would fail similarly on any system in which the user didn't have Administrative rights.

It looks to me like this is Beer come round to haunt the Channel9 forums like some kind of vengeful spirit once again. Whereas most of the world has moved on from blaming UAC for everything, Beer has decided once again to show his solid understanding of Windows internals by claiming that UAC is affecting third-party USB drivers.

Methinks it best that we ignore the troll.