*edit* WOW... that is one ugly MANBABY,
Hey guys, I'm new to the forums, but I've been reading this entire thread just now; wanted to give my developer and end-user input:
I think it's great we're trying to make a "generic" updater for others to use for whatever application (program and/or game updates).
I'm going to try to address all of
Cellulose's OP design wishes, as well as those proposed up until this post.
=== Multi-platform Design ===The best way to go about this is have a different updater for each OS.
Not only will the overall file size be smaller, but less prone to bugs/issues/resigns if future OS structure designs change.
Would also be kind of dumb, if I had to update my updater, because a new MacOS/Linux came out,when I'm using Windows.
=== Minimal Design ... Necessary Files ===If we're talking about the core files, we'll need:
1) Launcher.exe
2) Config.ini (whatever extension)
The reason we need a config file, is because we never know if/when the client needs to change the http address, or whatever. If you don't want users to tamper with it, you can keep the file hidden during launch so that only the developers know about it.
The Config file should also contain the last update version.
The file update list (manifest) should be downloaded from the server, and later deleted after update is complete.
The program name and those kind of details need to be edited by the developers before they build the solution.
Icons can be built into the binary file, so no need for (.ico) files.
As far as staying invisible after finishing updates...
Option 1:
The updater should be the parent process, stay launched in an IDLE state, and launch the program in question as a child process. The developer will be responsible for proving the launcher an "exit exception", so the launcher knows the main program ended, and it too needs to close.
Option 2:
The updater should be the parent process, launch the program in question as another parent process, then close itself. (
I THINK this option is possible...)
=== Archives / File Compression ===For a FREE one... I too believe (.zip) files are the way to go. They are universal across all platforms, are archives, as well as file compressors. You can also password encrypt the files, in case you believe they should be... though I see no reason to do so.
=== Launcher & Installer (combined) proposal ===This was a discussion early in April, but)I believe there should be 3 completely different modules to this entire project idea:
1) Game exe
2) Launcher exe
3) Install/Uninstall exe
The reason I believe the launcher and installer should be separate, is because not all program developers may like the installer we provide.
If anything, the launcher should have an "
Uninstall Button", and nothing more.
What type of uninstaller the developer chooses (custom or standard) is up to them.
This keeps the entire design concept more modular, less prone to bugs, and smaller in size.
Less work on our end, and gives us a broader client base if this open source patcher/updater is launched.
=== Client / Server updater (http) ===I just saw your program
technogothica... great work!
I too believe the MD5 checksum IS the way to go in terms of checking for data integrity when patching files.
I also agree that writing the update list (manifest) in XML would be better than standard Text format. I too experienced the same issues technogothica had in the past with standard text files.
XML files may be larger (not by a lot), is well used in today's industry, and IS robust enough for this situation.
There was also talk earlier about keeping the command line on the server end... I honestly think that is a bad idea, unless you're making a browser based game, or a game that requires connection to the website to launch; which is very client specific (small client base). The thing would break if offline.
=== Auto Updater? ===The updater should ONLY be launched when the user wants to launch the program.
I honestly HATE those auto updaters that run in the background or at startup 24/7. I also edit my registry and disable those evil things.
Now, about the auto updates...
Instead of always checking for updates and auto updating, I think we should give the developer (not client) "options" to allow this "feature" or not. (IE. Firefox auto updates features).
The developer may want to force an auto update (like MMORPG games), make it periodical optional (like browsers), or completely optional (offline programs in which the client/user has to force an update).
=== Update Directories (folders) & User Security Issues ===These are the toughest questions...
I understand that
Cellulose doesn't want to have an updater that deals with the varying file directory structures, as well as deal with user security levels.
The "easiest" solution, is to allow the developer to make their product, include the updater program in their INSTALLER, and let the installer modify the registry to allow all users to access the updater / files.
That way, there are no issues with the updater having to deal with user permissions when adding/removing files.
However, if the developer has no installer, and the product they have is only a few binary files, but still requires access to an updater... now we have problems.
This is more of a client/developer issue, because they will be 2 completely separate programs with no common directory. Actually, nothing we can do about this problem.
The (end-user) will need to copy all the files where the UPDATER developers mandate the files to go for everything to work properly, not the actual client/program-developers.
=== GUIs ===This is completely in the air...
Most game developers want a "nice looking" updater with a lot of "bling bling", so their clients can see/do something during the updates, and not be stuck staring at a boring progress bar.
Commercial programs on the other hand are looking for more professional (streamlined) updaters that use as little memory/space as possible.
We could give the client here, again, the option for a simple progress bar, or a fancy GUI they can customize.
Unfortunately, this means more coding, and a much larger binary file... even if the client wants a simple updater.
I know
Cellulose said he wanted this updater to be as small and lean as possible, but let's be honest... updaters are NOT that large in file size, and 1-2MB extra due to a better GUI option won't hurt. I honestly believe giving the client 2 options (advanced graphic GUI / simple progress bar and cancel button) is the best way to go if you want the broadest client base.
It's not like we're making something for a mobile device where very BYTE counts.
==============================================
I think that's all the major points I wanted to address.
If there are a few I missed, I'll make another post.
Oh... is there anything I can do left?
I think
technogothica pretty much finished the first Alpha of this updater.
I'm not fluent enough with Linux OSes, and nothing for MacOS.