svn rev #24533: trunk/src/ appl/ ccapi/lib/ ccapi/lib/mac/ ccapi/lib/win/ ccapi/server/win/ ...

[Greg Hudson]

On Thu, 2010-11-25 at 16:54 -0500, Jeffrey Altman wrote:
> Also, make sure
> that ordinal numbers are assigned to all functions listed in the .DEF
> file.  Functions with unassigned ordinals are alphabetized by name and
> assigned unused ordinal values from lowest to highest.  A failure to
> make these changes prevents an application built against version X from
> working with version Y.

While doing this work, I read
http://www.mail-archive.com/kfwdev@mit.edu/msg00118.html and did some
additional research, and I wasn't able to understand the benefit of
static ordinals.

The MSDN documentation I could find
(http://msdn.microsoft.com/en-us/library/hyx1zcd3(v=VS.90).aspx and 
http://msdn.microsoft.com/en-us/library/e7tsx612(VS.80).aspx) implies
that applications built against a DLL will link by name rather than by
ordinal if no ordinal is specified.  Also, the most recommended way of
exporting symbols from a DLL (using __declspec(dllexport), which we
don't do) doesn't allow you to specify an ordinal.

Moreover, I had no trouble finding examples of well-supported libraries
which don't define static ordinals.  The Heimdal Windows build
infrastructure doesn't appear to do it.  NSS doesn't do it.  If
Wikipedia is correct
(http://en.wikipedia.org/wiki/Dynamic-link_library#Symbol_resolution_and_binding) then the DLLs comprising the win32 API don't generally do it.

I don't want to be obstinate about this point, as they're mostly
harmless, but I would like to understand better.

> I'm not sure what versions of Windows MIT intends to support.

I am guessing the platforms supported by the latest version of the SDK
(7.1).

> The issue that 20277 was intended to address (regardless of whether or
> not the author's code was correct) is still present.  The version of
> ntsecapi.h required to produce a correct build needs to be from version
> 6.0 of the SDK or above.

Is this as simple as documenting the required SDK version?

> > * klist -V prints just "Kerberos for Windows", since it has no access
> >   to PACKAGE_NAME and PACKAGE_VERSION from autoconf.  This should be
> >   addressed correctly.
> 
> It should print its own file version number from the compiled resource data.

Okay.  I'll have to do some additional research to learn how to do that.

> > * krb5, telnet, gssftp, and NIM are removed from the build.

Whoops, that should have started with "krb4".  I didn't remove krb5.exe
from the build.

> will these items be removed from the source repository?

I am assuming yes, but I didn't want to do that right away.  gssftp is
already unbundled into the krb5-appl repository.

> do we need another cross platform portability library?   Heimdal's roken
> is extremely well supported and is license compatible.  I recommend you
> import the portions of it that you require as an external third party
> library just as openafs has.  See the openafs src/external/heimdal/roken
> directory.  The effort required to port it to Windows has already been
> performed.

I will look into that, thanks.