Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 3 Feb 2003 18:05:31 -0700

> We could create an iocxxx.bat file in the ioc's startup
> directory that
> sets up the necessary PATH environment and then starts the IOC,
> but we
> don't know the name of the .exe that we're supposed to run.
> That wouldn't
> solve the issue for non-IOC programs either - we have no way to
> do that on
> win32, so we have to punt and default SHARED_LIBRARIES=NO on
> win32.
> 

Sorry, I fear that I am entering into this discussion somewhat
late. I am somewhat nervous about where we are punting from, but
perhaps I will be convinced. 

The standard way that software is distributed on windows is with
DLLs (shared libraries), and we have had that default for a long
time. So the above change isn't entirely compatible with what has
been done in the past on win32. I am also concerned (maybe this
is just paranoia) that changing the default to *not* use
shareable libraries might imply that IOC applications wont really
work right if the Windows system manager chooses to use shareable
libraries?

It seems that there are some alternatives?

1) It would be possible to generate an iocCore environment setup
..bat file when building base. We could tell users that they must
run the appropriate script from base before starting up an
application if they need to run multiple versions of base
shareable libraries and other base executables on the same
machine. On windows this script would tack the base binary
directory onto the end of whatever path exists when the script is
run. On UNIX the PATH variable and also the LDLIBRARYPATH
variables would be augmented. I currently use a hard coded
version of this approach when debugging in multiple base versions
on windows. I run one of these scripts before launching the IDE,
but my requirements are specialized, and for many windows users
(2) below might be simpler to understand and maintain, and
possibly more compatible with what is typical and expected on
windows.

2) The Microsoft approach to this issue appears to be to never
change the binary interface of shareable libraries with the same
file name, and to require that all versions of a DLL with the
same file name are patches and not functional changes. So with
EPICS we would have ca3.13.dll, ca3.14.dll, etc. This is the
"shrink wrap" approach that critics have argued was, in its
absence, an impediment to integration of commercial software
components from different vendors on UNIX systems. This also
probably comes from Microsoft's desire to make certain that bug
fix patches are universally used by all 3rd party programs. Janet
sets the version number inside the file header when creating
windows DLLs, but my understanding is that this is not checked at
run time when binding with the shareable libraries on windows,
and instead I suspect that the internal version number is
primarily used by install scripts to avoid copying an old patch
over a newer one. 

So I think that I understand that Andrew's approach specifying
the shareable library path in the linker command line is
intending to make certain that the application's executable
always runs with the shareable libraries that it was compiled
with. This is the "a-link-is-required-to-receive-a-patch"
viewpoint. The Windows approach intends for shareable libraries
to patch problems without relinking all layered products. Of
course your view of this depends heavily on whether you think
that the system developer decides when patches are applied or the
system manager. Of course Microsoft being run by system
developers probably decided that they know best and that the
system managers for PCs are usually users and that they will be
fairly lazy about applying patches if they must rebuild some
program. On Windows at least this is the standard approach and
like it or not we will be flying in the face of convention if we
do not employ it when creating install scripts for EPICS on
Windows?

It seems that including the EPICS major release number in the
name of the shareable library might be a good conservative
practice that is hard to argue against, and is probably an
independent issue from the issue of including the shareable
library search path in the link options. 

Ditto for the automatic generation of scripts that place base in
the path - the use of these scripts or not would be strictly up
to the user. 

However, if this was deemed to be incompatible with the
traditional UNIX approach then there is nothing stopping us from
implementing (1) and (2) on Windows, in deference to what is the
more common approach on Windows, independent of what Andrew is
implementing on UNIX systems if Andrew is careful to limit his
changes to build system configuration files that are used only on
UNIX systems.

I would like to hear Ken, Janet's, and Chris's views on this.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System