SAMBA 2.2.8 source kit for 8.2 (and possibly earlier)

[John E. Malmberg]

Jean-Yves Collot has examined my posted changes and has discovered a bug
in the VMS_TRICKS.C

   Where the old code was:

	int d[2] = { 512, (int) imgname};

   I replaced it with:

  int d[2];
  ...
  d[0] = 0;
  d[1] = (int) imgname;

   Where the interim fix would be for d[0] = 512;.

This could will disable SMBD caching and possibly introduce a memory leak.

I will not have time to address this before late tuesday evening at the
earliest, so if you are using my posted code for testing, it will need this
edit.

The proper fix would be to change "d" to be of struct dsc$descriptor_s and
completely fill in the descriptor values.

When VFS modules are implemented, there should not be any need for this
trick as the caching code would be contained in the VFS module, and only
the SMBD loads the VFS modules.


And I want to clarify that I am limited in what I can test, and what
VMS versions that I can build for.

I am concentrating on getting the current SAMBA releases for the 2.2.x, 3.x,
and 4.x to build on the current OpenVMS version for ALPHA and IA64, and
using only the minimum number of supplimental or replacement routines needed
for this.

The UNIX 2.2.x release is now up to 2.2.12 because of a security related
patch that was just release.  That is my next target.

Since current versions of VMS support LDAP and Kerberos, I will also be
phasing in support of this in future builds, along with the HP released
version of OpenSSL.  As the SSL is only for SAMBA to SAMBA connections,
it's use would be a build time option.  My preference is to default it
as off.

For building and linking on older versions of VMS, I want to positively
identify exactly what suppliemental or replacement routines are needed for
them, and why they are needed.  Some of the stuff in earlier SAMBA releases
was being carried around just to support versions of VMS that it was not
even possible to run that version of SAMBA on.  And even now there are comments
that indicate an uncertanty of what replacement routines are needed or
not.

If there is something that needs to be enhanced or fixed in the current C
RTL for SAMBA or other UNIX program, I would like to get that formally
documented.


Compiling on newer versions of VMS and then linking on older versions is
risky and not supported by HP.  Code must be compiled on the oldest
version of VMS that it will be linked against.

So if it is known at compile time that a hack/feature is not needed for
the version that is being compiled on, then the build should take advantage
of this.

There are unsupported tricks to get around this, but they involve keeping
private copies of selected files from the older VMS versions and setting
a bunch of logical names, some of which are not publically documented.
And this is not something that is easy to maintain.  Especially since ECOs
also affect this.

Unless otherwise documented in the compiler documentation, redefining
a reserved predefined macro can result in undefined operation at compile
time.  What you can get away with on one version/patch level of the compiler
and VMS may not apply to any other combination.

Reserved predefined macros typically start with a double underscore.
The specific rules are in the ANSI documentation and in the HP C Compiler
documentation.

So the use of the compiler pre-defined macros is to allow programs built
on a specfific version of VMS to take advantage of new features in the CRTL
or the operating system, which should make the programs more efficient.

Now if there is a strong need for LINKING on an older version of VMS than
what the modules were compile on, and no one can volunteer to compile on
that older version, then it may be possible to work out extra defines like
#ifdef VMS_TARGET_V552 to flag the hacks needed to convince the compiler
to generate the correct code.

>
> http://encompasserve.org/~malmberg/samba/
>
> SAMBA_2_2_8-V82-SRC-20041003_BCK.ZIP, 5504 Kb, Sun Oct  3 20:14:54 2004
>
Good Luck,
-John
wb8tyw at qsl.net
Personal Opinion Only