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.

Not even two months after I wrote this article, where I described why desktop .NET is finally ready for take-off, the news is out that Visual Studio 2010 is a managed (.NET) application. Finally, Microsoft are setting an example.

What does this mean to you, the developer? It means that if you've been sitting on the sidelines regarding .NET and are still coding with *gasp* MFC, or Win32 API, it's finally time to move to .NET.

This also means that WPF is here to stay, unlike its predecessor - Windows Forms. Many early adopters of .NET were under the impression that Windows Forms would be supported and actively developed for many years. As it turned out, Windows Forms was a dead end.

The good news: WPF is now fully endorsed by Microsoft through Visual Studio 2010. This means WPF is finally mature enough for adoption. Plus, it's included in Windows 7 and Windows Vista. You don't even have to distribute the .NET Framework (provided you target version 3.0 and not 3.5 or 4.0). Visual Studio now makes it easy to target a specific version of the .NET Framework, unlike some of the early versions (VS 2003/2005).

Personally, I think we're going to start seeing an explosion of new WPF apps in the coming months. It could be like the explosion that happened with the iPhone (and I'm not talking about the screen).

These are the most exciting times for Windows developers since Windows 95.

So gold just shot up above $1090 today - a new all-time high, oil is up above $80 a barrel again, and I'm getting emails in my inbox about contract opportunities with rates of $60+ an hour. So what does all of this have to do with Bob Prechter?

Who is Bob Prechter anyway? For those who don't know, Robert Prechter is a semi-popular financial analyst who occasionally pops out of his wooden shed to warn us all about the impending danger of deflation. Much like Mike "Mish" Shedlock of globaleconomicanalysis.blogspot.com, he was right in the fall of 2008, when the price of everything collapsed spectacularly. However, most prices have pretty much recovered since then and some (like gold) are actually making new highs!

Robert Prechter has an interesting theory, however: that short-term market movements are entirely random - influenced by a recurring cycle known as the "Elliott Wave," which is based on the Fibonacci ratio of 1.618. In short, markets are irrational, but predictably so - they can be predicted by applying this Elliott Wave theory.

I agree with Robert Prechter on the "markets are irrational" bit. I even think he might be on to something with the Elliott Wave theory. But as far as deflation goes, I am strongly against it. I do not believe deflation can happen in a system of fiat currency (where money is created out of thin air).

One example that deflationistas often like to bring up is the case of Japan in the 1990s, and how allegedly Japan experienced deflation from 1990 to now. That is just totally wrong. Japan experienced roughly -0.5% inflation for 3 years. That's it. That's all the "deflation" it ever experienced. Japan is not a valid example of deflation.

One other example some deflationistas hearken back to as a last resort is the Great Depression. However, during the Great Depression the US was still on a gold standard, so that example is totally invalid in today's fiat world.

So given the track record of these "deflation" predictions, why does Robert Prechter think that "this time is different"? And where is he now, when his predictions appear to be falling apart by the day?

Let's talk a bit about assumptions and what can happen if you make wrong ones and never bother to correct them. The example in this article will, fittingly enough, be Microsoft - and specifically .NET.

.NET is supposed to be an OS-independent API. It was designed to hide most of the OS behind a convenient, consistent API that does not expose any underlying OS details. That's what I mean by "OS-independent API." But it turns out, Microsoft is still a little confused about what "OS-independent API" really means.

Starting with .NET 1.0, Microsoft has continually made the assumption that the less unmanaged code they had in their implementation of .NET, the better. This is best evidenced on this web page - called "Is .NET a Win32 Wrapper?"

In reality, an OS-independent API does not have to be entirely OS-independent. Only the API - the part that the programmer sees - is OS-independent, hence "OS-independent API". The implementation need not be OS-independent, and should not be.

The developer does not care how many unmanaged calls are happening behind the scenes. The only thing the developer cares about is the API, because the only thing the developer sees is the API. As long as the API is OS-independent, the implementation of the API does not matter.

So why is Microsoft reinventing the wheel by reimplementing basic controls like buttons in Windows Forms, and then again in WPF? Why not just create a thin wrapper around Windows API, like SWT? (SWT, by the way, is a thin Java wrapper around standard OS controls like Button, TextBox, etc.)

Right now, .NET is completely lacking a thin wrapper for Win32 API. WinForms and WPF are both thick wrappers. They only call the Windows API for extremely low-level tasks like GDI. They are more like Java Swing than SWT. The trouble is, when you build a thick wrapper, you inevitably run into performance issues and UI inconsistencies. You're also reinventing the wheel, often unnecessarily.

Another issue you run into when building a thick wrapper is size. SWT is 2 MB (small enough to fit into the L2 cache of a Core 2 processor!) because it's a thin wrapper. You also have the issue of maintainability: a thick wrapper is more complex and therefore harder to maintain than a thin wrapper.

Sure, there are advantages to thick wrappers. I'm not sure exactly what they are, but there probably are some. However, developers often prefer simple, clean, and small applications. And so do users. So, Microsoft, where is the SWT for .NET?

It was 2002. I had just finished developing Dacris Benchmarks 4.9 using pure Win32 API. I was proud of myself. It was the first 100% Windows API application I had developed. No more Borland OWL crutches. It was a clean start. The application went on to become a phenomenal success. But something was not quite right in the land of Windows development. A major new player was just entering the arena. Its name was ".NET", previously known as NGWS, and it promised to change everything.

From the beginning it was clear that this .NET thing was not going to be popular right away. It was a gigantic change at a time when the world was still trying to recover from the collapse of the dot-com bubble. It was, furthermore, a behemoth in the days when broadband Internet was still a rare commodity. Weighing in at a hefty 23 MB, the .NET redistributable was just too much of a penalty to pay for the convenience of developing "managed" applications with a truly object-oriented language.

From the developer's perspective, .NET was amazing from day one. Sure it still had some kinks which ultimately led me to develop NetXP, but as a development paradigm it completely overshadowed the archaic Windows API. It was a dream come true - garbage collection, Windows Forms, remoting, and a whole bunch of other goodies.

.NET immediately took off on the web. Within one year, nearly every major company was developing ASP.NET web apps with .NET 1.1. The release of Windows Server 2003 only served to accelerate that trend even further. .NET web development soon reached a frenzy as the advantages of ASP.NET over other technologies (PHP, JSP) became evident.

However, something was wrong on the desktop. Three years after .NET came out, virtually no .NET desktop applications were being developed. The reason? Most ISVs, especially the small ones, saw the gigantic size of the .NET framework and the support headache associated with its deployment as a major roadblock to adoption. Even though .NET was great for developers, it was not so great for end users.

The fact that Windows XP SP2 and SP3 did not include the .NET Framework only made the situation worse. For most ISVs, it was clear that if they wanted to develop Windows apps, they would have to continue using Windows API, until something better came along.

Well, something better finally did come along in 2007. It was called .NET 3.0 (or WinFX), and it was embedded in Windows Vista. Suddenly, the deployment obstacle to .NET adoption was removed. Now, there was really no reason for ISVs not to adopt .NET. Or was there?

The reason was one word: "Vista." This word soon came to be reviled among the Windows community. Nobody wanted to touch Vista with a ten-foot pole. The truth is, Vista was plagued with problems for at least a year after its RTM. Finally, in 2008, the initial Vista problems started getting resolved and users started adopting Vista at a more rapid pace.

Today, there is a two-word reason why .NET adoption on the desktop finally makes sense: "Windows 7." Windows 7, which includes .NET 3.5 by default, is leaner and meaner than its predecessor. Every PC that can run Vista can run Windows 7 and do so with better performance. In a few months, the combined market share of Windows 7 and Windows Vista will exceed 35%. It's practically there right now.

From an ISV's perspective, however, it is not only market share that counts. It is also the value per customer within that segment of the market. For example, a Mac user typically has 4 times more value than a Windows user because Mac users tend to buy applications more readily than Windows users. Now when it comes to Windows XP versus Windows Vista/7, the Windows XP user at this point is basically stuck in the stone age. The odds of a Windows XP user purchasing a new application are much lower than the odds of a Windows Vista/7 user purchasing a new application. The Windows XP user generally runs old applications on old hardware, and is very conservative when it comes to making new purchases. The result is that the value of a Windows XP user is (sorry XP users) generally lower than the value of a Windows Vista/7 user from the point of view of an ISV.

Anyway, to make a long story short, despite a market share of "only" 35%, Windows Vista/7 users are now actually a more important market for ISVs than Windows XP users. This is only now starting to happen, after about 8 years of XP dominance.

What does this mean for ISVs and the software industry as a whole? It means that .NET will finally be adopted on the desktop. .NET makes development much easier, there is no question about that. However, for a long time there was a question about whether Microsoft would embrace or at least continue to support .NET. That question has finally been answered. .NET is here to stay and the future for Windows applications is .NET. Windows API has finally come to the end of its life. It's an exciting time to be a Windows developer.