Slashdot Mirror
Windows Already Up and Running On ARM Architecture
syngularyx writes "Over at Microsoft's MIX Developer Conference in sunny Las Vegas, Microsoft has demoed a new preview build of Internet Explorer 10 (which you too can take for a spin, if you feel so inclined), and also dropped a little premature Easter egg – the build of IE10, and the underlying Windows OS, were both running on a 1GHz ARM chip. Sneaky."
can you hack the iphone / ipad to run windows 8?
It's about frickin' time! As usual MS take the longest to get on the trend train.
They demoed this at CES months ago... http://www.zdnet.com/blog/microsoft/ces-microsoft-shows-off-windows-8-on-arm/8339
But... But... But...
/rimshot...
How are they going to make it compatible with all those viruses and trojans out there?
It seems that everyone is going to go for the accelerated releases now.
10 is much bigger than 5 (firefox), so I think IE is going to win.
You probably can, as I think Windows 8 is designed to run on tablets as well as PCs, having totally different shells running for each type.
I thought one of the biggest Windows / SQL Server computers in the world was the Nasdaq Tandem (now HP) MIPS computer.
http://news.cnet.com/Nasdaq-upgrades-HP-based-trading-system/2110-1010_3-5628950.html
though it seems Microsoft phased it out for other customers:
http://www.microsoft.com/presspass/press/1996/oct96/mipspr.mspx
At least based on my MS friend's claims... they probably have many such projects (say, like, a fully functional web-based MS office)
In fact I'd say this is one of those companies where such innovative ideas usually go to die, as they often "might windows or office cashflows".
Now that windows is threatened, then the skunkworks projects get revealed. The battle for ARM dominance is joined and now there are many contenders (WebOS, iOS, ChromeOS, etc).
Make sure everyone's vote counts: Verified Voting
It's about frickin' time! As usual MS take the longest to get on the trend train.
Windows CE has been running on ARM for about eight (?) years.
If Android has not been made to run on Apple iOS hardware, then it's very, very doubtful that Windows can be made to do so, as the source code isn't even available.
Better known as 318230.
I think you mean bloating of the OS, not CPU. And a firewall hardly adds bloat, it's in the kernel (although I must admit I'm not sure if that's where it is in Windows... I sure hope so).
As far as antivirus goes, Microsoft Security Essentials is actually very good, and extremely lean. There's not much reason to use any of the commercial antivirus bloatware anymore.
Except that is Android does run on iOS hardware, good point.
http://www.idroidproject.org/
Gone!
Wow, no more posting when I'm half asleep! :/
Gone!
ARM isn't standardized like x86 is, so probably not... at least not easily. IBM PC clones use a fairly standard set of firmware and peripherals, whereas ARM-based machines tend to be largely custom, just with a degree of binary compatibility between them. Getting Windows running on an iDevice would take serious work.
What amazes me is how many of the young 'uns here are surprised, whereas we old guys remember when MSFT brought over Dave Cutler his big thing was portability and he had WinNT running on just about every chip out there.
So I wouldn't doubt they've kept a division of MSR going with an up to date portable version of the NT code base. what I don't see how they can keep from getting bit in the ass on is if they name it Windows people are gonna expect Windows apps to work which of course they most assuredly WON'T, not without a recompile that most companies simply won't do.
that is one I will hand to the F/OSS guys, if they want to run F/OSS OSes on the old Motorola 68k or any other chip they can do so if they spend the time recompiling it for the arch. Too much of Windows value is tied up in third party code that will simply not get off x86 anytime soon, and without it windows is pretty much worthless. After all people aren't gonna buy Windows licenses just to play Solitaire.
ACs don't waste your time replying, your posts are never seen by me.
PHP has encountered an Access Violation at 7C82A01A
You are being MICROattacked, from various angles, in a SOFT manner.
Assuming that Microsoft doesnt jump the shark and do something totally unlike their past releases, like overtly junking all back-compatibility with x86 legacy applications (I see this windows offering being adapted for use on the emerging tablet market, where existing legacy application support, even if crippled, would be a big selling point), this offering will be technologically inferior to the existing (and based on more portable technologies) offerings like iOS and Android.
The reason is because this new windows flavor will have to JIT emulate the x86 instruction set for those legacy apps, and do all kinds of calisthenics to make shit happen between native binaries and emulated binaries. The ARM cpu uses less power, but is also somewhat more gutless compared to desktop x86 chips. It will suck hard trying to emulate that bloated dinosaur of an instruction set.
If microsoft finally sacrifices the holy vestal virgin of legacy compatibility (Its major strongpoint in corporate environments by a long shot-- Look at the immense power of zombie IE6) for its ARM port, it will suffer the same fate as all the previous alternative architecture builds (PPC, SPARC, Itanium, et al.)-- That is to say, it will die on the vine because users will hate it with purple pasion.
I am curious to see how microsoft pulls this off. If they were smart, they would do something similar to what Apple did when they switched from PPC to x86 commodity chips, and incorporate a special abstraction layer like Roseta. (Note, I am NOT an apple fanboi-- If you call me one, you are an idiot. Just pointing out something I thought apple did that was interesting.)
Sadly, like so many things microsoft does these days, it will probably be filled with so much useless bloat and duct-tape code that it will run like congealed dogpoo even on high end ARM hardware when trying to do such legacy support-- (again, if they even do it at all.)
I will reserve further judgement until I see it in the wild. It might be great-- but I wont get my hopes up.
Yes Microsoft is going to chase the trend and make something for ARM, otherwise they cede the mobile space to Apple and Google. However, while they will call it Windows 8 it won't bear much relationship to the x86 edition we all know and either loath or love.
1. Anyone think Microsoft (or any of their hardware OEM partners) are remotely interested in releasing what we think of as an Operating System on a new mobile platform? Not when they can lock it down hard and rake in the same 30% Apple gets from their app store. Do not think it an accident Microsoft also leaked screenshots of thier app store this week.
2. No, it won't run any existing Windows apps. ARM is puny, x86 is strong. x86 can emulate ARM (see iOS and Android dev environments) but there is no way ARM is going to emulate x86 apps at a usable speed. Assuming of course I'm totally full of crap on point one and unsigned apps were somehow permitted in the first place. Exception possible for .NET projects with no native code, but again see point one.
3. Even if you could, smartphones and tablets are a different environment so an existing Windows app would be lame.
4. Microsoft has ported Windows in the past. They even got some of their own apps running. I'm told Alpha even had most of Office running native vs via FX!86 before the end. But 3rd party buy in wasn't there and they suffered something similar to the fate of Linux. No 3rd party apps means no large deployements which means no interest by developers to port the 3rd party apps. If Microsoft can make cross porting totally painless this time they might have better luck, but again see point one and three. Just having an ARM binary of Photoshop crap out of Visual Studio along with the x86_32 and x86_64 copies won't result in a product Adobe would be willing to sell to tablet customers. Also have to wonder if they will like giving Microsoft 30%. Yes the normal retail path eats more but BestBuy isn't out to kill them.
So if Windows on ARM gains little from the existing catalog of "Windows" applications, will almost certainly require more robust hardware (battery life is issue one) to run it vs Ubuntu or Android and might even piss off customers who won't realize that Windows != Windows will it get traction?
Democrat delenda est
Running the OS on an ARM chip isn't even half the battle. What about the apps? Has Microsoft created a "fat binary" format, the way Apple did for its migration from PowerPC to Intel? Are the development tools ready? Are all the Windows application developers lined up to recompile and migrate? How much of that stuff is still tangled up in assembler, anyway?
Microsoft's advantage has always been the breadth of its ecosystem. Now that's Microsoft's disadvantage. There's not much point to owning a power-miserly ARM-based Windows machine if the apps you've come to depend on aren't available. You might as well swallow the medicine and migrate to a more secure, stable OS with a future.
Pure .NET apps should work though, which will assist Microsoft in eliminating non-managed languages.
No way I'd run it without antivirus.
boycott slashdot February 10th - 17th check out: altSlashdot.org
is finally ARMed...
For some reason I think the better word is "Desperate" Like they notice their customers (well they assume they are customers) jumping on a new ship...
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
Alpha and several other non-x86 platforms?
I seem to recall this was back when Windows NT Workstation was aspiring to supplant Unices on a variety of Unix vendor hardware in the early '90s.
STOP . AMERICA . NOW
Eliminate but not quite. The future of Windows is one where only authorized driver developers, Adobe, and game companies are allowed to run native code.
Fortunately Windows will probably be all but dead by then (except for in the business world).
The real value of Windows is in the massive installed base of applications that it has. I wonder how many vendors of important Windows applications will release an ARM build. I do hope that it will be as simple (for the most part) as recompiling the same source in an ARM-based build environment, but even so I wonder how many developers would do it. Good luck getting all those legacy VB6 apps running on ARM Windows though, or any other app for which the source is gone. Without the application ecosystem one might as well be using some other platform.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
When has anyone ever wanted Windows on anything but x86? Anyone else remember NT on MIPS, DEC Alpha, HPPA, etc?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
They're something like a decade late to the ARM party. "Already" is hardly the right work for it.
Freedom is the freedom to say that 2 + 2 = 4
Was that a joke?
Darwin, which is the actual OS underlying OS X is also the actual OS underlying iOS, which runs on iPhones and iPads. It's also open source.
CLR/.Net stuff should run fine I imagine. Also, I remember Alpha had FX32! which would run x86 code at decent speeds using static recompilation and that was many years ago now.
Holy cow, Batman! How much more backward can you understand the problem?
The reason x86 can emulate ARM is because ARM is *simple by design*. ARM cannot emulate x86 at decent speeds because x86 is a *pile of crap* from 30 years ago with legacy bullshit bolted on top of each new generation.
Strip away 20 Years of hardware boat, but then add the most bloated OS on it.
It doesn't make sense.
https://www.youtube.com/c/BrendaEM
OS is short for operating system. Flash has nothing to do with the operating system.
I know Slashdot has gone downhill in the last ten years, but are you sure you're on the right site?
There does not (yet, I suppose, but it's hard to see this changing) seem to be much interest in ARM for "non-appliances". People don't expect their OS X apps to run on their iPad, likewise they won't expect some random Windows application to run on whatever tablets/phones/appliances end up running "ARMWin", or whatever it gets called.
MSFT, the only ones without WebGL...
Firefox4 has it
Chrome has it
Opera beta has it
Safari beta has it
music - http://www.subatomicglue.com
Does anyone write "Pure .Net apps" though? A serious question, as I can't think of an app that I've written that is pure .Net. I always need to include some pInvoke (Platform Invoke or Windows API calls), which can make code less than portable (depending on memory packing / variable alignment, pointer size, etc.). However, since I write code to help maintain our Windows images and also as utilities for users (not as large applications), perhaps my perception is a bit skewed.
Windows of various incarnations and IE has run on many platforms.
Now, show me the latest version of Microsoft Office running on ARM with file compatibility with the x86 version. Then I'll be impressed.
Shouldn't they finally fix the x86 versions first (?)
Adobe? Why Adobe? Don't they introduce more exploits to a Windows machine than even Microsoft? I know I've read articles in the recent past that say more exploits are using Adobe products as the vector than all other vectors combined. And, you're going to give Adobe some kind of a free pass on the new architecture? Wow - you should be a politician. You certainly have the smarts for it!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Can't or doesn't?
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Has Microsoft created a "fat binary" format
No, but Microsoft does have .NET, and it might even have a compatibility layer to run CE apps.
Windows can't open OOXML documents. Office can. That's a whole 'nother kettle of fish, they had big problems getting Office for Mac from PowerPC to x86, and reportedly the Office for Windows codebase is even older and more convoluted. It'll be hard if not impossible to port to ARM.
The big problem, Windows will be at a big big disadvantage, and in fact I don't thik it'll be competitive:
1) It's bloated and poor-performing when compared to most Linux distros, or MacOS for that matter. ARM systems tend to me "small" (low processor speed, low RAM, etc.)
2) Applications. This is really Windows main (IMHO sole) strength, on ARM it is gone! You use Ubuntu, and you have a full set of NATIVE applications on ARM just as on x86*. You use Windows, you'll either have almost no applications (if it doesn't emulate x86), or you'll have all these apps that run at a fraction of native speed. Microsoft *had* NT running on HP PA-RISC, Dec Alpha, PowerPC, and perhaps one or two other platforms. The absolute lack of apps did the in (Alpha used an x86 emulator however.) There was Windows for Itanium, again no apps (it was really stripped, though, couldn't even print.)
---------------------
*Side note, i almost got into collecting some "exotic" computers, but after we installed Linux onto several, they were so indstinguishable from the regular PC experience I figured it wasn't worth it even if I could get them at a good price. I put Linux onto a DEC Alpha about 5 years ago, it was so similar to an x86 desktop that I would not have been able to tell it was an Alpha without looking at the case (which was a PC-like Case but said "Alpha" on it.) As a prank, my workmates switched my x86 Ubuntu desktop out for a PowerMac with Ubuntu, moved it into the same case, and got USB->PS2 adapters so my model M keyboard and all was plugged in, and put my home directory etc. back onto that. Seriously, I didn't notice it was a Mac until I rebooted and heard the Mac startup sound. We installed some distro on a PA-RISC, again it was indistinguishable from a x86 desktop. With a ARM based system you will not be disappointed with an ARM distro.
They could test it in the N900, everyone does that. Extra points if they manage to run it in maemo. Also they will show how tied are with Nokia that way.
Windows NT was originally positioned as a portable, platform-neutral system and Microsoft made a big deal of it not being just limited to Intel architecture but also running on ACE platforms (remember ACE?), MIPS, Digital Alpha, and at least one other whose name escapes me. IBM PowerPC maybe?
Microsoft seduced and abandoned companies that committed to Windows on non-Intel platforms, with the abandonment beginning almost as soon as the seduction was complete. My employer made a significant commitment to Windows-on-DEC-Alpha--at that time, their specific application benchmarked over twice as fast on Alpha as on Intel. It was NT 3.51, IIRC, and Microsoft moved up to Windows 4.0 on Intel and kept dragging feet and making excuses on Alpha, finally acknowledging that it was not going to be supported. At that point, the Alpha systems bought by my employer's customers were barely a year old, and those customers were not happy with us for selling them such rapidly orphaned products.
What matters is not whether Windows can run on ARM, but whether Microsoft actually has any serious or durable commitment to supporting it on that platform.
"How to Do Nothing," kids activities, back in print!
Windows firewall programs aren't really firewalls, for the most part. They're more like ACLs for API calls involving sockets.
That's why when you run a Windows "firewall" program you don't generally see things like IP addresses, masks, protocols, port numbers, and state information. If you do, it's buried in the menus someplace, not the core function of the program, and likely added as a limited afterthought. They're definitely not a great example of bloat but they are certainly more resource-intensive than something like iptables and the relevant *nix kernel support.
The few times I have used a Windows sytem in the last several years, it was most disappointing. Where you could just write a few rules to cover your needs, now you have to go through a tedious list of programs and incrementally enable each one that may want to use a particular protocol after, of course, having some system tray pop-up distract you from whatever you were trying to get done. Depending on the "firewall", you may have to do it again when you upgrade/update the program since the executable has changed.
Really the only justification for this is the terrible host security of so many Windows systems, which leads to the hope that a strange executable the user has never seen before that wants to use the network might get noticed. It's one of the least efficient ways to operate a firewall. The need to enforce permissions that apply to system calls (of any kind, whether they are related to sockets, disks, etc) should be a core OS function that requires no third-party utilities. The need to regulate network traffic is a different problem that would properly have a different solution.
Honestly it's a fucking inelegant mess but it avoids the BIG SCARY OH NOES!! of requiring users who want to adjust a firewall to know a few things about how networks and firewalls work (sort of like the way we expect people who want to tinker with an engine to have skill as a mechanic and no one calls that unreasonable) or, failing that, to hire/consult someone who does. Like most of the culture surrounding Windows really. For those people who like it this way, use what you like and I say more power to you. To me, it's downright suffocating. I'd much, MUCH rather spend a few minutes reading up on networking, learn it one time, and do it the simple/elegant way from them on, rather than continuously do everything the hard way solely to avoid a little reading.
This set of priorities, more than anything else, is the difference between Windows "computing as a product" and many other systems. You can spend a great deal of time looking at differences in design and technologies without having a satisfying understanding of why things work out the way they do.
As far as antivirus goes, it's a terrible substitute for a good security system that doesn't treat the user like an illiterate idiot. I'm wondering how much worse the malware problem has to get before more people are willing to admit that antivirus is at best a band-aid and does not address the problem of security. Usually things have to become some big-ass crisis before people are willing to say "you know, the way we've been doing things doesn't work, maybe it's time to try another approach." Until then, those who said all along that something is not sustainable, is moving in the wrong direction, and lacks long-term viability are ignored and marginalized. Too often, that's the way it works.
It is a miracle that curiosity survives formal education. - Einstein
Windows NT had the same problem with PPC. It wouldn't actually run on a PPC Mac even though it was the most common machine out there.
IE running on Windows is about as exciting as grass growing in dirt - it works, but it is not exactly novel. As you said, Windows NT was designed on architecture independence. In fact, Windows itself is even endian independent, but it still reads and writes files in the native endian-ness (or so I remember from Alpha-NT). With ARM endian-ness is not a problem because ARM is bi-endian, so they can just use little-endian and be happy. If IE only uses the Windows API and the Windows API only uses a kernel built for the hardware, it should compile and run without any changes (because the Windows API is essentially a hardware abstraction layer with the kernel being hardware dependent).
Generally with this sort of design, the API itself is architecture independent (in this case, C++) code and hardware dependent pieces such as graphics, I/O, and devices are part of the kernel. Apple has pretty much the same thing in architecture independent Objective-C code on top of a hacked Mach microkernel (aka monolithic kernel based on mach) which they used to transition from PowerPC to Intel.
Comment removed based on user account deletion
Adobe? Why Adobe? Don't they introduce more exploits to a Windows machine than even Microsoft?
AC probably only mentioned Adobe because of the prevalence of Flash... the end users certainly don't care that all the code Adobe writes is full of holes. If they did, they wouldn't keep using it. Obviously the risk is worth the reward of getting to watch youtube videos and play flash games...
Your memory is suspect... NT 4.0 had Alpha support at launch. It was even in Windows 2000 RCs, and only dropped come release time, though I do recall Compaq selling Alpha servers with 2000 despite that.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
The more that Microsoft tries to squeeze the square Windows peg into the round hole of current and future computing needs, the more ugly splinters that will be flying and injuring the innocent bystanders. Microsoft needs to wake up and smell the non-Windows world. Until it does, it will never be able to compete. What else is there to say?
Uh, that's exactly what Microsoft is doing now with Windows Phone 7. Adobe is going to get unhindered native access for Flash. Performance trumps security, apparently.
Microsoft never cares about security while it puts compatibility at risk. Which is why Microsoft still bundles a ring 0 driver made by Macrovision, previously susceptible to escalation attacks, in all copies of Windows 7.
Windows had been ported to the DEC Alpha, and was going to be running on mainframes, MIPS, and SPARC soon after.
How is this any different?
Yawn.
Maybe they can get it running on X86, instead of being the poster child for the three finger salute.
that hardware already has 1GB of memory and all we see is it's running a browser and not much else. This reminds be of a few days after they showed off what would be Windows NT v3.1 and mentioned the hardware it would require. They quickly mocked up a Windows 3.x with a new UI and started calling it Chicago, the next great Microsoft desktop operating system and stopped calling NT that.
Windows on ARM is going to suck or it won't be anything like the Windows you know( ie it will have to be _vastly_ cut down ). And you know it's going to need antivirus software so start betting on 4+ cores and a couple of gigs of RAM as a minimum configuration. I wonder how small they can make those cooling fans?
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Big deal Atom is just x86 plenty of other OSs run on the architecture other Linux's, BSDs, Solaris, etc...
Intel has just launched Oak Trail, which is the name for the combination of Atom Z600 and SM35 PCH. In particular, the SM35 PCH provides compatibility with the main IBM PC compatible x86 platform with all the legacy, so it can run any standard x86 OS, but it is still low-power ("Put together, Oak Trail's Atom Z620 processor and SM35 Express hub have a thermal envelope of just 3.75W."):
http://techreport.com/discussions.x/20753
If it looks the same and is called the same, people are going to expect it to behave the same. But I suspect this will be handled like the Apple transition from POWER to Intel chips - fat binaries for new apps, the Common Language Runtime and other runtimes ported to ARM, and an emulation layer (probably based on VirtualPC) to handle stuff that really can't be easily handled any other way such as legacy apps.
Flash is cash. Seriously, if Microsoft wants to beat Android and iOS this is the one place they have a content advantage. They can both capitalize on the existing websites that use Flash and slow the transition to alternatives. If Windows makes applications run in a proper sandbox, exploits should not be a huge problem.
The US government have made it clear that we have no inalienable rights; any we do not defend vigorously will be taken.
Let's say MS somehow manages to come out with a tablet version of Windows that CAN be installed and run on an iPad. In fact, let's say they design it specifically to do so. What's the legal consequence of this? Can Apple actually declare it's illegal to install a different OS on their hardware? And if so, would they actually do so? Perhaps this is part of MS's strategy. If they can't supplant iOS on the iPad, they make Apple look oppressive (see Sony vs Geohot). Win-win for Microsoft.
"The only normal people are the ones you don't know very well."
There are a whole lot of comments here about running Windows on phones and tablets built around the ARM architecture. However, that may not be the only reason Microsoft is porting Windows to ARM.
nVidia has announced they are developing a high performance 64-bit processor based on the ARM architecture. They claim is will be used for personal computers and servers, and scale up to supercomputers. They also claim there will be versions with integrated nVidia graphics also.
Now, announcing a product that revolutionary and actually delivering it are very different beasts. If nVidia actually manage to pull it off, I don't think that Microsoft would be happy if the new processors could only run Linux.
Windows can't open OOXML documents. Office can. That's a whole 'nother kettle of fish, they had big problems getting Office for Mac from PowerPC to x86, and reportedly the Office for Windows codebase is even older and more convoluted. It'll be hard if not impossible to port to ARM.
They already have office mobile running on ARM that can open ooxml documents.
So... I will surprise everybody.
WIN8 running very very well already on ARM processors.
They rebooted WIN8 to the originally planned WIN7 micro kernel.
Win8 is a one microkernel with multiple interfaces to be booted up within 3sec.
1. It can be traditional PC
2. CAN be Tablet
3. Can be WInphone (Bye bye WInphone 7... if you didn’t realize it was/is just a research and UI project)
4. It runs inside TVs (Hello Samsung!)
5. Runs in the cloud.
6. It is the embedded.
The same Win8.
The Winphone 7 software delivery packaging implemented and further enhanced for consistent solution delivery.
One development toolkit to develop solution across all platforms.
You think it is not true. You don't believe that MS can pull this off. They already did it!!! Just they have learnt from Apple. SILENCE! You will be shocked.
People talking about the backward comp ability as an issue. This is NOT a problem anymore because of what MS done in the virtualization.
The virtualization is part of the kernel and can natively virtualize anything to achieve backward compability.
Have you ever thought what this Really really means? You should have goose bumps...
I'm not sure "seduced and abandoned" really captures the flavour of those heady days. From what I can recall, most of the companies involved were fighting fires on three fronts: their old-line proprietary businesses were getting chopped to bits by PC's and the war of attrition that was Unix at the time - the company I worked for had internal in-fighting as the unix and PC business started to threaten the old mid-range server business and competition BETWEEN companies was even more cut-throat. Sun was playing everyone for suckers as the Unix wars played out. Microsoft offered a plausible, one size fits all solution that looked like a complete end-run around Sun. Digital, in particular, the company with most to lose (vax, ultrix, a dead line of PCs that started with the wacky rainbow and ended up with them buying white boxes or 3rd party contracting out that part of big govt contracts) signed up big time. In fact the relief was palpable in their office nearby when the sales guys suddenly had a story to tell other than obvious loser products like OSF.
That NT never took off on anything other than Intel wasn't really Microsofts fault - in fact to think they orchestrated some Machiavellian plot to sucker a bunch of lucrative partners into mercy killing their businesses doesn't match what happened. What happened is that the customers woke up to proprietary hardware.
In a lot of ways, Sun looked like "the good guy" for 15 years but they really were kind of evil by currying discontent amongst the other Unix vendors (and even their own partners like Novell). Microsoft were the main beneficiary of Sun deciding to try to monopolise the Unix market which inadvertently made Windows a player beyond the desktop.
and just maybe that was their plan all along since it helped eliminate yet another competitor to the WinTel duopoly and solidified both in the industry for far too long. Remember, they planned a nice game with getting apps ported from UNIX to Win32 and played the bait/switch on them too. Gave out lots of licenses for Win32U, got lots of UNIX software vendors to port claiming they would have one code base and be able to support both platforms. But once they got a significant number of core UNIX apps ported to Win32, they yanked the rug out from under the Win32U companies by massively increasing the licensing costs so that none of them, but one, could stay in business. The one(MainSoft?) could because Microsoft also was paying them for 'porting Internet Explorer to Solaris and HPUX'. Nicely hedging their bet on ending up in court.
The company is made up of bastards who would probably plan your first child's funeral to make sure Windows keeps its position. And I'm also reminded of how they assigned a dozen Microsoft employees( some psychologists ) to script and lead a magazine article author to the specific way they wanted the article to be written. Even down to scripting question/responses to be used when various calls from the author were made to various Microsoft people.
This Windows on ARM is going to get as much or more of the same kind of attention. Microsoft's future could ride on this. IMO
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
windows has a cli and more then 1 decent scripting system directly out of the box ya know, I really dont think your qualifications of "x years ago I messed with a friends big box hp and norton was pissy" is not compelling
wow a lot of prediction for a single picture tech demo
What does this mean for Windows 8 mobile?
WindowsCE was a joke. MaximumPC called it a "Hey we have all this old Windows 3.11 code we do not know what to do with since NT/Windows 95 came along ... hmm I know ...".
My guess is since Andriod and Ios are much more powerful and related to their native bases of Gnu/Linux and MacOSX that Microsoft is going to base Windows 8 mobile on Windows 8 desktop.
Since directX, DNA, and other cool technologies are only available on the desktop make Windows mobile 7 and 6.5 very very far behind.
Obviously Microsoft is not going to release their desktop version of Windows 8 on an arm. BestBuy and Joe Six packs trying to get office to work would have a fit.
http://saveie6.com/
Notice that MS did a pretty decent job with binary translation from the xbox to the xbox2, and that was much lower priority (in fact it was primarily written by one guy afaik, he gives talks fairly regularly). Damned if I can remember his name at the moment. But that's not all that relevant. Enough money might produce a half decent solution for windows. Also, all that code that's in windows they've had to figure out how to move to ARM, and windows is (for better or worse) a lot more than just a process scheduler and minimalist front end and API.
It's also not clear what they're targeting windows on ARM for. Desktops? Tablets? Phones? Are they going to a unified OS for all of the above? Pretty much every piece of software has requirements, if the goal is a limited subset of those markets they might do fine killing off compatibility with a lot of apps as long as it will do web browsing, office and a few other things, especially new programs compiled for whatever new market they're working on. I wouldn't be surprised if you could boil down 85 or 90% of non gaming computer use to a dozen application suites or so (office, web browsing, pdf reading, some sort of music app, e-mail, and video watching). Most of those apps are updated on a fairly regular basis so recompiling for ARM might not be a big deal, and unless you're going for a full on desktop replacement at full speed you might be able to manage. Computers are sufficiently more powerful in hardware than most applications require that even relatively inefficient implements might manage.
Wouldn't that be good for MS though?
It should still run on Windows 8 ARM (as they can control how the API works), but not on Mono?
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Windows NT ran on the cross-platform PowerPC Reference Platform, or PREP. So it ran well on various IBM Power PC boxes. Apple at that time was still dancing their proprietary dance. Some of the Mac clones were more hopeful.
I ran Windows NT 4.0 on an IBM PowerPC box. But it was an exercise in 'just because.' There were zero third party apps for it. It made a nice solitare desktop box, or you could use it as a Server.
I think you missed the point. The ISA (instruction set architecture) may be standardized (even then, there are dozens of variants), but you don't even really have an idea what sort of bus you're going to be sitting on, let alone anything else. On an x86 system you know you've got a north bridge, a south bridge, a particular type of PIC, a certain kind of timer, PCI, etc. While you could certainly build a computer based on an x86 that is completely unlike that, it would be an oddball. On ARM systems, no, pretty much anything that isn't an industry x86 architecture, it's just total chaos.
Microsoft will end up specifying a particular reference platform. Those of us who have NDAs with MS will get the details in the next little while. I even know which variant of ARM is going to be used, though of course I can't say what that is right now.
Ok: you got ARM, and you're trying to build a decent web browser. What about a decent POSIX subsystem in Windows next? Windows is the only major environment who can't run a simple bash script, this is so 90's! Given that MS survived the OS wars at ease wouldn't be hard to give a *standard* tool to Win people....
Flash would still need to be recompiled for a new platform, this will probably take Adobe until 2025 at their current rate, even assuming the API calls remain constant.
Resistance is Futile: Surrender now. You will service us. You will pay the Windows Tax. Our Arm Will Reach You. Resistance is Futile. We will add your technological distinctiveness to our own and dumb it down to the lowest cheapest junk tek. Resistance is Futile.
http://youtu.be/mVg5VxPdK80
I think we'll be surprised how many Windows apps will run on Windows 8 with just a recompile - or for that matter, just running through the .NET CLR. MS appeared to be pushing this way, one way or another, since the "Microsoft Java" days for application development, and their programming frameworks improving significantly along the way... it's not MSVC++6 anymore...
On the phone, I think the value Windows will provide will be:
* Real Outlook
* OneNote
* Modern security models
* More mature kernel with proper memory protection, etc.
* Adaptability/utility to the person who actually wants to use the device
Basically, it'll be what Windows Mobile should've been 5 years ago, and what Windows Phone isn't. At least, that's my theory.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
If you're writing code tied to a particular hardware problem in 2000 or later, you deserve whatever fail you get. Microsoft aren't stupid and will be writing hardware portable code.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
uh... by hardware problem i meant "hardware platform". problems on the brain @ work....
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I have a strong suspicion this is really just IE10 running on Windows CE7. The road towards bringing Windows 8 onto ARM is a very long and hard path, unless all backwards compability is tossed out the window.
It actually seems like Windows 8 will be atleast two different platforms with one or two common development enviroments. One separate platform for ARM and a fundamentally different one for x64, and another beast for WP7 phones that shares some similarities with the ARM version.
As always when it comes to Microsoft much water will run under the bridges and many features will be scrapped before we see the real products so its not much use speculating yet.
HTTP/1.1 400
And you know it's going to need antivirus software so start betting on 4+ cores and a couple of gigs of RAM as a minimum configuration.
How many viruses have you actually had on your system? what were they?
Please explain what "security system" performs an equivalent function to a virus scanner.
and you point out a carefully constructed view. The UI differences - multitouch and cocoa touch thereby being an example - have made the consumer extremely aware that apps written for one platform just make no sense on the other! With windows having, from a UI sense, much less differentiation (and mean wince 6.5 and previous) between phone and desktop, they could not craft the same expectation that a windows app should be "hard" to make work on a portable device. In this case, multitouch has become the valhalla by which OSX application developers can get the the average person to happily buy the same code twice Whether I like it or not.. windows would wise to "invent" a UI that has a basic divide from their mainstream offering. Is that their current offering? Maybe.. but I personally have no clue (*as a savvy developer*) what the hell all those boxes on the screen are other then some art students' thesis....
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
"Seduced and abandoned?" Not hardly. MS makes their OS for the processors it feels there is a market for. In the NT days, they decided to try it on some other platforms, since it was portable. Problem was hardly anyone was buying. Yes, yes your employer got on board, well one company is not enough to make a market for this kind of thing.
You are also incorrect about support, NT 4.0 supported Alpha, MIPS, PPC, and x86. With Windows 2000 they were dropping support for MIPS and PPC due to massive lack of interest, but initially planning on keeping Alpha support. You could get it in beta. However, Compaq announced they were dropping Windows on Alpha, so MS dropped it with RC1, since that was the last major vendor that gave a shit.
That means they supported Alpha versions of Windows NT from July 1993 (Windows NT 3.1) to June of 2004 (the date they stopped support for NT4) and they were releasing new updates for the OS until November 1999 (SP6's release date). That is not an insignificant timeline. They didn't exactly role it out and kill it a year later.
The thing is Alpha was dying by the end of 1999, when Windows 2000 was launched. Like I said, Compaq stopped supporting Windows on Alpha (and they owned DEC at that point). In 2001 they sold Alpha to Intel, killing all development for it.
So either you are pissed off because you made a bad decision, and got bitten for it (if it got orphaned in one year, you were selling your products in 2003, which means Alpha had been officially dead for two years) or you are just making stuff up because you dislike MS (given that your statements do not fit the facts).
So, what'll happen with Windows on ARM (presuming they release it, could be just a test or for embedded applications)? Well that'll depend on the market. If there is strong demand, they'll keep making it. If nobody wants it'll they'll phase it out.
Same shit with IA-64. MS supported that in Windows 2000 Server, and has continued support for it with Windows 2008R2. However demand has been declining, so they've said 2008R2 will be the last Itanium version unless anything changes. They didn't support it for one version and drop it, they supported it as long as there was demand, and if demand picks up again, so can support. It also isn't like they make it a surprise. They've announced support is stopping, however 2008R2 will be supported at least until 7/10/2018 (that is their guaranteed date for support, they can extend it). So it isn't like there isn't some time to make a change.
Windows 8 may not have x86 compatibility. MS has stated they wish to end x86 support after Windows 7 and indeed Server 2008R2 (the server version of 7 more or less) does not have x86 support. Now this remains to be seen, if there are too many current x86 devices (like Netbooks) then they may continue support, but their stated goal is to drop it and go x64 only.
Does anyone write "Pure .Net apps" though? A serious question, as I can't think of an app that I've written that is pure .Net. I always need to include some pInvoke (Platform Invoke or Windows API calls), which can make code less than portable (depending on memory packing / variable alignment, pointer size, etc.). However, since I write code to help maintain our Windows images and also as utilities for users (not as large applications), perhaps my perception is a bit skewed.
I need to use p/invoke in about half of my projects, usually to shell functions (e.g. requesting information about explorer shell items, building context menus, and the like). That's necessary for seemless integration with the desktop. But I suspect p/invoke to windows api functions will still work, it's only p/invoke to a custom dll or using a non-MS COM object/activex control that is likely to fail, so we should both be in the clear...
Thing is, emulation introduces a huge overhead. You really don't want to do it unless the architecture you're emulating is several times slower than the host architecture you're emulating it on.
That's not the case with emulating x86 on ARM.
I think the purpose is less to do with "let's run Windows everywhere" and more to do with "this way we only need to maintain one OS and maybe a different shell for tablet devices. With the added bonus that we can still take advantage of the Windows name as a marketing tool".
Windows people are gonna expect Windows apps to work which of course they most assuredly WON'T, not without a recompile that most companies simply won't do.
I'm pretty sure MS can make them run, dynamic recompilation is hardly a new concept.
The question is can they make them run with tolerable performance. Apple got away with using this method to migrate from PPC to x86 but afaict they only got away with it because the x86 boxes were much faster than the PPC boxes they were replacing. ARM boxes tend to be slow in comparison to x86 boxes.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
They already maintain the Windows Mobile 7 OS as well. And that has an OS designed for mobile touch screen devices. The most logical thing for Microsoft to do would be to use that for tablets, just as iOS and Android are used on tablets.
The fact that Microsoft aren't doing that means they see some competitive advantage to using WIndows. And it's not to do with maintaining less OSs. It's clearly that they see enterprise users wanting to use their existing Windows software on tablets. Even if that will need a few tweaks and a recompile to do it.
I'm sure they're wrong, as they've been trying to push Windows tablets for more than a decade with no success. But I'm sure they think if they can only get size down and battery life up, they'll succeed.
The really odd thing is they've had a shining example of how to do the firewall interface available right in their web browsers for years. Snapgear (bought out a few times since that name in a bigger fish eating smaller fish sort of way) made firewalls on network cards (and routers) with a very easy but powerful point and click way to set it all up. Half the ADSL routers on the planet went on to do similar simple interfaces for their firewalls. Meanwhile Microsoft dropped the ball.
I really do not understand why a company that has always been about bringing the stuff out of the server room to the masses does not copy good stuff like that along with everything else they have copied.
The malware problem is already beyond the dreams of SF too bad to publish so if it gets worse it's not going to wake up anyone that is still asleep. We're stuck with "allow by default" forever on that platform, and all we're getting from the vast swamp of malware is people getting frightened into scareware scams.
You are right about NT. It was, and still is, good kernel. Back in days it could run on many architectures and had may other nice features.
But IIRC it was Intel that killed other architectures. At least they killed Alpha by incorporating Alpha technology to Pentium. Also IIRC there was some court battle between DEC and Intel which was decided out of court but didn't turn out so good for DEC/Alpha.
You don't know what you don't know.
Ah. You again. What he is talking about is a different security model and it's not just about bashing the operating system you use so calm down.
The current model is "allow by default" with a list of bad stuff to look for after it has already got in plus some attempts at finding stuff that is try to get in, but it falls prey to race conditions so stuff still gets infected plus if it's new malware that isn't on the list yet the system gets infected.
Another security model is "deny by default" with a list of the things that are allowed. If it isn't on the list it isn't allowed to run or if it isn't on the list of things allowed to communicate it is not allowed to communicate.
These models are operating system agnostic.
Windows 7 shows a definite shift towards the second model from Microsoft and their server products adopt it to an even greater extent.
To sum up, instead of the virus scanner acting as a bandaid and list of bad stuff you instead have a list of what is allowed so that only the good stuff runs. It's not an "equivalent function". It instead removes the need for a virus scanner.
Nothing prevents anyone from writing a decent firewall software. NDIS (that's the kernel interface for network drivers) has nice interface to hook up intermediate drivers into the TCPIP stack. I've written one myself over 10 years ago.
But you are wrong. Those programs are real firewalls. They hook up their own driver to kernel to do the actual monitoring and filtering of packets. Usually they also hook up to higher level in network stack and intercept socket API calls before OS sees them to prevent socket binding operations.
Oh! I see you are an expert. Sorry. Forget everything I wrote above ;)
You don't know what you don't know.
They just used wine. :)
Steadily, stealthy? They've been screaming and ranting about it for a decade but has so far gotten nowhere despite numerous attempts. Their only advantage over other platforms are their win32 API and all the applications written for it. Take that away and you have a failed MS product.
If Win8 on ARM lacks full support for win32 its dead on arrival. That backwards compability is what makes the whole project next to impossible. The biggest error Microsoft can do is to scrap their only advantage over other platforms, the applications barrier. At the same time, thats the single most difficult issue to solve.
HTTP/1.1 400
You clearly haven't worked with any embedded systems. The PC architecture is well defined and, for the most part, backwards compatible. There's a reason you can still put a windows 95 CD in a machine and it will be able to find the display controller, enumerate the PCI busses etc. It's because much of that stuff is not going to change. Might be because the BIOS or the chipsets provide a static abstraction layer over the underlying system, but it doesn't matter - from a software view everything works the same.
When you get an embedded system what you have is a cpu core (ARM, PPC, whatever) and a whole bunch of other silicon IP on the same chip that provides additional functions. So if you want to get to the PCI bus, you need to know how that's been interfaced. Presumably there's some IP core on the chip somewhere that provides the PCI connectivity, but how do you access it? Is it at a certain memory address, do you need to write some magic control register to enable it, do you even know how it works?
If you want an example - have a look at your linux source. In my arch/x86/config I have two defconfig files, one for x86 and one for x86_64. That's it for every single PC platform out there, laptop, desktop, server, whatever. Now have a look at arch/arm/configs or arch/powerpc/configs. See the difference? Many of those will come associated with platform specific code to support that architecture. That's how Linux does it - you provide the interface between the standard system code and the underlying hardware and everything falls into place, no doubt the Windows port is similar. ARM is a CPU core, not an architecture.
What is ACE?
http://en.wikipedia.org/wiki/Advanced_Computing_Environment
microsoft have silverlight as a competitor to flash. why would they allow adobe to run flash nativelly on the new windows and/or windows phone then ?
even apple doesn't allow flash (and i don't blame them, flash on mobiles is even buggier and shittier than on desktops) and apple doesn't have anything that competes directly. MSFT does. no i don't see flash on winphone/new windows anytime soon.
What ? Me, worry ?
Fortunately Windows will probably be all but dead by then (except for in the business world).
Wow, this future must be really terrified of this future. In related news, there will be almost no professional chefs (except in the restaurant trade).
I am TheRaven on Soylent News
reportedly the Office for Windows codebase is even older
Which reports are that? Office came out for Macs first. Compare i.e. here
Microsoft will end up specifying a particular reference platform. Those of us who have NDAs with MS will get the details in the next little while. I even know which variant of ARM is going to be used, though of course I can't say what that is right now.
Good to hear. ARM has needed this for a long time, and since Google didn't do it for Android, the task falls to Microsoft.
Ironically this reference platform will make Linux on ARM an attractive prospect, unlike the current situation where your kernel has to precisely match the hardware you want to use, which makes everything very difficult for both users and developers.
You're an immobile computer, remember?
Thing is, emulation introduces a huge overhead
The thing is, no it doesn't. For one thing, most modern emulators don't emulate everything. A platform like Windows ships with a large number of standard libraries, including things for drawing and even video playback. When you draw a line in a window, 99% of the CPU time is spent computing the pixel intersections, and this is all done in Win32 code. When you draw a character on the screen, you're drawing a set of antialiased bezier curves and compositing them onto a buffer. Pretty processor intensive. However, when you do this in emulated code, only the initial call is emulated - the 99% part is native code.
For really CPU-intensive things, like video decoding, this can be even more pronounced. A Windows app playing back video will typically use DirectShow filters for the decoding. It passes a chunk of data to the filter and gets a decoded frame back (often passing it directly to the display device). In an emulated environment, the decoder filter will likely run on the ARM SoC's DSP, and the emulated code will be woken up periodically to pass it new data. Very little of the application actually runs in the emulator.
For 3D stuff the code is even shipped as bytecode already. nVidia and AMD don't even provide the same instruction set between product generations, let alone between vendors. When you run a 3D application, all of that shader code is already being JIT compiled (by the drivers) for the current target GPU. Doing it for the GPU on an ARM SoC is not a challenging problem.
I've written an article on the challenges Microsoft faces with the ARM port. None of them are insurmountable.
I am TheRaven on Soylent News
Apple got away with using this method to migrate from PPC to x86 but afaict they only got away with it because the x86 boxes were much faster than the PPC boxes they were replacing.
Running Rosetta apps on my Core 2 Duo, the CPU load is almost never above 20%. Most applications just aren't that processor intensive. The one time I noticed a high CPU load was VLC, which struggled a bit playing back HD video - it took me a few months to realise that I was using a PowerPC binary, not a universal binary, so it was running emulated.
And it's worth remembering that Apple didn't create Rosetta. The licensed it from Transitive Technologies (a spin out from Manchester University), who also license the same technology to big UNIX vendors (e.g. to IBM, so they can say 'switch from your old SPARC system to a shiny new POWER system and you can still run all of your old binary-only applications'). That same technology is available for Microsoft to license, if they want to (although they already have a nice x86 emulator in-house, since they bought the company that produced VirtualPC, which emulated an x86 PC on PowerPC Macs).
I am TheRaven on Soylent News
Closed source code will always be dependent on a fixed architecture. It just isn't practical otherwise. The only way to make it practical is virtualization, and it would have to be at the hardware/firmware level to allow these ARM chips to run an x86 OS and all the apps on top of it, and then you have to take the performance hit of basically running everything inside an emulator.
Can you imagine every single Windows app and driver needing to be released with a version for each architecture? What a nightmare that would be.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Pure .NET apps should work though, which will assist Microsoft in eliminating non-managed languages.
They should also works on other OSes with mono.
First of all, what you're saying really only applies to versions of Windows prior to Windows 7 and Server 2008 R2. Open the Windows firewall settings up in one of these operating systems and have a look at it some time. Second, I'm not sure why you think port based firewall rules provide more security than process based rules. You almost assuredly have port 80 outbound open on any desktop computer if you plan on browsing the web, which is great because my malware(tm) only makes outbound connections on port 80, using HTTP so it passes any more complex rules looking at the traffic.
Egress filtering has always been a crap-shoot that ultimately fails to enhance security in any significant way, while generally being annoying.
Adobe only recently ported their trash to AMD64. It's only months ago that I downloaded their pre-release for testing on Linux, then a couple months later I saw another pre-release for Windows. I really don't know what they've done with Mac - are they still stuck with a 32 bit version?
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
I think you misunderstand the point of AV software. It's not there to prevent things from running as a part of security policy, it's there to prevent things from running once your security policy has been circumvented.
So long as unmanaged computers exist, AV will always have its place because there are always going to be people prepared to "run this to see b00bies".
Incidentally, there's not really anything different about Windows' 7 security model as opposed to earlier versions of NT, all the way back to the 3.1. UAC is almost entirely a matter of user interface improvement.
They ported it to ARM for Android, and crappily. They will need to port it again to ARM for Windows 8, because of course, the windows API has nothing to do with Android.
If anyone were to ever start using Windows on Arm in the mobile/client space, perhaps they will port it one day. After a long period of development it may work right. As another pointed out they JUST started supporting 64-bit, even though many of us have been using 64-bit windows/linux for years.
We're not talking about embedded systems. We're talking about a new version of Windows that will no doubt require a "Certified for Windows" sticker just like the typical windows boxes you buy today.
Windows on ARM is coming due to power consumption in the mobile space. Its not coming because of an abundance of ARM hardware already in circulation. You'll buy a new ARM based box for it.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
On an x86 system you know you've got a north bridge, a south bridge, a particular type of PIC, a certain kind of timer, PCI, etc.
Have you been paying attention at all in, say, the last 20 years?
WHAT!!??!?? You are touting Microsoft security models as a selling feature?
I predict that MS will never be a major player in the tablet/phone market, for one simple reason: They will continue to call it "Windows", so the people who buy iy will expect it to work like Windows on their desktop/laptop. When it doesn't they will hate it.
This is something Apple did right.
If I were God, wouldn't I protect my churches from acts of me?
The one caveat to this is that different processor architectures have different performane characteristics, so while the base code will run (sans JS-JIT, which is architecture dependent), likely memory mangement and arithmetic would be recoded for performance reasons.
Except when Alphas were running FX!32, they were quite a bit faster than x86 machines at the time, and could get away with the emulation overhead. (And even then, some software still sucked after a trip through the profiling recompiler.)
ARM CPUs are about as fast as the slowest x86 CPUs, nowadays.
Since when is Windows endian-independent?
Because I recall reading quite a lot of stuff saying that the SPARC port of Windows was a failure due to Windows being unable to handle big-endian architectures.
(And, Alpha, MIPS, and PPC (at the time, anyway) were bi-endian, as are Itanium and ARM. And, fun fact, the de-facto standard in Linux is to treat all of those except for PPC (due to later PPCs being big-endian only) as little-endian.)
Well, Microsoft has demoed Office 2010 running on ARM, and Office 4.2 was ported to MIPS and Alpha, IIRC, and part of 97 (Word and Excel only, IIRC) ported to Alpha.
Also, ARM is pushing into the desktop space. Just because a SoC today will struggle with Windows doesn't mean that there won't be chips that can handle it when Windows for ARM actually comes out.
In any case, the rumor is that Windows for ARM won't run the normal UI or any of the normal apps - that it'll be used with a dedicated tablet UI, as a tablet OS that happens to be Windows NT instead of Windows CE under the hood.
The funny thing with all of the NT RISC boxes is, they were basically x86 PCs with a socket for a RISC CPU instead of an x86 CPU, and Microsoft's own ARC firmware instead of IBM's BIOS. (Actually, I believe there's bits and pieces of ARC in NTLDR on x86.)
Well, Windows has support for HALs. IIRC, there's just one for x86 PCs.
While Alpha, MIPS, and PPC were all following a standard that was similar to that of the x86 PC, at least on Alpha, DEC went ahead and split everything up into HALs. So, the firmware had enough to boot NT far enough to select your HAL, and then you could pick the appropriate HAL for your chipset (or supply one on floppy).
The poster that said ACE was confused, but he meant ARC - ARC being the system standard that MIPS, Alpha, and PPC-based NT systems used, much like how the Compaq Deskpro 386 defined the system standard that x86-based systems used.
I think they're going to change their naming convention.
Microsoft Windows: Desktops
Microsoft Server {Advanced, Enterprise, etc.}: Servers
Microsoft Embedded: platform for everything else, including Xboxes.
People don't really hate Windows. What they hate is crappy software. MS has improved that department a great deal in the past 5 years.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
A few comments. Microsoft has already ported office to several architectures years ago, and it's very likely that they've kept office portable since, given the high hopes Itanium had, then other architectures.
Second, Microsoft has never been as worried about commercial app compatibility as they have with custom app compatibility (all those special purpose apps that companies write internally). After 10 years, most of those apps have been converted to .NET which is architecture agnostic (for the most part). Any .net app will run without change on a version of windows for a new architecture. If they have their apps, and custom apps covered, that's probably 80% of the market, and given that ARM is likely only going to be used in tablets and possibly netbooks, rather than desktops.. they can sell an awful lot of those with 80% of the market.
If you need web hosting, you could do worse than here
IBM ported OS/2 to PPC as well, but it actually came with a x86 DOS VM... and it even ran Win-OS2! They put a lot of effort into that dead end port for nothing. http://pages.prodigy.net/michaln/history/os2ppc/index.html
Why did I bother? In an attempt to clear up your confusion I not only failed but got accused of misunderstanding myself. I course I get the point of AV software. Please read either my post or the GP post again so that you can get the point of what is being discussed here.
Your final point is quite fortunately also incorrect but I am baffled as to how you can be so unobservant as to make it at all.
Then why call it a bandaid ? It's not, it's part of a layered defense against malicious code.
What would a "non-bandaid" solution look like ? This:
Is ultimately useless so long as an ignorant end user can decide what is or is not on the whitelist.
What's changed ? UAC is mostly about a better UI to existing functionality and a change to the default configuration of a certain subset of machines. ASLR and DEP are semantic changes enabled by hardware.
At the user code level ARM is somewhat standardised. The core instruction set is standardised (though comes in several different versions each adding extra instructions). There are serveral different FPUs but afaict most current phones are using the same one.
At the OS level things get a lot messier. On a PC there is a LOT of standard hardware in standard places and the non-standard hardware tends to be on a PCI bus (with a standardised method for accessing PCI configuration space) which makes it easy to enumerate. There is also a bios which knows how to initialise the hardware, read the code from the boot sector on a drive and run it while providing it with services that let it easily access the keyboard, mouse, screen and hdd. On an arm system you might have a PCI bus but you might not, the hardware may be mapped anywhere. ARM linux distros often have multiple kernels for different hardware and the kernels they do have have many special cases in them.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Forget the analogy then and focus on the reality.
With antivirus you have list of what is not allowed but any new threat gets free reign unless the bastards that code them are lazy enough to make it similar to an existing threat. That's one reason we are up to our necks in malware even with close to universal antivirus software adoption. That is one reason why Microsoft have made many changes over the last decade to their fully open model - but as I can tell you with three wasted days last week disinfecting win7 laptops, the changes are not moving fast enough for many of us.