MS Windows build use of versions in directory names/paths

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Frank Seesink
I'm relatively new to Erlang, so please excuse me if this has been
covered.  I've searched the FAQs and not found a reasoning, so thought I
would post here.

What exactly is the reasoning behind using version numbers in the
directory names/paths in the Windows prebuilt binaries?  That is, the
latest version of Erlang as I write this is Erlang/OTP R10B-4 (release
23 Mar 2005).  Performing a vanilla/standard install, the user has
Erland installed in

        x:\Program Files\erl5.4.5

and there is a subdirectory

        x:\Program Files\erl5.4.5\erts-5.4.5

Why does the Erlang development team (or the Windows installer creator)
just install to

        x:\Program Files\erl\

with a subdirectory

        x:\Program Files\erl\erts
?

Here is why I ask.  I notice that often open source apps do this sort of
thing, especially when they have ties to the *nix world.  I also know
that in the *nix world, it is common to decompress appX version A.B.C in
a directory such as ./appX-A.B.C, then create a symlink

        ./app-X -> ./appX-A.B.C

This allows the path to the application to remain constant, regardless
of updates/changes.  If appX version A.B.D comes out, that is simply
decompressed to its own folder and the 'app-X' symlink changed to point
to the new version.

However, this is not how things are done typically in the Windows world.
  I've gotten used to certain open source projects installing in a
different directory with reach version release.  For example, the game
BZFlag v2.0.0 installed in

        x:\Program Files\BZFlag2.0.0

whereas BZFlag 2.0.2 installed in

        x:\Program Files\BZFlag2.0.2

This is annoying enough, as my personal firewall rules must be adjusted
with each release.  Average Windows users will not deal with this well,
as it gets to be quite annoying.  But this is tolerable with games as
you typically do not build/layer other applications on top of them.

However, programming languages like Erlang exist almost exclusively for
just that reason:  to layer other applications on top of them.  Other
examples might be Perl, PHP, etc.  Now in the Windows world, one of the
most common variants of Perl is ActiveState's ActivePerl, and their
installer by default will install Perl in

        x:\Perl

The documentation on PHP similary advocates installing in a directory
such as

        x:\PHP

And with a new version release, updating is simply a matter of replacing
the old files with the new ones in most cases (barring those users who
heavily customize/add/change/delete files from the distribution).

The advantage of this approach is that the PATH to a given language's
files/engine remains the same.  This makes script writing easier, not to
mention the above firewall rule situation where you have
application-level firewalling.  There is no "moving target" as it were.

This issue came up for me as my introduction to Erlang came from looking
into ejabberd, the Erlang-based Jabber/XMPP server
(http://ejabberd.jabber.ru).  Installing/running ejabberd requires
Erlang, of course.  And the ejabberd installer offers to create a
Windows service so that a user can run ejabberd on system startup.

However, the installation of this NT service involves launching Erlang
and having it fire up ejabberd.  This, of course, necessitates putting
the PATH to the current installed version of Erlang into the appropriate
place in the Windows Registry
(HKLM\SYSTEM\CurrentControlSet\Services\ejabberd...) where the NT
service is set.  (Note this is not something many users will understand.)

If a new version of Windows software comes out, most people simply
either run the latest installer on top of the old install, OR often they
will first uninstall the old version before installing the new one.  I
tend to do the latter so not sure how well the former might avoid this.
  That is, if I install R10B-4 on top of R10B-3, I'm not sure if it will
simply keep the current path or not.

But using the "uninstall, then install" approach results in a lot of
things suddenly breaking.  The ejabberd service is no longer pointing to
the right directory for Erlang.  Any scripts or other items which also
required this path are also snafu'd.  Note this does NOT happen with
updates to Perl or PHP, for example.

So I was wondering why the Erlang team chose this approach.  Noting that
many other open source projects do NOT resort to this in Windows by
default--e.g., Apache1/2 webservers, AWStats, Dev-PHP, Ethereal,
FeedReader, FileZilla/Server, Neverball, OpenSSL, PuTTY, WinMerge--it
seems it might be best NOT to put a version number in the path, but
rather let the user find the version either by looking at a README in
the installed directory, or in the case of Erlang, simply by running the
  shell.  Especially noting that updating Erlang itself at present can
result in almost ANY Erlang app breaking, and that the number of Erlang
apps will be >= 1 (otherwise why install Erlang?), this means with each
release of Erlang, users may have to go through and not just install the
latest Erlang, but they will have to go adjusting any and all Erlang
apps such as ejabberd which need the path information to work properly.

Thanks for any insight into this.  At present I resort to digging
through the system and adjusting the path where necessary, but I can
assure you that most Windows users will NOT do this.  The end result is
that adoption of Erlang as a language--just as I started playing due to
ejabberd--will be hindered as others may be frustrated/annoyed by this
process (and I believe rightfully so).  I know the folks behind ejabberd
swear by Erlang, and it definitely has some interesting features.  But
even their image will be tarnished any time someone updates Erlang only
to find that suddenly ejabberd will not run anymore.

P.S. I tried adjusting the install path for Erlang, but the best I could
get was

        x:\Program Files\erl

Unfortunately, the subdirectory for ERTS is still

        x:\Program Files\erl\erts-5.4.5

And as ejabberd uses this path, BOOM!




Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Vlad Dumitrescu-4
Hi,

This isn't an answer, but a partial workaround. I use Junction Link Magic
(http://www.rekenwonder.com/linkmagic.htm) to create a hard link to the current
Erlang distribution directory (only works with NTFS).

However, this doesn't solve the problem with the erts directory...

regards,
Vlad


Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Raimo Niskanen-3
In reply to this post by Frank Seesink
Well, that was a long question...

Erlang comes from the Unix world, and is built for handling hot code
upgrades, so if you are a commercial customer and installs an OTP
patch, the patched application is installed in a subdirectory
with a new version number. The old version is kept in case you
would want to back out the patch later on.

That is the main reason for the version numbers on the directories.
The patch script is the same for Windows and Unix, and I guess it
is not even aware of the platform.

Large parts of OTP (at least the code server) also depends on this
directory structure. And rewriting all code would cost too much.

But, as a side note. In our internal development environment
we have a directory tree without version numbers. Version handling
is done in ClearCase. So, probably, if you would take a Windows
(or Unix) installation and strip all version suffixes from
the Erlang installation tree, and rebuild the start scripts
(the start script compiler takes an undocumented flag to
build without version numbers) - it would work. _But_ OTP
patch handling would _not_ work, and that is why the
installation tree does not look that way.

This is an area where Windows and Unix security approaches
still clashes head on. E.g ZoneAlarm on windows checking which
installed program that tries to get out - that is not really
what a firewall is supposed to do. In the Unix world a firewall
is a separate box, and it checks which user and which machine
that tries to get out and knows nothing of program installation
pathes. The ZoneAlarm check is really a Worm check.

Why ejabberd uses the registry is another question. Erlang/OTP
and many others has moved away from using the registry. I think
the Erlang/OTP installer fixes the path, so if ejabberd used the
Erlang that was in the path, there would be no problem (guessing
here...)



frank (Frank Seesink) writes:

> I'm relatively new to Erlang, so please excuse me if this has been
> covered.  I've searched the FAQs and not found a reasoning, so thought I
> would post here.
>
> What exactly is the reasoning behind using version numbers in the
> directory names/paths in the Windows prebuilt binaries?  That is, the
> latest version of Erlang as I write this is Erlang/OTP R10B-4 (release
> 23 Mar 2005).  Performing a vanilla/standard install, the user has
> Erland installed in
>
> x:\Program Files\erl5.4.5
>
> and there is a subdirectory
>
> x:\Program Files\erl5.4.5\erts-5.4.5
>
> Why does the Erlang development team (or the Windows installer creator)
> just install to
>
> x:\Program Files\erl\
>
> with a subdirectory
>
> x:\Program Files\erl\erts
> ?
>
> Here is why I ask.  I notice that often open source apps do this sort of
> thing, especially when they have ties to the *nix world.  I also know
> that in the *nix world, it is common to decompress appX version A.B.C in
> a directory such as ./appX-A.B.C, then create a symlink
>
> ./app-X -> ./appX-A.B.C
>
> This allows the path to the application to remain constant, regardless
> of updates/changes.  If appX version A.B.D comes out, that is simply
> decompressed to its own folder and the 'app-X' symlink changed to point
> to the new version.
>
> However, this is not how things are done typically in the Windows world.
>   I've gotten used to certain open source projects installing in a
> different directory with reach version release.  For example, the game
> BZFlag v2.0.0 installed in
>
> x:\Program Files\BZFlag2.0.0
>
> whereas BZFlag 2.0.2 installed in
>
> x:\Program Files\BZFlag2.0.2
>
> This is annoying enough, as my personal firewall rules must be adjusted
> with each release.  Average Windows users will not deal with this well,
> as it gets to be quite annoying.  But this is tolerable with games as
> you typically do not build/layer other applications on top of them.
>
> However, programming languages like Erlang exist almost exclusively for
> just that reason:  to layer other applications on top of them.  Other
> examples might be Perl, PHP, etc.  Now in the Windows world, one of the
> most common variants of Perl is ActiveState's ActivePerl, and their
> installer by default will install Perl in
>
> x:\Perl
>
> The documentation on PHP similary advocates installing in a directory
> such as
>
> x:\PHP
>
> And with a new version release, updating is simply a matter of replacing
> the old files with the new ones in most cases (barring those users who
> heavily customize/add/change/delete files from the distribution).
>
> The advantage of this approach is that the PATH to a given language's
> files/engine remains the same.  This makes script writing easier, not to
> mention the above firewall rule situation where you have
> application-level firewalling.  There is no "moving target" as it were.
>
> This issue came up for me as my introduction to Erlang came from looking
> into ejabberd, the Erlang-based Jabber/XMPP server
> (http://ejabberd.jabber.ru).  Installing/running ejabberd requires
> Erlang, of course.  And the ejabberd installer offers to create a
> Windows service so that a user can run ejabberd on system startup.
>
> However, the installation of this NT service involves launching Erlang
> and having it fire up ejabberd.  This, of course, necessitates putting
> the PATH to the current installed version of Erlang into the appropriate
> place in the Windows Registry
> (HKLM\SYSTEM\CurrentControlSet\Services\ejabberd...) where the NT
> service is set.  (Note this is not something many users will understand.)
>
> If a new version of Windows software comes out, most people simply
> either run the latest installer on top of the old install, OR often they
> will first uninstall the old version before installing the new one.  I
> tend to do the latter so not sure how well the former might avoid this.
>   That is, if I install R10B-4 on top of R10B-3, I'm not sure if it will
> simply keep the current path or not.
>
> But using the "uninstall, then install" approach results in a lot of
> things suddenly breaking.  The ejabberd service is no longer pointing to
> the right directory for Erlang.  Any scripts or other items which also
> required this path are also snafu'd.  Note this does NOT happen with
> updates to Perl or PHP, for example.
>
> So I was wondering why the Erlang team chose this approach.  Noting that
> many other open source projects do NOT resort to this in Windows by
> default--e.g., Apache1/2 webservers, AWStats, Dev-PHP, Ethereal,
> FeedReader, FileZilla/Server, Neverball, OpenSSL, PuTTY, WinMerge--it
> seems it might be best NOT to put a version number in the path, but
> rather let the user find the version either by looking at a README in
> the installed directory, or in the case of Erlang, simply by running the
>   shell.  Especially noting that updating Erlang itself at present can
> result in almost ANY Erlang app breaking, and that the number of Erlang
> apps will be >= 1 (otherwise why install Erlang?), this means with each
> release of Erlang, users may have to go through and not just install the
> latest Erlang, but they will have to go adjusting any and all Erlang
> apps such as ejabberd which need the path information to work properly.
>
> Thanks for any insight into this.  At present I resort to digging
> through the system and adjusting the path where necessary, but I can
> assure you that most Windows users will NOT do this.  The end result is
> that adoption of Erlang as a language--just as I started playing due to
> ejabberd--will be hindered as others may be frustrated/annoyed by this
> process (and I believe rightfully so).  I know the folks behind ejabberd
> swear by Erlang, and it definitely has some interesting features.  But
> even their image will be tarnished any time someone updates Erlang only
> to find that suddenly ejabberd will not run anymore.
>
> P.S. I tried adjusting the install path for Erlang, but the best I could
> get was
>
> x:\Program Files\erl
>
> Unfortunately, the subdirectory for ERTS is still
>
> x:\Program Files\erl\erts-5.4.5
>
> And as ejabberd uses this path, BOOM!
>
>

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Helmut Enck-Radana-2
In reply to this post by Vlad Dumitrescu-4
Hi,

At 08:42 2005-03-29, Vlad wrote:
>I use Junction Link Magic (http://www.rekenwonder.com/linkmagic.htm) to
>create a hard link to the current Erlang distribution directory (only
>works with NTFS).

May be only nitpicking: AFAIK NTFS links to folders (junctions) are more
like symbolic links, while NTFS hard links only can point to files.
(Folders in NTFS aren't files.) There is a difference between a folder and
a link to the folder: When you delete the folder, the content is gone and
you can't reach it via the link. Links to files behave like hard links in a
POSIX system.

Unfortunately both aren't well supported by the Windows system tools. In
Windows Explorer you can't see the difference between a link and a copy,
and Windows Backup even treats links as if they were copies.

-- helmut



Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Vlad Dumitrescu-4
From: "Helmut Enck-Radana" <her>
> May be only nitpicking: AFAIK NTFS links to folders (junctions) are more
> like symbolic links, while NTFS hard links only can point to files.
> (Folders in NTFS aren't files.) There is a difference between a folder and
> a link to the folder: When you delete the folder, the content is gone and
> you can't reach it via the link. Links to files behave like hard links in a
> POSIX system.

Yes, I mixed up my metaphors -- you are right.
 
> Unfortunately both aren't well supported by the Windows system tools. In
> Windows Explorer you can't see the difference between a link and a copy,
> and Windows Backup even treats links as if they were copies.

Also true. For my own purposes, I can live with that. Your mileage may vary.

regards,
Vlad


Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Vlad Dumitrescu-4
In reply to this post by Raimo Niskanen-3
From: "Raimo Niskanen" <raimo>
> Why ejabberd uses the registry is another question. Erlang/OTP
> and many others has moved away from using the registry. I think
> the Erlang/OTP installer fixes the path, so if ejabberd used the
> Erlang that was in the path, there would be no problem (guessing
> here...)

I don't know about ejabberd, but I guess it's the same issue I got when running
an erlang node as a Windows service: erlsrv.exe uses the registry. By default
the VM used is the one in erlsrv's directory which is $ERL_TOP/erts-n.n.n

By using a link to the current erlang directory, one can write for example

    erlsrv -m c:\program\erl\bin\erl.exe <other args>

It would be nicer if cygwin links would work outside the cygwin environment -
but I guess then it wouldn't be Windows anymore :-)

regards,
Vlad




Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Vlad Dumitrescu-4
> By using a link to the current erlang directory, one can write for example
>
>    erlsrv -m c:\program\erl\bin\erl.exe <other args>

Sorry, I did speak too early. The Windows service manager stores also the
path to erlsrv.exe, which means that one also has to create a link
$ERL_TOP/erts to $ERL_TOP/erts-n.n.n

/Vlad


Reply | Threaded
Open this post in threaded view
|

MS Windows build use of versions in directory names/paths

Anders Svensson-3
In reply to this post by Frank Seesink
Frank Seesink wrote:

> I'm relatively new to Erlang, so please excuse me if this has been
> covered.  I've searched the FAQs and not found a reasoning, so thought I
> would post here.
>
> What exactly is the reasoning behind using version numbers in the
> directory names/paths in the Windows prebuilt binaries?  That is, the
> latest version of Erlang as I write this is Erlang/OTP R10B-4 (release
> 23 Mar 2005).  Performing a vanilla/standard install, the user has
> Erland installed in
>
>     x:\Program Files\erl5.4.5
>
> and there is a subdirectory
>
>     x:\Program Files\erl5.4.5\erts-5.4.5
>
> [snip]
>
I can see how this can be annoying for some uses but I would still
not like any major change to the current situation. We typically
have to support several versions of our application and these in
turn (often) use different versions of Erlang. This means that I
need to have several versions of Erlang installed in parallell on
my development environment.
With the current system this is a breeze. I simply install the
versions of Erlang I need. I can then work using any of the
installed versions without risk of using a newer compiler than I
want, or an older stdlib, or ...
The reason this works so well is because the versions install in
completely different structures. Not in spite of it.

> This issue came up for me as my introduction to Erlang came from looking
> into ejabberd, the Erlang-based Jabber/XMPP server
> (http://ejabberd.jabber.ru).  Installing/running ejabberd requires
> Erlang, of course.  And the ejabberd installer offers to create a
> Windows service so that a user can run ejabberd on system startup.
>
> However, the installation of this NT service involves launching Erlang
> and having it fire up ejabberd.  This, of course, necessitates putting
> the PATH to the current installed version of Erlang into the appropriate
> place in the Windows Registry
> (HKLM\SYSTEM\CurrentControlSet\Services\ejabberd...) where the NT
> service is set.  (Note this is not something many users will understand.)
>
 > [snip]
 >
I don't know how ejarrerd works and this is not an argument either
for it or against it. Our application, which is run in a Windows
environment, is built to work with a specific version of Erlang.
Each version is verified for one Erlang version only. Running it
using a different version of Erlang is NOT supported.
To make this work our installer checks for the required version
of Erlang. If that version is not found it will be installed.
Once the correct version of Erlang is available that version is
used by the installer to run the erlsrv application to install
or update the Windows services. The services will then be
registered with a full path to the required Erlang version.

Selecting the version of Erlang is (in our case) up to us. Not our
users. (They usually have no idea what Erlang is.) If they do
install another application using a different version of Erlang
that is not a problem. Our stuff still works just fine.

/Anders