Creating Auto-Update program.

So I'm trying to create a generic auto-updating program that I can use in any future game/app.

An auto-update program must use 5 main steps. I've already completed the first 3, just need help with number 4.

1. Check a server for version information.
2. Determine if version on server is more recent.
3. If more recent, download software update file.
4. Install update file to replace current version.
5. Close and re-open the application to run new version.

So, my application has the version check and download working just fine... I'm just not sure how to actually install the new update to overwrite the current application.

Currently, the program is stored in a ZIP archive on my server. The application downloads this ZIP to the app-path. Now I'm trying to use the ZIP object to unzip it, but I can't figure out how it works at all.

I know there has got to be a better method as well. Is there any way that I could create a patch file that would be downloaded instead? (So that a user doesn't have to download the whole program every time)

What are some other methods of software updating. I want the process to be fairly automatic.

Oh one more question.
Currently the application checks for new software automatically at the start of the application. But I was wondering if there is a way to make it only run these events every 48 hours or so. I don't want it making requests to my server every time the user closes and opens the program.

I need something that will not allow the actions to repeat until 48 hours have passed, even when the program has been closed and opened dozens of times. I'd probably use an INI file for the time storage. But is there a way to convert dates to an integer that can be easily compared mathematically?

I created a similar update system into one of my old applications.

Unfortunately I found that when the updater unzipped and replaced the main program .exe, my virus software would identify this as suspicious activity and would block the program from executing.

The solution I though of (but never tried) could be to have the program download a patcher and to invoke administrator rights when it's run.

That 48 hours thing had me thinking of, you should just have the program tell you about an update maybe once a week if there's one available.

Similar to how iTunes does it. "Will check for update on X/X/XXXX"

Of course, there's never a guarantee that the user will have the program open on that specific day. Maybe a couple checks a week? Or you can always opt-out of auto update, then just put a "Check for Update" button somewhere on it?

Yeah, thats basically what I had in mind. My idea was to have an option to "Check for updates every X hours" with the minimum value being 48. Or maybe even just set it to days, with the minimum as 2.

But it won't check on a specific date that would require you to be on. It'd just compare the last update to the current date (as an integer) and if x > 2, it would run a single update routine.

This way it runs only AT LEAST once every 2 days, only when you start the program.

Rather than checking for a specific date, in which case the application must be run on that date, why not check to see if a specific date has passed.

In other words, if I check for an update today, then the application would set the update flag to tomorrow's date. If that date has been passed the next time the application is run, then the updates will be checked again.

That sounds like a good idea. I'm guessing I could do this with the Calander object.

But doing the update check isn't really my issue at the moment. I'm trying to figure out how exactly to run the installation process -- How to actually make App v1.0 turn into App v2.0 automatically.

Right now it works like this:

• There are 3 files on my server: App_v1.zip, App_v2.zip, and version.ini.
• For the purpose of the Auto-Update test, it is assumed that the user has App_v1.zip unzipped onto their hard disk somewhere.
• User unzips App_v1.zip, and runs App.exe contained within (the full version 1 build of an MMF2 application).
• App.exe (v1) looks for update in file "version.ini" on sever via the GET object, and finds v2 text available.
• App.exe downloads App_v2.zip from a string contained within "version.ini".
• App_v2.zip is downloaded to the AppPath$ of App.exe -- saved as "NEW_VER.zip"
• ???

I don't know what to do next.
App_v2.zip (AKA "NEW_VER.zip") contains a new full version of App.exe, with more features. It seems kind of redundant to have to re-install the whole application though. I want to use some sort of patch file but don't know how to do this within MMF2.

Also, I can't seem to get the ZIP object to work at all. So currently it downloads the ZIP to the application path, and the user has to extract the App.exe from within and replace it manually. Not very intuitive.

I want my App to be able to do this all automatically.

Usually a "patch" is just the updated exe... Actually I can't really recall a time when the "patch" was a separate file that somehow merged itself into the old exe. Games that uses patches usually have smaller exes and store most all of the content stuff in external folders... this way if there is a change to just a few graphics or new additional graphics, those are just copied over into the game folder and replace old files. This keeps the exe smaller and quicker to download new versions and replace it.

I don't have any experience with any unzipping in MMF, but I would imagine it is pretty straightforward.

Also, I don't know if you set it up like this, but you're gonna need to have the patcher/auto updater be a separate program from your main app... Otherwise it won't be able to replace the app with a new version since it is currently running. This is why so many games have "launchers" because the player runs the launcher, it checks for updates, patches the main exe, and then either lets the user click "launch game" or just launches the game instantly and closes the launcher.

Because yeah... an app can't replace itself while it is running. :p

Quote:

---

Originally Posted by Konidias

Usually a "patch" is just the updated exe... Actually I can't really recall a time when the "patch" was a separate file that somehow merged itself into the old exe.

---

Patches are usually only small data files that tell the program to replace/add certain binary data within the EXE, as opposed to downloading the entire EXE again. This is a method to save bandwidth for large programs needing only minor fixes.

Here's an example I can think of: Imagine if a program like Photoshop released a new version in which they made a typo. The menu bar said "flies" instead of "File" just under the title. Oops!

Instead of sending you a new 800mb EXE file to fix a single typo, they can just send a patch file.

The patch will only be a few bytes containing this information:
1. The memory address to be changed (at the location where the text "flies" is stored).
2. The data to be replaced/inserted at that address (replace "flies" with "File")

The updater application will search the memory address of the Photoshop EXE where "flies" is stored and change it to "File".

A simple 4kb fix for an 800mb program. But of course with large changes the files will be larger. The Patch file should only contain NEW binary data to be changed for the EXE, and the locations of where to change it. This is why patch files themselves can not be run as executables, because they don't contain all of the commands to run as such!

But in our modern auto-updating age, you usually don't get the privilege to patch EXEs manually like we used to. The patch files are usually downloaded automatically to a local folder, then patched to program, then deleted from your hard drive for you. You never actually touch the file yourself.

Quote:

---

...but you're gonna need to have the patcher/auto updater be a separate program from your main app...

Because yeah... an app can't replace itself while it is running. :p

---

I could have the same EXE overwrite itself within the application. Then just have a screen that says, "The changes of the update patch won't take effect until you close/restart the application. Would you like to exit now?"

While the application is open, Windows should be able to keep it in memory. This is how Firefox works, I believe. I don't know how this works exactly, but I may just make a separate installer like you said. It would probably be easier.

Can you have the updater as a separate program?
Main App runs updater utility to check for new version
If Updater utility detects an update, it closes Main App and downloads the update
Updater utility then replaces the needed files
Updater utility runs updated Main App, and closes itself.

That's how I have mine set up, and gets around the issue of updating a file already in use.

If you want to check for updates for the updater itself, set that check in the Main App.

Alternatively, If you have Install Creator (Pro?), you can make an installer for the update, and then your steps would be:
1) Check for update, if found download
2) run update & close app
3) update installer does its thing, and runs Main App at the end

I'm not sure if I understand...

You're saying to have the user open the Main Application, which will call the Updater application to open. Then it will determine if it needs to do any updating... Instead of having the user open the Updater app which simply calls the Main Application when its done.

Yeah, I could actually do that pretty easy with sup-apps. That's a good idea.

I think I've got most of this figured out. Everything is working now, including the unzipping part. But the ZIP object isn't responding properly. I'm having problems checking its state. The event condition "File Unzipped Successfully" never triggers!

My events are like this:

Code:

---

User presses "Update Button"
 = Open "test.zip"
 = unzip to "some file path"

---

This event work just fine.
The files unzip in the proper location, but the event that tells me its complete never triggers.

Code:

---

File is unzipped Sucessfully
 = End Application.

---

What should happen is, when the files are done being unzipped, the application closes... But it never does! The files have absolutely been unzipped, so its not possible that the condition isn't met. I've been trying for a while now, and this event will not trigger no matter what I do. Whats wrong with it?

I also noticed that the ZIP object conditions "Is Zip Open" and any of the error conditions also seem to just be ignored. They never trigger, even if an error is found or the ZIP is indeed open.

I need to know when the zip is done unzipping so that I can have it finish the updating process.

Use Archive Object. Zip Object is obsolete.

I didn't even have the Archive object. I'll try it out.

EDIT: The Archive object was perfect. Everything works flawlessly. When I get everything complied together I'll see if I can release my auto-updater to the public.

Thanks to everyone who helped.

Ok, so I finally got everything figured out. I just need to test my update system. Could I get a few volunteers?

You can download my Auto-Update Test application here:
http://www.crimsontheory.byethost6.com/downloads/hilo_v1-5.zip

If you choose to test this application for me, please follow these instructions:

• Extact the files to any location of your choosing.
• Run the "HiRez LoRez.exe"
• You should see a purple screen with a logo, some options and buttons.
• Please notice the box in the lower-right corner. It should say "version 1.5" somewhere.
• Check the box "Use Auto Update"
• Now close the application.(so that auto-update can run itself on the next open)
• Run "HiRez LoRez.exe" again.
• This time you should be taken to an update screen. It will alert you that "A newer version is available."
• Click the "Download" button.
• A new window should open that downloads the new version.
• When it is done, click the "Finish" button. The "HiRez LoRez.exe" should run itself.
• This time, you should notice that the screen is white and the logo inverted. Also notice that the version in the corner says "2.1" now. Congratulations, you just downloaded a new application automatically!
• Click the "Check for Updates" button.
• It should alert you that "Your version is up to date."
• All testing is done, please close the program and delete it from your computer. You won't need any of it anymore.
• This program also uses the windows "Application Data" folder to store some data. You will want to navigate to this directory and delete the app data too. It will be in a folder called ""HiRez LoRez". You can safely delete the whole folder.
• Report back here with the results!

So, did everything work as expected? Did the new version install itself, then run itself? Did the auto update feature work? Please tell me if there were any problems.

Also, please tell me what version of Windows you are running. Tell me which Windows OS you have even if it worked... I want to confirm that it works universally.

If everything works, and I can get it integrated into my current programs, then I might release the source for everyone to use.

I've got to get some sleep right now, I'll check back here tomorrow morning.

Anyone try it yet?

I really just need a few people to test out the program. It'll only take a minute.

I need to know that it works on many different kinds of computers, OS, etc.

The download bar gets about 85% done and then it crashes:

Problem signature:
Problem Event Name: BEX
Application Name: stdrt.exe
Application Version: 3.0.251.1
Application Timestamp: 4d3ed929
Fault Module Name: Archive.mfx
Fault Module Version: 1.0.0.0
Fault Module Timestamp: 4c589ff7
Exception Offset: 000036a3
Exception Code: c0000409
Exception Data: 00000000
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 1033
Additional Information 1: 94fe
Additional Information 2: 94fe5584424cb349da3b9b6db7cb8ee8
Additional Information 3: c0b2
Additional Information 4: c0b2c9752fc55f22a231f2107d3a5fe4

edit: oh and I'm running windows 7

Oh man. I expected some issues, but nothing like that!
Hmm... I can't make heads or tails of that error code. All I can really get out of it is that the Archive object is involved.

Ok, I think I might have an idea. I was having an issue like this before, but I had fixed it. The ZIP file that gets automatically downloaded contains 2 files: HiRez LoRez.exe, and and HiLo Updater.exe.

What caused the problem was that the Updater.exe would try to replace itself when it was running. I fixed this by having the Updater.exe DELETE the new Updater.exe from the ZIP before unzipping.

If you are getting an error, its possible that Updater.exe isn't being removed properly.

Could you do something for me? If you didn't delete your files already, could you go to your "Application Data\HiRez LoRez" folder? Within it should be a file called "new.zip". Can you open it manually and tell me what files are inside? (don't need to unzip them)

It should only contain "HiRez LoRez.exe"

If there is anything else, then I may have an idea where it went wrong.

If you did delete it all already, could you re-download and run the program again to recreate the error? (It doesn't happen on my end)
Just follow the steps above please.

Thank you for your cooperation so far!

Oh, one more thing. After the application crashed, did you happen to re-run it again? If so, what version number did it show in the corner? If it was 1.5, then the program failed to update. If it was 2.1, then it did indeed update.

I was having trouble before where it crashed right after updating, but still managed to update.

I opened the zip. It contained only the HiReze LoRez.exe file

I did run the program again, and it showed that it was still 1.5

edit: Though I'm kind of curious why you have the updater replacing itself... I would think that the updater would never really need updated... It would just snag version info from some place and then download and overwrite the actual game exe and not itself. Hence the whole reason for having the updater separate from the application, so that you don't have to worry about the updater trying to replace itself while it's still running.

Quote:

---

Originally Posted by Konidias

I opened the zip. It contained only the HiReze LoRez.exe file

I did run the program again, and it showed that it was still 1.5

---

Hmmm. Thats odd. So what that means is that the ZIP was opened, the update was purged from the program, but the main EXE wasn't copied over... You said that it crashed at about 85%? Thats odd... It shouldn't be accessing the ZIP file until 100% download. Maybe it crashed because it tried to open the ZIP too early. I might have to include a timer function of some sort to delay the opening of the Archive.

Quote:

---

Originally Posted by Konidias

edit: Though I'm kind of curious why you have the updater replacing itself... I would think that the updater would never really need updated... It would just snag version info from some place and then download and overwrite the actual game exe and not itself. Hence the whole reason for having the updater separate from the application, so that you don't have to worry about the updater trying to replace itself while it's still running.

---

That's exactly the point, yes. The Updater was only replacing itself before I fixed the glitch. I thought about this myself, too. I was almost about to release the program, when I noticed that the ZIP on my server didn't include the "Updater.exe"... I thought to myself, "Oh...well how are they going to use my Updater if my computer has the only copy!" So I had to include it in some way in the ZIP so that new users would have it.

See, there are two versions of the program on my website: Version 1.5, and Version 2.1. Each of these are contained within a ZIP archive (for compression).

- Say if, for example, the last version was 1.5, but I just released version 2.1.
- Any of my users who have 1.5 will receive 2.1 automatically.
- But what about people who download the version 2.1 manually from my site (and they never had 1.5 or earlier).
- If they download manually, they need a copy of "Updater.exe" (since they don't have it) within their ZIP file, so they can perform future updates automatically.
- But user's who receive the new version ZIP don't need another "Updater.exe"

Your Method:
- What you are proposing is that I have 2 ZIP files: One that contains everything including "Updater.exe" for manual downloads, and one that contains everything but "Updater.exe" for those who already have it.
- That would mean I'd have to maintain two ZIP archives for each new version. That leaves room for twice as many human errors on my part.
- During transitional periods between versions, I'd likely need to keep the older version on the site. That means I'd have 4 or more ZIP files to track for just one program. And if I plan on making more programs, that's another 2 for each new version there.
- This method you propose isn't a bad one. It costs extra hosting space to have 2 (nearly identical) ZIPS on my server. Also its harder to maintain. The benefit though, is that it saves bandwidth usage (since Auto Updater users don't have to download the extra bulky "Updater.exe")

My Method:
- The option I have chosen is different. There is only ONE new ZIP archive for the new version. It includes all necessary files (including "Updater.exe") for the program to run (for those who manually download for the first time).
- When a user updates internally from the "Updater.exe" program, it will download this same ZIP archive. It will then open it, throw away the new "Updater.exe" (so as to not replace it while open), then extract all remaining files within.
- This method makes it so that I only have to maintain this 1 single ZIP file. That way I don't have inconsistencies with each "version" (say for example that I accidentally left out an important file in the "Manual" download ZIP, but not in the "Auto" one. Now I get only half my user's saying their program won't work, and I don't know why!) The cost is that the user's have to use the extra bandwidth to download this unnecessary file. But its not so bad, because I delete it for them through the program itself, so they won't even know they got it.

- Alternatively, I could have each version come with all files except "Updater.exe", then just have a separate manual download for the Updater.
- But, this brings a problem -- what if a potential user doesn't see this link, and skips over the Updater.zip download? Now they will never be able to receive new updates!

So its really a battle between whether you want to save disk space or bandwidth. I chose disk space only because its easier to maintain fewer files.

Quote:

---

Originally Posted by Konidias

Problem signature:
Problem Event Name: BEX
Application Name: stdrt.exe
Application Version: 3.0.251.1
Application Timestamp: 4d3ed929
Fault Module Name: Archive.mfx
Fault Module Version: 1.0.0.0
Fault Module Timestamp: 4c589ff7
Exception Offset: 000036a3
Exception Code: c0000409
Exception Data: 00000000
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 1033
Additional Information 1: 94fe
Additional Information 2: 94fe5584424cb349da3b9b6db7cb8ee8
Additional Information 3: c0b2
Additional Information 4: c0b2c9752fc55f22a231f2107d3a5fe4

---

You are attempting to access a file that is not available with Archive object.

Thanks for the info on the error, StephenL! But what exactly does that mean?

Surely the file should be available (it works fine on my Windows XP machine).

- By "not available" does that mean the file is in use by another program?
- Or does it mean that the file doesn't exist/can't be found?
- Or does it mean that the file isn't a recognized Archive file? (the file in question is a "WinRAR ZIP archive" so it should be standard).

Is there any way you can tell me more specifically what the error means? Or is that about all the information you can get from it?

Thanks StephenL and Konidias. You've been great help so far. I appreciate it.

It either means the file is being used by something and cant be accessed, or the file does not exist.

You've been great help Konidias, but can I ask one more thing of you?

I create a possible fix. If the problem is the ZIP is being opened "too soon," I have created a 3 second delay within the program to prevent this.

You should see a small counter count up to 100 after the download now. When it reaches 100, only then will it attempt to unzip the archive.

If you could, please, can you tell me if it works now?
The link is still:
http://www.crimsontheory.byethost6.com/downloads/hilo_v1-5.zip

Okay, now it completes the download. It says "Decompressing Archive" and gets to 99 and then it crashes:

Problem signature:
Problem Event Name: BEX
Application Name: stdrt.exe
Application Version: 3.0.251.1
Application Timestamp: 4d3ed929
Fault Module Name: Archive.mfx
Fault Module Version: 1.0.0.0
Fault Module Timestamp: 4c589ff7
Exception Offset: 000036a3
Exception Code: c0000409
Exception Data: 00000000
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 1033
Additional Information 1: d72e
Additional Information 2: d72e0f6f7e2ddf63c2f0034df7874549
Additional Information 3: 663d
Additional Information 4: 663dd05bf9372edd0e2e5b558e2b63de

Quote:

---

Originally Posted by StephenL

It either means the file is being used by something and cant be accessed, or the file does not exist.

---

Ok, thank you. Well the file surely does exist (because Konidias said it was there). So that must mean that the file is being accessed by something else.

I implemented a possible fix for this by making a delay, can anyone verify that it works? (link is in above post)

If that doesn't work, I'll have to some how check whether the file is free.

I have to question why you are having the user manually download anything aside from the updater.

The way I've set up my game is that it has a Launcher (which doubles as an updater)

All the user downloads manually is this launcher from the website. When they run the launcher, it checks for what version of the game the player has (in this case, they have none, since it's not installed yet) then it downloads the latest version and once it's installed, the launcher unlocks the Start button. The player clicks Start, the launcher opens the game.exe and then the launcher closes.

Every time the player wants to play the game, they just run the launcher. If there's no update needed, they just click the start button and launch the game. There can even be an option to auto-start if no update is required or once updates are complete. That way it's no different than opening the game.exe directly.

The launcher also doubles as a news and updates display if you want to do that.

This way, the launcher.exe is totally separate from everything else. The player only ever manually downloads the launcher one time. That's it. From there, the launcher is automatically downloading any other stuff for the game (and the game itself)

I see that you've considered this but you're saying:

"- But, this brings a problem -- what if a potential user doesn't see this link, and skips over the Updater.zip download? Now they will never be able to receive new updates!"

It's not a problem if you don't give the user any other downloads aside from the launcher. Don't let them download the game directly from the site. There's no need for that.

Quote:

---

Originally Posted by Konidias

I have to question why you are having the user manually download anything aside from the updater.

The way I've set up my game is that it has a Launcher (which doubles as an updater)

All the user downloads manually is this launcher from the website. When they run the launcher, it checks for what version of the game the player has (in this case, they have none, since it's not installed yet) then it downloads the latest version and once it's installed, the launcher unlocks the Start button. The player clicks Start, the launcher opens the game.exe and then the launcher closes.

---

I see what you saying, but my Updater isn't designed for a Game, but instead an art application. Usually these sort of things don't have a pre-launcher like that (that I'm aware of).

There is another problem with this method:
You say that it checks which version you have (none) and then downloads game.exe. This assumes one of 2 things: 1) your Launcher.exe contains some sort of web link string (http) to the location of where to check for updates. 2) The link is stored in a string within an INI file locally, and Launcher.exe checks this file.

The problem with method 1) is this: if the link to your website is hard coded into the updater, what happens if you must change hosting locations in the future? How will you "update the updater" in this case, so that the Launcher.exe knows where to check for version info?

if your suggestion is to use an external INI file to store the link and version info, this would be method 2) which has a HUGE security risk: what if a malicious user opened this file, replaced the link within to their own website (which would give a 'false update'). Then, they could use this to have your application download some virus or malware.

Quote:

---

Originally Posted by Konidias

Every time the player wants to play the game, they just run the launcher. If there's no update needed, they just click the start button and launch the game. There can even be an option to auto-start if no update is required or once updates are complete. That way it's no different than opening the game.exe directly.

The launcher also doubles as a news and updates display if you want to do that.

This way, the launcher.exe is totally separate from everything else. The player only ever manually downloads the launcher one time. That's it. From there, the launcher is automatically downloading any other stuff for the game (and the game itself)

---

Ok, I see the benefits of what you are saying here, but it still leaves my problem:

[size:14pt]I don't want to store version info on the user's machine within an INI file.[/size] [color:#FF0000]It is a huge security risk[/color]. Now, here you could say to "use encryption", but encryption can be decoded easily by many novice hackers. I have instead chosen to hard-code the information into the Alterable Values of an internal object within the App.exe. This way it would be much harder for a malicious user to be able to change the info for version and download location. Its generally harder (from what I understand) to find specific variables within the binaries of an executable.

In my application, the App.exe does the version checking and sends the download link (which it checks MY server for) to the Updater.exe. This way the Updater.exe never actually stores any sort of version information. All it does is check to see whether the info it receives from the App.exe is valid, then downloads and extracts the new version.

So if the Updater isn't going to use external data (like ini or array), then the version info must be hard-coded into the Updater.exe (your Launcher.exe).

If this is the case, how do you change this information to reflect your new local versions within the Updater.exe? This brings up the problem I stated above:
[size:14pt]How do you Update the Updater?[/size]

My current method has the versions hard-coded into the App.exe, with each new version having the new version info hard-coded into it.

I'm curious to know what your solutions are to these security issues. Because I couldn't find a way around it -- that's why I used this method. If you know something, please tell!

Quote:

---

Originally Posted by Konidias

Okay, now it completes the download. It says "Decompressing Archive" and gets to 99 and then it crashes:

---

Huh, this is a problem indeed! The counter is just that -- a counter. When the download completes, this counter starts adding 1 to itself until it reaches 100 (takes just over 3 seconds). This timer doesn't do anything, its just a delay. When it reaches 100, it then stops, opens the archive, removes the updater, then extracts the rest.

If the program is crashing for you at 99, it means the problem is definitely within the event in which the archive is extracted. And the error report you gave me is the same as before, the only lines that were different were the Additional Information 1-4:

Quote:

---

Originally Posted by Konidias

Problem signature: (last time)
Additional Information 1: 94fe
Additional Information 2: 94fe5584424cb349da3b9b6db7cb8ee8
Additional Information 3: c0b2
Additional Information 4: c0b2c9752fc55f22a231f2107d3a5fe4

Problem signature: (this time)
Additional Information 1: d72e
Additional Information 2: d72e0f6f7e2ddf63c2f0034df7874549
Additional Information 3: 663d
Additional Information 4: 663dd05bf9372edd0e2e5b558e2b63de

---

But honestly, I don't know what this means. I'm not an extension developer.

Here is a picture of the code I described above. This is code from the "Updater.exe". Maybe someone can spot something I missed, or am doing wrong: (its kind of a big image, you may have to expand it)
http://www.deviantart.com/download/2...in-d46hb3p.png

Quote:

---

The problem with method 1) is this: if the link to your website is hard coded into the updater, what happens if you must change hosting locations in the future? How will you "update the updater" in this case, so that the Launcher.exe knows where to check for version info?

---

Just set it to a domain name. Then if you ever need to change hosts/servers or whatever, you can change the address linked to that domain but the domain will always remain the same even if you change servers a hundred times. It's not even a question of money because domain names are so dirt cheap nowadays that you can get one for the price of a lunch. (cheaper even)

It doesn't even have to be any special domain name... it can be totally random since it's just being used as a permanent link in your updater.

You really should never have to update the updater.

Your solution doesn't fix your problem anyway. Say Updater v1.0 was looking at web address 1.2.3.4 but a year from then, you had to change to web address 4.3.2.1

Anyone with the v1.0 updater won't be able to update to the newest version anyway.

But if your Updater v1.0 was looking at web address domain.com, and a year from then, you change hosts and redirect domain.com to the new host, then the Updater would still be able to download the latest updates. :)

I see your point here. The domain name would fix this issue regardless of hosting service.

The domain name could be hard-coded into Updater.exe, while the version number could be stored in an INI. The user could "hack" the ini to change the version number if they wanted, but what benefit would that give them? (none)
So security shouldn't be an issue.

I've been using free hosts for years, so a domain never crossed my mind. Because of this, I never thought of an internet address as ever being "permanent" like this before. Thanks for the suggestion.

I finally understand what you are getting at. It seems I was wrong. It looks like I'll be doing some more code re-arranging. The way I have everything set up, it shouldn't be a hard change.

If anyone still has any information about the obscure crash error above, please post. Because that part of my code should work fine, and won't be changing in the new edition. So its still an issue.