Hi Alaska,

The following are some issues and problems with the Workbench Update Manager 
that I have encountered:

1) The Workbench Update Manager can't be opened without a connection to the 
   Alaska Update/Activation Server, either due to a lack of Internet access 
   or because the Alaska server is down or unreachable. This prevents the 
   user from switching versions or even seeing what versions are available,
   unless an Internet connection to the Alaska Update/Activation Server can 
   be established.

2) The Workbench Update Manager has only a single "Download and Install" 
   button, rather than separate buttons for those two features. If a user 
   wants to download (an older) version, but not actually install it (at 
   the time of download), then that isn't currently possible.

3) On the "Installation History", the single button is also labeled as: 
   "Download and Install", even though those builds were already downloaded 
   and only need to be Installed.

4) Because the only way to switch between versions -- through the Workbench 
   Update Manager -- is to totally uninstall the current/active version and 
   then to install a different version, selecting the MSI's "Cancel" button 
   might completely destroy the existing installation -- depending on when 
   in the process the button is pressed -- leaving the user without a 
   working development environment.

   A "normal" user -- one of those that needs to be protected by Alaska from 
   installing the application where ever they like -- would be completely 
   lost at that point, unable to run the Workbench or its Update Manager to 
   fix the installation. As the location of the MSI files isn't officially 
   documented, (novice) users might have no choice but to contact Alaska 
   support for help.

5) Each change of version takes in excess of 30 minutes, because of the 
   verbose log file that is created and because the entire existing Xbase++ 
   development environment is first uninstalled only to be re-installed in 
   the same location.

Please consider the following requests:

1) Let the user install the application where ever they like, supporting 
   parallel installations of different versions right out of the box. All 
   the specifics about each installation could be easily saved in the 
   "product.config" file, requiring only small changes to the current 
   installation and update process.

2) Add separate "Download" and "Install" buttons for each build in the 
   Update Manager, so users can select each of those features separately.

3) Consider supplying incremental updates for new builds, if they are 
   principally compatible with the existing version of Xbase++, similar to 
   the HotFix Rollups. Use the Minor Version Number to ensure compatibility 
   between builds and to determine if a full install is necessary or not.

4) Document which individual files have been changed between each Build, 
   specifically: Source Code files, Header files, Runtime DLLs.

   Also document if a new build will require new versions of add-on products 
   that do not come with source code, such as Xb2Net, SQLExpress, etc. or if 
   they are runtime-compatible with the previous build(s).

5) Do not create a verbose Log file for each uninstall/install, to make the 
   (update) process much faster.

6) Do not delete any files that weren't installed by your installation 
   process or have been updated since. For (common) DLLs, use the existing 
   Version information in those files to not overwrite newer version files.

7) Consider updating the Open Source DLLs, such as Open SSL, MIT Kerberos, 
   GNU Text Utilities, Microsoft Visual C runtimes, Terra Informatica 
   HTMLayout DLL, and PostGre SQL, when newer versions of the files are 
   available. Otherwise, don't replace newer versions of the files, if they 
   exist. The same is true for the OCX/Active-X files that come with the 
   installation (and which aren't installed by default).

8) Allow the user to open the "Update Manager", even if ASGet.exe returns 
   an error of some sort.

For everyone who would like to do just that -- open the "Update Manager" of 
the Workbench, no matter if the Alaska server is reachable or not -- I have 
attached a small "ASGetProxy" program. This program requires Xb2Net as well 
as ASINet and is just a quick little hack to allow the Workbench to open 
the Update Manager under any circumstances.

If Alaska fixes the Update Manager, so it comes up even if the ASGet.exe 
program returns an error, then this "ASGetProxy" program will no longer be 
necessary.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

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

Valid points.

mr. Andreas: do command line (pbuild, xpp compiler and alink linker) work
flawlessly as they were in 1.x releases?

When we upgrade to 2.x, we probably will not use ide for much more than
updating release when necessary.


Andreas Gehrs-Pahl wrote in message
news:1pws42dazykhq$.w0seizmncjpk.dlg@40tude.net...
>Hi Alaska,
>
>The following are some issues and problems with the Workbench Update Manager 
>that I have encountered:
>
>1) The Workbench Update Manager can't be opened without a connection to the 
>   Alaska Update/Activation Server, either due to a lack of Internet access 
>   or because the Alaska server is down or unreachable. This prevents the 
>   user from switching versions or even seeing what versions are available,
>   unless an Internet connection to the Alaska Update/Activation Server can 
>   be established.
>
>2) The Workbench Update Manager has only a single "Download and Install" 
>   button, rather than separate buttons for those two features. If a user 
>   wants to download (an older) version, but not actually install it (at 
>   the time of download), then that isn't currently possible.
>
>3) On the "Installation History", the single button is also labeled as: 
>   "Download and Install", even though those builds were already downloaded 
>   and only need to be Installed.
>
>4) Because the only way to switch between versions -- through the Workbench 
>   Update Manager -- is to totally uninstall the current/active version and 
>   then to install a different version, selecting the MSI's "Cancel" button 
>   might completely destroy the existing installation -- depending on when 
>   in the process the button is pressed -- leaving the user without a 
>   working development environment.
>
>   A "normal" user -- one of those that needs to be protected by Alaska from 
>   installing the application where ever they like -- would be completely 
>   lost at that point, unable to run the Workbench or its Update Manager to 
>   fix the installation. As the location of the MSI files isn't officially 
>   documented, (novice) users might have no choice but to contact Alaska 
>   support for help.
>
>5) Each change of version takes in excess of 30 minutes, because of the 
>   verbose log file that is created and because the entire existing Xbase++ 
>   development environment is first uninstalled only to be re-installed in 
>   the same location.
>
>Please consider the following requests:
>
>1) Let the user install the application where ever they like, supporting 
>   parallel installations of different versions right out of the box. All 
>   the specifics about each installation could be easily saved in the 
>   "product.config" file, requiring only small changes to the current 
>   installation and update process.
>
>2) Add separate "Download" and "Install" buttons for each build in the 
>   Update Manager, so users can select each of those features separately.
>
>3) Consider supplying incremental updates for new builds, if they are 
>   principally compatible with the existing version of Xbase++, similar to 
>   the HotFix Rollups. Use the Minor Version Number to ensure compatibility 
>   between builds and to determine if a full install is necessary or not.
>
>4) Document which individual files have been changed between each Build, 
>   specifically: Source Code files, Header files, Runtime DLLs.
>
>   Also document if a new build will require new versions of add-on products 
>   that do not come with source code, such as Xb2Net, SQLExpress, etc. or if 
>   they are runtime-compatible with the previous build(s).
>
>5) Do not create a verbose Log file for each uninstall/install, to make the 
>   (update) process much faster.
>
>6) Do not delete any files that weren't installed by your installation 
>   process or have been updated since. For (common) DLLs, use the existing 
>   Version information in those files to not overwrite newer version files.
>
>7) Consider updating the Open Source DLLs, such as Open SSL, MIT Kerberos, 
>   GNU Text Utilities, Microsoft Visual C runtimes, Terra Informatica 
>   HTMLayout DLL, and PostGre SQL, when newer versions of the files are 
>   available. Otherwise, don't replace newer versions of the files, if they 
>   exist. The same is true for the OCX/Active-X files that come with the 
>   installation (and which aren't installed by default).
>
>8) Allow the user to open the "Update Manager", even if ASGet.exe returns 
>   an error of some sort.
>
>For everyone who would like to do just that -- open the "Update Manager" of 
>the Workbench, no matter if the Alaska server is reachable or not -- I have 
>attached a small "ASGetProxy" program. This program requires Xb2Net as well 
>as ASINet and is just a quick little hack to allow the Workbench to open 
>the Update Manager under any circumstances.
>
>If Alaska fixes the Update Manager, so it comes up even if the ASGet.exe 
>program returns an error, then this "ASGetProxy" program will no longer be 
>necessary.
>
>Andreas

Matej Jurac wrote:

> Valid points.
> 
> mr. Andreas: do command line (pbuild, xpp compiler and alink linker) work
> flawlessly as they were in 1.x releases?

Yes - no problems at all so far. I'm using Multiedit as the editor and will
not change.

> When we upgrade to 2.x, we probably will not use ide for much more than
> updating release when necessary.

Same here - I have the whole Alaska environment in a small Windows 7 VM and
update when neccesary (not a single time since release of 2.x)

Thomas

Matej,

>mr. Andreas: do command line (pbuild, xpp compiler and alink linker) work
>flawlessly as they were in 1.x releases?

The command line Project Builder, Compiler, Linker and Debugger work pretty 
much the same as before, and I normally only use those, rather than the 
workbench. But (apparently to better integrate with the workbench) those 
programs, specifically the compiler, do not display much information in the 
command dialog anymore, if output is re-directed to a file. This is about 
the only change to 1.9 that is easily noticed.

As the workbench also uses those command line programs -- with the exception 
of the debugger, of course -- there shouldn't be any difference in the 
resulting targets between compiling them with or without the workbench IDE.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

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