3 ms·

I've got the same exe running in client installs since the late 90's. It's had a tweak or two here and there, but largely unchanged. I last recompiled it about

I've got the same exe running in client installs since the late 90's. It's had a tweak or two here and there, but largely unchanged. I last recompiled it about 2yrs ago and had a fresh install of it about 6 months ago. It's not the prettiest thing and could have certain upgrades in light of new security practices (eg use new encryption algos & go thru an in-depth security audit). But to the clients, it's unbeatable and there's nothing remotely close to migrate to. Unbelievably, it's a vb6 app that I never bothered porting to dotnet. Even more unbelievably, it's a port of its predecessor, written in turbo pascal. As long as I can continue to find the dev environment installer, it's good to go. So. I think s large part of the problem is that ppl don't redirect their dev environment enough to keep an install disk, (if one was available in the first place). A second large problem is that modern development relies heavily on 3rd party library use, which means your software is reliant on more than one company for your binary. So. Find an environment that you can archive/keep, and ignore the not invented here rule to a large extent

user5994461 6y ago
>>> I've got the same exe running in client installs since the late 90's. That's on Windows that has stable API and ABI. The 90's is probably the limit because older software are 16 bits and don't work on current 64 bits Windows. On Linux all software break with each distro release because "core" libraries are unstable. Got executable and libraries compiled on RHEL 6 and most of them fail to load on RHEL 7 because something.so not found.
- laumars 6y ago
  You can bundle the .so files in Linux just like you would bundle .dll files in Windows. Or statically compile if you don’t want dynamic libraries. Linux and Windows isn’t really any different there aside from Windows has more in the way of novice friendly tools to create redistributables. It’s also worth noting that you’re comparing Apples to Oranges in that Visual Basic 6 is a very different language to C++. VB6 has its own warts when it comes to archiving such as it’s dependence on OCX and how they require registering for use (they can’t just exist in the file system like DLL and SO libraries, OCX required their UUIDs loaded into Windows Registry first). To further my previous point, if you wanted to use another language on Linux, maybe one that targets the OS ABIs directly (eg Go), then you might find it would live longer without needing recompiling. Contrary to your statement about user space libraries, Linux ABIs don’t break often. Or you could use a JIT language like Perl or Python. Granted you are then introducing a dependency (their runtime environment being available on the target machine) but modern Perl 5 is still backwards compatible with earlier versions of Perl 5 released in the 90s (same timescale as the VB6 example you’d given except Perl is still maintained where as VB6 is not).
  - PaulDavisThe1st 6y ago
    Linux ABIs might not break often. But GTK, Qt, libwhatever ? More often than one would like.
    - laumars 6y ago
      I’d discussed that problem in the first paragraph of my post.
      - user5994461 6y ago
        For reference, the C++ ABI is changing with every minor version of gcc, making compiled libraries like glibc or Qt incompatible. Major distro releases upgrade gcc so all packages are incompatible. I agree on compiling statically to avoid DLL hell. However it is fairly difficult in practice because software rarely document how to statically build them and they very often take dependency to some libraries on the system. All it takes is one dynamic dependency to break (libstdc++ is not stable for example).
        laumars 6y ago
        > For reference, the C++ ABI is changing with every minor version of gcc, making compiled libraries like glibc or Qt incompatible. Major distro releases upgrade gcc so all packages are incompatible. It’s actually not as dramatic as that and you can still ship libc as a dependency of your project like I described if you really had to. It’s vaguely equivalent in that regard to a Docker container or chroot except you’re not sandboxing the applications running directory. This is something I’ve personally done many times on both Linux and a some UNIXes too (because I’ve had a binary but for various different reasons didn’t have access to the source or build tools). I’ve even run Linux ELFs on FreeBSD using a series of hacks, one of them being the above. Back before Docker and treating servers like cattle were a thing, us sysadmins would often have some highly creative solutions running on our pet servers. > I agree on compiling statically to avoid DLL hell. However it is fairly difficult in practice because software rarely document how to statically build them and they very often take dependency to some libraries on the system. All it takes is one dynamic dependency to break (libstdc++ is not stable for example). There are a couple of commonly used flags but usually reading through the Makefile or configure.sh would give the game away. It has been a while since my build pipelines required me to build the world from source but I don’t recall running into any issues I couldn’t resolve back when I did need to commonly compile stuff from source.
myth2018 6y ago
I'm glad for you. I'm aware of a dozen of systems in my country built using VB6 or Clipper/Harbour (text mode) which are still in use. And what I like most on such cases of success is that users mostly feel pleased by using them -- those systems basically do the job, fastly. For me, that tells a whole lot about how wrong are some philosophies getting mainstream, focusing on great aesthetics, mobile-first and, in my opinion, a very mistaken sense of user-friendliness
magicalhippo 6y ago
While we're actively developing our program, we got several core modules that have barely been touched since they were written in 1997. It's not pretty code, but hey it works, so until we need to there's no need to touch it. A coworker has written a tool that edits the registry such that you can do a fresh install of our compiler/IDE (Delphi), run the tool, and then load up our project and it'll compile. The tool gets updated when needed, usually when we change dependencies. All dependencies are kept alongside the source in the same repo, which makes it easy to ensure you got the right stuff available for compilation, as well as being able to make patches if we really need to fix an issue ourselves. Need to compile an old version? Check out the right branch, run the tool and start the IDE version used for that branch. Easy.

user5994461 6y ago

>>> I've got the same exe running in client installs since the late 90's. That's on Windows that has stable API and ABI. The 90's is probably the limit because older software are 16 bits and don't work on current 64 bits Windows. On Linux all software break with each distro release because "core" libraries are unstable. Got executable and libraries compiled on RHEL 6 and most of them fail to load on RHEL 7 because something.so not found.

laumars 6y ago
You can bundle the .so files in Linux just like you would bundle .dll files in Windows. Or statically compile if you don’t want dynamic libraries. Linux and Windows isn’t really any different there aside from Windows has more in the way of novice friendly tools to create redistributables. It’s also worth noting that you’re comparing Apples to Oranges in that Visual Basic 6 is a very different language to C++. VB6 has its own warts when it comes to archiving such as it’s dependence on OCX and how they require registering for use (they can’t just exist in the file system like DLL and SO libraries, OCX required their UUIDs loaded into Windows Registry first). To further my previous point, if you wanted to use another language on Linux, maybe one that targets the OS ABIs directly (eg Go), then you might find it would live longer without needing recompiling. Contrary to your statement about user space libraries, Linux ABIs don’t break often. Or you could use a JIT language like Perl or Python. Granted you are then introducing a dependency (their runtime environment being available on the target machine) but modern Perl 5 is still backwards compatible with earlier versions of Perl 5 released in the 90s (same timescale as the VB6 example you’d given except Perl is still maintained where as VB6 is not).
- PaulDavisThe1st 6y ago
  Linux ABIs might not break often. But GTK, Qt, libwhatever ? More often than one would like.
  - laumars 6y ago
    I’d discussed that problem in the first paragraph of my post.
    - user5994461 6y ago
      For reference, the C++ ABI is changing with every minor version of gcc, making compiled libraries like glibc or Qt incompatible. Major distro releases upgrade gcc so all packages are incompatible. I agree on compiling statically to avoid DLL hell. However it is fairly difficult in practice because software rarely document how to statically build them and they very often take dependency to some libraries on the system. All it takes is one dynamic dependency to break (libstdc++ is not stable for example).
      - laumars 6y ago
        > For reference, the C++ ABI is changing with every minor version of gcc, making compiled libraries like glibc or Qt incompatible. Major distro releases upgrade gcc so all packages are incompatible. It’s actually not as dramatic as that and you can still ship libc as a dependency of your project like I described if you really had to. It’s vaguely equivalent in that regard to a Docker container or chroot except you’re not sandboxing the applications running directory. This is something I’ve personally done many times on both Linux and a some UNIXes too (because I’ve had a binary but for various different reasons didn’t have access to the source or build tools). I’ve even run Linux ELFs on FreeBSD using a series of hacks, one of them being the above. Back before Docker and treating servers like cattle were a thing, us sysadmins would often have some highly creative solutions running on our pet servers. > I agree on compiling statically to avoid DLL hell. However it is fairly difficult in practice because software rarely document how to statically build them and they very often take dependency to some libraries on the system. All it takes is one dynamic dependency to break (libstdc++ is not stable for example). There are a couple of commonly used flags but usually reading through the Makefile or configure.sh would give the game away. It has been a while since my build pipelines required me to build the world from source but I don’t recall running into any issues I couldn’t resolve back when I did need to commonly compile stuff from source.

myth2018 6y ago

I'm glad for you. I'm aware of a dozen of systems in my country built using VB6 or Clipper/Harbour (text mode) which are still in use. And what I like most on such cases of success is that users mostly feel pleased by using them -- those systems basically do the job, fastly. For me, that tells a whole lot about how wrong are some philosophies getting mainstream, focusing on great aesthetics, mobile-first and, in my opinion, a very mistaken sense of user-friendliness

magicalhippo 6y ago

While we're actively developing our program, we got several core modules that have barely been touched since they were written in 1997. It's not pretty code, but hey it works, so until we need to there's no need to touch it. A coworker has written a tool that edits the registry such that you can do a fresh install of our compiler/IDE (Delphi), run the tool, and then load up our project and it'll compile. The tool gets updated when needed, usually when we change dependencies. All dependencies are kept alongside the source in the same repo, which makes it easy to ensure you got the right stuff available for compilation, as well as being able to make patches if we really need to fix an issue ourselves. Need to compile an old version? Check out the right branch, run the tool and start the IDE version used for that branch. Easy.