how much does Snow Leopard suck?

In the interest of not burying the lede: if you install Snow Leopard, none of your 3rd-party screen savers will work (.qtz files may work but .saver files will not).

Normally I wouldn't give a shit about installing this OS upgrade, except that apparently Apple has fucked up ScreenSaverEngine, so in order to make the XScreenSaver distribion work on 10.6, I have to do a 64-bit build of all of the savers... and that's not possible on 10.5, because the 10.5 version of the ScreenSaver.framework bundle doesn't include the x86_64 architecture.

How angry am I going to be if I install 10.6 on my only computer?

Will it break Photoshop, Illustrator and Lightroom?

The nature of Apple's screen saver fuckup is that .saver bundles aren't separate programs (like they are in XScreenSaver under X11) but instead are dynamically loaded code into the ScreenSaverEngine app. And now they've changed ScreenSaverEngine to a 64-bit app which refuses to load 32-bit code -- meaning they broke every third party .saver bundle.

Dynamically loading the code this was always an idiotic idea. Even before Apple's current fuck-up, it had already meant that one screen saver could screw up the namespace of one that happens to run later (e.g., there are some savers that you can't run consecutively in System Preferences); and it means that a buggy screen saver that hangs can make you need to power-cycle the computer, since deactivation requires the cooperation of the 3rd party saver itself, instead of that being handled at a higher level. With X11 XScreenSaver, user activity guns down the saver whether it is responsive or not: a sandbox, basically, which is the only sensible way to do it.

I'd volunteer to rewrite ScreenSaverEngine from scratch, to make it less flaky and more compatible, if I thought there was any chance Apple would accept and ship my contribution.

Update: Progress is being made. I have questions.

Tags: , , ,

68 Responses:

  1. salyu says:

    i believe it does load 32, 64 bit is backwards compatible, no?

    • jwz says:

      Believe what you want, unless you want to believe the truth.

      • primaleph says:

        I recall when I used to work at a helpdesk, there was initially a problem with Leopard not being able to connect to our network, while Tiger had been able to just fine. We discovered that replacing the network connection software (I forget the exact name) on Leopard with the one from Tiger would fix the issue.

        Is it possible to do this with ScreenSaverEngine? (That is, to remove the Snow Leopard version and replace it with the previous version, from Leopard?) I'm assuming it would probably still run, if the replacement is possible...

    • cjensen says:

      No. Almost all compatibility issues I've seen on Snow Leopard are related to plugins because of the code change. Just as xscreensaver is failing, so are the release version of the 1password plugin, all version of the Evernote plugin, etc...

    • blasdelf says:

      You're right in that 32-bit processes run just fine on [OS X, Linux, FreeBSD, Windows] machines that otherwise run 64-bit code, for [x86_64, ppc970, Itanium]

      What you can't do is load cross-load plugins on any of those ISAs or OSes.

      If you have a 64-bit machine, 10.6 is running the 64-bit version of the ScreenSaverEngine, which is incapable of loading 32-bit saver plugins.

  2. fantasygoat says:

    Photoshop CS3 seems to work fine.

    I think this is more of a $30 service pack than a true OS upgrade.

    • gen_witt says:

      Photoshop CS3 is not supported on OS X.6.

      • tkil says:

        Note that "runs fine" and "not supported" are not mutually exclusive.

        When we say that we officially support a specific OS, you can trust that we've done very extensive testing on that platform. If we haven't done that level of testing, then we simply won't say that we support it. That's why the FAQ reads as it does.

        That said, none of us like to inconvenience customers, so the reality is that we *do* actually perform some amount of testing on older product if we believe that there are a significant number of customers using it. So does Apple.

        As I say, we have reason to expect that all meaningful issues of running Photoshop CS3 under Snow Leopard have been resolved. However, because we have not done the level of testing that true certification demands, we need to stand by our statement that we don't officially support CS3 on Snow Leopard.

        • Pogue reported "frustrating glitches" with PS CS3 on Snow Leopard, which is vague enough to make me want to strike him with a stick.

          • Ah and the compatibility list that leopanthera links to has a check mark for CS3 suite but a notation "Minor bugs in Photoshop and Dreamweaver". Also very helpful. Still, makes me less fearful of upgrading than I was -- I'm not touching CS4 with a 10-foot pole made out of melted down Vista CDs.

  3. leopanthera says:

    Snow Leopard compatibility list

    I'm running it. Spotlight is broken if you have more than one disk/partition. Fixable by erasing the .Spotlight-V100 and .fseventsd folders, and rebooting. Otherwise seems OK.

  4. bifrosty2k says:

    I'm sitting in an OSX heavy shop right now, its totally screwy.
    There are a bunch of machines that it won't even load 64 bit on...

    There are some machines that apparently have 32 bit only bootloaders, that won't run 64bit code properly. You have to load in some hacked bootloader to get stuff to work. Go apple.

    • blasdelf says:

      That's only if you want to boot a 64-bit kernel, which you do not unless you're a wanker. Only the recent Xserves do so by default.

      OS X runs 64-bit code on a 32-bit kernel just fine (both for x86_64 and ppc970). It is novel in this regard.

    • karlshea says:

      I challenge you to give one reason why you need to be booting the 64-bit kernel on anything other than an Xserve.

  5. rane500 says:

    Grain of salt, YMMV, etc etc.

    Seems to be a decent list to me, though. There are a few of my daily-use apps that are either ? or X, but not enough to stop me from upgrading in the next week.

  6. endico says:

    I hope Snow Leopard doesn't break Nikon Scan since Nikon has stopped supporting it. Its a bit crashy on Leopard but usable enough.

  7. pavel_lishin says:

    I'm imagining the guy responsible for the way screensavers work proudly checking in his code, going home, and giving his kids loaded pistols.

    "You kids have fun now!"

    • bugpowered says:

      I'm imagining the guy responsible for the way screensavers work proudly checking in his code, going home, and giving his kids loaded pistols.

      "You kids have fun now!"

      Yeah, because he's like just one guy, not a team, plus he has got no engineering experience, unlike any random LJ commenter.

      3rd party screensavers? That sounds *so* critical...

      • jwz says:

        If it took a team to implement ScreenSaverEngine, things are worse at Apple than I imagine. I speak from some experience on this.

        • tadster says:

          . . . that would be me. Back in 2000 Mike Trent did the basic screensaver engine design and I was assigned to integrate it with OpenGL and produce the fade-between-photos effect. Prolly 4 engineer-months, dunno what happened after 10.4 . . .

          • hal_obrien says:

            You might be amused by this, then.

            Every now and then, when I wake my MacMini from an extended absence at my desk, it does a snow crash. Since it only happens under those circumstances, my working hypothesis is it's related to the screen saver somehow.

            The good news: I've been able to swap email with Neal Stephenson over this (meaning, he answered, something he's known to rarely do).

            The bad news: Neither Snow Leopard nor the recent firmware update for my MacMini resolves the issue.

            The good news: Rebooting the machine seems to clear it, and I've never lost any data.

            So it's only a nuisance. It's an impressive looking nuisance for all that, though.

  8. scullin says:

    The main issue I'm seeing building XScreenSaver is that GetWindowPort is a Carbon function, and Carbon is 32bit only, so none of the GL screen savers build.

    There's also some other weirdness of "This screen saver requires Mac OS X 10.4.0 or later. Your computer has Mac OS X 10.6 installed." for the other screen savers that I'm assuming is a setting somewhere I have yet to find.

    • jwz says:

      I believe the error message that implies that 10.6 < 10.4 is how Apple spells "you are trying to load a 32-bit bundle into a 64-bit process." If this is one you've built yourself, make sure you have the x86_64 arch selected in XCode.

      I'm not sure what the new way to spell GetWindowPort is. Apple's documentation on what Cocoa function you should use to replicate Carbon or Quicktime functionality is typically deplorable.

      • QuickTime went to QTKit. QuickDraw went to Quartz -- there isn't a direct replacement; they've been telling people that QuickDraw was a dead API since 10.4. But anything that could be ported from X11 to Carbon can presumably be ported equally well to Quartz. It's a nicer rendering model anyhow, IMHO.

        Kinda surprised if there isn't an open source library out there to imitate the QD API and issue Quartz calls, since that's what's happening under the hood on pre-SL anyway.

        • jwz says:

          That's fascinating, but if you intended me to understand "what I should call instead of "GetWindowPort", you failed utterly.

          • I guess because there isn't a trivial answer.

            GetWindowPort() is what you call if you need a CGrafPtr, right? There ain't no CGrafPtr no more; that whole rendering model (QuickDraw) is gone, replaced by the Quartz (PostScript / PDF rendering model) CGContextBlahBlah() functions.

            The thing that's analogous to a CGrafPtr is a CGContextRef, whch you can get from [[NSGraphicsContext currentGraphicsContext] graphicsPort].

            • sjl says:

              Yeah, I had a look at the code last night, before going to bed. There's no straightforward "call this function instead of GetWindowPort and everything will work once more". To get it working, it's necessary to replace the aglSetDrawable calls as well; if we're going to do that, we might as well rip out all the deprecated functions and replace them with the modern equivalents.

              I'd suggest that if you can replace the Carbon calls with the Quartz model, XScreenSaver should compile cleanly for 10.6, without sacrificing compatibility with 10.4 or 10.5. I'd sit down and do it myself, but it really would be diving in the deep end of OS X development for me..! Not that that's a bad thing, but it'll be a while before I get my head around things and come up with something that's (a) workable and (b) reasonably clean.

            • jwz says:

              Well, the only reason I'm calling GetWindowPort() is because aglSetDrawable() wants one of those. And the only reason I'm calling aglSetDrawable() is because the AGL stuff is the only way I know of to request RBGA, double-buffering, etc. So you can chase this as high as you like: if AGL is not considered "Cocoa" enough, how do I do the crap that init_GL() needs to do in whatever way is considered "non-obsolete" this month?

              • sjl says:

                I freely admit that I am not an OpenGL expert, and haven't delved in depth. Far from it. My knowledge of OpenGL is close to being little more than its name.

                That said, NSOpenGLPixelFormat (which meshes in with NSOpenGLContext) appears to be what you're looking for. I could be wrong - I'm enough of a neophyte that I'm not certain enough to make more than a very tentative suggestion. I don't know enough about XScreenSaver's internals, or OpenGL, to say that I have the answer, and if you tell me to pull my head in, I will.

                None of which excuses what appears to be a gratuitous, poorly documented change on Apple's part.

          • So, I ported xscreensaver to snowleopard, where "ported" means "GLHanoi and GLKnots and a few others work in ScreenSaverTester, but not in the system screen saver". Turns out that the system screen saver requires your savers to be marked as compatible with garbage-collection, as well as being able to run in 64-bit mode. (It generates a detailed error message internally then discards it and replaces it with an utterly useless one to present to the user.)

            Dunno if you want the changes, they're not large.

            • Hm, if I compile them with -fobjc-gc I can get them to run as real screensavers, but I assume they're either leaking memory like crazy or heading to zombietown, or both.

              • duskwuff says:

                Unless your savers are allocating tons of memory using Cocoa APIs, they're probably fine. GC only applies to ObjC objects - malloc() is treated the exact same as usual.

                • Yeah, good point. The X11 code is probably fine, only the OSX compatibility layer is using ObjC. -dealloc won't be being called so there'll be some leaking, but not as much as I'd thought.

                  • duskwuff says:

                    -dealloc won't be being called so there'll be some leaking, but not as much as I'd thought.

                    That can be dealt with by implementing a -finalize method. And it's not even a particularly big deal unless you care about transient leaks at exit.

      • bonzinip says:

        You need to use aglSetWindowRef instead of aglSetDrawable:

        GLboolean aglSetWindowRef(AGLContext ctx, WindowRef window);
        WindowRef aglGetWindowRef(AGLContext ctx);

        This is not so easy though because unlike many other APIs added in preparation for the QD deprecation, this one is not in Tiger. So you have to look in the system libraries for GetWindowPort, aglSetDrawable and aglSetWindowRef, store their function pointers somewhere, and use either aglSetWindowRef or your own function using GetWindowPort+aglSetDrawable. Alternatively you can create a one-function dylib implementing aglSetWindowRef for 10.4 and load it at run-time (together with retrieving aglSetWindowRef from the AGL dylib if on Leopard or later), or you can create two dylibs and load the appropriate one.

    • rbeef says:

      Do a project find (command-shift-f) for "10.4.0" and replace it with "10.6", and that should resolve that error. I still couldn't get the savers to run after I did that, but at least System Preferences didn't complain when I tried to open them from the Finder.

      For some reason, it needs to be "10.6" rather than "10.6.0", or you'll get a nonsensical error telling you you need "10.6.0 or later" when you have "10.6".

      • jwz says:

        It's looking at LSMinimumSystemVersion in Contents/Info.plist in each .saver bundle (built from xscreensaver/OSX/XScreenSaver.plist). What happens if you change that from "10.4.0" to "10.4"?

        • scullin says:

          It does solve the version whining like changing it to 10.6, however something is still flagging it as incompatible, even after build the binary with the same architectures as the ScreenSaver application, which oddly is still "ppc7400 i386 x86_64".

          • duskwuff says:

            Terrible idea: What happens if you strip away the x86_64 component of ScreenSaverEngine?

            • scullin says:

              Well, I didn't have to resort to that. It is possible to force the screen saver to run in 32 bit mode, and then the Desktop & Screen Preference Pane then comes up with "(32 bit)" in the title bar. However... I have no clue which of a handful of things I tweaked resulted in this, because the effect was not instant. So I guess I can go start reversing things to figure out what that particular change was.

              • scullin says:

                Oh never mind, it's worse than that. If you start 32-bit 3rd party preference panel, System Preferences will ask to restart, and it will restart in 32-bit mode. Then you can select, preview and test older 32-bit screen savers.

                However, they still won't actually work, and even selecting "Open in 32-bit mode" on doesn't seem to make it play along.

                • duskwuff says:

                  I think the "open in 32-bit mode" flag only works for stuff that gets run through LaunchServices. Try actually stripping away the 64-bit component from the ScreenSaverEngine binary (using lipo) and see if it'll work afterwards.

                  (Keep a backup beforehand, though, because this is irreversible.)

  9. vordark says:

    Christ, the 64/32 bit conversion shit isn't behind us yet?

    That said, can some of you tech-industry folks start telling people to stop doing plug-ins via object code and dynamic loading? Yeah, it's great for managing memory in tightly-integrated systems, but screensavers!?! Browser plug-ins? The FUCK!?!

    I thought Apple figured out that letting any idiot with a C compiler extend the OS was a bad thing back in the old Extension days. With binary compatibility a real problem now, this is an even worse idea than it was ten years ago.

    • We tell Apple that regularly, but Apple doesn't itself care -- everything they do can simply be recompiled, and encapsulation is unimportant.

      Actually they're slowly coming around in one way: browser plugins on SL can run in their own process. This lets the 32-bit, buggy, Flash plugin run in a 64-bit Safari browser and crash it less. They have to do it through some crazy GL hack, it's not quite as clean as it could be under X11, but hey, progress of a sort.

      (Presumably you could also run a ppc plugin on an x86 machine this way, under emulation. Wonder if that works.)

    • mattbot says:

      Dynamic extensibility is one of the defining features of Mac OS X/NextStep/OpenStep, from the current Xnu micro-kernel loading kexts to modifying Objective-C code during runtime. A privileged user can override just about anything without recompiling the kernel. They may be giving out just enough rope for someone to hang themselves but Apple has been surprisingly consistent in applying this philosophy.

  10. duskwuff says:

    Any reason you can't build a 32-bit version for Leopard and a 64-bit version for Snow Leopard, then glue them together with lipo? (Aside from the fact that it's a pain in the ass, that is.)

    • jwz says:

      Yes, there is a reason: the 10.5 build of ScreenSaver.framework does not include a 64-bit build. So there is no way to compile a 10.6-compatible bundle using a 10.5 OS. So I have to actually spend $30 to Apple to recompile my software -- with no changes -- to make it run on their new OS. And frankly I find that offensive.

      • It is surprising that this ostensibly-minor upgrade is causing so much trouble, but Apple's always been more willing to break backwards compatibility in the name of progress than Brand M. If you want your old code to run forever, the OS you will never ever ever use is a much better bet.

      • bratling says:

        Wait. Let me get this straight. You're angry because you can't compile for a new version of an operating system using an old version of Xcode on an old operating system?

        I feel like I have got to be missing something basic here?

        • tadster says:

          cross compiling isn't a big deal, XCode can build for iPhone of course.

          Main problem is just the full x64 support I s'pose. Apple's got PPC (G3, G4, G5), x86/x64, and ARM on its plate so the x64 was no doubt a new wrinkle in things.

          Shoulda gone bytecode like C# a long long time ago.

        • taffer says:

          There seem to have been an awful lot of breaking-third-party-software changes for an OS advertised as "no new features, just tuning!" everywhere.

          Why on earth would a screen saver engine need to be running in 64-bit mode? Why is the default kernel 32-bit?

          I'm all for driving ahead and actually deprecating things that need to go away, but there seem to have been some odd decisions made here.

      • primaleph says:

        You don't actually *have* to spend the $30. I'm sure you can think of other ways to find software you'd rather not spend money on.

        • legolas says:

          And maybe less (if still somewhat) illegal: if you can get your hands on a copy of the 10.6 ScreenSaver.framework, you might be able to link against that even on 10.5 (if all the 10.5 tools can handle the ScreenSaver.framework compiled with the 10.6 tools).

          Apple's 'compatibility' behavior is very hard to believe, especially if you're trying to do the same thing for the other commercial OS without any such problems. When is making life hard for developers for your OS ever a good idea, but more importantly to me: why on earth does Apple get away with it?

  11. primaleph says:

    I'll volunteer to build XScreensaver for you on my Macbook with Snow Leopard on it, if you can give me a quick walkthrough of the process. (I know how to compile on Linux, but I'm a fairly new Mac user, so I'm not sure how similar the process is.)

    • jwz says:

      Well, since I haven't screwed around with 10.6, I don't know what's needed. But on 10.5, it should be just: load the xscreensaver.xcode project; Build All. I suspect 10.6 will require editing the project to include the x86_64 arch, and possibly other meaningless compatibility indignities. But as I haven't done it, I don't know.

      • stickofjoy says:

        I had to enable garbage collection (required in 10.6) and activate the 64-bit architecture to get a screensaver I made to run on 10.6. If there's a way of building a screensaver to work on 10.5 and 10.6 I've not yet figured it out.

        Briefly during one of the 10.6 betas, Apple deprecated a text function I use but it came back for the final 10.6 release version. Other than that I love Snow Leopard. :)

        ps: this is an old lj account I never use, but it let me post here.

  12. lionsphil says:

    Great. So, basically, OS X is still using xlock.

    I wish I could say I was surprised, but I tried to hack about with iAlertU at one point to sync it's better-than-nothing alarm shenanigans with arbitrary screensaver [un]locking, only to find that the closest OS X seems to have to xscreensaver-command is to launch and kill ScreenSaverEngine. And that the only way to tell it "please unlock without the usual password prompt" was to use SIGKILL. Weep.

  13. kespernorth says:

    Snow Leopard is broken in fascinating ways. When a friend of mine tried to install it, the installer somehow managed to TURN ON THE DVD WRITER and etched lovely, precise concentric circles INTO THE INSTALL MEDIA:

    Not kidding.

    • jwz says:

      You know, when you see a bug like that... you've just got to sit back and admire it.

    • gryazi says:

      That'd be awesome if it didn't look suspiciously more like a case of 'someone dropped their laptop too many times and the busted-up optical drive is scratching the disk.' Which is pretty common. Second best guess would be 'extreme focus problems due to being dropped too many times,' wherein the lens is scraping the surface. Is there a demonstration of this machine not scratching the shit out of other media inserted and read to the outer tracks?

      Do prove me wrong, because I Want To Believe.

      • kespernorth says:

        I don't really have a way to prove that, but the laptop is less than a month old and looks to be in good shape - I don't *think* it's been dropped. (This isn't happening to other DVDs, either.)

  14. rafasgj says:

    OS 10.4 (Tiger) is still better than the later versions, and 10.6 (Snow Leopard) won't run on any of my machines. (Yep, they are all PPC.)

    That said... It seems there is a way to run CS 3. CS 4 is said to work "out-of-the-box". I'm not sure about LR, but I believe the latest update will also work (haven't read many complaints about it).

    Anyway, it's mainly guesswork, as after any (later) update, it is "cross your fingers and reboot".