Win32All On 64-Bit Operating Systems

[Tim Daneliuk]

I have a pure-Python program developed on a POSIX platform (FreeBSD) that
I'd like to make fully compatible with Windows systems as well. The only
conflict arises insofar as this program makes considerable use of the
stat UID and GID values, as well as their corresponding user- and group
names. Since Windows has not grp and pwd modules, I need to synthesize
this.

In the past, I've solved this problem by detecting the presence of Win32All.
If present, I do the necessary magic to return the true UID/name, GID/name
info from Windows itself. If not, I return UID/GID as provided by an
os.stat call and use the phoby names "winuser" and "wingroup" respectively.

Now for the question: Is there even an instance of Win32All for 64-bit
OSs like Vista and Win7? If not, I'm inclined not bother with it at all
and just return the phony values as placeholders because I do not want
different features on 32- and 64-bit platforms.

Thanks,

 

[Tim Golden]

I have a pure-Python program developed on a POSIX platform (FreeBSD) that
I'd like to make fully compatible with Windows systems as well. The only
conflict arises insofar as this program makes considerable use of the
stat UID and GID values, as well as their corresponding user- and group
names. Since Windows has not grp and pwd modules, I need to synthesize
this.

In the past, I've solved this problem by detecting the presence of Win32All.
If present, I do the necessary magic to return the true UID/name, GID/name
info from Windows itself. If not, I return UID/GID as provided by an
os.stat call and use the phoby names "winuser" and "wingroup" respectively.

Now for the question: Is there even an instance of Win32All for 64-bit
OSs like Vista and Win7? If not, I'm inclined not bother with it at all
and just return the phony values as placeholders because I do not want
different features on 32- and 64-bit platforms.

Looks like it:

http://sourceforge.net/projects/pywin32/files/

but, frankly, I wouldn't bother with the uid/gid thing on
Windows. It's nearly meaningless most of the time. Just
return placeholders.

TJG

 

[Tim Daneliuk]

Looks like it:

http://sourceforge.net/projects/pywin32/files/
Thanks!


but, frankly, I wouldn't bother with the uid/gid thing on
Windows. It's nearly meaningless most of the time. Just
return placeholders.

TJG

That's not really so. Windows definitely has the notions of users and groups,
they just don't quite align with the POSIX model exactly.

 

[Tim Golden]

That's not really so. Windows definitely has the notions of users and groups,
they just don't quite align with the POSIX model exactly.

Yes, my comment was a little blase. I know that Windows has users & groups:

http://timgolden.me.uk/python/win32_how_do_i/get-the-owner-of-a-file.html



I was thinking that you wanted a naive transfer of the Posix concept.
The "owner" of a file does mean something to Windows (while the "group"
really doesn't; it's just an artefact of Windows' posix-compatibility)
but not as much as it does on Posix systems, because the security system
is much more sophisticated.

But maybe I'm teaching my grandmother to suck eggs ?

TJG

 

[Tim Daneliuk]

Yes, my comment was a little blase. I know that Windows has users & groups:

http://timgolden.me.uk/python/win32_how_do_i/get-the-owner-of-a-file.html



I was thinking that you wanted a naive transfer of the Posix concept.
The "owner" of a file does mean something to Windows (while the "group"
really doesn't; it's just an artefact of Windows' posix-compatibility)
but not as much as it does on Posix systems, because the security system
is much more sophisticated.

But maybe I'm teaching my grandmother to suck eggs ?

TJG

Naw. The intent is just to provide as similar as possible a user experience.
From a coding POV, it is surely simpler to just use 'winuser' and 'wingroup',
but I am sort of philosophically wired to not throw information away if
it's a available from the OS.

BTW, wanna beta test a really cool CLI mass file renaming tool?????

 

[Tim Golden]

The intent is just to provide as similar as possible a user experience.
but I am sort of philosophically wired to not throw information away if
it's a available from the OS.

It's hardly worth disputing I suppose, but I would argue that simply
presenting the owner & group of a file in Windows is actually doing
a disservice to the user of the app. It's cluttering up the display
with information which is essentially useless. Pretty much the only
time I ever look at a file owner is when I have some knotty security
issue and I need to assess who might have WRITE_DAC permission. The
group - never; it really is a relic.

The file owner & group simply don't play the same role in Windows
security that they do in *nix. The trouble is that there isn't a
simple alternative: most files, even with default security, will
have two or three groups involved in their security at different
levels.

BTW, wanna beta test a really cool CLI mass file renaming tool?????

Sure -- I'll have a look. But I can't promise any great amount of
time at present

TJG

 

[Tim Daneliuk]

It's hardly worth disputing I suppose, but I would argue that simply
presenting the owner & group of a file in Windows is actually doing
a disservice to the user of the app. It's cluttering up the display
with information which is essentially useless. Pretty much the only
time I ever look at a file owner is when I have some knotty security
issue and I need to assess who might have WRITE_DAC permission. The
group - never; it really is a relic.

The file owner & group simply don't play the same role in Windows
security that they do in *nix. The trouble is that there isn't a
simple alternative: most files, even with default security, will
have two or three groups involved in their security at different
levels.


Sure -- I'll have a look. But I can't promise any great amount of
time at present

TJG

I will announce the Beta for 'tren' here and you (and anyone else) can have at it.