3 ms·
It's such a pity that microsoft did not provide a path forward for the applications written in vb6. Further, at a time when they are open-sourcing so much they
by barking 10y ago
It's such a pity that microsoft did not provide a path forward for the applications written in vb6.
Further, at a time when they are open-sourcing so much they still keep vb6 closed source so that no-one else can either.
It's almost sadistic.
- cm2187 10y agoI have some sympathy for Microsoft on this. Some of the changes could have been backward compatible (like making "set" optional). But some breaking changes had to be made. Like making all function parameters byval by default. Having everything byref by default in VB6 was just a bad initial design.
- barking 10y agoNot sure I understand your second example. The upgrade code to VB7 could just have inserted a ByRef for every parameter lacking both a Byval and a Byref?
- deleted 10y ago[deleted]
- cm2187 10y agoYep, sorry. But I guess you are then changing people's code. Although in this case it is a relatively safe change.
- WorldMaker 10y agoMicrosoft produced several migration tools from VB6 to VB.NET over the years. An "Upgrade Wizard" to do a first pass conversion. Some integration tools to run VB6 COM components in VB.NET applications and vice versa (VB.NET code as VB6 ActiveX components). VB.NET was always meant to be the path forward, and VB.NET, at least, is open source now.
- barking 10y agoIt was a path forward that required the people to leave their intellectual property behind. Not sure if path forward is the correct term for that.
- WorldMaker 10y agoWhat are you talking about? In that very comment I just pointed to several ways that Microsoft (not even getting to third party options) tried to give a helping hand to people to migrate existing projects at the time of the VB6 to VB.NET conversion path. Yes, it wasn't an entirely smooth transition, but there was a forward transition path.
- barking 10y agoThe assistance they provided got better as the years went by up to about the time of vb2008. Even then the assistance was such that migration of existing vb6 code was recommended by microsoft as the option of last resort. By the release of vb2010 microsoft appeared to have given up on migration completely and removed the upgrade tool from the product. Too little too late is probably a fair description of it.
- WorldMaker 10y agoYes, but "a bumpy road is still a road". Forward does not imply "painless", and Microsoft did try to help, even if it felt like "too little too late". VB.NET was still the forward path from VB, whether developers and companies liked that or not.
- VB6-Programming 10y agoThe migration tool was next to useless. Even if, after a lot of effort, you migrated your app it would typically run a lot slower than on VB6. The only practical way to "migrate" was a complete re-write, that way you could have something comparable in performance to the original app. And that is why there are still so many VB6 applications around today, the cost of migrating (to an app that was no better than the original) was rarely justified. Now that Microsoft support VB6 until at least 2025 while VB.Net is falling in popularity (only 12% of .Net developers use Vb.Net now) it looks like those staying with VB6 made the right decision.
- devopsproject 10y agomicrosoft knows that vb6 users want vb7, not .net, and that opensourcing it would likely divert millions of people away from microsoft.