Just add these two lines to the top of your page:

Of course, this is a hack workaround that uses Silverlight to emulate the Video object, but going from “doesn’t work at all” to “make users install a plugin, once” is a pretty good deal. Here’s the original post describing it.

One of the things I see pop up on Stack Overflow all the time is, people wanting to hide or suppress the Windows Error Reporting dialog – the feature of Windows where crash reports are sent to Microsoft when your app crashes. Developers say, “MS doesn’t care about my app, what’s the point?” If they’re not so bright, they’ll write a try/catch block around their main() and hide all errors, then they’ll never find out why their apps crash in the field. Smarter developers will essentially write their own hacked-up version of WER with varying degrees of success. However, there’s a 3rd option that is superior:

Register with Microsoft, and get the WER Reports

Microsoft doesn’t just trash your reports, we will automatically aggregate them into distinct crashes (called ‘buckets’) and show you a ‘popularity contest’ of crashes – you can find out a ton of detailed information about what is happening in the field. Here’s the MSDN article detailing how to sign up. It takes a bit of leg work, but if you’re writing any sort of production-quality application, it’s 100% worth it.

But here’s what to do if you don’t believe me

Alright, so you have some super-good reason as to why you really don’t want this dialog to show up. Here’s what works on Win2k and higher (Vista has an API to do this explicitly though):

WPF hardware acceleration dies under VMWare

Just as a note since this comes up a lot from designers who use Macs and are getting into Silverlight / Expression Blend – if you are trying to use VMWare Fusion or Parallels and are coming up with weird graphics glitches or black screens while trying to use Blend, it is because WPF doesn’t get along well with these products’ graphics virtualization (I imagine because both products are focused on gaming / full-screen graphics).

WPF can be forced to run under Software-only rendering however, which clears all of these glitches up (and for Blend, doesn’t seem to have a huge impact on its usability). To do this, check out this MSDN page – you’ll need to open up the Registry Editor (regedit.exe), find the HKEY_CURRENT_USER\SOFTWARE\Microsoft key, create a new folder called Avalon.Graphics, then in that folder, create a new DWORD value called DisableHWAcceleration and set its value to 1. Close Blend and restart it, and everything should work now

…that sometimes you run into some semi-famous CS people on there.

Good thing the author of the book I forgot still remembered that he wrote it.

An app that I had to abandon once I started at Microsoft called gnome-format; apparently, one of the writers at Phoronix picked up on my program and wrote a review on it! Even though the code is dead, it’s still cool to see that it was a pretty positive review. If you want to see the last version of the code (i.e. the one the reviewer was working on), check out:

However, while the review is great, the version that he meant to review, was the one written by Felix Kaser, who has started from scratch on a new version of the code in Vala. So, check out his version too, and help him to get it into GNOME where it belongs!

Continuing from last year’s edition, here’s the software that I use on a day-to-day basis. Because of my traitorous switch to Mac, this list looks quite a bit different than it did earlier. As before, this is cribbing from Mark Pilgrim’s series – his 2008 edition is also full of good recommendations.

1. Mac OS X 10.5 – after using a Mac as my primary machine for over a year now, I’m on the fence as to whether I’d ever go back to Linux or not. On one hand, the UI design and software support is great, but there’s just enough proprietary bullshit to make me reconsider. For the time being though, it’s the best there is, because my other favorite OS Ubuntu and Linux in general seems to be on a steady decline to crap city. If anyone takes offense to this assertion, I’ll be glad to write up a detailed response as to why it’s a mess.
2. F-Spot, delicious, Vim – still continue to kick ass. Because of the wedding, I ended up effectively doubling my picture library, mostly with U’s 2MB pictures from her SLR camera – F-Spot handles it like a champ.
3. Git and GitHub – Git is so mind-blowingly useful to anyone who is a developer, power-user, or anyone who works with text files, that I can’t possibly leave it off this list. This program continues to help me out just about every time I program; at work, I use it to manage multiple in-flight hotfixes to certain train-wreck components who shall remain nameless (but not linkless), as well as whenever I have to do any large change to Windows source code. At home, GitHub is a great way to manage my developer tools as well as my personal projects.

   Seriously, if you’re any sort of programmer whatsoever, learn Git.

4. Quicksilver – it’s hard to describe what QS actually is, the term “app launcher” betrays its real utility, but it’s by-far one of the best reasons to use Mac OS X. Basically, it’s a GUI version of a fast command-line interface, one that learns which commands you use most often and shortens the number of keystrokes you need to use them. Taking some time to learn everything that QS can do pays off quite a bit for your productivity.
5. Firefox – continues to be the browser of choice, with its fantastic plugins (the “It’s All Text!” plugin being one of my favorite, lets me use GVim to type Emails or this blog entry for example). Great developer tools like Web Developer Toolbar and Firebug make it way better than Safari for most things. Speed and platform-integration are two of the things I do miss though…
6. Live Mesh – file synchronization that just works. Works great with both Windows and Mac, and its remote desktop feature while somewhat anemic, is beautifully simple to use. If you don’t have a backup solution (and if you don’t, you will lose your stuff – storing everything on a USB stick does not count), this is a fantastic way to do it with almost zero work
7. VMware Fusion – solid virtualization software for Mac, great integration with the guest without the evil hacks that Parallels uses (trust me as a Windows developer when I say this, you are much safer with VMware than with Parallels). These days however, I prefer more to use a dedicated VM running on another machine that I can remote desktop into rather than a local VM.
8. Cygwin – without this, work would be way more painful. A Windows machine without Cygwin is nearly worthless to me.
9. iTunes – …and I f’ing hate it. Please, someone write a music player for OS X that doesn’t epically suck. Amarok 2.0 and Songbird don’t count – Amarok went from the best music player on the planet without question, to a giant pile of gray crap. Trolltech systematically destroyed every decent KDE piece of software by releasing Qt4 and causing everyone to decide to make massive rewrites of their software, but I digress.

   Anyways, some of the few things that iTunes got very, very right are, how it remembers exactly where I am in a podcast and syncs it with the iPhone, its podcast support in general, and its great sync support with devices (letting me choose whether to auto/manual sync music, making automatic backups of my phone, etc). The iTunes store would also be a gigantic win if it wasn’t so DRM-encumbered, and I would spend way more money there, instead of at Amazon MP3, which is also a fantastic service.

10. XBMC – I’ve been using this on the XBox for years, and now that it’s a 100% cross-platform app, it’s even more awesome. Playing back video on your TV with this is fantastic, I stream movies and TV from my desktop machine over wireless and it works near-flawlessly, and understands just about any format. Setting up a cheap box with XBMC on it is the best way to get your music and movies onto your TV, hands-down. There’s also versions for hacked AppleTVs, which turns an AppleTV to me, from “complete trash” to “very compelling”. If the AppleTV had decent audio/video outputs, it would’ve been my new media box.

Stuff I don’t use anymore

1. Tomboy – only runs on Linux until recently, and is local-only. The original developer also annoys me by coming up with fantastic ideas then abandoning them (I could also point that right towards myself, but anyways…)
2. sshfs – I still use this occasionally when I have to traverse firewalls, but for everything local, Samba is faster and a bit less of a pain on OS X
3. Unison – since I do much less work on my desktop than I used to, having two-way sync isn’t as useful to me; I just rsync from laptop -> desktop.
4. Ubuntu – too many things broken on MacBook Pros, most the fault of Apple’s strange hardware, but it doesn’t change the fact that it’s broken.

64-bit is the future

Despite everyone dragging their heels as much as possible, eventually developers and users will start moving soon to 64-bit; in WinSE, we predict that this is going to accelerate quite a bit because computer manufacturers are starting to sell machines with more than 4GB of RAM, and customers start complaining when they pay for 4GB and only get 3ish or so

However, even among experienced developers, I hear a lot of confusion about how 64-bit works, and how I can run 32-bit programs on 64-bit. Listening to the .NET Rocks episode on the subject shows that even fairly knowledgeable guys can be pretty confused about how all of this works. Hopefully, this blog post can set the record straight for some of you – if anything seems like it makes no sense, leave a comment or send me an Email and I’ll try to update the entry!

The one thing to remember

Whether you’re on Windows, Linux, or OS X, there’s one fundamental problem that underlies all of the complexity; if you remember this one fact, everything else in this article will make sense. Here it is:

You can not load a 32-bit library in a 64-bit process.

Repeat that out loud a few times, it’ll help. This is a fundamental aspect of 64-bit computing and 32-bit compatibility mode on the amd64 and IA64 architecture, it’s not specific to Windows. This rule shows up in a lot of places that you wouldn’t expect, like Explorer shell extensions, browser plugins like Flash, and multimedia codecs in Linux.

In an “all 64-bit” world, there are no problems – everything is simple and works pretty much just like 32-bit. However, one of the advantages of the amd64 architecture is that it allows 32-bit code to be run in compatibility mode, with almost no loss in performance. Being able to run both 64-bit and 32-bit apps in the same OS is huge for application compatibility, and AMD was very smart to make it possible (unlike Itanium, which pretty much threw x86 compatibility out the window, and felt the much-deserved consequences). However, to make this actually work is most-definitely not a trivial affair – there’s a lot of things to fix up to make everything as seamless as 32-bit.

How does Windows deal with it?

The core infrastructure in Windows NT to handle this is called WOW64 – this code manages emulating the 32-bit architecture (either by only setting the processor mode in amd64, or actually performing emulation in IA64). As a result of the rule I’ve described above, there are actually two copies of almost every API in Windows – one for native binaries and one for 32-bit binaries.

For every system DLL, there’s two versions!

When a 32-bit app gets launched on x64, all of the DLLs being used are from the \Windows\SysWOW64 directory; usually these follow an identical codepath to the 32-bit version of the DLL, though certain DLLs like user32.dll actually operate differently in WOW64 mode. There’s a lot of stuff behind the scenes to make this happen, such as Filesystem Redirection (almost all apps don’t need to know anything about WOW64!) However, there’s still one problem – for 100% user-mode DLLs, this solution works, but the kernel is 64-bit, and only 64-bit. We surely can’t load a separate 32-bit kernel running at the same time!

When it comes down to it, you need to get the data to the kernel in a different way, some sort of IPC mechanism – in Windows this involves the RPC/LPC mechanism, or more commonly, via a syscall. When a 32-bit app calls CreateFileW, it calls NtCreateFile, which pushes the appropriate parameters into registers, and invokes the SYSENTER instruction to switch back into 64-bit mode. This mechanism works because there is only the kernel to worry about transitioning to, and it can have special knowledge as to whether the calling process was 32-bit or 64-bit.

What about .NET?

.NET is an interesting case; when you install the 64-bit .NET framework, two versions of the CLR are installed as well as the GAC (knowing that there are two GAC’s can avoid a major Gotcha!). However, most .NET binaries are MSIL – since the binary is in a processor-agnostic instruction set, which one does it choose?

The answer is, “usually 64-bit, except for when it doesn’t.” .NET assemblies can be marked as “only run on x86/x64″ via the compiler or via the Corflags tool,and there’s one very important reason to do so, if you use P/Invoke to a library that only has a x86 version. Unfortunately, the check for x86-only will only extend so far down the dependency chain, so if you have a library who uses a library who uses a native library, the CLR will end up throwing a BadImageFormatException.

Debugging using WinDbg

There’s one special trick to debugging an x86 binary on 64-bit with WinDbg, via this blog entry, that if you’re having trouble getting a call stack, you need to load the wow64exts debugger extension and use the “!sw” command to switch between 64-bit and 32-bit mode. VS is luckily smart enough to handle this for you (though I haven’t tried it recently!)

As a part of my goal of learning as much as possible about programming, I’ve set out to read all of the “classics” of Computer Science / Engineering books. And since everyone has their own definition of what a classic is, I’ll share my own $0.02 on the subject.

Of course, if I stuck to the traditional knowledge of the subject, I’d have the same list that everyone else has, so I’ll try to be a little bit more unique through the series and put a few books on there that might not be typical. These are books that improve your perspective on how to design and write software, as well as specific technology books that I find to be really well-written and useful, even if they don’t teach anything specifically about software design.

However, this first book isn’t atypical at all, but it’s something that changed how I approach programming, especially when working with others’ code. And the fact of the matter is, after you’re done learning how to program and start working professionally in the field, you’ll most likely be working frequently with other people’s code. Even if you’re a one-man shop, learning to refactor properly will make adding features to your code easier and cleaner, and helps you to write elegant, maintainable code.

Refactoring by Martin Fowler

One of the best things that Fowler discusses in the book is, not only what refactoring is or how to do it, but when to do it. his cheat sheet in the back of the book identifies what he calls “code smell” – common code mistakes that result in lousy code, and what to do about them.

If you take away only one thing from this book, it’s this: if you go to add a feature to existing code and it’s not trivially easy to add in, refactor the code until it is. Hacking in code all over the place to make something happen will work for awhile, but you’ll eventually turn the code into an unmaintainable mess.

And if you have room for two things, here’s the 2nd takeaway: unit tests are very important, they let you refactor the code without wondering if you broke anything. If you spend time debugging an issue, it helps you exactly one time. You could spend an equal amount of time writing a unit test that catches the issue, and it helps you over and over.

Writing your own iPhone apps is fun and all, but it’s completely useless to me if Apple’s going to make me pay $100 and wait for months to get it onto my phone – one of the flat-out stupidest things that mar an amazing product; well luckily, the hackers are stepping up and turning Apple’s cathedral into a bazaar by Jailbreaking out of Apple’s code-signing prison, and creating an awesome alternative to App Store called Cydia.

Using some elbow grease, you can write an app using Apple’s official SDK, test it in the simulator, then actually put it onto the phone to see how it works. If it works great, either host your own F/OSS iPhone repository, or pony up the cash and get it into the App Store.

Or, just click on this:

Here’s the steps to get an SDK app onto your phone:

1. Since Apple enforces codesigning on the iPhone, you need to Jailbreak your phone – otherwise we have to have a dev key.
2. Build your app using the “2.0 Device – Release” profile (*not* Simulator)
3. Using Cydia, install OpenSSH, and use the network preferences pane to figure out your IP address
4. Open up a terminal, and get your app onto the phone:
   cd /path/to/my/app/build/Release-iphoneos
   tar -czpvf MyAppName.tar.gz MyAppName.app
   scp MyAppName.tar.gz root@192.168.xxx.xxx:/Applications/   # Replace with your iPhone’s IP
   ssh root@192.168.xxx.xxx
   cd /Applications
   tar -xzpvf MyAppName.tar.gz
   rm MyAppName.tar.gz

5. We need to “fake sign” our binary, so keep typing in the terminal…
   apt-get install ldid
   cd MyAppName.app
   ldid -S MyAppName
   exit

6. Now, restart your iPhone – you should see the app in your Springboard

I make no guarantees about this method, but it at least worked with the AccelerometerGraph.app sample that Apple ships (and that ironically is completely useless unless it’s on an actual phone).

Update: Getting your apps into the Cydia list is as easy as going to this website and submitting a description / package – just like App Store, only way easier and Free’er!

In my push to make Yikes! a real open-source app, one thing that the project needs is a good forum. Either hosted, or I can put it on my own server, as long as it’s easy to use. I’d also prefer that it supports OpenID. Beast looks pretty good (PS: you do *not* want to Google for that), but hosting >1 Rails site on my Linode may cause it to explode. Anyone had good/bad experiences?