Code Comments
Programming Forum and web based access to our favorite programming groups.An interesting discussion came up in the office the other day with regards to MS's commitment to managed code. A coworker, whose opinion I highly respect was basically asking some questions and making some statements that basically revolved around MS practicing what it preached ... basically he is saying: "MS seems to be telling us to bet our stuff on Managed Code, 'build you applications on managed code, it is THE way to go...', but how much of Microsoft's own applications are done in managed code? Why is Visual Studio even the newer (2005) versions not fully managed code? Eclipse ... which has less resources than MS did a rewrite of the environment in completely managed code (ie. Java) in very little time. I don't see MS Office moving to managed code? I don't see SQL Engine stuff moving to managed code, yes ... Yucon is 'hosting' the CLR, but it isn't depended on it? they don't seem to be putting the same kind of investment in the CLR that they are constantly telling us to ..." and so on and so forth ... I was basically attempting to defend MS's position, not because I *love* MS, but because I believe that MS is committed, and that their decisions are not as simple as 'To be Managed, or not to be ..." it's business, legacy, the right mix between resources for re-writing and innovation etc, etc. At the end of the day ... I don't know jack about the real hard figures ... so I got me some questions for the MS guys... How much (what percentage) of VS was developed in Managed Code? Are any of MS products written completely in .NET ? If so What are they ? What is the future plan for MS product lines with regard to moving to Managed Code? And any other questions you guys can think of that will add to this discussion. Cordell Lawrence [clawrence@teleios-systems.com] Teleios Systems Ltd. [www.teleios-systems.com]
Post Follow-up to this messageHere's my best guess: Microsoft has been developing applications in native machine language for over 20 years, using C and C++. These apps have a long history, and are quite large in scope as well as size. Therefore, it will take Microsoft quite awhile to convert many of them to managed code. There is also another aspect to it: performance. Managed code is not useful for everything. Sometimes it takes some unmanaged code to do things quickly. For example, take Bitmaps. The managed Bitmap class has a GetPixel() method that will allow you access to individual pixels in the Bitmap. However, if you want to perform some kind of filter on an image (blur, sharpness, etc), it is necessary to make changes to ALL the pixels in the Bitmap. Using the GetPixel() method to do this takes way too much time, and uses too much resources. This is why the Bitmap class has a property called Scan0. Scan0 is the memory address of the first pixel in the Bitmap. Using unmanaged C code with a pointer, you can loop through all the pixels, and perform the necessary math on each one in a very short time interval. This is why even managed classes often have unmanaged code hidden deep inside them. Therefore, it is sometimes a matter of performance when to use or not use managed code. The beauty of managed code is that you can get down and dirty with the bits when you need to, and work fast and easy when you can. It is not so much a substitute for native machine code as it is an extension, a layer of abstraction, if you will. It does not preclude one from using unmanaged code. Instead, it offers the ability to use unmanaged code when needed. -- HTH, Kevin Spencer Microsoft MVP .Net Developer What You SIs What You Get. "Cordell Lawrence" <clawrence@teleios-systems.com> wrote in message news:eQPvT$GNFHA.3420@tk2msftngp13.phx.gbl... > An interesting discussion came up in the office the other day with regards > to MS's commitment to managed code. A coworker, whose opinion I highly > respect was basically asking some questions and making some statements > that > basically revolved around MS practicing what it preached ... basically he > is > saying: > > "MS seems to be telling us to bet our stuff on Managed Code, 'build you > applications on managed code, it is THE way to go...', but how much of > Microsoft's own applications are done in managed code? Why is Visual > Studio > even the newer (2005) versions not fully managed code? Eclipse ... which > has > less resources than MS did a rewrite of the environment in completely > managed code (ie. Java) in very little time. I don't see MS Office moving > to > managed code? I don't see SQL Engine stuff moving to managed code, yes ... > Yucon is 'hosting' the CLR, but it isn't depended on it? they don't seem > to > be putting the same kind of investment in the CLR that they are constantly > telling us to ..." > > and so on and so forth ... I was basically attempting to defend MS's > position, not because I *love* MS, but because I believe that MS is > committed, and that their decisions are not as simple as 'To be Managed, > or > not to be ..." it's business, legacy, the right mix between resources for > re-writing and innovation etc, etc. At the end of the day ... I don't know > jack about the real hard figures ... so I got me some questions for the MS > guys... > > How much (what percentage) of VS was developed in Managed Code? > Are any of MS products written completely in .NET ? If so What are they ? > What is the future plan for MS product lines with regard to moving to > Managed Code? > > And any other questions you guys can think of that will add to this > discussion. > > Cordell Lawrence [clawrence@teleios-systems.com] > Teleios Systems Ltd. [www.teleios-systems.com] > > >
Post Follow-up to this message"Kevin Spencer" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message news:%237rihwHNFHA.2384@tk2msftngp13.phx.gbl... > Here's my best guess: Microsoft has been developing applications in native > machine language for over 20 years, using C and C++. These apps have a > long history, and are quite large in scope as well as size. Therefore, it > will take Microsoft quite awhile to convert many of them to managed code. > > There is also another aspect to it: performance. Managed code is not > useful for everything. Sometimes it takes some unmanaged code to do things > quickly. For example, take Bitmaps. The managed Bitmap class has a > GetPixel() method that will allow you access to individual pixels in the > Bitmap. However, if you want to perform some kind of filter on an image > (blur, sharpness, etc), it is necessary to make changes to ALL the pixels > in the Bitmap. Using the GetPixel() method to do this takes way too much > time, and uses too much resources. This is why the Bitmap class has a > property called Scan0. Scan0 is the memory address of the first pixel in > the Bitmap. Using unmanaged C code with a pointer, you can loop through > all the pixels, and perform the necessary math on each one in a very short > time interval. This is why even managed classes often have unmanaged code > hidden deep inside them. > > Therefore, it is sometimes a matter of performance when to use or not use > managed code. > > The beauty of managed code is that you can get down and dirty with the > bits when you need to, and work fast and easy when you can. It is not so > much a substitute for native machine code as it is an extension, a layer > of abstraction, if you will. It does not preclude one from using unmanaged > code. Instead, it offers the ability to use unmanaged code when needed. > > -- Which brings up another point. How much of the managed code was written using managed code? It all comes down to all of the "managed" code was written using lower-level languages such as C/C++, Assembler, et cetera... Can't we just have COBOL.Net or Natural.Net become the new standard??? (jk of course) Mythran
Post Follow-up to this messageThanks for the reply Kevin, I agree with you and have said all that you have to my collegue, so Performance and problem applicability to Managed code are both big issues, but he continues to argue that MS touts the performance of the CLR and still wants US to build stuff on managed code(I disagree that this simplistic view is their position), plus he (as I knew he would lol) pointed out that there are managed interfaces to many things that you would think should be done natively like Graphics, there are both Managed Direct X interfaces and thigns like GDI+. At the end of the day I disagree with him, but I just thought that it would be really interesting to hear what the community thinks. Looking forward to more feedback guys. I'm particularly interested in hearing from some on the VS developemnt team about how much of it was developed in Managed code. Cordell Lawrence "Kevin Spencer" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message news:%237rihwHNFHA.2384@tk2msftngp13.phx.gbl... > Here's my best guess: Microsoft has been developing applications in native > machine language for over 20 years, using C and C++. These apps have a long > history, and are quite large in scope as well as size. Therefore, it will > take Microsoft quite awhile to convert many of them to managed code. > > There is also another aspect to it: performance. Managed code is not useful > for everything. Sometimes it takes some unmanaged code to do things quickly. > For example, take Bitmaps. The managed Bitmap class has a GetPixel() method > that will allow you access to individual pixels in the Bitmap. However, if > you want to perform some kind of filter on an image (blur, sharpness, etc), > it is necessary to make changes to ALL the pixels in the Bitmap. Using the > GetPixel() method to do this takes way too much time, and uses too much > resources. This is why the Bitmap class has a property called Scan0. Scan0 > is the memory address of the first pixel in the Bitmap. Using unmanaged C > code with a pointer, you can loop through all the pixels, and perform the > necessary math on each one in a very short time interval. This is why even > managed classes often have unmanaged code hidden deep inside them. > > Therefore, it is sometimes a matter of performance when to use or not use > managed code. > > The beauty of managed code is that you can get down and dirty with the bits > when you need to, and work fast and easy when you can. It is not so much a > substitute for native machine code as it is an extension, a layer of > abstraction, if you will. It does not preclude one from using unmanaged > code. Instead, it offers the ability to use unmanaged code when needed. > > -- > HTH, > > Kevin Spencer > Microsoft MVP > .Net Developer > What You SIs What You Get. > > "Cordell Lawrence" <clawrence@teleios-systems.com> wrote in message > news:eQPvT$GNFHA.3420@tk2msftngp13.phx.gbl... regards he moving ... constantly for know MS ? > >
Post Follow-up to this messageWell, Cordell, Performance and problem applicability have ALWAYS been issues. The fastest program in the world would have to be written in machine language only. Assembler was a short-hand code for creating sequences of machine language. Of course, one could go through the resultant machine language and optimize it a bit more. But the purpose of Assembler was that programs were getting too big and complex to write in machine language with any speed. C, and higher-level languages were written for the same purpose. Higher-level languages are first compiled into Assembler, and the Assembler is compiled into machine language. Of course, some optimization is lost in the process. As the "programming stack" gets higher, optimization suffers, but productivity increases. In fact, .Net is highly optimized, and runs faster than its chief competitor, Java, which is also a platform-independent byte code that must be fully compiled at run-time via a Just-In-Time virtual machine. And let's not forget Moore's law. Programs that we wirte today run exponentially faster than programs that ran on 386 machines, so the loss in optimization is more than made up for the gain in machine speed. Buts, as C, for example, allows you to write in-line Assembler when needed, C# let's you write C when needed. It is helpful to think of each new programming technology as an "extension" of an older programming technology, because you don't lose anything; you actually gian something. You retain the ability to do the low-level programming when warranted, but also have the ability to use the higher-level stuff for productivity's sake. -- HTH, Kevin Spencer Microsoft MVP .Net Developer What You SIs What You Get. "Cordell Lawrence" <clawrence@teleios-systems.com> wrote in message news:%23NXFW5HNFHA.3704@TK2MSFTNGP12.phx.gbl... > Thanks for the reply Kevin, I agree with you and have said all that you > have > to my collegue, so Performance and problem applicability to Managed code > are > both big issues, but he continues to argue that MS touts the performance > of > the CLR and still wants US to build stuff on managed code(I disagree that > this simplistic view is their position), plus he (as I knew he would lol) > pointed out that there are managed interfaces to many things that you > would > think should be done natively like Graphics, there are both Managed Direct > X > interfaces and thigns like GDI+. At the end of the day I disagree with > him, > but I just thought that it would be really interesting to hear what the > community thinks. > > Looking forward to more feedback guys. I'm particularly interested in > hearing from some on the VS developemnt team about how much of it was > developed in Managed code. > > Cordell Lawrence > > "Kevin Spencer" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message > news:%237rihwHNFHA.2384@tk2msftngp13.phx.gbl... > long > useful > quickly. > method > etc), > bits > regards > he > moving > ... > constantly > for > know > MS > ? > >
Post Follow-up to this message> Which brings up another point. How much of the managed code was written > using managed code? It all comes down to all of the "managed" code was > written using lower-level languages such as C/C++, Assembler, et cetera... Well, you have to understand how managed code is processed to know the answer to that one. Managed code is compiled into IldAsm, which is a platform-independent byte code. You could certainly write managed classes to do this. But the byte code is only part of the story. At run-time, the code is fully-compiled to native machine language, by the Just-In_Time .Net virtual machine. Managed code could not do this. The virtual machine is not managed code, as it must operate on the machine for which it is built. Therefore, like Java, there are different virtual machines for different computer systems. As for the rest, well, most managed code is wrappers for Windows API calls. Windows API calls are not in any way managed code. So, way at the bottom of most CLR classes, where you can't see it, most of them use unmanaged code at some level. -- HTH, Kevin Spencer Microsoft MVP .Net Developer What You SIs What You Get. > Can't we just have COBOL.Net or Natural.Net become the new standard??? (jk > of course) "Mythran" <kip_potter@hotmail.comREMOVETRAIL> wrote in message news:egyQE2HNFHA.164@TK2MSFTNGP12.phx.gbl... > > "Kevin Spencer" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message > news:%237rihwHNFHA.2384@tk2msftngp13.phx.gbl... > > Which brings up another point. How much of the managed code was written > using managed code? It all comes down to all of the "managed" code was > written using lower-level languages such as C/C++, Assembler, et cetera... > > Can't we just have COBOL.Net or Natural.Net become the new standard??? (jk > of course) > > Mythran > >
Post Follow-up to this messageHey Kevin, I do understand all these things concerning Managed code versus Native code. Managed code has shown similar performance characteristics to native code (minus JIT time) and in some cases has even surpassed code written in non-managed languages such as C & C++. I disagree that the fastest application would have to be written in machine code (and please bear with me, I'm being "devil's advocate here), because at the end of the day all applications at their core are machine code, and it is possible to write very poor machine code and as a result get a very poorly performing application (although this will be alot harder to do at the machine code level of abstraction than it would in our 4th gen languages of today), it's really about how smart the compiler is, and if there was this 'super-duper infinitely smart compiler' lol, then we could have perfectly generated machine code, but as we all know there exists no such compiler :). But this is not really my arguement, I could argue that applications like Visual Studio, where the extra 100 pico / nano seconds for processing graphic surfaces or blitting regions of video memory are not *really* necessary, speed at this level is a mut-point. I guess, in my head I'm thinking ... there isn't really any technical reasons that VS could not be written completely in Managed code (or is there??) and I'm interested in the choices that the people at MS have to make when making that decision, and I'm not talking about the compiler parts of the platform ... in fact all my assumptions about VS not being in managed code may be completely off base to begin with and they could have implemented 80 ... or 90 percent of Visual Studio in managed code :) Hope I'm not being too much of a pain Kevin :) lol, again, looking forward to more feedback. Thanks in advance. Cordell Lawrence
Post Follow-up to this messageYou can be a "devil's advocate" all day long as far as I'm concerned. but your logic is flawed. The only logical way to compare managed code to native machine code is to compare apples to apples. IOW, all else being the same, machine code can be written which runs much faster than any programming language can write. That's not a matter of debate. That's a matter of pure fact. The best compilers in the world can't optimize to the degree that you seem to give them credit for. Think of it this way: You have to mow your lawn. Now, if you want it perfect, you get a pair of scissors and a ruler, and cut every blade to the same length. Perfect. But of course, you don't have time for that. Why, by the time you get your grass cut it will have needed cutting many times over! So, you buy a lawn mower, a REALLY GOOD one, in fact, the best friggin' lawn mower ever made. Now, that lawn mower can cut MOST of your grass to APPROXIMATELY the length you want. But it will never be able to cut it as well as you could by hand. It would have to do it the same way you do to get the best results, and that would take much too long for it to cut your lawn. > I guess, in my head I'm thinking ... > there isn't really any technical reasons that VS could not be written > completely in Managed code (or is there??) and I'm interested in the > choices > that the people at MS have to make when making that decision, and I'm not > talking about the compiler parts of the platform ... in fact all my > assumptions about VS not being in managed code may be completely off base > to > begin with and they could have implemented 80 ... or 90 percent of Visual > Studio in managed code :) Actually, what you SHOULD be thinking is "what technical reasons would PREVENT Microsoft from using unmanaged code in the .Net platform?" And the answer is, there are none. Programming technologies are tools. Programmers are builders. When I want to build something, I don't ask myself, "how can I do it using this tool?" I ask myself "what is the best tool to use to get this built right?" And that is the tool I use. IOW, Microsoft makes the same sorts of decisions regarding building a programming toolset that all programmers make when deciding how to build an application. How do I meet my requirements? What are the best tools to use to efficiently build my app to the requirements? -- HTH, Kevin Spencer Microsoft MVP .Net Developer What You SIs What You Get. "Cordell Lawrence" <clawrence@teleios-systems.com> wrote in message news:Ot7ZbtJNFHA.244@TK2MSFTNGP12.phx.gbl... > Hey Kevin, I do understand all these things concerning Managed code versus > Native code. Managed code has shown similar performance characteristics to > native code (minus JIT time) and in some cases has even surpassed code > written in non-managed languages such as C & C++. I disagree that the > fastest application would have to be written in machine code (and please > bear with me, I'm being "devil's advocate here), because at the end of the > day all applications at their core are machine code, and it is possible to > write very poor machine code and as a result get a very poorly performing > application (although this will be alot harder to do at the machine code > level of abstraction than it would in our 4th gen languages of today), > it's > really about how smart the compiler is, and if there was this 'super-duper > infinitely smart compiler' lol, then we could have perfectly generated > machine code, but as we all know there exists no such compiler :). But > this > is not really my arguement, I could argue that applications like Visual > Studio, where the extra 100 pico / nano seconds for processing graphic > surfaces or blitting regions of video memory are not *really* necessary, > speed at this level is a mut-point. I guess, in my head I'm thinking ... > there isn't really any technical reasons that VS could not be written > completely in Managed code (or is there??) and I'm interested in the > choices > that the people at MS have to make when making that decision, and I'm not > talking about the compiler parts of the platform ... in fact all my > assumptions about VS not being in managed code may be completely off base > to > begin with and they could have implemented 80 ... or 90 percent of Visual > Studio in managed code :) > > Hope I'm not being too much of a pain Kevin :) lol, again, looking forward > to more feedback. > > Thanks in advance. > > Cordell Lawrence > >
Post Follow-up to this messageKevin, we are not in disagrement, just appreciate the theoretical point that I'm making here Kevin wrote: language only. Assembler was a short-hand code for creating sequences of machine language. Of course, one could go through the resultant machine language and optimize it a bit more. Cordell wrote: machine code ... [1] Because at the end of the day all applications "at their core are machine code" [2] It is possible to write very poor machine code and as a result get a very poorly performing application (although this will be alot harder to do at the machine code level of abstraction than it would in our 4th gen languages of today) [3] It's really about how smart the compiler is, and if there was this 'super-duper infinitely smart compiler' then we could have perfectly generated machine code (noticed that I quoted 'super-duper infinitely smart compiler) [4] But as we all know there exists no such compiler (So we clearly agree, I'm not giving compilers any more credit than they deserve and the do deserve quite a bit, I'm just stating that machine-code isn't faster than compiled C++ [or any other compiled code) soley because of the fact that it's machine code, but becuase compilers are not smart enough to optmize every last bit of an application the way a piece of hand written machine code can be) Next, not going to address the lawn-mower analogy, there is no need to. But I will address this for arguements sake ... I can't resist Kevin wrote: length you want. But it will never be able to cut it as well as you could by hand. This is an assumption that I can. I mean, I could be cross-eyed, have the sakes with a serious case of nerves ... really, you're "assuming" that I can manages the complexity of cutting i.e. posses the patience, will, concerntration etc etc to cut the lawn better, I think this is a big assumption, though I understand the theoretical point behind this statement. Kevin wrote: PREVENT Microsoft from using unmanaged code in the .Net platform?" And the answer is, there are none. Programming technologies are tools. Programmers are builders. When I want to build something, I don't ask myself, "how can I do it using this tool?" I ask myself "what is the best tool to use to get this built right?" And that is the tool I use. Cordell wrote: reasons that VS could not be written completely in Managed code (or is there??) and I'm interested in the choices that the people at MS have to make when making that decision ... Again, no disagreement from me ... the two statments are semantically equivalent Cordell
Post Follow-up to this message> Kevin, we are not in disagrement, just appreciate the theoretical point > that > I'm making here I tried, but it makes my head hurt to think like that. ;-) -- HTH, Kevin Spencer Microsoft MVP .Net Developer What You SIs What You Get. "Cordell Lawrence" <clawrence@teleios-systems.com> wrote in message news:uuSx$XKNFHA.2748@TK2MSFTNGP09.phx.gbl... > Kevin, we are not in disagrement, just appreciate the theoretical point > that > I'm making here > > Kevin wrote: > > language only. Assembler was a short-hand code for creating sequences of > machine language. Of course, one could go through the resultant machine > language and optimize it a bit more. > > Cordell wrote: > machine code ... > [1] Because at the end of the day all applications "at their core are > machine code" > [2] It is possible to write very poor machine code and as a result get a > very poorly performing application (although this will be alot harder to > do > at the machine code level of abstraction than it would in our 4th gen > languages of today) > [3] It's really about how smart the compiler is, and if there was this > 'super-duper infinitely smart compiler' then we could have perfectly > generated machine code (noticed that I quoted 'super-duper infinitely > smart > compiler) > [4] But as we all know there exists no such compiler (So we clearly agree, > I'm not giving compilers any more credit than they deserve and the do > deserve quite a bit, I'm just stating that machine-code isn't faster than > compiled C++ [or any other compiled code) soley because of the fact that > it's machine code, but becuase compilers are not smart enough to optmize > every last bit of an application the way a piece of hand written machine > code can be) > > Next, not going to address the lawn-mower analogy, there is no need to. > But > I will address this for arguements sake ... I can't resist > > Kevin wrote: > length you want. But it will never be able to cut it as well as you could > by > hand. > > This is an assumption that I can. I mean, I could be cross-eyed, have the > sakes with a serious case of nerves ... really, you're "assuming" that I > can > manages the complexity of cutting i.e. posses the patience, will, > concerntration etc etc to cut the lawn better, I think this is a big > assumption, though I understand the theoretical point behind this > statement. > > > Kevin wrote: > PREVENT Microsoft from using unmanaged code in the .Net platform?" And the > answer is, there are none. Programming technologies are tools. Programmers > are builders. When I want to build something, I don't ask myself, "how can > I > do it using this tool?" I ask myself "what is the best tool to use to get > this built right?" And that is the tool I use. > > Cordell wrote: > reasons that VS could not be written completely in Managed code (or is > there??) and I'm interested in the choices that the people at MS have to > make when making that decision ... > > Again, no disagreement from me ... the two statments are semantically > equivalent > > Cordell > > >
Post Follow-up to this message
Show a Printable Version
Email This Page to Someone!
Receive updates to this thread
Powered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.