DEP and density
"Altering existing API calls to have different semantics (e.g. DEP) to what they usually have will break any existing applications that use JIT compilation, for example."
FWIW, DEP has been part of the Win32 API since the early days. Dig out the very first Win32 SDK, and there you will see VirtualProtect() and friends in all their glory. http://msdn.microsoft.com/en-us/library/ms810627.aspx is an old (1993) article describing some of these.
The catch is that it took another ten years or so before we saw x86 hardware support this. By then, the other WNT hardware platforms (capable of DEP before DEP had a name) had ceased to be. (incidentally, it would not do any harm to use these API functions on non-DEP hardware, they simply turn into NOPs -- there was never any excuse not to support DEP, even back in 1993)
But yes, JITters should face difficulties and it is telling that both shockwave and java forced IE to run without DEP until quite recently. The lack of flash is still making 64-bit IE a daunting user experience.
Most applications however do not use features that would require any special thought vis-a-vis DEP. There were some surprises in the early days, e.g. with Borland Delphi it was commonplace to patch the runtime library at runtime, but it did not take long until these patches had been made DEP compliant (using VirtualProtect() as I recall).
The real issue however is that some ISVs insist on eating the same dog crap their customers do. I.e. if most customers use WinXP, then by golly, the developers must use XP too. How could anyone implement ASLR support then? I remember advocating using WinNT back in the day, to idiot developers who insisted on using Win95. They were hopelessly crashing left and right with that sorry excuse for an OS, but could not abandon it because of a misplaced sympathy with their customers... It was bizarre then, and it is just as bizarre now.
I have always felt that even half-decent software developers should help lead their customers/users into the future. Be it through providing a smarter user interface, faster performance or better integration. You rarely accomplish that by sticking to ten year old technology. Most people have seen the newest flavour of MSOffice, and many of them will expect new software to adopt that particular look and feel (or something equally impressive). 64-bit Windows offers improved security (MS finally removed the feature where drivers can hook into the kernel), so that means decent ISVs should help people make the transition to 64-bit Windows. (When I joined my current employer, one of my first priorities were to make sure to help them realize they could get their software to run just fine with 64-bit Windows, something they had failed at in the past due to a basic lack of know-how)
In any case, it is sad to see how an ISV like Adobe can be so slow at adopting e.g. Win64 support for flash.