(Windows) Minimum files in deployment that cannot be moved

JonB

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 the exe 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-folder third-party-game\manager, rather than in third-party-folder. In no way does that interfere with its ability to mange or access files in third-party-folder, the parent directory of manager. It is no easier to access/manage files in the same directory as an exe 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 wrapping exe/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 that QtMyFolder will be a sub-directory of third-party-game\manager. Whatever files/folders you say you still have not managed to moved out of your exe folder will no longer sit next to the third-party's exe.

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....

ScottMichaud

@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.

JKSH

@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.

ScottMichaud

@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.

JonB

@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-party exe/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! :)

ScottMichaud

@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-party exe/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.)