Win32 API and .Net Future
-
I don't think this has been posted yet, but if so......Sorry Joel may have some controversial ideas and be grumpy in general but he's usually pretty accurate. This article is about the Win32 API, OS Lock-in, .Net and the future of WinForms and ASP.NET. Brings up some interesting points. Good read no matter what you think. Anybody have any opinions/ideas about his ideas, the article, etc.? Brian "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." - Douglas Adams
-
I don't think this has been posted yet, but if so......Sorry Joel may have some controversial ideas and be grumpy in general but he's usually pretty accurate. This article is about the Win32 API, OS Lock-in, .Net and the future of WinForms and ASP.NET. Brings up some interesting points. Good read no matter what you think. Anybody have any opinions/ideas about his ideas, the article, etc.? Brian "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." - Douglas Adams
This is a re-post. But I do agree with his point that people usually don't upgrade, especially if the computer they have works just fine. Means it will be tough for businesses to justify spending time and money writing super-cool apps that only work on Longhorn when a very small percentage of their customer base will actually be able to use them. I couldn't care less about WinForms though. XML-based GUIs are the way to go. The shame is that it's 100% technically possible to do those today, without Longhorn (we do, and so does Marc Clifton[^]), but MS chose not to go that route... "Fish and guests stink in three days." - Benjamin Franlkin
-
I don't think this has been posted yet, but if so......Sorry Joel may have some controversial ideas and be grumpy in general but he's usually pretty accurate. This article is about the Win32 API, OS Lock-in, .Net and the future of WinForms and ASP.NET. Brings up some interesting points. Good read no matter what you think. Anybody have any opinions/ideas about his ideas, the article, etc.? Brian "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." - Douglas Adams
joel wrote ... Racing car aficionados will probably send me hate mail for this, but my experience has been that there is only one case, in normal driving, where a good automatic transmission is inferior to a manual transmission i almost had to write sum hate mail here. joel ought to stick to software. there is SOooo many reasons this statement is wrong. blah
-
joel wrote ... Racing car aficionados will probably send me hate mail for this, but my experience has been that there is only one case, in normal driving, where a good automatic transmission is inferior to a manual transmission i almost had to write sum hate mail here. joel ought to stick to software. there is SOooo many reasons this statement is wrong. blah
I agree! Not the least of which is demonstrated when my puny Nissan stick-shift blows past other vehicles while driving up a big hill, simply becuase I can easily switch into a lower gear to get more power. :-D "Fish and guests stink in three days." - Benjamin Franlkin
-
I don't think this has been posted yet, but if so......Sorry Joel may have some controversial ideas and be grumpy in general but he's usually pretty accurate. This article is about the Win32 API, OS Lock-in, .Net and the future of WinForms and ASP.NET. Brings up some interesting points. Good read no matter what you think. Anybody have any opinions/ideas about his ideas, the article, etc.? Brian "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." - Douglas Adams
He makes some very good points, and a very interesting view on the MSDN Magazine camp vs. The Raymond Chen camp. As a developer I can agree 100% about the MSDN camp winning; for several months now all I see on MSDN is articles on technology MS wants us to use as a replacement to our existing technology. To make it worse, often times this technology isn't even available to developers (for example, I've been reading many articles and code samples pertaining to Longhorn, Avalon, XAML, generics, etc. which developers can't get unless your boss is generous enough to get an MSDN subscription, and even then it's just tech previews of software of alpha maturity. I disagree with him on several points though. One is the idea that web apps will eventually overtake rich client apps. I don't see this happening, although I think the line between a rich client app and a web app will become blurred as client apps start getting deployed through web browsers. The reason I doubt this is simply because people ~like~ running rich client apps, believe it or not. Sure, web apps suffice for some simpler tasks like web mail, but honestly, no one wants to have to navigate to some URL to run office. MS has done a lot of research in this area and had to change some of their stategies for planned web apps. And it's not just end users, I find (as Joel points out) that most power user/geek types truely despise the idea of replacing client apps with web apps. Just because web apps make deployment a lesser burden on the developer does not mean developers should switch en masse to writing web apps. I also disagree that .NET, the 'unification of the mess of VB, C++, and Win32', has only created a bigger mess. As a former C/C++ developer, I find .NET to be a breath of fresh air from the disaster that is previous programming models in C and VB. Sometimes when things get messy enough, it's time to start with a clean slate. Now .NET doesn't exactly wipe out Win32 (obviously, many parts of .NET wrap existing Win32 and COM APIs) so one could argue that .NET is more a mask over ugliness than a clean slate of beauty, but that's where WinFX comes in, which brings me to the 3rd point I disagree with him. WinFX is going to be revolutionary. If anyone doesn't fully understand the scope of what they're trying to accomplish with Longhorn and WinFX, I urge you to read this article[
-
I don't think this has been posted yet, but if so......Sorry Joel may have some controversial ideas and be grumpy in general but he's usually pretty accurate. This article is about the Win32 API, OS Lock-in, .Net and the future of WinForms and ASP.NET. Brings up some interesting points. Good read no matter what you think. Anybody have any opinions/ideas about his ideas, the article, etc.? Brian "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." - Douglas Adams
BrianEllis wrote: Anybody have any opinions/ideas about his ideas, the article, etc.? Pretty boring, really. How bout a nice article to compare and contrast the VAX/VMS and NT kernels instead? :)
-
He makes some very good points, and a very interesting view on the MSDN Magazine camp vs. The Raymond Chen camp. As a developer I can agree 100% about the MSDN camp winning; for several months now all I see on MSDN is articles on technology MS wants us to use as a replacement to our existing technology. To make it worse, often times this technology isn't even available to developers (for example, I've been reading many articles and code samples pertaining to Longhorn, Avalon, XAML, generics, etc. which developers can't get unless your boss is generous enough to get an MSDN subscription, and even then it's just tech previews of software of alpha maturity. I disagree with him on several points though. One is the idea that web apps will eventually overtake rich client apps. I don't see this happening, although I think the line between a rich client app and a web app will become blurred as client apps start getting deployed through web browsers. The reason I doubt this is simply because people ~like~ running rich client apps, believe it or not. Sure, web apps suffice for some simpler tasks like web mail, but honestly, no one wants to have to navigate to some URL to run office. MS has done a lot of research in this area and had to change some of their stategies for planned web apps. And it's not just end users, I find (as Joel points out) that most power user/geek types truely despise the idea of replacing client apps with web apps. Just because web apps make deployment a lesser burden on the developer does not mean developers should switch en masse to writing web apps. I also disagree that .NET, the 'unification of the mess of VB, C++, and Win32', has only created a bigger mess. As a former C/C++ developer, I find .NET to be a breath of fresh air from the disaster that is previous programming models in C and VB. Sometimes when things get messy enough, it's time to start with a clean slate. Now .NET doesn't exactly wipe out Win32 (obviously, many parts of .NET wrap existing Win32 and COM APIs) so one could argue that .NET is more a mask over ugliness than a clean slate of beauty, but that's where WinFX comes in, which brings me to the 3rd point I disagree with him. WinFX is going to be revolutionary. If anyone doesn't fully understand the scope of what they're trying to accomplish with Longhorn and WinFX, I urge you to read this article[
Well said. :cool: Charlie if(!curlies){ return; }
-
He makes some very good points, and a very interesting view on the MSDN Magazine camp vs. The Raymond Chen camp. As a developer I can agree 100% about the MSDN camp winning; for several months now all I see on MSDN is articles on technology MS wants us to use as a replacement to our existing technology. To make it worse, often times this technology isn't even available to developers (for example, I've been reading many articles and code samples pertaining to Longhorn, Avalon, XAML, generics, etc. which developers can't get unless your boss is generous enough to get an MSDN subscription, and even then it's just tech previews of software of alpha maturity. I disagree with him on several points though. One is the idea that web apps will eventually overtake rich client apps. I don't see this happening, although I think the line between a rich client app and a web app will become blurred as client apps start getting deployed through web browsers. The reason I doubt this is simply because people ~like~ running rich client apps, believe it or not. Sure, web apps suffice for some simpler tasks like web mail, but honestly, no one wants to have to navigate to some URL to run office. MS has done a lot of research in this area and had to change some of their stategies for planned web apps. And it's not just end users, I find (as Joel points out) that most power user/geek types truely despise the idea of replacing client apps with web apps. Just because web apps make deployment a lesser burden on the developer does not mean developers should switch en masse to writing web apps. I also disagree that .NET, the 'unification of the mess of VB, C++, and Win32', has only created a bigger mess. As a former C/C++ developer, I find .NET to be a breath of fresh air from the disaster that is previous programming models in C and VB. Sometimes when things get messy enough, it's time to start with a clean slate. Now .NET doesn't exactly wipe out Win32 (obviously, many parts of .NET wrap existing Win32 and COM APIs) so one could argue that .NET is more a mask over ugliness than a clean slate of beauty, but that's where WinFX comes in, which brings me to the 3rd point I disagree with him. WinFX is going to be revolutionary. If anyone doesn't fully understand the scope of what they're trying to accomplish with Longhorn and WinFX, I urge you to read this article[
Judah Himango wrote: It's time for Windows to become a secure operating system, it's time for developers to write software using a modern API, it's time to move on and let Win32 and its associated unmanaged & unsafe rich client apps die. We'll move on to a secure & safe execution environment with rich client apps that run both over the web and locally, with modern user interfaces that utilize the powerful hardware we have today. I am always part-amused and part-irritated with talk about "safe" or "unsafe" code --- a piece of Microsoft marketing fluff that some people have swallowed. What we are moving toward is greater dependence on Microsoft code libraries and there is every reason to believe that they will be as buggy as ever and that the design will be less than ideal. I view the future without concern but also without any illusions that current problems are going to be solved by Microsoft's next version of whatever. John Carson "I believe in an America where the separation of church and state is absolute--where no Catholic prelate would tell the President (should he be Catholic) how to act, and no Protestant minister would tell his parishoners for whom to vote ... and where no man is denied public office merely because his religion differs from the President who might appoint him or the people who might elect him. - John F. Kennedy
-
He makes some very good points, and a very interesting view on the MSDN Magazine camp vs. The Raymond Chen camp. As a developer I can agree 100% about the MSDN camp winning; for several months now all I see on MSDN is articles on technology MS wants us to use as a replacement to our existing technology. To make it worse, often times this technology isn't even available to developers (for example, I've been reading many articles and code samples pertaining to Longhorn, Avalon, XAML, generics, etc. which developers can't get unless your boss is generous enough to get an MSDN subscription, and even then it's just tech previews of software of alpha maturity. I disagree with him on several points though. One is the idea that web apps will eventually overtake rich client apps. I don't see this happening, although I think the line between a rich client app and a web app will become blurred as client apps start getting deployed through web browsers. The reason I doubt this is simply because people ~like~ running rich client apps, believe it or not. Sure, web apps suffice for some simpler tasks like web mail, but honestly, no one wants to have to navigate to some URL to run office. MS has done a lot of research in this area and had to change some of their stategies for planned web apps. And it's not just end users, I find (as Joel points out) that most power user/geek types truely despise the idea of replacing client apps with web apps. Just because web apps make deployment a lesser burden on the developer does not mean developers should switch en masse to writing web apps. I also disagree that .NET, the 'unification of the mess of VB, C++, and Win32', has only created a bigger mess. As a former C/C++ developer, I find .NET to be a breath of fresh air from the disaster that is previous programming models in C and VB. Sometimes when things get messy enough, it's time to start with a clean slate. Now .NET doesn't exactly wipe out Win32 (obviously, many parts of .NET wrap existing Win32 and COM APIs) so one could argue that .NET is more a mask over ugliness than a clean slate of beauty, but that's where WinFX comes in, which brings me to the 3rd point I disagree with him. WinFX is going to be revolutionary. If anyone doesn't fully understand the scope of what they're trying to accomplish with Longhorn and WinFX, I urge you to read this article[
Judah Himango wrote: I believe the reason is two-fold: one, Microsoft wants you to upgrade to Longhorn and buy a new computer. They're a company, companies exist to make money. And while everyone but MS will bitch over this, and about how it may be temporarily bad for your wallet, it's generally good for advancing higher levels of software development, pushes the need for faster and better hardware, it allows developers greater flexibility in terms of what can be done with computing, and generally drives the industry we are making a living off of. People complain about this.. becuase this model doesn't work. Just look at all the people out there still running downlevel OSes. There are *far* more people running something other than Windows XP or Server 2003 than there are running it. Nobody in their right mind would develop software that *only* runs on XP. Same thing will happen in Longhorn... most developers are going to write apps that will be backwards-compatible with XP, 2000, etc. "Fish and guests stink in three days." - Benjamin Franlkin
-
joel wrote ... Racing car aficionados will probably send me hate mail for this, but my experience has been that there is only one case, in normal driving, where a good automatic transmission is inferior to a manual transmission i almost had to write sum hate mail here. joel ought to stick to software. there is SOooo many reasons this statement is wrong. blah
joshfl wrote: almost had to write sum hate mail here. joel ought to stick to software. there is SOooo many reasons this statement is wrong. What are they ? A good modern automatic is in many ways BETTER than a manual transmission in normal driving. The only situation I can think of when its not is when pulling a heavy trailer. There may ba a case for debate about driving in bad weather but that is more a function of antispin antilock technology and not the tranny. Richard "He who joyfully marches in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would suffice. --Albert Einstein
-
Judah Himango wrote: It's time for Windows to become a secure operating system, it's time for developers to write software using a modern API, it's time to move on and let Win32 and its associated unmanaged & unsafe rich client apps die. We'll move on to a secure & safe execution environment with rich client apps that run both over the web and locally, with modern user interfaces that utilize the powerful hardware we have today. I am always part-amused and part-irritated with talk about "safe" or "unsafe" code --- a piece of Microsoft marketing fluff that some people have swallowed. What we are moving toward is greater dependence on Microsoft code libraries and there is every reason to believe that they will be as buggy as ever and that the design will be less than ideal. I view the future without concern but also without any illusions that current problems are going to be solved by Microsoft's next version of whatever. John Carson "I believe in an America where the separation of church and state is absolute--where no Catholic prelate would tell the President (should he be Catholic) how to act, and no Protestant minister would tell his parishoners for whom to vote ... and where no man is denied public office merely because his religion differs from the President who might appoint him or the people who might elect him. - John F. Kennedy
John Carson wrote: I am always part-amused and part-irritated with talk about "safe" or "unsafe" code --- a piece of Microsoft marketing fluff that some people have swallowed. That's where you're wrong. Go write a C++ library and put in on the web as an ActiveX control. Guess what - it's unsafe code, and when a user goes to run it, it's an all-or-nothing blind prayer your code doesn't do anything malicious. Or put an unmanaged .exe on the web for download; after I go download it I have to say a few Hail Mary's in hopes your code doesn't do anything bad. Don't like the marketing term 'unsafe code'? Fine, let's just call it potentially dangerous code, because it has the potential to corrupt someone's machine. On the flip side, take a look at so-called 'safe code' using .NET or Java. I can write an applet in Java and the J2EE runtime can guarantee (bugs aside) that the code being run will not harm my machine. Or I can write a C# .exe and deploy it either over the web or run it locally and the CLR runtime can guarantee (bugs aside) that the code being run will not harm my machine. So guess what? It's no longer a pray and run situation anymore! Pray and run situations are bad for the user and have already irreparably damanged the image of computer security. Imagine if all client apps were managed code? Here I could actually click on one of those 'important document' spam attachments without damaging my machine. :-) I don't like marketing terms either, but 'safe' or 'verified' code correctly describes code running in a managed & secure environment ala .NET, and 'unsafe' code very accurately describes unmanaged code. #include "witty_sig.h"
-
Judah Himango wrote: I believe the reason is two-fold: one, Microsoft wants you to upgrade to Longhorn and buy a new computer. They're a company, companies exist to make money. And while everyone but MS will bitch over this, and about how it may be temporarily bad for your wallet, it's generally good for advancing higher levels of software development, pushes the need for faster and better hardware, it allows developers greater flexibility in terms of what can be done with computing, and generally drives the industry we are making a living off of. People complain about this.. becuase this model doesn't work. Just look at all the people out there still running downlevel OSes. There are *far* more people running something other than Windows XP or Server 2003 than there are running it. Nobody in their right mind would develop software that *only* runs on XP. Same thing will happen in Longhorn... most developers are going to write apps that will be backwards-compatible with XP, 2000, etc. "Fish and guests stink in three days." - Benjamin Franlkin
Navin wrote: There are *far* more people running something other than Windows XP or Server 2003 than there are running it. I disagree. This model works because Microsoft has a monopoly. Take a look at Google Zeitgeist[^], in particular the OSes used to access Google[^]. This is a pretty good indication of the current market - currently 67% of all searches on Google were made by machines running Windows XP or 2000. That's pretty impressive by any standard, just goes to show that a lot of people do in fact upgrade or just buy new machines altogether, even after the .com bomb, even after everyone had already been running a solid OS (Win98 SE). That said, I do agree developers will not develop Longhorn-specific software until a vast majority of machines can run their software, or until emulation software or alternative runtimes ala Mono can run XAML+Avalon on multiple OSes, both of which are very likely to happen. #include "witty_sig.h"
-
Navin wrote: There are *far* more people running something other than Windows XP or Server 2003 than there are running it. I disagree. This model works because Microsoft has a monopoly. Take a look at Google Zeitgeist[^], in particular the OSes used to access Google[^]. This is a pretty good indication of the current market - currently 67% of all searches on Google were made by machines running Windows XP or 2000. That's pretty impressive by any standard, just goes to show that a lot of people do in fact upgrade or just buy new machines altogether, even after the .com bomb, even after everyone had already been running a solid OS (Win98 SE). That said, I do agree developers will not develop Longhorn-specific software until a vast majority of machines can run their software, or until emulation software or alternative runtimes ala Mono can run XAML+Avalon on multiple OSes, both of which are very likely to happen. #include "witty_sig.h"
Judah, I really don't disagree with anything you have said. But your point with 67% also works against WinFX. If your starting a new project and you know you have users that still run XP and 2000 you won't be using WinFX on that project. This is just an undeniable fact.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
-
Judah Himango wrote: It's time for Windows to become a secure operating system, it's time for developers to write software using a modern API, it's time to move on and let Win32 and its associated unmanaged & unsafe rich client apps die. We'll move on to a secure & safe execution environment with rich client apps that run both over the web and locally, with modern user interfaces that utilize the powerful hardware we have today. I am always part-amused and part-irritated with talk about "safe" or "unsafe" code --- a piece of Microsoft marketing fluff that some people have swallowed. What we are moving toward is greater dependence on Microsoft code libraries and there is every reason to believe that they will be as buggy as ever and that the design will be less than ideal. I view the future without concern but also without any illusions that current problems are going to be solved by Microsoft's next version of whatever. John Carson "I believe in an America where the separation of church and state is absolute--where no Catholic prelate would tell the President (should he be Catholic) how to act, and no Protestant minister would tell his parishoners for whom to vote ... and where no man is denied public office merely because his religion differs from the President who might appoint him or the people who might elect him. - John F. Kennedy
Oooh one other thing I'd like to address. John Carson wrote: What we are moving toward is greater dependence on Microsoft code libraries How does running code in a managed virtual machine environment place more dependence on Microsoft? If anything, the abstraction from the underlying platform provided by .NET unties us from any particular platform; you can keep your C# code and run it on Red Hat via Mono, DotGNU, or another alternative managed environment if you want. Whereas if your unmanaged code uses the Win32 library directly, you're completely tied to a Microsoft OS and are forced to either rewrite your code or depend on a Windows emulator ala Wine to run on different platforms. #include "witty_sig.h"
-
Judah, I really don't disagree with anything you have said. But your point with 67% also works against WinFX. If your starting a new project and you know you have users that still run XP and 2000 you won't be using WinFX on that project. This is just an undeniable fact.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
Right, but the point I'm making is that new OSes from Microsoft, especially landmark releases such as Windows 95, XP, or Longhorn, are adopted fairly quickly, and the pace continues until another OS is released. Again, I agree that virtually all developers won't write Longhorn-specific software until a vast majority of users can run it. That means either Microsoft will have to develop an Avalon runtime/emulator for XP and 2k, alternative runtimes like Mono will develop their software such that a majority of users can run it, or Longhorn is run by a vast majority of users. All 3 are certainly possible, but the former 2 are more likely in the nearer future. #include "witty_sig.h"
-
joshfl wrote: almost had to write sum hate mail here. joel ought to stick to software. there is SOooo many reasons this statement is wrong. What are they ? A good modern automatic is in many ways BETTER than a manual transmission in normal driving. The only situation I can think of when its not is when pulling a heavy trailer. There may ba a case for debate about driving in bad weather but that is more a function of antispin antilock technology and not the tranny. Richard "He who joyfully marches in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would suffice. --Albert Einstein
-
Oooh one other thing I'd like to address. John Carson wrote: What we are moving toward is greater dependence on Microsoft code libraries How does running code in a managed virtual machine environment place more dependence on Microsoft? If anything, the abstraction from the underlying platform provided by .NET unties us from any particular platform; you can keep your C# code and run it on Red Hat via Mono, DotGNU, or another alternative managed environment if you want. Whereas if your unmanaged code uses the Win32 library directly, you're completely tied to a Microsoft OS and are forced to either rewrite your code or depend on a Windows emulator ala Wine to run on different platforms. #include "witty_sig.h"
Judah Himango wrote: How does running code in a managed virtual machine environment place more dependence on Microsoft? If anything, the abstraction from the underlying platform provided by .NET unties us from any particular platform; you can keep your C# code and run it on Red Hat via Mono, DotGNU, or another alternative managed environment if you want. Whereas if your unmanaged code uses the Win32 library directly, you're completely tied to a Microsoft OS and are forced to either rewrite your code or depend on a Windows emulator ala Wine to run on different platforms. I referred to dependence on Microsoft code libraries. I agree that there is no greater tying to the Windows platform, just a greater reliance on code libraries that happen to be written by Microsoft (or its imitators in the case of the Mono project). Of course, there are great benefits from code libraries but Microsoft proliferates them at a rate that ensures that they are usually fairly buggy. That and the learning curves involved makes some of them more trouble than they are worth for a lot of developers (though some developers will of course find their lives being made easier). John Carson "I believe in an America where the separation of church and state is absolute--where no Catholic prelate would tell the President (should he be Catholic) how to act, and no Protestant minister would tell his parishoners for whom to vote ... and where no man is denied public office merely because his religion differs from the President who might appoint him or the people who might elect him. - John F. Kennedy
-
There is really not that much difference in fuel use - less than 1 1/2 MPG. In many cases with an unskilled operator the auto will do better than the manual. An automated manual is an auto is it not ? And just what is a slush box ? Soon the question will be moot anyway. When we get to using electric engines there will be no need for a tranny. A modern computer controled transmission is an engineering marvel - take a look at them. Ford is using one in some of their race cars. The Chevy Vette with an auto has performance specs equal to the in line manual tranny as far as acceleration etc.. is concerned. I personally think that the manual tranny is just a macho type thing. There is no longer any need , except in large truck type vehicles, for a manual and all its inheirent problems. Richard "He who joyfully marches in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would suffice. --Albert Einstein
-
joshfl wrote: almost had to write sum hate mail here. joel ought to stick to software. there is SOooo many reasons this statement is wrong. What are they ? A good modern automatic is in many ways BETTER than a manual transmission in normal driving. The only situation I can think of when its not is when pulling a heavy trailer. There may ba a case for debate about driving in bad weather but that is more a function of antispin antilock technology and not the tranny. Richard "He who joyfully marches in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would suffice. --Albert Einstein
I bet you brag about that hot little Dodge Caravan in your driveway, don't you? :rolleyes:
Software Zen:
delete this; -
John Carson wrote: I am always part-amused and part-irritated with talk about "safe" or "unsafe" code --- a piece of Microsoft marketing fluff that some people have swallowed. That's where you're wrong. Go write a C++ library and put in on the web as an ActiveX control. Guess what - it's unsafe code, and when a user goes to run it, it's an all-or-nothing blind prayer your code doesn't do anything malicious. Or put an unmanaged .exe on the web for download; after I go download it I have to say a few Hail Mary's in hopes your code doesn't do anything bad. Don't like the marketing term 'unsafe code'? Fine, let's just call it potentially dangerous code, because it has the potential to corrupt someone's machine. On the flip side, take a look at so-called 'safe code' using .NET or Java. I can write an applet in Java and the J2EE runtime can guarantee (bugs aside) that the code being run will not harm my machine. Or I can write a C# .exe and deploy it either over the web or run it locally and the CLR runtime can guarantee (bugs aside) that the code being run will not harm my machine. So guess what? It's no longer a pray and run situation anymore! Pray and run situations are bad for the user and have already irreparably damanged the image of computer security. Imagine if all client apps were managed code? Here I could actually click on one of those 'important document' spam attachments without damaging my machine. :-) I don't like marketing terms either, but 'safe' or 'verified' code correctly describes code running in a managed & secure environment ala .NET, and 'unsafe' code very accurately describes unmanaged code. #include "witty_sig.h"
Judah Himango wrote: That's where you're wrong. Go write a C++ library and put in on the web as an ActiveX control. Guess what - it's unsafe code, and when a user goes to run it, it's an all-or-nothing blind prayer your code doesn't do anything malicious. Or put an unmanaged .exe on the web for download; after I go download it I have to say a few Hail Mary's in hopes your code doesn't do anything bad. Don't like the marketing term 'unsafe code'? Fine, let's just call it potentially dangerous code, because it has the potential to corrupt someone's machine. On the flip side, take a look at so-called 'safe code' using .NET or Java. I can write an applet in Java and the J2EE runtime can guarantee (bugs aside) that the code being run will not harm my machine. Or I can write a C# .exe and deploy it either over the web or run it locally and the CLR runtime can guarantee (bugs aside) that the code being run will not harm my machine. So guess what? It's no longer a pray and run situation anymore! Pray and run situations are bad for the user and have already irreparably damanged the image of computer security. Imagine if all client apps were managed code? Here I could actually click on one of those 'important document' spam attachments without damaging my machine. My area is desktop apps rather than network/Internet stuff. In that context, "unsafe" code means manual resource management and the associated risk of resource leaks. In fact, my strong impression is that the chief use of the term by Microsoft relates to manual resource management. This annoys me because the use of sensible C++ programming idioms (use of the Standard library, acquiring resources in constructors and releasing them in destructors, use of smart pointers etc.) makes resource leaks a minor issue. Well-written apps are in this respect very safe. On the other hand, there is ample scope for managed code to be buggy and hence to be "unsafe" in other ways. You make the point that you can run applets in a sandbox and, bugs aside, the sandbox will stop them doing anything malicious. Of course, bugs aside, Windows machines wouldn't have anywhere near the vulnerability to viruses that they currently do. But there are bugs. Nevertheless, I accept the basic point that sandboxes can be useful in restricting permissions to applications that can do their job with limited rights (this, of course, is also the principle behind Administrator vs User privileges and the like on the desktop, which are applicable to "unsafe" C++ code).
