Re: [Patches] PC\config.[hc] changes for Win64
On Mon, May 08, 2000 at 10:16:42AM -0400, Guido van Rossum wrote:
The patch to config.h looks big but it really is not. These are the effective changes: - MS_WINxx are keyed off _WINxx - SIZEOF_VOID_P is set to 8 for Win64 - COMPILER string is changed appropriately for Win64
One thing worries me: if COMPILER is changed, that changes sys.platform to "win64", right? I'm sure that will break plenty of code which currently tests for sys.platform=="win32" but really wants to test for any form of Windows. Maybe sys.platform should remain win32?
No, but yes. :( Actually I forgot to mention that my config.h patch changes the PLATFORM #define from win32 to win64. So yes, you are correct. And, yes (Sigh) you are right that this will break tests for sys.platform == "win32". So I guess the simplest thing to do is to leave it as win32 following the same reasoning for defining MS_WIN32 on Win64:
The idea is that the common case is that code specific to Win32 will also work on Win64 rather than being specific to Win32 (i.e. there is more the same than different in WIn32 and Win64).
What if someone needs to do something in Python code for either Win32 or Win64 but not both? Or should this never be necessary (not likely). I would like Mark H's opinion on this stuff. Trent -- Trent Mick trentm@activestate.com
[Trent]
What if someone needs to do something in Python code for either Win32 or Win64 but not both? Or should this never be necessary (not likely). I would like Mark H's opinion on this stuff.
OK :-) I have always thought that it _would_ move to "win64", and the official way of checking for "Windows" will be sys.platform[:3]=="win". In fact, Ive noticed Guido use this idiom (both stand-alone, and as :if sys.platform[:3] in ["win", "mac"]) It will no doubt cause a bit of pain, but IMO it is cleaner... Mark.
[Trent]
What if someone needs to do something in Python code for either Win32 or Win64 but not both? Or should this never be necessary (not likely). I would like Mark H's opinion on this stuff.
[Mark]
OK :-)
I have always thought that it _would_ move to "win64", and the official way of checking for "Windows" will be sys.platform[:3]=="win".
In fact, Ive noticed Guido use this idiom (both stand-alone, and as :if sys.platform[:3] in ["win", "mac"])
It will no doubt cause a bit of pain, but IMO it is cleaner...
Hmm... I'm not sure I agree. I read in the comments that the _WIN32 symbol is defined even on Win64 systems -- to test for Win64, you must test the _WIN64 symbol. The two variants are more similar than they are different. While testing sys.platform isn't quite the same thing, I think that the same reasoning goes: a win64 system is everything that a win32 system is, and then some. So I'd vote for leaving sys.platform alone (i.e. "win32" in both cases), and providing another way to test for win64-ness. I wish we had had the foresight to set sys.platform to 'windows', but since we hadn't, I think we'll have to live with the consequences. The changes that Trent had to make in the standard library are only the tip of the iceberg... --Guido van Rossum (home page: http://www.python.org/~guido/)
It will no doubt cause a bit of pain, but IMO it is cleaner...
Hmm... I'm not sure I agree. I read in the comments that the _WIN32 symbol is defined even on Win64 systems -- to test for Win64, you must test the _WIN64 symbol. The two variants are more similar than they are different.
Yes, but still, one day, (if MS have their way :-) win32 will be "legacy". eg, imagine we were having the same debate about 5 years ago, but there was a more established Windows 3.1 port available. If we believed the hype, we probably _would_ have gone with "windows" for both platforms, in the hope that they are more similar than different (after all, that _was_ the story back then).
The changes that Trent had to make in the standard library are only the tip of the iceberg...
Yes, but OTOH, the fact we explicitely use "win32" means people shouldnt really expect code to work on Win64. If nothing else, it will be a good opportunity to examine the situation as each occurrence is found. It will be quite some time before many people play with the Win64 port seriously (just like the first NT ports when I first came on the scene :-) So, I remain a +0 on this - ie, I dont really care personally, but think "win64" is the right thing. In any case, Im happy to rely on Guido's time machine... Mark.
To help me understand the significance of win64 vs. win32, can you list the major differences? I thought that the main thing was that pointers are 64 bits, and that otherwise the APIs are the same. In fact, I don't know if WIN64 refers to Windows running on 64-bit machines (e.g. Alphas) only, or that it is possible to have win64 on a 32-bit machine (e.g. Pentium). If it's mostly a matter of pointer size, this is almost completely hidden at the Python level, and I don't think it's worth changing the plaform name. All of the changes that Trent found were really tests for the presence of Windows APIs like the registry... I could defend calling it Windows in comments but having sys.platform be "win32". Like uname on Solaris 2.7 returns SunOS 5.7 -- there's too much old code that doesn't deserve to be broken. (And it's not like we have an excuse that it was always documented this way -- this wasn't documented very clearly at all...) It's-spelt-Raymond-Luxury-Yach-t-but-it's-pronounced-Throatwobbler-Mangrove, --Guido van Rossum (home page: http://www.python.org/~guido/)
To help me understand the significance of win64 vs. win32, can you list the major differences? I thought that the main thing was that pointers are 64 bits, and that otherwise the APIs are the same. In fact, I don't know if WIN64 refers to Windows running on 64-bit machines (e.g. Alphas) only, or that it is possible to have win64 on a 32-bit machine (e.g. Pentium).
The 64 bit pointer change propagates to related types like size_t and window procedure parameters. Running the 64 bit checker over Scintilla found one real problem and a large number of strlen returning 64 bit size_ts where only ints were expected. 64 bit machines will continue to run Win32 code but it is unlikely that 32 bit machines will be taught to run Win64 code. Mixed operations, calling between 32 bit and 64 bit code and vice-versa will be fun. Microsoft (unlike IBM with OS/2) never really did the right thing for the 16->32 bit conversion. Is there any information yet on mixed size applications? Neil
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 :-) Its-times-like-this-we-really-need-that-time-machine-ly, Mark.
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/)
Guido van Rossum writes:
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?
Since no one else has responded, here's some stuff from MS on the topic of Win64: http://www.microsoft.com/windows2000/guide/platform/strategic/64bit.asp This document talks only of the Itanium (IA64) processor, and doesn't mention the Alpha at all. I know the NT shipping on Alpha machines is Win32, though the actual application code can be 64-bit (think "32-bit Solaris on an Ultra"); just the system APIs are 32 bits. The last link on the page links to some more detailed technical information on moving application code to Win64. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
On Tue, 9 May 2000, Fred L. Drake, Jr. wrote:
Guido van Rossum writes:
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?
Since no one else has responded, here's some stuff from MS on the topic of Win64:
http://www.microsoft.com/windows2000/guide/platform/strategic/64bit.asp
This document talks only of the Itanium (IA64) processor, and doesn't mention the Alpha at all. I know the NT shipping on Alpha machines is Win32, though the actual application code can be 64-bit (think "32-bit Solaris on an Ultra"); just the system APIs are 32 bits.
Windows is no longer made/sold for the Alpha processor. That was canned in August of '99, I believe. Possibly August 98. Basically, Windows is just the x86 family, and Win/CE for various embedded processors. Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein writes:
Windows is no longer made/sold for the Alpha processor. That was canned in August of '99, I believe. Possibly August 98.
<sigh/> -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
Since no one else has responded, here's some stuff from MS on the topic of Win64:
http://www.microsoft.com/windows2000/guide/platform/strategic/64bit.asp
Thanks, this makes more sense. I guess that Trent's interest in Win64 has to do with an early shipment of Itaniums that ActiveState might have received. :-) The document confirms my feeling that WIN64 vs WIN32, unlike WIN32 vs WIN16, is mostly a compiler issue, and not a user experience or OS functionality issue. The table lists increased limits, not new software subsystems. So I still think that sys.platform should be 'win32', to avoid breaking existing apps. --Guido van Rossum (home page: http://www.python.org/~guido/)
Thanks, this makes more sense. I guess that Trent's interest in Win64 has to do with an early shipment of Itaniums that ActiveState might have received. :-)
Could be.... Or maybe we don't have any Itanium boxes. :) Here is a good link on MSDN: Getting Ready for 64-bit Windows http://msdn.microsoft.com/library/psdk/buildapp/64bitwin_410z.htm More specifically this (presuming it is being kept up to date) documents the changes to the Win32 API for 64-bit Windows: http://msdn.microsoft.com/library/psdk/buildapp/64bitwin_9xo3.htm I am not a Windows programmer, but the changes are pretty minimal. Summary: Points for sys.platform == "win32" on Win64: Pros: - will not break existing sys.platform checks - it would be nicer for casual Python programmer to have platform issues hidden, therefore one symbol for the common Windows OSes is more of the Pythonic ideal than "the first three characters of the platform string are 'win'". Cons: - may need to add some other mechnism to differentiate Win32 and Win64 in Python code - "win32" is a little misleading in that it refers to an API supported on Win32 and Win64 ("windows" would be more accurate, but too late for that) Points for sys.platform == "win64" on Win64: Pros: - seems logically cleaner, given that the Win64 API may diverge from the Win32 API and there is no other current mechnism to differentiate Win32 and Win64 in Python code Cons: - may break existing sys.platform checks when run on Win64 Opinion: I see the two choices ("win32" or "win64") as a trade off between: - Use "win32" because a common user experience should translate to a common way to check for that environment, i.e. one value for sys.platform. Unfortunately we are stuck with "win32" instead of something like "windows". - Use "win64" because it is not a big deal for the user to check for sys.platform[:3]=="win" and this way a mechanism exists to differentiate btwn Win32 and Win64 should it be necessary. I am inclined to pick "win32" because: 1. While it may be confusing to the Python scriptor on Win64 that he has to check for win*32*, that is something that he will learn the first time. It is better than the alternative of the scriptor happily using "win64" and then that code not running on Win32 for no good reason. 2. The main question is: is Win64 so much more like Win32 than different from it that the common-case general Python programmer should not ever have to make the differentiation in his Python code. Or, at least, enough so that such differentiation by the Python scriptor is rare enough that some other provided mechanism is sufficient (even preferable). 3. Guido has expressed that he favours this option. :) then change "win32" to "windows" in Py3K. Trent -- Trent Mick trentm@activestate.com
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 :-)
Maybe someone has made noise about this before I joined the discussion, but I see the absence of a mixed mode being a big problem for users. I don't think that there will be the 'quick clean" migration from 32 to 64 that there was for 16 to 32. It doesn't offer that much for most applications. So there will need to be both 32 bit and 64 bit versions of Python present on machines. With duplicated libraries. Each DLL should be available in both 32 and 64 bit form. The IDEs will have to be available in both forms as they are loading, running and debugging code of either width. Users will have to remember to run a different Python if they are using libraries of the non-default width. Neil
[Neil Hodgson]
Maybe someone has made noise about this before I joined the discussion, but I see the absence of a mixed mode being a big problem for users. ...
Intel doesn't -- they're not positioning Itanium for the consumer market. They're going after the high-performance server market with this, and most signs are that MS is too.
... It doesn't offer that much for most applications.
Bingo. plenty-of-time-to-panic-later-if-end-users-ever-care-ly y'rs - tim
One more data point: Windows CE uses "wince", and I certainly dont believe this should be "win32" (although if you read the CE marketting stuff, they would have you believe it is close enough that we should :-). So to be _truly_ "windows portable", you will still need [:3]=="win" anyway :-) Mark.
Windows CE uses "wince", and I certainly dont believe this should be "win32" (although if you read the CE marketting stuff, they would have you believe it is close enough that we should :-).
So to be _truly_ "windows portable", you will still need [:3]=="win" anyway :-)
That's a feature :-). Too many things we think we know are true on Windows don't hold on Win/CE, so it's worth being more precise. I don't believe this is the case for Win64, but I have to admit I speak from a position of ignorance -- I am clueless as to what defines Win64. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
[Trent]
What if someone needs to do something in Python code for either Win32 or Win64 but not both? Or should this never be necessary (not likely). I would like Mark H's opinion on this stuff.
[Mark]
OK :-)
I have always thought that it _would_ move to "win64", and the official way of checking for "Windows" will be sys.platform[:3]=="win".
In fact, Ive noticed Guido use this idiom (both stand-alone, and as :if sys.platform[:3] in ["win", "mac"])
It will no doubt cause a bit of pain, but IMO it is cleaner...
Hmm... I'm not sure I agree. I read in the comments that the _WIN32 symbol is defined even on Win64 systems -- to test for Win64, you must test the _WIN64 symbol. The two variants are more similar than they are different.
While testing sys.platform isn't quite the same thing, I think that the same reasoning goes: a win64 system is everything that a win32 system is, and then some.
So I'd vote for leaving sys.platform alone (i.e. "win32" in both cases), and providing another way to test for win64-ness.
Just curious, what's the output of platform.py on Win64 ? (You can download platform.py from my Python Pages.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Tue, May 09, 2000 at 11:09:40AM +0200, M.-A. Lemburg wrote:
Just curious, what's the output of platform.py on Win64 ? (You can download platform.py from my Python Pages.)
I get the following: """ The system cannot find the path specified win64-32bit """ Sorry, I did not hunt down the "path" error message. Trent -- Trent Mick trentm@activestate.com
Trent Mick wrote:
On Tue, May 09, 2000 at 11:09:40AM +0200, M.-A. Lemburg wrote:
Just curious, what's the output of platform.py on Win64 ? (You can download platform.py from my Python Pages.)
I get the following:
""" The system cannot find the path specified
Hmm, this probably originates from platform.py trying to find the "file" command which is used on Unix.
win64-32bit
Now this looks interesting ... 32-bit Win64 ;-)
"""
Sorry, I did not hunt down the "path" error message.
Trent
-- Trent Mick trentm@activestate.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev
-- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (8)
-
Fred L. Drake, Jr. -
Greg Stein -
Guido van Rossum -
M.-A. Lemburg -
Mark Hammond -
Neil Hodgson -
Tim Peters -
Trent Mick