Will Windows 7 drop backward compat?

The question is in the title

Is the intention to relegate it to a VM, or will it still be one of the primary 'features'?

Moving legacy products/features/APIs into an obviously separate VM worked for Apple with Classic (until they eventually dropped it, and nobody noticed) why would it not work for Microsoft with VPC? 

There might be some concern that lots of developers wouldn't have time, nor energy, nor appetite to re-write for a new system, but I would be interested in hearing the reasons why Microsoft shouldn't find an alternative route for backwards compatibility. Is it even possible to say, drop Win16 support or is it so tightly wound that it would be disastrous?


Edit: I am not talking about the Kernel, you can keep that

Rossj wrote:

The question is in the title

Is the intention to relegate it to a VM, or will it still be one of the primary 'features'?

Moving legacy products/features/APIs into an obviously separate VM worked for Apple with Classic (until they eventually dropped it, and nobody noticed) why would it not work for Microsoft with VPC? 

There might be some concern that lots of developers wouldn't have time, nor energy, nor appetite to re-write for a new system, but I would be interested in hearing the reasons why Microsoft shouldn't find an alternative route for backwards compatibility. Is it even possible to say, drop Win16 support or is it so tightly wound that it would be disastrous?


Edit: I am not talking about the Kernel, you can keep that

YearOfTheLinuxDesktop wrote:



wasn't win16 support dropped with 64bit XP/Vista?

Like 99.999% of people, I've never seen the Windows internals, so I have no idea how it's written, or what's possible and what's not.

However, as a general concept, I'd say... more modular is better... being able to enable/disable features and/or compatibility layers (such as 16-bit support) would be a nice option. i.e. if you don't use it, completely disable it and remove the code layer.

The Windows Server guys seem to have a good handle on this approach.

Is dropping it to a VM relegation? Virtualisation has coem on so much these last few years. By the time windows 7 comes out will the hardware be better enough that there will be no noticable degradation compared to what you got on your leagacy apps when they were new?

I think VMs have to be the way to go. They have the potential to set the OS free from the biggest constraint on innovation.

Yes, drop backwards compatibility completely and go with Virtualization.

It would be a bold move, but a sensible one.

The Windows kernel was designed to accomidate legacy OSes within subsystems. It's maintaining compatability with legacy subsystem components like WOW16 and NTVDM thats causing some of the issue I think, along with maintaining the old Win32 APIs and .NET ones.

It's what Apple has done twice now with OS X. First time the virtualized OS9 with classic and now they are virtualizing PPC code using Rosetta. Except for a few small hick-ups it has worked fantastically. Would not be a bad move from my experience if Microsoft did the same with Windows.

I'd love to see them do backwards compatibility through virtualization, allowing complete freedom for a redesign of the entire OS. Windows 7 was the one with the radical new UI, right?

I'd like to see this on a per-application basis. So basically, start an application that isn't recognized as a Windows 7 application, and Windows automatically and transparently runs it in a sandboxed environment that handles all interactions with the OS.

I'm wondering how much of a strain this is going to put on games and heavy multimedia apps, though.

I don't see it happening personally, a nice new fresh start with all the old hidden away in seamless (if not; a bit slower) virtualization. If it was such a big problem then I don't see why they haven't done it so far..

Theres other reasons for not changing the OS too much, standards and what people get used to (virtual standards?). I think once you decide on a big enough step that isn't too far away from what people are used to, then there isn't really all that much reason to 'new up' a new shiny OS with lots of clever virtualization.

Of course virtualization sounds like the coolest/best thing to do, I would love to see it, but I don't think Microsofts development of Windows is as simple as we see it..

Virtualisation is not a panacea, it can't fix all the problems and it most certainly creates some new ones into the process. Full blown virtualisation (like VPC) isn't very transparent in terms of how you access filesystems etc, so that's no good. A somewhat bodged solution, like Mac Classic, works a bit better but is fraught with problems of it's own (shared libraries etc). Windows would suffer more than Mac OS in this regard because so much of its strength come from COM and the ability for applications to interact.

What's more you have the very real problem of transitioning all the existing codebases over to this new OS. So unless your new APIs look a lot like Win32 (in which case what is the point) all the new applications are going to have to be rewritten anyway, at which point they've got a bigger incentive than ever to reconsider supporting your platform at all. Apple, who had a much smaller developer community to begin with, still had to put a lot of effort into transitioning apps to OS X via Carbon.

I sure as hell hope so.

As far as VMs go. I suppose dropping a Vista light version, or something, in built-in VirtualPC might be an option, as long as seamless window mode is offered, which is pretty much mandatory.

Going a step further, they could paravirtualize the living crap out of said Vista light using PV drivers where possible. If you want to push it, replacing core layers that redirect complete functionality. The memory manager, swap and file cache would be prime candidates, pushing the responsibility on the new host, alone for reducing the footprint of the VM to the bare minimum. No one would want VM idling away 512megs of your host, plus causing additional swap IO, since two swapfiles are running.

Alternatively, which requires a lot of work, moreso than the VM+Vista Light solution, would be writing a wrapper layer around potential new APIs. But seeing as far as the WINE project got in this regard, this would probably not work out.

I say why not do something like WINE... Only obviously MUCH better because they don't have to reverse engineer anything (we hope..). But yeah, just...reroute calls and whatnot. Obviously no matter what they do it's not going to be simple, but I agree something needs to happen.

You might want to check out WINE then. They have several professional developers, as well as an open source community working at it. Since years. And yet, common software that accessed a lot of different Windows APIs doesn't work. Case in point, important business software: Office 2007 is a no go, Office 2003 crashes left and right, Office XP works kind of.

A VM-like construct with a gutted Windows, as explained earlier, is probably the better short term solution. Most APIs in that sandbox would still be native.

Wine is an Win32 API implementation with homemade Win32 libs and a PE launcher. There is no emulation except for maybe the DX parts, which is really a dynamic translation to OpenGL functions.

So there really isn't anything different than whats in Windows now, except that it can be installed and removed at will.

Chinmay007 wrote:



In regards to the OP,

I don't think this a very good idea. One of the biggest strengths of Windows in my opinion is that it's quite backward compatible. Windows has a wide assortment of software. You really can't expect it to all be rewritten. If you destroy that you might as well not call it Windows anymore.

Chinmay007 wrote:

Yeah if I am not mistaken you can run Wine ontop of Windows, and I don't think it brings a POSIX layer with it. Wine seems to actually be a Windows implemention, i.e. they are trying to recreate Windows.

I wonder if you drop place Wine dlls in replacement of Windows system dlls.

There is also a project which takes Wine and and a custom Windows-like kernel to create an entire Windows-like operating system. By the looks of it (the difference between 0.3.2 and 0.3.3 is 800 new features and bug fixes) it's a very active project.

In a very practical sense, dropping backwards compatibility would ensure that you'd have a version of the Windows operating system that very few people would actually use.

Look at the screaming and hollering over Vista since it was released, with system builders recommending folks stay with Windows XP. Now, magnify that ten thousand fold; that's what's what you'd end up with.

While it has some appeal from a technological, purist perspective, it would make absolutely zero financial sense for Microsoft. There's no money to be made in breaking (or forcing virtualization) of 95% of the applications running on desktop systems. And if it doesn't increase their market share and improve their bottom line, why should they do it?

Never forget, the bleeding edge of technology is where few businesses want to be. After all, it's rarely a bad strategy to let someone else take the arrows in the back.