|
Davy Mitchell wrote:
Just think of a huge codebase that would need migrated, tested - even then you are introducing risk only to 'stand still' in functionality. Many small shops will struggle or fold over this.
But this is only a problem if you think that you HAVE to convert.
If what you have written in VB6 works then keep it there. Start converting as needed when you want to expand. This is what 'the next version' is part of in product development.
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[^]
|
|
|
|
|
Actually, the problem will eventually arise when someone wants to use their VB6 app on a future OS (which Longhorn+?) that won't support it. It will also become a problem to support VB6 apps when you must keep a separate system at hand simply to be able to maintain the app.
I'm quite ambivalent on this issue. While .Net and the Framework brings a lot of great stuff to the developer, the success of VB was its low entry level threshold. AFAICT, the ease of entry into the development is gone. Sure, it allowed a lot of non-developers to develop a lot of lousy code, but it also allowed people with expertise in other fields to implement applications that did a decent job of providing solutions within those fields.
It isn't usually the most elegant implementation that is the "best" or most successful application. I have seen some apps that I wouldn't touch with a ten foot pole be successful, and some that filled me with awe fail. Over 30 years, I have seen and worked with many languages, and I'll use whatever gets the job done the fastest. In that respect, VB6 has been great. The .Net languages carry a lot of promise, but the complexity is moving from the application development to the tool. I remember when C/C++ developers gasped over the 800 or so API's in Windows (that was way back). The .Net framework is multiple magnitudes "bigger".
"Managed Code" is only a big deal because C[++] on DOS and Windows was basically the Wild Wild West. Managed Code was common back in the 60's. Algol, Simula, and Pascal implementations were both "managed" and typesafe. Even Fortran was somewhat managed - but not typesafe. VB Classic was somewhat managed and "type-flexible" (it would bend over backwards to perform implicit conversions, but it wouldn't allow incompatible data). I like "managed code" - because that means that I don't have to "manage" something (i.e. memory allocation). But there should never have been a need for me to manage memory allocation in the first place. While pointers are dangeraous, they can also be very powerful, and they should never have been available in general interfaces, only for private and/or restricted system level (requiring full system access, i.e. OS level software) interfaces. And the language run-time should be responsible for allocation and releasing memory. Access to non-data areas could have been protected by hardware mechanisms.
Now I have to worry about what type of object is providing me with the simple information (some times as simple as a count) so that I can determine if I have to perform one or more levels of typecasting. That, I don't like about .Net.
|
|
|
|
|
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
