3 ms·

Several VB6 based tools from 1999 are still in use. They still work just fine in Win 7 64-bit. (VB6 was the best RAD tool from Microsoft, great integration with

by frik 10y ago

Several VB6 based tools from 1999 are still in use. They still work just fine in Win 7 64-bit. (VB6 was the best RAD tool from Microsoft, great integration with Windows and was part of the "information at your fingertip" vision. Then Java happend and Microsoft frantically tried to create something similar. 15 lost years, nowadays compiled languages and on the otherside dynamic languages like Javascript succeeded. And also the web succeeded over AOL, Microsoft Network and other pay-to-use-closed-attempts. And now with Win10 the whole platform is on a crossroad, the trust is gone with all spying, tracking and as-a-service idea - "users aren't slaves" and want to decide for themself after all)

Jaruzel 10y ago
Having spent a long time with VB6 as my go-to language, I get a little upset when people criticize it. It was designed as you say, as a RAD language so that the masses could easily knock up front-ends for almost anything, and as machines got faster it's main weakness (it's execution speed) became irrelevant. Yes, the lack of enforced typing, native multi-threading, and OOP finally killed it, but for it's time it was a very useful programming platform. On the upside, if you want a VB6 app to run on Windows now, all you need is MSVBVM60.DLL* in the same folder and it will run, unlike the massive clutch of files that .NET needs... (*This holds true for 16bit VB5 and VB4 as well, on 32 bit systems)
shthed 10y ago
A few months ago I recompiled a VB5 app for the first time since it was last built in 1998, it has been used daily. I didn't build this, just inherited it over 7 years ago and have never needed to look at it. Every once in a while it would miss some files in its directory listings. Took me forever to figure out that it only occurred when the new SAN was under heavy load and took longer than half a second to return a directory listing. I laughed when I came across this: Problems Using Intrinsic File System Controls https://support.microsoft.com/EN-US/kb/196141 https://support.microsoft.com/EN-US/kb/196141 SYMPTOMS: When you are using the intrinsic Visual Basic file system controls (for example, DriveListBox, DirListBox, FileListBox), some or all of your files are not listed. This usually occurs when you are trying to access files on a network server, but can occur locally under some circumstances. CAUSE: ... These controls are old technology. They were not designed for, nor tested with, some of the new operating and network system software. ... I just made it sleep for a second and then refresh its directory listings, sigh.. not gonna rewrite this thing now..

by frik 10y ago

Jaruzel 10y ago

Having spent a long time with VB6 as my go-to language, I get a little upset when people criticize it. It was designed as you say, as a RAD language so that the masses could easily knock up front-ends for almost anything, and as machines got faster it's main weakness (it's execution speed) became irrelevant. Yes, the lack of enforced typing, native multi-threading, and OOP finally killed it, but for it's time it was a very useful programming platform. On the upside, if you want a VB6 app to run on Windows now, all you need is MSVBVM60.DLL* in the same folder and it will run, unlike the massive clutch of files that .NET needs... (*This holds true for 16bit VB5 and VB4 as well, on 32 bit systems)

shthed 10y ago

A few months ago I recompiled a VB5 app for the first time since it was last built in 1998, it has been used daily. I didn't build this, just inherited it over 7 years ago and have never needed to look at it. Every once in a while it would miss some files in its directory listings. Took me forever to figure out that it only occurred when the new SAN was under heavy load and took longer than half a second to return a directory listing. I laughed when I came across this: Problems Using Intrinsic File System Controls https://support.microsoft.com/EN-US/kb/196141 https://support.microsoft.com/EN-US/kb/196141 SYMPTOMS: When you are using the intrinsic Visual Basic file system controls (for example, DriveListBox, DirListBox, FileListBox), some or all of your files are not listed. This usually occurs when you are trying to access files on a network server, but can occur locally under some circumstances. CAUSE: ... These controls are old technology. They were not designed for, nor tested with, some of the new operating and network system software. ... I just made it sleep for a second and then refresh its directory listings, sigh.. not gonna rewrite this thing now..