Hi Alaska,
Could you please install in each new update only the affected DLLs? 
Alternatively, please publish which DLLs were changed.

When we distribute to clients a new compiled program [with new release], we 
shall also distribute the required DLLs.  Including all DLLS (whether 
changed or not), create a needlessly large MSI which takes longer to 
download.  I’d like to include in each MSI only the necessary so it is agile 
and easy to download.

Many thanks,

Itai

Itai Ben-Artzi wrote:

> When we distribute to clients a new compiled program [with new release], we 
> shall also distribute the required DLLs.  Including all DLLS (whether 
> changed or not), create a needlessly large MSI which takes longer to 
> download.

I think changing the Alaska distribution to only the affected files makes
it very complicated and also prone to errors - I prefer to get a full
update instead.

If download volume is an issue (which normally isn't anymore with todays
internet lines) you could use something like delta patch:

http://www.grafxsoft.com/deltapatch.htm

We have been using this in the 1990s, when internet lines where slow and
our Clipper application had a total of 120 MB exe and overlay files (wow...
that was really MUCH in those days.

Thomas

Am 06.03.2015 um 08:08 schrieb "Itai Ben-Artzi":
> Hi Alaska,
> Could you please install in each new update only the affected DLLs?
> Alternatively, please publish which DLLs were changed.

to mix different Xbase++ Releases was never a good Idea.
Some will work, others will tell you that the DLLs are not compatible or 
you only get strange errors.

... 1.90.331 # 1.90.355 (SL1)

Am 06.03.2015 um 08:08 schrieb "Itai Ben-Artzi":
> Hi Alaska,
> Could you please install in each new update only the affected DLLs?
> Alternatively, please publish which DLLs were changed.
>
> When we distribute to clients a new compiled program [with new release],
> we shall also distribute the required DLLs.  Including all DLLS (whether
> changed or not), create a needlessly large MSI which takes longer to
> download.  I’d like to include in each MSI only the necessary so it is
> agile and easy to download.
>
> Many thanks,
>
> Itai
Simply compare the runtime directory off your app with the Alaska runtimes

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

Am 07.03.2015 um 01:11 schrieb "Andreas Gehrs-Pahl":
> 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

perfect description.

And there are Xbase++ developers with realy poor internet speed at work 
(wie do have only UTMS with a poor signal).
Thats why I always downloaded the ZIPs from the web site at home (50 
MBit) and took them to the office by a USB HD.

If I think about the worktime on such things ... and some other stuff 
... and how long I was waiting on DataObjects and SQL Server shown at 
the Devcon in 2007 ... I can't say this on a open forum 

Bye the way, I do have a 2.00.575 pressed in my old installation mode 
(CMD can change the used compiler with a double click) ... 

Bye
Hubert

I second all of that !


On 06/03/2015 21:11, "Andreas Gehrs-Pahl" wrote:
> 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
>


--
Edgar Borger
Softsupply Informatica Ltda.
Rua Alagoas, 48
Sao Paulo, SP
01242-000
Tel : (5511) 3159-1997
Fax : (5511) 3255-5224

---
Este email foi escaneado pelo Avast antivírus.
http://www.avast.com

Most (often all) DLLs still have the same size but the date is different.
What should be compared?

Hi Itai,

The Workbench's update manager shows all closed workitems per
update. In there you also find the component that was updated.

Note that the updates are incremental.

The preferred way to update the Xbase++ runtime is to distribute
everything required by your application. This way you need not to
plot what component got modified when.

Furthermore, executing "xppload version" at your customers side
will list the build per component. Finding unmatching combinations
is no longer a big issue.

Hope this helps,

Andreas Herdt
Alaska Software

--------------------------------------------------------------------

Technical Support: support@alaska-software.com

News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm

Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
--------------------------------------------------------------------