All C++ applications loading any kind of image resources that are too big for embedding into the binary need this, yet I haven't seen a single okay solution for long-term maintenance. My goal is that programs written using my library should have a minimum amount of maintenance when moving from one operating system to another over centuries, so any temporary hacks won't do any good. I don't care about the cases when the program runs from memory or access is blocked by the operating system.
* System specific calls will only work for around 20 years before being deprecated. This has to work for at least 200 years.
* Using a register key won't work on systems without a register and probably requires system specific calls.
* argv[0] only returns the CLI alias or path to the desktop shortcut, which says nothing about the application's location.
* Using the current directory only worked in Windows 2000 and older where current directory was set to the application folder path even when called using a shortcut.
* Searching for a unique filename would be both slow and a security risk.
* Comments about "how one shouldn't know the application's path" won't load assets reliably.
* Passing the folder path as an argument requires hard-coded shortcuts, which will break if the folder moves.
* System specific calls will only work for around 20 years before being deprecated. This has to work for at least 200 years.
* Using a register key won't work on systems without a register and probably requires system specific calls.
* argv[0] only returns the CLI alias or path to the desktop shortcut, which says nothing about the application's location.
* Using the current directory only worked in Windows 2000 and older where current directory was set to the application folder path even when called using a shortcut.
* Searching for a unique filename would be both slow and a security risk.
* Comments about "how one shouldn't know the application's path" won't load assets reliably.
* Passing the folder path as an argument requires hard-coded shortcuts, which will break if the folder moves.
Edited by Dawoodoz
on
Reason: Initial post
Bold of you to assume you'll still have a C++ compiler for whatever the desired platforms might be in 200 years! Who knows what executables and filesystems will even look like by then? Any software that wants to survive that long is going to need some amount of maintenance. You should no more expect to write a program that lasts 200 years with no maintenance than to build a house or a road that lasts 200 years with no maintenance. Rather than trying to avoid making system-specific calls to do system-specific things, if you're serious about writing 200-year software, you should first start worrying about who's going to take over its upkeep after you die.
What is "C++ application folder"? %APPDATA%? LocalLow? - those you can get from environment variables.
Or are you talking about path to executable?
It do not think this is true (unless we're talking about some old Windows version, then I'm not sure). But on latest Windows argv[0] will contain full path to your executable if launched from shortcut.
But anyways, for getting path to executable on Windows I would just use GetModuleFileName function, it's completely normal function and does not involve any syscalls - it just walks over LDR linked list of loaded modules in PEB.
On GNU/Linux this involves syscall, but it is stable and won't change - readlink("/proc/self/exe", ...)
Or are you talking about path to executable?
Dawoodoz
* argv[0] only returns the CLI alias or path to the desktop shortcut, which says nothing about the application's location.
It do not think this is true (unless we're talking about some old Windows version, then I'm not sure). But on latest Windows argv[0] will contain full path to your executable if launched from shortcut.
But anyways, for getting path to executable on Windows I would just use GetModuleFileName function, it's completely normal function and does not involve any syscalls - it just walks over LDR linked list of loaded modules in PEB.
On GNU/Linux this involves syscall, but it is stable and won't change - readlink("/proc/self/exe", ...)
Edited by Mārtiņš Možeiko
on
notnullnotvoid
Rather than trying to avoid making system-specific calls to do system-specific things, if you're serious about writing 200-year software, you should first start worrying about who's going to take over its upkeep after you die.
I'm just writing the library, not the applications. An average developer should be able to port the library to a new operating system together with the program. I expect the programming language to be replaced in cycles of 50 years using artificial intelligence.
Dawoodoz
I'm just writing the library, not the applications.
Then answer is easy - ask library user to pass path in. Then it's application problem to do that after 200 years correctly.
Edited by Mārtiņš Možeiko
on
mmozeikoDawoodoz
I'm just writing the library, not the applications.
Then answer is easy - ask library user to pass path in. Then it's application problem to do that after 200 years correctly.
Okay. Maybe it shouldn't stretch its responsibility too far then.
I've now sent a suggestion for this feature to the C++ standard.
Edited by Dawoodoz
on