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.


Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.

Reply via email to