Dispatcher Devlog

[Code6226]

So yes, Dispatcher now features Stats Reporting, which means you can give it a URL of yours, and it will POST to it when users update. See here: http://www.puchisoft.com/Dispatcher/Man ... anced.html

Also, you can now have a whitelist of users who may receive your updates, which is good if you have software you are selling. You must set this up via Web Authentication yourself, but the Updater will fully support it. See: http://www.puchisoft.com/Dispatcher/Man ... ation.html

[Code6226]

[Updater]
-Title now says "YOUR_SOFTWARE Updater YOUR_VERSION", rather than Dispatcher's version
-Free/Pro: Screen Log now gives version of Dispatcher
-Corp: No mention of Dispatcher's version (If you wanted to check which version it is, you could delete the Updater.dat and then run Updater.exe)
[Manual]
-Added info on Changing Updater's Left-Side Image
-Explicitly noted that both /AddVersion params must be included for command-line way for adding a version

[Code6226]

Just added a pretty cool feature that I call "Inflate". With it, you can inflate a project just from it's MirrorURL+ExtensionMask.

So instead of installing a version of your software with the Updater.exe and Updater.dat, you could just create an empty folder and put the Updater.exe into it. Then call something like: Updater.exe -inflate http://example.com/Up/MySoft/.zip

The Updater will then inflate the entire project whose Update Data is hosted at http://example.com/Up/MySoft

Of course, this will not work for projects who have Allow File Recovery turned off.

Even the Updater.exe will update(or downdate) itself to be the exact Updater.exe that this project currently uses, for compatibility.

[Code6226]

After working on fixing the issue of pop-up windows stealing focus yesterday, and nearly all day today, I have come up with a pretty elegant solution.

Basically, I decided to create a new helper program, the "Dispatcher Release Log". This is what I always wanted Dispatcher to have but couldn't previously think of how to get accomplished effectively, and more.

When you release your program, in Full or just the Update, you used to have the main Dispatcher GUI freeze, and you would see many Compiler pop-ups, each of which just had a status text.
Now, the Dispatcher GUI window hides, and the Release Log pops up, if it's not already running. You can then watch progress with a history log. This fixes the issue of the Compiler.exe stealing focus, and is great if you are just releasing one project.

But what if you are, as some users claim to be, releasing a chain of over 15 projects with Dispatcher at a time?
The Release Log never closes. The rest of Dispatcher just keeps communicating with it while it's open. If you were to leave it open after successfully releasing one project, and then move on to the next, it would simply keep at it.

All I had to do at this point was prevent the main Dispatcher GUI from showing up when using an ACTION parameter to automatically release a project.

So if you batch release your software with Dispatcher, the first time you run Dispatcher, the Release Log will pop up, and that's it. For the rest of the time, the same Release Log window is used to keep you updated on the progress.

Right now I have the Release Log being Always On Top, but you can of course minimize it to get it out of the way.

The new version of Dispatcher is being released as I write this, so look forward to updating to it soon.

[Code6226]

I am just in the process of releasing a new version of Dispatcher. The biggest thing for this update is organization and clarity.

I've reorganized the Manual's Menu tree a bit, and touched up the website.

For the actual software, the biggest change you will notice is that selected tabs are in bold now (making it easy to see which one is open), and that Minimum Days Between Update Checks is now under Advanced rather than Updater, which allowed the top-left section of the Updater tab to be renamed to "Appearance" from the cryptic "Misc".

[Code6226]

New version being released!

This fixes the issue that was reported 2 days ago, where if you supply an FTP-Upload URL with an @ in the Username, it won't work. The problem was that in URLs, you are suppose to replace @s in the username with %40.

Firefox doesn't make users do this, and rightfully so.

cURL is what Dispatcher uses to upload files via FTP. I reported the bug, and they prompted explained that you are suppose to use %40.

Well, I wanted my users to be able to use either %40 or @, so Dispatcher now automatically fixes user-entered URLs that use the @ in a username without having manually replaced it with %40, and replaces it for the user, transparently behind-the-scenes, before passing the URL onto cURL.

I don't know if the cURL people will add this feature too, but the Firefox people have, and Dispatcher has followed in their footsteps for the sake of a great user experience.

[Code6226]

Just in the process of releasing a new version!

Many slight changes, nothing major. Notably, this update fixes an issue where Windows 7 would spam you with Compatibility pop-ups while the Compiler was compressing your updates with LZMA. For you, the developer, this has now been fixed by upgrading the bundled LZMA. This never effected users of your Updaters.

I'm also hoping to add support for changing the Updater's message strings to add support for other languages soon.

[Code6226]

A new version is about to be released. This one features the long-awaited ability to customize most texts in the Updater, for the purpose of changing the Language, or whatever non-sense you wish.

Example of non-sense that you can now do:


It also features another requested feature: that the Installer will by default now include a Start Menu link to the Updater, as "MyProject - Check for Updates". So even if you don't feel like letting the user run the Updater.exe from you main program exe, the user can still run the Updater from the Start Menu. Old projects have this setting off to maintain how things were before (but you can turn it on in Installer Configuration in the Release tab).

This release only comes with 1 preset language (English). I'd really appreciate it if someone could submit their customized Language.inis for other languages (especially those of you who are already planning to do just that for their own projects). I'd be happy to give you a discount on purchasing Dispatcher, if you submit a well-done Language file.

[Code6226]

Coming soon: Check for updates without requiring Admin rights.

I'm amazed nobody requested this feature. Once I thought of it, it's so obvious. The Updater.exe shouldn't require Admin rights to check for new versions. It's never effected most of my software, since they all need admin rights of themselves. However, if you have a game, for example: Games shouldn't require Admin rights to run, so the Updater should need admin rights just to check for updates.

So coming soon, you will be able to check for updates with your user-level game without requiring the user to escalate to admin-level. Of course: doing the actual update, like doing the actual install, will require admin rights. The user will just be asked to give admin-rights once they are needed.

[Code6226]

Just released a new version, codenamed "Proper UAC Support".

I know I say this every time, but this update is pretty sweet! ^_^

The Updater no longer requires Admin Rights to check for updates. Only after updates are found, and if the users says he wants to update, does the Updater check if it needs elevated rights. If it does, it will prompt the user to elevate them via UAC on Windows 7/Vista. On XP everyone runs as Admin by default, so XP users will probably not notice anything different about this new Updater.
However, if a user is a Limited User on Windows XP, the error message when he tries to update will now be something like "You need Admin" versus "You need write access to folder X", which should be more user-friendly.

The huge feature I didn't even think about implementing until today is this though: I added a new Installer default called "Basic-NonAdmin". This thing does the same thing that the Google Chrome installer does to let Limited Users install their software: Install your software into AppData rather than ProgramFiles. It's all transparent to the user.

Also, if you install your software (and, of course, the Updater) like this, the Updater won't ever need Admin rights either! So just by changing your Installer default from "Basic" to "Basic-NonAdmin", you can let Limited Users install and update your software without them ever needing admin rights! Some considering it a bad form to bypass the operating systems security like this, but if Google Chrome does it, why shouldn't you?

[Code6226]

The question was raised if Dispatcher could handle big file sizes, about 1 GB in size. Well, my test programs weren't that big, and I couldn't think of any huge files I had on my hard drive, of which I possessed multiple slightly varied versions.

So instead, I took my already existing test Application, both with its version 1 and version 2, and increased the EXE's file size dramatically. How? Thanks to this little program:



Adding 1MB takes about 1 Minute, so I can only assume that adding 1GB will take ...oh oh... 16 hours!

Not impossible, but not my first choice. Back to the drawing board.

Update1:
So, I have now taken v1 of MySoftware.exe [700kb], and generated a patch to v2 of MySoftware.exe, inflated to [371MB]. So that's theoretically at 370MB addition between v1, and v2. However, thanks to compression... guess how small the patch was? Under 500 bytes. Yes, not MB, not kb, but bytes.

So the patches rock, but that wasn't the point of this test. The 371MB wasn't as big of a test data as I hoped for, but it did successfully upload via FTP in full for uncompressed Sync Mode (which is clearly a poor choice in this special case, but it works as advertised).

Now to play with some 3.6GB linux isos as test files.

Update2:
NSIS Installer EXEs have a max filesize limit of 2GB: http://forums.winamp.com/showthread.php?postid=2500330
So, if you want to release a huge project of a greater filesize, you can still do this, but you will have to:

Either A) Use a different NSIS Script that doesn't put your files into the installer EXE, but rather keeps them external. To do just use use the NSIS's "CopyFiles" command from a relative sub-folder with something like "$EXEDIR\MyFiles\", instead of the "File" command. If there is a demand for this feature, I can create a new default NSIS script that does this.

B) Use another external installer-making solution. Just point it to the Release folder after you do a "Full Release + Update". The Release Folder can be found in Dispatcher by (Go to the Release tab, click on Expert, then just copy the path in the bottom-left).

Update3:
Stumbled upon a bug that causes config.zip or snapshot.zip to fail to compress when there is a huge file in your Release folder. Fixed this. The change will go live in the next release.

Releasing the 4GB file-including project, including the FTP Upload seems to work file with compression off. I'm just testing with compression on, which takes some time for a 4GB file.

Here's the answer to if Sync Mode works with >3GB files:
1) Without Compression: Yes, releasing and applying updates works
2) With Compression: No, when the Updater extracts a file, the library I used which extracts the 7-zip-like file seems to be doing this in RAM. So, if your users don't have 3GB of RAM to spare, please leave Compression DISABLED.

Update 4:
Let's test generating a huge patch. For this purpose, I have downloaded this software: http://www.mynikko.com/dummy/
I'm creating two huge dummy data files full of random data. Let's see how good the patch is when the files are huge with no data in common.

This is pretty cool. I've generated two 1GB files, but with random data, with the above mentioned program. I've called them both the same thing, added one to v1 of my project, released, and then added v2 of my project with the other 1GB file. So Dispatcher created a patch from one random 1GB file to another, completely different 1GB file.

Creating this patch took it's sweet time. I'm going with ~30minutes. However, I ended up with just a 4MB patch. I can only assume the random data was not that random after all. But anyway, that's pretty impressive. When the Updater found this patch on the client-side, it took only a few minutes to apply.

This all seems to work well. I did run into one issue where the resulting patch could not be copied to the Update Data folder. Imagine my mood when I got that after generating a patch for 30 minutes and having to start over again. So I added code to give a retry message box in that scenario, but with more tests, I have not ran into the same issue anymore. Looks good! ^_^

[Code6226]

Did some work on Dispatcher tonight. I have something exciting to announce soon, but not yet.

[Code6226]

http://www.puchisoft.com/news/?p=11

[Code6226]

Windows XP Bug Fixed: viewtopic.php?f=29&t=691

[Code6226]

Patch Mode now free!
http://www.puchisoft.com/news/?p=13