Linkers and servicing

Here's a question for you.

Let's say Microsoft did a linker for .NET.

Let's also say the very, very unlikely event happens and there is a bug in the version of .NET that you linked into your application.

Finally, let's say that Microsoft ships a fix for the aforementioned bug.

Will your app get the update?  Would you want it to?  Would you want it not to?

I think the answer to the first question is "no, there is no technically feasible way to make this work" and the second two get "it depends."  The only way I can think to make it work is that Joel (and everybody else) has to get the fix, recompile their apps, and redeploy it at all the customer sites.  Microsoft used to do this model.  And whatever you say about today's model, I think it certainly true that the previous one was worse.

as to wanting the bug, I think you'd certainly want it if it was a critical security update, but you wouldn't want it if it was a "feature" that your app didn't need or want.  How do you tell? Who owns the deciding the gray areas?  What if fix introduces a regression in Joel's app?  Is he going to tell his customers to not accept the fix?  how does the customers make the tradeoffs...and so on.

anon
Thursday, January 29, 2004

How about an intelligent statically-linked runtime?

A runtime that, in the abscense of any .net installation, ran from the exe; however, in the presence of a fuller .NET installation, borrowed libs from there?

Of course, if MS continues to pay scant regard for binary compatibility (as Joel hinted with the version hell), then what do you expect?

On a sidenote, BC is something that programmers generally don't know about.  But there is no excuse for people making APIs not to understand!

i like i
Thursday, January 29, 2004

  Recent Topics

  Fog Creek Home