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)