svn rev #24533: trunk/src/ appl/ ccapi/lib/ ccapi/lib/mac/ ccapi/lib/win/ ccapi/server/win/ ...
ghudson at MIT.EDU
Thu Nov 25 18:20:21 EST 2010
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://email@example.com/msg00118.html and did some
additional research, and I wasn't able to understand the benefit of
The MSDN documentation I could find
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
> 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
I will look into that, thanks.
More information about the krbdev