tsk said:
I agree with the first statement, but I don't think it's that difficult to recompile the software. It's certainly not going to take anywhere close to a year IMO.
Of course it's not that hard to recompile the software! Good development shops will do a recompile of their code every night (so compile-breakers are caught and fixed quickly and a "latest code" build is always ready)! However, while that is good news to developers, that doesn't mean that Intel/PPC binaries will be out tomorrow morning. There's a bit more involved here than just a recompile.
A few points.
1. For a developer using XCode already, using Cocoa already, and using the Altivec high-level APIs instead of low-level APIs already, it should be a quick recompile. HOWEVER, it is more likely than not that this will not be released as a "patch", but rather as a new version. Different companies may make different choices, but history shows that, generally speaking, things like this will debut in the "next" minor/major release opportunity. Doing it as a slipstream patch is a tech support nightmare.
2. For developers not using XCode/gcc (CodeWarrior still has a substantial user base! IBM's compiler has been put into use by a good number of high-end application developers because it makes significantly faster executables than gcc!), not using Cocoa, or using low-level APIs or, heaven forbid, assembly code ... well let's just say that one year may just about be enough time to make the transition internally. But, maybe not enough time to both make the transition locally AND piggyback that onto a release opportunity. I wouldn't be surprised to see a good number of Quarks out there still this time next year for that very reason.
3. Across the board, a significant hardware change means additional QA. No major development house should be shipping Intel/PPC software if they did not do a full regression test on Intel boxes as well as their traditional PPC-based QA test fleet. Mom and Pop shops are excluded from this requirement (we'll understand if something slips through there, and blame Apple instead), but the big guys and even the not-quite-little guys will need to plan for proper QA. Note that adding QA isn't something you do overnight; either you add time to your existing release plans (which may be impossible, forcing the Intel/PPC binary to debut in the "next next" release), or you add heads to the QA team to run the same tests you've been planning for in PPC-land on the Intel boxes. While the latter gets you out the door on time and allows for earlier Intel support, it is generally harder to pull than slipping release dates.
4. Fallback plan: Rosetta. Will work great for low-CPU usage applications that currently run on G3s. Anything that requires Altivec (remember how Apple has been telling you not to do that for the past five years? Yeah, you wish you'd listened!) will not run. All Classic apps (which, obviously, are even less likely to be updated for Intel than any others) might as well be put in the museum. Fortunately, the Altivec-loving apps tend to be from bigger companies in general, and they should be able to pull off an Intel transition within the year. But there are a handful of small one-man development shops that put out software that loves altivec; you'd better hope that if you have any on your Mac that the guy decides to flip the switch, recompile, debug, and support Intel, or you'll just have to learn to live without it.
FWIW, Intel Macs any time prior to 2006 would be suicidal for Apple. Period. The software just won't be there. I'm betting on an April launch of Intel Macs. Maybe the Mac Mini will be earlier, but I'd be somewhat surprised if they were announced and shipped in January at MWSF. MWSF chops the expectation of one year that Apple just gave their developers to about 6 months. And that, my friends, is just plain silly. But, still, it's possible, given the size of the show and the impact. But definitely not before then!