Comment Spam Again: Missing MT-Blacklist

We recently upgraded to MovableType 3.3.1 because it fixed a bug that was causing the base name of an entry to get a number appended to it every time it was edited. This was very annoying. Sadly, with the upgrade, we've lost MT-Blacklist. I loved MT-Blacklist. MT-Blacklist had these features I loved:

1. It automatically held comments and trackbacks for moderation when a post was XX days old. If a post became popular again, it would publish everything for YY days again.
2. If a comment contained a naughty spam word, the person that submitted the comment would be told exactly what word was naughty so they could change the word and get their comment published. We have a huge list of naughty words, phrases, and domains a lot of spammers use.
3. Every single comment that was posted here that didn't have contents on the naughty list was emailed to us. As it stands now, comments being marked as junk aren't being emailed to use. There are currently 7446 junked comments I need to sort through...
4. MT-Blacklist never let a comment be ignored. I liked this as it meant all feedback was read. Due to the way MT Spam Lookup works, the lovely Drew Thaler's comments are always being junked because he loves using naughty words.
5. MT-Blacklist also showed how many times a particular entry in the naughty words list was "hit". This allowed us to remove one-time entries.
6. If a comment/trackback wasn't corrected, it wasn't even added to our server. It was completely and utterly obliterated. I liked this.

Is there anything like MT-Blacklist that can hopefully use the wordlist we've created and tell the user that submitted the comment what word(s) were naughty so they could correct them? Right now we are using Spam Lookup but it doesn't tell the user (or us) that their comment is junked and being held for moderation. Which is really quite depressing. Spam Lookup also doesn't let me set "naughty" words if these words appear in the name or email field of the comments. Some spammers always use variations of the same name. Even worse, Spam Lookup is publishing these evil spam comments so they appear on our blog until one of us can smite the evil.

I miss MT-Blacklist. The only thing I wish MT-Blacklist had (other than working with MT 3.3) was a known bad hosts lookup. Before when we have MT-Blacklist installed it took over for all the comment/trackback moderation so the SpamLookup stuff never had a chance to see if the host was an evil possessed zombie back from the dead (running Windows) for revenge on the Internets community on the blogosphere.

Yes, we are using Blacklist Connector for MT 3.2 but that doesn't tell the user why their comment was junked, nor does it allow them to edit the comment so it isn't naughty. Even worse, it doesn't email us these comments nor does it mark how many hits the naughty words in the naughty word lists get.

WindowShade X 4.1b2

While we are working on the Rosetta applications fix in the Application Enhancer, here is a newer public beta version of WindowShade X:

http://unsanity.net/beta/windowshade-x-41b2.dmg

• When clicking on the application icon in the Dock, and all of the application windows are minimized in place or collapsed, one will be expanded by WindowShade X to prevent confusion.
• Fixed a bug that made Firefox windows unclickable after window shading.
• Fixed an issue with WindowShade X not working correctly with some Java applications.
• Many other smaller fixes.
• Includes Application Enhancer 2.0.2b2 (this one fixes the Java issue mentioned above).

This build still has some minor issues, but overall we recommend using it over the 4.0.3b1 posted earlier. Thank you for your support! I'll keep you posted on the progress.

As usual, don't publish this on update sites, this is a beta, yadda yadda. =)

Desktop Wars

Nope, we're not talking about Linux vs. Windows vs. Mac, we're talking about your Desktop. Yeah, that spot you keep nearly everything on your computer. Enough icons to make the Desktop picture you have there near indistinguishable!

Well, what if you could put that place to use!? (or um, rather useless...)

Introducing the only MyDreamApp entry I'm likely to blog about: Desktop Wars

Check it out, comment, tell my brother how dumb the idea is. Even better, tell him how to make it better and let's get this sucker made! Seriously, I'd love to see this in action... I'd love to see some Lanham created soldiers/creeps battle it out for control of my desktop!

Press Zero For Operator

We all know and love the voice phone menus -- they seem to be everywhere nowdays:

"If you are already our client and wish to inquire about our services, press 1. If you wish to become a client, press 2. If you only speak French, press 3. If you want to kill yourself after listening to all these options (and you know Japanese), press 4."

The good thing is that the best solution is spam 0 at all times, and in most cases that will get you to a real live person (there's an entire site dedicated to that). Either way, the reason I am writing this is a bit different.

I barely escaped a car accident today while returning with my wife and son from Peterhof. Two cars hit into each other on the oncoming lane, and one went flying towards our lanes. I managed to brake out of it, and the unfortunate lady on the Mazda to my right didn't, so it quickly became a 3 car accident instead of 2 car accident. And, as usually happens, the most injured part was the one not involved in the original collision. I parked my car to the side of the road and rushed over to the other car to see if they need any help (not that I know anything about the medicine, even though I am a PhD ;) - primarily, maybe call the ambulance since the parties in the crashed cars would likely be too occupied for a bit to call themselves.

So I took my cell phone and tried to call 03. A quick information on Russian emergency services: we dial 01 for fire dept, 02 for militia (police), 03 for ambulance/ER. Recently, however, there has been a notion to get away from that set of numbers that we were used to for the entire existence of the phone system in this country, in favor of 112, a universal number used through Europe (akin to 911 in the States). In a few years, 01/02/03 numbers will no longer work when you use the landline phones, and 112 will instead.

Either way, someone on the cell network I use have decided that it's time to convert people to 112 now (I realize 112 is a standard GSM emergency number, but 01-02-03 used to work before).

I rushed towards the closest car, dialling 03 on my phone to get to ER. Sadly, all I got was a beep and no answer. I redialled just to notice a text message that flashed on my phone: "For emergency, please use 112". Crap, fine. So I dialled 112.

What would you expect less on an emergency number that is supposed to aid you in urgent, out of control situations? Right, a voice phone menu.

"Please make sure your phone is in tone mode, and dial the number appropriate for your emergency situation: 1 for the fire department, 2 for militia, 3 for ER, 5 to access the paid advisory system."

Ugh? I just don't get why in the world would you need to listen to the voice menu when dialling an emergency number. Let's pretend you're badly injured but you did managed to dial 112 (after all, it's fairly easy to tap on the phone even if you're not conscious enough). But then to get somewhere, you have to listen to the options and tap more buttons - how stupid is that?

Thankfully, nobody died in this particular accident, as far as I know. But getting through voice menus just to get to ER is ridiculous. Get a clue, Megafon. ;)

Ordering Memory for a Portable ICBM

So I finally ordered a 17-inch portable ICBM. I couldn't order it while I was at WWDC because I didn't want to take two 17-inch laptops home (the new ICBM and my original PowerBook). Now, everyone knows that you should never order extra memory from Apple, as they charge way too much. I usually order memory from 18004Memory, however, they either sold or gave my email address to spammers. I won't support companies that give my email address to spammers.

So where should I order the memory? I'm looking at OptiVAL memory, but I've never ordered from them before and I haven't really heard much about them. I've never been one of those to believe the entire "buy the most expensive memory" mantra as often the memory is manufactured from the same place and many companies (like Crucial) seem to artificially inflate their memory prices when they know they are dealing with a Mac user, even when it is the exact same part. I'm most interested in hearing from people that have had memory fail. It's not that I want to avoid the companies with failed memory modules, I want to know how hard it was to get a replacement for no additional cost.

Apple is known for making computers with extraordinarily strict RAM requirements and they have released firmware updates that have caused the requirements to get event stricter. So it's very important to know how these RAM companies handle replacements. I originally started using 18004Memory because they offered free replacements when Apple released the first such firmware update. But of course, they're no longer a suitable candidate.

So yeah, where do people out there in the land of the internets buy their ICBM (Core Duo) memory?

Russian Only, Sorry

Sorry, I've been bored in the plane to SF. Also, I am not going to translate this, as it is untranslatable for number of reasons.

This said, you probably can safely ignore this entry. ;D

---

В который раз он шептал ее имя, и в который раз она приходила к нему. Её волосы, развеваясь, напоминали птиц, что он привык видеть каждый день вокруг себя.

Он знал, что она не для него. Он также знал, что она не может не придти, когда он зовет ее. Они были частью одного целого, безупречно отлаженного механизма, который работал уже давно, и не в их власти было что-либо менять.

Он задумчиво смотрел на нее, и она улыбалась уголками губ - тихонько, только для него. Им очень хотелось хотя бы прикоснуться друг к другу пальцами рук - но было еще не время. Да и знали они, что их время не настанет никогда.

Он не знал, что он чувствует к ней. Она же лишь загадочно смотрела на него, и выражение ее глаз было для него загадкой, как и в первый раз. Случайные свидетели их встреч тихонько стояли рядом, не решаясь случайным движением или звуком нарушить эту странную тишину.

Потом она неспешно одевала капюшон, перехватывала косу поудобнее, и исчезала далее по своим делам, а он, вздохнув, брал весло, согнав задремавшую на нем ворону, и заново начинал свой путь через реку с новым попутчиком.

---

Oh, my WWDC impressions? I'll post later. ;D

Whootie WWDC Whoo!

Unsanity is going to be heading to lovely pure-evil San Francisco for the next week for the always popular, always fun, and hopefully completely unsane WWDC. If you're a dev who's going to be there, or you just live in SF and you'd like to hang out, that'd be just totally spifftacular with us. We especially like it when you buy us beers!

I'm not going to make any predictions for the keynote because, well, I just don't care, and, I like to be surprised and if I think about it too much in advance, I won't be. So, come what may, I'm sure I'll enjoy it. As long as Apple doesn't release an iPhone since I just bought an SE w810i last week.

Instead, I'll go for predictions on what band will be playing the Apple Campus Bash. Panic! at the Disco. At least, that's what I hope.

Anyway, hope you guys enjoy the rumors as much as we enjoy sitting in cold rooms with sweaty bearded salivating geeks!

And, hopefully, we'll be able to fix the APE Rosetta bug while all of our brains are in the same physical location, too!

Developers! Developers! Developers! Developers!, Caring For: Microsoft vs Apple

Notice: This post is incredibly long. 22 pages long. And this entry may offend some people. Especially those that are religious, easily offended, have active imaginations, or find offense in things that are not inherently offensive because they have a really dirty mind but don't want to admit it. Anyone that fits this description should stop reading now as you're just going to complain. Instead, I suggest stepping away from the computer and curling up with a good book. This post should be rated "mature" for strong language and graphic imagery… or something like that.

My point of this entire entry is to point out some of the areas where Apple's communication with third party developers could use some improvement. There are some areas where Apple absolutely excels like their public mailing lists. And some where Apple could take some cues from Microsoft, such as bug reporting and hardware support. While I may complain about Apple a lot, please realize that I still believe that Apple is bar-none the best computer company and they have hands-down the best operating system to develop applications for. And I don't think that anyone is making a mistake by purchasing a Mac. Especially since Macs are usually the best choice for the job whether it be because of software Apple or a third party made.

Also, remember that anything you find offensive does not represent the views of Unsanity. They are my views and my personal opinions based on my personal observations. Dislike me because of them if you so desire.

[Digg This] (but comment here).

The sad thing about this entire troll rant informative article is that I've been working on this off and on for two months. Most of the delay has been due to other priorities or researching things for this article. I really wanted to order a 17-inch portable ICBM when I finished with this post. However, it is now too close to WWDC and there's no way it would ship to me before then. I can't buy one at the Apple store either because the Apple store doesn't accept/offer the developer hardware discount. So now I'll be going to WWDC with a laptop that has a busted shift key, among other problems (read the Support:Hardware section below).

Due to the sheer length of this post and the fact that most people won't read the entire thing due to its length, I've written this thing in sections. Each section has a header and sub-headers. You can easily use these to skip to the portions that may interest or amuse you. But please, please, do not read the "Suggestions to Apple" sections without reading the entire section they pertain to. The suggestions to Apple sections are written to be completely in context and are not standalone.

With that said, I really wanted to post this before WWDC. I didn't want people to get the impression I was simply being reactionary to something that just happened. I can also be reactionary to stuff that happened well over a year ago. So there!. I make quite a few comparisons to Microsoft's developer relations in this post. While I have been a member of Apple Developer Connection for over 7 years, I have very little experience with Microsoft's developer stuff. What I do know about it I've only learned by browsing Microsoft's website. However, if I get anything wrong about either, please correct me. The things I say about Apple's various developer programs are based primarily on my own personal experience and may not be anywhere near what other people may experience. And no, I don't actually expect anyone from Apple or Microsoft to ever read this post. This blog just isn't that famous (or infamous).

It's All in the Family or There's Nothing we can't Face… Except for Bunnies

The entire Macintosh development community is like a huge family with the Apple software engineers (née programmers) being the nuclear family. Whereas some unnamed (*wink*) small third party developers are treated more like that weird relative that shows up at family reunions. The other family members all avoid this person due to the vicious rumor that they only come to the family reunions to flirt with and try to pick up the other family members. Even though no one in the family has actually seen me talk to the other family members, they still avoid this person. The avoidance only fuels and gives credence to the rumors. "See, they're all alone over there because they keep hitting on their own family members." It becomes horrible cycle of rumors with not a single person actually witnessing the event. I guess the same goes for repairing permissions. MacFixIt started the rumor, which got passed around the Mac "technical" community. And each time it was told from one person to another it was changed ever so slightly to make the person listening more likely to believe it. Purple Monkey Dishwasher. The anecdote made a full circle back to MacFixIt eventually and they used this as "proof" of what they were saying was true. Even though they're the ones that said it in the first place!

Hmm. Incest>Repairing Permissions>Sheep>MacFixIt. Something is missing. Usually whenever I am involved in or start a conversation implicitly or explicitly mentioning incest it eventually ends up that I start talking about the awesomely awesome awesomeness that is the CoreText API. I wonder what happened this time. The only reason incest comes up "often" is because I am extremely interested in the battle/opposition between things inherent to the system (genetics) and acquired knowledge (mind) and things such as GSA and the Westermarck effect are good examples of this battle in play. It is also why the idea of genetic memory interests me so. This battle really makes me hope the children of Britney and Cletus can overcome their genetics. If humans have any kind of genetic memory, it would better explain those that believe they were someone else in a "former life". Then again, if the ancient Egyptian rulers really were Goa'uld, that'd explain that genetic memory if they interbred with humans. Ack, ok, I need to stop there. I've gone from Incest to Repairing Permissions to Sheep to MacFixIt to Britney Spears to the Goa'uld.

My conversations usually flow like this though. Someone will be arguing about the object-oriented nature of C++. This leads to a conversation about pig-farming which then leads to a conversation talking about how someone has been repeatedly impaled in the foot with pitchforks or repeatedly stepped on nails. Actually, I guess the transition from C++ to "nail in foot" is actually quite logical. A better example would be someone talking about the recent incident in which a Dell laptop caught on fire leading to someone asking if the placenta is acceptable food for vegans. This is actually a rational flow of conversation. Can you guess how?

Okay, I really did have a point to all of this. Namely that the entire Mac development community is like a family. Each developer is not completely estranged from one another. Most Mac developers are extremely approachable. In fact, many of them will give other developers help. This goes double for Apple software engineers. The far majority of them are very nice, helpful, and all-around good people. Although there are a few that constantly curse. Almost as if every other word is a curse word. It's not directed at anyone so there's no need to be personally offended. It's just that they've likely been dealing with C++ for so long that they don't even realize they are cursing at all. This is yet another reason I love going to WWDC. (The direct communication, not the cursing.) I can talk to fellow developers and don't have to worry about filtering marketing-speak (such as various forms of the word "productize"). Heck monkey, even Steve Jobs keeps the marketing-speak in the WWDC Keynote to a minimum (but only compared to his other keynotes and speeches) I am definitely not saying that the same isn't true for Microsoft employees. The ones I've had contact with have been extremely nice. However, being primarily a Mac developer, I have no idea what avenues to explore when I would like to talk to a Windows developer. Then again, I often have no need to contact them. But it is nice when the option is there.

Communication is Key or "It's a Feature, not a Bug. So STFU"

Lists and Forums

That brings me to my next point: Developer Communication. This is also where the post gets a little more negative. The kind of negativity I am known and loved for... Apple has excellent and fabulous mailing lists developers can subscribe to to get answers to various questions or answer questions other developers have. Many of these lists have active involvement by Apple employees (and most often this is on their free time, to boot). Microsoft, on the other hand, has MSDN Newsgroups. Some of these newsgroups require a paid membership to access, however they have guaranteed responses. Personally, I loathe newsgroups. For one, there is the massive spam problem mentioned on that page. Secondly, the majority of Mac newsgroup clients appear to be designed for sex-perverts and do not appear to have discussions as a primary feature. Microsoft also has something called MSDN Forums. I hope Apple never goes this way. There is one exception which I'll mention later. It's extremely difficult to search online forums if you do not have internet access. With Apple's mailing list, each post gets saved directly to my hard drive and is searchable anywhere, whether it be on a plane or whether it be under the sea. Furthermore, Apple is known for deleting posts (last line) that say negative things about Apple. Developers in general (such as LH, RK, and MC) are extremely negative by nature when something doesn't work. Their negativity does not hamper their helpfulness at all, it would just be something Apple Corporate probably wouldn't like and would strike from the record.

Granted, I've never used the Microsoft side of things, but just because Apple and Microsoft have means for developers to ask the community for help does not mean you'll get an answer. In fact, there is no guarantee (from Apple at least) that the posts will even be read. Some of the more "technical" questions I've asked in the past have gone completely unanswered. There are some very, very noticeable surprises, however. Sadly, most of the font-related questions I have go completely unanswered as well. No matter who I ask.

Some of the mailing lists Apple hosts have a list mom that have a no tolerance policy to off-topic posts. By off-topic I mean things like asking about something on the BSD level on a mailing list dedicated to CD Burning or asking about the best way to communicate something, such as an error, to a user. I don't mean completely off-topic like talking about politics or religion, which isn't tolerated on any list. A notable exception is asking how to convert a Muslim calendar date to a Buddhist Calendar date. The tolerance level varies greatly between lists. On some lists, the list mom will complain if there's anything even remotely off-topic. Some "odd" list moms won't even allow asking about determining if a IOKit device reference belongs to a writable CD drive on a CD Burning mailing list, referring you to the IOKit mailing list.

The complaint usually involves an email about how you're spamming the list and to take it elsewhere with no actual suggestion on the elsewhere to take it. Then another email follows almost monthly making an assertion that off-topic posters waste hundreds of dollars for each off-topic post they make. Not sure what marketing school that train of thought is from (probably the same school of marketing that says college students are responsible for seven bajillion dollars of lost sales due to music piracy), but whatever. Especially considering that almost everyone gets tens to hundreds of maliciously sent real spam emails a day. One or two off-topic posts is barely a dent. The only exception for allowed off-topic posts on this particular list is saying positive things about the list mom's day job. If it is negative, you're told to contact Apple off-list.

Granted, I may be taking it just a little bit personal and may be just a little bit spoiled by other lists. For example, one of the mailing lists tolerates almost anything off-topic, assuming it relates to the Mac OS. I really like this method as it allows angry developers to blow off a little steam in a mostly constructive manner especially since other developers chime-in and describe how they have worked around the issue or how they've dealt with it. Then the topic usually never comes up again as everything that could be said about it has been said. In which case, they're just pointed to the list archives. I guess in these cases you're either seeing the same off-topic subject brought up 10 times with 2 posts each (one for the beginning, one for the end of thread notice), or you have it brought up once with 15 posts. Still other times these off-topic threads result in a "mass" of bugs being found in the system when they may not have otherwise been found. However, I've only seen the latter actually once. It is by no means the norm.

Suggestions to Apple: Stay the course. I currently like the mailing list system a lot and find it far more accessible than the forum or newsgroup system. The Apple employees that frequent the mailing lists are usually responsive (except when it comes to fonts...) for most people. And I have nothing but absolute and utter respect for them and I owe them quite a lot. They make the mailing lists extremely nice. My policy is not to name names for good things people do, so I'll give them all hugs at WWDC or teach them never to look the same way at soft-boiled eggs again or something.

I'd guess it'd be super-swell if some mailing lists had less "pissy" list moms, but as I stated above, the perception I have of these list moms may be entirely subjective and based on personal experience. One thing that I seem to remember about the MSDN Forums is that they have employees of each group lurk the forums and respond to any unanswered questions. Apple could benefit from such a policy on some lists.

Bugs: Microsoft

That was a very long and unexpected rant. Somehow I think it can only get worse. Here's something I can directly compare between Apple and Microsoft: bug reporting. Microsoft has recently opened up a website for bug reporting and participating in general development software testing/development. I do find it odd that Microsoft's new developer site is at connect.microsoft.com, while Apple's developer account management and seed download site is at connect.apple.com. Awfully similar subdomains... Microsoft's is around a year old, Apple's is at least seven years old.

Anywho, Microsoft's Connect allows users/developers to file bugs on software they are participating in the development of. Pirates are not permitted to file bugs on beta software (such as Vista) using this channel. If you haven't joined a product program, you get the default options for filing bugs on products currently out of beta that were released around the debut of the Microsoft Connect site such as SQL Server 2005 and Visual Studio 2005. If a product was released before that, I have no idea how to report a bug. Some people seem to largely imply it isn't possible unless you're a super special customer.

Assuming that the product is available to the public on Microsoft Connect, their bug reporting is very interesting. Basically, you click on the product you wish to report feedback on from the "Available Connections" link, search for the pre-existence of the feedback (which is a nice touch), and, if no results are found, file a new bug report.

Let's go back to the search for a second. Microsoft actually allows you to search all existing bug reports for an "available connection" (does MS have to have marketing come up with names for everything?) that were not explicitly marked as private by the reporter of the bug. I think that's extremely awesomely awesome. For example, this bug or this bug in Visual Studio 2005. I chose both for the amount of comments and the fact they were still open. But as you can see, both have public comments from the creator and public comments from Microsoft. The creator of the bug in the former actually got quite livid. I appreciate this a lot.

The point is, not only can the reporter of the bug clearly see feedback on the bug, the general public can as well. For programs (like Vista) that are not available to the public, anyone that is a member of the program can also view all bugs marked as public for that program. Someone actually made some pretty graphs based on the public bug data for Windows Vista. How sweet is that? Although it does show a slight case of major OCD. Oh well.

Filing bugs using Microsoft Connect is free. Presumedly, as are all the program memberships that are offered via Microsoft Connect. However, membership in the betas require either an invitation of some sort or you need to request membership via a link on the Available Connections page. In order to login to Microsoft Connect, you need a Windows Live ID, which is free. It was formally called Microsoft Passport but appears to be have been renamed by marketing to distance it from the failed "single sign-in" idea that Microsoft originally planned Passport to be. However, a Windows Live ID will sign you into almost all sections of Microsoft's website that require a free sign-in.

Bugs: Apple

For the love of all things holy in this world and the next, if you're not a developer or just filing a general feedback item on an Apple product, use the Mac OS X feedback form (which also has links to the feedback forms of other products).

Now, on the other sad hand, we have Apple's bug reporter which has two advantages over Microsoft's: it covers all products Apple makes and has been around much, much longer. In order to sign into Apple's bug reporter, you must have an ADC Account. The online account is free and can be had by going to the ADC Member Site. If you have a .Mac account, you can login using your .Mac email address and password. ADC will then ask you if you wish to join using that account. Otherwise, you can click "Join Now" to create a new account. The ADC Member login can be used every where on Apple's site. From the online discussion forum to the iTunes Music Store. Once you have an ADC Member login, head on over to Apple's RadarWeb website (also called the Apple Bug Reporter).

Once you have an account and have logged into RadarWeb, just click on the "New Problem" link near the top. Filing a bug is pretty straightforward. The hardest part is choosing the component. Like, if it's an iTunes or iChat bug, do you choose "iApps" or "Mac OS X"? It's all pretty ambiguous once you get down to it. Either way there are about 50 brazilian components in Mac OS X and choosing "Mac OS X" doesn't exacly narrow it down. I've started prefixing my bugs with the title of the component such as "Fez", "Finder", or "Processes.i" depending on the component I think the bug belongs to (I am often wrong, which probably makes the limited choice of components a good thing). It really, really, really, really helps if you can upload a simple Xcode project that clearly shows the problem in the smallest amount of code possible if this is an API bug. Apple allows files up to 50 megs to be uploaded along with a the bug report. Microsoft allows up to 200 megs. But I don't think that really matters.

Bugs: Apple, Feedback (or lack thereof)

Once a bug is filed, the happy people at devbugs (or something) shift through the bugs and actually forward them to the correct team/component... or so the rumors on the Internets go. You will likely never see any kind of feedback whatsoever for most bugs other than "Behaves Correctly, STFU" or "Duplicate". If there is any feedback required, the feedback from the Apple software engineer first goes through a DTS/devbugs "filter" to remove excessive profanity, changes internal references to external ones (e.g. "MacBuddy" to "Setup Assistant") and to clean it up for the person reporting the bug. Unlike Microsoft Connect, the person reporting the bug doesn't get to see any comments from the people working on fixing and/or ignoring the bug at Apple unless their feedback is marked as "public" and goes through said filter. So if you get a reply as completely clueless as "There's no way to track files as they move," do not blame the messenger. The name you see on the email you get saying you received feedback from engineering on the issue is not the name of the person that sent the feedback.

You will not get any additional feedback about a bug if it is marked as "duplicate". You won't likely even be told the problem ID of the bug it duplicates. Furthermore, after some amount of time duplicate and closed bugs are removed from "My Originated Problems" so if you have a bug you want to check the status of, there will no longer be any way for you to get the radar number of the bug you filed using the resources you have direct access to. You may be able to get the status of the original bug or find the long lost problem ID if you email devbugs (email address near the bottom). However, this method has been a pure crapshoot for me. Sometimes it works, sometimes it doesn't. On the other hand, Microsoft Connect links to the original bug and duplicates of the bug for "anyone" to view.

This disappearing bug problem has become a huge issue for me, personally. When I log into RadarWeb and click "My Reported Problems" I only see 123 bugs listed. I've filed way more than that. If that number scares you, realize that most of those bugs were documentation bugs, font bugs, feature requests, me intentionally filing a duplicate bug, or me being dumb. And sometimes I swear I've filed a bug before but have no record of it whatsoever because it "fell off" the listing. Some of these bugs that disappeared I'd really, really like to know the current status of them like that bluetooth menu extra bug (since I spent so much time reversing the problem). There doesn't appear to be a consistent rhyme or reason why some bugs disappear. Some have speculated that closed bugs disappear after an amount of time, say six months. However, I've got some closed bugs that I've filed six years ago that I can still view.

Notice how I said I have intentionally filed duplicate bugs there? According to various people in Apple and other people, bugs/feature requests/whatever are assigned a priority of sorts based on how many duplicates there are. For example, if a thousand people file a bug requesting a CFLog() function, then it is more likely that a CFLog() function will actually appear. (I do think that there have been over a thousand requests for that function but it still isn't public as of Mac OS X 10.4.7.) However, as I just implied, more duplicates do not mean any particular thing is going to change. Especially when it's a management decision from on high that they have no intention on changing (see Metal). It's up to the person in charge of the component to escalate it. Oh well, I've been told to file bugs even if they're duplicates so I will continue to do so unless someone tells me otherwise. And since there's no search mechanism even for your own bugs, you have no way to tell if a bug is going to be a duplicate unless you were told so beforehand.

A good example of people using the "power of duplicate reporting" for evil is the Mac Maintenance Quick Assist document. When it was first brought to my attention, I was pissed off at its very existence for some odd reason. Much like the reaction to Technote 2034, mine was initially overblown to the Quick Assist document. So I waited five minutes and took some deep breaths, then filed my bug. I tried to be calm and mention point by point what I disagreed with. A lot of other developers did as well (either by filing a bug on the "Documentation" component or by clicking on the feedback link in the article). Amazingly, just a few days later the article was updated. Although sadly it still recommends the useless virus option and for some reason says "make a backup and delete the original". If you have only one copy of something, it isn't a backup, is it? Oddly enough, the bug I filed is still marked as being open. However, I guess that my particular bug had nothing to do with the change.

Now, let's say that you've filed a bug and/or feature request that wasn't marked as a duplicate or closed as "Behaves Correctly, STFU" as odd as that may be. In the rare case someone at Apple makes a comment on your bug such as, "your callbacks are wrong. Correct them and it works as documented," and the comment is marked as external (sometimes engineers write comments meant to be external but forget to mark them as such), then you'll probably get an email from devbugs saying that they have received feedback from engineering on your bug. A relatively recent addition to RadarWeb is the fact it also marks in red and bolds any bugs that have such feedback. Usually, I've received an email at the same time this reddening has happened. Other times, if the bug is left for red too long without being read then devbugs will fire off the email. I guess it'd be better if Apple put the bugs that needed attention at the very top of the bug listing in a section above your filed bugs since it may not be noticed if it isn't on the first page of the bug listing. Perhaps I should file a bug requesting that...

After you've made a comment on the bug in response to Apple's external comment, even if your comment is just, "OMGWTFBBQ?! I'm such an idiot," it'll either be closed, if it was resolved but waiting for your comment to confirm closure, or engineering will get your comment and proceed from there. Run on. There have been a few bugs in which I have had multiple back-and-forths with Apple. Perhaps two like that out of the 119+ I've filed.

The almost complete lack of communication from Apple on bugs has other issues as well. Sometimes bugs can be marked open for many many months because they are fixed in an upcoming software release. Perhaps they are marked as resolved in Radar. However, since Apple is so freaking secretive, they won't tell you anything until you personally have access to the release that fixes it either via a seed release or because the update was released to the public. Once you do get access, you'll get an email for every single bug that is in that state. I remember when Tiger was first seeded after WWDC, I was getting an email about every other week until it was released telling me engineering could not reproduce the issue with this release and see if I could confirm the issue. More on the future later.

On a small side note: If you want to ask about a bug and end up emailing devbugs or someone at Apple that asks about a bug you've filed, it's best to do it in the format of a link such as radr://4318699 (or if you have multiple issues, you can separate each problem ID with an ampersand (&) such as radr://3204961&4318699&3664624). This makes it super easy for the Apple employee to look up the status of the bug since they can just double-click it in Mail.app. I guess I'm saying that if you want any information from Apple it helps if you can go the first step and make it easier for them to get the information. You'll see these types of links all the time in Mac developer communities and mailing lists. They're useless to losers like me and are targeted to Apple employees. After a while, it just becomes customary to write problem IDs in this format.

Bugs: Apple, What They See versus What I See

Here's another huge point on contention between Mac developers and Apple engineers. Most Apple engineers have absolutely, positively, no freaking idea what losers like me see when filing a bug via RadarWeb. Often I'll see an Apple engineer tell an external developer (loser) to file a bug and choose "Finder", "LaunchServices", or "Safari (new bugs)" as the component. OMGWTFBBQ?! Those options do not exist to people outside Apple*. The only options we get containing those particular components are "Mac OS X" and "Safari". There is nothing else to narrow it down further except for the prefixing thing I mentioned previously.

The only thing losers like me get to see when filing a bug is a title, the severity (in our minds), the version of the product it affects (does it apply to the subcomponent you can't set or the Mac OS X version?), the reproducibility, two file upload buttons (one for a system profiler report, one for other things), and a text field to describe the problem. That's it. I have no idea what the cool people see. At WWDC, I sat right next to someone at Apple as they were filing a bug for me but I refused to look at what they were doing since the UI of the interface they see may be NDA'd. I wouldn't even take a peek. I do take NDA's very seriously and anything told to me privately will stay private with me if there's any hint it should remain private. It won't be mentioned at all. This is true even if keeping it private forces me to lie through my teeth. Point is, I don't know what Apple sees and many there don't know what I see.

Seriously, I think the devbugs team should force every single Apple employee to take a monthly or bimonthly class that shows them exactly what losers, such as I, see when filing a bug. Otherwise it just causes confusion when external developers are given "orders" to file bugs by Apple employees and the instructions don't match at all what they see. Alternatively, they could make sure all incoming and existing employees are shown the loser interface during orientation/training.

*Some external developers have their ADC Account marked in such a way they can see all the comments and can see the interface that internal Apple employees see. I wasn't even aware that this was possible until someone on one mailing list accidently had their account marked in this manner. Someone told him to file bugs on stuff if he had so many complaints about Mac OS X. He responded that Apple's bug reporting interface was extremely confusing. Everyone was aghast and wondered how someone could find such a simple interface to be confusing. As the conversation continued, it was clear what he was seeing was not meant for him. He was told to contact Apple and Apple fixed his account. No one was sure how it happened and there have been no other instances of this accidental marking in the four years since that I've seen. Personally I'd never want such power as I'd just end up choosing the wrong component. I'd rather have someone with better judgment handle it.

Bugs: Apple, What Benefits?

Quite a few people have stopped filing bugs due to the lack of communication from Apple. They just don't see the point in it. "Why bother to file bugs if they're just going into /dev/null anyways?" Their bugs either stay open indefinitely or are closed with "Behaves Correctly, STFU". Some people consider a simple non-automatic acknowledgment to be enough. Others would like to know that their bug was actually fixed because they filed it. As it stands, if one is fixed we're told it's "no longer reproducible in the current version". This statement doesn't connect your bug to the outcome of the current situation. It sounds more like marketing took over. It's obvious Apple acknowledges that bugs exist based on their release notes (especially for Security, where they actually give credit to the person that reported it).

Other times bugs may be filed on the current version of some piece of software and will be fixed in the next one. This becomes a problem if you don't have access to the fixed version. For example, when I first got my Developer Transition Kit, I figured I'd go ahead and test what would most likely break under Rosetta. I chose QuickTime Player as my target as I figured most people would need to run it under Rosetta for a while in order to watch their porn since the codecs used would take a while to be ported to x86. I tried a DV encoded movie and a movie encoded with the Animation codec. Both failed miserably with two separate problems. I filed bugs (and attached the files) and it was quickly fixed. I got the software and confirmed that it was fixed but found a different problem, QuickTime Pro no longer worked under Rosetta. I filed a bug on this as well. I also cited my reasons for choosing QuickTime Player as my first test target. This bug was fixed. However, it was fixed in the version of Mac OS X that came with the official ICBMs. I was told it was "no longer reproducible" when I received my exchange ICBM. I responded and told them I did not have a QuickTime Pro key to test it with (the DTKs came with QT Pro keys installed as part of Mac OS X). Devbugs or the engineer then closed the bug. No reward.

I've had various success with bugs based on the type of bug. Here are a few personal observations:

Documentation bugs: These are almost always fixed. Sometimes I have to scream and yell and give examples of why another document with correct information doesn't excuse a document from having the incorrect information even if the correct documentation is linked from the incorrect documentation. Most of the changes get made. Usually not resembling anything I've suggested, but they do get addressed. There are a few exceptions such as the word "species" being used as a verb instead of the word "specifies". Another example is the fact the *ResolveAliasFile* calls are not thread-safe despite being marked as such. If the main thread is playing with GetResource() while the other thread resolves the alias file, it can cause a crash since the Resource Manager is not thread-safe. The problem is, it's exceedingly hard to reproduce.

Feature/Enhancement Requests: I think these have always been marked as duplicate or they're left open indefinitely. I cannot remember a feature request that has been implemented. But then again, I don't ask for feature requests often.

Actual Bugs: I've had various luck with these. Sometimes they are fixed. Sometimes they are not. I think I've filed a bug on every single API and concept in FontPanel.h. Only one of these have been fixed. I started filing these bugs when 10.3 was released and after the WWDC in which 10.4 was announced. So many are quite old. I guess I just have bad luck with fonts.

The RadarWeb Itself: Usually the RadarWeb interface works just fine, no issues. However, I've had it totally die on me a few times. Once, it just completely died and gave me an error message. I sent the error message to devbugs but I couldn't give any more information than the error as I could not reproduce it. Another time, RadarWeb appeared to eat my attachment. It looked like it uploaded it, but it wasn't there. Which made me look the fool as I was getting visibly angry while commenting on a specific bug because the engineer was asking for information I had already sent. I didn't find out about this until I emailed someone at Apple asking for the status and they told me it looked as if I was yelling about something I had thought I uploaded, but didn't. RadarWeb gave me no feedback that the file did not upload correctly. Once you upload a file, you can never download it.

Bugs: Apple, The More Things Change^W Stay the Same

In the seven years since I've started filing bugs there have been very little changes I've noticed to RadarWeb or the bug process in general. Sure, the reddening was added. They also made it so the bugs are spread out across many pages. After a while, it was taking ages for people to log in as RadarWeb formatted every bug on one page. With these changes, something was lost. Now we can sort bugs by problem ID, date, or status. But the default sort of "activity" is gone. RadarWeb used to move bugs to the top of the listing if someone at Apple had modified any part of it. Devbugs or someone tried to remedy this by sending out an email every time any part of a bug was changed, but people were soon inundated with emails and they couldn't even see which part of the bug was modificated which just created more complaints.

Granted, the bug reporting form is now much simpler than it was before. The old form used to look like the non-account form. Except it autofilled the name and address fields. I never liked this form since it had separate fields for Summary, Steps to Reproduce, et cetera. It was annoying filling all of these out for each bug when they were often superfluous. Let's look at the "species" example above. Summary: "Uses species instead of specifies." Steps to Reproduce: "Read the sentence." Results: "Use of wrong word, species" Expected Results: "Using the correct word, specifies." It just gets very annoying after a while. Good riddance.

The lack of communication has remained a constant as far as my fuzzy memory will allow me to remember.

Suggestions to Apple: Take a cue from Microsoft. Allow the developer filing a bug to mark a bug as private or public. During the transition, mark all bugs reported prior to the transition as private as they may contain source code, but allow the reporting developer to change it. Allow developers to search the public bugs. Allow developers to see certain comments on their bugs.

I know that Apple is super secretive almost to the point that it's hurting them. However, Apple doesn't have to compromise security in order to increase communication. After all, Microsoft doesn't seem to find it an issue and they're many times larger than Apple, make a lot more money than Apple, get sued more often than Apple, and lose a lot more often than Apple. In fact, Microsoft seems to lose or settle every lawsuit brought against them. This hasn't stopped them from allowing comments. Simple comments such as "To be addressed in Chablis," are not considered something that should be kept secretive.

When an Apple engineer makes a comment on a bug, they could have a checkbox/popup that marks whether the comment itself is private or public. This checkbox/popup should have no state by default (to prevent an accidental choice) and it should be after the comment text field so the engineer can properly determine which status it should have after the comment has been made. Even if the comment is marked as private, it should say "Comment added by Apple engineer" to the losers viewing the bug (whether the loser be the reporter or the public if it is a public bug). Then at least they'd know that their bug was being loved (in the way a man loves a puppy) and wasn't being sent to the bit bin.

It would also be exceedingly nice while being very unlikely for developers reporting a bug in a piece of software to automatically get the next version of the software that fixes the bug they reported so they can confirm it was fixed. Of course, this would only apply to software that is not a simple update like the above mentioned QuickTime Pro key issue.

Finally, let's not forget the fact the Apple engineers themselves need to be schooled on the bug reporter and what losers like me see compared to what the cool people see, nootch.

Microsoft: Crash Reports, Getting Access to

Microsoft has a built-in crash reporter tool in Windows called Dr. Watson. This creates a log file (Drwtsn32.log) when something bad happens to an application. Windows XP has something called the "Error Reporting" service. This allows end users to send crash logs to Microsoft when an application crashes or stops responding (and you have to force the dang thing to quit). These reports are anonymous. If you want to file a bug with Microsoft (see above) or a Microsoft employee asks for it, you may be required to send the Dr. Watson log to some location on the internets.

Microsoft also offers an Online Crash Analysis website but I am unsure how this thing functions. However, it does appear to use the Dr. Watson logs. The Online Crash Analysis privacy statement says that they may send "error reports" to third-parties if a third party product is involved in the crash. However, the third party must abide to the privacy policy as well. In this case, Microsoft initiates the contact to the third party developer.

Alternatively, third party developers (henceforth, ISVs) can sign up to retrieve crash reports on a special Microsoft website. Instructions for signing up are available online. The "WinQual" website has many instructions on how to proceed. Basically an ISV just heads on over to Windows Quality Online Services website (which will not load in Safari unless you change your user agent to MSIE 6). Once there, the ISV just creates an account (which also has a list of all companies currently signed up). Note that in order to get a company account, your company needs a Verisign Class 3 Certificate which costs about $500/year. This same certificate can be used with other Microsoft programs and services that have code signing requirements. The certificate does not say anything about the quality of a company or the products they create, it just says the company officially exists. $500 a year is easy for most developers to afford that would be willing to sign up for Windows Error Reporting services. The hardest part in getting some signing certificates is they might require you to prove your business has been around for a certain amount of time, which may be impossible for start-ups. Note that I am not advocating code-signing as it needlessly locks out the little guy while doing nothing to make software better nor does it prevent malware. After all, malware companies can afford to buy certificate after certificate and create multiple faux companies in Brooklyn.

Once the WinQual account is created and the account is confirmed by Microsoft, you just sign into the account and map your program files to the company. How this is done, I do not know. I don't have anything to map so I don't have a reason to get an account or wait the days while VeriSign verificates that Unsanity does exist. It's interesting, but the instructions seem to imply that you'll automatically get everything Windows Error Reporting has captured before you signed up. This makes sense, but it is odd that it is retroactive like this. I am not sure how Microsoft verifies the binaries you choose are indeed your binaries. Especially if you never sign your code. Actually signing code does not appear to be a requirement to signing up for this service or reaping its benefits. Microsoft says it has over 1900 developers signed up for Windows Error Reporting services.

Microsoft Windows Error Reporting Service also has another really neat feature. Developers can send feedback to the user. Such as telling then an upgrade is available that fixes the crash they just experienced. I'm guessing this is automatically sent back if the crash contains binaries the company signed up for. I've never seen it, but I imagine this appears instead of or along with a dialog that says "we've received your report". That is, just a simple confirmation that the report was sent with additional default information provided by the server.

Apple: Crash Reports, Not Getting Access to

Sigh, so much negativity. Mac OS X includes something called CrashReporter. The Crash Reporter application automatically appears and shows a dialog, by default, to the user if an application crashes or (as of 10.4.x) the system suffers a kernel panic. The user can choose to send this report to Apple or to not send it. Unless you are one of the super big Mac OS developers (Adobe, Microsoft, Macromedia, et cetera), there is no way to get crash reports for your product from Apple (rdar://3356232). Even if you are from one of the really, really big companies, I've heard it's a pain in the butt to get Apple to turn this data over to third party developers. This can easily be "proven" in the fact that Microsoft Office 2004 comes with its own crash reporting application called (get this), "Microsoft Error Reporting".

Apple gives various reasons why it doesn't give third-party developers crash reports, most of them lies. I've been told they're proprietary information although I'm not quite sure how a stack trace and some state information from a PowerPC or x86 processor that came from an end user's machine is considered "proprietary," especially to Apple. After all, nearly identical information can be gathered from Windows. The only thing close to "proprietary" is the symbol names Apple chooses to use. If that were the case, then the symbol names third parties use would definitely not be proprietary to Apple. Another common reason is that the crash logs contain personal information. Now, this is where the lying comes in. After all, the Crash Reporter application clearly says (emphasis mine):

Your report will help Apple improve this software. Your personal information is not sent with this report. You will not be contacted in response to this report. For Apple product support, visit www.apple.com/support or contact your Apple dealer.

Now, if someone representing Apple is saying they can't send the crash reports to third-party developers because they contain personal information and an application, also representing Apple, clearly says no personal information is being sent, then one of them must not be telling the truth. Which is it? The crash logs are shown to the end user before they submit them, so the end user is free to not send it if they think it contains personal information for whatever reason. However, even assuming the application is correct, it's still not good as Apple has been the target of some privacy concerns lately. I'd imagine getting two different stories about what the Crash Reporter sends would not help ease those concerns.

As you can see, I clearly have personal motivations for wanting to access Crash Reports. One, to handle these claims. Two, to fix any kind of crashers that manage to sneak by our extensively extensive error checking procedures. Sadly, no amount of begging or suggesting certain favors to be performed seems to get those crash reports out of Apple's grip.

This is ultimately why Slava created Smart Crash Reports (SCR). We needed these crash reports and Apple wasn't about to send them to us. There are some other methods to get crash reports from users, but they don't tend to have the benefits SCR does. Namely they require developers that want to use them to modify their code, link in new code, or make some other drastic changes. They also either end up adding an additional dialog to the crash experience or completely suppress sending the crash log to Apple. Users tend to be less likely to send crash reports if they get a bunch of dialogs appearing when a crash occurs, especially a dialog they don't recognize as being the standard one. Further more, if one of the crashes occur during first-run of an application and your application only checks to see if crashes have occurred at launch, then you'll likely never find out about these crashes as people tend to toss applications that crash the first time they're ever used.

While developers can link to an object file and install SCR, it is not required. All they have to do to get the benefits of SCR is add two entries to their Info.plist file. Then if the user happens to have SCR installed and their application unfortunately crashes, the crash log will be sent to the developer if the user so chooses to send it. SCR is seamless as it just modifies the existing Crash Reporter application user interface with another button. This allows the user to send a crash log to the developer and Apple from one interface, by clicking on one button.

However, SCR has two limitations. One, because of the way InputManagers are handled, SCR is loaded into every Cocoa process, even though it does nothing in those other processes. Even if there was a massive memory bug in the host application, the loading of SCR is unlikely to trigger the bug in the host application. SCR gets the bundle identifier of the host application by calling [[NSBundle mainBundle] bundleIdentifer] which uses already allocated statics/globals allocated by NSApplicationMain() (the first line of code in 99% of Cocoa applications). Furthermore, SCR is loaded long, long before most applications even run any code at all. So even a hideously buggy application would be extremely unlikely to run any code before SCR is loaded. Two, in order to keep the amount of code SCR runs in the Crash Reporter application itself, SCR isn't all that bright in narrowing down the cause of a crash when a plugin is involved.

Let me elaborate a little. SCR does know which thread crashed and does know which binary was the likely cause. However, it does nothing to weed out false positives. It'll stop looking at the first registered code image in the crash log. While this doesn't affect application developers at all, it does affect us at Unsanity a great deal as we get a lot of crashes misidentified as being a haxie crash. Since it mostly affects us, we didn't see the need in creating an advanced AI just for our case.

Since we get a lot of false positives and read every single crash report that comes in, we've been able to determine some common issues in various applications and we have contacted the application developers when we discover these. Most of the false positives involve various APE Modules installing state and/or context patches. Patches that only exist in order to get data about the current state of the program for later usage. Patches that do nothing else but store a variable. Quite a few of the actual culprits are Contextual Menu Modules. Oddly a very, very high number of them call CFBundleGetIdentifier() and then release the result, which is a strict no-no. Yet, the CMMs do it so they only modify the context menu in the Finder. We've notified the developers of these CMMs as we find them. Some have fixed it very quickly, others still haven't. A different semi-often crash we've seen is the Windows Media Player plugin for Safari causing Safari to crash, but that's no longer being developed. Another common issue is application developers over-releasing memory when a window is closed. Usually because they don't realize the system will release the memory for them. This is often due to developers not understanding that while HIViewAddSubview() does not bump the retain count of the view, the owning window will release it anyways. Due to this misunderstanding of the object's ownership changing when the window is released, many developers tend to double-release the view, leading to a crash (often a crash on quit, which most users do not notice). Heck Neko-chan, even QuickTime itself has this bug. If you actually manage to create a/an HIMovieView, the application will crash as soon as the owning window is closed. Even the sample code exhibits this behaviour. On a side note (...), someone on QuickTime owns HIMovieView, the HIToolbox team does not. As it stands, HIMovieView is completely unusable and hasn't been usable since it was introduced in 10.4.

What does Apple do with these crash logs? Now that I'm finally done talking about how great SCR is, I figured I'd actually speculate on what Apple does with all these crash reports. After all, they obviously don't send them to third-party developers and they likely get more than thousands of crash logs per day. So what is their use? Some say Apple aggregates all the crashes together and then determines from those which ones are caused by bugs in Mac OS X. However, I do tend to doubt this. There's been a very annoying, very sporadic crash in CoreText since 10.4 was released. It's not very reproducible and happens entirely within Apple's code. Deep within Apple's code. It seems to be fixed in 10.4.7, but I am not sure it was due to the massive amount of crash logs on the subject or if it was because the crash was discussed on an Apple hosted mailing list a few months ago. If it was due to the massive amount of crashes, it shouldn't have taken over a year to fix it (if it is fixed). Post hoc ergo propter hoc? Maybe.

Another very common crash involves CoreImage and the various graphics drivers. Namely, some graphic drivers are extraordinarily crashy when being taxed heavily with CoreImage. Especially the ATI drivers. I've seen these crashes happen more often in Keynote recently when people are using the various neat, but ultimately useless, effects Keynote provides. guiTweak also triggers these crashes. Even more disturbing is that all machines using PCI Express graphics (regardless of video card) suffer from kernel panics when using CoreImage semi-heavily. Not good. Sadly, neither of these are fixed on the latest versions of Mac OS X and the application crash with ATI drivers has been there since 10.4. It's hard to use CoreImage to its full potential due to these crashes. The workarounds usually involve slowing CoreImage's effects to the speed of cold molasses running down a clown's leg. Clowns hate tangelos.

I actually have an amusing anecdote about the CoreText crasher. Some user of a particular application suffered a crash. He sent the crash log to the developer of said application. The developer responded, "No idea, it must be some Unsanity haxie you have installed." The user then sent us the crash log. The user and crash log both confirmed that none of our software was installed on his computer. That was the first time I think we've ever been blamed for something when our software had never been on a user's computer.

Suggestions to Apple: Give third parties access to crash logs for their applications! Then we wouldn't need things like SCR in the first place. And definitely allow plugin developers (like Unsanity) to get crash logs for their plugins. However, please do it without the code-signing requirement that Microsoft has. But if code-signing is required, even that's better than the current state of affairs. Especially since many users have the incorrect assumption that third-party developers have access to the crash logs they are sending to Apple. Which then leads to very angry emails from customers based on this false assumption.

Blogs

Both Microsoft and Adobe have corporate hosted blogs. Apple does not. I can imagine why Apple does not have blogs. One good reason is the above crazy corporate secrecy. I've even heard from various people that work at the Apple retail stores that when you get a job there, you aren't even permitted to mention anything Apple related on your own personal blog. But that's Apple Retail which is a separate division entirely from the people that work on making Mac OS X and the various Apple applications. I am not sure if this rule applies to them. Some Apple engineers have blogs, but they're completely scattershot on the internets and are thus truly personal.

I guess it's best that Apple does not have corporate blogs for their developers. I mean, who would trust a blog entry where the post was so full of Kool-Aid you had to assume the writer had a BKC of 0.73. You also can't trust blogs full of marketing speak. After all, this is what the .Mac "blog" appears to be. And Apple would definitely not want someone that works at Apple to say a third-party should be shut down because of their own personal beliefs. Nor do I think they would want one of their developers insulting a third-party by calling them "soulless profiteers and taking a private email conversation public (he never did send those crash logs).

Suggestions to Apple: I guess I don't really have any. It would require a massive corporate policy change to even hope to get Apple to support developer blogs and even more of a change to allow comments. What, with all the secrecy and Apple's reputation for removing anti-Apple stuff from their hosted servers. I mean, there's no way in the world anyone from Apple could every write something as harsh as this and hope to keep their job. Apple would probably even go far enough that they'd sue the Negative Nelly for "leaking trade secrets" rather than address their complaints.

Microsoft: Future Windows Versions

There are a few things that could be said about how Microsoft develops Windows. One, it is always delayed and features are cut to make a deadline. Two, they fully and completely communicate with developers. Microsoft already had public developer documentation available for Windows Vista back when it was still called Longhorn. They have an entire public subsection of MSDN just for Windows Vista development. They have a public "compatibility cookbook" so developers can now know what needs to be changed in their application for Vista. They even have forums for developers to use if they need assistance programming applications for Windows Vista.

Microsoft doesn't seem to have any kind of mandate about what their employees can say about Vista either. I mean, you've got posts that clearly show how bad the audio stack is in Windows XP and the low-level changes being made for Windows Vista. In fact, Microsoft hosts countless blogs containing posts about low-level changing in Windows Vista. Just recently, they even posted a long list of changes post-Beta 2. And this is all long, long before Windows Vista is to be released to retail.

I guess my point here is that Microsoft most definitely has a very open and public dialog with it's ISVs about Vista. It does not appear they are hiding any aspect of Vista from the ISVs and the ISVs are free to communicate with each other about their difficulties or solutions to developing for and on Vista. Microsoft also takes feedback from ISVs seriously. This allows reports like this to be made. It can ultimately also lead to a reduction in bugs for the final release of Vista as developers can collaborate better on new APIs which means they will get more use which means bugs can be found sooner. An API that is never used will never have bugs found for it until it is used.

Apple: Future Mac OS X Versions… Shh!

Now, Apple on the other hand… They're completely tight-lipped about everything. I'm talking about what's happened in the past when Apple has "previewed" a then future release of Mac OS X. There is no public documentation after the future version of OS X has been previewed. The third-party developers attending WWDC are allowed to talk about it amongst themselves at length. However, that's about it. They couldn't talk about it or ask questions about it outside of WWDC unless the people were in the same company as them and had seed keys. Even all the happenings and sessions at WWDC are NDA'd except the keynote.

The only way to ask for help with some new API or some quirk in the new version of Mac OS X is, officially, to contact DTS. However, I do not know if contacting DTS and asking for assistance for an unreleased Mac OS X requires a DTS incident or not. If it does require one and you don't have one available or you've used them all up, then that's $195 per question. If you are in the student ADC program, you can't even purchase an incident at all. You cannot ask for assistance on any Apple hosting mailing list. If you try it, you'll just be told you're under NDA not to talk about it.

At the last few WWDCs that had previews of a future version of Mac OS X, Apple employees have repeatedly said they would try to get an NDA mailing list started for third-party developers that want to discuss the APIs in that future Mac OS X release. (They already have some NDA mailing lists for other projects but they are invite only.) Even after WWDC is over and people ask about the status of said list(s), they're told "we're working on it". No such list(s) has/have ever been formed.

Compounding this problem is the fact that Apple doesn't give third-party developers the final (GM or RTM) release of the future Mac OS X version until long after the consumers get it. With Tiger, it was about a week after most consumers got it (but later in the evening on the "official" release date). For Panther, it was a few days after the "official" release date. This causes a massive problem for third-party developers as they cannot test on the final version until after consumers get it. And then consumers wonder why third-party software breaks on the new Mac OS X release. Probably because the third-party developer never had the chance to test it on a production system with the final before the consumer got it. At least then they could issue a warning before consumers started to complain.

Actually testing software on different versions of Mac OS X is also incredibly tedious and difficult. Microsoft has Virtual PC for free, so developers can easily test their applications with multiple versions of Windows on one computer box. To test an application with multiple versions of Mac OS X, you need either a separate partition for each version of Mac OS X or a different computer. The latter may be required if one computer cannot run all the versions of Mac OS X an application should be compatible with. So it's either rebooting back and forth without being able to debug easily or having multiple computers connected via something like Timbuktu. This difficultly is why most developers (including Unsanity) only support the current major version and the immediately previous version of Mac OS X.

Suggestions to Apple: Actually follow through with these NDA lists we developers have been hearing about for the last 3-4 years. Not allowing developers to discuss pre-release Mac OS X versions with other developers just leads to far buggier initial retail Mac OS X releases. Adding to the issue is that developers can't even really write code for the new APIs until the version of Mac OS X is finally released from NDA. Well, they can write code for it, but if they have any issues they might have to create really nasty workarounds that defeat some of the benefits of the new APIs. A great example of this is Core Image. It was practically unusable in Mac OS X 10.4.0. It had simple but massive problems that could have been found and addressed before 10.4.0 was released if third-party developers could work together to understand the new API rather than each one starting from scratch and having the acquire the same knowledge themselves. Fifty developers all having to work from scratch to develop the same workarounds differently just leads to slower adoption of new APIs.

Documentation or Description Forthcoming

Microsoft's online developer documentation has often been considered the pinnacle of documentation for a consumer operating system. One of the biggest benefits the Microsoft documentation has is how an API reference links to or shows an example, in code, of how to use the function. A good example is the GetMenu() which links to a document about using Menus. Apple's documentation for the "same" function has no such reference to sample code.

Actually, Apple's documentation has gotten a lot better over the years. It's hard for me to find things to complain about now. When Mac OS X was initially released, almost every single function said "description forthcoming". My, how times have changed! It's actually exceedingly difficult now to find this kind of documentation. Most of it has been fleshed out with the biggest problems with the actual documentation is the lack of consistency. The documentation for GetMenuRef() has one documentation style whereas what I just pointed out has a completely different style. Personally I'm fond of the GetMenuRef() style.

Other than almost the complete lack of example code in Apple's documentation, many third party developers have wanted to edit the documentation themselves in order to fix any lacking caveats or "gotchas". Thinking, "If Apple won't do it, I will!" Well, Microsoft actually has an MSDN Wiki that allows anyone to edit or add to the documentation. It's probably meant to be like Wikipedia in nature. Anyone can edit it and submitted content and existing content is covered by a Creative Commons license, which is pretty sweet. However, I have no idea how to edit existing content, the beta site doesn't appear to work well in Safari or Vista. If you look at the documentation for menus you can see that the documentation contains the kind of sample code Apple's documentation should have for each function.

Apple has recently added almost monthly documentation downloads for offline viewing in either Xcode or in PDF format. Xcode automatically checks for new versions of the documentation at a settable duration. The most recent download is the June documentation. With WWDC right around the corner, I don't imagine there will be a July release. For some very odd reason, you must be an ADC member to download the documentation even though Xcode comes with Mac OS X. Granted, registration is free, but you have to be at least 18 years old to download the most recent documentation which seems like an odd requirement. Microsoft also has full offline documentation downloads. They used to only be available for MSDN memberships, the kind that cost money. But now, they are free. The most recently available is the May edition with future releases to be free. Microsoft does not require any kind of registration to download and thus has no age limit. Sorry AngusD.

Sample Code

Apple has a semi-massive amount of sample code. Both on their website and installed in /Developer/Examples/ with the Xcode tools. The latter also has source code for TextEdit, SimpleText, and Sketch. SimpleText being a sample that developers had been yearning for when Mac OS 9 was the main release. Apple's license to their sample code almost seems to be public domain. You can use it in any way you want. Some developers have even just taken some sample code, recompiled it, and sold it as their own. Sony Ericsson's website actually uses some Apple sample code (search the source for "sample"). However, if you modify Apple's sample code, you cannot say the source code is from Apple. Which makes total sense.

Comparatively, Microsoft seems to not have much web-accessible sample code. Visual Studio includes various sample code pieces as does the Windows Platform SDK. Microsoft says you can "modify, copy, and distribute the source and object code form of code marked as 'sample'". However, I am unsure if you can take Microsoft's sample code, recompile it, and sell it as your own. Although I'm not sure if the ability to do that is a good thing.

Suggestions to Apple: Give me more to complain about. But seriously, they could create a wiki-like system for outside people to edit documentation. Granted, I can't imagine they'd allow anyone in the public to do it. It might be better if they granted a few people at a time that ask for it. I mean, I don't think I could be trusted to edit Apple's documentation without screwing something totally up. I do know they currently allow third parties to create technotes but I don't know the procedure for writing such a document. I also know that these documents can be woefully out of date. (As Mac OS X 10.4, FSRefs are guaranteed to be valid across processes.)

Apple could also implement some kind of automatic inlining of sample code. For example, someone from apple could write a sample using a host of functions like GetMenuRef(), AppendMenuItemTextWithCFString(), and ChangeMenuItemAttributes and the documentation for those three functions would have that sample code right below the function. Granted, you'd need some way to exclude very common functions like CFRelease(). You'd also need some way to make a specific sample as being the preferred sample for an API. But doing it automatically is a good way to start.

The HIG, or Do As We Say, Not As We Do

Ah, the Apple Human Interface Guidelines. What a sweet, sweet document. This is the document that causes Mac users en masse to email Mac developers just to complain about every nit-picky thing that violates the Mac "standard" (standard meaning HIG). In fact, there are many beta testers out there in the world that only email HIG violations.

It's easy to determine which applications (like Word) try to fake conformance by including their own graphics inside their application that "look" like the standard Mac OS X/Aqua graphics. However, Apple has updated the way OS X looks in every single major release so far. Sometimes slightly, sometimes by a large margin. This makes applications that fake it look horribly out of date. For example, Office v.X has all these weird striped lines everywhere and 10.1 style buttons. The Adobe applications have the same problems as well. It's funny, Mac OS X has an extensive Theme API which developers can use to make sure they are drawing the correct theme patterns, colors, fonts, and brushes for their custom controls or custom content. In fact, there are many developers that have installed ShapeShifter and changed the theme in order to make sure they are actually using the APIs correctly so when Apple changes the main theme of Mac OS X yet again, their application doesn't look completely retro.

Let me say this flat out: The HIG is a good thing. It keeps Mac applications consistent and consistency is good. It's designed so anything that works in one application, works the exact same way in another and this reduces the learning curve for new applications. The very first page of the HIG lists eight reasons why developers should follow them. But there's a slight problem with this Gospel of Mac™, Apple itself completely ignores it. Not only do they ignore it, they make gross violations and then they'll make changes to the HIG to accommodate the violations and make them the new "standard". I won't mention the obvious problems with the metal (or textured as it is called) windows.

For example, the Toolbar icon section of the HIG used to have a long tirade about choosing the shape of toolbar icons. It suggested making the shape of toolbar icons unique. It then went on to show a screenshot of the old Mail.app toolbar. The current Mail.app toolbar (shown above) gets rid of the shapes. Now each toolbar item is an ugly blue button. There's no logical reason for this change other than someone high up at Apple wanted to "experiment" with a hideous new UI element design. Because the former HIG guidelines conflicted with how Mac OS X actually behaved, the section about the shape of the icons was removed in the 2006-02-07 revision of the HIG. Sadly, I don't have a previous revision of that page.

Other times Apple applications or APIs themselves violate the HIG just because the person in charge of said technology disagrees with the HIG. Case in point, it is virtually impossible to make an HIG conforming application using Cocoa without crazy subclassing. This is mostly due to the manager(s) in charge seemingly believing they are better than the HIG, as it is a piece of the "old Apple" and thus they don't have to adhere to it. A great example is the NSDocument class. The HIG clearly says use "untitled" for new document windows. NSDocument does not do this. When asked why and how to conform to the HIG, the guy in charge has a rather ridiculous response and tried to make excuses for why his personal preference is the correct one. Sorry, but "other applications do it wrong" and "other languages have no concept of case" are not valid excuses. Sorry to be so cliché, but if everyone was jumping off a cliff, would you do it too? The second reason just made me scratch my head. See, Mac OS X supports this little thing called localization.

This means that you can use different strings for different languages. Now, Cocoa already has localized strings for the "untitled" name. For example, "Untitled", "Sie können angeben, wo das Dokument gesichert werden soll", "名称未設定", and "무제". In other words, if a language has no concept of case (like Japanese and Korean there), then you obviously cannot make a lowercase string. However, for languages that do (like English), it's as simple as changing the "Untitled" = "Untitled"; string in /System/Library/Frameworks/AppKit.framework/Versions/C/Resources/English.lproj/Document.strings to "Untitled" = "untitled";. Also, thou shalt not disagree with the Chicago Manual of Style.

Apple used to have a mailing list dedicated to questions about the HIG and commenting on the HIG. However, shortly after Mac OS X was released and the "new" decision makers came into power, the amount of complaints on this list skyrocketed. The complaints started to decrease as Mac OS X evolved, but it's hard to tell if that was because the problems were resolved or just because people became complacent. Anywho, after a few years of complaints, the higher-ups got sick of it and rather than address any of the complaints, they just shut the mailing list down. The way it was closed seemed kind of petty, almost as if Apple was saying, "Don't want to praise our play? Then we're taking the ball home!" or something. But my memory of that time is foggy and rereading the list archives (which are not on Apple's website) I don't feel the same rant-inducing "outrage" I felt when it was initially posted.

The Apple Design Awards

I'm sorry, but I tend to find the ADAs to be more of a joke now days. I don't disagree with awarding application developers that have taken the time to carefully use Mac OS X technologies and make sure their applications conform to every detail of the HIG. However, some applications (but not all, of course) that are awarded an ADA just don't do either of these well. It seems they are awarded for initial prettiness rather than for use or conformance. If we look at the list of previous winners, I see one that I couldn't disagree with more. STX (Salon Transcripts) is an application I've had nothing but problems with. If you look at their various features, they all seem to show completely different views. All these views come from one single application. What's worse is the install procedure. You get a CD that contains about 6 disk images. Some disk images are optional but others require you to install the private frameworks inside the disk images in a specific order before you can install anything else. And then if you want to upgrade from a previous version of ST Pro, you have to actually open ST Pro (which runs only under Classic) on the computer, hope you have a serial number for the old version that is still valid as they tend to expire, go through about 14 pages of detailed instructions in order to clean out NULL entries in the databases, and then hope the final export program (which also runs under Classic) actually succeeds. I could not get it to succeed on some of the computers. If you're upgrading from an old computer that runs Mac OS 9 and upgrading to an ICBM, you're in for a world of hurt.

I've been wanting to complain about that for over a year… The other issue I have is with the fact that Delicious Library won two awards with one being the "Best Mac OS X User Experience". I know I can be hard on Delicious Library at times, but I cannot agree with this. It's interface is completely non-standard (with regards to the HIG). For example, there's no real way to tell which pane is focused so doing a select all may or may not select all the items you meant to select. Another small violation is the fact the cursor changes to a copy cursor when you drag something into the info pane but you can't actually usefully drop it until you're over the little image well inside the pane. Delicious Library also has flaws due to the Cocoa mentality (the one that says the system does everything for you and you don't have to optimize anything). If you have more than a handful of items, DL takes minutes to launch and minutes to quit. And I can't seem to reload information for every item without DL first eating a bunch of memory and then crashing. Perhaps I am being too harsh on DL and am only mentioning it because ranting about one program (STX) makes me look like a loon.

Actually, it almost seems like the winners of the ADAs have become predictable. So I'd like to make some predictions. Let's see, The Omni Group seems to win a lot of these awards. So I'd imagine either OmniPlan (which is beta) or OmniDazzle will win some award. The latter possibly winning best use of Mac OS X technology. Videator might get a special mention for Mac OS X Technology. Sandvox will probably get a runner's up award if it doesn't get anything else and the author will make some quip about Apple stealing it. Growl might win for open source software. If Delicious Monster has any major new version or new software, that'll win. Then the author will make some quip about Apple stealing all his talent. It would be nice to see NetNewsWire and EyeTV win an ADA, however.

Suggestions to Apple: FOLLOW YOUR OWN BLOODY HIG! I don't know how else to say it. When Apple doesn't follow the HIG (as they often don't, look at any iLife application) then third party developers will try to do as Apple does. This just makes horribly inconsistent applications, as often the things Apple does are hand-rolled and have no system API. Mac developers basically follow the leader.

Developer Support

Software and Code

Microsoft offers between 2 and 4 technical support incidents. I cannot seem to find much information about how to use these since I don't have an MSDN subscription. However, Microsoft seems to prefer you use the managed newsgroups to get your support but that won't work if what you need help with is proprietary to your company and you have to use a support incident.

Now Apple's support, I do have experience with that. A lot of experience. The technical support incidents that Apple offers are code-level support incidents. Meaning if you have problems with writing source code, you use an incident. It cannot be used for general use software problems. With Apple's programs, you get either 2 or 8 technical support incidents, depending if you are a premier or select member. If you run out of incidents and need to purchase more, they are available from the ADC Store for $195 each or $9000 for a pack of 50 incidents which expire after one year of non-use. I swear that Apple used to offer more than eight incidents for the premiere account and more than two for the select account. To use an incident, you just email DTS from the email address attached to the ADC Account with the incident.

Technical support incidents are usually used when a developer has lost all hope and exhausted all methods such as asking on the mailing lists and asking the Mac developer community at large. When you contact DTS with some issue and the issue you are having turns out to be a bug or is better done by another API, Apple will return your incident to you in most cases. Most of my incidents have turned out this way. The other times they've mostly just been really dumb mistakes on my part.

I file a lot of technical support incidents as I often do the "researching" for the company. Researching how to do some features or how to best implement some features that may be a long time off. Sometimes I just do incredibly stupid stuff to see if it can be done. Most of the times when I do contact DTS, I get a response back rather quickly. If the answer to the question necessitates code being written, then the lovely people at DTS will often write the code for you. They'll write it in a manner so that the code can be copy and pasted easily into your project without too much setup. Often, the code they write will become official Apple sample code for others to enjoy.

Granted, not all my DTS experiences have ended so nicely. Once I filed an incident trying to figure out how AppendResMenu() was getting the name of some fonts. The names didn't appear to be in the font file at all. No matter what I did, I could not reproduce the name some of these fonts had in the font menu. Someone at DTS responded a few days later telling me they'll have to contact engineering to get further information. A month passed, no response. I emailed back again and was told they were still awaiting a response. Two months passed. Eventually I was just given back the incident and I never got an answer.

After downloading the various font technotes from Adobe's website, I was able to figure out I needed entry 18 in the font table. The SNFTTypes.h header file stops at name code 14. I have no idea why I never could get a response from DTS on this issue. It took me quite a long time to find the answer and the answer turned out to be something entirely simple that could have been found by running some old Apple sample code.

Hardware

Well, Microsoft doesn't exactly make or sell general PCs. So they obviously have no method for hardware support. Apple also does not offer any kind of technical support for hardware purchased through the ADC Hardware Store. This I found kind of odd since the hardware was purchased through the program. If a developer has problems with their computer then they are left to the whims of AppleCare. Not exactly what I'd consider to be the best method, considering developer hardware is very important to developers and they need it to function correctly in order to do their job. Developer machines often contain source code so the hard drive needs to be removed or wiped completely before it is sent off to AppleCare.

What happens if AppleCare doesn't do the repair properly? If a machine used for programming fails and needs repaired then that means you'll be without it for multiple days while Apple fixes it. This kind of makes it hard to get a second repair done since you need to schedule downtime in advance. For example, my PowerBook's arrow keys have died twice. They just stopped working. This makes it nearly impossible to navigate code without using the mouse. The first time it was repaired, mostly everything was fixed. However, the '?' key lost its backlighting for some odd reason. Not exactly the biggest problem.

The second time the keys failed, whoever did the repair did a not so very good job. As you can see from the photo on the right, the keyboard now "slopes". The left and right sides of the keyboard are not flush with the case. At first, I thought it was just a cosmetic issue but then I started typing a bit of text. I then noticed it was nearly impossible to use the shift key without applying an excessive amount of force. This makes it extraordinarily hard to write code, which is case sensitive. Not to mention my code contains a lot of sad faces, which are hard to type without a shift key.