Why .NET?
-
Depends on how you define mission critical, if your aircraft maintenance system goes down, the planes dont get maintained. If your air traffic control system goes down, people start dying. Thats my definition of mission critical. You obviously dont have much Windows experiance, or SW experience; Windows does not randomly change data. So a plane would not get the wrong amount of fuel. What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that. It is for that reason I would never trust windows for a mission critical system. Nunc est bibendum
fat_boy wrote:
If your air traffic control system goes down, people start dying. Thats my definition of mission critical.
But for an airport manager that is only a part of the job, getting the right things and the right passengers to the right planes every time and all the time is also mission critical. Or a JIT car production line making sure the right parts are available at the right time, neither to soon nor too later, is mission critical. Or many other types of applications that have to do their job correctly all the time and for very long periods of time.
fat_boy wrote:
Windows does not randomly change data. So a plane would not get the wrong amount of fuel.
No it doesn't, and that's precisely why it's used such software. But suppose the somewhere in the software, written in some native language, someone forgets to initialize a variable. That could cause random values to end up who knows where, or not? Or suppose somewhere in the software something causes a small memory leak? It could take a long time before such a bug causes a problem but give it enough time, and some management applications run non-stop for years, and it will be a problem. Suppose it's an application controlling a factory production line, would you go to the factory manager and say "I'm sorry, could you stop the factory for a few minutes while we reboot the server?" Or what if someone assumed some string would never have more than say 5 bytes and some user types in 20, crashes the application and brings the airport to an halt? And in many cases performance isn't an issue so there's little or no advantage in choosing C or C++ over Java or C#, especially since with Java or C# development times are usually shorter, which, for bussiness, is a huge advantage. Quidquid latine dictum sit, altum viditur.
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
I started on C/C++ in the early 80's and continued until the second beta of .NET 1.0 when I switched to C#/.NET. Well, "switched" may be putting it lightly, I have had complete dread to even work on anything C/C++ related after spending just a few weeks with .NET 1.0. The two most important features of C#/.NET, the first is the clean framework classes which handle just about anything I would want to do and the second is the lack of debugging my applciations require. You could always build a nice framework that may handle most of .NET in a C/C++ world, but you would STILL be in a C/C++ world. There is no way to count the number of hours spent in C/C++ code searching out simple little typos that caused the application to crash with little if no clue as to where the problem was at. Shoot, just not paying attention to a change in DLL would crash you every which way and possibly cause you hours if not days to troubeshoot in a production system. I bet in the last four years in C#/.NET I have spent less than 50 hours in total, actually debugging anything, where in C/C++ that would be hit on apps of any decent size in just a month or two. Talk about time savings! There are some gotchas when you first start, but after you are past those, development comes pretty smoothly. In short, it is the productivity that I have gained in C#/.NET that is of value to me above all, followed closely by security and expandability. There are many reasons that I am hard core dedicated C#/.NET after about two decades of C/C++, but these are the most important. Rocky <>< Latest Post: SQL2005 Server Managemnet Studio timeouts! Blog: www.RockyMoore.com/TheCoder/[^]
-
fat_boy wrote:
If your air traffic control system goes down, people start dying. Thats my definition of mission critical.
But for an airport manager that is only a part of the job, getting the right things and the right passengers to the right planes every time and all the time is also mission critical. Or a JIT car production line making sure the right parts are available at the right time, neither to soon nor too later, is mission critical. Or many other types of applications that have to do their job correctly all the time and for very long periods of time.
fat_boy wrote:
Windows does not randomly change data. So a plane would not get the wrong amount of fuel.
No it doesn't, and that's precisely why it's used such software. But suppose the somewhere in the software, written in some native language, someone forgets to initialize a variable. That could cause random values to end up who knows where, or not? Or suppose somewhere in the software something causes a small memory leak? It could take a long time before such a bug causes a problem but give it enough time, and some management applications run non-stop for years, and it will be a problem. Suppose it's an application controlling a factory production line, would you go to the factory manager and say "I'm sorry, could you stop the factory for a few minutes while we reboot the server?" Or what if someone assumed some string would never have more than say 5 bytes and some user types in 20, crashes the application and brings the airport to an halt? And in many cases performance isn't an issue so there's little or no advantage in choosing C or C++ over Java or C#, especially since with Java or C# development times are usually shorter, which, for bussiness, is a huge advantage. Quidquid latine dictum sit, altum viditur.
Well, we are discussing Windows's suitability for Mission Critical situations, not .Net. As for the rest of your post, regardless of the OS, bad code is bad code, for example, a 16 bit overflow brought down the Arianne rocket some years ago. Still, Windows is not good enough for mission critical applications. The US Navy tried with NT4 (and its a lot better than XP), and still their Friggate was dead in the water for days. And anyway, XP is a user oriented, game oriented, hot plugging hardware, kind of machine. This in itself is almost useless in a mission critical situation, or, even a producrtion line for cars. So why do it? Why not just run a minimal 'something else', PDP11, AS400, Unix, even, perhaps, NT4. Any of these will offer all you need for process control, (Unix is better than NT4 for the reason of interrupt latency, and for some process controll situations this is inmportant). Nunc est bibendum
-
Marc Clifton wrote:
So, I hope I'm not totally munging the understanding of the reasons/technology for you
Definitely not. Thanks again! The good thing about MS is that quite often they've done some very right things. :wtf: The really bad thing about MS is that every single time they refuse to tell you why they have done something and instead they drown you in a flood of marketing ******** and hope that you are going to do what they say because they say it instead of doing it because you agree with them ... X| /Simon This is not a signature.
Simon Hofverberg wrote:
is that every single time they refuse to tell you why they have done something and instead they drown you in a flood of marketing ********
:-D That's what sites like this are for. To get you grounded with useful info. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
It's a tool, not a religion. Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
Well, arrival of .NET was obvious since most of the % of developers on MS platform was of VB developers which had limitations though. But .NET removed the problems and complaints about VB developers. Everyone know that its .NET which breaked the market of Java and its really powerful. But every application has to choose a language/technology. C++ is still good for low level applications like device drivers etc. Maybe, only that knows the pain who has felt it. Sameers Need custom software? Contact DevelopersINN[^] Need to add reminders for your Outlook emails? Try Outlook Personal Assistant[^]
-
Marc Clifton wrote:
not a religion.
Yeah, there are absolutely no ayatollahs in IT :laugh:
Pull the tapeworm out of your ass Fold with us! ¤ flickr
K(arl) wrote:
there are absolutely no ayatollahs in IT
What about Kool-Aid drinking cultists? Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
MS doesn't want to be language specific They wants to create a generic framework that is common to all langauges that 's for VB, or C# or C++ the frame work is the same depending on your flexiblity and past experience u can easily migrate to the corresponding languages the name .net is common to all languages since frame work is same I think u knew it With .net plat form independent ,interoperablilty,language independent,managed code ,Memory management,Exception handling,Gc,CLr and many more "I find that the harder I work, the more luck I seem to have."
-
That is why the re wrote the Kernel for Vista, the NT4 kernel with 98 pnp and power stuff was architecturally unstable. However, I expect to see a whole pile of new bugs! Nunc est bibendum
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
You make some interesting points and so do the posters who have contributed. Here is my take on it:-D. I have used MFC and the win32 API for over ten years and I still am. I maintain a lot of applications, some of which will never move across to .NET because there is simply no need and they do exactly what they are supposed to as well as when they were introduced. However, .Net brings a goody bag of useful and productive classes and access to the latest GUI controls/Windows forms. A brand new app in VC6 still looks old and yes I know there are ways of merging the technology but in my experience this effort would be better spent on producing the system. Whether you like it or not Microsoft is a huge company and as long as it has a reasonable product it is going to sell because of the sheer weight behind it. As a developer I need to make money and therefore my skills need to be compatible with the largest number of people (future customers) and I need to be the most productive I possibly can be. This is the reason why I don't concentrate on the Mac or Linux which are both great technology but for my particular needs customers want a PC running XP Pro some dedicated hardware and a nice glossy interface which looks familiar and not out of place when used with themes. There is still a large market for MFC/C++ simply because of the sheer size of the code base. But this is not going to increase and .Net is slowly eating into it. If I was a hobbyist then I could afford to choose the little guy. When the next great thing comes along (Vista) I will give it 6 months and then begin learning to program with it. Before I get accused of being a Microsoft diehard my biggest gripe with .Net is the fact that using Reflector most .Net applications can be very easily reverse engineered into source code that is remarkably similar to the original. Do not underestimate the amount of time you are going to spend working with an obfuscator to protect your code. For this reason and that of performance I mix .Net with C++ dll’s. .Net handles the front end and some of the mundane tasks while the unmanaged dll contains all of the IPR and does all of the work. My two cents Jason
-
You make some interesting points and so do the posters who have contributed. Here is my take on it:-D. I have used MFC and the win32 API for over ten years and I still am. I maintain a lot of applications, some of which will never move across to .NET because there is simply no need and they do exactly what they are supposed to as well as when they were introduced. However, .Net brings a goody bag of useful and productive classes and access to the latest GUI controls/Windows forms. A brand new app in VC6 still looks old and yes I know there are ways of merging the technology but in my experience this effort would be better spent on producing the system. Whether you like it or not Microsoft is a huge company and as long as it has a reasonable product it is going to sell because of the sheer weight behind it. As a developer I need to make money and therefore my skills need to be compatible with the largest number of people (future customers) and I need to be the most productive I possibly can be. This is the reason why I don't concentrate on the Mac or Linux which are both great technology but for my particular needs customers want a PC running XP Pro some dedicated hardware and a nice glossy interface which looks familiar and not out of place when used with themes. There is still a large market for MFC/C++ simply because of the sheer size of the code base. But this is not going to increase and .Net is slowly eating into it. If I was a hobbyist then I could afford to choose the little guy. When the next great thing comes along (Vista) I will give it 6 months and then begin learning to program with it. Before I get accused of being a Microsoft diehard my biggest gripe with .Net is the fact that using Reflector most .Net applications can be very easily reverse engineered into source code that is remarkably similar to the original. Do not underestimate the amount of time you are going to spend working with an obfuscator to protect your code. For this reason and that of performance I mix .Net with C++ dll’s. .Net handles the front end and some of the mundane tasks while the unmanaged dll contains all of the IPR and does all of the work. My two cents Jason
Thanks for your take! I enjoyed it. I must admit that when I wrote my initial post I really did not see any reason why I should use the .NET framework at all. But after reading all of the reply posts I've come to the same conclusion as you have:
JaseNet wrote:
For this reason and that of performance I mix .Net with C++ dll’s. .Net handles the front end and some of the mundane tasks while the unmanaged dll contains all of the IPR and does all of the work.
This sounds like the way to go for "regular" applications - applications that aren't web-centered. As long as the application has any parts that are either faster or easier implemented in unmanaged code, that is, or that need to be protected from an IPR point of view. Otherwise I no longer see no reason why not to use .NET ... ! :wtf: The angle of reverse engineering / obfuscation is new to me but definitely an important one (or so it sounds to me). /Simon This is not a signature. -- modified at 3:00 Monday 20th March, 2006