by Michael S. Kaplan, published on 2009/08/05 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2009/08/05/9857486.aspx
So McDowell asked in a comment:
Apologies if this is the wrong place, or this has come up before, but does 64bit Windows sound the death knell for OEM code pages on the console? I haven't run a 64-bit version of Windows, so I can't check if I'm just behind the times.
I can see the point of cmd.exe defaulting to a DOS codepage for DOS compatibility, but if the operating system no longer supports 16bit apps, it might be a good time to change. I live in hope that, even if Unicode isn't on the table, it might one day default to the system default "ANSI" encoding. (Yep, I'm aware of TT fonts/chcp and PowerShell.)
Or are there deeper issues of which I am not aware? I've never had cause to go near the recovery console and I know the rules change on full-screen.
Now yes this was very very very offtopic and it would have been better asked the Suggestion Box, but I figured I'd just answer it -- he knows for next time! :-)
Let's start by looking at the argument itself -- the relationship between 16-bit apps and 32-bit DOS (i.e. OEM) apps. We'll momentarily stipulate that there is such a relationship.
One could perhaps have made the argument when 64-bit first came out, in Server 2003 and 64-bit XP.
But now that
have shipped with things as they are, it is a bit too late to make such an argument.
No of course there is a flaw in the stipulation, too. Because the two are not coupled together so closely!
The use of 8-bit SBCS and MBCS code pages predates Unicode, obviously. But as much of a fan as I may be of Unicode, I do not claim that 64-bit support is connected; each and every documented ANSI and OEM function in the Win32 API is a regular 32-bit function call on 32-bit platforms and 64-bit function call on 64-bit platforms. Pointers to OEM strings are 64-bit pointers, and so on.
And more to the point, the fact that so many of the OEM code pages date back to the time when there were only 16 bit apps doesn't mean that dropping support for one means dropping support for the other.
Things don't work that way; they can't!
Changes to make the OEMCP or a locale equal the ACP are definitely not possible, either -- no one wants to break as many applications as that would do....
John Cowan on 6 Aug 2009 12:03 AM:
I'm confused. Of course on 64-bit platforms pointers (including pointers to functions) are 64 bits. But I had understood that 64-bit Windows was LLP64 -- that is, ints and longs are both still 32 bits, just as on 32-bit Windows.
Michael S. Kaplan on 6 Aug 2009 12:34 AM:
Yes, ints and longs are still 32 bits. Strings are the same size on both platforms (8 bit or 6 bit units), and pointers are 32bit on one an 64bit on the other....
But WOW support for 16bit was removed from 64bit platforms.
Doug Ewell on 10 Aug 2009 1:59 PM:
What's this I'm reading about "6-bit support" and "6-bit units"? Is there some version of Windows that supports ECMA-1 or BCDIC?
That was a typo, Doug. Fixed now. :-)
Random832 on 13 Aug 2009 9:27 AM:
The point of the original question seems to be that (apart from some aspects of cmd.exe itself), the only use of the OEMCP is by DOS applications (which are nearly univerally 16-bit), and that windows console applications use (or are supposed to use) unicode console functions
Does 64-bit windows actually drop support for DOS applications (as opposed to dropping WoW for Win16) as the person asking the question seems to believe?
Michael S. Kaplan on 13 Aug 2009 3:11 PM:
16bit apps are not supported on 64-bit Windows, but non-Unicode apps and especially 32bit apps are; this includes virtually every console app written in the last decade (you cannot build 16bit apps with any modern tool I know of).
Win16 and 64bit are NOT related!