 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Visual Studio.NET / General / June 2005Is VS written in Managed Code ?
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] 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.  SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > 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 [quoted text clipped - 38 lines] > Cordell Lawrence [clawrence@teleios-systems.com] > Teleios Systems Ltd. [www.teleios-systems.com] > 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 [quoted text clipped - 23 lines] > 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 > 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. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Can't we just have COBOL.Net or Natural.Net become the new standard??? (jk > of course) >> Here's my best guess: Microsoft has been developing applications in >> native machine language for over 20 years, using C and C++. These apps [quoted text clipped - 34 lines] > > Mythran Personally, I don't see the same commitment from MS about writing managed code as they seem to be expecting from the rest of the development community and industry in general. MS just don't practice what they preach. MS have not completely re-written packages like Office in .Net for the same commercial reasons the rest of us are not re-writing our own packages (and we don't have the funds and resources that they do). I agree we other peoples comments about performance issues and therefore some things are just best left to unmanaged code. However, I recently downloaded the MSDE / SQL 2000 Deployment Toolkit. Great, it contains VC .Net and VB .Net examples however on closer inspection some of the components used behind the sample code are written in VB5 (and they have now removed support for VB6 - don't figure). They even make the point in the instructions to make sure the VB5 runtime is included on your CD / distribution media. SignatureAndrew D. Newbould E-Mail: newsgroups@NOSPAMzadsoft.com ZAD Software Systems Web : www.zadsoft.com Well, you do seem to know a lot about what Microsoft has done in the past, but what about the present? These applications have scheduled releases that span several years time, as they are quite large and complex. What makes you think Microsoft isn't migrating like everyone else, as they can afford it, and as they put out new releases? I can tell you for a fact that they are. Indigo, for example, is written entirely on top of the .Net platform. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Personally, I don't see the same commitment from MS about writing managed > code as they seem to be expecting from the rest of the development [quoted text clipped - 13 lines] > the instructions to make sure the VB5 runtime is included on your CD / > distribution media. >Well, you do seem to know a lot about what Microsoft has done in the past, >but what about the present? These applications have scheduled releases that >span several years time, as they are quite large and complex. What makes you >think Microsoft isn't migrating like everyone else, as they can afford it, >and as they put out new releases? I can tell you for a fact that they are. >Indigo, for example, is written entirely on top of the .Net platform. I accept and agree with your comments Kevin. I am not anti MS and do like some of the new features of the .Net platform however, I still have to maintain and develop existing applications under VB6 (and VS6). I was just trying to make the point that MS like turning the tap off for other Developers when they too have to continue to support Their products, yet MS are happy to keep using old technologies in their own products. By MS's own statements VS 2005 will only contain approx 50% managed code and with its release this will be the 4th version of the product. In Office this figure is around 30-40%. This is not leading by example. The rate of change within MS to using .Net is left to the individual teams to decide when and where its used. In the UK and Europe MS have a bad reputation for looking after ISV's and its only over the last 18 months or so they have been trying to change this. And there is normally a big BUT attached ... we MUST commit to using VS.NET first. As an ISV we can't even get additional copies of VS6 for new Developers without jumping through hoops. Normally down grading a .Net license for additional cost, but then if I want to use that .Net license I have to buy another one. SignatureAndrew D. Newbould E-Mail: newsgroups@NOSPAMzadsoft.com ZAD Software Systems Web : www.zadsoft.com > By MS's own statements VS 2005 will only contain approx 50% managed code > and with its release this will be the 4th version of the product. In > Office this figure is around 30-40%. This is not leading by example. The > rate of change within MS to using .Net is left to the individual teams to > decide when and where its used. Well, by my own admission, my managed apps are only about 90% managed code. Managed code is not a panacaea for the ills of the programming world, and Microsoft certainly doesn't tout it as such. It is an extension of unmanaged code. There are still many times when unmanaged code can do what managed code cannot. The most important consideration in such a decision is performance. Managed code has a fairly high overhead, and definitely runs slower than unmanaged code. But it's a trade-off. Never forget Moore's Law. It is much cheaper today to throw cheap hardware at a performance problem than it is to hire expensive programmers to optimize the wazoo out of the code. The days of saving a bit here and there are long past. IOW, if you are waiting for the day when all Microsoft products use all managed code, don't hold your breath. It will never come. Visual Studio is a monster of an application. The only app that Microsoft makes that is larger and more complex is Windows itself. In such a large and complex application, saleability is affected strongly by performance issues. Programmer time is expensive. The faster the app performs, the more likely it is to sell. And when you need that sort of optimization, you have to get out of the sandbox to do it. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. >>Well, you do seem to know a lot about what Microsoft has done in the past, >>but what about the present? These applications have scheduled releases [quoted text clipped - 25 lines] > license for additional cost, but then if I want to use that .Net license I > have to buy another one. >> By MS's own statements VS 2005 will only contain approx 50% managed code >> and with its release this will be the 4th version of the product. In [quoted text clipped - 21 lines] >when you need that sort of optimization, you have to get out of the sandbox >to do it. Couldn't agree more ! SignatureAndrew D. Newbould E-Mail: newsgroups@NOSPAMzadsoft.com ZAD Software Systems Web : www.zadsoft.com <SNIP SNIP> > code cannot. The most important consideration in such a decision is > performance. Managed code has a fairly high overhead, and definitely runs > slower than unmanaged code. But it's a trade-off. Never forget Moore's Law. At some point, I must have been dreaming, because I swear I've read article after article in MS publications and on the newsgroups about how "Managed Code" etc. is faster than non-managed code. What's the story? -Michael Viking > At some point, I must have been dreaming, because I swear I've read article > after article in MS publications and on the newsgroups about how "Managed > Code" etc. is faster than non-managed code. What's the story? > > -Michael Viking No disrespect Michael, but you probably were dreaming lol. Seriouly, I myself have come accross some reading in the past the showed C# having comparable performance and in a few rare instances outperforming C/C++ code. I believe (form what was said) that in the cases where C# outperformed C/C++ was due to the ability of the memory manager to allocate memory on the managed heap much faster than the C runtime memory allocator since allocation is *always* contiguous on the mamaged heap. Of course when the managed heap is full the GC does a collection and thats where your performance takes a big hit.IMO, even given the point above, the heap would have to be pretty fragmented and object long lived for this to occur. I attempted to find the links that did the tests, but could find the ones that I read, but here is one http://www.c-sharpcorner.com/Code/2003/Nov/MemoryManagementInNet.asp If you think about it, it should be theoretically impossible for Managed Code with garbage collection to outperform native code, with all other things being equal of course. Some simple pseudo code that should show this Unmanaged code: Think of the following code being native instructions ... while ( ! done ) { doWork( ); } If the Same code were to be JIT-ted it would change slightly (this from reading a bit of the Shared Source CLI specification) while ( ! done ) { doWork( ); pollGC( ); // check to see if a garbage collection is required } The JITter would emmit more code (like those to check the GC above) into the native code, theoretically this should always cause this code to be slower than the previous example. Cordell Lawrence Teleios Systems Ltd. > At some point, I must have been dreaming, because I swear I've read > article > after article in MS publications and on the newsgroups about how "Managed > Code" etc. is faster than non-managed code. What's the story? You may have seen some benchmark testing of .Net vs. Java. .Net is faster than Java. However, no managed app could possibly run faster than a native machine code app. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > <SNIP SNIP> >> code cannot. The most important consideration in such a decision is [quoted text clipped - 8 lines] > > -Michael Viking Well that isn't quite true - with some managed designs (not sure if .Net is one of them) the JIT has the ability take the data stream coming at it into account and compile it accordingly and inlining accordingly - kind of like on the fly profiled optimization. And in 2005 we are seeing a 30% speed increase with the profiled optimization feature (of course that makes it harder for .net to compare favorably). Gordon. >> At some point, I must have been dreaming, because I swear I've read >> article [quoted text clipped - 18 lines] >> >> -Michael Viking Which part isn't quite true? .Net is faster than Java or no managed app could possibly run faster than a native machine code app. I happen to stand by both statements. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Well that isn't quite true - with some managed designs (not sure if .Net > is one of them) the JIT has the ability take the data stream coming at it [quoted text clipped - 29 lines] >>> >>> -Michael Viking It sounds to me like Gordon is suggestion that managed apps could potentially run faster than a native machine app due to the fact that the "manager" could look ahead and feed the code to the processor in the most optimized way. Certainly you can hand optimize assembly code and produce faster code in many cases, so I could see how it -may- be possible for the manger to optimize to the point of not only making up for any overhead, but sometimes actually coming out ahead.. Not that I personally have ever heard anything like that before, but it sounds plausible to me. Cheers > Which part isn't quite true? > [quoted text clipped - 40 lines] >>>> >>>> -Michael Viking Did some reading on this topic, In this paper Fahad Gilani suggests as to the potential of Managed code to outperform statically compiled code with smarter compiler/JITer. Here is an exerpt: "JIT compilation is a remarkable bit of technology that opens the gates for a wide range of optimizations. Despite the fact that the current implementation is restrictive in the number of optimizations that can be performed due to time constraints, in theory it should be able to outperform any static compiler that exists. Of course, this is because dynamic properties of performance-critical code or its context are not fully known or verified until run time. The JIT compiler is able to exploit this gathered information by emitting more efficient code which can, in theory, be re-optimized every time it's run. Currently, the compiler emits machine code only once per method. Once machine code is generated, it executes at raw machine speed. " http://msdn.microsoft.com/msdnmag/issues/04/03/ScientificC/ > It sounds to me like Gordon is suggestion that managed apps could > potentially run faster than a native machine app due to the fact that the [quoted text clipped - 51 lines] > >>>> > >>>> -Michael Viking Maybe in theory, but pretty much everything I've come across that's done in C# (not much) is slow and bloated. It could be these apps are simply not done "correctly", but slow and bloated is what I see, and that's not an admirable quality. Splash screens don't hide this very well (ahah). Signature40th Floor - Software @ http://40th.com/ iPlay : the ultimate audio player for PPCs mp3,mp4,m4a,aac,ogg,flac,wav,play & record parametric eq, xfeed, reverb: all on a ppc > Maybe in theory, but pretty much everything > I've come across that's done in C# (not much) > is slow and bloated. It could be these apps > are simply not done "correctly", but No buts about it. I have written extremely fast code using C#, and am painfully aware of how many so-called programmers are writing horribly bloated code these days, for a variety of reasons, most of which are NOT good ones. I would venture to guess, in fact, that MOST programmers are writing horribly bloated code these days. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Maybe in theory, but pretty much everything > I've come across that's done in C# (not much) [quoted text clipped - 3 lines] > admirable quality. Splash screens don't hide > this very well (ahah). :) I actually agree that most of what is done is C# is actually quite slow, BUT its not because of any inherent qualities of the C# Language or of the .NET Framework (per se, but its implementation does affect performance) ... Rather, most C# applications are slow because people don't understand the implications using particular constructs / patterns / paradigms in a Managed environment as opposed to an "non-managed" environment, and it's because of this naivete (coupled with the fact that the .NET framework is popular and lots of people use it without fully understanding it) that poor performing applications are developed. As for being bloated ... well, I simply don't know how to address that one directly, but previous statement indirectly address this. Again, I reiterate ... right now, (ceteris paribus) static compilers ( + runtimes ) today produce more performant applications than their managed counterparts, but it does help that people write sloppy managed code in the first place ;) Oh BTW, I came accross this interesting project: http://purana.csa.iisc.ernet.in/~kapil/project.htm Cordell Lawrence Teleios System Ltd. > Maybe in theory, but pretty much everything > I've come across that's done in C# (not much) [quoted text clipped - 3 lines] > admirable quality. Splash screens don't hide > this very well (ahah). Very interesting link, BTW.. Thanks :) I would just like to ask if you have any sources or reading material, websites, books, or whatever that would be good for someone who wanted his or her programming to NOT fall into the category you describe below. What do I need to learn, and what are good sources to learn it, to write programs like someone who DOES understand the implications of using given constructs / patterns / paradigms in a managed environment as opposed to a "non-managed" environment. (.NET in particular, of course) Any suggestions or thoughts would be appreciated.... Thanks! - N > :) I actually agree that most of what is done is C# is actually quite > slow, [quoted text clipped - 31 lines] >> admirable quality. Splash screens don't hide >> this very well (ahah). 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 > 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 [quoted text clipped - 65 lines] > > Cordell Lawrence [clawrence@teleios-systems.com] > > Teleios Systems Ltd. [www.teleios-systems.com] Well, 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. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Thanks for the reply Kevin, I agree with you and have said all that you > have [quoted text clipped - 112 lines] >> > Cordell Lawrence [clawrence@teleios-systems.com] >> > Teleios Systems Ltd. [www.teleios-systems.com] 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 You 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 [quoted text clipped - 6 lines] > 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? SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Hey Kevin, I do understand all these things concerning Managed code versus > Native code. Managed code has shown similar performance characteristics to [quoted text clipped - 31 lines] > > Cordell Lawrence Kevin, we are not in disagrement, just appreciate the theoretical point that I'm making here Kevin wrote: >> 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. Cordell wrote: >> I disagree that the fastest application would have to be written in 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: >> 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. 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: >> 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. Cordell wrote: >> 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 ... Again, no disagreement from me ... the two statments are semantically equivalent Cordell > 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. ;-) SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Kevin, we are not in disagrement, just appreciate the theoretical point > that [quoted text clipped - 67 lines] > > Cordell > Thanks for the reply Kevin, I agree with you and have said all that you > have [quoted text clipped - 12 lines] > but I just thought that it would be really interesting to hear what the > community thinks. M-DX was mainly intended for the game tool path. Its nice that its fast enough for some game developers to consider it for their core engine, but that was not necessarily its primary target. so M-DX's existence is not then a proof that all development should be managed. A judicious decision considering all the vectors/requirements for your app is still required. > 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 [quoted text clipped - 95 lines] >> > Cordell Lawrence [clawrence@teleios-systems.com] >> > Teleios Systems Ltd. [www.teleios-systems.com] Thanks for the reply Ralph, I've tried M-DX for some game stuff as well as some other little things and the performance was pretty darn good, but push it a little too much and write sloppy GC-unfriendly code and it begins to crawl. However, it was more than good enough for things like writing code editors and stuff like that. While all these things are interesting ... the questions that I'm looking for answers to are the following How what percent of the Visual Studio 2002+ development environments were written in Managed Code? If not 100%, what are the chief reasons for those parts not being written in managed code? Outside of the performance and legacy problems, what other reasons exist that would influence a Microsoft Development Team, for whatever product, to NOT choose to develop that product in Managed code, since managed code offers greater *verifiablilty*, security, type safety, manageability, and all the other great stuff that developing code on top of the .NET Framework allows? Cordell Lawrence [clawrence@teleios-systems.com] Teleios Systems Ltd. [www.teleios-systems.com] > How what percent of the Visual Studio 2002+ development environments were > written in Managed Code? How? I don't know how. What percent? Well, unless Microsoft made that figure available, for whatever reason, there is no way to tell. I can tell you this much: A lot. check out the CLR. Most of it is in there as classes. That's how Web Matrix was written. > If not 100%, what are the chief reasons for those parts not being written > in > managed code? I believe I went over this in an earlier message. Managed code is high-level code. To get jiggy with it, you need something lower. And believe me, Visual Studio gets jiggy with it a lot! > Outside of the performance and legacy problems, what other reasons exist > that would influence a Microsoft Development Team, for whatever product, [quoted text clipped - 4 lines] > Framework > allows? Requirements. Requirements drive eveything. IOW, if the managed code can fulfill the requirement, managed code is used. If not, unmanaged code is used. You can buy a ready-made house, but unless you build a foundation for it, the house is useless. And you can't buy a ready-made foundation. So, what technology you use depends on what you need to do. Windows, for example, is definitely NOT written in managed code. It is, after all, THE platform (foundation). The processor doesn't understand anything but 1s and 0s. To write a program that talks to the processor, you even have to write some Assembler now and then. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Thanks for the reply Ralph, > [quoted text clipped - 25 lines] > Cordell Lawrence [clawrence@teleios-systems.com] > Teleios Systems Ltd. [www.teleios-systems.com] Okay Kevin, I realize that you arguments are going somewhat in circles, because you keep not answering my questions and going off on the difference in charastics between managed and unmanaged code, which I know enough about. We at the office went looking for some of the answers ourselves and found them, kind of ... First of all, lets deal with this statement: > How? I don't know how. What percent? Well, unless Microsoft made that figure > available, for whatever reason, there is no way to tell. I can tell you this > much: A lot. check out the CLR. Most of it is in there as classes. That's > how Web Matrix was written. Yeah I know ... that "How" was a typo ... I'm imbarassed about that ... I know that alot of it is written in managed code ... The CLR, I don't think that that one quite applicable to this arguement ... but WebMatrix on the other had definitely is and is more in the line of what I'm talking about, but WebMatrix is free. To re-emphasise my original post that started this whole thing, MS isn't betting the company's investments or really making a ststement about it's confidence in the CLR by building a free WebMatrix tool on the .NET Platform. Next lets deal with this: > Requirements. Requirements drive eveything. IOW, if the managed code can > fulfill the requirement, managed code is used. If not, unmanaged code is > used. Well buddy, there are three "types" of code that can be produced by the C# compiler: 1. Verifiable and Managed code 2. Non-verifiable and Managed code 3. Non-verifiable and Unmanaged code Check out Don Box's post on this at http://pluralsight.com/blogs/dbox/archive/2005/02/06/5596.aspx Don points out that in Indigo's 1123 C# files 19 used the unsafe keyword to do low level stuff . In fact here is the last part of the post >> In systems programming, it's occasionally necessary to do low-level buffer manipulation, especially in I/O code. >> In looking at the Indigo code base (which was 1123 C# files as of early last week), only 19 of them use the unsafe keyword. >> Every single use was to do buffer manipulation, either for low-level XML cracking, SSPI munging, or async I/O buffer management. >> Could we have written those pieces in unmanaged C or C++? >> [quoted text clipped - 3 lines] >> >> First, the code was written in the same language the rest of the DLL was written in, meaning that it's less of a cognitive mode >> switch for a dev to deal with when they go spelunking (or debugging). >> >> Secondly, there is no "transition" for the runtime to go through when executing the code. ... [READ THE BLOG FOR THE REST ... which BTW is great info] ---> Important point coming up ... * So there are options available other than going to strictly unmanaged code. (BTW #2 'type' of managed code helps with the GetPixel() example in your first reply to my initial post) > You can buy a ready-made house, but unless you build a foundation for it, > the house is useless. And you can't buy a ready-made foundation. So, what [quoted text clipped - 3 lines] > write a program that talks to the processor, you even have to write some > Assembler now and then. Yes yes ... but what were those things?? I am not for one single moment saying that everything HAS to be or even should be done in managed code, I am simply asking why did they choose not to do it in managed code? ... saying that managed code isn't applicable to every problem is a half answer. As for the latter part of you last argument, if I were to step in to the theoretical here for a moment, a machine should need only two components and everything else could be done in managed code, 1. a boot strapper 2. a JIT-ter after that, even the CLR could be managed and JIT-ted to native code then applications run on top of that. Finally someone else asked the quesion I did in this post already. Read about it here: http://www.codesta.com/knowledge/technical/csharp_clr/page_05.aspx " Microsoft is writing much of Longhorn in "managed code" atop the company's .NET framework ..." http://www.pcmag.com/article2/0,1759,1631379,00.asp There are other sites, Google "Longhorn" and "Managed code" to find content about managed code in the operating system, and sometimes projects and products built on managed code are mentioned. Cordell Lawrence Teleios Systems Ltd. It seems to me that you are either 1. Simply arugmentative, or 2. Simply don't understand my answer The blog you mentioned said one thing that you didn't mention, and that was why managed code is used - Productivity. IOW, what I said was entirely true, although you certainly didn't seem to hear it: Requirements drive everything. Productivity is a requirement as well. And regardless of how many different combinations of types of code you're talking about, it all boils down to one thing: requirements. A good developer understands all of the requirements, and builds his plan accordingly. A good developer isn't concerned about whether he's using "managed code" or not. He's concerned about fulfilling his requirements in the most efficient way possible, and that includes what level of programming he works at for individual pieces of the puzzle. The .Net platform was first released about 3 or 4 years ago. If you're still trying to determine whether it's a salient programming platform or not, you're way behind. It is nearly as ubiquitous now as Java. As to Web Matrix - It's a scaled-down version of Visual Studio.Net. Microsoft would no more re-invent the wheel than any good developer would. The very same components are used in both software packages. Visual Studio.Net simply has more components. SignatureHTH, Kevin Spencer Microsoft MVP .Net Developer What You Seek Is What You Get. > Okay Kevin, I realize that you arguments are going somewhat in circles, > because you keep not answering my questions and going off on the [quoted text clipped - 111 lines] > Cordell Lawrence > Teleios Systems Ltd. I guess I forgot to say this in my last post, so I'll put it up here. I mentioned that WebMatrix is the kind of project that I'm talking about, because these types of projects lend themselves very nicely to the .NET/ RAD / High level (as kevin put it), types of problems, so it just seems natural that alot if not all of it (like WebMatrix & Casini, SvcUtil in Indigo, .NET Terrarrium?, MS FXCop 1.3 and so on and so on) would be written in Managed code. When all is said and done I "believe" that MS is committed to the .NET Platform, I love the platform and think that it is the best runtime, development tools and support mix that I've ever worked on and I'm confident about building my stuff on this platform. Cordell Lawrence Teleios Systems Ltd. This is the best representation of the spirit of our discussion in the office as it relates to the Microsoft .NET Framework and questions about their commitment to it. Essentially another instance of the question I asked on this thread >> So what application has Microsoft written totally in .NET that is worth a [expletive]? >> Visual Studio - NO, Office - NO, Notepad - NO, Calc - NO. >> Why haven't they? ..... Dan Fernandez responds to the above excerpt http://blogs.msdn.com/danielfe/archive/2004/11/02/251254.aspx Rihard Grimes's farewell to .NET http://www.ddj.com/documents/s=9211/ddj050201dnn/ IMHO, the tone of this article is more of a tantrum but still a well thought out argument and contains essentially the spirit of our discussion in the office, the least the 'con' side of the argument. Dan Fernandez' reply to Richard Grimes's article http://blogs.msdn.com/danielfe/archive/2005/02/22/378343.aspx In the comments section, Mr. Grimes's relpy to Dan's rebuttal is more sober and articulate than the initial article. Again, this thread / discussion is and goes beyond the spirit and content of our office discussion. Thanks all, Cordell Lawrence [clawrence@teleios-systems.com] Teleios Systems Ltd [www.teleios-systems.com] Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.