VB6 is DEAD!

[Shaggy Hiker]

That's my entire point here - to sharpen the recognition of what MS *continues* doing.
The *functionality* .NET provides is great - I ruled it out for other reasons.

I'm not convinced that you did. On the other hand, I'm also not convinced that humans are intelligent, so I will just live with the doubt.

On *only* the tech-side these are:
- the necessary "blob"-deployment (instead of only choosing the COMponents your App needs).
(the little "Mandelbrot-competition" we had, showed quite clearly what I mean... the .NET
implementation was developed against version 2.0 of the framework, to offer roughly the
same "reach" as the VB6-counterpart - many customers still use XP).

That wasn't a good reason to target 2.0 of the framework. XP got 3.5 as an update, just as it got 2.0, except that 2.0 was a mandatory update while 3.5 was not. A better reason to target 2.0 was....why not? 3.5 offered many significant changes, but not ones that woul win speed races. The biggest additions were LINQ and lambdas, which make for VASTLY shorter code, but are slower than the old-fashioned methods. However, had you targeted 4.0 or 4.5, then you'd have the Task parallel library, which is lighter than any threading available to VB6. The Task parallel library arose from the recognition that multi-threading is going to become increasingly important as CPU advances are in core numbers and multi-thread support rather than in clock speed. The 4.0 Task parallel library is pretty complete, while 4.5 adds a couple convenient features.

- the Garbage-Collector (it's really not that easy, to reliably wrap flat C-libs behind
.NET-classes, when the *order* of potentially necessary C-Handle-freeing becomes important)

- the potential of the GC, to "kick in" at unpleasant times

You see this? In what way? In all these years, I've never seen any impact of the GC on anything.

- the MSIL not being "true native code" (the "getting hot"-time for the Jitter I've already mentioned -
but in addition, there *is* a better protection of "Intellectual Property" with native compiled code)

But that's not true. There isn't ANY protection for intellectual property in either type of code for the desktop other than obfuscation. The thing that protects people is that it's almost always easier to write the program yourself than to crack some other code. When that's not the case, the code is cracked and cracked quickly, it doesn't matter whether it is proprietary or not. The economics of software is that it can be sold because it is cheaper in time and money to pay somebody else for their work than it is to do it yourself. Moti Barski covered this in the final chapter of his book on Battle Programming (though in an inverted fashion). You aren't protected by native code. You are protected by the cost of writing vs the cost of cracking vs the cost of purchase. The rest is all a mirage.

Note, that I left out "general performance" - because that's roughly equal (as soon as the MSIL
was jitted) to the VC6-compiler which works underneath the VB6-native-compile-option...

So, since the .NET native group has stated repeatedly that they will be doing .NET native for the desktop, which removes both the JIT cost, the startup cost, and the (invalid) concern over native code, what will that do to your position?