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

[Jeffrey Altman]

On 11/25/2010 6:20 PM, Greg Hudson wrote:
> 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.
Try building an application linked against kfw 2.6.5 and then try
running it with libraries from 3.2.2.
You will find that the application won't execute because the ordinals
do not match the entry points they were assigned to.
>
> 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.

It is not necessary if you are building applications that are linked
against dll from the same product version.
Nor would it be necessary if the DLLs were being distributed as part
of an assembly.   MIT has historically shipped a loose collection of
DLLs.  Assemblies were not supported before XP.
>
> 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.

The Heimdal Windows build infrastructure doesn't do it because Heimdal
is built as a set of assemblies.  Each version of the assembly
specifies a well defined ABI.


> 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.

You are welcome to do what you would like.  The reason ordinals were
added (by me) in version 3.0 of KFW is because of the significant
issues that organizations had with upgrading KFW libraries in place.
Apps linked against the 2.6.5 gssapi32.lib would fail to load 3.2.2
gssapi32.dll
>
>> 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).

MIT needs to do more than that.  It needs to specify the OS platforms
that are supported.  Even if MIT says that only SDK 7.1 is supported,
it is the OS platform that is targeted that determines which APIs may
be used.

The selection of SDK also determines the minimum visual studio tool
chain that can be used.  Typically, newer SDKs are not compatible with
older visual studio distributions.
>
>> 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?

The reason the check was added because documentation was not
sufficient to ensure that MIT itself distributed binaries built
against the correct 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.

Note that the command line tools distributed with KFW have not been
the krb5 versions.  The pismere tools have additional functionality
that will need to be migrated.
>
>>> * 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.
>