KFW and Vista

[Jeffrey Altman]

Sam Hartman wrote:
> Why isn't this what we want?

You want the krb5.ini file to be per-user with no ability to have
system-wide defaults like we have now?

The reason that we use %WinDir% as the location for the configuration
files is largely historical.  That is where people put .INI files for
Windows applications back in the 16-bit days.  It has been a long time
since this was recommended practice.  However, until now there has been
very little reason for us to move the configuration data (except on
Terminal Server systems) because nothing stopped us from keeping them
there.  On Vista, because of the new security enforcement, applications
are not permitted to modify the contents of the %WinDir% directory tree.
Any changes will be reverted.

> I don't understand why that's true.  We can use the Vista SDK to build
> for XP, right?  And only use features if they are present on the
> current system.  Don't we do this already for some MSLSA extensions?

There are multiple issues here:

(1) if you build for XP, are the symbols we require for Vista MSLSA
    extensions published?

(2) if you build for XP, are the symbols and APIs required for Vista
    user interface design accessible?

(3) if you build for Vista, can the resulting binaries be executed
    on Vista?

The answer to all three are 'no'.  For the LSA operation symbols we
have a combination of OS version tests (because the behaviors have
changed in 2000, XP, and 2003) and run-time tests to determine if
other LSA functions exists.  We have required that the version of
the Platform SDK be sufficiently high that the symbols we need are
defined.  Now in the Vista SDK, symbols are being selectively defined
based upon the OS version you are building the application for.  This
is being done much more consistently in the Vista SDK than in prior
versions.  I bet this is a result of documentation efforts put forth
to satisfy the anti-trust cases.

For UI controls we run into a different problem.  If you build a binary
that uses new UI controls, then it links to a different version of the
common controls library than it would if you restricted yourself to the
UI controls of earlier OS versions.  We already have this problem
between 2000 and XP.  For that we build separate 2000 and XP versions
of the NetIDMgr binaries (minus the plug-ins) and torture ourselves
in order to make sure that the correct binaries are installed on the
correct OS.  The Windows Installer engine is not designed to handle this
case.

In Vista, all user accounts including those accounts which are members
of the Administrators group login to the system without Admin
privileges.  Applications that contain a combination of non-Admin and
Admin functionality must be broken up in to separate components.
The non-Admin components must spawn the Admin components using new
APIs that are not present on older versions of the OS.  New UI control
extensions are to be used to mark those controls which will invoke
Admin privileges because activating those operations will push the
user to the secure desktop for a permission request.

I'm suggesting drawing the line at Vista partly because the use of the
Vista SDK requires it but also because the user experience on Vista
is going to be different from the older OS versions anyway.

Jeffrey Altman