Desktop deployment environment

Read a great quote the other day, the irony made me smile for ages.

“Initially we thought we’d be using Java, but we ended up not using it because we concluded that there would never be a stable runtime environment that we could count on on all desktop PCs.” Ray Ozzie, Microsoft Chief Software Architect, ex CEO of Groove, talking about why Groove was written in C++. (Founders at Work, Livingston 2007).

My biggest complaint about .net? same thing – it just can’t be relied on to be there in the right version. Maybe thats going to change going forward??

Or maybe we will just start targeting servers and have thin-client browser apps?

cheers

Simon

Advertisements

10 Responses to “Desktop deployment environment”

  1. Marcus Says:

    I think Marc Andreessen made that prediction (albeit with Scott McNeely’s hand up his back) some years ago. I think it was in the Pirates of Silicon Valley.

    Are we really any closer now than then?

    It also appears to be a contributing factor as to why Excel/VBA development is so prevalent – because we know it’s there.

    Cheers – Marcus

  2. Stephane Rodriguez Says:

    Marcus said “It also appears to be a contributing factor as to why Excel/VBA development is so prevalent – because we know it’s there.”

    I don’t entirely agree with this. Whenever you write a line of code of Excel/VBA, you are assuming :

    1) your code will run the same on someone else’s machine
    2) the inputs and outputs will be the same regardless the Excel version, Excel language, user locale and Windows version.

    In reality, this cannot be further from the truth, as Excel internals have changed with every single release. Not only that, but even with service packs hot fixes that changed behaviors, regressions, …

    What’s problematic with .NET is that 1) and 2) are way harder to achieve. One of the reasons being that when you are working with .NET in a native environment :

    a) you have to worry about native problems (native deployment, dll hell, …) AND .NET problems. Not just .NET problems.

    b) you often code and test while being alone (sole add-in loaded), even though customer environments have all kinds of add-ins loaded, which you can’t predict or test. Now consider that some of those other add-ins also load the .NET run-time, and you have a perfect recipe for disaster.

  3. Ross Says:

    >>Now consider that some of those other add-ins also load the .NET run-time, and you have a perfect recipe for disaster.

    So is that not why you should isolate them? One of the nice things about.Net is App domians etc I thought this would/was designed to some extent, to get around this type of problem. – I.e, on a sever, when app 1 charshes, i can close it’s app domian, and i dont have to reboot the whole server? Maybe this don’t work quite right in the real world?

    What does this all mean, C++ is the only real way to go?

  4. Stephane Rodriguez Says:

    “So is that not why you should isolate them?”

    That’s Microsoft marketing brochure. Here is some reality check :

    – when more than one .NET add-in is loaded, the first one decides for others which version of the .NET runtime is loaded. Remember : the .NET CLR is a dll and hence gets loaded in-process : all add-ins share the same CLR. Well, I’ll leave it as an exercise what kinds of problems you have when you need to worry about who gets loaded first. Sounds strikingly similar to the dll hell problem of the native world…
    – the app domains do not allow add-ins to intercommunicate. Kind of a problem…
    – the app domain model is so bad that 1) Microsoft is rewriting it in next .NET version codenamed “Orcas”. I think (correct me if I am wrong) it’s about the only “new” .NET CLR feature since .NET 2.0. When the dust starts to settle with VSTO deployment hell, how timely for a major .NET CLR change… 2) Microsoft has never quite managed to bootstrap .NET in a mixed environment properly. Just take a look at their record history of .NET loaders (each new VSTO version comes with a different loader!)

    Well, you get the idea.

    “What does this all mean, C++ is the only real way to go?”

    I don’t mean to imply “only”. I meant to imply .NET is just not the right execution model for mixed environments. Take the fact that Windows Vista is fully written in C/C++ the best backer.

  5. Dennis Wallentin Says:

    Stephane et al,

    The largest news with .NET Framework 3.5 is LINQ. As far as I understand .NET Framework 3.5 use the same CLR as for .NET Framework 3.0 (version 2.0 of CLR with “red fixes”).

    As long as VSTO runtime is not part of Windows it will be an issue.

    Windows Vista is shipped with .NET Framework 3.0 and I assume it will be updated when the final version of 3.5 is released. During the transition time the CLR may be an issue however when Vista is the de facto platform in use it will no longer be a problem.

    Kind regards,
    Dennis

  6. Stephane Rodriguez Says:

    Dennis,

    I am afraid that solves none of the mixed environment issue. Remember it’s Excel which should be written in .NET for the mixed environment issue to go away.

    (PS : LINQ is not a CLR change. It’s a compiler change, plus a simple OR/M layer. The underlying CLR objects remains statically typed.)

  7. Simon Says:

    I’m with Marcus:
    The .xls framework is more prevelant and more consistent than the .net one.

    Personally I think native win 32 is the way to go at the moment for widely distributed stuff, the alternative is real deploment challenges trying to play catch up with framework versions. And while you are at it I’d go for an ISO standard language (C/C++). .net is fine for server stuff and low number deployments, maybe the landscape will be different in 5 years.

    Or maybe distribute full VMs as Stephane previously suggested.

  8. Stephane Rodriguez Says:

    Speaking of .NET, look how Microsoft violate their own rules :

    “While installing VisualStudio 2008 Beta2 I was surprised that the NET framework 2.0 installation got automatically updated. My good old copies of mscorlib.dll v2.0.50727.42 and friends got updated to v2.0.50727.1378. (…)”

    http://codebetter.com/blogs/patricksmacchia/archive/2007/08/08/new-net-3-5-core-stuff.aspx

    MeThought side by side meant oldies are left untouched.

    I must have missed something obvious…

  9. Ross Says:

    Intresting insight Stephane, I didn’t know that’s how it worked – amazing really that it should be that,… well crap!

  10. Stephane Rodriguez Says:

    Some more .NET deployment fun.

    http://www.codeproject.com/lounge.asp?msg=2197336#xx2197336xx

    Clearly, expecting what works on your machine to work on somebody else’s machine is more a dream than a reality. With .NET

    I don’t know who on this blog used the expression “controlled environment”, but that’s I guess a better way to go if you don’t want to shoot yourself in the foot. Now, who can afford that? Especially micro-ISVs?

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: