Wolfgang,

>Simply compare the runtime directory off your app with the Alaska runtimes

That would be a useless undertaking, as all files are always changed. Until 
Alaska does incremental updates, like it did for years with HotFix Rollups,
each "update" will be a complete and total install.

Incremental updates shouldn't be a problem, and could be replaced by 
complete installations for minor Version Number updates. So, when Alaska 
releases a new Build, only the files that were actually changed could be 
distributed. If for compatibility reasons a complete install is needed, 
just increase the Sub-Version Number (to 2.01.xxx, etc.) -- as that is what 
this version format was "designed" for -- and install it in parallel to any 
existing Xbase++ installation.

Imagine Microsoft would require everyone to download a complete new Windows 
install every couple of months, completely uninstall your existing Windows 
Operating System, and re-install the new one from scratch. Besides the fact 
that Xbase++ is much smaller than an entire OS, this hypothetical example 
should make some of the issues involved more obvious.

1) Alaska's updates delete all files in the "Program Files\Alaska Software\" 
   directory when an update is made. That includes updated runtime DLLs that 
   might be installed there, including updates to all their totally 
   out-dated common DLLs, like the ones for SSL, etc. Users are therefore 
   forced to either update (or delete) those files after every "update" or 
   "restore" and/or keep separate runtime directories for add-ons and other 
   common files. DLL-hell at its finest.

2) Alaska's updates also delete all files in the "My Documents\Xbase++\" 
   directory that where installed, even the ones that were changed or 
   modified by the user. Even though the "update" leaves any intermediate 
   files, like *.obj files. If you create an updated XppSys.dll, e.g., any 
   changes to the sources are erased, and have to be re-done for every 
   version "update" or "restore". That's besides the necessary re-compile. 
   There might not be a way around this problem (as parallel installations 
   aren't supported/allowed) if a new version actually contains changes to 
   those files, but they rarely do.

3) Because the "automatic" updates create verbose (7+ MB) Log files when 
   deleting the installed version, each update takes nearly half an hour
   if run from the Workbench's Update Manager. If versions could be 
   installed in parallel or incremental updates were made, that process 
   would be much quicker and simpler. Parallel installs would also fix all 
   the other issues listed here.

4) As all files are deleted, including source and include files, there is 
   no way to know what was changed, especially in the "Source\Runtime\"
   directories. Additionally, all files, including the ones that haven't 
   changed since the last millennia, get new File Date/Time Stamps, and 
   occasionally new copyright notice updates (to the year), so even if one 
   manually keeps copies of older versions, comparing them is tedious. As 
   Alaska doesn't document any of those changes, (unpleasant) surprises 
   are inevitable, and only a matter of time.

And don't get me started about the fact that you can't even get to the 
Workbench's "Update Manager" unless you can establish a connection to the 
Alaska Update and Activation Server, which is a completely unnecessary 
(and intrusive) design flaw in the entire process. Or how about the fact 
that we are not able to install the Xbase++ software anywhere else but in 
the Alaska-prescribed directories. Just wait until they decide that either 
running the Workbench or compiling a program will require an Internet 
connection to their Alaska Update and Activation Server to verify that you 
have a valid and activated version installed. Based on what I've seen the 
last couple of years, and Alaska's refusal to address the existing issues, 
I wouldn't put it past them.

Sorry for the rant, but I once in a while need to blow off some steam, or 
I'll explode. I love Xbase++ (the language) but I struggle with some of the 
decisions that Alaska (the company) has made with regard to the way they 
ignore or belittle their customers' -- the Xbase++ developers -- requests 
for easier, simpler, less restrictive, and less time consuming, ways to 
work with Xbase++ (especially with updates and installations).

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net