So...
Will "Windows 7 Mode" contain "Windows XP Mode"?
Microsoft has said that recent comments from Intel software chief Renée James on the next version of Windows were "factually inaccurate and unfortunately misleading." At Intel's Investor Meeting 2011 at the company's Santa Clara, California, headquarters on Tuesday, James told her keynote audience that the upcoming versions of …
...MS has been pretty good at maintaining backwards compatibility. Have you seen the video going from Windows 1 to Windows 7? I thought it was pretty amazing to be honest.
I'm pretty sure that one could not do that with OS X and as for any given Linux distro I don't think it would work either (downloading source and re-compiling is cheating. :-P)
I completely agree; binary compatibility for the Mac goes back a decade at the most and requires the installation of optional components to do so. Obviously you can argue some virtue in that from the perspective of bloat and support, but the benefits of full backward compatibility are so obvious as not to need arguing. Microsoft aren't always 100% on the nail, but it says a lot that I can remember the only two times I've had problems, and the first of those was running a Windows 2 version of PageMaker on 3.1...
Apple does shut down parties with prejudice. One major change over the past ten years is PowerPC to Intel.
Thing is, if you asked Microsoft, they would express their envy that Apple can do this.
But, Microsoft is in a different business and moving the herd off of the obsolete is a problem. It means the efforts they make in improving user experience and apis are ignored by developers who have customers running the os from 2001. Plus, modern browsers are widely available and there has been a lot of work put towards improving the speed and power of web apps.
So, Apple has to do with this report, how?
If Microsoft is not looking at the ARM opportunity as a moment to somewhat break with the burdens of backwards compatibility, then that's it, the moment of negative mojo.
My guess, when Windows 8 on ARM rolls around, we'll find that Intel was more correct than incorrect, but it won't be a problem to adapt old applications to the new processor, beyond the work to address different underlying assumptions about speed, RAM, and responsiveness.
Not quite true; if I recall correctly then a PowerPC version of Windows NT 4 shipped for the PReP platform in a few extremely obscure ThinkPads that could run Intel binaries through emulation. Or my memory might be fooling me, and the emulator may have been an add-on, though I'm pretty sure it worked at the system level, to emulate the binaries but forward the relevant system calls directly to the native NT implementations. Or I'm just very confused indeed.
"If they are going to have backwards compatibility on an ARM chip then the ARM chip will have to emulate an x86 chip to run it."
Really? I'm no Comp.Sci. grad, but surely it would be up to the kernel to translate whatever calls were coming through into what the CPU can deal with and back again? Or if not the kernel, then the virtual machine that is translating the byte-code.
And if something like that is not going on - how the heck does Linux manage to support AMD and Intel at the exact same time?
Even then, emulation/virtualisation would allow you to isolate the executing code from the underlying hardware.
> but surely it would be up to the kernel to translate whatever calls were coming through into what the CPU can deal with.
The compiled binaries will be for an x86 chip. This means they will not run on an ARM chip. An emulator will have to translate the x86 instructions in the old binary into the equivalent instructions for an ARM chip. How the kernel handles translating system calls is irrelevant (and trivial).
> how the hack does Linux manage to support AMD and Intel at the exact same time.
Because AMD and Intel are compatible on the instruction set they use. This means that, for example, the effect and the hex code for the POPA instruction will be exactly the same on both processors.
But virtualisation on the slower ARM chips will be dire, so I hope they don't try to include it in the OS.
I envisage an "app store" where low cost ARM W8 apps can be purchased (or repurchased) much like Apple's model. Those real old legacy apps will just have to stay were they are or die. As another poster points out, much of MS' pickle has been due to trying to be all things to all men - I mean apps..
I give up. I was looking forward to ARM windows not having all the ancient baggage. Now MS snaps back at Intel by saying not only will Win-ARM not run legacy apps, but Win-ARM isn't really Win-ARM. It will be multiple incompatible versions of Win-OMAP, Win-Snapdragon, Win-Tegra, Win-why-should-I-care-now...
It is the joy of allowing vendors to tinker with the system
On PC, the tinkering ended within 1-2 years from the start. From there it was all standard and all an IBM clone. That has allowed a single system to exist.
Arm, MIPS, PPC, etc are not there yet or have been artificially prevented from getting there. So it is natural to have a Win-why-should-I-care-now...
Based on Microsoft's denial and the port to ARM, I'm optimistic that they're deprecating some legacy stuff by relegating it to a Windows 7 compatibility mode. So they wouldn't be re-jigging the underlying architecture, just trying to push everyone more forcibly towards the re-jigged stuff.
Would an all .NET Windows with all or most of Win16/32/64 in a sandboxed, legacy support environment really be a bad thing?
"Would an all .NET Windows with all or most of Win16/32/64 in a sandboxed, legacy support environment really be a bad thing?"
Given that .NET runs on top of Win32 (or Win64, as appropriate), which in turn has to run on *some* kernel that can load third-party drivers which are currently all native mode code, your suggestion is about as realistic as running a Linux kernel on Javascript.
But anyway, would that be .NET 1.x, .NET 2/3 or .NET 4? They are all sufficiently different that you can't run programs targetting one on top of either of the other two, and you can uninstall any of the three without affecting the other two. In fact, it's a bit like Win16/32/64.
they don't know. Which is actually fair enough - they're still developing it. Makes Intel look all the stupider (and the more desperate) that they knee-jerked all that crap the other day.
Still MS now have a heads-up - think of all the Visual Studio licenses they can sell if they build in "transition" tools. Also, they'll be coding up an x86 emulator as we speak.
So MS says that Intel mislead us, but won't "lead" us right, so we are all still mislead...
Great, that was really helpful MS, thanks! (Should we have expected more helpfulness?)
"You all think the wrong thing, and you are wrong and we know but won't say. Ner ner ner ner..."
"Oh I'm a PC by the way..."
On of the problems inherent with Windows is precisely because it's forced to run legacy applications. That translates to having to leave a lot of items in, just in case someone wants to run some twelve year old piece of software. Leave that to the virtual machines please, it's time they cut loose.
Do you count malware as being legacy? I would do so in my book.
"Virtualization will allow legacy apps to run. If Microsoft doesn't provide it, a third party will."
Definately not.
The word you are looking for is emulation, not virtualization.
Virtualization runs most code native, intercepting only relevant system/hardware calls.
Emulation requires translation of every assembly instruction.
The difference?
Usually 10-20% percent performance penalty as compared to a factor 3-5.
The vast majority of Win32 user mode applications can be translated at install time or load time, like .NET apps are. Anything without self-modifying code is trivial, and self-modifying code is both easy to spot (on a system that forbids data execution) and largely restricted to a handful of well-known libraries.
It's been done before, on Windows, translating from x86 to RISC. Microsoft almost certainly still have the code somewhere.
come on, the longer they allow backwards compatibility the longer you can use your old printers, scanners, games, software, etc. It makes "sense" to make everything require new hardware with the new software that way everyone makes more money off your "top of the line" setup that's 2 months old.
lol gotta love M$ always living up to their name.
Looking at 2 of my systems:
2ghz cpu, 2gb ram, Windows XP Pro: Handles 1 user freezes regularly
3ghz cpu, 1gb ram, Ubuntu 10: i've had a total of roughly 5 shell users, 100 remote users, 1 local user. never lagged. local user was using it as a desktop for proper tests (streaming video etc)
"2ghz cpu, 2gb ram, Windows XP Pro: Handles 1 user freezes regularly"
You might want to look at that then as that is NOT right. I have a few customers running perfectly behaved 1Gb Atom N270 machines they were given as thin clients as full XP systems now and they are beautifully quick and bomb proof. 1.8Ghz P4 with 1Gb ram should be perfectly useable.
Theres a difference between Shell users and RDP users, oh lets see, a slight lack of GDI overhead for one. I've seen 386 machines handle huge numbers of shell users.
Could it be you are just trolling?
We're all assuming they are referring to the backwards compatibility and / or inter-compatibility between the ARM versions.
What if M$ actually has a gripe with the statement that there will be a "working" ARM for each single ARM version ... AS WELL as a "TRADITIONAL" Win8 for x86's.
Or even worse, perhaps even the "traditional" won't be backwards compatible.
Or what else? Giving such an "open" denial could mean anything really!
...
So, M$'s response is actually: "Intel said some things which aren't correct. We WONT tell you what they are!" ... To be read in between the lines: "The things which are incorrect in Intel's statement is actually going to show up even worse problems!"
PC tinkering ended within 1-2 years. What?!?
8086, segmented 286, expanded memory, extended memory, 386 protected mode, virtual 8086, SMI, PAE, AMD64;
x86, Weitek, 8087, MMX, 3DNow!, SSE, SSE2, SSEinfinity, AVX, FireStream, CUDA, OpenCL;
ISA, EISA, VLB, PCI, PCI-X, InfiniBand, PCIe;
ST506, ESDI, SCSI, ATA, SATA, SAS;
RS232, IRDA, USB, FireWire, BlueTooth, Thunderbolt;
UHCI, OHCI, EHCI, XHCI;
CGA, EGA, Hercules, VGA, 8514, XGA, ... ... ... nVidia vs. AMD;
Shall I continue?
Yeah, but the longer they keep saying it, the less likely it is to ever become true.
I can remember when Silverlight was the future of the web. If I try really hard and squint, I can remember when IA-64 was the future of PCs. I can no longer remember when Windows on multiple RISC platforms was the future. It was too long ago.
There's a lot of C# development going on out there, and has been at least since .NET 2.1
Just for fun, go to any large IT job site and compare the number of listings you get for C# and C++. Even discounting ASP.NET work done in C#, there's a lot of deman for .NET developers, which is an indication of how many (in-house, if nothing else) applications are developed in C#
(Personally, I prefer C++ out of habit, but C# and .NET can be quite nifty in many cases)
I remember doing a fun experiment with installing Windows 7 preview to G5 Power mac of mine (fastest one). It actually worked except choking because of completely cosmetic 512MB RAM limit which I always compared to 640K story.
It is MS Virtual PC, MS has capability to software emulate x86. If they license or make it easy for OEM to license the technology from the company who makes Rosetta for Apple, things may even get more interesting.
Remember legacy apps doesn't need too much memory too since developers of these didn't have face to "buy more ram instead of me fixing memory leak" type thing.
What are the reasons for not being able to take an x86 binary and convert it to an arm binary? Yes the layout of the files will be different, but surely you can rearrange what you need to, replace instructions with their equivalent arm instructions and add additional commands where needed? So long as the same external function references exist why would there be a problem?
Paris, coz I'm having a blond moment.
No blondes here, I'm afraid. In the absence of self-modifying code, the translation you propose is trivial, it can be done once and thereafter the code behaves just like a normal ARM executable. You'd probably lose a few percent in performance on low-end chips, but on higher end CPUs the out-of-order execution would mean that you were actually bottlenecked on memory references rather than instruction execution and so performance would be indistinguishable from a native build.
In the presence of self-modifying code, you need to re-translate the modified code on the fly. In practice, such modifications are rare and confined to very short stretches of code, mostly generated by well-known libraries. It wouldn't be hard to handle them and you wouldn't notice the performance hit.
To elaborate on something I said in an earlier reply to someone else, when Microsoft were pitching Windows NT on all sorts of RISC platforms, they had a sub-system called FX!32 which let you run 32-bit x86 applications on the RISC-y Windows. In the case of the Alpha, FX!32 was so good that x86 apps ran faster on the Alpha than on the best Pentium chips of the time. (The Pentium Pro put paid to all that, and indeed to the entire RISC revolution, but that's another story.)
If Microsoft want Windows-on-ARM to be able to run x86 applications at full speed, they already have the code to do it. Intel know this. It is a credible threat to their business.
In the 80s and early 90s, RISC-based systems chewed up the mainframe business from below. In the 90s and early 00s, x86-based systems chewed up the UNIX workstation vendors from below. Only a fool would now ignore the *possibility* that hand-held devices and low-power laptops will now chew up the desktop PC market from below. Intel didn't get where they are today by being fools.
Nice writeup Ken, just want to point out that FX!32 didn't come from Microsoft (how could you think anything clever could come from MS).
As you (nearly) say, FX!32 automagically translated NT/x86 Win32 executables to NT/Alpha Win32 executables. It actually came from DEC's Alpha people. The impact of this is that MS afaik don't actually have rights to that code (correction welcome), but in the years since then, emulation technology in general has moved on and there are probably equivalent tools, maybe even better tools, which are now available to MS.
When Microsoft hast to develop and support 5 totally different versions of Windows 8 it will have even more problems than Vista had.
Same IE on 5 Versions of Windows? Or do they do it like today. One for CE, one for WinPhone7 and two to three for Windows on Intel?
Even the track record for keeping .net in sync over different platforms isn't that promising.
Since my customers just started moving from XP to Win7, I'm not panicking, but I expect to run a lot of virtual desktops not too far in the future.