Hi Munawar,
Yes, all too true. Back around 2002/2003 when I began learning .NET it
clearly seamed to be the way to go. The way of the future and all that.
The early .NET books on VB .NET and C# .NET praised .NET as some great
and wonderful API which in many ways it was. However, after you have
worked with .NET a while its disadvantages begin to come quite apparent.
For example, a lot of people here probably don't know I actually
originally created STFC in C++ using LibSDL for sound and input on Red
Hat Linux around 2002/2003. When .NET came out I immediately switched to
C# .NET, rewrote the program for .NET, and released the .NET version we
all know and love. However, over time I have really come to regret that
decision for a number of reasons.
First, I tied STFC to a Windows API, and made the game and code too
platform specific. I used Managed DirectX which is now not even being
supported by Microsoft. All I really had to do back then was modify and
recompile the game using Visual C++ and shipped the Windows version of
the SDL libraries with it. I could have actually had a Windows and a
Linux version of the game way back then. So there is greavence number one.
Second, when I began learning C# .NET and VB .NET I wasn't aware I
needed to use obfuscation tools to protect my programs. I was well in to
STFC's .NET rewrite when someone asked me what program I was using for
.NET obfuscation. At the time I was like, "what the heck are you talking
about?"
Of course, it was explained to me I had to use an obfuscation tool like
Dotfuscator to scramble my MSIL code so no one could reverse engineer my
programs. Naturally, I was pretty miffed at Microsoft for leaving such
an obvious and huge security risk open to hackers and crackers. So I had
to whip out a hunk of change to secure my programs. That was greavence
number two.
Third, there is the entire issue of Windows 32 byt and 64 byt additions.
If you use a free tool like Visual C# 2008 Express you can't change the
target platform easily, and it defaults to AnyCPU. This is major bad
news as I've got experience the AnyCPU option often fails to work
because if you use a managed library compiled for a different platform
than .NET thinks you are running Crash City here we come. You can force
Visual C# Express to compile for X86, or x64 but it is a matter of
enabling a bunch of stuff they turned off by default. If you ask
Microsoft how to do this they will lie and tell you the express versions
can not be compiled for x86 or x64 target platforms, and you must
purchase the professional version. I should know as that is what they
told me, and i found out from someone else that Microsoft was lying
through their teeth. Someone walked me through the steps setting up
Visual C# Express for creating the x86and x64 target platforms, and it
worked like a charm. So it is obvious Microsoft is using the ability to
change the target platform in the IDE as a selling point for their
professional versions even though we don't need to upgrade for that
feature, and they know better than anyone that this ability is needed
more than ever given the number of Windows 64 byt systems out there now.
That's major greavence number three.
Fourth, there is the old problem of native code verses runtime code.
With .NET even though the .NET Framework is powerful it still falls
short of giving you full access to everything you may want or need for
an application. You can't simply use DirectX without using a third-party
API like SlimDX for sound/input support. There are plenty of other Win32
API libraries like kernel32.dll or user32.dll you can't access unless
you write a .NET wrapper for them. Why do this when a language like C++
can use them without any extra steps of writing a managed wrapper for
them. That's greavence number four.
Fifth, with the growth of Mac OS and Linux these days it is a good idea
to try and be as platform independent as possible. At least make the
software product so it can be easily modified and ported to other
platforms as needed. Originally this is one of the ideas behind the Mono
Project using C# .NET. However, over time legal issues have arisen
between the Mono Project's founders and Microsoft making the future of
.NET on non-Windows platforms very uncertain. Any developer might want
to think twice about developing .NET based products for Mac OS and Linux
given the legality of the open source Mono Project. That's greavence
number five.
Finally, .NET does a lot of things that are nice for newbies, but isn't
so great for time critical programming. Most new programmers can take
advantage of the .NET Framework's garbage collecter for cleaning up
after the program, but that isn't always the best thing to do. Some
applications will run better if the developer does his/her own garbage
collection, memory management, and doesn't rely on some universal vacuum
cleaner to clean up after his/her mess. It just seams more logical that
doing it yourself is usually better as you can fine tune the program
even if the end user might not notice it.
When you really come down to it while .NET sounded great when it first
came out it isn't as great or wonderful as Microsoft claimed it would
be. Nothing really beats writing your program in C++ using native APIs
and libraries. If you decide to use a cross-platform solution like FMOD,
OpenAL, SDL, that's just great. Makes your job easier yet.
<Smile>
---
Gamers mailing list __ [email protected]
If you want to leave the list, send E-mail to [email protected].
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/[email protected].
If you have any questions or concerns regarding the management of the list,
please send E-mail to [email protected].
