Not Much to 'C' in C#
-
"C# is getting a lot of attention these days—so much attention that some DevX readers have begun to remonstrate on what they consider excessive coverage, especially for a language that is still in its beta stage. I can agree with some of the points raised. Personally, I find C# (at least in its current shape) disappointing, technically crippled, and extremely over-hyped..." Read the complete story @ DevX: http://www.cplus-zone.com/free/articles/KalevCsharp/default.asp What do ya think?
-
"C# is getting a lot of attention these days—so much attention that some DevX readers have begun to remonstrate on what they consider excessive coverage, especially for a language that is still in its beta stage. I can agree with some of the points raised. Personally, I find C# (at least in its current shape) disappointing, technically crippled, and extremely over-hyped..." Read the complete story @ DevX: http://www.cplus-zone.com/free/articles/KalevCsharp/default.asp What do ya think?
I think the author is speaking with out any real knowledge. Let me take some quotes and point out why I think this to be so. "On the one hand, C# is a Windows-only language." Not so. The C# language has been ported to Linux, and will likely be ported every where else. (Note that the ports are under development, but then even the Windows version is still in beta, so that's irrelevant.) I've seen too many people working on ports to consider this claim to be anything than the claim of an Advocacy bigot. "Its focus seems to be on graphics and Windows specific programming tasks, which make it less useful in other application domains—say embedded systems, infrastructures, and numeric applications." There is *nothing* about C# that's geared towards graphics or Windows specific programming tasks. Now, the available libraries are geared towards this, but that's to be expected at this stage, and since C# doesn't have libraries of it's own, instead relying on .NET, this is not much of an argument. In contrast, the same could be said for Java with a lot more weight to the claim, yet Java is found to be a useful general purpose language and has been used for diverse tasks such as compiler creation and text file manipulation and has been the basis of many an embedded system. "In addition, C# is a proprietary language whose evolution is steered by a commercial company." Flat wrong. This is a very valid argument for Java, but not for C#. C# has been fully released to the ECMA and so is an open standard (or will be), not a proprietary language. The initial design was "steered by a commercial company", but so were the designs of C and C++. "If judged from our experience with Java in the 1990s and Ada in the 1980s, this is a recipe for an immature and pretentious language. Sun's bias toward SPARC/Unix affected Java's design in many subtle ways, to the chagrin of Windows users." Hmmm... Unix and C have been tied so closely as to be nearly one and the same thing since the inception of both. This didn't stop the language from evolving and being the basis of nearly every other serious endeavor on nearly all platforms for many years after. The problem with Java wasn't its bias for SPARC/Unix (in fact, the best Java VMs existed on Windows) but it's total control by Sun. Ada suffered even worse problems. "Still, C# designers have made several gaffes, such as removing template support." I'm not at all convinced this was a "gaffe". Templates in C++ are a hair ball (and that's from someone who l
-
I think the author is speaking with out any real knowledge. Let me take some quotes and point out why I think this to be so. "On the one hand, C# is a Windows-only language." Not so. The C# language has been ported to Linux, and will likely be ported every where else. (Note that the ports are under development, but then even the Windows version is still in beta, so that's irrelevant.) I've seen too many people working on ports to consider this claim to be anything than the claim of an Advocacy bigot. "Its focus seems to be on graphics and Windows specific programming tasks, which make it less useful in other application domains—say embedded systems, infrastructures, and numeric applications." There is *nothing* about C# that's geared towards graphics or Windows specific programming tasks. Now, the available libraries are geared towards this, but that's to be expected at this stage, and since C# doesn't have libraries of it's own, instead relying on .NET, this is not much of an argument. In contrast, the same could be said for Java with a lot more weight to the claim, yet Java is found to be a useful general purpose language and has been used for diverse tasks such as compiler creation and text file manipulation and has been the basis of many an embedded system. "In addition, C# is a proprietary language whose evolution is steered by a commercial company." Flat wrong. This is a very valid argument for Java, but not for C#. C# has been fully released to the ECMA and so is an open standard (or will be), not a proprietary language. The initial design was "steered by a commercial company", but so were the designs of C and C++. "If judged from our experience with Java in the 1990s and Ada in the 1980s, this is a recipe for an immature and pretentious language. Sun's bias toward SPARC/Unix affected Java's design in many subtle ways, to the chagrin of Windows users." Hmmm... Unix and C have been tied so closely as to be nearly one and the same thing since the inception of both. This didn't stop the language from evolving and being the basis of nearly every other serious endeavor on nearly all platforms for many years after. The problem with Java wasn't its bias for SPARC/Unix (in fact, the best Java VMs existed on Windows) but it's total control by Sun. Ada suffered even worse problems. "Still, C# designers have made several gaffes, such as removing template support." I'm not at all convinced this was a "gaffe". Templates in C++ are a hair ball (and that's from someone who l
I am learning C# right now, and I like some aspects of this language, especially delegates and event handling. Of course, C++ has function objects, but delegates are (probably) easier to use. However there are several things that I dislike in C#: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. And promisses about including generics in some future version :rolleyes: can only motivate programmers to refrain from using C# until the next version. 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. 4. The "Java philosophy" of the language. Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes, so the most powerfull aspects of C++ are just left out. While I agree that some programmers (perhaps too many of them) tend to misuse the power of C++, I still think that this should be solved by better project management, and not by cutting of the best features of C++. I vote pro drink X|
-
"C# is getting a lot of attention these days—so much attention that some DevX readers have begun to remonstrate on what they consider excessive coverage, especially for a language that is still in its beta stage. I can agree with some of the points raised. Personally, I find C# (at least in its current shape) disappointing, technically crippled, and extremely over-hyped..." Read the complete story @ DevX: http://www.cplus-zone.com/free/articles/KalevCsharp/default.asp What do ya think?
I think it should be called VB#, because it is more similar to VB than C++. Also VC++ Developer Journal was so hyped up about c# it took over the magizine, and then embedded its content in to VB developer journal (bye bye subscription). -Steven Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com
-
I am learning C# right now, and I like some aspects of this language, especially delegates and event handling. Of course, C++ has function objects, but delegates are (probably) easier to use. However there are several things that I dislike in C#: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. And promisses about including generics in some future version :rolleyes: can only motivate programmers to refrain from using C# until the next version. 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. 4. The "Java philosophy" of the language. Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes, so the most powerfull aspects of C++ are just left out. While I agree that some programmers (perhaps too many of them) tend to misuse the power of C++, I still think that this should be solved by better project management, and not by cutting of the best features of C++. I vote pro drink X|
1. Lack of support for generic programming There's at least some hope that CLR (and C#) will have run-time generics. http://research.microsoft.com/projects/clrgen/ has some interesting info. Tomasz Sowinski -- http://www.shooltz.com
-
I am learning C# right now, and I like some aspects of this language, especially delegates and event handling. Of course, C++ has function objects, but delegates are (probably) easier to use. However there are several things that I dislike in C#: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. And promisses about including generics in some future version :rolleyes: can only motivate programmers to refrain from using C# until the next version. 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. 4. The "Java philosophy" of the language. Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes, so the most powerfull aspects of C++ are just left out. While I agree that some programmers (perhaps too many of them) tend to misuse the power of C++, I still think that this should be solved by better project management, and not by cutting of the best features of C++. I vote pro drink X|
Clap, Clap, Clap, Clap!!! I agree completely with you :
- Generic programming is an awesome and so powerful tool! My life as a programmer has completly changed since I used STL. Did you have a look at the containers provided by the .Net libraries, ouuch...
- Garbage collecting is a so powerful tool that either in Java or in .Net, you have a lot of API which allow you to be sure that it works as intented and that not too much ressources are wasted :eek:
- If multiple inheritance is not useful, why the hell these guys bother about interfaces. Multiple inheritance provide interface at the power 10 because you can also provide a default behavior
Serge :)
-
I am learning C# right now, and I like some aspects of this language, especially delegates and event handling. Of course, C++ has function objects, but delegates are (probably) easier to use. However there are several things that I dislike in C#: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. And promisses about including generics in some future version :rolleyes: can only motivate programmers to refrain from using C# until the next version. 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. 4. The "Java philosophy" of the language. Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes, so the most powerfull aspects of C++ are just left out. While I agree that some programmers (perhaps too many of them) tend to misuse the power of C++, I still think that this should be solved by better project management, and not by cutting of the best features of C++. I vote pro drink X|
Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes Humans are known to make mistakes. Even C++ gurus spend way too much time tracking down bugs that would have been avoided in a less complex language. This extra time has to be paid with actual money. Cutting error-prone features from a language has nothing to do with programmer's level of "stupidity". It just means that misstakes in C++ are more expensive than in, for example, C#. Not that I don't appreciate the power of C++. But it comes at a price, and it would be a fatal mistake to think that only newbies have to pay it. -------------- "Aagh!! I'm a victim of a Random Act of Management!"
-
1. Lack of support for generic programming There's at least some hope that CLR (and C#) will have run-time generics. http://research.microsoft.com/projects/clrgen/ has some interesting info. Tomasz Sowinski -- http://www.shooltz.com
The trend to move so much processor-intensive work from compile-time to runtime bothers me. One of the great advantages Blitz++ gets from generic programming is that it concentrates a huge amount of computational effort in compile-time optimization of generic functions (if you call a linear algebra function on a matrix, it uses information available at compile time about the matrix to strategically unroll loops, simplify indexing, and generally decompose the generic problem into efficient subproblems appropriate for the special case at hand). In principle, one could have a compiler that would spend a week optimizing its code and generating the most efficient runtime possible. This would be worthwhile effort for numerically intensive engineering code (I have many programs that will run for days at a time, occupying a significant fraction of processor power). If we go to the .NET model, the generic stuff ends up being optimized by the CLR JIT compiler, so instead of efficiently compiling once, on the developer's machine, we duplicate the effort of compiling to machine code on every user's machine. Moreover, information is lost in the translation from source to intermediate code, so optimization will be less efficient downstream than if you compile directly to machine code, specifying the exact target processor. Consider FFTW or the current generation of BLAS generators for extreme examples! These analyze your computer and generate optimized C or FORTRAN code specific to the configuration (available RAM, virtual memory, L1 and L2 caching, etc.) you are compiling for. These are completely orthogonal to the CLR approach and I am concerned that the emphasis on complete genericity in the intermediate language is eclipsing important considerations for the engineering and scientific markets.
-
I am learning C# right now, and I like some aspects of this language, especially delegates and event handling. Of course, C++ has function objects, but delegates are (probably) easier to use. However there are several things that I dislike in C#: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. And promisses about including generics in some future version :rolleyes: can only motivate programmers to refrain from using C# until the next version. 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. 4. The "Java philosophy" of the language. Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes, so the most powerfull aspects of C++ are just left out. While I agree that some programmers (perhaps too many of them) tend to misuse the power of C++, I still think that this should be solved by better project management, and not by cutting of the best features of C++. I vote pro drink X|
1. It's not the syntax that's a pain. You get used to the syntax really quickly. It's the semantics. Simple templated types are just that, simple. But when you get into more complex uses (specializations, both full and partial, etc.) then the semantic results become difficult to deal with. A lot of this is because C++ compilers aren't fully compliant yet, but there are also a lot of corner cases where the standard missed a difficult nuance. From a strategic standpoint I can not fault MS from not including generics in .NET or C# in release 1. 2. Ref-counting is simpler and faster, but is no different from GC in semantics. It's an implementation detail. The only real complaint is that the .NET infrastructure, and therefor C#, only allow objects to be created on the GC heap (well, actually, simple types can be placed on the stack, but you and I both know that these aren't the object types we're talking about). At least in MC++ you can somewhat handle this issue with stack based approaches that are easier to deal with than finally blocks. That said, you should read my article on the gc_ptr<> on this site where I talk about the pros and cons of GC. I won't fault C# for it's choice to be a full GC language since for many things this makes programming simpler and less error prone, but I'm not going to give up C++ RAII idioms for it either. 3. I'll agree with this, as will most C++ users, and probably all Eiffel users. However, this is a very heated religous issue with valid points on both sides. I can live with the lack in C#, though I'm more concerned with the lack in .NET. 4. C# leaves out very little functionality that's available to C++ users. The only two I can think of we've already discussed... MI and GC. C# does make it harder to use some of the more dangerous constructs, such as pointer manipulation, but as long as it still can be done I see nothing wrong with making harder to shoot yourself in the foot. If you want to talk pure opinion and not technical merits, I'll stick with C++, thank you very much. But trying to find technical faults in C# (at least for any of the reasons given so far) just shows either a religious bias or ignorance. Bill Kempf William E. Kempf
-
I think it should be called VB#, because it is more similar to VB than C++. Also VC++ Developer Journal was so hyped up about c# it took over the magizine, and then embedded its content in to VB developer journal (bye bye subscription). -Steven Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com
C# is nothing like VB. It's more like Java# if you have to make such a comparison, but Java was based on C++, so... William E. Kempf
-
Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes Humans are known to make mistakes. Even C++ gurus spend way too much time tracking down bugs that would have been avoided in a less complex language. This extra time has to be paid with actual money. Cutting error-prone features from a language has nothing to do with programmer's level of "stupidity". It just means that misstakes in C++ are more expensive than in, for example, C#. Not that I don't appreciate the power of C++. But it comes at a price, and it would be a fatal mistake to think that only newbies have to pay it. -------------- "Aagh!! I'm a victim of a Random Act of Management!"
I have 7 years of C/C++, and 4 years of VB experience (also some Java), and I didn't find VB projects easier to debug at all. Now, I don't imply here that I'm a C++ guru (far from it :-O), but my point is that if you put in some discipline, C++ can be as safe as any programming language. Just don't hack with pointer arithmetics, use STL containers instead of "intristic" arrays, and do some planning before you start coding. Again, I don't think C# is unusable. It is a great replacement for VB. All that I want to say is that it could (and should) be even better without dropping generic programming and MI I vote pro drink X|
-
C# is nothing like VB. It's more like Java# if you have to make such a comparison, but Java was based on C++, so... William E. Kempf
C# was a language that was suppose to be a mixture of VB and VC++, but to me it looks like VB, because of the loss of control. C# is not a very powerful language, you can't even write a OS in it. Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com
-
The trend to move so much processor-intensive work from compile-time to runtime bothers me. One of the great advantages Blitz++ gets from generic programming is that it concentrates a huge amount of computational effort in compile-time optimization of generic functions (if you call a linear algebra function on a matrix, it uses information available at compile time about the matrix to strategically unroll loops, simplify indexing, and generally decompose the generic problem into efficient subproblems appropriate for the special case at hand). In principle, one could have a compiler that would spend a week optimizing its code and generating the most efficient runtime possible. This would be worthwhile effort for numerically intensive engineering code (I have many programs that will run for days at a time, occupying a significant fraction of processor power). If we go to the .NET model, the generic stuff ends up being optimized by the CLR JIT compiler, so instead of efficiently compiling once, on the developer's machine, we duplicate the effort of compiling to machine code on every user's machine. Moreover, information is lost in the translation from source to intermediate code, so optimization will be less efficient downstream than if you compile directly to machine code, specifying the exact target processor. Consider FFTW or the current generation of BLAS generators for extreme examples! These analyze your computer and generate optimized C or FORTRAN code specific to the configuration (available RAM, virtual memory, L1 and L2 caching, etc.) you are compiling for. These are completely orthogonal to the CLR approach and I am concerned that the emphasis on complete genericity in the intermediate language is eclipsing important considerations for the engineering and scientific markets.
The JIT doesn't have to be done with each invokation. It can be done at installation time. This approach is better than at compile time, since the JIT can do system optimizations not available to the compiler and can optimize the code for the specific CPU instruction set. Also, not all applications need this amount of optimization in any event. With fast CPUs a JIT done at first invocation is not likely to be noticable at run time even for speed critical applications. If the JIT occurred with every invocation you'd have more of an argument, but that's not what happens. William E. Kempf
-
Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes Humans are known to make mistakes. Even C++ gurus spend way too much time tracking down bugs that would have been avoided in a less complex language. This extra time has to be paid with actual money. Cutting error-prone features from a language has nothing to do with programmer's level of "stupidity". It just means that misstakes in C++ are more expensive than in, for example, C#. Not that I don't appreciate the power of C++. But it comes at a price, and it would be a fatal mistake to think that only newbies have to pay it. -------------- "Aagh!! I'm a victim of a Random Act of Management!"
Conversely, the more complex the task the harder it is to do in these "safer" languages, offsetting the costs and often making the "less safe" langauges more cost effective. The right tool for the right job... William E. Kempf
-
C# was a language that was suppose to be a mixture of VB and VC++, but to me it looks like VB, because of the loss of control. C# is not a very powerful language, you can't even write a OS in it. Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com
Name a single thing that represents your claim of "loss of control". You tried with the claim that you can't write an OS in C#, but C# has more hardware control than Java, and Java's being used to develop an OS today. Is C# the right choice for such an understaking? No. But you can still do it. The right tool for the right job... William E. Kempf
-
C# was a language that was suppose to be a mixture of VB and VC++, but to me it looks like VB, because of the loss of control. C# is not a very powerful language, you can't even write a OS in it. Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com
And why the hell would you want to write an OS? You have Windows, Mac OS, Linux, Solaris, HP-UX, FreeBSD, WinCE, PalmOS, etc, etc, etc. Leave the OS programming to OS programmers with C and Assembly. Leave the Application development to Application developers with C, C++, C#, Java, VB, etc. Jason Gerard, Master of Kung Foo
-
C# is nothing like VB. It's more like Java# if you have to make such a comparison, but Java was based on C++, so... William E. Kempf
It is true that C# is nothing like VB. However, it's also true that it aimes to be an alternative to VB rather than to C++. Remember Microsoft slogan: "Ease of use of VB, with raw power of C++"? Of course, for big and complex projects, VB is hardly easier to use than C++, but that's another story. I vote pro drink X|
-
I am learning C# right now, and I like some aspects of this language, especially delegates and event handling. Of course, C++ has function objects, but delegates are (probably) easier to use. However there are several things that I dislike in C#: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. And promisses about including generics in some future version :rolleyes: can only motivate programmers to refrain from using C# until the next version. 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. 4. The "Java philosophy" of the language. Java (and now C#) designers seem to think that programmers are generally stupid people, and that they should not be allowed to make mistakes, so the most powerfull aspects of C++ are just left out. While I agree that some programmers (perhaps too many of them) tend to misuse the power of C++, I still think that this should be solved by better project management, and not by cutting of the best features of C++. I vote pro drink X|
I'd like to discuss a few of these: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. **** There was just no way to get generics into the current version. They will likely show up in a future version, though not necessarily the next version. Since you can use the "object" type as a "poor man's generics" in C# and get a similar effect, generics aren't as critical in C# as C++. You do lose a few things, however: 1) You have to write casts from object to the type that you want, though this occurs less than you'd think due to the use of foreach. 2) You get run-time type checking on these casts rather than compile-time type checking. 3) You box value types in collection classes. I don't find these to be tremendously important issues. #1 and #2 are easy to get used to, and #3 isn't usually a problem, and you can get around it with effort by writing a type-specific collection, though that's a pain. **** 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D *** I think most C++ programmers have this attitude towards GC; they hate any loss of control. I know I did when I first started working on C#. But over time, I've realized that for the code I write, I don't care that much about exactly how memory is used, and the GC saves me tons of time and gives me programs that are more likely to be correct. Reference counting can't detect cycles, among other things. There are still some issues dealing with non-memory resources that require more thought than we'd like, but overall it's a very easy model to work in. *** 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. *** I have mixed feelings about this; from a language perspective, I'm not sure the advantages of MI are worth the increase in complexity (of the language, compilers, debugging task, etc.) Interfaces cover some of the things you'd want to do with MI. That aside, the runtime team couldn't come up with a way to do MI without penalizing the SI case. Even if they could, it's tough to decide what MI means, since different languages have different d
-
C# was a language that was suppose to be a mixture of VB and VC++, but to me it looks like VB, because of the loss of control. C# is not a very powerful language, you can't even write a OS in it. Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com
C# is not a very powerful language, you can't even write a OS in it. *** You're correct, you can't write an OS in it. C# is designed to be a language that targets the .NET platform. If you don't like managed environments, then C# isn't for you. I understand your point about power; sometimes you really need it, but it's not the be-all and end-all of a computer languages. ***
-
C# is not a very powerful language, you can't even write a OS in it. *** You're correct, you can't write an OS in it. C# is designed to be a language that targets the .NET platform. If you don't like managed environments, then C# isn't for you. I understand your point about power; sometimes you really need it, but it's not the be-all and end-all of a computer languages. ***
I wonder if WinXP was written in C#. ;) Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com