Customer Interest / Needs - .NET / Win32 / Win64?
.NET is the future of the Microsoft platform, right? We've been told this, we've been sold this. Even Borland, in 2003 and 2004 bought into this. Hence, C#Builder came out. Delphi for .NET came out. C++ for Win32 was seen as no longer a need, and essentially got scratched in favor of C++BuilderX, a java-based IDE for C++ development that could target applications for multiple platforms. But because of a lack of RAD-like capability and compatibility with previous C++Builder projects, C++BuilderX failed miserably.
Accepting the reality/hype of .NET (and it's hard to tell the difference between the reality and the hype) I found myself putting one of my feet on the .NET developer bandwagon, but still keeping another foot on the hi-mileage, but the ever faithful Win32 API jalopy. Truth be told the .NET development that I've done using C# isn't bad - I like it! But, you know what, I don't have any customers out there chanting, "We want our .NET Apps!" For a majority of them, Win32 apps are just fine! If anything some of them (actually a growing number of them) are asking for Java apps. Why? Cross-platform portability! (Apparently they haven't gotten the memo that .NET intends to be cross-platform). For those that aren't asking for any changes, Win32 is preferred, simply because they want to run the application on their laptop or desktop. Very few want them on their smart phone or PDA.
But like "South of the Border" billboards popping up on US Interstate 95 every half-mile, the .NET mantra continues to be spewed from the Microsoft machine -- at least to us developers who are focused on the future. However, I find myself realizing the road infrastructure I'm driving on is what's really essential, and it continues to smell like and taste like the Win32 API.
In fact, as I look around the landscape, I find two things are certain, which don't appear to change anytime soon. For market share and performance, the Windows API is still alive and well. And then, for cross platform capability, Java VM rules over .NET.
Thus, Microsoft's biggest draw is the Windows API not .NET. The proof is in all the apps that are out there. Old ones. New ones. Think about it? It's the software that provides capability for Microsoft's Windows platform. If Microsoft went exclusively to .NET and dropped support for the Win32 API, what do you think would happen? People would go nuts. Apps wouldn't work. Production would be affected. It would be catastrophic. My bet is that the Win32 API isn't going anywhere, and that's good reason to be jazzed about DeXter, which is Borland's attempt to resurrect C++Builder as a personality in the Delphi IDE. Once again, developer's will have a tool for Win32 API development. This, of course, is good – really good -- but there's even more reason to focus on the Windows API...
Just ahead is a change in the road. But it's not an attraction at the border like .NET, which, I might add, is an attraction which could not exist and thrive without the Win32 interstate. No, what we have ahead are more lanes on the highway. An extension of the Win32 interstate that will result in better performance and more capability that can be exercised.
And on the interstate passing us now are the new crop of affordable Hummers - ready to make use of those new lanes. These are inexpensive, yet powerful 64-bit processors, like the AMD 64 Athlon. And now, Microsoft has unveiled a version of Windows XP that is designed to make use of these new processors, and in order for Windows to make use of this 64-bit capability, an extension was needed of the Windows API, which they have done.
So, as a developer I ask myself why do we really need .NET? Hasn't the VCL served the need from a programming standpoint that .NET intends to fill? Wouldn't werather have a VCL that ties in closer to the Windows infrastructure producing better, quick, high performing applications? So what is the benefit of VCL for .NET? The .NET Compact Framework? Maybe, but we're still waiting on that.
The bottom line is that for the Microsoft platform, the base infrastructure is not .NET -- no it's the Windows API. And as developers what we need to begin leveraging for future applications are the new functions, and data types that have been added or updated for 64-bit Windows.
Perhaps what should be encouraged is for Borland to extend the VCL for Delphi and C++Builder personalities to include support for 64-bit Windows. Perhaps a VCL Win64 equivalent to the current VCL Win32 library. Seriously, why put more energy into developing or using a .NET VCL, which provides a wrapper ontop of a wrapper, when we know the Windows API isn't going anywhere. Microsoft surely recognizes that if they dropped support for the win API, the wrath of the world would come upon them. The proof that they wouldn't drop this is that they've already quietly engineered and delievered a Win64 API to carry on their flagship Windows product.
It seems to me, as developer's we've gotten very excited about .NET, and it is cool, but that doesn't mean the VCL is broken or has needed to be retooled for .NET. It all comes back to this question, "What do folks want and need?" For most customers, the users of our software, they don't care about .NET, they just want apps that work and continue to work on the desktops and notebooks that they own. And Microsoft has shown, albeit quietly, that they have no interest replacing the Windows API with .NET. It's just not going to happen. But, certainly the .NET billboards aren't coming down either. :-)
Accepting the reality/hype of .NET (and it's hard to tell the difference between the reality and the hype) I found myself putting one of my feet on the .NET developer bandwagon, but still keeping another foot on the hi-mileage, but the ever faithful Win32 API jalopy. Truth be told the .NET development that I've done using C# isn't bad - I like it! But, you know what, I don't have any customers out there chanting, "We want our .NET Apps!" For a majority of them, Win32 apps are just fine! If anything some of them (actually a growing number of them) are asking for Java apps. Why? Cross-platform portability! (Apparently they haven't gotten the memo that .NET intends to be cross-platform). For those that aren't asking for any changes, Win32 is preferred, simply because they want to run the application on their laptop or desktop. Very few want them on their smart phone or PDA.
But like "South of the Border" billboards popping up on US Interstate 95 every half-mile, the .NET mantra continues to be spewed from the Microsoft machine -- at least to us developers who are focused on the future. However, I find myself realizing the road infrastructure I'm driving on is what's really essential, and it continues to smell like and taste like the Win32 API.
In fact, as I look around the landscape, I find two things are certain, which don't appear to change anytime soon. For market share and performance, the Windows API is still alive and well. And then, for cross platform capability, Java VM rules over .NET.
Thus, Microsoft's biggest draw is the Windows API not .NET. The proof is in all the apps that are out there. Old ones. New ones. Think about it? It's the software that provides capability for Microsoft's Windows platform. If Microsoft went exclusively to .NET and dropped support for the Win32 API, what do you think would happen? People would go nuts. Apps wouldn't work. Production would be affected. It would be catastrophic. My bet is that the Win32 API isn't going anywhere, and that's good reason to be jazzed about DeXter, which is Borland's attempt to resurrect C++Builder as a personality in the Delphi IDE. Once again, developer's will have a tool for Win32 API development. This, of course, is good – really good -- but there's even more reason to focus on the Windows API...
Just ahead is a change in the road. But it's not an attraction at the border like .NET, which, I might add, is an attraction which could not exist and thrive without the Win32 interstate. No, what we have ahead are more lanes on the highway. An extension of the Win32 interstate that will result in better performance and more capability that can be exercised.
And on the interstate passing us now are the new crop of affordable Hummers - ready to make use of those new lanes. These are inexpensive, yet powerful 64-bit processors, like the AMD 64 Athlon. And now, Microsoft has unveiled a version of Windows XP that is designed to make use of these new processors, and in order for Windows to make use of this 64-bit capability, an extension was needed of the Windows API, which they have done.
So, as a developer I ask myself why do we really need .NET? Hasn't the VCL served the need from a programming standpoint that .NET intends to fill? Wouldn't werather have a VCL that ties in closer to the Windows infrastructure producing better, quick, high performing applications? So what is the benefit of VCL for .NET? The .NET Compact Framework? Maybe, but we're still waiting on that.
The bottom line is that for the Microsoft platform, the base infrastructure is not .NET -- no it's the Windows API. And as developers what we need to begin leveraging for future applications are the new functions, and data types that have been added or updated for 64-bit Windows.
Perhaps what should be encouraged is for Borland to extend the VCL for Delphi and C++Builder personalities to include support for 64-bit Windows. Perhaps a VCL Win64 equivalent to the current VCL Win32 library. Seriously, why put more energy into developing or using a .NET VCL, which provides a wrapper ontop of a wrapper, when we know the Windows API isn't going anywhere. Microsoft surely recognizes that if they dropped support for the win API, the wrath of the world would come upon them. The proof that they wouldn't drop this is that they've already quietly engineered and delievered a Win64 API to carry on their flagship Windows product.
It seems to me, as developer's we've gotten very excited about .NET, and it is cool, but that doesn't mean the VCL is broken or has needed to be retooled for .NET. It all comes back to this question, "What do folks want and need?" For most customers, the users of our software, they don't care about .NET, they just want apps that work and continue to work on the desktops and notebooks that they own. And Microsoft has shown, albeit quietly, that they have no interest replacing the Windows API with .NET. It's just not going to happen. But, certainly the .NET billboards aren't coming down either. :-)
5 Comments:
Of course your customers don't come running, saying: "we want .NET!"
.NET is a technology for developers, not for customers (not yet, at least).
There are good things with .NET and there are bad things. Of all the things I have experienced with .NET, there are more bad than good things overall (at least now).
If we then add all the extra work they put on the developers for learning and testing on this new framework, the loss is big.
Now we even need code scramblers before releasing .NET products because disassembling .NET apps will even give you local variable names. It's as close to the original source as it can get. I wonder what Microsoft intended with this...
I have many libraries of C++ code that it took me years to create. Why on Earth would it benefit me to move to another language. I'd prefer my current language to keep pace with Windows. If it can't then I'd still be able to crank out 32 bit code, because it will run on Windows for years to come. Heck, my old DOS apps still run on Windows.
Bravo - someone ducks the politically correct .NET jumbo and gets to the point. Why wouldn't end user want to download and install each .net framework update and the requisite bags of bug pathes? Instead of tight, secure C++ apps written by knowlegeable developers, we can have swarms of poorly written, memory intensive, bloated .net code just waiting (like Java may I add) for the latest in a series of never ending updates.
I worked extensively with java since 1990. I tried C# since 2000. These things are like a coconut tree which grows as you climb. You cannot reach the coconuts (new apis to be learnt) you cannot go down as you are too far up (backward compatibility problems)! I now focus on using C++ (GNU on LIN and MingW on WIN) using code blocks editor, FOX Toolkit GUI and CGI for web. LIN 2 WIN portability is just a compile away! Users couldnt care less. The want software that works the way they require!
Post a Comment
<< Home