Recap

First of all, let me clarify that I think C is a great language and excellent for the development of low-level system software. I think C++, specifically, adds an extra unnecessary layer of complexity which makes it less suitable for low-level work but in some cases it's the only option. I would readily choose C over C++ for low-level software projects (e.g. drivers).

When dealing with C code, I would aim to write as little code in C as possible and provide an interface for writing the remainder of my code in another "safer" language, such as C# or Java. By "safe" here I mean something that is detached from the OS, so that it has a lower risk of corrupting the system's memory or file system upon failure. Again, C# and Java run in virtual machines which provide an extra layer of safety should things go horribly horribly wrong. The layer of safety may not be perfect, but it's better than having no layer of safety at all.

Also, when I said C++ sucks (sort of), I meant that C++ sucks for most types of applications (e.g. GUI or web applications). There are some cases where C++ is a decent choice, but those cases are rare and limited in scope. For the most part, C++ is just plain awful, because it consumes more time and produces more lines of code than either C# or Java. It also induces programmers to produce substandard code and has the inherent property of creating very difficult-to-debug code.

There are certainly cases where using C++ is unavoidable. When such a case arises, it does not usually mean that C++ as a language is in some way superior. It just means that C++ is not completely useless. I still write C++ code occasionally, because I have to.

The Debate Goes On

Recently I came across an article that attempts to refute my claim that, in most cases, C++ sucks.

I have a couple of remarks related to that article:

"What do you do when writing cross-platform code in C and you need to make heavy use of the filesystem?"

I assume by "heavy use" here you mean low-level operations. In that case, you need to make a file system driver in C (or whatever language the OS supports for drivers) and expose APIs that can easily be called from a higher-level Java or C# client application. Again, minimize the integration between high-level application code and low-level driver code.

"On that note, nobody, and I mean nobody should be using C++ without Boost"

If that is the case, why is Boost not a feature of C++? Maybe it will make its way into C++0x? The very fact that Boost exists indicates that C++ is a deficient language. Boost is merely a patch over those deficiencies. And when I talk about C++, I'm also referring to the standard library as well as the language itself.

"I guess the author has never worked on embedded software or real time systems. Or games for that matter. Or I guess anything other than canned business software."

Actually I have built games using DirectX in the past. I can confidently say that C++ was not needed for any feature. Given the extra time that C++ adds to the development of any app, being able to use any other language (and minimize the use of C++) is quite important.
Here is a simple 3D demo I built with OpenGL and Java in 4 intensive days of coding: http://www.dacris.com/article.aspx?name=demos. I probably would not have been able to perform such a feat with C++.

"C++ has a keyword called sizeof() that lets you determine how big a pointer is."

Again, that's nice, but I'd rather not use pointers and not write sizeof() statements all over the place. The time I save by not thinking about pointers (and by not reading code that contains pointers) is enormous.

"Perhaps an even better answer is in order though. I won't use any Gui toolkit, because I won't develop GUI code in C++. Why would I use the language for something which it doesn't excel at?"

Exactly. If you're content with building console applications, use C++. No problem. But for any kind of UI, C++ just sucks.

"C++ has a very strong, flexible type system."

Flexible, yes. But the problem is it's also lacking some very useful features compared to C# or Java. For example, how do you enumerate a class's fields or properties in C++? How do you detect that class A inherits class B at runtime, or get an object's type at runtime? In C# this is called "reflection." There is nothing like it in C++. For this reason, it's very difficult to do generalized serialization in C++. In C# and Java you can literally serialize any type.

"Code generation"

I can't think of any reason why you would ever want this. Macros and templates are a symptom of bad design. Instead of using code generation to deal with repetitive code, why not build a reusable component? Generated code is hard to maintain, hard to understand, hard to verify, and hard to debug.

Write as Little Code as Possible

Let me end by saying, I'm not a "substandard programmer." I'm merely a lazy programmer. I like to write as little code as possible. I keep track of the lines of code in all my projects, to make sure that number stays low. I guess if I was paid by KLOC I'd be pretty broke.

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.

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.

It was 2001 when I first started developing with Win32 API. Back then, Win32 API was the only way to develop a Windows application. Sure, you could use a variety of different wrappers, including MFC and Borland's OWL. However, the Win32 API was always at the core of the application. This resulted in applications having a very consistent look & feel. Every application looked like it belonged in Windows.

In 2002, a new phenomenon started, called the .NET Framework. The .NET Framework was supposed to be Microsoft's decision to improve developer's lives by replacing C++ with managed code (written in any language). At least that's what I hoped back in 2002. However, from the very beginning it became clear that Microsoft's intent was not to replace Win32 API with .NET but in fact to carry two separate development frameworks, and ultimately to confuse and alienate Windows users and Windows developers.

Let's look at what "mistakes" MS made with .NET that have been causing ongoing pain for Windows developers.

1. Not including .NET in Windows.

Microsoft has an ongoing policy of keeping .NET & Windows separate. For some bizarre reason, Microsoft will not distribute the latest version of .NET with the latest version of Windows. Windows XP SP1 could have included .NET 1.1. It didn't. Windows XP SP2 could have included .NET 2.0. It didn't. .NET should've been a required update from the very beginning. It should've been an inextricable component of Windows, just like IE. Though it's unclear which version of .NET will ship with Windows 7, what is clear is that when a later version is released, Microsoft will make damn sure that users won't even know about it.

2. Not making the Win32 API obsolete.

With Windows Vista, Microsoft could've made all new APIs available only to .NET developers. Why do that? To discourage Win32 API development. To make it clear to developers that .NET is the future. Starting with Vista, Microsoft should've moved all of its innovation into .NET. Instead, they added new features to Win32 API! Features that they didn't add to .NET! In other words, they showed that Win32 API is still the only way to develop Windows applications.

3. Not setting an example.

Microsoft could have migrated all of its apps to .NET. Office 2007 should've been entirely written in .NET. Visual Studio .NET (first version) should've been written in .NET! Microsoft should've set an example, that .NET is the future. Instead, they keep writing apps in MFC or Win32 API. Clearly, MFC and Win32 API is still the future. I challenge you to find any major Microsoft application written in .NET.

4. Reinventing the wheel.

Rather than using native Win32 API controls in .NET WinForms applications, Microsoft instead decided to reinvent the wheel, coding an entire UI toolkit from scratch using managed code. What for? Sun already did that! It's called Java!

The inconsistencies in look & feel in .NET are hideous, but even worse are the inconsistencies in behaviour. .NET 1.1 was notorious for its non-standard controls. It's the reason I developed NetXP. It's the reason why I had to write a gigantic .NET wrapper around Win32 API. .NET itself should've been that wrapper. Here's an exercise: Try popping up a balloon tooltip (a feature of Win32 API in Windows XP) in .NET 1.1.

This is the biggest issue with .NET, and Microsoft still hasn't fixed it. Take the XAML menu for example. It's totally different from the standard WinAPI menu. Even the ClearType looks different in a XAML app! This decision by MS not to enforce OS UI conventions will lead to a wide range of UI variation on Windows, and will ultimately lead developers (and users) away from Windows, and toward Mac or even Linux.

Conclusion - My Message to Microsoft

It's painful to develop apps in Windows API (or MFC) in 2009. You (Microsoft) could've changed that. You had the opportunity, with .NET, to create a new way of programming Windows. You blew it. Until you fix the 4 issues above, I will be programming in Java. Java is everything .NET is and more. Java is cross-platform, free software, and has a wider user base. Why should I limit myself to Windows when the choice I have is between Windows API (a 25-year-old technology) and .NET (a clone of Java that runs only on Windows)?

To those out there who remember Visual Basic, .NET is another Visual Basic. VB was great for RAD (Rapid Application Development). So is .NET. But the problem with VB was that it was non-standard. It didn't wrap the Win32 API well enough. The same is true for .NET. Now, if .NET was going to be cross-platform, I'd understand. But it was never intended to be cross-platform. Microsoft totally blew it with .NET. Developing a Windows application in .NET is as ridiculous as developing a Windows application in Visual Basic.

Windows 7: A Review

By Dan Tohatan

In 1994, Microsoft unveiled a user interface that was truly revolutionary at the time. Code-named "Cairo", it was to become the interface of the new Windows 95 operating system. When Windows 95 came along in July of 1995, the new shell (Windows Explorer) totally surpassed the old Program Manager / File Manager combination, which had been a staple of Windows since Windows 3.0. Windows 95's unparalleled multimedia capabilities became evident very quickly.

I remember how amazed I was when I first saw the Windows 95 boot-up screen, in all its 256-color beauty. Microsoft got it. The world was moving toward true color displays. No longer were UIs going to be boxed into the 16-color (or less) paradigm which had dominated displays since the 1980s. A revolution was beginning, and Windows 95 was going to lead it.

Fast-forward to the present, and a new revolution is beginning. This time, it's a move from bitmapped graphics to vector graphics. It's a move toward 3D-accelerated vector graphics. You can see it in the new Web 2.0 websites out there: smooth gradients, subtle 3D effects, animations, and heavy use of mouse-over events. You could call this the second UI revolution.

Windows Vista was supposed to bring in this new UI revolution. However, Microsoft bit off more than it could chew. Vista over-promised and under-delivered. The result was, as everyone now knows, a total disappointment. Today, almost 3 years after Vista's release, the market share held by Windows Vista is around 25%. The market share held by XP? 60%. What's even worse for Microsoft is that Mac OS X and Linux have been gaining feverishly thanks to Vista's lack of stability and incredibly slow performance.

Windows 7 is what Vista should have been. It is to Windows XP what Windows 95 was to Windows 3.1. I would encourage everyone reading this review to go out and download & install the Windows 7 Release Candidate. I have (so far) only used the OS for a day, and I am extremely impressed.

The most interesting thing about Windows 7 is that it's the first Windows OS to have lower system requirements compared to the previous version. While it has been demonstrated that Windows 7 can be installed on a system with only 512 MB RAM, it's not a realistic requirement if you want to run the latest applications. A system with 1 GB of RAM or more should be able to run Windows 7 at least as fast as it would run Windows XP. Also, while Windows 7 requires 16 GB of free disk space to install, it only ends up using about 9 GB, which is far better than Vista.

I'm going to start this review by looking under the hood - at how the OS performs. One of my biggest problems with Vista is the size of the WinSXS folder. Apparently, in order to solve "DLL hell", Microsoft decided to keep every single version of every DLL forever. Before I installed Windows 7, my Vista SP1 WinSXS folder was 7 GB, with no apps installed. This was after I ran the SP1 clean-up tool. Before that, it was over 10 GB. With Windows 7, it's only 4 GB. Seems MS was able to cut out a whole 3 GB from the WinSXS folder, which is excellent.

Another thing that MS improved with Windows 7 is the speed of shutdown. While boot-up is about the same as Windows Vista, shutdown is noticeably faster. Also, the speed of installation (if you're doing clean install) is much faster than a comparable Vista installation. I remember when I installed Vista that it seemed to take longer than an equivalent XP install. Windows 7 actually installs faster than XP.

I remember with Vista having issues with the TrustedInstaller. It would just start up randomly and my hard drive would start thrashing, and my system would slow to a crawl. Windows 7 seems much more quiet (in terms of hard disk activity) and CPU usage is actually at 0% most of the time! It's incredible how Windows 7  release candidate (not even final release) outperforms Vista so much. The final release will probably be even better.

Moving on to the UI, the first thing you notice about Windows 7 is how much cleaner it is compared to Vista. Gone are the incessant notification popups or the glaring UI inconsistencies that made Windows Vista such a pain to use. UAC is totally gone. In Vista, just about everything you did would pop up a UAC dialog. It was extremely annoying. In Windows 7, the UAC prompts, even where you would obviously expect them (e.g. Task Manager), are totally gone. It's a mystery what MS did here, but it's a really good thing. I really hope that this is permanent and that UAC doesn't come back in the final release.

The other pleasant surprise I had with Windows 7 was that MS added new accessories! This is the first time MS did something like this since (probably) Windows 95! Not only that, but the existing accessories (Wordpad, Paint) have been totally revamped. You will also notice the UI consistency in Windows 7 (versus Vista). Finally, I'm pleased to announce that MS has finally removed the "Install New Font" dialog that still had a Windows 3.0-like UI. This calls for a major celebration! This dialog existed in Windows - unchanged - since 1990! Now it's finally gone!

What I really like about Windows 7 is its new Libraries feature. A library is a special folder that is actually the aggregate of multiple folders. Libraries makes organizing files so much easier. Microsoft also implemented a fairly complete set of filters (or views) for each library. For example, you can view your music by artist or by album. The views are customized to fit each library type. For example, the Music library only has views that are relevant to music.

But it's the small things that make Windows 7 so impressive. For example, when copying files, the progress is shown in the taskbar as the background of the taskbar button, and it updates in real time. So you can just look at the taskbar to see the progress. You no longer have to Alt+Tab. Also, the extensive use of mouse-over effects really adds to the usability of the OS. For example, hovering over a taskbar button shows you a preview of the window that corresponds to that button.

Windows 7 is probably the first Windows OS for which screenshots aren't enough. This is because of the extensive use of mouse-over effects. Screenshots just don't do it justice. When I looked at various screenshots of Windows 7, I thought "what a bad UI design!" But in practice, the UI design is very usable. Not only is it usable - it's fun! This is the first time I'm having fun using Windows since Windows 95!

To conclude, you really have to use it to fully appreciate it. There are many pleasant surprises in this OS. When I switched to Ubuntu back in 2007, I never thought I'd see another version of Windows as great as Windows XP was. Well, it turns out I was wrong. Windows 7 is the new Windows 95. Windows XP was an evolutionary change. Windows 7 is a revolutionary change. Windows 7 leaves its competition in the dust. In the end, Microsoft still gets it.

APRIL 2009 --
The economic downturn leaves no company unaffected. MSFT is finished.
July, 2008 Bill Gates stepped down. The company will not release one single product
worthy of investigation this year. IE 8 has been surpassed by Mozilla and there is
absolutely nothing MS can do to resurrect IE. The major theme this year will be the
death of Microsoft.

In the open source arena, Linux continues to make advances. At some point this year,
Linux market share will rise dramatically. There may be an event which triggers
a mass migration to Linux on the desktop. My belief is that an amazing software
product comes out which only runs on Linux. People are so drawn to this product that
they are willing to ditch their Windows OS (or at least dual-boot Linux with it). The
product will be intentionally designed NOT to run on Windows.

In the hardware realm, Intel will be going the slow & steady route. AMD is finished.
The video card industry is finished. They've pushed it too far. PSUs can't handle
3 cards in SLI. It's pure madness. NVIDIA will suffer this year, and so will AMD,
because of its ownership of ATI. All graphics card manufacturers will suffer. I don't
think we will see any further advancements this year in graphics hardware.

In addition, the recession means less spending on high-end hardware. Therefore, any
high-end hardware product will drop in price dramatically. Look for deals on top-notch
video cards and super-fast memory. DDR3 will get very cheap, very fast.

I almost missed it - the biggest story this year will be Apple. Specifically, the
iPhone is taking over the world. Those who were slow in adopting blackberries or other
smart mobile devices will now swarm to the iPhone. The iPhone will replace the iPod,
cell phones, digital cameras, video cameras, and many other portable devices. The
iPhone is part of the new iLife trend which is all about unifying mobile devices into
one incredible everyday-life-enhancing device that you can take with you everywhere.

Continuing the trend with the iPhone, it will soon start to replace devices used in
industry. For example, on construction sites, the inclination of the ground will be
measured using an iPhone. In your car, instead of having a real map, an iPhone plus
Google maps will do.

The trend towards minification of laptops (i.e. netbooks & tablets) will merge with
the iPhone trend. The trend is towards a fully portable computer (i.e. a computer you
can carry in your pocket). This computer will be capable of having all sorts of devices
attached to it (as peripheral extensions). It will be a virtual sensor - an extension
of the human senses.

Touch is the biggest trend in terms of UI. Without touch, a screen is nothing. Every
screen is going multi-touch. There will be a shift toward touch-friendly UIs.

In the UI realm, there is a growing trend towards 3D-ization of everything, even the
web. I believe 3D accelerated web browsers are coming soon. Whoever makes the first
move into 3D-accelerated web browsing will become famous. All UIs will be
3D-accelerated. The exact form that this will take remains to be seen. The idea is
that a whole new concept of "3D layout" will need to be developed. Web 2.0 is a first
step in this direction, with its pervasive use of realistic 3D gradients. These will
soon be replaced with real 3D surfaces (perhaps designed with Bezier curves and
ray-traced). Yes - real-time ray tracing. It will be very exciting.

On the topic of ray tracing, I believe ray tracing is slowly going to overtake the
old polygon + projection model that we're all so familiar with. The reason? Ray
tracing lends itself to parallel processing. In particular, photon mapping will soon
be done in real-time and scenes in 3D games will be rendered with photon mapping, for
unbelievably realistic lighting. The photon map will be precomputed for static scenes
to save processing speed. Models (meshes) will be made using Bezier splines, so that
meshes will be totally smooth (no more polygons!). The result will be unbelievably
smooth surfaces. It turns out that with ray tracing, splines (curves) are much easier
to process than polygons! Bottom line - the buzzword (or phrase) these days in
graphics is "real-time ray tracing".

Because ray tracing produces such realistic graphics, I believe we're trending toward
a world where a lot of the images you see as design elements on websites and other UIs
will be ray-traced, either in real time or rendered once and saved as an image. You
can quite easily imagine a building contractor having on their website a ray-traced
image of the inside of a virtual apartment, with such perfect graphics that you would
instantly be amazed. Ray tracing will become the holy grail in graphic design.

The biggest trend rising in 2009 is the use of portable computers for entertainment.
This will grow, over many years. Rather than performance improvements, improvements in
hardware will most likely be focused more on functionality rather than performance.
You're going to start seeing a lot more innovative input & output devices in the
coming years, directed mainly towards entertainment & improving day-to-day life.

Projecting trends into 2010, Apple will dominate the mobile arena. MSFT is history.
In the server & business world, MSFT is being replaced by Linux at a rapid pace. The
ever-present need for standardization means UNIX is becoming the de-facto standard
OS, similar to how HTML became the de-facto standard web presentation language. All
new software is built for Linux or some UNIX variant (like Apple's OSes).

Graphics cards manufacturers will continue to suffer. Integrated graphics comes on
in a big way this year. Intel now manages to capture 90% of graphics performance with
its latest integrated graphics chip + integrated memory controller & DDR3 RAM. The
idea of a separate graphics chip falls by the wayside and soon graphics cards will be
a distant memory of an ancient past. Why have 1 GB of dedicated video RAM when the same
RAM, at the same speed, can be allocated from system RAM? Soon, the GPU + CPU will
merge into one unit, much like the way math co-processors disappeared back in the 1990s.

The biggest trend this year is the realworldization of the virtual world. The idea
of taking the desktop computer outdoors. Custom sensors will become an enormous market.
E.g.: Imagine checking your iPhone's UV sensor when walking out on the beach on a sunny
afternoon. Or imagine connecting your iPhone up to a telescope to align it perfectly
with the moon on a clear night. A whole new computer (the "real world computer") will
appear, for this purpose alone.

2010 is when I believe a "Microsoft" will emerge in the real-world computer realm.
Apple will have competition later this year. I'm not sure who will be that next Bill
Gates but I'm certainly a contender.

In 2010, computers will start to replace books for casual reading. Already the Amazon
Kindle is making huge headlines, but this trend will fully take off only in 2010, when
90% of newspapers go bankrupt and everyone starts reading the news on their new
real-world computer.

In 2010, the support-based software model becomes the only viable business model for
software. The idea is you pay separately for licensing and support/customization. The
idea is that by paying for support you're guaranteed that the company will provide
that support. In other words, many companies lose potential clients because those
clients are afraid that the company might go out of business or that they might release
a new version of the software tomorrow that is fully incompatible with the old version.
This is the nightmare of every IT department. Naturally, business models that make life
easier for IT departments will grow. The idea of "we guarantee that we won't go out of
business" is a very seductive one for any IT department.

The home computer will remain, but it will remain as a sort of appliance where
data can be centralized. Its sole purpose will be the centralization of data. In other
words, it will become more of a server.

What is the future in terms of hardware? By 2011, we should expect 22nm processors
with 4 to 8 cores. Clearly, the trend will be towards parallel computing and more
integration as I believe Intel will finally merge the GPU & CPU into one with its
new "Sandy Bridge" technology which comes out in 2011. This technology will be as
revolutionary for Intel as the "Pentium M" was (which then led to the Core 2).

Intel will rapidly become dominant in the area of graphics, forcing AMD to adopt a
similar strategy of integrating its ATI chips onto its CPUs. This may actually give
AMD a competitive advantage over Intel, because let's face it - Intel's graphics chips
suck compared to ATI. I believe at this point NVIDIA will be begging to be acquired,
and guess who will acquire NVIDIA? Intel!

So the biggest story in 2011 will be the rise of Intel to total domination of the
desktop computing world. On top of that, the trend towards innovative display devices
that started with touch screens will intensify by 2011. I believe we'll see the first
holographic or projective displays in 2011. The idea is the image is projected onto
any surface. Imagine a pen that projects the daily news onto an 8.5x11 piece of paper.

Another example of an innovative input device would be an exercise machine that is
designed to interact with your desktop computer (or game console). For example, a
treadmill that corresponds to a virtual car driving around a city. When you run
faster, the car goes faster. The idea is to turn physical effort into positive UI
feedback, thus producing positive reinforcement and turning people into fitness
junkies.

PC gaming will make a comeback. Game consoles have been slowly replacing PCs when it
comes to gaming. However, I think this trend may actually reverse. People will soon
discover that they can connect their PC to their TV and save the money that they
would otherwise have spent on a game console. Thus, PC-to-TV output devices will
become extremely popular. Also, on your PC you can obtain games for free (via
downloading) and you can obtain an unlimited number of games, and you can even make
your own games. Therefore, I don't believe that PC gaming is dead. In fact, I think
it will come back in a big way, mainly because of the current economic downturn
which I expect to last well into the next decade.

So I've met a couple of people (who shall remain nameless) over the past few weeks who insist that C++ is better than Java. I am truly impressed by the stubbornness of these people. So here goes. I'm going to argue once & for all why ...
OH NO! I'm not falling into that trap.

I'm just going to pose questions that any developer should ask before choosing either C++ or Java. NOTE: I'm not advocating just Java here. Mono has comparable features, or .NET if you don't care about cross-platform.

Before I start I'd like to mention that I was once a die-hard C++er. I started programming in C++ back when I was 11, but 5 years after that I found .NET and never looked back. So I technically have 5 years of experience with nothing but C++, and I have used it off & on and will continue using it whenever I absolutely need to.

1. Ant vs "make"

What's better? Ant or "make"? Would you rather write a Makefile (no extension) in a proprietary hard-to-read language, with a text editor like "vim", or would you rather write an XML file (build.xml) which could easily be generated by a tool (perhaps with a GUI)?

Secondly, which one has more capabilities? Ant or "make"?

2. Pointers

Do you really need pointers? Do you really need to convert integers (memory addresses) to objects? Are you willing to put up with the hassle of manually collecting garbage (using "delete" statements)? How are you going to test that you don't have memory leaks?

What if the architecture you're working on uses 48-bit memory addresses and you want to port your program to an architecture that uses 64-bit memory addresses? Have you thought about how you're going to do that? Because you know, in Java you don't need to think about any of this.

3. CPU Architecture and OS

What CPU are you programming for? What OS? Do you need little-endian or big-endian integers? Are you going to use Unicode? Which kind? UTF-8 or UTF-16? With Java, you don't need to think about it.

Suppose you are coding for multiple OSes/CPUs. Do you like having lots of preprocessor statements in your code? There is no need for preprocessor statements in Java. If you do want to check what OS or CPU you are running on, you can do so at runtime.

How are you going to know what libraries to link to on each OS? And how will you know that you have the right version? For the right architecture/OS? In Java, you have only one shared library: the JDK. In C++, you have a variable number of shared libraries.

4. JUnit

One question: Unit testing: how will you do it in C++? Or will you just rely on integration testing all the way through?

5. Graphical User Interface

Suppose you want a GUI for your application. What toolkit will you use? Gtk, Qt, Win32, MFC, .NET? Console is starting to look more attractive already, isn't it? Will you use a different toolkit for each OS? At least in Java, SWT handles all that dirty work and you can get a native GUI on just about every OS.

6. Web Applications

What are you going to do for web applications? Make/use a CGI application? Use Perl/Python/PHP? Does the ugliness of those scripting languages bother you at all? Or the fact that you'll have to learn yet another language? With Java, you can build a totally custom web server in about 300 lines of code. You also have JSP.

7. Dynamic Linking

Suppose you want to enable your application to have plugins, so that other developers can contribute parts of your application without seeing the core application's source code. How exactly are you going to do this? In Windows, you can use DLLs. What about in Linux? How are you going to distinguish between the two?

What if somebody submits a plugin built for Linux and your application is built for Windows? Maybe you want to load that plugin anyway, because it technically shouldn't have any OS calls. How will you do it? The plugin is an .so file and your application is an EXE. Feel like figuring that out?

8. Exceptions vs. Core Dumps

Think about this carefully: Would you rather receive a core dump (segmentation fault) if something goes really seriously wrong, or would you rather it be an exception?

Conclusion

This is it for now... I may add to this article if I come up with anything else.

What better way to start a .NET blog than with a good old fashioned .NET article?
 
Ever notice how the property grid in the collection editor or in your own applications doesn't have an Events tab? You may think that adding the Events tab isn't a trivial thing to do, well you're wrong.
 
There is barely any documentation available on the web on how to add custom tabs to the property grid, let alone the Events tab. You might think the Events tab is a proprietary tab, available only in VS.NET. You're wrong again!
 
So here's the scoop: The Events tab is part of the .NET Framework and it's quite simple to add it to the property grid. Through my insistence, I was able to figure out how to add it, and here's how.
 
This is all you have to do:

grid.PropertyTabs.AddTabType(typeof(System.Windows.Forms.Design.EventsTab), PropertyTabScope.Global);

Where 'grid' is your property grid. Make sure you reference System.Design.dll in your project.
 
Now, you might notice that if you do just what I said above, you don't get any results. Don't panic, here's the catch. You have to assign a valid Site to the property grid. That is, you need to set the Site property of the grid to some designer site that you've implemented. If you're hosting your own designers, you should know how to retrieve this. If you don't set a Site, the tab won't show, period. Furthermore, you must assign a value to the Site before you add the tab. And that's basically it!
 
Now for the second part of this mini-article, adding the Events tab to not just any property grid, but the Collection Editor's property grid! Here's how to do it.
 

// In your custom collection editor class deriving from CollectionEditor, add this code:
protected override System.ComponentModel.Design.CollectionEditor.CollectionForm CreateCollectionForm()
{
 System.ComponentModel.Design.CollectionEditor.CollectionForm frm =base.CreateCollectionForm ();
 PropertyGrid grid =null;
 //ask it "which one of your controls is a property grid?"
 foreach(Control ctl in frm.Controls)
 {
  if(ctl is PropertyGrid)
  {
   grid = (PropertyGrid)ctl;
   break;
  }
 }
 if(grid !=null)
 {
  //an ingenious way to hook up to property grid and do whatever the hell we want!
  //look ma', no reflection!
  grid.BackColor = SystemColors.Control;
  grid.LineColor = SystemColors.Control;
  grid.ToolbarVisible =true;
  grid.HelpVisible =true;
  grid.Site = site;
  grid.PropertyTabs.AddTabType(typeof(System.Windows.Forms.Design.EventsTab), PropertyTabScope.Global);
 }
 return frm;
}

 
And that's it! Now you have an Events tab in your collection editor. Perhaps I should post this on CodeProject.