[Python-Dev] Re: [Patches] PC\config.[hc] changes for Win64

[Guido van Rossum]

> > To help me understand the significance of win64 vs. win32, can you
> > list the major differences?  I thought that the main thing was that
> 
> I just saw Neils, and Trent may have other input.
> 
> However, the point I was making is that 5 years ago, MS were telling us
> that the Win32 API was almost identical to the Win16 API, except for the
> size of pointers, and dropping of the "memory model" abominations.
> 
> The Windows CE department is telling us that CE is, or will be, basically
> the same as Win32, except it is a Unicode only platform.  Again, with 1.6,
> this should be hidden from the Python programmer.
> 
> Now all we need is "win64s" - it will respond to Neil's criticism that
> mixed mode programs are a pain, and MS will tell us what "win64s" will
> solve all our problems, and allow win32 to run 64 bit programs well into
> the future.  Until everyone in the world realizes it sucks, and MS promptly
> says it was only ever a hack in the first place, and everyone should be on
> Win64 by now anyway :-)

OK, I am beginning to get the picture.

The win16-win32-win64 distinction mostly affects the C API.  I agree
that the win16/win32 distinction was huge -- while they provided
backwards compatible APIs, most of these were quickly deprecated.  The
user experience was also completely different.  And huge amounts of
functionality were only available in the win32 version (e.g. the
registry), win32s notwithstanding.

I don't see the same difference for the win32/win64 API.  Yes, all the
APIs have changed -- but only in a way you would *expect* them to
change in a 64-bit world.  From the descriptions of differences, the
user experience and the sets of APIs available are basically the same,
but the APIs are tweaked to allow 64-bit values where this makes
sense.  This is a big deal for MS developers because of MS's
insistence on fixing the sizes of all datatypes -- POSIX developers
are used to typedefs that have platform-dependent widths, but MS in
its wisdom has decided that it should be okay to know that a long is
exactly 32 bits.

Again, the Windows/CE user experience is quite different, so I agree
on making the user-visible platform is different there.  But I still
don't see that the user experience for win64 will be any difference
than for win32.

Another view: win32 was my way of saying the union of Windows 95,
Windows NT, and Windows 98, contrasted to Windows 3.1 and non-Windows
platforms.  If Windows 2000 is sufficiently different to the user, it
deserves a different platform id (win2000?).

Is there a connection between Windows 2000 and _WIN64?

--Guido van Rossum (home page: http://www.python.org/~guido/)