Dan Tohatan - .NET

Performance - Why Not to Upgrade

Dan Tohatan (Admin) — Tue, 24 Aug 2010 16:02:23 GMT

Are you a developer thinking of upgrading your PC? I have a very good reason for you not to upgrade.

It boils down to one thing: testing.

If you want to test your application from the user's perspective, especially from the lowest common denominator user's perspective, then your PC configuration needs to match those specs. If you have a top-notch PC that only 2% of your users have, guess what: 98% of your users will perceive your application as being "slow."

Rule of Thumb: 90th Percentile

Since you don't want to give your users the perception that your apps are slow, always match the 90th percentile of what your users are likely to have. So for example, if 90% or more of your users have at least 256 MB of RAM, then your development machine should have only 256 MB of RAM.

It turns out that about 90% of my users have dual-core CPUs (not quad core or single core) and at least 2 GB of RAM. They also have a video card that generally gets at least 30 TTP/s in the 3D test. My current dev PC is about twice those specs. It is a dual-core Intel Core 2 Duo E8400 with 4 GB RAM, and it gets around 70 TTP/s in the 3D test. It is a bit more powerful than I want it to be, and I will certainly not be upgrading it for a while.

When I developed Dacris Benchmarks 5.0, in late 2001, I did so on an Athlon 1 GHz machine with only 256 MB of RAM. That became roughly the 90th percentile PC spec in early 2002 (for power users). I also had to target Windows 98 and Windows 2000 at the time. I had to set up virtual machines in VMWare to test those OSes, since I was already running Windows XP.

I have basically been following the 90% rule for at least 9 years, mostly not by choice - since I did not have the lavish budget to spend on the latest & greatest hardware. However, in the past 2 years I have been consciously following this rule and if anything it has given me a great excuse not to spend too much money on upgrades.

Going Against the Rule: Windows Vista, .NET

An infamous example of not designing for the 90th percentile can be seen with Windows Vista. In early 2007, the 90th percentile configuration was quite out of reach of the system requirements imposed by Vista. Keep in mind that Windows has to run on all kinds of PCs. Also, Vista is not like Dacris Benchmarks where users are knowledgeable about hardware and usually have more powerful hardware than your average PC user. Bottom line - the jump from XP's basic 64 MB RAM requirement to Vista's 1 GB was too much for mainstream PC users. The result - Vista never reached more than 19% market share!

And if you still doubt that performance matters, take a look at how slow the adoption of .NET has been. .NET is much more resource-hungry than "raw" C++. It requires lots of memory to do JIT compilation. You can hardly run a .NET app without major disk thrashing on less than 512 MB of RAM. That is part of the reason why .NET adoption did not really begin until late 2004. I remember the JVM (Java Virtual Machine) being extremely slow (again due to insufficient RAM) even as late as 2005.

Stick to a $2000 Budget

My advice to those thinking of building a super-ultimate beast for a development box: don't. Try to spend less than $2000 on your beast. Otherwise, you'll be living in an elite fantasy world, isolated from the real world inhabited by most PC users. Note - if your users are super-power users, then the $2000 budget is trumped by the 90th percentile rule. Always try to match the 90th percentile.

If, on the other hand, you want to do R&D, by all means go for the latest & greatest hardware. It is the best way to stay ahead of the game and develop ideas for software that will only be commercially viable in 3+ years. It is a great idea as part of a larger R&D strategy to have at least one "R&D beast" machine. However, you should never do real "production" development on your R&D beast.

Conclusions

Development (for your products) should always be confined to your 90th percentile configuration, so that performance is accurately modeled for 90% of your users. Otherwise, you may have a surprise when your users start complaining about performance issues.

It is far too easy to become tempted to write slow code if, on your PC, the slow code isn't really slow. Even if you plan to test your software on other (slower) PCs, the time you spend during that testing may not be enough to give you a solid feel for how your users will perceive your software. And even if you do spend enough time testing your software on slower PCs, if you catch performance issues at that late a stage in development, the effort necessary to correct them is much greater than if you simply designed your software for that PC configuration in the first place.

Announcing Vmana Beta Program

Dan Tohatan (Admin) — Wed, 18 Aug 2010 07:43:45 GMT

Today, the world of search is one step closer to revolution.

Vmana - the cloud-based commerce search engine - is entering beta on September 1, 2010. Starting today, we are accepting requests from users who wish to participate in the beta program.

The Vmana beta program is expected to run for at least two months. We plan to accept up to 200 beta testers; no more.

What is Vmana?

In a nutshell, Vmana is a hosted e-commerce search engine.

It supports filtering, facets, XML feeds, and all of the other bells & whistles of a top notch search engine.

It is fully managed, with a 100% up-time SLA (service level agreement).

Being a hosted solution, performance never suffers. We always grow capacity behind the scenes to meet demand.

Why is it a revolution?

Quite simply, this has never been done before. Especially not on the scale that it is about to be done.

As the cost of computing continues to decline exponentially (at a rate of ~40% per year), the time for providing high-level software APIs in the cloud is growing ever closer to the present. Vmana is one such example: a high-level search API sitting in the cloud.

Up until now, cloud computing has centered around the idea of providing low-level services (such as queues, storage, or CPU) to the user. This is akin to the days of time-sharing computers and dumb terminals.

The key to the future of cloud computing lies in the ability to provide high-level services (such as search). This is only recently becoming possible. Just as the evolution from the command line to the GUI required a certain critical performance level to be reached, we are now on the cusp of a major transition in cloud computing, from low-level "dumb" APIs to high-level "smart" APIs.

Vmana is a high-level API, which is why it is called "intelligent" search. That's why it's a revolution.

How is it being done?

Behind the scenes lies Lucene - a powerful open-source search engine. However, Lucene is just a tiny fraction of Vmana.

Vmana consists of a crawler, a search engine, and a management & administration dashboard.

Key features include: on-demand and automatic crawling, comprehensive logging, XML feed support (for input), XML search results, REST-style API, and more.

Why cloud?

There are several key advantages to cloud computing in general:

Guaranteed performance.
Guaranteed reliability.
You only pay for what you use.
Easy setup and deployment.

These are the advantages of Vmana over, say, an enterprise search appliance like the GSA (Google Search Appliance).

Why not a "bare bones" search engine like Lucene?

There are several disadvantages to doing that:

Steep learning curve.
Integration effort is costly.
Maintenance is difficult (often requires dedicated staff).
No analytics or reporting features.

The better question is - why live with those disadvantages?

Conclusion

A hosted search solution really makes sense when you take into account all of the disadvantages of the alternative solutions.

For those willing to try something new, it may be worthwhile to sign up for the Vmana beta program or learn more about Vmana.

Note - we are only accepting 200 beta testers in total.

C# Serializable Dictionary - a Working Example

Dan Tohatan (Admin) — Sat, 31 Jul 2010 06:42:38 GMT

Here is the example:

using System;
using System.Runtime.Serialization;
using System.Xml;
using System.Xml.Serialization;
using System.Collections.Generic;
using System.Text;

[Serializable()]
public class SerializableDictionary<TKey, TVal> : Dictionary<TKey, TVal>, IXmlSerializable, ISerializable
{
        #region Constants
        private const string DictionaryNodeName = "Dictionary";
        private const string ItemNodeName = "Item";
        private const string KeyNodeName = "Key";
        private const string ValueNodeName = "Value";
        #endregion
        #region Constructors
        public SerializableDictionary()
        {
        }

        public SerializableDictionary(IDictionary<TKey, TVal> dictionary)
            : base(dictionary)
        {
        }

        public SerializableDictionary(IEqualityComparer<TKey> comparer)
            : base(comparer)
        {
        }

        public SerializableDictionary(int capacity)
            : base(capacity)
        {
        }

        public SerializableDictionary(IDictionary<TKey, TVal> dictionary, IEqualityComparer<TKey> comparer)
            : base(dictionary, comparer)
        {
        }

        public SerializableDictionary(int capacity, IEqualityComparer<TKey> comparer)
            : base(capacity, comparer)
        {
        }

        #endregion
        #region ISerializable Members

        protected SerializableDictionary(SerializationInfo info, StreamingContext context)
        {
            int itemCount = info.GetInt32("ItemCount");
            for (int i = 0; i < itemCount; i++)
            {
                KeyValuePair<TKey, TVal> kvp = (KeyValuePair<TKey, TVal>)info.GetValue(String.Format("Item{0}", i), typeof(KeyValuePair<TKey, TVal>));
                this.Add(kvp.Key, kvp.Value);
            }
        }

        void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
        {
            info.AddValue("ItemCount", this.Count);
            int itemIdx = 0;
            foreach (KeyValuePair<TKey, TVal> kvp in this)
            {
                info.AddValue(String.Format("Item{0}", itemIdx), kvp, typeof(KeyValuePair<TKey, TVal>));
                itemIdx++;
            }
        }

        #endregion
        #region IXmlSerializable Members

        void IXmlSerializable.WriteXml(System.Xml.XmlWriter writer)
        {
            //writer.WriteStartElement(DictionaryNodeName);
            foreach (KeyValuePair<TKey, TVal> kvp in this)
            {
                writer.WriteStartElement(ItemNodeName);
                writer.WriteStartElement(KeyNodeName);
                KeySerializer.Serialize(writer, kvp.Key);
                writer.WriteEndElement();
                writer.WriteStartElement(ValueNodeName);
                ValueSerializer.Serialize(writer, kvp.Value);
                writer.WriteEndElement();
                writer.WriteEndElement();
            }
            //writer.WriteEndElement();
        }

        void IXmlSerializable.ReadXml(System.Xml.XmlReader reader)
        {
            if (reader.IsEmptyElement)
            {
                return;
            }

            // Move past container
            if (!reader.Read())
            {
                throw new XmlException("Error in Deserialization of Dictionary");
            }

            //reader.ReadStartElement(DictionaryNodeName);
            while (reader.NodeType != XmlNodeType.EndElement)
            {
                reader.ReadStartElement(ItemNodeName);
                reader.ReadStartElement(KeyNodeName);
                TKey key = (TKey)KeySerializer.Deserialize(reader);
                reader.ReadEndElement();
                reader.ReadStartElement(ValueNodeName);
                TVal value = (TVal)ValueSerializer.Deserialize(reader);
                reader.ReadEndElement();
                reader.ReadEndElement();
                this.Add(key, value);
                reader.MoveToContent();
            }
            //reader.ReadEndElement();

            reader.ReadEndElement(); // Read End Element to close Read of containing node
        }

        System.Xml.Schema.XmlSchema IXmlSerializable.GetSchema()
        {
            return null;
        }

        #endregion
        #region Private Properties
        protected XmlSerializer ValueSerializer
        {
            get
            {
                if (valueSerializer == null)
                {
                    valueSerializer = new XmlSerializer(typeof(TVal));
                }
                return valueSerializer;
            }
        }

        private XmlSerializer KeySerializer
        {
            get
            {
                if (keySerializer == null)
                {
                    keySerializer = new XmlSerializer(typeof(TKey));
                }
                return keySerializer;
            }
        }
        #endregion
        #region Private Members
        private XmlSerializer keySerializer = null;
        private XmlSerializer valueSerializer = null;
        #endregion
}

The full C# file can be downloaded here: SerializableDictionary.cs

This class is both XML-serializable and binary-serializable. It is hard to find examples out there that do both.

WCF – A Gigantic Monstrosity from the Depths of Hell

Dan Tohatan (Admin) — Fri, 23 Jul 2010 22:37:52 GMT

So it seems everyone out there who wants to create REST services is using WCF to do it. I don’t know how this trend got started, but it’s wrong. You see, WCF was never made for the web. It was made to replace inter-process communication which used to be done through RPC. Then, it grew into a bloated Swiss-army-knife solution trying to solve all of the world’s problems, including (as it happens) REST. Sure it solves the problem, but not very well. Only if you accept the gigantic limitations that WCF imposes on you.

Trying to build a REST service with WCF is like trying to open a beer bottle with explosives. It will open, but then you’ve got a whole mess on your hands.

This week I’ve been struggling to do exactly that – set up a REST service with WCF. Given that I have shared web hosting (I know, poor old me) and have multiple sub domains hosted on the same IIS service, it proved to be impossible. The error: “This collection already contains an address with scheme http.”

Looking around on the web for a solution proved to be futile. It appears that unless you have a dedicated IIS instance just for your WCF REST service, it ain’t gonna happen.

Another thing that really makes my blood boil with WCF is the fact that tracing is so difficult. You have to use a proprietary tool to view a proprietary trace format – and that’s when you finally get it to work right. If you can’t get it to work (I couldn’t), the result is that you try to access one of your service methods and, if there's something wrong with the method, you only get a blank browser screen. No debug output, no exception message, nothing.

I then realized there’s a much easier way to make it happen. The answer is so staggeringly simple you will laugh…

Global.asax

Here’s how you do it:

Take out all the WCF junk from the web.config. God knows WCF likes to flood you with configuration.
Add one line to Global.asax.cs, in Application_BeginRequest:
MyService.ProcessRequest(HttpContext.Current);
Then, create a class called MyService, with a bit of reflection to figure out which service method to call (based on your URL and query string parameters), and a call to XmlSerializer to convert the return value to XML. One example (in my case, called SearchService), can be found here.

That’s it. Three easy steps! Now you have a REST service. No changes to your WCF service contract. Your interface can stay intact – even with the WCF attributes still on it!

So to those who want to implement a simple REST service without the hassle of WCF, here you go. From now on, I prefer not to use WCF unless I absolutely have to.

Project Vmana: Lucene.NET in the Cloud

Dan Tohatan (Admin) — Fri, 16 Jul 2010 08:39:49 GMT

An idea has been tossing & turning in my head for months now - 3 months actually. Rarely does an idea stick around that long without me finding some way to dismiss it.

The idea is a hosted customizable search engine, similar in ease of use to GSA (Google Search Appliance) but more capable - more like Lucene.

After searching for hours & hours for a decent hosted search engine, guess what? I found nothing.

The closest thing I was able to find was GAELucene (on Google Code). It's a Google App Engine version of Lucene. However, the index can only be read-only. It does not support a dynamic index. Without that, it's useless to me.

Hosted Applications - Some Examples

Just so you are less inclined to think I have finally lost my marbles:

IIS --> Windows Azure
SQL Server --> SQL Azure
Outlook --> Gmail
Backup --> Mozy
Bugzilla
SVN

There is a clear trend towards traditional server/desktop applications moving over to hosted services.

Getting a Customized Search Engine ... the Traditional Way:

These days, if you need a customized search solution, your options are as follows:

Purchase, deploy, and maintain a gigantic enterprise search application (e.g. Google search appliance, Endeca, FAST).
Integrate Lucene (or another free search engine) into your application (Java/ASP.NET) and develop your own management interface for it.
Drop the customization and integrate a basic Google search box into your web app, that can only index & search your HTML pages.

Clearly, none of these options are particularly appealing to a small or medium-sized business. Why?

- Option 1 is super-expensive. Not only is the entry cost in excess of $20,000, the cost of maintenance and operation also exceeds $10,000 per month.
- Option 2 is less expensive, although certainly not free, and very time consuming. It could take at least 5 weeks to get a working solution, resulting in more than $5,000 in development costs. Then there's the cost of hosting Lucene yourself. With a large index, you probably need a dedicated server - around $200 per month!
- Option 3 is super cheap, but it's not at all what you want. It's basically the same as giving up.

Is there a better way?

Yes! There is one more option - option 4. But nobody's built it yet.

Option 4 is a hosted search engine where you control what data flows in & how it comes out, but the management & maintenance is handled by someone else.

Think of it as cloud search.

Two words! Simple.

Enter Project Vmana. Thinking search? Think Vmana.

How would it work?

You go to vmana.com and sign up for your free entry-level search account.
Just like App Engine, Vmana is metered. Let's say your entry-level account has 500 MB of index space and 100,000 queries per month.
Using an easy-to-use admin interface, you configure your data sources:

You want some data to be pulled in from your blog, so you give it your RSS feed URL.
You want it to crawl your website, so you give it your home page URL.
You set up some exclusion lists using regular expressions to filter out unwanted URLs.
You have some custom objects with metadata that you will feed in with your own feeder application.

Vmana handles all of your object types & indexes them regularly. You can check your stats using the built-in dashboard.
Vmana provides a testing console - a simple web page where you can type in queries, see results, and build out customized result templates for use later.
You then use the Vmana XML API to send queries from your web application. Your web app just builds the query, sends it to Vmana, and retrieves the results in XML format. Then, you apply a bit of XSL and magic happens - you've got your fully-customized search results page.

How much development effort is involved? Probably about 5 days. Under $1,000.

The value in Vmana lies mainly in the management & admin interface. Lucene does not provide it. If you did option 2, you'd have to build it yourself from scratch. Building all that crawling logic and pretty reporting UIs is not that easy, which is why I said 5 weeks, and that's probably a conservative estimate!

Why "Vmana"? I like the name - it's short, and the domain was available. ;)

Summary

With Vmana, your costs are reduced to about one-fifth relative to comparable options and you get better value & peace of mind!

The project has already begun. Stay tuned for additional status updates - probably in about 3 days.

Release Schedule

The first phase is a working internal prototype that we can showcase via screenshots. That is probably about 2 weeks away. Following that, a public beta - if one happens at all - would arrive around late August. The quality would be similar to the App Engine beta or the Azure CTP. The beta would continue probably for at least two months. Expect heavy promotional giveaways during the beta (i.e. high quotas).

This is all I will divulge at this time. I have nothing more anyway.

.NET Framework Versions and Backwards Compatibility

Dan Tohatan (Admin) — Thu, 15 Jul 2010 06:48:11 GMT

I come across this question quite frequently, and the answer may not be quite so obvious, but it makes sense once you think about it.

Question: How do I know my app (built with .NET version X) will be compatible with .NET version Y?

Answer:

As a rule of thumb, if .NET version X installs side-by-side with .NET version Y, then .NET version X is not compatible (backwards or forwards) with .NET version Y. This is a rule I've been using for quite some time (since .NET 2.0 came out). It's probably too safe for small-scale applications, but it's better to be safe than sorry.

Here are some concrete examples:

.NET 4.0 will not run .NET 3.x or earlier applications properly
.NET 3.5 will run .NET 3.0 & .NET 2.0 applications, but not .NET 1.1
.NET 3.0 will run .NET 2.0 applications, but not .NET 1.1
.NET 2.0 will not run .NET 1.1

Here is a matrix that shows every scenario:

Here are the versions that install side-by-side:

.NET 4.0
.NET 3.5, 3.0, or 2.0
.NET 1.1

Getting over the fear of asking

Dan Tohatan (Admin) — Tue, 13 Jul 2010 08:34:15 GMT

I have a strong feeling that for most people, the biggest reason for business failure or personal stagnation is due to the fear of asking. This applies to me, so it must apply to others out there.

Let's examine this for a minute. What are some fears that people have when it comes to asking?

Asking to be treated fairly in a relationship
Asking for what you feel you deserve to be paid, instead of what you think you can get
Asking others to allow you to speak & make a point
Asking the people you have wronged for forgiveness
Asking that your government representatives actually represent your interests for a change
Asking a girl out on a date

The list goes on...

It has always been a weakness of mine. I'm sure others are in the same boat. Why else would it be that so many people are having trouble making ends meet? They clearly accept their precarious financial situation. It's as if they are content with being poor. Just as in centuries past, people were content with being slaves.

The reason is always the same: they are afraid to ask.

Well, I don't know about you all, but as far as I'm concerned, I'm determined to get over my fear of asking. Whatever it takes.

This new modus operandi is called "being assertive." It is now my new quest.

I will start by getting over my fear of asking for $300/hr as my consulting rate. This is how it begins.

Stay tuned for status updates on my quest. This blog will be my journal on this exciting shift in paradigm.

Why C++ Sucks (Part 2)

Dan Tohatan (Admin) — Tue, 16 Feb 2010 02:41:33 GMT

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.

D3: Free WPF Data Visualization

Dan Tohatan (Admin) — Thu, 03 Dec 2009 03:37:26 GMT

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!

Windows 7 Phones: Coming Next Year!

Dan Tohatan (Admin) — Wed, 02 Dec 2009 00:50:03 GMT

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.

DoEvents really is evil!

Dan Tohatan (Admin) — Wed, 18 Nov 2009 01:15:46 GMT

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.

Call of the Devil: System.Diagnostics.Process.Start

Dan Tohatan (Admin) — Wed, 18 Nov 2009 00:54:34 GMT

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.

Visual Studio 2010 is a .NET App

Dan Tohatan (Admin) — Fri, 13 Nov 2009 03:09:39 GMT

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.

Making Bad Ass-umptions

Dan Tohatan (Admin) — Fri, 09 Oct 2009 00:33:58 GMT

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?

Desktop .NET Finally Ready for Take-Off

Dan Tohatan (Admin) — Mon, 28 Sep 2009 06:46:10 GMT

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.

What .NET Should Have Been

Dan Tohatan (Admin) — Mon, 25 May 2009 21:27:16 GMT

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

Dan Tohatan (Admin) — Sat, 23 May 2009 23:37:39 GMT

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.

2009 Technology Trends

Dan Tohatan (Admin) — Tue, 14 Apr 2009 22:42:10 GMT

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.

Why C++ Sucks (Sort Of)

Dan Tohatan (Admin) — Tue, 10 Feb 2009 06:31:23 GMT

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.

.NET - How to show Events tab in a property grid

Dan Tohatan (Admin) — Wed, 02 Jan 2008 02:13:51 GMT

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.

Blacklisted APIs

Dan Tohatan (Admin) — Sat, 29 May 2004 09:03:51 GMT

What follows is a re-post from an older blog of mine:

---

I've been meaning to write about this for some time. It seems there are certain functions in every library that you, as a humble programmer, were never meant to use, yet they're somehow "there". One example of this is the infamous Application.DoEvents function which, to me, does more harm than good. These are the functions you were never meant to call; the functions I refer to as blacklisted APIs. I will now share with you my present list of blacklisted APIs, the functions that you should never EVER call in your applications...

.NET - Blacklisted APIs - “The functions you were never meant to call“

Screen.GetWorkingArea() - Use instead, Screen.PrimaryScreen.WorkingArea (For some reason, GetWorkingArea takes 25 ms to complete)
Application.DoEvents() - The call of the devil.
Control.RecreateHandle() - There's no reason why you should ever need to use this.
Application.EnableVisualStyles() - Use a manifest. .NET 1.1 just doesn't implement this function right.
NativeWindow.ReleaseHandle() - Contains some nasty bugs.

Dan Tohatan - .NET

Performance - Why Not to Upgrade

Announcing Vmana Beta Program

What is Vmana?

Why is it a revolution?

How is it being done?

Why cloud?

Why not a "bare bones" search engine like Lucene?

Conclusion

C# Serializable Dictionary - a Working Example

WCF – A Gigantic Monstrosity from the Depths of Hell

Project Vmana: Lucene.NET in the Cloud

.NET Framework Versions and Backwards Compatibility

Getting over the fear of asking

Why C++ Sucks (Part 2)

D3: Free WPF Data Visualization

Windows 7 Phones: Coming Next Year!

DoEvents really *is* evil!

Call of the Devil: System.Diagnostics.Process.Start

Visual Studio 2010 is a .NET App

Making Bad Ass-umptions

Desktop .NET Finally Ready for Take-Off

What .NET Should Have Been

Windows 7: A Review

Windows 7: A Review

2009 Technology Trends

Why C++ Sucks (Sort Of)

.NET - How to show Events tab in a property grid

Blacklisted APIs

DoEvents really is evil!