Tried it out, other than some problems with the UI, it looks very nifty! I can use it only on the testnet at the moment, though.

I don't have enough RAM to hold the whole main network blockchain, that's why.

The GUI issues are nothing severe, it just looks a bit ugly with overlapped text and buttons :
https://i.imgur.com/BOQ6d.png

Man I suck at quality control.  I had tested the pseudo-binary solution in Windows, except I used a machine with python already on the path which wasn't part of the install instructions.  I updated install_zope.py and tested it on a fresh Windows7-32bit VM.  Works perfectly now.

Also, it gave me the opportunity to test the XP-32bit binary on Windows7-32bit, which did work.  So I renamed them simply to "Armory_32bit.zip" and "Armory_64bit.zip".  Only the rare few with WinXP-64bit may have an issue.  And I don't have a sample system like this, so I can't test it.  If you do have such a system, let me know how it goes.

I'm still working on the full-binaries, but the issue I'm having is inconsistent, so I don't have a good way to know for sure.  I just have to do some more exhaustive testing.  Thanks for your patience!

the existing format sucks and armory has a completely different and imho way superior approach. its better to make a clean cut early than to carry on with a bad solution because of backward compatibility.
its not like there a millions of people out there depending on their old addresses.

and then you have a deterministic wallet that is a few bytes big  + hundreds of isolated keys including the backup keys. very useful.

Joric succeeded at reading encrypted wallets, and I do want to eventually allow the move, but I want to make sure it's possible to run Armory without running bitcoin-qt/bitcoind at the same time.  Sharing some addresses between the two wallets while also having some independent addresses can lead to you having absolutely no idea how much money you have (and usually over-estimating).

At the very least, I want to allow people to switch to Armory, but I can't reliably create a perfectly synchronous dual-wallet system.  I designed the Armory wallet specifically to be simple and straightfoward, and easy to maintain among multiple clients.  The Satoshi client wallet uses a database engine, which not only requires a separate library, but I also think it comes with extra risks (like the encrypted-wallets-not-actually-encrypted bug 0.4.0).   I will not add any support for Satoshi wallets beyond pulling keys out of them.  

In the future I will not only implement a bulk-import feature, but also leverage pywallet code to do a direct import of the Satoshi wallet, but with a warning to stop using the Satoshi wallet (perhaps a print-backup-then-delete option).  Until then, just create a new wallet and send it some money.

The single-address-import function was aimed more for vanity-gen addresses and Casascius physical bitcoins.

Good decision.

btc_artist,

That is exactly right.  There's actually a warning box when you decide to print a paper wallet that warns you that imported keys are not part of that backup.  However, that's why there's also a wallet option labeled "Backup Individual Keys."  Clicking that gives you a list of private keys that you can manually copy/save/print (and a checkbox for imported-keys-only).  The goal was to allow you to be able to get your individual keys if you want to import them into another program, or just create a imported-key-backup to supplement your deterministic backup.

Just FYI:  I already applied those patches to the codebase and verified that they don't affect Armory running in Windows or Linux.  The only thing that might need to be modified, still, is the Makefile (but I'm pretty sure that was patched, too). 

After Joric posted, I patched, tested and committed it, then modified the directions slightly and posted them on the Building Armory from Source.  Probably doesn't fix your problem, but it's worth mentioning since I don't think I responded to Joric's post directly.