Certainly, virtualization has a role; Win16 needs virtualization these days (no Win16 is available on 64-bit Windows), but we’re really not in a position where we could say, for example, “virtualize all Win32 apps”.

“I think I’ll probe some contacts at MS regarding 64-bit .NET. I may not be able to blog about them (due to NDAs), but you’ve got me curious.”
Well, it depends on what you want to do with “64-bit”. Sure, you can create a lot of objects (it is a 64-bit process, after all), it’s just that I’d like to create huge objects instead of lots of objects.

I do think they should have been forward-looking and made array sizes use ‘long’ rather than ‘int’. Sure, it’d take a hit on 32-bit systems. I don’t care; even in 2002 it was obvious that the days of 32-bit were numbered. Look to the future, not to the past.

I think I’ll probe some contacts at MS regarding 64-bit .NET. I may not be able to blog about them (due to NDAs), but you’ve got me curious.

Things would get a bit more tricky if we were talking something more ambitious–a wholesale replacement (rather than merely a tidying up) of User32 with something good, say–so that would require more effort (one might envisage a User32-workalike layer written to sit on top of WPF, say) but I think could still ultimately be achieved.

Please don’t get me wrong: I’m not suggesting that this would *eliminate* the issues MS faces. Rather, I’m suggesting that it would give them greater scope to move forward without jeopardizing their legacy, by compartmentalizing and isolating it. And I find it incredibly frustrating that even though MS has good infrastructure for this with .NET, it’s not being used.

“A 4GB image file?! Wow! What kind of file is it? Video comes to mind, but you said image, and I’m curious as to what file type it is now”
Oh, for work we get all kinds of huge TIFFs that we would like to manipulate in certain ways (typically convert them to other formats so that their file sizes are a bit smaller…). Standard TIFF is in principle good for up to 4 GiB (though many implementations are restricted to signed 32-bit, i.e. 2 GiB), and there are proposed extensions for 64-bit TIFFs, BigTIFF, and there are certainly applications for such files. Again, this is not to say that creating a bloody great array to hold all the image data is necessarily the best approach to use for such files (especially as they can easily outstrip any reasonably likely amount of memory), but even if you’re dividing the images into chunks, you’ll often want chunks as big as possible.

MMF’s rock. They still haven’t created a wrapper for them … bummer. I wrote one a few years ago, but I’d much rather it just be part of the core .NET framework.

A 4GB image file?! Wow! What kind of file is it? Video comes to mind, but you said image, and I’m curious as to what file type it is now …. :)

I think Vista is the best Windows ever, and it’s the OS I use most of the time (by far). But it took more than *five years* from the release of XP to get there. And there’s no way that Vista is five years of improvement over XP. It’s no wonder that home and business users alike are saying “You know what? XP is good enough. Vista’s not offering anything worthwhile; it’s just bigger, slower, and spuriously different”. There *are* good things about Vista (though many of them not obviously visible; I wrote at length about them at Ars), but there’s very little that’ll make someone who’s of two minds think “gosh, I really must have that”.

MS’s slavish adherence to backwards compatibility–and they *way* in which that BC is achieved–is preventing MS from giving value to its shareholders.

“It’s not a lack of imagination that I have (if you knew me, you’d never suggest that) — it’s the knowledge and first hand experience of the hard truth of doing software development and trying to make money — sometimes you have to ship, even when it’s not what you wanted. You are absolutely underestimating the power of enterprise on Microsoft’s ship and design schedule. The enterprise plays a HUGE role in their every-day decisions. I know for sure — as I have worked there. ”
Sure. But that’s kind of missing the point, I think.

There are ways to provide backwards compatibility that do not hamstring future development. The most obvious thing is *version your libraries*. It’s OK to freeze an old library and introduce a new one. That doesn’t break old applications, and equally, it doesn’t cripple new ones. But MS doesn’t do that, which makes its development much, much harder. Any time MS *does* try to introduce a new feature, MS has to make sure that it doesn’t upset old programs. Why? Because the new feature has to be shoehorned in amongst the old stuff.

This approach simply doesn’t scale well, as MS has discovered on countless previous occasions.

I’m not claiming versioning is a panacea; if the change is big enough it can be very difficult to continue to support the old versions, no matter how good your intentions are (although we have good solutions for that, too–virtualization). But it would provide a hell of a lot more flexibility than MS currently has.

“How much time do think it would take to create a new 64 bit API with a compatibility layer for 32 bit? And how much testing would it require, by both Microsoft and 3rd parties? I can’t fathom it — it’s so high. ”
How much time? Less than it took to deliver Vista, that’s for sure.

“What do you want from a 64 bit API anyway? What’s the real issue?”
I want to write 64-bit applications.

“If you use .NET, you’d normally not have to worry (unless doing PInvokes).”
That’s unfortunately not true. .NET is, unfortunately, 32-bit. Oh, sure, if you run a .NET program on 64-bit Windows it’ll create a 64-bit process. But you can’t, say, allocate an array that’s more than 2^31 elements long. This is annoying, to say the least; I’d like to, for example, work with large image files, and the ability to create 4 GiB byte arrays would make my coding *considerably* simpler. You can take a look for yourself if you don’t believe me; load up mscorlib.dll from the Framework64 directory and take a look at System.Array.LongLength. It just casts the signed 32-bit Length property to long. To deal with these large images, I’d have to do some kind of a chunking mechanism. That’s a huge amount of extra complexity.

With native code, I don’t have an issue. I can just create a 4 GiB array. I’m not saying I would necessarily want to do things this way–although it probably *is* the most efficient way on large-memory systems–but it’d be nice to have the option. To compound the annoyance, .NET doesn’t even have a good memory-mapped file mechanism (MMFs are another good way of handling large data structures). If I want to create lots of little objects (i.e. more than 4 GiB worth of them), I suspect .NET would be good enough, but if I want to create a few huge objects, it actually kind of falls down.

And then there’s all the things that I just can’t access in .NET anyway. Like DirectShow, or Media Foundation, or Core Audio. These are off-limits whether 32- or 64-bit, because they just don’t exist in .NET. P/Invoke is quite good if I want to bring a couple of C API calls into the .NET world, but it’s pretty grim if I want to bring whole APIs with complex data structures over. C++/CLI is a much better option, because it lets me eschew the .NET things entirely. I can ignore .NET Collections and arrays and ValueTypes and just use the C and C++ things directly.

“Microsoft maintains a level of compatibility, even with .NET to make it easier to upgrade. If they didn’t, you’d find developers wouldn’t upgrade. The amount of effort required would exceed their schedules, the perceived benefit may be limited, etc. ”
I don’t agree. I think .NET provides pretty good infrastructure to support MS making breaking changes (especially if they have one version where things are deprecated and a second to remove them; this gives developers plenty of advance notice and opportunity to get their house in order). With .NET’s versioning, breaking changes will only break applications that are *actively maintained* (and hence rebuilt against the latest libraries). They won’t break legacy applications. To me (and the enterprise development I have done), that seems like a more than acceptable compromise.

“The harsh truth is that it’s Microsoft’s customers and developers who are preventing them from moving forward. Look at the number of people who are clinging to XP. How can they move the OS forward if people refuse to change? Imagine if they made a huge jump and all of their favorite software stopped working. It’s just not a simple problem to solve. There is no right answer.”
The reason that people are clinging to XP is because Vista simply isn’t that big a leap (in spite of its extended gestation). A key reason that it’s not a big leap is because its development was so restricted by backwards compatibility.

It’s not a lack of imagination that I have (if you knew me, you’d never suggest that) — it’s the knowledge and first hand experience of the hard truth of doing software development and trying to make money — sometimes you have to ship, even when it’s not what you wanted. You are absolutely underestimating the power of enterprise on Microsoft’s ship and design schedule. The enterprise plays a HUGE role in their every-day decisions. I know for sure — as I have worked there.

How much time do think it would take to create a new 64 bit API with a compatibility layer for 32 bit? And how much testing would it require, by both Microsoft and 3rd parties? I can’t fathom it — it’s so high.

What do you want from a 64 bit API anyway? What’s the real issue? If you use .NET, you’d normally not have to worry (unless doing PInvokes). Microsoft maintains a level of compatibility, even with .NET to make it easier to upgrade. If they didn’t, you’d find developers wouldn’t upgrade. The amount of effort required would exceed their schedules, the perceived benefit may be limited, etc.

The harsh truth is that it’s Microsoft’s customers and developers who are preventing them from moving forward. Look at the number of people who are clinging to XP. How can they move the OS forward if people refuse to change? Imagine if they made a huge jump and all of their favorite software stopped working. It’s just not a simple problem to solve. There is no right answer.

Again, thanks for your comments.

It may well be that people near the bottom of the totem pole care about this kind of thing, but it’s also clear that people at the top–people who make decisions–do not. There is no-one within the company saying “This application’s UI is needlessly non-standard; it reinvents this, this, and this, it’s a pain for users and it’s a pain for maintenance–go fix it”. It just isn’t seen as a priority.

Point 2: “Dude, do you seriously want to conditionalize all of your code just so you can recompile on 64 bit Windows? Do you want a new API just for that? Seriously, what’s the gain?”. No, I don’t want that. And I think it shows an incredible lack of imagination on your part that you think that’s the only alternative.

What I would like to see is a clean 64-bit API, and a 32-bit compatibility library, so I could write 32-bit apps against a workalike of the 64-bit API. This isn’t unprecedented, at all; Microsoft created the Unicode layer for Windows 9x, so that programs could be written to use (NT’s preferred) Unicode APIs against the (narrow char/multibyte) Windows 9x family. Apple produced CarbonLib to allow programs to use Mac OS X’s (semi-modern) Carbon APIs on (legacy) MacOS 9. This isn’t a totally outlandish, never-seen-before concept. It’s something that both Apple and MS have done to ease transitions.

Point 3: It is precisely because Apple to such an extent started with a clean slate that Apple has been able to be much better on keeping APIs clean and powerful. Apple is also willing to deprecate and remove things, which MS never does. This is particularly upsetting in .NET. .NET, unlike Windows proper, has a pretty good versioning mechanism built-in. SxS installation, rolling forward dependencies on minor version changes, that’s all there already. There’s no reason to keep everything old and deprecated hanging around for ever with .NET, and yet that’s the road they’re going down anyway.

Point 4: No, they don’t need to all ship on the same schedule. But you are mistaken if you think that their development is “innovat[ion]” or producing something “unique”. The no-menu thing in WMP, Explorer, IE, WLM, Photo Gallery, etc.–that’s not unique. It’s just coded a bunch of different times. That’s not providing any advantage to any user. It’s not even providing any advantage to MS (because it’s just that much more code to maintain). The reason MS is doing that is simply because there’s no co-ordination between divisions. The left hand is totally clueless about the right hand.

Now, maybe we could let that slide for stuff like WLM, which is a separate download anyway (though I still think first party apps should do a lot better than MS’s do). But for the things that *all ship together on the Vista DVD* to suffer this same reinvention and inconsistency? That stuff *already* has the same ship schedule. It’s *already* being combined into a single release. It is *not* asking a lot for it to be even slightly consistent.

At that point in time, C++ was still also a young language, and Obj-C was actually more compatible with ANSI C than C++ (i.e. it was a strict extension to C).

The conceptual implementation of OO in Obj-C was also better – it is closer to Smalltalk – whereas C++ (and by extension Java) compromised OO in favour of performance. At the time, that was a fair trade-off – NextStep only ran on workstation class machines around the $10,000 price point, whereas C++ apps could run on anything. There was no ‘C++ runtime’ that they ran in.

On the downside, that also means shared libraries rather than shared components and objects.

I think that is the particular strength of Cocoa – the late (runtime rather than compile time) binding makes it easy for existing applications to share components, or pick up new O/S features without recompilation – for example, the standard text class was extended under Tiger to include Spotlight/Google search options, and under Leopard a grammar checker.

My understanding from the debate around the Java bridge, and the more recent Python and Ruby bridges, is that it’s easier to build a bridge to a more dynamic language, than to a less dynamic one – in much the same way that it is easier to call C from C++ than the other way round.

I do wonder about your first question – given the origins of Cocoa and Obj-C date back 15 years, I do wonder what a new clean API based around those 15 years of experience would look like.

Anyway, that’s getting away from the API debate!