|
August 25, 2008
Purified Chicken Embryo Cell, The VUF, and Menu Master Beta
The response to the voluntary upgrade fee for FruitMenu was freakin' amazing. It far, far exceeded our hopes and we give our gratitude to everyone that did the VUF.  Once again, I want to give thanks to all those that participated in the VUF and to all those that plan to participate. Let's have a chat about Menu Master For the last year and a half (18 months), every Menu Master beta has included a "Silly Effect". Most people never noticed this because it would only appear in one or two applications (TextEdit and Safari). The Silly Effect itself was created over the span of two weeks way back when, and polished so it could be shown off to users. It looks something like this (but animated):  Anywho, that's how it was in Menu Master one point four point three beta three. And then there was the anger. So much anger and so much ire. Some people claimed it was a bug. Some people tried repairing permissions, being unable to tie the new behaviour to the software they just installed that mentioned "silly". Some people went completely "psycho". (For what it's worth, he was told not to share the key because it had already been changed to something else in the codebase for beta four). If anyone has seen any other public forums with posts that complain about b3, please email the links to us or put the URL in the comments. Before releasing the third beta, we were a little worried that not that many people use Menu Master (MeMa from now on). Well, putting in that "new" feature and defaulting it to on with so many animations (some very hard to read) definitely taught us something. People that love MeMa... really love it. We'd also like to apologize to anyone that lost work or had a drop in productivity while the animations were showing. What's new in 1.4.3b4?  Here are the release notes:
Here is what has been added to the read me: Silly Effects Silly Effects is a cheesy animation option developed over the course of a few weekends over a year ago. There was no work needed to make it compatible with Mac OS X 10.5. Silly Effects puts a Quartz Composer document animation in the background of a menu. By default, these documents are culled from Library/Application Support/Unsanity/Menu Master/ in both your user folder and the main Library folder (Local Domain and User Domain). There are also a number of quartz composer documents included in the Menu Master.ape application enhancer bundle. However, these are not loaded by default. If you wish to load these bundled animations, check "Include Bundled Animations" in the Menu Master preference pane. If you wish to create your own snazzy animation and are familiar with Quartz Composer, Quartz Composer documents can use two inputs that Menu Master makes available to them. "SelectedMenuItem", which is the name of the currently selected menu item (you may want to filter out "-", the separator), and "MenuItems", which is an array structure containing the names of all the menu items in a menu. More information on Quartz Composer can be found at: Apple's Quartz Composer Documentation Futurismo Zugakousaku's excellent Quartz Composer Lab study (contains a lot of excellent Quartz Composer documents) Do we remove it or keep it in? Now that people have seen the silly effects, should we keep them in MeMa (but disabled by default) or should we just remove the entire thing, so no one can enable them? Of course, if we decide to keep it in for the final, we would really like some better looking animations than that MenuEvil.qtz thing I made. I do not have the skills of an artist. If anyone does have the skills, and is willing to let us use your work in MeMa, we would greatly appreciate it. Other Stuff Well, there's been two betas of MeMa released and still no new fansubbed episode of Detective Conan has been released. I weep. Also, please do respond in the comments here on the "keep or trash issue" and the Menu Master voluntary upgrade fee. Please state your reasons if you don't mind. Important Note: the final version of MeMa will be released super quickly fast depending on the results of this post. So I'd like to see some responses to this post by the time I wake up tomorrow. I've already been awake for 24+ hours. Although, there might be a reprieve if a new Detective Conan fansub is released.
August 18, 2008
New Releases: APE 2.5, SCR 1.5, FruitMenu 3.7
Over the last three days, we've released the final versions of Application Enhancer 2.5, Smart Crash Reports 1.5, and FruitMenu 3.7. Application Enhancer 2.5 and APE SDK 2.5 
 Remember, if you want to know more about the background of APE 2.5 or any other release mentioned here, see the post entitled "Enthusiastic Trepidation". Download APE 2.5  The now condensed release notes are the following:
The biggest issue with SCR, by far, was making sure the permissions were correct for Mac OS X 10.5 and making sure SCR wasn't installed previously in ~/Library/InputManagers/. If it was, remove it from the current user's Library. Download Smart Crash Reports 1.5  Here are the condensed final release notes for FruitMenu 3.7:
A lot of people have commented on this blog and via email that they would gladly pay for FruitMenu again once the final release was out. However, if you feel you want to "give" money but don't want to give the whole amount, then the voluntary upgrade fee (vuf) might be more kosher to your tastes (Ketchup or Catsup?). Please Note: There are no perks or benefits to paying the vuf. FruitMenu is not aware of anyone that opts to pays the vuf. And paying the vuf will not get you an additional code as the vuf is not tied into the SN system. It's completely optional, there is no pressure. The vuf is mostly targeted to users that purchased FruitMenu some four years ago. Since we've never charged for an update to FruitMenu so far, the amount of revenue coming from FruitMenu is low as we've nearly saturated the market of people that would install FruitMenu and thus, would pay for it. The reason FruitMenu was the first non-free software we released for Mac OS X 10.5 is that it was the product where the least amount of changes were required to run on Mac OS X 10.5. Most of the changes in FruitMenu 3.7 were done to decrease application launch time (the performance factor) when FruitMenu was installed. A few people have complained that the performance increases cause the System Preferences item to take "forever" to load on the first display per application. We figured it was a decent compromise to reduce the application load time. In order to decrease the first display time of System Preferences (and improve the performance of other parts of FruitMenu), FruitMenu is going to need some logic rewrite. We figured it'd be best to get a final version of FruitMenu 3.7 now and include more performance optimizations in a future update. Other stuff Expect a new Menu Master beta sometime around when a new fansubbed episode of Detective Conan is released. Please note that we will not update this blog when a new beta of a product already in beta is posted. However, all the links in previous posts will download the new betas, even if they say they are for old betas. And new betas will be available via the updater if you have an old beta installed.
August 06, 2008
Dear APE, I want you inside me. Love, Leopard #2: APE 2.5b2
Uhm... Well, I didn't have this post very well thought out. Usually I dwell on blog posts for weeks while in the shower, but all I had for this post was the title and the photo.  Of course, there are some exceptions. For example, Smart Crash Reports 1.5b3 was released a few weeks ago (it's also a part of FruitMenu 3.7b3 and higher). SCR does not include an updater (there's no need... yet) so I will state what's new on this post (ugh, that's not creative writing!)
Download Smart Crash Reports 1.5b3 The really big news of course is Application Enhancer 2.5b2. We really, really didn't want a repeat of what happened with older versions of APE (re: previous post). I mean, we really didn't want it. To that end, we've added an updater to APE itself. By default, it checks for updates weekly (or when the system version changes). If you install APE 2.5b2, I'd like you to change update checking (in the Application Enhancer preference pane) to daily. Some third-party APE module developers asked if they could disable the update check when the user installed their software. We have decided against allowing it to be changed on install by anyone other than the computer user. I mean, "the problem" only occurred because some third parties were shipping very old versions of APE with their products (re: previous post again). It'd kind of defeat the purpose of the updater if it could so easily be controlled by third-party software.
Download APE 2.5b2 Finally, there is a new beta of FruitMenu that includes APE 2.5b2 and SCR 1.5b3. However, you'd have to use the updater to get the new beta. We are desperately trying to get people to use the updaters. Once again, I'd like to repeat the warning stated on previous posts in this category. I'm sorry if it seems harsh, but it has to be said. Note: Please do not post comments and/or send emails asking about the present and/or future of things not mentioned in this post. Such comments will be moderated, deleted, or edited. When we have something to say about other products, it will be posted, and not a moment before then. Asking us about ETAs just ends up wasting both of our time. Apologies for taking such a harsh stance, but the only thing we would tell you is "it'll be done when it's done" and we're trying to prevent a repeat of the tens of thousands of comments/emails we've received asking for an ETA. Any kind of timeframe or ETA we could possibly give will be wrong and users get very disappointed when ETAs are missed. That's the nature of ETAs, they are always wrong. And due to the fact we won't release something before we feel it is ready, any ETA is even more likely to be missed.
On a happier note, I would like to state that SCR 1.5b3, FM 3.7b5, and APE 2.5b2 are nearly the final versions before actually being released in non-beta form. Except for the logging in FruitMenu, assume everything to be final and do not treat the software as beta quality in your mind. Speaking of the logging in FruitMenu, we are looking for any large values attached to "CreateMenuItem:" as listed in the console. We especially want to know if any operation takes longer than 200ms. This information will be used to increase FruitMenu's loading speed in the future. Price Increases Abound On a final note, the prices of the haxies are going up as the Leopard-compatible versions are released. FruitMenu, for example, is increasing from $10 to $12. The reason for this price increase is the sad state the US economy is in (seriously, Canadian funny money is worth more than the US dollar, OMGWTFBBQ?!). The price increases of other products have not been decided on yet.
February 24, 2008
Enthusiastic Trepidation
(Yes, Betas). While my previous post talked only about the past, this post talks about the present. Some of the previous post is intentionally wildly out of context if you don't read this post. And some of this post may be out of context if you don't first read the previous post. Note: Please do not post comments and/or send emails asking about the present and/or future of things not mentioned in this post. Such comments will be moderated, deleted, or edited. When we have something to say about other products, it will be posted, and not a moment before then. Asking us about ETAs just ends up wasting both of our time. Apologies for taking such a harsh stance, but the only thing we would tell you is "it'll be done when it's done" and we're trying to prevent a repeat of the tens of thousands of comments/emails we've received asking for an ETA. Any kind of timeframe or ETA we could possibly give will be wrong and users get very disappointed when ETAs are missed. That's the nature of ETAs, they are always wrong. And due to the fact we won't release something before we feel it is ready, any ETA is even more likely to be missed.
Standard Goldfish Disclaimer Applies These betas also have some significant user interface issues that will be resolved by the time their final release approaches. With that said, I wanted to talk about the current public betas for Mac OS X 10.5 we are releasing now. But, I'll do it in no specific order. APE 2.5 (and SDK)First, let's talk about the situation behind what happened with APE 2.0.1 and Mac OS X 10.5.0 (note that APE 2.0.2 was released on 2006-11-01, a year before Leopard's release, and APE 2.0.3 is the current version). Namely, specifically what caused the issue and what the issue actually was. I am hoping discussing this issue at length will restore any confidence in APE that may have been lost or at least prevent people from pointing to this issue as an argument against APE. BackgroundAPE is "burdened" by a number of restrictions placed on it. Some are the usual restrictions others are restrictions we've placed on APE from our knowledge and years of experience. Still other restrictions we've placed on APE just because it seems like a good idea to restrict APE to certain boxes beyond empirical evidence (hypothetico-deductive?). For example, "if doing something X is a bad idea, then certainly related action Y is just as bad." We also keep enforcing restrictions that were true on previous versions of Mac OS X, even if those restrictions have long since been lifted by the system itself. We try to respect the legacy. Also, whenever it is decided APE has to call a new API it's never called before, we evaluate who else uses the API on the system (especially if Adobe, Microsoft, and/or Apple applications uses the API) and the chances of a system update changing the previously documented behaviour of said API. We try to choose functions that, if they ever change due to a system update, they will fail in a spectacular and catastrophic manner. So spectacularly catastrophic that Apple cannot release the system update without breaking hoards of Mac OS X's most important applications (this is known as maintaining backwards compatibility). All of our code contains metric assloads (imperial assloads, too) of error checking and state checking code. If a function returns anything but void, an error check is made (and sometimes even if a function returns void. If something calls into a different API, a state check is made. APE contains about four point three times (if not more) state and error checks than most developers (including developers for embedded devices) would find necessary. With the result of every check being that APE stops doing what it is doing and disables itself if the check is not exactly what we expect it to be or if APE suspects the state of anything has changed. There is absolutely no room for "kind of" in APE. As an extremely abbreviated example, "this is a green tree". APE would first check to make sure the state is correct. The state being that APE is currently in an environment that can support something that lives, then something that grows (most developers would just assume their application is running above ground on the planet Sol 3, APE makes no such assumptions). APE would then error check to make sure green is a color and that a tree is organic. It would then check the state and make sure the environment has the nutrients to support organic life, then to make sure it supports the combined object "green tree" (that the wavelength of incoming light supports the chloroplasts for a tree and that the wavelength reflected is perceived as green). It would then do a bunch of other error and state checks. Of course, "this" could be a purple tree but APE has never seen a purple tree before. Therefore, APE will disable itself if it sees a purple tree. APE actually does a lot more checks and changes the order of the checks a bit, but this was just an abbreviated example. That may have been a somewhat tortured example, but it correctly describes the nature and amount of paranoia gone into the state and error checks in APE in a manner that may be understandable to most people. It's also all of I could think of at the time. Sadly, I will continue using this analogy. The IssueThe problem in Mac OS X 10.5 with APE 2.0.1 is that one of the state checks APE used is rather high-level. In Mac OS X 10.5, Apple made a change so that this particular state check initializes a lot of unrelated subsystems and caches the states of those subsystems. To use the above analogy, it'd be similar to APE querying Mac OS X to determine if the tree was on Sol 3. However, instead of just loading the state of the current planet like Mac OS X 10.4 and earlier did, Mac OS X 10.5 also asks the USGS for the count of the items on the list of named lineae on Europa and then asks the IAU for the list of named minor planets around Ceres. This became an issue in that the component of APE 2.0.1 that asks for this state check happens to also be a client of one of the unrelated subsystems (configd in this case, used for synchronous notifications of specific state changes). Since configd cannot respond to a query indirectly made to itself at very specific times, this created a race condition that could result in the login process deadlocking. This problem was not caused by a failure or bug in APE's code. (configd accidently and indirectly asked a question of itself and refused to answer until the question was answered by itself.) Due to it being a deadlock, the login process would never continue on Mac OS X 10.5 with APE 2.0.1 installed, no matter how long the user waited. Note: This particular state check is explicitly documented by Apple as being thread-safe, but we do not call it from multiple threads anywho. I wish to remind everyone at this point that APE 2.0.2 was released on 2006-11-01 and that APE 2.0.3 is the current non-beta version. This problem should be reproducible in a stand alone application. I've spent a few hours on it here an there, but could never get the threads to align with the moon in just the right way to reproduce the race condition. After a few hours with no results, I stopped trying to reproduce it as I realized I had better things to do than try to make a new project, reproduce the deadlock, and send a bug to Apple. Especially since I knew Apple wouldn't be able to reproduce it due to the nature of race conditions and immediately close the bug as "cannot reproduce". Sadly, no amount of error checking or state validation on our part could have prevented this issue. It was not a situation we could have tested for as the fact it occurred at all was happenstance. So you found this problem and fixed it for APE 2.0.2, right?Yes and no. No and yes. Since the problem only occurred on Mac OS X 10.5 with APE 2.0.1 and not later versions, we looked at what changed in APE 2.0.2 and later that prevented ("fixed") the problem. Turns out that while we were trying to find a workaround to include in APE 2.0.2 for the horrible Rosetta bug, we had realized that if this particular state check (the one in the above section) was ever false, many of the other state checks before it and after it would also be false. Therefore, we could move this state check to a much, much, much earlier place in the code as it was a type of "master control" for other state/error checks. Moving the state check to such a location made the initialization of the completely unrelated subsystems that happens on Mac OS X 10.5 occur at a time at which no race condition could occur. Furthermore, by the time we moved the state check for APE 2.0.2 (which was around September or early October 2006), the Mac OS X 10.5 seed that developers had was virtually unusable. It would either kernel panic often or couldn't be installed on our development machines due to bugs in the seed. And if we happened to find a machine that it could run on for a while, applications crashed often. And this is all on a completely clean install, with no third-party software installed on it. So we never got chance to find out about this problem before APE 2.0.2 was released. Then again, I'm not sure the problem would have occurred on that seed of Mac OS X even if APE 2.0.1 would have gotten that far. The changes to all the various subsystems in Mac OS X 10.5 between October 2006 and October 2007 (when Mac OS X 10.5 was finally released) were very significant. Some components were completely removed from Mac OS X 10.5 in that time and some brand new components were added. Basically, we were not aware of the problem when we implemented the workaround. So it was a coincidence that the problem is addressed with APE 2.0.2. It is important to mention this now before I discuss some other things. Important Note: If, for whatever reason, you want to stick with APE 2.0.1 (and don't want to install APE 2.0.3 or APE 2.5b1) and you are running Mac OS X 10.5.0, then install the Mac OS X 10.5.1 update or the Mac OS X 10.5.2 update to address this issue. After installing Mac OS X 10.5.1, you will no longer have this issue if you have APE 2.0.1 installed.
Despite the fact that the issue was completely addressed by APE 2.0.2 (released on 2006-11-01), for APE 2.5, we decided to look for an alternative API to get the same state information; one that was not as high-level as the one we used previously (read above for low-level vs high-level discussion). Luckily, such an alternative API exists in Mac OS X 10.4 and Mac OS X 10.5. (You may notice that APE 2.5b1 and all the betas listed in this post now require Mac OS X 10.4 or later). This alternative API fits within all the requirements and restrictions I mentioned APE has above, especially the catastrophic requirement. This new API is also what the higher-level state check we used to use eventually calls to actually get the information we requested. This new API also has a super bonus failure check built directly into it, automatically adding more error and state checking. So it matches our design philosophy quite well. Yay! Why didn't you test APE 2.0.1 with Mac OS X 10.5 before Leopard was released?This is a question we've gotten from a few people, but I've never understood why it would be asked since APE 2.0.2 was released on 2006-11-01 and APE 2.0.3 is the current version. Note that the question is phrased here exactly as it was asked by these people. The question was not edited to be more APE friendly. First, assuming we could have tested it, why would we? APE 2.0.1 was replaced a year before Mac OS X 10.5 was released. If we would have tested it and found a problem, what would our recourse have been? To release an update to APE 2.0.1...? We already did that a year beforehand. All of our haxies have built in software updaters. If the user didn't choose to install any updates that include APE 2.0.2 or later in that year, they wouldn't have installed an update that was released with nothing but a bumped version number (as a form of lip-service). Well, they wouldn't have seen it since our software update has no method of ignoring updates and they would have had to have turned off the updater. And there are, of course, third party APE Modules and third party utilities that install APE. If these products were updated since APE 2.0.2 was released (since 2006-11-01), they should have made sure their products included the latest version of APE available at the time. Actually most, if not all, of these third party softwares do make sure to include the latest version of APE with their new releases. It's the primary reason why the APE installer is packaged into such an easy to use and easy to distribute file. This single file has all the logic to install, remove, validate, repair, and update APE built right into it. It also allows us to work around bizarre bugs in the system that are necessary to workaround for APE's sake. This is also why we do not permit third parties to modify the single file APE installer itself. If a third party wishes to make sure they have the latest APE installer in their product, they just install the latest APE SDK. Then they drag and drop the single file installer into their project/installer. The APE SDK also installs the latest version of the non-SDK APE installer to /Library/Frameworks/ApplicationEnhancer.framework/Tools/, so a lot of developers just make copying that file into their installer part of the build process (via Xcode's run script build phase). Doing this means they always make sure they have the latest installer included with their products. Secondly, even if we wanted to test APE 2.0.1 (as opposed to APE 2.0.3) on Mac OS X 10.5 before it was released to users, we couldn't have. Developers got the ability to download the final build (~6 gigs) of Mac OS X 10.5 at around 3pm on 2007-10-26 and the final developer documentation was not available until around 2007-10-31. Before that, developers weren't allowed to discuss Leopard, even if they had a purchased copy of Mac OS X 10.5 from a store (read that thread, if you have the time or the interest). And the two seeds released to developers before the final (9A559 on 2007-09-21 and 9A527 on 2007-08-24) had a very significant bug that prevented APE (any version) from working. Those versions of Mac OS X 10.5 refused to respect the security restrictions APE was asking for. Because this was a very significant bug, and involved security, we had no reason to believe it wouldn't be fixed in the final Mac OS X 10.5 release. (Yes, it was fixed by the final 9A581 build of Mac OS X). Due to the nature of this bug, APE versions earlier than the custom build for Mac OS X 10.5 we were using wouldn't have been able to get anywhere. Thus, there was no way to test APE 2.0.1 (or 2.0.2, for that matter) as the bug guaranteed they would not load. If, for some bizarre reason, this bug was not fixed in the final build of Mac OS X 10.5, then at that time we would have figured out a way to work around it and make Mac OS X respect the security restrictions we wanted. We would have done it then, and only then, because when Apple ships a bug in a major version of Mac OS X 10.y.0, it usually stays there until NMOS or NMOS+1 for backwards compatibility reasons. (Also, because it can be hard to convince the manager at Apple in charge of the component with the bug to let an Apple engineer work on fixing the bug and then ship the updated component in a Mac OS X 10.y.x>0 update). Luckily, because this bug (the one in 9A559 and 9A527, possibly earlier seeds) created an impossible state in Mac OS X (one that violated documentation, common sense, and a few standards), we were able to add even more error checking to APE. As discussed above, we like to add error checking code. There's no reason for us not to test for theoretical cases of failure; you should never test for theoretical success, only success you can verify in practice. Finally, who's to say we didn't test APE 2.0.1 (as opposed to just APE 2.0.3 or just APE 2.0.3 and APE 2.0.2) on every seed of Mac OS X 10.5.0 that we were capable of testing against? This state check subsystem initialization behaviour may have only been introduced in the later seeds of Mac OS X 10.5.0, preventing any kind of testing by us from finding it. Please do not assume we did not do as much as possible. I'm sorry if this section sounded overly harsh, but the question is it attempting to answer is a great example of a loaded question. The person asking the question is generally asking it in a rhetorical manner and does often not actually want or care for an answer. Alternatively, they ask it as fully knowing there's no way we can answer it without looking bad or as if we did something wrong, they've already decided what the conclusion is. Thus, it is a loaded question. If the situation was reversed and we asked the questioner a similar question, but one that fits their situation, they would also be at a loss to answer it as we are. The saddest thing about all of this is that we didn't even know there was an issue until consumers started getting Mac OS X 10.5 in their hands. By that time, it was all over the internets. And there was so much conflicting information that we were unable to understand the situation for a very long time, let alone reproduce it. However, we did update our website to show that APE 2.0.3 did not have the issue as soon as we were told about it (before we could confirm the issue in older versions) and we sent out a notice to everyone subscribed to our mailing list as soon as we could (which was again, before we could reproduce the issue or fully understood it). Due to the huge number of people subscribed to our mailing list, it took two to five days for some people to get the email and by then the story had spread all over the place. Why do y'all keep repeatedly saying APE 2.0.2 was released on 2006-11-01 (a year before Leopard was released) and that APE 2.0.3 is the current version?We mostly keep repeatedly saying that APE 2.0.2 was released on 2006-11-01 (a year before Leopard was released) and that APE 2.0.3 is the current version to drive home the fact that APE versions released in the past 16 months do not have this issue. Furthermore, anyone that's updated APE in the past 16 months would not have this issue. We also really want to convey to people that this issue was addressed long before we knew about it or could know about it (see above and below). A tangential reason for the repetition is that we really want to stress the importance of keeping software up to date. This applies to all software, not only APE. End users can use software tracking sites such as MacUpdate.com or VersionTracker.com. Developers should attempt to add software update checking into their own applications. They can either use a custom rolled solution (such as we do, since our requirements may be "unique") or use an extremely easy to integrate, open source updating framework, such as Sparkle. Yes, our custom updater does need a bit of work and polish, but that work will be done when we have more time to allocate to the task. I upgraded to APE 2.0.3 and I'm still having this issue || I completely deleted all traces of APE from my computer, yet APE is still causing this issueNo, you aren't still having an issue related to APE 2.0.1. There are a few changes to Mac OS X 10.5 that make it seem like something is failing, a blue screen appears for too long, or that login time is taking excessively long. I'll list some of the issues that could be confused with this one, but are unrelated to the problem APE 2.0.1 people experienced (note that APE 2.0.2 was released on 2006-11-01, a year before Leopard's release, and APE 2.0.3 is the current version). Mac OS X 10.5.x no longer shows a progress bar when booting. I think this is the biggest thing people attribute to a problem with APE. When people booted their computer box and it was running Mac OS X 10.4, the user would see a progress bar after the gray screen with the Apple logo. After the progress bar window disappeared, it would show the login window after a very short time of sitting at a blue screen. This progress bar was fake. It had nothing to do with how long Mac OS X 10.4 would actually take to boot. It was simply a program, /usr/libexec/WaitingForLoginWindow, that appeared for the amount of time the previous boot took to complete (this time value was stored in /var/db/loginwindow.boottime). It was absolutely nothing but a placebo there to make the user think progress was occurring. In Mac OS X 10.5, the boot process has changed a bit. WaitingForLoginWindow and /var/db/loginwindow.boottime are gone. Since launcd on Mac OS X 10.5 no longer supports explicitly listing dependencies and has no StartupItems, there is no reason for the fake progress bar during boot. All launch daemons are launched on demand and in an asynchronous manner. If a launch daemon has an implicit dependency (say it requires a service that another daemon provides) then the launch daemon will block ("pause") until that service is available. As soon as the service is available, the daemon will continue. This allows for multiple daemons to be launched simultaneously and to do as much work as they can before they need another service to be available. All of this leads to a significantly decreased boot time, further obliterating the need for a fake progress bar. The BootCache. Because loading multiple simultaneous daemons for startup can be slow, Mac OS X has an extensive boot caching mechanism. This caching mechanism is stored in a file, /var/db/BootCache.playlist. This cache significantly decreases the boot time of Mac OS X. This caching mechanism is surprisingly well documented in the BootCache.kext source code. If the BootCache.playlist file is outdated, old, or unavailable, the time a user sees the blue screen on Mac OS X can more than double. You can actually reproduce this yourself, if you so desire. At least, you can reproduce the longer blue screens display to prove to yourself that it's one reason you may see a longer blue screen irregardless of whether APE is installed. Simply reboot twice and measure the time the blue screen appears for. Then, open the terminal (/Applications/Utilities/Terminal) and run the following command: sudo rm /var/db/BootCache.playlist and reboot a final, third time. Time how long the blue screen appears for. It should appear for about 170% to 200% longer than it used to. The /var/db/BootCache.playlist is automatically regenerated on boot. If Mac OS X ever determines the BootCache.playlist is being a lying liar or isn't decreasing the boot time at all, it will ignore it and regenerate a new one. This is also why you see longer blue screens after installing an update to Mac OS X 10.5.x. If you wanted to reproduce a no progress bar, extremely long blue screen on Mac OS X 10.4, you can open the terminal (/Applications/Utilities/Terminal) and run the following commands (they are on two lines, they are two commands): sudo rm /var/db/BootCache.playlist Then reboot. When you are done playing around and want to restore the original behaviour, type: cd /usr/libexec/; sudo mv WaitingForLoginWindow.ignore WaitingForLoginWindow DiskArbitration. As I mentioned above, Mac OS X 10.5 has a lot of implicit service dependencies. Before the loginwindow can appear, and the blue screen can disappear, anything the loginwindow depends on must be up and providing its service. The loginwindow depends on DiskArbitration (diskarb) to be working before the blue screen will disappear. The problem is, diskarb freezes a lot. Especially if you have external FireWire or USB hard drives connected and their bridge boards are particularly shoddy. Diskarb will completely deadlock the machine until those disks are disconnected from the computer or the disk requests time out (whichever is shorter). This may explain why some people will reboot Mac OS X 10.5 once, see a blue screen forever, reboot, then no longer have a blue screen. Disks usually start responded when they are disconnected or the system has to requery them (which happens on a reboot). In fact, I have a SATA to USB bridgeboard that thrusts Mac OS X 10.5 into a blue screen 90% of the time, regardless of which computer I test it on. Perhaps I should send this bridgeboard to Apple so they can make diskarb handle this situation better. Bad Network Devices. One or more of the loginwindow dependencies also query the network to see if it is up. If DHCP is on, it may also query DNS in order to see if your computer has a hostname (to display in the loginwindow, syslogd, in terminal prompts, and some other places. However, the default connection establishment timeout on Mac OS X is somewhere between 10 and 15 minutes. This means that, on shoddy networks, borked routers, or in otherwise weird networking situations, Mac OS X 10.5 may show a blue screen for up to 15 minutes if the network cannot be traversed. After the timeout is hit, an error is returned to the API and the Mac OS X 10.5 booting resumes normally. This would explain some of the reports of Mac OS X 10.5 taking 10 to 15 minutes to boot. I've personally seen this in a lot of hotels and conferences when the network was down or overwhelmed with requests. This is especially annoying when trying to compile code using xcodebuild as it uses NSHost to try to resolve the current domain name of your computer box even if distcc is disabled (which is considered a bug). It's extremely annoying when you want to compile something but have to wait for the 10-15 minute timeout to expire before anything will start compiling. Application Enhancer 2.5b1 and APE SDK 2.5b1As I was trying to explain in my previous post, APE 2.5 will not load any APE module that has not been explicitly marked as compatible with Mac OS X 10.5. See my previous post for reasons on why. We discussed the issue with some other APE Module developers and they agreed that old modules should be disabled. Especially since it's been over 2 and a half years since Mac OS X 10.4 was released and some of these APE Modules haven't been updated since then. If an APE module cannot be loaded, for whatever reason, the APE Preference Pane will now show the listing why it cannot be loaded. The APE Prefpane now uses the same logic to determine why something won't load as APE itself. Previously, APE itself would have a bunch of undocumented checks and there would be no way for a user to determine why their APE Module wasn't working. The SDK documentation has also been clarified to mention the APEBundleMessage callback is not called on the main thread. If you need to call functions that are not thread-safe, call them on the main thread using something like MPRemoteCall. Not doing so can lead to unexpected behaviours. It's been an issue in the past, which is why it is now explicitly documented. Also, the SDK documentation now has a listing of all the Info.plist keys available to APE Module developers as they were never documented before and some are required for an APE Module to be loaded.
So here are the download URLs for the betas, finally. Download APE 2.5b1 Smart Crash Reports 1.5b2I am repeating this as I find it to be very important. Important Note: On Mac OS X 10.5.x, InputManagers must not be installed in the user's home folder (~/Library/InputManagers/) as it will prevent the InputManager from loading even if the InputManager is installed globally in /Library/InputManagers/ and meets all the requirements to load. If you are a developer installing an InputManager, make sure your InputManager is not in the user's home folder on Mac OS X 10.5.x and move it to the trash (FSMoveObjectToTrashSync()) if possible.
Download Smart Crash Reports 1.5b2
FontCard 1.5.1b1 Please Note: FontCard 1.5.1b1 has not been "certified" for use with Adobe CS3 products (it should work, the worst that will happen is that it won't work). Furthermore, it does not work with Microsoft Office 2008 (the worst that could happen is explosive projectile vomiting). We have not yet acquired these products, therefore we have not tested them with FontCard. FontCard 1.5.x currently has a lot of code for Word v.X and Word 2004 to work around various "quirks" in Microsoft Office. I would not expect FontCard 1.5.1b1 to work with Microsoft Office 2008.
Menu Master 1.4.3b1 Also, Menu Master had to work around a lot of bugs in Mac OS X 10.4 with certain types of windows. Either the bugs were fixed for those certain types, or the bugs remain. Either way, Menu Master still does what is correct for all types of windows.
Silk 2.1.4b1
FruitMenu 3.7b1
WindowShade X 4.2b1
Final ThoughtsRemember, these are beta. All of these betas include SCR 1.5b2 and APE 2.5b1, so they do not have to be downloaded separately. APE 2.5b1 may also have some fixes for APE not enhancing some applications on Mac OS X 10.4.x in some cases. Note: We are currently evaluating raising the prices to some of our products. A number of factors contribute to this, including the weakness of the US dollar (I mean, seriously, funny money from Canadia is worth more than the USD). But if this happens, it'll only start to apply when these things go out of beta. The prices for these betas are the same as they have always been. The only change would occur when these things come out of beta and are at a final release. But seriously, Canadian funny money worth more? Sorry it took so dang long to post these, I've just been various amounts of "not well" for the last few weeks. Sigh, I wish I could ask various doctors on the internets for samples of the sweet blue pill known as Lunesta. Alternative title to this post was, "Dear APE, I want you inside me. Love, Leopard"
Pragmatic Disillusionment
I wanted to talk about the issues we experienced while running the currently released versions of some of our software products on Mac OS X 10.5. I think this will help people understand a decision we made regarding Mac OS X 10.5, which I'll discuss more about in a future post. This does not cover every problem we saw, just the ones that influenced our decision. This post only discusses the past, even though it may use present tense.  All Haxies (Except FontCard 1.5) Running on ICBMs (Both PrefPane and APE Module)In Mac OS X 10.5, Apple removed the x86 part of an important (and fully supported) library some of our products linked to. In Mac OS X 10.4.x on the ICBMs, this library was fat. On Mac OS X 10.5, it is not. This was never documented and never mentioned that it would not be fat in the future. We used this version of the library as we needed Mac OS X 10.3.x (or as it Mac OS X 10.2.x?) compatibility and the newer version of the library was not made available on those older versions of Mac OS X. We never switched to a newer version as the old version still worked on ICBMs on 10.4.x. A quick Google search shows we were are not the only ones bit by this undocumented and unexpected change. Back when Mac OS X 10.5 was still being seeded (long before its release), I filed a bug about the missing architecture and was told it was correct. I strongly disagree. This change means none of these products loaded on Mac OS X 10.5 due to dyld rejecting the binary because of linking issues. (Mac OS X does not load binary images if they do not link as of at least Mac OS X 10.3 and later, before the host application would crash). Note: The only reason FontCard 1.5 doesn't suffer from this problem is because FontCard 1.5 was released shortly before WWDC, and I needed it to load on Mac OS X 10.5 so I could ask some questions about then future directions in the font/text APIs at WWDC. Since FontCard 1.5 required Mac OS X 10.4 or later, I could safely use the new version of the library. I also did it because I wanted to file a bug on the extremely silly and useless dialog System Preferences shows when a preference pane cannot be loaded due to a dyld error, but I needed to make sure the Apple people ignoring the bug didn't think I was filing a duplicate bug on the missing fat library. Individual Haxies Running on PowerPC (with no changes, in no particular order)FontCard 1.5FontCard 1.5 mostly works on Mac OS X 10.5. The only significant issue is the that the Font Panel features that were new to FC 1.5 did not work. Nothing bad happened, the font panel was just not modificated. FontCard's error checking caught the Mac OS X 10.5 changes to the font panel and prevented Bad Things™ from happening. All the font menu stuff continued to work, including support for inactive fonts in third party font sets (which surprised me greatly). FruitMenu 3.6.4FruitMenu 3.6.4 mostly works with no serious issues. The only thing that doesn't work is the contextual menu modifications since Apple significantly changed how CMMs are handled on Mac OS X 10.5. I strongly agree with the changes Apple made with regard to CMMs as FruitMenu was often pointed to as a cause of a crash when a buggy CMM was installed. Luckily, the Finder was also blamed for buggy CMMs even if FruitMenu was never installed, so Apple changed the behaviour of CMMs so the Finder would get less blame. Also, loading some CMMs every time on a right click could be a significant performance hit, even if the user never intended to use the CMMs during that click. Surprisingly, click and hold to show the contextual menu in the Finder still works. Another problem FruitMenu 3.6.4 has on Mac OS X 10.5 is disk operation speed. Mac OS X 10.5 significantly changed disk I/O. It is now low-priority in many cases and doesn't hit the UBC as hard as it used to. I'm not yet sure if either of these changes are good. The end result on FruitMenu is that if you have a large number of items in your Apple menu and you have hot key scanning on, application launches can take significantly longer on Mac OS X 10.5 than they did on Mac OS X 10.4 since the result of the disk operation isn't as aggressively cached as it was before. This becomes an even more significant problem if a Time Machine backup operation is running while you launch an application, as FruitMenu cannot get the results of its disk queries as quickly (Time Machine eats the bandwidth, especially if you use the craptacular and extremely Time Machine unfriendly Mail.app). Labels X 1.8.2Let's just say, "Uhm... no...". Labels X works mostly in Cocoa Open/Save dialogs on Mac OS X 10.5, but almost no where else. It does not work in the Finder. Menu Master 1.4.2Surprisingly just about every feature in Menu Master 1.4.2 works in Mac OS X 10.5. Even more surprising was that Menu Accelerator works. This is surprising because the menu accelerator feature had to work around a huge number of bugs in Mac OS X 10.4. So either the bugs were not fixed in Mac OS X 10.5 or the Menu Master fallback path (in case the bugs were ever fixed) works. I'm guessing it's a mix of the two. However, custom hot keys on Menu Extras do not work. This is due to a change in the Cocoa wrapper around menu items (all menus are Carbon menus, even in 64-bit) that Menu Master did not expect. This causes Menu Master to be unable to find menu items in menu extras, thus causing misidentification. This only applies to status items and menu extras (which are subviews of one large Status Item). There is actually one thing that works better in Mac OS X 10.5 with regard to Menu Master. I had been begging for years for the Menu Manager to support changing the width of menu items while the menu is open. Mac OS X 10.5 brings this feature to the table. This means when a new shortcut is set to a menu item, the system will no longer cut off the text and draw "…" until the menu is reopened. Yes, this is an extremely minor thing, but it's something I've longed for. Yay! ShapeShifter 2.5Also, "Uhm... no..." ShapeShifter 2.5 was always designed to not load on Mac OS X 10.5 to prevent any possible compatibility issues. However, this has an amusing result on Mac OS X 10.5. ShapeShifter 2.5 correctly does not do anything on Mac OS X 10.5. However, if you upgrade to Mac OS X 10.5.1 or Mac OS X 10.5.2 after installing a previous version of Mac OS X 10.5, ShapeShifter will warn you about having an out of date guiKit cache. And then it will correctly refuse to load. This is amusing because it's not possible to upgrade your guiKit cache on Mac OS X 10.5, since ShapeShifter won't load. A second problem is that the ShapeShifter 2.5 Preference Pane crashes a few seconds after load on Mac OS X 10.5. Silk 2.1.3Silk 2.1.3 mostly does not work in Mac OS X 10.5, therefore it is an "Uhm... no...". It will work in some places, but won't work in others. It's behaviour in the Finder is very mixed. A few Carbon applications (Finder, iTunes) on 10.5 ask for an undocumented ScriptCode (126, iirc) using GetThemeFont() when opening certain modal dialogs and this makes Silk crash. Luckily, Silk 2.1.3 does not crash at any time before a modal dialog is opened. WindowShade X 4.1.2This is also kind of an "Uhm... no...". WindowShade 4.1.2 will not load on Mac OS X 10.5 due to a linker (dyld) error because of a missing symbol. Xounds 2.4(.1)Xounds 2.4(.1) (2.4.1 was sent to some users, but never officially released due to what some other users perceived to be a significant bug) is a big freakin' loud, "Uhm... no...". It is the definition of "Uhm... no...". Let's just say that Xounds 2.4(.1) does not like Mac OS X 10.5. In any way, shape, or form. Especially the Xounds daemon. I'm sure you can imagine how bad something can be. Well, Xounds 2.4(.1) on Mac OS X 10.5 was that kind of bad. Other Non-Haxie stuffUnsanity Installer 3.6.1The Unsanity Installer is the application we wrote to install the majority of our stuff that requires an installer. We also allow third-parties to freely use the Unsanity Installer for their own products. It really doesn't have very many features other than what we at Unsanity need it to have. (That is, we do not accept feature requests as it is not meant to be a multi-purpose installer). Anywho, Mac OS X 10.5 introduces something called "File Quarantine" and "File quarantine" (copied from the Windows XP SP2 feature). This feature shows a dialog whenever you launch a file that was downloaded from the Internets or launch an application that is on a disk image that was downloaded from the Internets. This quarantine attribute is stored in the metadata of the file. When the file is copied, the quarantine metadata gets copied with the file as well. And thus, we have our problem. The Unsanity Installer explicitly tries to save all metadata on the files it is installing. Sadly, this includes the quarantine metadata. This becomes a super annoying issue for the user as they first see a quarantine dialog when the launch the installer, and then see another quarantine dialog whenever they launch (directly or indirectly) an application that was installed by the installer. Since the Unsanity Updater application was installed by the installer, the user would see a quarantine warning about the Updater when it was launched as part of automatic update checks. A second problem is the Smart Crash Reports plugin used in the installer suffers from the linker problem mentioned above on Mac OS X 10.5 and will not load (which is a moot point, as SCR 1.2.1 doesn't load on Mac OS X 10.5). InputManagers:Smart Crash Reports 1.2.1 and Menu Extra Enabler 1.0.3Smart Crash Reports 1.2.1 was always designed from the get-go to not load on Mac OS X 10.5. Other than MEE and SCR, we do not produce any InputManagers. None of our other stuff uses the InputManager technology, and thus, are not restricted by the limitations imposed and/or inherent to InputManagers. That said, Mac OS X 10.5 brings a whole slew of ultimately useless restrictions. Note that not all of the restrictions listed are actually required or true. However, neither MEE nor SCR are installed in a manner that matches the true and required restrictions. This means they will not load in Mac OS X 10.5. They won't even get a chance to decide they don't want to load. If Menu Extra Enabler 1.0.3 meets all the true restrictions, it will load and will work without any problems. In fact, some third parties are already shipping MEE 1.0.3 with their products and it works just super and jim dandy-like. Important Note: On Mac OS X 10.5.x, InputManagers must not be installed in the user's home folder (~/Library/InputManagers/) as it will prevent the InputManager from loading even if the InputManager is installed globally in /Library/InputManagers/ and meets all the requirements to load. If you are a developer installing an InputManager, make sure your InputManager is not in the user's home folder on Mac OS X 10.5.x and move it to the trash (FSMoveObjectToTrashSync()) if possible. Final ThoughtsWith all that said, I hope this helps to elaborate a little about the decision we made regarding Mac OS X 10.5 that I will discuss in a future post. *The above image is courtesy Chilton Webb. Used with his permission. Well, I asked his permission to use the photo for a yet to-be-determined blog post about 2 years ago. He said, "ok", but I do not know if he remembers this permission giving. So, try SuperCard or something. |
Archives
August 2008
February 2008 November 2007 October 2007 July 2007 May 2007 April 2007 March 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 January 2003 December 2002 November 2002 October 2002 September 2002
Recent Entries
Purified Chicken Embryo Cell, The VUF, and Menu Master Beta
New Releases: APE 2.5, SCR 1.5, FruitMenu 3.7 Dear APE, I want you inside me. Love, Leopard #2: APE 2.5b2 Enthusiastic Trepidation Pragmatic Disillusionment Apple Punishes Those That File Bugs on Their Precious Leopard Leopard! Smart Crash Reports: 300! FontCard 1.5b2: FAP, FEX, and Suitcase Fusion My DMG is Bwoken After Download!
Most Popular Articles
Search
About...
Syndication
Disclaimer
Views and opinions expressed on this site are personal views and opinions of members of Unsanity LLC. They do not necessarily coincide with the official company views and opinions.
| |||||||||||||||||||||||||||||||||||||||||||||||||
Posted by rosyna at