Microsoft WTF
-
I know you don't have to look hard to find Microsoft bloopers, but they for me they never seem to get old.
Windows PowerShell 1.0 Release Candidate 2 (RC2) English update package for Windows Server 2003
The 64-bit version of Windows PowerShell is installed in the following folder:
%Windir%\System32\WindowsPowerShell\V1.0
The 32-bit version of Windows PowerShell is installed in the following folder:
%Windir%\Syswow64\WindowsPowerShell\V1.0So 64-bit goes to system32 and 32-bit goes to syswow64. Brillant!
-
Weird, but not a WTF.
WOW64, short for "Windows-32-on-Windows-64," is responsible for providing two levels of support for 32-bit legacy applications.
First, the system files in Windows x64 Edition are not present on just the Windows\System32 folder, but split into two folders to separate the 32-bit applications from the 64-bit applications. The WOW64 subsystem intercepts calls from a 32-bit legacy application and redirects it to the Windows\SysWow64 folder; see Figure 1. If the call is from a 64-bit application, then the call is routed to the Windows\System32 folder and does not involve the WOW64. What's notable here is that Microsoft has retained the name System32 for the folder, which hosts the 64-bit system files. Figure 2, a snapshot from a system running Windows Server 2003 x64 Edition, highlights the classification of the Program Files folder into Program Files, which stores 64-bit applications and Program Files(x86), which stores 32-bit legacy applications.
Second, the WOW64 subsystem also provides redirection at the Registry level; see Figure 3. If the call is from a 32-bit application, then the call to access the HKLM\Software registry hive is intercepted by the WOW64 subsystem and redirected to the HKLM\Software\Wow6432Node. If the call is from a 64-bit application, then it is routed to the HKLM\ Software node. Figure 4, the Registry from a system running Windows 2003 Server x64 Edition, shows the Wow6432Node.
Although the compatibility has been achieved with respect to 32-bit applications, the same is not true regarding device drivers. The 64-bit edition requires 64-bit native drivers for all devices that are part of the system.
From http://www.ddj.com/184405994
Its there for backwards compatability. Don't want to break all those (misbehaving) applications that have hard-coded a path to the SYSTEM32 directory:
Andreas Magnusson: I don't quite understand; it's (some of) the 32-bit apps that hardcode "system32", don't they want the 32-bit binaries?
Raymond Chen: It turns out they usually don't! A 32-bit program that builds the path "C:\Windows\System32\control.exe" probably wants the 64-bit control panel, for example.
-
Yea, it's weird.
But if you want a real WTF from MSFT, then it should be this - VS .Net needing life support to run on Vista. What were they thunking ?
-
So, WTF to myself for mis-WTFing this WTFery. I guess I should have RTFM.
-
[quote user="kuroshin"]But if you want a real WTF from MSFT, then it should be this - VS .Net needing life support to run on Vista. What were they thunking ?
[/quote] I'm not sure what you mean by this. Are you referring to the fact that VS2005 may be the only Visual Studio product that is supported on Vista? (VS2003 won't work, apparently.)Link with details: http://searchvb.techtarget.com/originalContent/0,289142,sid8_gci1219579,00.html
-
[quote user="BradC"]
[quote user="kuroshin"]But if you want a real WTF from MSFT, then it should be this - VS .Net needing life support to run on Vista. What were they thunking ?
[/quote] I'm not sure what you mean by this. Are you referring to the fact that VS2005 may be the only Visual Studio product that is supported on Vista? (VS2003 won't work, apparently.)Link with details: http://searchvb.techtarget.com/originalContent/0,289142,sid8_gci1219579,00.html
[/quote]
Yes, I meant that. Even VS 2005 requires a patch to get it running in Vista.
-
[quote user="kuroshin"]What were they thunking ?[/quote]
Pun intended?
-
Yep, pun was intentional.
-
There actually seems to be some valid reasons for the problem:
Vista support
I think we are seeing some reaction to this on all fronts. People raise the question of whether or not VS’s stance on Vista support for its various versions signals a problem with Vista compatibility. I do not believe so. VERY few applications are like VS. The problems VS has running on Vista generally aren’t with “normal” application like code. The single biggest source of issues is the area surrounding the debugger. Not many applications are that invasive. Vista made a lot of changes to really try to lock down on security to further reduce vulnerability. Those kinds of changes really run contrary to the kinds of invasive things a debugger needs to do. Innovation requires change and change results in work. The Windows team goes to UNBELIEVABLE lengths to keep compatibility with previous applications and well beyond what you might expect.
Like you, we have resource constraints. It might look like Microsoft is a huge company with infinite resources but, unfortunately, it’s not. We are just as constrained as everyone else in the world as to how we invest our time and money. I can assure you we have spent a lot management time wringing our hands over what the right thing to do here is. All work we do comes at an opportunity cost. For example, if we go back and make VS2002 work on Vista, we have to trade that off against not making progress on Orcas. Ultimately, we balanced all of these trade-offs and came up with this plan. The plan is to support our run time environments on Vista and to support VB6, VS2005, Orcas and all future versions. Would it be good to support more? Yes. Is it worth the opportunity cost? We think it isn’t.
Of all the things Microsoft is and isn’t, we are very responsive to customer feedback. We made the decision that we think is in the best interest of our customers. If customers come back broadly and tell us they disagree, then we’ll reassess that decision. All of our goals here are the same – making everyone as productive and successful as possible. I don’t mean to sound patronizing here – I really believe it.
Brian (http://blogs.msdn.com/bharry/archive/2006/09/27/773632.aspx)
and they may actually be reconsidering the issue:
-
GDB runs on Windows 95 and up, Linux, most UNIX-es, and various obscure platforms. Why can't Microsoft manage to get their debugger to work on more than one version of their own?
-
[quote user="kuroshin"]
Yes, I meant that. Even VS 2005 requires a patch to get it running in Vista.
[/quote]
What the hell are you talking about? I'm running VS.Net 2005 on Vista RC1 and it installed perfectly. It runs perfectly. Well it runs as well as it does on XP. You know what I mean.
-
It could run on Vista RC1 without any hitch.
But as people have pointed out, a "patch" may have to be installed on the Vista production release. That's left upto Microsoft.
They've stated that it will run without any hitch except in certain circumstances. My guess is that the remote debugging components will need to be patched because of the difference in the security models in XP and Vista.
-
@error As expected, your profile contains an error. You've been here for 10 years.
-
The System32 vs System64 thread is
-
I was misunderstanding
SysWOW64before it was cool.
-
-
This post is deleted!
-
This post is deleted!
Brian Harry's Blog
