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 21:12 -0500, Jeffrey Altman wrote:
> 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. 

I was not able to verify this.  I created a test program using
krb5_copy_data (which changed from implicit ordinal 93 in KFW 2.6.5 to
explicit ordinal 101 in kfw 3.2.2), and it still worked after I replaced
the KFW 2.6.5 krb5_32 DLL with the KFW 3.2.2 version.

I also did some tests with a sample DLL in two versions.  I found that
if I did not specify an ordinal in either the old or new def file,
upgrading the DLL to the new version caused no backward compatibility
problems even if the implicit ordinals changed (i.e. the linkage was
clearly being done by name).  If I *did* specify an ordinal in the old
def file, and changed it or removed it in the new def file, that would
cause an app to break.  So, my conclusion is that function binding is by
name if no ordinal is specified, and by number if one is.

> 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

Apps using gssapi32.dll would be using data symbols in addition to
function symbols; I wonder if those are more restrictive.

Anyway, it's not particularly burdensome to add the static ordinals, so
I will do so just to reduce the risk that there is something I don't
understand, and for consistency with KFW 3.x.

> MIT needs to do more than that.  It needs to specify the OS platforms
> that are supported.

The OS platforms supported by SDK 7.1 are XP SP2, Vista, Server 2003,
Server 2008, and Windows 7.  From my current position of ignorance, that
seems like a reasonable set of OS platforms to support for a new KFW
release.

If there are APIs we want to use which aren't present in XP or Server
2003, we can detect the OS platform at runtime, right?  It looks like
cc_mslsa.c already does some amount of that.

> 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 minimum visual studio chain that can be used for building apps
against KFW, or building KFW itself?

I didn't need to install Visual Studio at all to get the core krb5 build
working; the SDK included all of the necessary command-line tools
(compiler, linker, nmake, etc.).  Will Visual Studio be needed to build
some part of KFW itself, such as the installer?

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

Noted.  So far I have only worked with the core krb5 build; I still need
to learn about how that is turned into KFW and how we can simplify that.