Win32All On 64-Bit Operating Systems
Tim Daneliuk
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 Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
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
> On 17/03/2010 16:32, Tim Daneliuk wrote:
>> 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/
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
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.
>> 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.
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
I will announce the Beta for 'tren' here and you (and anyone else) can have at it.