1. How much memory does 32-bit Windows support?

I'll try to explain this as simply as I possibly can...

You can have as much as 64 GB of RAM with 32-bit Windows, but there will be a hole between 3 GB and 4 GB.

64 GB? Yes. How is that possible? Well, Intel processors for a long time have had a feature called PAE (Physical Address Extension) that adds another 4 bits to the 32-bit limit of Windows, making it effectively 36 bit.

But...
A few caveats:
- If you have only 4 GB of RAM, you'll see just 3 GB because of the hole between 3 GB and 4 GB.

- If your CPU doesn't have PAE, you're stuck with 3 GB as the limit. Go to My Computer - Properties (in XP) to verify you have "Physical Address Extension" listed in your system information.

Also, processes in 32-bit Windows will see 2 GB of memory. But they won't see the same 2 GB. They'll be moved around by Windows so that all of your memory gets used (it's called multitasking!). So there is no "2 GB limit" as some might have you believe. The real limit is 3 GB, or even more if you have PAE.

2. What is different in 64-bit Windows?

The first thing that's different, you can access up to 16 EB (exabytes) of RAM! That's 8 million 2-TB hard drives!

But there are a few more things you need to be aware of:
- 64-bit Windows uses up 60% more memory and disk space than 32-bit Windows due to the doubling of pointer size
- You may have trouble finding 64-bit drivers for older hardware
- 32-bit software will still run perfectly on 64-bit Windows, thanks to WoW (Windows on Windows) emulation
- 64-bit Windows allows you to access all 4 GB of memory when you have 4 GB installed (not just 3 GB like 32-bit Windows)
- There is no memory hole in 64-bit Windows
- Each process can use more than 2 GB of memory
- Some CPU-intensive operations will complete faster if they take advantage of 64 bits (up to 5 times faster!)

Overall, if you have 4 GB of RAM or more, you should install 64-bit Windows to get rid of the memory hole. If you have 3 GB or less, you should stick with 32-bit Windows, because 64-bit Windows will eat up 60% more of your precious RAM.

My Experience - Going from 2 GB to 4 GB

I'm running 64-bit Windows 7 on my machine, with 4 GB RAM. It runs much more smoothly than it did on 2 GB of RAM. I installed 64-bit Windows 7 on 2 GB of RAM. Don't do it. It caused my memory usage to go up from 50% to 80%. Now, with 4 GB, my memory usage is down to 40%.

So, if you have 3 GB or less RAM and aren't planning to upgrade it right away after installing 64-bit Windows, don't install 64-bit Windows. It will eat up too much of your RAM.

Today I just discovered a neat little WPF graphing library called D3 (DynamicDataDisplay).

It's amazingly architected so that it's fast and extensible. Although it requires .NET 3.5, I was able to downgrade it to .NET 3.0 by using LinqBridge, a free library that emulates 99% of Linq without requiring .NET 3.5.

Actually, LinqBridge deserves a topic on its own - there is literally no reason for you to require .NET 3.5 in your apps, unless you use Linq-to-SQL. Linq-to-Objects is 99% emulated by LinqBridge.

To .NET library developers: start distributing .NET 3.0 versions of your libraries using LinqBridge, so that my Vista users don't have to download .NET 3.5. Saves me a boatload of headache as an ISV.

So, back to the main topic. If you're looking for a WPF line plot library that's free or simply want an example of how to build a WPF control library the right way, just take a look at D3.

Those are my findings for today. I guess it's been an exciting day!

So, it seems Moore's Law is at it again. And those who are not aware of it (by now) will be left in the dust. Read this article and you'll know what I mean.

First, I must warn you that you may be offended by reading this article. If you are an ardent fan of Google or Apple and/or a hater of Microsoft, you may not like what I'm about to tell you. That's fine. Just be prepared, if you do plan to read on.

Yesterday I installed Windows 7 on a 5-year-old laptop with 512 MB RAM and only 7 GB of free disk space. It installed (surprise!) and ran flawlessly! It even ran smoother than the XP installation I had on it before. Probably because with all the service packs, XP has actually become more bloated than Windows 7.

Now, I want you to note the specs: 512 MB RAM, 7 GB of disk space. Impressive. A high-end PC from 10 years ago would've had these specs. So literally, Windows 7 supports a decade of computers!

But what's more fascinating is the mobile arena. Currently, Apple is still dominant and yet still afraid to lose its iron grip on the iPhone. On the surface, Apple appears to be very friendly to developers, but behind the scenes they are the control freaks they've always been - I'm looking at you, Steve!

Anyway, there are quite a few frustrating things about the iPhone. First, you can only sell your app through Apple's app store and it has to be approved by Apple. Second, there is no Flash on the iPhone, and no web browser other than Safari. This ought to raise eyebrows and even get Apple into legal trouble like Microsoft got into trouble with IE and Windows, for supposedly abusing their monopoly. But it seems only Microsoft is the unlucky one.

Next we have Google's Android OS, which is a commendable OS. It has everything. It is, for mobile devices, like Windows is for PCs. It is open to developers and developers can share & sell their applications without Google's approval. The only "problem" with Android is that there are too many variants of it. I wouldn't really call this a problem. It's a natural drawback of having to support a wide variety of devices. I mean, look at Windows: Windows XP, Windows Vista, Windows 7, and do you hear Windows developers complaining about it? No. They've adapted to it. They expect it. Only Apple fanboys complain about "too many variants" of Android because they don't understand it.

Next, we have Windows Mobile. Or do we? Windows Mobile is laughably dated and limited. Microsoft seems to have lost it completely on the mobile front. But have they? Or are we all missing something that's actually staring us in the face? Are we missing the elephant in the room?

Yes.

Let me introduce you all to the elephant in the room. It's Windows 7. Yup. And it's moving to smart phones. Remember, I installed Windows 7 on a PC with 512 MB RAM and 7 GB of disk space. Why do you think Microsoft decided to actually support old devices this time, and not raise hardware requirements like before? Why do you think Microsoft developed multi-touch capabilities in Windows 7? Is it for all those giant useless tablets out there? Is it for all the giant useless netbooks out there? No! It's for MOBILE PHONES!

Suddenly it all makes sense. But wait, I hear you say, how can Windows 7 ever fit on a phone? Simple: There are smart phones today that have 512 MB of memory. There are smart phones today that are extensible (via microSD card) to as much as 32 GB of storage. Last but not least, is Intel's Atom processor. It's an x86 processor (just like the desktop ones) with speeds of nearly 2 GHz! But the best thing about Atom is, it's extremely low-power and low-heat.

So the situation is now ripe for Windows 7 to start transitioning onto smaller and smaller mobile devices. There are MIDs / UMPCs currently available with screens of 4.8" which is about as small as a PSP. They fit in your pocket. And they run Windows 7. The leap from here to mobile phones is tiny. There is no leap. It's a baby step.

In conclusion, if you thought Microsoft lost the mobile space, you are totally mistaken, and you'll be in for a shock next year. All the Android and Apple fans out there won't know what hit them. Better get on for the ride.

As for what I'm doing to prepare, I'm back developing client-side Windows applications. I use WPF and .NET. They are extremely easy and fun to work with. Microsoft has always had the best support for developers, which is what helped them gain (and maintain) a monopoly for so long. Windows has more software than any other OS, and will continue to do so for many years thanks to Windows 7.

Apparently some of my older blog articles were really quite popular, because today I stumbled upon something I wrote 5 years ago:

Application.DoEvents() - The call of the devil.

DoEvents messes up the normal flow of your application. If I recall correctly, DoEvents is asynchronous which means it terminates before the application has actually processed any outstanding events, so if you're using it in a procedure with many sequential statements, calling DoEvents causes a huge disturbance whenever it's called. Basically, if you find yourself needing to call DoEvents anywhere, think about starting another thread instead, or using asynchronous delegates.

Imagine this if you will: You have a button on your form that, when clicked, does some complex processing. During the complex processing it also intermittently calls DoEvents to keep the application's user interface "responsive" -- not the best method, I would have used async delegates, but we're talking about a mediocre programmer here. Anyhow, the user sees the application still responding and no indication that there's some processing going on. So the user clicks that button again WHILE the processing is going on! The button responds to the event and starts another processing thread but it isn't actually a thread here, I hope you get what I'm saying. So, like I said earlier, DoEvents screws up the flow of the application too easily.

I want to comment on this further, because I don't think I was really clear at the time.

DoEvents really is evil. Horribly, horribly evil.

In fact, the whole Windows Forms threading model is deficient. The fact that you can set a Label's Text property from any thread is a clear warning sign that something is wrong. This is only now becoming evident to me after having worked for a few months with WPF, which doesn't allow any such nonsense. It will throw an exception if you try to execute UI code on a non-UI thread.

DoEvents should have never been included in the .NET Framework, because it gives a programmer the illusion that you can get by without worker threads. You can't. If a programmer wants to keep the UI responsive while another task is executing, that programmer should use a background worker thread. To update the UI from that thread (to show changing progress), the programmer should call Invoke on the appropriate control and pass in a delegate that will be executed on that control's UI thread. Not only does this serve to keep things consistent, but it also reduces the chances of odd bugs related to threading (which are always difficult to troubleshoot).

So, in short, avoid DoEvents and do what good programmers do: use worker threads. WPF makes it easy (and dare I say fun?) to create & use worker threads, and it's perfectly safe. Windows Forms has a somewhat sketchy UI threading model, mainly because it still has to deal with Win32 API behind the scenes. This is also a reason why you should migrate to WPF and stop releasing production software built with Windows Forms. The sooner Windows Forms dies, the better.

So today will be the last time I use System.Diagnostics.Process.Start without explicitly setting UseShellExecute to true.

Why?

Oh, it started out innocently enough - I was building a simple load testing tool in C# to load-test a custom ASP.NET HTTP handler I was implementing. The tool would basically run wget many times to simulate HTTP requests. Don't know why I didn't just use System.Net.WebClient (because I certainly could've), but I guess I just had wget on my mind.

Anyway, so the tool ran fine but it slowly leaked away memory and handles. Initially I thought it was my HTTP handler. So I ran it with an invalid URL, just to test if maybe the load testing tool itself had a memory leak. Sure enough, it did!

The leak seemed to be coming from my call to System.Diagnostics.Process.Start.

So I did a quick Googling and it turns out that System.Diagnostics.Process.Start causes the child process to inherit handles from the parent process. That means, whatever process you spawn (e.g. Internet Explorer), that process gets all of the handles owned by your process! So even if you free up handles in your process, if the process you spawned is still running, your handles won't really be freed because the child process is supposedly using them. A more detailed explanation can be found here.

As it turns out, the CreateProcess call in System.Diagnostics.Process.Start has a certain parameter that is hard-coded: the bInheritHandles parameter is hard-coded to true. Well, that's a shame now isn't it?

So what can we do instead?

I would prefer any solution except calling the CreateProcess API directly, since API calls are ugly. One option is to set ProcessStartInfo.UseShellExecute to true before calling Process.Start. However, you won't be able to redirect stdio. In fact, if you want to redirect stdio you either have to accept MS's buggy implementation or roll your own with pipes, API, and all that funky stuff.

One last thing...

With the Process class, be sure to explicitly Close the process object (not just Dispose) after starting the process or after you're done using it, because otherwise the process handle may leak.