From: Donal K. Fellows on
On 7 Apr, 12:23, "Larry W. Virden" <lvir...(a)gmail.com> wrote:
> I would think that, on relatively recent Windows systems, the user's
> human, public, real name would be an Active Directory property in the
> user object associated with the login.

Fine, if that's available. Not always true, e.g., if the machine is
booted off the network or if the AD is behind a strict firewall and
the user is outside. Home machines are another case where there's
likely no AD server.

Donal.
From: Larry W. Virden on
On Apr 7, 9:28 am, "Donal K. Fellows"
<donal.k.fell...(a)manchester.ac.uk> wrote:
> On 7 Apr, 12:23, "Larry W. Virden" <lvir...(a)gmail.com> wrote:
>
> > I would think that, on relatively recent Windows systems, the user's
> > human, public, real name would be an Active Directory property in the
> > user object associated with the login.
>
> Fine, if that's available. Not always true, e.g., if the machine is
> booted off the network or if the AD is behind a strict firewall and
> the user is outside. Home machines are another case where there's
> likely no AD server.
>
> Donal.

Agreed. I don't know where Microsoft squirrels away the info in some
of those cases. Sure isn't something that Tcl core could depend on
making available.
From: APN on
On Apr 7, 6:47 pm, "Larry W. Virden" <lvir...(a)gmail.com> wrote:
> On Apr 7, 9:28 am, "Donal K. Fellows"
>
> <donal.k.fell...(a)manchester.ac.uk> wrote:
> > On 7 Apr, 12:23, "Larry W. Virden" <lvir...(a)gmail.com> wrote:
>
> > > I would think that, on relatively recent Windows systems, the user's
> > > human, public, real name would be an Active Directory property in the
> > > user object associated with the login.
>
> > Fine, if that's available. Not always true, e.g., if the machine is
> > booted off the network or if the AD is behind a strict firewall and
> > the user is outside. Home machines are another case where there's
> > likely no AD server.
>
> > Donal.
>
> Agreed. I don't know where Microsoft squirrels away the info in some
> of those cases.  Sure isn't something that Tcl core could depend on
> making available.

The same API retrieves the information either from the local accounts
db or from AD depending on where the user account is defined. But I
don't think this is the type of info for which the core should be
responsible for providing access.