3 ms·
Looking at it... Bad support for Windows, runs in Cygwin. Not compatible with Visual Basic, including trivial incompatibilities that are immediately inconveni
by dale_glass 3y ago
Looking at it...
Bad support for Windows, runs in Cygwin.
Not compatible with Visual Basic, including trivial incompatibilities that are immediately inconvenient (like different choice of file extensions).
But most important, as somebody who did a bunch of VB6 long ago: VB was marketed as "glue" for components that did lots of fancy stuff. Damn near everything in VB used a bunch of external components. CCRP project common controls, database interfaces, random junk that came with Microsoft Office like the Office menu controls, the Internet Explorer engine, Crystal Reports, you name it.
VB had the ability to use random OCX files that were on the developer's system for completely unknown reasons. You installed some random tool, and just got the corresponding OCX in the VB UI, and if you weren't too concerned about copyright issues you could just use it like that and package it into the installer. You didn't need any sort of development package, an OCX was usable on its own.
Reproducing all of this on Linux would have been impossible.
If you were a fan of VB you had no reason not to do it on Windows, and pirating Windows and VB wasn't hard back in the day.
The amount of people who wanted to write VB on Linux without any of what made it an useful tool on Windows would be tiny.
- pjmlp 3y agoMac has had similar kind of history in 3rd party libraries, and do iOS and Android to smaller extent, not as OCX/COM/.NET on Windows though. Ironically GNU/Linux could have pulled something like this when D-Bus became a thing after KDE and GNOME IPC stacks gave birth to it, but impossible given the fragmentation that plagues it to this day.