Solved (Windows) Minimum files in deployment that cannot be moved
-
@ScottMichaud said in (Windows) Minimum files in deployment that cannot be moved:
What is the minimum number of files that cannot be moved to a qt sub-directory, and what would I need to do to get my Qt application to see them (in a dynamically linked configuration)?
The "minimum number" depends on:
- Which compiler did you use to build your project?
- Which Qt modules do your project link to?
- Are you willing to modify your system's PATH?
Broadly, there are 2 groups of DLLS:
- Load-time DLLs need to be found by Windows before it launches your app. Examples:
- libstdc++-6.dll (if you used the MinGW compiler)
- Qt5Core.dll
- Run-time DLLs need to be found by your app before it tries to initialize specific features. Examples:
- platforms/qwindows.dll
- QtQuick.2/qtquick2plugin.dll
Most of the time, load-time DLLs as placed in the same folder as your executable, because Windows will always search that folder. Technically, load-time DLLs can be placed in a subfolder if that folder is in your PATH. You could, for example, launch a Batch script instead of launching your executable directly. The Batch script could temporarily add the load-time DLLs' folder to the PATH before it launches your executable.
WARNING: Do not permanently add Qt DLLs to your user's system PATH, or you could cause DLL Hell.
Run-time DLLs are the ones that you can configure using qt.conf or by calling a function. If you call
QCoreApplication::addLibraryPath("C:/MyPlugins/");
before you construct your QApplication, then you can have your run-time DLLs in, for example, C:\MyPlugins\platforms\qwindows.dll -
@ScottMichaud said in (Windows) Minimum files in deployment that cannot be moved:
Here is the Windows API that can load DLLs from arbitrary locations.
This link describes how to load libraries at runtime WITHOUT linking against them at linking time - this is not the same...
-
@JKSH said in (Windows) Minimum files in deployment that cannot be moved:
Broadly, there are 2 groups of DLLS:
- Load-time DLLs need to be found by Windows before it launches your app. Examples:
- libstdc++-6.dll (if you used the MinGW compiler)
- Qt5Core.dll
- Run-time DLLs need to be found by your app before it tries to initialize specific features. Examples:
- platforms/qwindows.dll
- QtQuick.2/qtquick2plugin.dll
Most of the time, load-time DLLs as placed in the same folder as your executable, because Windows will always search that folder. Technically, load-time DLLs can be placed in a subfolder if that folder is in your PATH. You could, for example, launch a Batch script instead of launching your executable directly. The Batch script could temporarily add the load-time DLLs' folder to the PATH before it launches your executable.
WARNING: Do not permanently add Qt DLLs to your user's system PATH, or you could cause DLL Hell.
Run-time DLLs are the ones that you can configure using qt.conf or by calling a function. If you call
QCoreApplication::addLibraryPath("C:/MyPlugins/");
before you construct your QApplication, then you can have your run-time DLLs in, for example, C:\MyPlugins\platforms\qwindows.dllThanks! It looks like addLibraryPath() is exactly what I need, but I'll circle back and try qt.conf again in case I was doing something stupid.
@jsulm said in (Windows) Minimum files in deployment that cannot be moved:
@ScottMichaud said in (Windows) Minimum files in deployment that cannot be moved:
Here is the Windows API that can load DLLs from arbitrary locations.
This link describes how to load libraries at runtime WITHOUT linking against them at linking time - this is not the same...
Correct, as I said in the very next sentence of the post you quoted:
@ScottMichaud said in (Windows) Minimum files in deployment that cannot be moved:
@jsulm No. No, that is not true. Here is the Windows API that can load DLLs from arbitrary locations.
The only DLLs that must be in the same directory as my executable (or somewhere else that Windows looks, like on the path environment variable) are the ones that are attached by the linker.
This entire thread was asking which DLLs are runtime-linked, and done so in a configurable way, and what mechanisms exist to move them. I am aware that some of these files could not move. I was asking which ones could (and how).
- Load-time DLLs need to be found by Windows before it launches your app. Examples:
-
Okay so it looks like in my project, I'm able to move every folder that doesn't start with Qt and every dll that doesn't start with Qt5 (unless something subtly broke somewhere that I'm not seeing) by adding...
QCoreApplication::addLibraryPath("./QtMyFolder/");
... to the top of my main function and tossing the rest into QtMyFolder. (I don't actually call it QtMyFolder of course.)
That brings me down to five folders (six if you count the subfolder that I created to hold the others) and eleven files... and they also visually "go together".
Hopefully this will be good enough. I don't really want to do one of the .bat-loads-exe or .exe-loads-dll hacks. :\ They are options, though.
-
Also, no, I'm not going to have the manager blindly modify folders in the parent of its working directory. I'd rather build the manager as a DLL, toss it in a sub-directory, and invoke it from a thin EXE in the main directory.
I do respect that you seem to know what you're doing, but this is a very strange comment to make.
You have a folder,
third-party-game
, containing theexe
for the game, its DLLs, and any sub-folders it might have for its stuff. A bunch of files & folders, which as I understand it you want to be able to modify from your manager app.You are planning to put your manager's
.exe
, plus its DLLs/sub-folders, into that same folder. Which leads to at least some of its files lying around next to the app you plan to manage, which is what you object to.There is absolutely no reason why you shouldn't root your
exe
, plus its DLLs etc., in sub-folderthird-party-game\manager
, rather than inthird-party-folder
. In no way does that interfere with its ability to mange or access files inthird-party-folder
, the parent directory ofmanager
. It is no easier to access/manage files in the same directory as anexe
lives than it is if they are in the parent folder (btw, not necessarily its "working" directory as you wrote). There is nothing "blind" about this, nor is there any need to create a wrappingexe
/bat
etc. Indeed, it is easier to manage for both you & your users if all your app's stuff is it in its own folder downward, precisely so that the game & your stuff do not share a folder where their respective files are mixed together, e.g. when upgrading either app.It doesn't stop you using
addLibraryPath()
either. Just thatQtMyFolder
will be a sub-directory ofthird-party-game\manager
. Whatever files/folders you say you still have not managed to moved out of yourexe
folder will no longer sit next to the third-party'sexe
.If you're happy with what you have now obviously that's fine, but I still don't get why you wouldn't prefer to store your stuff in
third-party-game\manager
even from where you have got to now, especially given your objective.... -
@JonB The manager is not a child of the game folder. The manager is the parent. The game is the child.
The idea is that the user downloads the manager and extracts it to a folder. We'll call that
/Documents/GameManager/
for the sake of argument.They would then run
/Document/GameManager/GameManager.exe
<-- Qt application.In GameManager.exe, there's a button to download and install the game (or update it if there's a new version). GameManager.exe puts it in its folder.
/Documents/GameManager/TheGame/(all of the games files)
The problem is that
/Documents/GameManager/TheGame/
was one of 16 folders (technically 18 because I had two other folders of my own in there) so it was intimidating to some users. Ideally, I'd have the folder structure be:/Documents/GameManager/ManagerFiles/(all the dependencies that Qt and I need)
/Documents/GameManager/TheGame/(all the game's files)
<-- if the game is installed
/Documents/GameManager/GameManager.exe
... but I figured that Qt had some hardcoded (because they're attached by the linker, or because Qt didn't provide a config mechanism, or because a third-party like ANGLE didn't provide a config mechanism) values so I was willing to compromise from that ideal model.
-
@ScottMichaud said in (Windows) Minimum files in deployment that cannot be moved:
/Documents/GameManager/ManagerFiles/(all the dependencies that Qt and I need)
/Documents/GameManager/TheGame/(all the game's files)
<-- if the game is installed
/Documents/GameManager/GameManager.exe
Another possible solution is
/Documents/GameManager/GameManager.exe
/Documents/GameManager/*.dll
/Documents/GameManagerGames/TheGame/
EA Origin uses this structure.
-
@JKSH Yeah that's an option.
Now that you mention it, I could also have the manager put the game in %AppData% and add a button in the manager to open the file explorer to the game folder for people who want to look into it. Honestly, that would be more professional than what I'm doing now.
-
@ScottMichaud
Dear Scott,I've tried all along to convince that you that, whatever the layout of files/folders you want is/might be, just don't place your own
exe
plus its DLLs/sub-directories into the same directory as wherever the third-partyexe
/DLLs/mods are. Doesn't matter so much where either one is a sub-directory of the other, or they are siblings, or they are quite separate. For all sorts of reasons anyway, but especially since you are bothered by their files sitting in the same place and confusing your users. It seems my efforts have been in vain, but @JKSH has somehow hit the sweet spot! It's the right move, good luck! :) -
@JonB said in (Windows) Minimum files in deployment that cannot be moved:
@ScottMichaud
Dear Scott,I've tried all along to convince that you that, whatever the layout of files/folders you want is/might be, just don't place your own
exe
plus its DLLs/sub-directories into the same directory as wherever the third-partyexe
/DLLs/mods are. Doesn't matter so much where either one is a sub-directory of the other, or they are siblings, or they are quite separate. For all sorts of reasons anyway, but especially since you are bothered by their files sitting in the same place and confusing your users. It seems my efforts have been in vain, but @JKSH has somehow hit the sweet spot! It's the right move, good luck! :)I was never going to put the game's exe and dependencies and the manager's exe in the exact same folder. That would be awful. When I said "unpack the game into my manager's main folder" I always meant extracting and placing the game's folder in my manager's main folder. Portable apps are a self-contained folder.
Also, I thought a little bit more and %AppData% won't work because I'd need to support external hard drives and USB keys. I really don't like accessing (especially deleting) folders that are not direct descendants of mine, although it's kind-of the best option short of a bootstrapping (bat-load-Qtexe or exe-load-Qtdll).
(If you've found this thread in the future: loading the same exe that used addLibraryPath() a couple days ago started complaining about platforms/ after turning my computer on the next day, and OpenGL was complaining on a clean Windows Server 2008 R2 VM. I might still have a problem.)