justin = { main feed , music , code , askjf , pubkey };
Ask Justin Frankel
No reasonable question unanswered since 2009!

Suggested topics: programming, music, sleep, coffee, etc.

Note: please do not ask questions about REAPER features, bugs or scheduling, use the forums instead.


Name: Ask: Human (enter yes):
[back to index] | [unreplied] | [replied] | [recent comments] | [all]

Question: Hello M. Frankel ! I've a newbie question : if I decided to write a C++ app right now with libraries / dependencies like Guile, ... a, b, c... Will my today's compiled app (under its binary form) could be broken if some dependencies were obsolete in a distant future ? If so, what would you do appart from using virtualization software at that time ? Have a good day ! Best,
Asked by Arlequin (212.224.224.x) on April 10 2021, 6:21am
Reply on April 10 2021, 12:09pm:
    Well, on Windows/macOS you would either need to static link or to ship copies of the libraries yourself, in which case you should be fine. On Linux, you could static link, or you could use the shared library, and in theory if some newer version of the library isn't compatible, they'd change the major version number and the linux distribution would still provide the old version as a separate package? I'd probably static link if the license allows for it, or provide a binary of the library to go in a local path to your app if not...


Comments:
  • Posted by Arlequin (212.224.225.x) on April 10 2021, 1:13pm:
    Then if I plan to use GNU Bison, Flex, Postscript, GUILE and Metafont I am safe within the two decades to come, right ? Many thanks ! Best,

  • Posted by Arlequin (212.224.239.x) on April 11 2021, 10:16am:
    In other words : is a compiled binary file (incl. its dependencies) compatible "forever" ? All the Best,

  • Posted by Mespotine (80.187.118.x) on April 11 2021, 12:17pm:
    In the computer world: nothing is compatible forever. You might be able to stretch the compatibility but there's progress in computers. Just look at Apple-Macs. Programs from 15 years ago do not run anymore on modern Macs, no matter how good they were programmed. Maintenance will always be a part of software engineering.

  • Posted by Mespotine (80.187.118.x) on April 11 2021, 12:18pm:
    (32 bit program

  • Posted by Mespotine (80.187.118.x) on April 11 2021, 12:19pm:
    (32 bit programs from 15 years ago.) (Hit Comment too early ;))

  • Posted by Arlequin (212.224.224.x) on April 11 2021, 12:28pm:
    Then If I want something compatible in a few decades I'd have to limit myself with for instance C / Soundpipe C library / even not Portaudio, right ? Best,

  • Posted by Mespotine (80.187.118.x) on April 11 2021, 12:48pm:
    Even this is no guarantee. You can only try to limit the amount of maintenance work by limiting the amount of dependencies. But still, these dependencies might rely on other things, even if it's only some kernel-features. You might be able to write something that you just need to compile once in a while but you never know, if something you need will be deprecated. The only way to guarantee software being runnable in 15 years is to write them to work on old homecomputers like C64, Apple II, ZX Spectrum, as

  • Posted by Mespotine (80.187.118.x) on April 11 2021, 12:49pm:
    will never change anymore, not even in 15 years

  • Posted by Mespotine (80.187.118.x) on April 11 2021, 12:52pm:
    but the more modern the computer gets and the os, the more likely it will become for things to break. It's understandable that you want to write something that works forever, but these times are long gone and it's very unlikely to code something like that anymore. So you'll need to at least recompile things once in a while. But even compilers change over time.

  • Posted by Justin on April 11 2021, 5:33pm:
    To be fair, win32 applications written in 1995 still run on Windows today... :/ and I'd imagine ancient a.out 32-bit linux apps can be made to (with a little bit of trouble). So really it's just Apple.


Comment:
    Your Name:   -- Site Owner's Name:  (for human-verification)

    Comment:    

    
  
[back to index] | [unreplied] | [replied] | [recent comments] | [all]
Copyright 2024 Justin Frankel. | RSS