3 ms·

That feeling when a VB6 application is more lightweight than most of today's "native" applications.

Jaruzel 4y ago
Until Windows drops 32-bit compatibility, VB6 apps will continue to run fine even if they do look f'ugly against todays UI design. In fact there's probably still a significant amount of industrial/heavy-commercial in-house applications written in VB still in use. I can see a use case for TwinBASIC in maintaining these legacy apps, as the VB6 IDE no longer behaves itself under Windows 10/11. If it offers compilation to 64-bit (pseudo)code, then these apps will gain an extension on their usable life.
- int_19h 4y ago
  Given than VB6 mostly used native widgets, you can make apps written in it look modern simply by adding a manifest with the appropriate incantations.
  - Jaruzel 4y ago
    True, but I think you also have to add a VisualStyles API call as well to the Form_Load() Sub ? It's been a long time since I've done it though.
    - orra 4y ago
      Looks like you need to call InitCommonControls(Ex), in addtion to the manifest. https://jeffpar.github.io/kbarchive/kb/309/Q309366/ https://jeffpar.github.io/kbarchive/kb/309/Q309366/ I'll forgive your slight misremembering, because it's probably been 20 years.
      - VB6-Programming 4y ago
        >Looks like you need to call InitCommonControls(Ex), in addtion to the manifest. Often all you need is the manifest. If the app won't run at all after you have added the manifest, then add a call to InitCommonControls(Ex)
bouncing 4y ago
Visual Basic was mostly just used for line-of-business software -- forms, reports, etc. That's mostly been moved to the web, but it was seldom used for anything where performance was important.
orra 4y ago
To be fair, it's been that way for a long time. VB6 (and VB5) compiled to machine code, unlike earlier versions which were criticised for interpreting bytecode ("P-code"). Now, VB required some runtime dlls, namely msvbvm60.dll, and several ActiveX controls, but that feels small compared to even the .NET Framework. And tiny compared to your implied comparison with Electron/Chromium.
giancarlostoro 4y ago
And it doesn't even have true threading in the language, you can do it, but its not like a language construct. What is beautiful about VB6 is your ability to use native DLLs and parts of the Win32 API as well. I've been wanting to see a VB6 successor for a long time. I have debated paying for Xojo but I'm not a fan of their docs and havent built anything worthwhile yet to justify buying a license.

Until Windows drops 32-bit compatibility, VB6 apps will continue to run fine even if they do look f'ugly against todays UI design. In fact there's probably still a significant amount of industrial/heavy-commercial in-house applications written in VB still in use. I can see a use case for TwinBASIC in maintaining these legacy apps, as the VB6 IDE no longer behaves itself under Windows 10/11. If it offers compilation to 64-bit (pseudo)code, then these apps will gain an extension on their usable life.

int_19h 4y ago
Given than VB6 mostly used native widgets, you can make apps written in it look modern simply by adding a manifest with the appropriate incantations.
- Jaruzel 4y ago
  True, but I think you also have to add a VisualStyles API call as well to the Form_Load() Sub ? It's been a long time since I've done it though.
  - orra 4y ago
    Looks like you need to call InitCommonControls(Ex), in addtion to the manifest. https://jeffpar.github.io/kbarchive/kb/309/Q309366/ https://jeffpar.github.io/kbarchive/kb/309/Q309366/ I'll forgive your slight misremembering, because it's probably been 20 years.
    - VB6-Programming 4y ago
      >Looks like you need to call InitCommonControls(Ex), in addtion to the manifest. Often all you need is the manifest. If the app won't run at all after you have added the manifest, then add a call to InitCommonControls(Ex)

bouncing 4y ago

Visual Basic was mostly just used for line-of-business software -- forms, reports, etc. That's mostly been moved to the web, but it was seldom used for anything where performance was important.

orra 4y ago

To be fair, it's been that way for a long time. VB6 (and VB5) compiled to machine code, unlike earlier versions which were criticised for interpreting bytecode ("P-code"). Now, VB required some runtime dlls, namely msvbvm60.dll, and several ActiveX controls, but that feels small compared to even the .NET Framework. And tiny compared to your implied comparison with Electron/Chromium.

giancarlostoro 4y ago

And it doesn't even have true threading in the language, you can do it, but its not like a language construct. What is beautiful about VB6 is your ability to use native DLLs and parts of the Win32 API as well. I've been wanting to see a VB6 successor for a long time. I have debated paying for Xojo but I'm not a fan of their docs and havent built anything worthwhile yet to justify buying a license.