VB6 is DEAD!

[axisdj]

Well all you .net folks told us it would not happen:

http://visualstudio.uservoice.com/fo...improved-versi

Time to move on, Delphi here I come. All my embedded devices will ship with Linux!

It's Over

Sad DAY

Lots of hard work to be done, here we go!!!

[DataMiser]

It is no deader now than it was last year or the year before.

I do like the fact they stated that the runtime? should be supported through 2024

btw It wasn't just .Net folks that were telling you that, it was VB6 guys too. I thought it was pretty clear 10 years ago that VB6 was not coming back but would continue to work for the foreseeable future.

[Carlos Rocha]

Sad news, but expected. I don't believe the pointed reasons tho.

[dilettante]

Doesn't really matter. They're just sticking to the same position they've had since 2005 or so.

I think it is probably telling that no 3rd party has stepped up to create an acceptable alternative. Perhaps a big reason for that is how hard it is to define something "acceptable" in a way that doesn't step on some of Microsoft's legally protected stuff.

There are tons of 3rd party alternatives already though. Find one that works for you.

[SamOscarBrown]

If you HAVE to post junk like this, keep it in the chat room....this forum (VB6 and Before) is designed to HELP people WITH VB6.

[Joacim Andersson]

Thread moved to Chit Chat.

Where we have been able to help move forward is in our stance around support and interoperability. The VB6 runtime it is still a component of the Windows operating system and is a component shipped in Windows 8.1. It will be supported at least through 2024.

Doesn't sound to me as MS has killed it yet...

Time to move on, Delphi here I come.

Well, Delphi 8, Delphi 2010 and Delphi XE2 was all different and you needed to make substantial changes to your code to upgrade between these versions. Moving from VB6 to VB.Net is actually easier.

[Carlos Rocha]

Moving from VB6 to VB.Net is actually easier.

I think difficulty is not the major reason why lots of VB6'ers didn't move to VB.NET, it's .NET itself.

[jmsrickland]

What do you mean VB6 is dead?

No it isn't. I'm using it right this moment and it still works

[Joacim Andersson]

I think difficulty is not the major reason why lots of VB6'ers didn't move to VB.NET, it's .NET itself.

So what's wrong with .Net? If you're running a modern Windows OS you've already have it. With it you can develop desktop applications, console applications, Windows Services, Web Applications, Web Services, Modern UI apps, Windows Phone Apps, XNA Games for the XBox or Windows, and the list goes on... How many of these things can you do with VB6? If you also invest in Xamarin you can even use your .Net skills to develop for Android and iPhone.

[sharpCode#]

I think difficulty is not the major reason why lots of VB6'ers didn't move to VB.NET, it's .NET itself.

Only thing I can see that is a considerable negative about .NET is that you need to install the whole framework even when most programs will barely begin to use a tenth of it. So I think as someone mentioned in another thread could be good to see it compile and include only the necessary stuff (could have my terms mixed up still learning).

Anyway I imagine VB6 development will still be quite prevalent for at least a few more years.

[Carlos Rocha]

So what's wrong with .Net? If you're running a modern Windows OS you've already have it. With it you can develop desktop applications, console applications, Windows Services, Web Applications, Web Services, Modern UI apps, Windows Phone Apps, XNA Games for the XBox or Windows, and the list goes on... How many of these things can you do with VB6? If you also invest in Xamarin you can even use your .Net skills to develop for Android and iPhone.

That's not the point. The point is: do you need .NET for most of that? I don't know about Windows Phone or XNA (whatever it is), but for all the rest you certainly don't need .NET. It's just, maybe,...easy to work with? but I don't think it's that easier than anything else as long as you know the right tools, and pure Win32/Win64 is still best, imho. The problem I see with VB6 dropping is that nothing is left from MS to create native binaries but C++.

[Joacim Andersson]

Well, .Net Native is still rather new but it will be covering these issues (if they are issues, .Net is preinstalled on Windows). And VB6 never created pure native applications since you still needed the runtime libraries since they contained all the wrapped controls.

[sharpCode#]

To this day .NET has less features than VB6, is slow and bloated and has about 10x distribution size compared to VB6.

My personal opinion is that Microsoft will make a new version of vb6, we are simply too many programmers. I'm glad we started to come together as a community and speak our minds.

Microsoft does not have the expertise to make a new VB6.

Saw a few comments I found interesting in the link. I never got to involved in VB6 though it was the first language I used and still love it. But even now is .NET still feature-less compared to VB6? Also could the fact that Microsoft don't have the expertise be a reason they don't want to remake it?

Also my understanding is technology has changed, every morning I pick up my phone and I use modern stuff that is generally all web based and extremely flexible. I don't think VB6 could really fit these purposes in today's world.

[dclamp]

I have to say I didnt see any of this coming. I thought they were going to bring it back. Fatia said his petition has 7200 votes...

[DataMiser]

Only thing I can see that is a considerable negative about .NET is that you need to install the whole framework even when most programs will barely begin to use a tenth of it. So I think as someone mentioned in another thread could be good to see it compile and include only the necessary stuff (could have my terms mixed up still learning).

Anyway I imagine VB6 development will still be quite prevalent for at least a few more years.

That would actually be a bad thing I think, The .Net framework is on most Windows machines already and lots of applications use it and have been doing so for quite some time. If each app compiled only the parts of the framework they needed and distributed it with their apps then all .net apps would be larger, some of them by huge amounts and the amount of disk space used would increase greatly.

What about VB6, most programs do not use most of the stuff in the runtime yet the entire runtime is required for all of them, pretty much the same thing with .Net just a different file set.

That's not the point. The point is: do you need .NET for most of that? I don't know about Windows Phone or XNA (whatever it is), but for all the rest you certainly don't need .NET. It's just, maybe,...easy to work with? but I don't think it's that easier than anything else as long as you know the right tools, and pure Win32/Win64 is still best, imho. The problem I see with VB6 dropping is that nothing is left from MS to create native binaries but C++.

XNA is a free product that allows you to develop games for Windows, Windows Phone and XBox 360 using .Net languages.

VB.Net also allows you to develop for Windows CE and Windows Mobile devices which I have been doing in VB.Net for several years now with much success.
Vb.Net is easy to work with once you have adjusted to it, and so is C# in many cases VB.Net can be easier to work with than VB6 and can do a lot more.

I have to say I didnt see any of this coming. I thought they were going to bring it back. Fatia said his petition has 7200 votes...

Which is a very small number to a company like MS.

What surprises me is that anyone is surprised that MS did what most expected them to do anyway. It really should have been clear to most a long time ago that VB6 was the last of the classic VB editions.

[Joacim Andersson]

That would actually be a bad thing I think, The .Net framework is on most Windows machines already and lots of applications use it and have been doing so for quite some time. If each app compiled only the parts of the framework they needed and distributed it with their apps then all .net apps would be larger, some of them by huge amounts and the amount of disk space used would increase greatly.

But this is coming with .Net Native.

[Joacim Andersson]

To this day .NET has less features than VB6

That's a ridiculous and an untrue statement.

[DataMiser]

But this is coming with .Net Native.

Does that actually build parts of the framework into the exe [meaning that the framework does not need to be present on the target] or is it just doing native compile of the code like VB6 does still requiring the runtime and possibly one to several other dlls, and such to operate on the target?

I assumed it would still use the framework as a runtime but be skipping the JIT runtime phase

[jmcilhinney]

But this is coming with .Net Native.

I haven't read too much on the subject but, while I could be wrong, I doubt that. I don't think each app would have parts of the .NET Framework compiled into its native code. I would expect that the Framework libraries would still be separate, whether in IL or native form, and there would only be one copy of each to be shared by all apps.

[Joacim Andersson]

I haven't read too much on the subject but, while I could be wrong, I doubt that. I don't think each app would have parts of the .NET Framework compiled into its native code. I would expect that the Framework libraries would still be separate, whether in IL or native form, and there would only be one copy of each to be shared by all apps.

If you'll have a look at this Channel 9 video you'll see that that is exactly what it's doing. Of course that doesn't mean that there will be zero dependencies.

However the .Net framework is all native, since in the end native is the only thing that will actually run on your machine. It's just that your app is JITet on first run, but the framework itself is already native. What .Net Native does is a lot of optimization and will compile all types that you're using into the app itself and produce two files: an app.exe and an app.dll. The app.exe is about 10kb in size and it's actually the app.dll that contains all your code. So the app.exe is just calling a main function in the dll.

[Shaggy Hiker]

The one thing I am curious about, but don't know how to ask about, is what the opposition to .NET is for those passionate about VB6? Some people appear to simply be misinformed, which is understandable, as there has been LOTS of misinformation out there. I stayed away from .NET for a couple years due to that mininformation, myself, but that's kind of minor. What I suspect is the case is that Object Oriented languages are such a different way to think about things when compared to block-structured, functional, or whatever the proper term is for the other way, that the shift from one to the other is daunting. Since I came from an OO background prior to VB of any sort, I tried to write VB5/6 in an OO fashion, which it doesn't really do. Therefore, I found OO to be one of the major selling points for .NET. On the other hand, I think TG said that he struggled with OO, initially (may not have been him, too, but until he contradicts me I'm sticking to it). I can really understand that. Our brains pick up concepts in different ways, and once some pattern is established, our brains work against changing that pattern (for good reason, too). So, there will be people who will really struggle with OO and there will be people who will not. I just wonder if that is the basis for much of the resistance to .NET, or if it is the misinformation stuff such as the need for the framework (all languages need a framework, and have since the 80s, we just shift the definition of framework around to suit our needs).

[RobDog888]

Run ScriptBrix™ instead

[techgnome]

On the other hand, I think TG said that he struggled with OO, initially (may not have been him, too, but until he contradicts me I'm sticking to it).

I've been using OO since I first learned about it back in late 80's early 90's ... it seemed quite natural and obvious... what I struggled with was event programming... Coming from a strictly procedural background of Pascal and BASIC, even programming was jibberish. "Where the fork is the IF statement that says 'If button clicked, call this method?'"
was a common phrase from me during that time... it was a while before the penny dropped and realized it's basically FM ...

You may now unstick yourself.

-tg

[Carlos Rocha]

@Shaggy,

I'm not "passionate" about VB6, I just think it's the easiest way to produce COM binaries, with near zero dependencies or deployment issues. Using .NET for this feels like using a train to go shopping.

My programming language is Visual Objects (created by CA as the Clipper successor for Windows, back in the 90s). It follows a beautiful OO paradigm that I can use with any ActiveX or COM Server, and I dont think it's too different from VB6 in this respect (at least at the basic level I use it). Sure, no inheritance, but there are other ways to accomplish something like it, and in fact COM is all about OO, so I don't think OO approach is the problem. The problem is the "non-simplicity" of .NET.

Now that we know Classic VB will not be further developed (so, no Win64 and no pure OO) it's time to find something else to fill the gap. That's why Delphi and the like are being referenced lately, and that's why I don't understand MS decision.

[Shaggy Hiker]

Bummer, I got the wrong detail wrong.

[FunkyDexter]

Axisdj, I really don't understand your position. Your arguments before now were always that you didn't want to have to rewrite you applications. This announcement means you don't have to. At least for another ten years. You can safely go on using VB6 until 2024.

I can understand (though I don't agree with) people's dislike of .Net. But the bit I can't get my head around is the gloom about having to move away from VB6 in response to MS announcing that you don't have to move away from VB6.

[RobDog888]

Just have to use the best tool (programming language) for each job (project)

[Fatina]

http://www.vbforums.com/showthread.p...-the-year-2024

[RobDog888]

Its still dead as a door nail

[DataMiser]

My programming language is Visual Objects (created by CA as the Clipper successor for Windows, back in the 90s). It follows a beautiful OO paradigm that I can use with any ActiveX or COM Server, and I dont think it's too different from VB6 in this respect (at least at the basic level I use it). Sure, no inheritance, but there are other ways to accomplish something like it, and in fact COM is all about OO, so I don't think OO approach is the problem. The problem is the "non-simplicity" of .NET.

I had not saw the name CA for quite a while, I remember back in the late 90s I wrote a few pieces of software for them, part of it in VB5 and other parts in a couple of different scripting languages.
A couple of the guys I worked with were fans of Clipper but I never really used it much myself.

[Shaggy Hiker]

@Shaggy,

I'm not "passionate" about VB6, I just think it's the easiest way to produce COM binaries, with near zero dependencies or deployment issues. Using .NET for this feels like using a train to go shopping.

That's a good point. I don't produce COM binaries, so I have neither knowledge nor opinion about that. Nothing is without dependencies, though, and hasn't been for a very long time. We have just come to ignore the dependencies that are convenient to ignore. After all, any talk about cross-platform issues is due to the fact that our apps are hosted in the cradle of some OS or other. There once was a day when that wasn't true...but it wasn't the best of times, to be sure. We also all use libraries of one sort or another, though not for every app.

My programming language is Visual Objects (created by CA as the Clipper successor for Windows, back in the 90s). It follows a beautiful OO paradigm that I can use with any ActiveX or COM Server, and I dont think it's too different from VB6 in this respect (at least at the basic level I use it). Sure, no inheritance, but there are other ways to accomplish something like it, and in fact COM is all about OO, so I don't think OO approach is the problem. The problem is the "non-simplicity" of .NET.

Now that we know Classic VB will not be further developed (so, no Win64 and no pure OO) it's time to find something else to fill the gap. That's why Delphi and the like are being referenced lately, and that's why I don't understand MS decision.

Delphi was referenced by axisdj who was clearly making that reference out of anger at MS. He'll really go round the bend if he goes to Delphi and sees what JA has now reported twice: They are perfectly content to introduce breaking changes to the language every few years. I feel that axisdj shouldn't even be considering any other language. From what he described, he's got at least another five years before he needs to even be worried about VB6 going away, and the world can change a whole lot in five years. On the other hand, if he wants cross platform, is Delphi really the best option? I'd be looking at Java or C. Things like PhoneGap might be an option, if his program wasn't what it is. I doubt PhoneGap would suit him well at all with the hardware access he's dealing with.

On the other hand, it seems to me that .NET is the right language for him, and I don't understand the reluctance. While I don't deal with COM binaries, I have dealt with hardware control for robotics, and .NET is an excellent language for that. Better than VB6 was, in fact. There was one thing that I kind of liked better about VB6, which was the handling of UDP in a simplistic situation. That was super simple. It was also super simplistic, which meant that it didn't scale all that well if scaling was important. Hardware control generally doesn't use UDP, though, but rather serial (the other com), which .NET has always handled as well, or better, than VB6 (I don't fully remember how VB6 handled it, except that it was a bit awkward).

Every tool is the best for some job. If the reluctance to change tools is because you have the best tool for the job at hand, then that's great. If the reluctance is resistance to learning new things...then you're in great company, because everybody has some of that. If the reluctance is over OO, then I totally understand that, as well, because I do know people who don't see things that way (though apparently not TG). The problem would be if reluctance was simply due to anger over some decision made by a sprawling corporation. Heck, I'm still amazed that there was even a response. I figured MS would simply ignore the petitions it didn't want to deal with and thereby leave everybody in limbo.

[DataMiser]

but rather serial (the other com), which .NET has always handled as well, or better, than VB6 (I don't fully remember how VB6 handled it, except that it was a bit awkward).

Umm not really. If memory serves VB2003 and Framework 1.1 did not come with a serial class at all. I had to buy a 3rd party tool in order to do some simple serial stuff in VB2003.

VB6 has the MSComm control which works fine in simple cases. I've used it on many projects for talking to printers, barcode readers and robotics. I also have a couple of 3rd party controls for VB6 that support the various transfer protocols such as X, Y, Z Modem and others.

As of VB2005 they added a serial class but still can be a bit tricky to use if you are coming over from VB6 due to the fact that it uses threading. Works very well once you get a handle on it.
TCP was easier to deal with in VB6 using the Winsock control but much more powerful in .Net using the Sockets Class

[Shaggy Hiker]

Well, I can't quite remember what 2003 had, but I thought I was using built-in serial back then for a series of PDA projects (I sure wasn't buying anything, as I had no budget, but I may have been using TCP). Now that you mention it, though, I do have some vague memory that it was added at some point.

[jmcilhinney]

Umm not really. If memory serves VB2003 and Framework 1.1 did not come with a serial class at all. I had to buy a 3rd party tool in order to do some simple serial stuff in VB2003.

VB6 has the MSComm control which works fine in simple cases. I've used it on many projects for talking to printers, barcode readers and robotics. I also have a couple of 3rd party controls for VB6 that support the various transfer protocols such as X, Y, Z Modem and others.

As of VB2005 they added a serial class but still can be a bit tricky to use if you are coming over from VB6 due to the fact that it uses threading. Works very well once you get a handle on it.
TCP was easier to deal with in VB6 using the Winsock control but much more powerful in .Net using the Sockets Class

.NET has always supported ActiveX controls so anyone with VB6 installed could use any ActiveX control that came with VB6 in the VB.NET apps. Some still do, but probably should have migrated away from them by now.

[jmcilhinney]

The one thing I am curious about, but don't know how to ask about, is what the opposition to .NET is for those passionate about VB6? Some people appear to simply be misinformed, which is understandable, as there has been LOTS of misinformation out there. I stayed away from .NET for a couple years due to that mininformation, myself, but that's kind of minor. What I suspect is the case is that Object Oriented languages are such a different way to think about things when compared to block-structured, functional, or whatever the proper term is for the other way, that the shift from one to the other is daunting. Since I came from an OO background prior to VB of any sort, I tried to write VB5/6 in an OO fashion, which it doesn't really do. Therefore, I found OO to be one of the major selling points for .NET. On the other hand, I think TG said that he struggled with OO, initially (may not have been him, too, but until he contradicts me I'm sticking to it). I can really understand that. Our brains pick up concepts in different ways, and once some pattern is established, our brains work against changing that pattern (for good reason, too). So, there will be people who will really struggle with OO and there will be people who will not. I just wonder if that is the basis for much of the resistance to .NET, or if it is the misinformation stuff such as the need for the framework (all languages need a framework, and have since the 80s, we just shift the definition of framework around to suit our needs).

I think part of the problem is that it's different things for different people. That's why there's never been a coherent plan for a new version of VB6 from anyone: because everyone wants something different. I've seen the fact that VB.NET is OO and VB6 is not used as an argument against VB6 before and then there will always be those who argue that VB6 had a number of OO elements and that was enough and I've even seen someone argue vigorously that VB6 is OO, even despite the lack of inheritance.

[DataMiser]

.NET has always supported ActiveX controls so anyone with VB6 installed could use any ActiveX control that came with VB6 in the VB.NET apps. Some still do, but probably should have migrated away from them by now.

Wasn't an option in my case as I was developing in VB.Net for mobile devices.

[jmcilhinney]

Wasn't an option in my case as I was developing in VB.Net for mobile devices.

Could you have written a mobile app in VB6 using that control? I'm not sure but I wouldn't have thought so. If not then I guess neither handling it at all still means that VB.NET handled it as well as VB6.

[axisdj]

Axisdj, I really don't understand your position. Your arguments before now were always that you didn't want to have to rewrite you applications. This announcement means you don't have to. At least for another ten years. You can safely go on using VB6 until 2024.

I can understand (though I don't agree with) people's dislike of .Net. But the bit I can't get my head around is the gloom about having to move away from VB6 in response to MS announcing that you don't have to move away from VB6.

Funky, Let me break it down. My program is sold to end users who buys a new laptop or windows machine to run my software(for controlling intelligent lighting). So lets say Windows 9 breaks my app/vb6 apps. I can no longer sell my product because my customer will only be able to buy a new pc with windows 9. I hope that makes sense.

OR

Am I missing something. Are you saying that my vb6 app will work until 2024 on the latest OS, I THINK NOT!

WP

[axisdj]

FYI,

I do not use serial communication. All my hardware communication is through a c++ dll.

I will have to do some more research, but from what I seen Delphi increments each version with mainly improvements, and something written in 1995, could very easily be converted and compiled in 2014. From what I understand there was never a version that completely broke everything as in vb6-.net. Correct me if I am wrong.

WP

[jmcilhinney]

Am I missing something. Are you saying that my vb6 app will work until 2024 on the latest OS, I THINK NOT!

Hmmm... I think that some, including myself, were interpreting that as saying that the VB6 Runtime would be distributed with Windows until 2024 but, upon reading it again, I now see that it looks to mean that the VB6 Runtime is supported on Windows 8.1 and Windows 8.1 will be supported until 2024. Rather a big difference.