AnyCPU Exes are usually more trouble than they're worth

A Disagreement

Stephen Cleary — Tue, 09 Jun 2009 16:19:36 GMT

I remain ambiguous to your conclusion. :)

Disagreements:

1A. Native DLL interop is a common stumbling point, but one that is quickly resolved with a mere Google search. If a company advertises support for a 64-bit platform, they should test on it.

1B. CLR bugs are rare; I've never encountered one (BCL bugs are much more common). A 32-bit platform has a 32-bit OS and 32-bit CLR underneath the code; a 64-bit platform has a 64-bit OS, WoW, and 32-bit CLR underneath, which removes one possibility for platform bugs (the 64-bit CLR) but adds another (WoW).

2. Hmmm. I don't actually know about this one. Never tested. :)

3. I'm sad to hear that historical debugging won't be supported on 64-bit. I never use EnC, though. I do all my development on a 64-bit platform quite happily.

I think there's only one really good reason behind this change: the BadImageFormatException on 32-bit P/Invoke.

My opinion is that x86 *should have been* the default in VS2008, but should be AnyCPU in the future:

1. Developers as a whole are in the process of moving from 32-bit to 64-bit platforms for development. This means all the "64-bit only" mistakes (such as P/Invoking a 32-bit DLL) will be caught immediately instead of in the testing phase. This will also naturally increase demand for historical debugging / EnC on 64-bit platforms.

2. WoW64 is not installed by default on Server 2008 R2 Core:

http://blogs.msdn.com/volkerw/archive/2009/02/09/32-bit-optional-in-windows-server-2008-r2.aspx

It's possible that future OS releases (e.g., Server 2012 Standard) may follow the same path.

VS2010 is a tough call. I believe the default should definitely be AnyCPU in the VS2012, so I can see where keeping the default as AnyCPU in VS2010 would have fewer surprises for developers. On the other hand, people still do trip up on 32-bit P/Invoke, so changing the default to x86 in VS2010 would benefit them.

Conclusion: ambiguity. There is no correct choice. :)

I know! Do it both ways! Have a checkbox at install time that allows the developer to choose their own default. ;)

http://blogs.msdn.com/oldnewthing/archive/2009/02/13/9416485.aspx

Interesting Finds: June 9, 2009

Jason Haley — Tue, 09 Jun 2009 17:22:02 GMT

Interesting Finds: June 9, 2009

re: AnyCPU Exes are usually more trouble than they're worth

ShadowChaser — Tue, 09 Jun 2009 19:32:10 GMT

I must admit, I was a bit disappointed when I saw the change to x86. I'm right on the fence in terms of the logic - my company generally uses AnyCPU when we can, and fully test against 64-bit.

WoW may be "good enough" or "just as fast today", but it won't be forever. Case in point - when the NTVDM & WOW32 were ripped out of 64-bit Windows, there were still legacy apps such as major installation packages shipping 16-bit binaries.

The next server version of Windows, Windows Server 2008 R2, won't have support for 32-bit hardware. I'd be shocked if the client OS release after Windows 7 shipped with 32-bit support too.

Most people treat the Visual Studio defaults as the "best practices". A percentage of assembies written as AnyCPU would might not have been tested on a 64-bit OS, but factor that against the huge number of 100% managed applications that work perfectly.

I'm not sure if Edit and Continue is a good argument against 64-bit. I've always considered it a "dubious feature" and one of the weirdo VB features that got carried into C#. I'm sure people use it, but (so far) I've never met a developer that does. You said it yourself - it's not high enough priority to add 64-bit Edit and Continue.

I know it's not Microsoft's intent, but 64-bit still feels like second class. Silverlight is a really good example of the chicken and the egg problem we're facing:

* Flash doesn't have a 64-bit IE plugin

* No one runs 64-bit IE because Flash doesn't work

* Silverlight doesn't provide a 64-bit assembly because no one runs 64-bit IE

* adobe doesn't build a 64-bit plugin for Flash because no one is using 64-bit IE and even Microsoft isn't providing 64-bit plugins. Argh!

I love 64-bit and the extra memory capcity I get, but it's extremely frustrating supporting a frankenstein installation of 32-bit in a 64-bit world. I have programs that literally have 32-bit MSI installers, 64-bit Explorer plugins, and 32-bit helper processes that are loaded by the 64-bit Explorer plugins. Ugh.

It's a bit psychological - many people don't want Visual Studio generating what is perceived to be "legacy applications" by default. Regardless of how well architected WOW64 is, it will still feel second class and inferior to many people.

That said, I frequently encounter two common problems when writing AnyCPU .NET apps:

* The 64-bit version of SetWindowLong has a different name than the 32-bit version (ie/ it's now SetWindowLongPtr). It's probably the #1 bug most 64-bit interop developers make - the MSDN documentation says to call "SetWindowLong", but internally the Win32 SD maps it to SetWindowLongPtr. This is a tough one to work around and typically requires wrapper/helper functions. It would be great if there was a cleaner way to do this, or at very least if it could be detected as a compiler warning somehow.

* It's difficult to deploy a "side by side" 32-bit and 64-bit unmanaged assembly and have an AnyCPU compiled executable intelligently decide which one to load. It's difficult even when developers want to hard code the names of the two different DLLs - from what I've seen, most developers give up and compile two separate .NET executables, even though the unmanaged assemblies are being dynamically linked. I'm not sure if there's an easy way to fix this, but it sure would be nice to provide separate 32-bit and 64-bit unmanaged DLL names to pinvoke.

Put me down in the AnyCPU default camp. Tough decision for the VS team though!

re: AnyCPU Exes are usually more trouble than they're worth

rmbyers — Tue, 09 Jun 2009 19:51:35 GMT

Some good points, thanks.

One argument against which I think is legitimate and deserves some real thought is that we'd all like to get to a simpler 64-bit-only world as quickly as we can (to avoid the complexity, confusion and cost of the WOW). By changing the defaults, we might be slowing down that transition (chicken-and-egg problem). That's definitely worth taking into account, but I don't think it's a terribly strong argument until at least a large fraction of native applications out there support 64-bit. Maybe the right thing to do here at some future point is to make x64 the default (so people have to actually opt into supporting 'ancient legacy OSes' <grin>) - but we're clearly not there yet.

Anyway, I'm sure there's going to be lots of great points here, and I'm not going to try to debate them all. I will, however, make sure the product team responsible for this change knows about the comments so they can consider whether anything should change for RTM. Thanks!

re: AnyCPU Exes are usually more trouble than they're worth

ssteesy — Tue, 16 Jun 2009 18:43:20 GMT

Excellent discussion of the x86/x64 transistion in development.

I also have been running on strictly x64 OSes for years now, and customer are finally catching up. In the past 6 months we have had a huge uptick in requests for x64 version of our applications. I've also noticed a lot or laptops and PC being advertised coming preinstalled with Vista x64 ... so I think we may make a majority of the trasistion in the next 2-3 years, but I'm also sure we'll be keeping the WOW for a while. So, I'd rather you keep the default as "Any CPU".

Now I have a complaint ... I have been waiting for Edit and Continue on x64 ever since it didn't make it into Whibdey. Someone above said they never use it and don't know any developers that do and say it comes from VB. I disagree! I've never been a VB developer, I was VERY pleased when I started using Visual Studio 6's C/C++ compiler and it supported making code changes on the fly and continuing execution. I do it all the time, as when you are deep in a trace and debug session and it has taken literally hours to get to the source of a problem, it is absolutely wonderful to be able to make a minor logic change, move the line of execution back in front of the change and step through it again, see that it works and continue tracing to find other issues. Now that customers want x64 support because they have machines with 4+ GB of RAM (and our applications can use it) it is becoming a major pain trying to debug in x64 without Edit and Continue.

re: AnyCPU Exes are usually more trouble than they're worth

rmbyers — Tue, 16 Jun 2009 21:05:40 GMT

Thanks for the feedback ssteesy.

I hear you on x64 EnC - we really wanted to add it in CLR v4, but since it requires some significant work on the x64 JIT compiler it had to be traded-off against features that affect ALL users (like perf improvements) and ultimately we decided the cost/benefit was higher for those other features. One of the things we use in determining priority is the number/strength of 'connect' votes. This one currently has only 5, feel free to increase the vote here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=355849

That said, we have a plan for getting this nearly "for free" in a future release by coupling it with some other JIT work we're planning on doing. That, coupled with increasing x64 development as you mention, should make the cost/benefit ratio much more clearly in favor of doing the work.