|
Well, there's nothing to stop people maintaining and adding new functionality to their existing code. MS's decision just means that there will be no more bug fixes or new unmanaged functionality for VB developers. But they can enhance their existing apps. and still have them run under Longhorn. Or they can write new bits in the new languages and have them interoperate with existing functionality. That's what they're doing at the company I've just left.
Kevin
|
|
|
|
|
Because Basic programmers need an option to write unmanaged (native) apps. C#ers knew they'd be stuck with .NET and managed stuff when they took up C#. But VBers and C++ers are used to native development, when .NET was thrust upon them without their permission. MS didn't take away unmanaged abilities from C++, they added .NET features through a specific compiler option (/clr).
I feel VB 7 should be something like that. By default VB7 should be the updated unmanaged version of VB6 and there should be a /clr compiler switch which will convert the VB compiler into a VB.NET compiler. Due to the nature of the classic VB language, VB and VB.NET obviously won't coexist in the same assembly (no C++ style mixed mode stuff), but that shouldnt be a prob.
Regards
Nish
|
|
|
|
|
Most VBers are used to the need of a runtime to run their programs. Most of them really don't care if their code is managed or unmanaged and don't know the difference between generational garbage collection to reference counting. What is really annoying to them is that the new language is incompatible with the old one. And there's ADO.
IMHO, the migration tool does a good work and puts you 95% there. The major problem is with ADO. If someone ports ADO classic for .NET (you see, I'm not saying ADO.NET), most of VBers would settle down. I know they can use interop to call ADO, but it's half a truth. The .NET GC (in 1.1) isn't capable of adding memory pressure to pointers, so ADO connections and recordsets live for a long time in .NET world, compared to VB6. While some say you can use interop, in practice this is unusable, as the memory use and the number of connections grow very quickly.
Solving that, only those who have code that is too messy or uncapable of (un)learning a couple of keywords would complain. To these, VB6 is still a good solution.
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
|
Daniel Turini wrote:
only those who have code that is too messy or uncapable of (un)learning a couple of keywords would complain.
Or, as Nishant already stated, those who want to compile to native code using the same language they've been compiling to native code in for years.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
But what I don't understand is - what is the difference between compiling to native but requiring the VB6 runtime to compiling to managed code?
I mean, I totally understand the technical differences - but why would this pose a problem to VB developers?
Honestly, last year I worked on porting an old VB6 app to VB.NET. I had to do a complete redesign since it was so ugly and non-object oriented. The new VB.NET object oriented solution is so much cleaner and easier to maintain that it seems like the VB6 version is just shabby.
Now honestly, why don't VB developers want to improve their skills to take advantage of the bleeding edge such as object oriented programming, aspect oriented programming and such? Just seems weird to me - especially with how much simpler it will make their lives in the long run.
|
|
|
|
|
aerospaceboy wrote:
Now honestly, why don't VB developers want to improve their skills to take advantage of the bleeding edge such as object oriented programming, aspect oriented programming and such? Just seems weird to me - especially with how much simpler it will make their lives in the long run.
Why because 90% can't.
My Blog ^
|
|
|
|
|
norm.net wrote:
Why because 90% can't.
I would like to believe this, but I see so many MVPs trying to get MS to continue support/development of VB6 that I just can't. These were people that I always considered to be reasonably competent thinkers in VB6.
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
My Blog[^]
|
|
|
|
|
aerospaceboy wrote:
But what I don't understand is - what is the difference between compiling to native but requiring the VB6 runtime to compiling to managed code?
VB6 native code or P-code can't be decompiled, it can only be disassembled (like unmanaged C++.)
Also, it doesn't have to be JITted.
Even $1200+ obfuscation tools can't even come close to the level of code/IP security that is achieved by the simple expedient of compiling to native code.
And correct me if I'm wrong, but doesn't MFC C++ code require a run-time library, too? So to extend your argument, why would anybody still want to write MFC-based C++ code instead of just using managed C++?
Grim (aka Toby) MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
GO
(0 row(s) affected)
|
|
|
|
|
Hello,
Wasn't it the managed part of VB6 that made it so popular? I'm not a VB6 programmer, but I think that I've read something about that a while ago.
I also got the blogging virus..[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
