Windows and Office will be written in native code forever

I'm sure you're all aware of the complexities involved in writing and shipping native code. It in general is much harder than managed code, principally because computer memory must be managed by the developer, but the language itself is very difficult as well.

Microsoft Windows and Microsoft Office are released every 3 -5 years, and this is no guarantee that business or users will upgrade their previous version (as Vista and Office 2007 prove). It now is more of a case where "I'll use my current machine" until that is "on-its-last-legs", then buy a new one with a new OS or Office license. This inherently means that the rapid development that managed code offers, is not necessarily an advantage for these products. If you could ship a new OS every 2 years would you?

There have been exciting things like Midori or the Singularity project recently, but they failed to recognise the fact that business and users aren't and won't upgrade willy-nilly, so the turnaround for application development is neither here-nor-there. The other overwhelming aspect is cost. It takes many more developers to develop native code applications (much more), but if you have something like office, you can reduce the staff - look, I know its still a huge engineering project- and release the product every 4 or 5 years.

This is in complete contrast to line of business application and website development, where you want to complete the product at the soonest available opportunity. Having the .NET framework seems a worthwhile trade off for the rapid and bug freer software you get.

Would you say that this is a fair assessment, or is my reasoning misjudged?

I think you are right, at least in the next 10 years they won't change to much.

When you listen to Mark Russinovich in his last interview a few days ago (link) you get the answer. Even Microsoft don't know what's going on inside the system. It is just to complex. But after that it will change rapidly I think. There is a extreme desire for correct program code and people will even trade performance to get closer.

The question about the time between releases is a very old one. Today no one has a good answer to that. Take a look at OpenOffice, it is free (yes I mean like in free beer) but there are so many people out there that still use version 1.x or 2.x.

just my 2 (euro-)cent

littleguru said:

Horst0815 said:

*snip*

I wouldn't say that... I mean I don't know anything about the future of Windows but it seems to me that managed code has benefits in time to market. There are probably still some issues that need to be solved to make more parts of Windows managed. But in general it might (must) be in the intention of Microsoft to switch more into the managed world. Imagine how much more features and stuff could be done simply because development takes less time.

I'm not sure... The average users may not even be able notice the advantage bring by managed code.

When was the last time you seen BSOD/system crash in WinXP or Vista that's caused by poorly-written application? I haven't for at least 4 years. Besides, how many daily applications average users use are written in managed code?

I doubt that all the users would see is just slower overall performance.

Maybe it'd be more benefitial to just develop the managed OS as a server-class OS, because we're all for High-Availablity for server systems. Moreover, except drivers, antivirus and web applications your company developed, how many software you run on Windows server are not from Microsoft?

cheong said:

littleguru said:

*snip*

I'm not sure... The average users may not even be able notice the advantage bring by managed code.

When was the last time you seen BSOD/system crash in WinXP or Vista that's caused by poorly-written application? I haven't for at least 4 years. Besides, how many daily applications average users use are written in managed code?

I doubt that all the users would see is just slower overall performance.

Maybe it'd be more benefitial to just develop the managed OS as a server-class OS, because we're all for High-Availablity for server systems. Moreover, except drivers, antivirus and web applications your company developed, how many software you run on Windows server are not from Microsoft?

Don't bet on it. One of the biggest announcements about .NET 4.0 (which has gone largely unoticed AFAICT) is the you will be able to have in-process side-by-side versions of the CLR. This removes one of the biggest hurdles to mixing a native code base (particularly a very extensible one) and managed code.

Shell namespace extensions, Office plugins and IE add-ons could now easily be developed in managed code, without being guaranteed to be a breaking issue should Explorer, Office or IE ever move to or take advantage of managed code. This has always been one of the major stumbling blocks (especially for Explorer) and certainly hints at the possiblity of a more managed code future.

Surely pluggins could manifest to say exactly 'what' environment they want to run in, and the host process will spawn environments as needed in separate processes?

Time will come when the balance of keeping clr compat and pushing for more changes will make it that a new clr version won't run alone side of the previous.. I'm guessing that clr 4 can only offer side by side because its very similar to clr 2, whereas clr 2 was drastically different to clr1.x?

AndyC said:

cheong said:

*snip*

Don't bet on it. One of the biggest announcements about .NET 4.0 (which has gone largely unoticed AFAICT) is the you will be able to have in-process side-by-side versions of the CLR. This removes one of the biggest hurdles to mixing a native code base (particularly a very extensible one) and managed code.

Shell namespace extensions, Office plugins and IE add-ons could now easily be developed in managed code, without being guaranteed to be a breaking issue should Explorer, Office or IE ever move to or take advantage of managed code. This has always been one of the major stumbling blocks (especially for Explorer) and certainly hints at the possiblity of a more managed code future.

Side by side CLR versions? This is fantastic news for the Shell Extension front! Can you point me to a press release/PDC presentation about it?

I can't agree with several things in your premis.  First, managed languages aren't inherantly easier than unmanaged languages.  You'll have to talk specifics to make a claim like that (for instance, I won't argue that C# is easier than C++, but it's not really any easier than D or Eiffel).  Not all unmanaged languages require you to do memory management.  Heck, even in C/C++ there's garbage collectors you can use, and in C++ they actually plan on adding GC to the language spec.

Linux ships new OSes every quarter, basically, and that's with most of the code written in C/C++.  Different model, yes, but the point is that the time frame of releases isn't all that relevant.  I work on commercial applications written mostly in C/C++ that ship new versions quarterly.  Not all users are "wait until I can't wait any longer" types.  In fact, I'd say the majority still aren't in this camp, though I'm guessing as much as you are.

Midori and Singularity haven't proven anything, other than you can use managed code in interesting places.  Users aren't switching for many reasons, but none of them have anything to do with users not wanting to "upgrade".  It's more along the lines of costs vs. benefits analysis (the user's current investment in applications that won't run on Singularity, for instance, prevent them from doing more than checking it out).  Also note that these are research projects and not commercial offerings.  With out marketing, MOST users don't even know they have the option to switch, and haven't made the cost/benefit analysis.

Yggdrasil said:

AndyC said:

*snip*

Side by side CLR versions? This is fantastic news for the Shell Extension front! Can you point me to a press release/PDC presentation about it?

It is indeed a world of awesomeness. Jason Zander blogged about it here.

wkempf said:

I can't agree with several things in your premis.  First, managed languages aren't inherantly easier than unmanaged languages.  You'll have to talk specifics to make a claim like that (for instance, I won't argue that C# is easier than C++, but it's not really any easier than D or Eiffel).  Not all unmanaged languages require you to do memory management.  Heck, even in C/C++ there's garbage collectors you can use, and in C++ they actually plan on adding GC to the language spec.

Linux ships new OSes every quarter, basically, and that's with most of the code written in C/C++.  Different model, yes, but the point is that the time frame of releases isn't all that relevant.  I work on commercial applications written mostly in C/C++ that ship new versions quarterly.  Not all users are "wait until I can't wait any longer" types.  In fact, I'd say the majority still aren't in this camp, though I'm guessing as much as you are.

Midori and Singularity haven't proven anything, other than you can use managed code in interesting places.  Users aren't switching for many reasons, but none of them have anything to do with users not wanting to "upgrade".  It's more along the lines of costs vs. benefits analysis (the user's current investment in applications that won't run on Singularity, for instance, prevent them from doing more than checking it out).  Also note that these are research projects and not commercial offerings.  With out marketing, MOST users don't even know they have the option to switch, and haven't made the cost/benefit analysis.

OK, my premise is this.

I have a just grabbed a copy of Practical Visual C++ 6 from my bookshelf. Were I to use this to create the commercial applications I've written, I still would not have finished the first one. I am a qualified native C++ developer by the way, but self taught managed C#.  I find .NET much much easier, and not having to deal with pointers, stack overflows and buffer overruns for me at least, makes C# "a walk in the park", compared with native C++. The IDE is much cleaner, re-factoring and a standardised framework, makes it lovely to work with. I have the utmost respect for native developers and think they can be hoity-toity towards managed developers, because native coding is harder. Why to you think managed code has taken off the way it has - because it's just as hard as unmanaged?

D and Eiffel would be easier to deal with if they had a rich IDE like VS and the resources put into it that the base class library has. Another flaw in your argument, is comparing domain specific languages with general purpose programming languages like C++ and C#. Designing programs by contract well in general is done by people with some experience of programming, Spec# being the latest offering from Microsoft. A quick look at D has things like tuples (funtional programming) and Eiffel has a lot of features that leave academics salivating. This is all well and good, but not as productive as a general purporse programming language like C#.NET.

Everything about .NET is based around productivity. I know of no single ISV developers, that have completed n-tier, multi user applications, with a sproc data access layer, utilising web services. It is possible to do this with native C++, Eiffel or D, but it takes longer, and there is a wider scope for bugs. The trade off is performance, and having a bulky runtime beneath.

For a business with 500 users, a quarterly upgrade as you suggest with Linux is expensive and impracticable, unless there is an overwhelming reason to do as such. Microsoft have just spent $300 million on marketing Vista, can you imagine them launching a new campaign every 13 weeks? You find that reasoning agreeable?

vesuvius said:

wkempf said:

*snip*

OK, my premise is this.

I have a just grabbed a copy of Practical Visual C++ 6 from my bookshelf. Were I to use this to create the commercial applications I've written, I still would not have finished the first one. I am a qualified native C++ developer by the way, but self taught managed C#.  I find .NET much much easier, and not having to deal with pointers, stack overflows and buffer overruns for me at least, makes C# "a walk in the park", compared with native C++. The IDE is much cleaner, re-factoring and a standardised framework, makes it lovely to work with. I have the utmost respect for native developers and think they can be hoity-toity towards managed developers, because native coding is harder. Why to you think managed code has taken off the way it has - because it's just as hard as unmanaged?

D and Eiffel would be easier to deal with if they had a rich IDE like VS and the resources put into it that the base class library has. Another flaw in your argument, is comparing domain specific languages with general purpose programming languages like C++ and C#. Designing programs by contract well in general is done by people with some experience of programming, Spec# being the latest offering from Microsoft. A quick look at D has things like tuples (funtional programming) and Eiffel has a lot of features that leave academics salivating. This is all well and good, but not as productive as a general purporse programming language like C#.NET.

Everything about .NET is based around productivity. I know of no single ISV developers, that have completed n-tier, multi user applications, with a sproc data access layer, utilising web services. It is possible to do this with native C++, Eiffel or D, but it takes longer, and there is a wider scope for bugs. The trade off is performance, and having a bulky runtime beneath.

For a business with 500 users, a quarterly upgrade as you suggest with Linux is expensive and impracticable, unless there is an overwhelming reason to do as such. Microsoft have just spent $300 million on marketing Vista, can you imagine them launching a new campaign every 13 weeks? You find that reasoning agreeable?

Wow!  Where to begin.  You're confusing soooo many topics, it's hard to straighten out my response.

You're original post was about languages, not tools.  Bringing in IDEs and other tools just confuses the topic at hand.

You're also talking about things in the abstract, but it seems you really want to talk more concrete.  C# vs C++ is a wholly different topic from managed (you really mean .NET) and unmanaged (you really mean not .NET).

D and Eiffel are general purpose languages.  Having DbC in the language doesn't change this (what niche would DbC force the language into?).  Uh oh... D has functional language features, so it must not be general purpose!  That ignores the fact that C#, which you claim to be general purpose, is nearly as functional as D is (especially in the latest versions, with all the LINQ features).  I'm willing to bet these languages are every bit as "productive" as C#.  I'm betting that based on my experience with them.  Do you have any experience with them, or research to back up this wild claim?

There's NOTHING technical that's inherantly different about C# or other .NET languages that makes development for ISVs simpler or more productive.  There ARE several non-technical differences that make C# and .NET appealing (tools, community and existing libraries, for instance).  There's NOTHING, however, that makes it impossible or even difficult to have these same things exist in the native world.

AndyC said:

Yggdrasil said:

*snip*

It is indeed a world of awesomeness. Jason Zander blogged about it here.

Oo, thats really interesting actually since it sounds like they truely have worked to get the clrs running together regardless of their simularitys in clr2 and 4..

Ion Todirel said:

wkempf said:

*snip*

It's not just the language itself (with just the language you can't do anything), the libraries that comes with it has a huge impact on how/what can you do with it, also it's popularity is also important because it's most likely you'll find very easily answers to your problems in that case. Now are you saying that D/Eiffel has better base classes than C#/.NET? Regarding the whole managed vs. unmanaged thing, don't forget about security, interoperability and other stuff it makes more easier to do.

Libraries are only relevant when you get into specifics, which we haven't done.  The closest to specific that we came was in discussing OS development... and at that level, libraries don't mean a whole lot. More importantly, I never claimed that libraries and/or popularity weren't important considerations, only that they were non-technical considerations that were also unrelated to the managed/unmanaged premise.  C++ has as much of a community (popularity) as C#, and has a ton of libraries available (not that some niches aren't lacking... for instance C++ has limited libraries, if any, that address web development needs).  Not that I'm claiming C++ to be better than C#... for those kind of arguments you have to get into specifics, which we aren't doing.

D/Eiffel both have very extensive libraries.  C# probably has more (especially when you consider 3rd party libraries) than either of them, but that will only matter when you talk specifics.  Java probably has more than .NET, so does that make Java better?  And "better" is subjective and always depends on specific criteria.  I will say that in some cases I find libraries from other languages to be "better" than those in .NET, sometimes due to language features making things easier to express, and other times for other reasons.  .NET doesn't have a monopoly on library design.

I'm not forgetting about security, interoperability and "other stuff".  Those concepts aren't non-existent in managed languages.  You'll have to get into specifics before we can get into meaningful arguments.

I believe we could move to Singularity today provided there is similar technology to vmware that allows to run OS X apps in Vista almost as if you were using a Mac. (not that this is supported by vmware and barely works but it could work fine if optimized)

In that case you'd just have a fully managed shell,os then use hypervisor to run the legacy code and window manager to integrate the legacy windows into the managed shell.


Why I think this hasn't been done yet is that there's still a lot to do before Singularity could act as full fledged OS - so far it's focus has been in areas of research, there would need to be some years of API development to make it a serious contender for developing compared to what's currently available on Windows. And from what's seen so far Singularity research hasn't even touched many OS development areas that could use more improvement than just porting over existing functionality. Then there's that thing where you don't have much people who know about developing for entirely new system so it's unclear where those would come from if this effort took many years and MS was expected to release new legacy-OS at regular intervals.

wkempf said:

vesuvius said:

*snip*

Wow!  Where to begin.  You're confusing soooo many topics, it's hard to straighten out my response.

You're original post was about languages, not tools.  Bringing in IDEs and other tools just confuses the topic at hand.

You're also talking about things in the abstract, but it seems you really want to talk more concrete.  C# vs C++ is a wholly different topic from managed (you really mean .NET) and unmanaged (you really mean not .NET).

D and Eiffel are general purpose languages.  Having DbC in the language doesn't change this (what niche would DbC force the language into?).  Uh oh... D has functional language features, so it must not be general purpose!  That ignores the fact that C#, which you claim to be general purpose, is nearly as functional as D is (especially in the latest versions, with all the LINQ features).  I'm willing to bet these languages are every bit as "productive" as C#.  I'm betting that based on my experience with them.  Do you have any experience with them, or research to back up this wild claim?

There's NOTHING technical that's inherantly different about C# or other .NET languages that makes development for ISVs simpler or more productive.  There ARE several non-technical differences that make C# and .NET appealing (tools, community and existing libraries, for instance).  There's NOTHING, however, that makes it impossible or even difficult to have these same things exist in the native world.

I have to agree with wkempf here.  vesuvius, I really don't understand what your trying to say here.