Taiwanese OEMs Consider ARM Products For Windows 8 167
siliconbits writes "At CeBIT 2011, we went around the stands from some of the biggest component manufacturers in the world and asked them a simple question, would you consider bringing out ARM products (barebones, laptops, tablets, motherboards) for Windows 8? The answer was a unanimous yes; like Microsoft, the same firms that have been faithful Intel and AMD partners for years are prepared to explore other territories as soon as Windows 8 will go live."
Dumb question - of course they'll say yes. (Score:5, Insightful)
Re:Dumb question - of course they'll say yes. (Score:4, Insightful)
What did you expect them to say - "No, we won't - we'll cede that market to our competitors, because our customers prefer products with crappy battery life"?
Parent is correct... and for even more reasons than indicated. (no, this next section is not a slam against MS... read through the whole thing) Sure, Win8 may bomb on such things (pick a reason: no interest, Microsoft yet again not fulfilling their promise to have something actually suitable for such devices, Win8's requirements being too absurd for such "minimalist" hardware, whatever)... but the simple fact is, it may gain traction and take off. On that possibility, there isn't one OEM with half a brain that would say "no, we aren't doing this" at this point in time. When the correct time comes to make a decision, they'll choose to (a) release some test bed units, (b) dive full in or (c) look away from Win8 and concentrate on other things - but now is definitely not them time for them to say no, especially under the possibility that they will need Microsoft's good will in the future (assuming Win8 proves suitable and desired on such devices).
Re: (Score:2)
these companies are already making ARM products, it's just that they'll be making them for the next windows version when it comes out. So this is a change of nothing.
hint: it's not going to be called windows 8.
Re: (Score:3)
hint: it's not going to be called windows 8.
Yes, it would be uncharacteristic for MS to settle on a versioning scheme.
We've already had version numbers, two-digit years, four-digit years, single-digit numbers, acronyms and names.
The only thing left is using nonsensical symbols like Prince did; TOSFKAW.
Re: (Score:2)
Wrong question, wrong answer.
All major Taiwanese manufacturers have been shipping ARM based devices for years. The only difference as far as they are concerned is that instead of WinCE 3 years ago and Android today they will be shipping Win8. They are not the ones who support the end product and do the software development for it so they could not care less what it actually runs.
Good (Score:4, Funny)
Re: (Score:3)
Re: (Score:3)
Re:Good (Score:5, Informative)
All x64 CPU's support both single and double precision SSE, which is why its the default for 64-bit targets. If you are targeting a 32-bit OS, then a 32-bit binary cannot simply assume that single precision SSE is available, let alone the later double-precision support of SSE2.
Also, the x87 FPU performs calculations in 80-bit precision, so is not directly comparable to SSE's single and double precision features.
Finally, it is not "some compilers".. its ALL THE MAJOR ONES, both 32-bit and 64-bit.
Re: (Score:2)
...the x87 stack...
...the x87 FPU...
Are you being consistent with your typo, or am I missing something?
Re: (Score:2)
All x86_64 compilers ouput SSE, as x87 isn't supported in 64-bit mode.
Re: (Score:2)
Depends on if your'e doing kernel code or similar. The device driver and OS dev crowd still uses it...
Re: (Score:3)
Re: (Score:2)
You realize that in practice both terms can be, and are, used interchangeably right?
http://en.wikipedia.org/wiki/Assembly_language#Use_of_the_term [wikipedia.org]
Ofcourse, both are wrong. It should be "assemblino".
Re: (Score:2)
Not that anyone even uses assembly anymore...
Assembly's used all the time for embedded systems.
No compiler's going to generate code as compact as a good programmer. That can be important when there's only a handful of KB for firmware. Performance is less of an issue these days, but if you're clever you can still shave off a few cycles. I don't think we've quite reached the 'John Henry' point yet in terms of optimization.
I even know a few weirdos who find it easier to write and/or read than C.
Re: (Score:2)
Re:Good (Score:5, Insightful)
RISC won 20 years ago, all x86 processors decode to some internal instruction set. I am certain the engineers at Intel and AMD have tested exposing the native instructions and if it could perform much faster than x86 I'm sure they'd enable applications to bypass the hardware decoder and send micro-ops directly. While they still process the instructions the really obscure ones live in microcode instead of hardware, x86_64 adjusted the number of registers etc. so most things have been tweaked. I don't need to remind you that the last attempt to do better was the Itanic...
Re: (Score:2)
Exposing the micro-ops would mean they have to keep some compatibility, keeping them hidden behind x86 means they can change the micro-op functions all they like without impacting compatibility.
Re: (Score:2)
RISC won 20 years ago, all x86 processors decode to some internal instruction set. I am certain the engineers at Intel and AMD have tested exposing the native instructions and if it could perform much faster than x86 I'm sure they'd enable applications to bypass the hardware decoder and send micro-ops directly.
No need, as they are already exposed directly. Plenty of instructions that emit a single micro-op... for example, most of AMD's DirectPath instructions emit a single micro-op and in fact, 100% of AMD's micro-op's can be found in the set of DirectPath instructions.
Re: (Score:2)
I am not really sure what your point about itanium is exactly. We were discussing for the most part technical realities if RISC, CISC, and micro code. Itanium is first off still in production, in fact they just released new models, and second if its a failure it is so in the marking sense more so than the technical sense. The chip performs well.
MS Windows supported RISC 15 years ago ... (Score:3)
OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.
MS Windows NT 4 supported RISC 15 years ago in 1996(*), Dec Alpha, IBM/Motorola PowerPC and MIPS. All on the standard Win NT 4 retail CD. Consumer oriented PowerPC machines were available. I recall Byte magazine comparing dual PowerPC and dual x86 systems. Alpha machines were available for the more serious users. Despite better computational performance on the RISC based machines x86 won due to price and software availability. ARM could fail as well. ARM may have better battery performance but is it so much
Re: (Score:3)
Is ARM the new ACE? (Score:2)
(*) OK you can argue 1993, day 1 for Win NT, since MIPS was supported. However I don't think there was any real push towards a consumer MIPS machine. The motivation was more internal, making sure Win NT was portable to other architectures.
On the contrary, there was a major push by the ACE consortium [wikipedia.org] to replace the x86 PC with a common platform built around MIPS and Windows NT. Unfortunately, it was mostly industry hype with very little product appearing in the retail channel before the whole thing was discarded.
Re: (Score:3)
The software issue might not be as big this time a round. Netbooks aside, ARM is driving today's tablets, cellphones, and embedded devices. That seems to be where computing is going in general. It simply won't make sense to bring most of the existing PC software into that world. The software that does make sense to go there is cross platform already. Hell I am running ArmedSlack on my GuruPlug and its package for package almost exactly the same as the x86 Slackware versions.
So people are really not goi
Re: (Score:2)
OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.
Does this mean I'll finally be able to use my books on CHRP [wikipedia.org]?
Re: (Score:2)
LoB
Re: (Score:2)
I've been trying to get an article through slashdot submission which describes exactly this: perhaps this article which has been accepted will trigger people to realise what i'm on about. if you put multiple RISC cores into 28nm or below, they SCREAM along at such unbelievably fast speeds that pure economics dictates that it is insane to ignore them. LEON4 by gaisler.com can do up to 8 cores, each at 1.5ghz, in 30nm. the size of the chip is so small that you can fit i believe it's around 10,000 processor
Re: (Score:2)
http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=338&Itemid=231 [gaisler.com]
"The LEON4 pipeline uses 64-bit internal load/store data paths, with an AMBA AHB interface of either 64- or 128-bit. Branch prediction, 1-cycle load latency and a 32x32 multiplier results in a performance of 1.7 DMIPS/MHz, or 2.1 CoreMark/MHz."
there's an excellent overview from 2009 of the LEON4 architecture, even if it's just the abstract of a paper, try googling this:
Next Generation Multi-Purpose Microprocessor
Re: (Score:2)
the main site also reports that you can either put up to 2mb of 2nd level cache down, to get high performance, or you can put zero cache down, to save power. the usual deal, basically.
Re: (Score:2)
The last hope of an open RISC platform was back in the mid `90s when the PowerPC platforms were getting tos
Re: (Score:3, Informative)
As I recall Windows NT 4.0 was independent of hardware. They had this concept they called HAL, which did all of the communication when it came to hardware. You had an alpha chip, no problem, just get a alpha HAL. I have in person seen Windows NT 4.0 running on other architectures, including alphas and apples of the day (long before they switched to intel equipment).
I'm guessing they dropped this capability with one of the newer incarnations...
Re: (Score:3)
As I recall Windows NT 4.0 was independent of hardware. They had this concept they called HAL, which did all of the communication when it came to hardware. You had an alpha chip, no problem, just get a alpha HAL. I have in person seen Windows NT 4.0 running on other architectures, including alphas and apples of the day (long before they switched to intel equipment).
I'm guessing they dropped this capability with one of the newer incarnations...
Ummm... yeah, kinda... other than the massive portions that are monolithic and definitely tied to the hardware in NT 4. XP has a HAL as well... guess which other versions do also? As a matter of fact, most OS's have a device abstraction layer. Such does not make a multi-platform OS, as both IBM (OS/2 PPC) and MS (Windows NT for certain RISC schemes) can tell you via the problems they had getting their operating systems to run on non Intel compatible hardware. Even with how modular OS/2 was (in comparison to
Re: (Score:2)
NT was designed from the ground up to be processor agnostic. I've even got a Byte Magazine around somewhere with a little news article about Microsoft first getting OS/2 NT V3 to boot up (to text mode).
It was a MIPS processor IIRC. This was before it booted on X86 and even before they officially switched it to Windows.
OS/2 was (and still is) tied to X86 and the PPC version had to have a new kernel, different device driver system as well as the last of the 16 bit API ported to 32 bit. Even the object format
Re: (Score:2)
NT was designed from the ground up to be processor agnostic. I've even got a Byte Magazine around somewhere with a little news article about Microsoft first getting OS/2 NT V3 to boot up (to text mode). It was a MIPS processor IIRC. This was before it booted on X86 and even before they officially switched it to Windows.
NT was intended to be designed from the ground up to be processor agnostic. In actuality, it ended up being (by the time there was more than just a text mode NT) hardly such. Things changed a LOT by the time NT 4 came out.
OS/2 was (and still is) tied to X86 and the PPC version had to have a new kernel, different device driver system as well as the last of the 16 bit API ported to 32 bit. Even the object format was ELF instead of OMF. Some of it was ported to X86 OS/2 like the GRADD video driver model.
Any OS that I know of, NT included, needs a different "kernel" (abstraction layer) for different hardware. OS/2's kernel *IS* much of the abstraction layer. All one megabyte of it. Oh, sorry, I mean... no, that's what I meant... one megabyte. The rest, such as the BASE device drivers, of c
Re: (Score:2)
As I recall Windows NT 4.0 was independent of hardware ... I'm guessing they dropped this capability with one of the newer incarnations...
They dropped it only in the sense that they no longer offered it to the public. Recall that Windows NT was started on MIPS, x86 came later. The goal was to make sure the code was portable between architectures. My understanding is that internally MS kept building NT (XP, Vista, 7, ...) on non-x86 platforms to maintain/verify portability.
Re: (Score:2)
x86 on MiPs required a secondary x86 coprocessor that changed the instruction set.
So if it started on MIPS then it did so very poorly.
Re: (Score:2)
No, it didn't require a secondary x86 coprocessor.
It just ran on MIPS.
The problem is, x86 userland software didn't run without being recompiled (except for a badly emulated DOS environment), so if your software vendor didn't compile for MIPS, you were screwed.
On Alpha, DEC did a profiling recompiler for NT, and due to the speed of the Alpha, that approach nearly worked, except for Compaq getting distracted by Itanium, and cancelling Alpha stuff just as it was picking up steam into Windows 2000.
Re: (Score:2)
NT has always supported RISC architectures. Even today Itanium is supported on Windows Server 2008 R2.
In fact, NT was first developed on MIPS and i860 RISC chips, the X86 port came later (seriously). Back in the 1990s, there were active NT versions for MIPS, PPC and Alpha and Itanium. There were even rumours of a Sparc port.
The reason that most of those ports aren't alive today is that the hardware manufacturers told MSFT that they weren't interested in supporting NT for their platform any more.
Re: (Score:2, Insightful)
Not that it matters at this point. VLIW, like in high-performance DSP's and certain niche processors, is the future.
Re: (Score:3)
"VLIW, like in high-performance DSP's and certain niche processors, is the future."
I want an Itanium in my iPhone!
Re: (Score:3)
Not that it matters at this point. VLIW, like in high-performance DSP's and certain niche processors, is the future.
Yes, VLIW has been the future since the 1970s.
Re: (Score:3)
Predictability does not exist on any modern CPU because of a variety of factors, including caches, super-scalar execution, out of order execution, and branch prediction.
On a load-store (which is the precise term for what most people call "RISC") architecture, roughly 1 in every 3 instructions is either a branch or a memory instruction. On a CPU with caches and branch prediction you cannot have predicta
Re: (Score:2)
OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.
MS-DOS was running on ARM's x86 emulator in 1987 [chriswhy.co.uk].
Well, that's not quite the same as running natively on it... even though somewhat similar to how things run on today's 64bit CPUs.
Re: (Score:2)
You used to be able to emulate x86 on the Amiga too, using applications such as PC-Task or PCX...
Opportunities (Score:3)
Re: (Score:2)
Yeah, I also prefer they don't cater to the wants of their customers rather than the wants of the minuscule minority that are fighting some petty OS war.
Re: (Score:2)
Linux is already making inroads in casual users' phones (the Android kernel). Not that they know or care about it. As a Linux desktop user I'm fine with that and I'm just happy that about all the web applications I worked on in the last years are running on Debian servers or on Debian-derivatives.
I just don't believe that casual users will ever massively switch to Linux. Maybe they'll start to use Chrome OS tablets but they won't know about them being Linux-inside, just like almost all iPhone and iPad users
Re: (Score:2)
I'd actually prefer they didn't. Joke as you will, it's an excellent opportunity for Linux to make inroads to the more casual user. The last one (netbooks) didn't get much time before Microsoft jumped in with XP netbooks.
If Microsoft's track record is a good indication, I would be happy if they DID go for it... can anyone count how many versions of Windows were targeted at tablets - and failed to get anywhere except niche markets like Home Depot's inventory carts? Heck, even skip the WinMo crap that was never suited for touchscreen.
"Everyone" wants a tablet nowadays. Apple and the various OEMs that build on Android are doing a phenomenal job. A blunder like taking iOS and Android on in markets they were designed for would
Re: (Score:2)
Who is "everyone"? Not me or most of the people I know.
Re: (Score:2)
Who is "everyone"? Not me or most of the people I know.
You didnt note the use of quotation marks in my post? Nor understand their meaning?
Re: (Score:3)
If Microsoft's track record is a good indication, I would be happy if they DID go for it... can anyone count how many versions of Windows were targeted at tablets - and failed to get anywhere except niche markets like Home Depot's inventory carts? Heck, even skip the WinMo crap that was never suited for touchscreen.
Why MS failed at tablets was all they did was shove Windows into a different form factor. And then called it done. Now other than having a touchscreen and using a stylus instead of a mouse, Windows tablets were just very expensive laptops. In the many years MS pushed tablets, they only wrote one application that truly used touch. They however left the rest of the OS very keyboard/mouse centric. So for the average consumer, why would they buy an expensive touchscreen laptop that gave them no real advant
Re: (Score:2)
Actually until the iPhone came out, touch was considered uninteresting in consumer devices. All the tablets I've ever seen were designed around stylus input, not touch.
When the iPhone came out it was a game changer in more ways than one - touch became the norm, capacitive screens instead of resistive ones, etc.
Re: (Score:2)
Actually until the iPhone came out, touch was considered uninteresting in consumer devices. All the tablets I've ever seen were designed around stylus input, not touch.
When the iPhone came out it was a game changer in more ways than one - touch became the norm, capacitive screens instead of resistive ones, etc.
Nope, and I even mentioned such touch based usages. There's plenty more like POS systems. Efforts were made to hit the consumer market, but there were no apps suitable, regardless of whether a stylus or finger was the modus operandi.
Re: (Score:2)
Add that Microsoft has a poor track record for building an architecture neutral OS, and fell back so easily to the X86 architecture back in the 90s. How many versions of windows will be available for the ARM or another architecture? win8, maybe 9? Then they drop support if there aren't enough users.
This is one place where Open Source and Free software excel. As long as the users of that architecture are willing to pony up the talent, they are guaranteed the access they need to make it work. With Window
Re: (Score:2)
Nice to see that even the Linux partisans know that the only way for Linux to have desktop success is to have no competition. Given a choice, almost no one would choose linux.
Migrate to Linux. To get people to switch to something - anything, it can't be "as good as". There has to be some specific reason to do it that you're not getting anywhere else, unless you're dealing with very idealistic/cost averse people. Running on ARM while Windows didn't could be one such thing. In fact I suspect will be one such thing, because most apps will only be x86 no matter what Microsoft does.
Personally it was the pre-SP Vista that did it, I was like "fuck if this is the way forward I'd rather
Re: (Score:2)
Re: (Score:2)
No, it's more that Microsoft will move in and compel the OEMs to ditch Linux, as they did with netbooks.
Re: (Score:2)
Re: (Score:2)
Android isn't really Linux. Linux is basically a bootloader for it.
That's one mighty large, over-engineered bootloader!. Why didn't they just use uBoot?
Re: (Score:2)
It's a load of dingo's kidneys. Linux is a kernel. Anyone who says different is selling something.
ARM Windows (Score:5, Insightful)
How are they going to explain to the million of Windows users that no application they know will work on ARM Windows? It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low. I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?
Well, at least I can then finally buy some ARM notebooks and put a decent Linux distribution on it.
Re: (Score:2)
How are they going to explain to the million of Windows users that no application they know will work on ARM Windows?
Clever marketing that appeals to yuppies.
"Don't be left behind with slow stupid x86 Microsoft Office, upgrade to the new better more powerful Microsoft ARM Office today. It's newer so you know its better, and come on it has the word "Arm" in it, which means powerful, duh!"
Re: (Score:2)
And I expect the market for ARM-based Windows 8 devices to be just as horrible as it is now, in terms of replacing the OS, as it is for tablets and phones. Lack of drivers, binary only video drivers, and lock down to prevent people from actually removing the OS.
And here I was hoping that the transition to ARM would get us away from Microsoft's domination. Now it could very well be enforced in hardware.
Re: (Score:3)
Windows 64bit is different, most 32bit applications run on it just fine and the 32bit consumer versions are crippled (ie wont support more than 4gb of address space, even tho the hardware is capable of it using PAE)...
Windows on ARM won't run x86 applications natively, and if they provide an emulation option it will be almost certainly be extremely slow.
Re: (Score:2)
The tablet market is the perfect transition to a more controlled Microsoft Windows ap
Re: (Score:2)
Re:ARM Windows (Score:4, Interesting)
It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low. I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?
The reason 64-bit wasn't was adopted quickly was more about need vs features. The model MS choose for their 64-bit migration (LLP) meant that 32-bit programs were backwards compatible. So there was no need for a consumer to get 64-bit Office because 32-bit Office would work fine in 64-bit Windows. If all the 32-bit programs worked either way on 64-bit or 32-bit OS, there wasn't as much as a push to migrate. Unfortunately 64-bit Windows would often times require new drivers. So there were more negatives moving to 64-bit on Windows unless the consumer had a specific need like more memory addressing. For the most part, businesses were more open to using 64-bit Windows Server as there was a need in many cases to access more than 3GB of RAM.
Software companies that wanted to take advantage of 64-bit for Windows had to maintain separate 32-bit and 64-bit binary and source code versions during the migration. While the 32-bit version would work on either Windows flavor, the 64-bit would not work on a 32-bit OS. Many companies were reluctant to maintain two versions especially if moving to 64-bit provided no real advantage.
The Linux/Unix/OS X model (LP) took a different approach as that model focused more on forward compatibility. A 32-bit program could be made into a 64-bit program with a recompile and testing to ensure there were no special scenarios that required 32-bit addresses, etc. Software companies would have to maintain two binary versions but for the most part could maintain one version of source code. With Linux/Unix/OS X, a great deal of software was open source so that it was far easier to make this migration.
Re: (Score:2)
The lack of a 64 bit version of Office was probably an issue too. Although Office 2010 is now 64 bit none of the previous ones were.
Re: (Score:3)
Read about LLP vs LP [wikipedia.org]. MS choose LLP which introduced a new 64-bit data type: long long (that's not a typo) and kept a 32-bit type: long. In terms of backwards compatibility, LLP means you don't have to recompile or do anything to have your 32-bit program still work. However you cannot simply recompile a 32-bit program to take advantage 64-bit; you actually had to change source code and compile. In some cases, it was going to be a simple find and replace; in other cases, it wasn't that easy. This means
Re: (Score:2)
That said, you still have a couple things wrong. First, LLP doesn't really "introduce" long long; that's been usable even in 32-bit software for ages.
Not according to unix.org [unix.org]. What you are talking about is the C99 standard which isn't about data models but a specific programming language specification. I don't have a definite history of LP64 vs LLP64 but the paper from unix.org suggests that it predates C99 by at least a year. Also as you no doubt aware, not every compiler follows the C99 standard fully. GCC supports it mostly. And some compilers use the older C89 standard. And if you are using Windows you are not using the C99 compiler, you are u
Re: (Score:2)
Re: (Score:2)
That said, that code is latently broken anyway; in some sense it doesn't deserve to work in the first place. But that doesn't mean that the Windows crew has to maintain two source trees; that's ridiculous. What it means instead is that if you have an 'int' variant that you want to hold an address, you should use 'intptr_t' instead. Which is what the Linux software should be doing anyway.
Yes they could avoid the problem if everyone wrote in standard Ansi C99 but as you are no doubt aware, C varies when factoring compiler and hardware differences. Add to that software companies coding for Windows may not code in standard C but Microsoft C++ and in one of the MS programming platforms like .NET where they use MS data types instead of the low level "intptr t".
Re: (Score:3)
The switch from 32bits to 64bits *is* going to break some set of applications. There's simply no way to avoid it.
If you use the LP model, you're going to break every application that assumes that sizeof(int) == sizeof(long). Call this set IntEqualsLong.
If you use the LLP model, you're going to break every application that assumes that sizeof(int) == sizeof(void *). Call this set IntEqualsPointer.
The question is: Is the set of applications in IntEqualsLong greater than the set of applications in IntEqualsPoi
Re: (Score:2)
If they're aiming at the tablet/netbook market, then the lack of hardware drivers won't be a problem, they just need to support the on-board hardware and a few key applications (IE, Office, Flash). Ironically, i
Re: (Score:2)
By releasing prototype hardware to devs before going to launch so apps do exist for the platform?
We are no longer in the paradigm of "will my apps run?" but "will there be an app that lets me do $task with $data?"
ARM Windows but not on desktop PC (Score:2)
I don't think desktop machines will move, or at least not move easily. However, unlike 1993, desktop machines aren't quite the PC universe anymore. On the top, we have legions of rack mounted servers. Coming up from the bottom are smart phones and tablets. Neither of these segments is as tightly wedded to Windows as the desktop. Tablets today already run ARM and don't run Windows. For Microsoft, this must be very disturbing.
With servers, the move hasn't happened yet but data centers are seriously lo
Re: (Score:2)
It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low.
That's because most people don't need it. Hell, you can buy a $2000-2500 top MacBook/iMac and it doesn't have more than 4 GB standard. Me, I got 16 GB and disabled swap entirely but I don't really need it. Not even under the craziest of workloads I put on it would I break the 10 GB barrier, and that includes one app that likes to chew 2-3 GB alone + one full VM. I just like having more than enough.
Re: (Score:2)
You don't typically play games on a small low power netbook anyway...
Linux already offers browsers and media players, but selling windows on arm will probably hurt their brand more than anything because users will buy it expecting it to be the same as x86 windows, and then be sorely disappointed...
At least if they buy linux, they wont be expecting x86 compatibility and will use it for what it is.
Re: (Score:3)
The CIOs dealing with thousands of seats requiring little more than Microsoft's suite, few easily ported business applications and a browser will appreciate that no application that their Windows users want (except Office, and the small number of official applications) will work on ARM Windows.
Lack of compatibility is a feature, not a bug.
Now they don't have to justify "why don't you let me install my XYZ" any more.
They just say "OK go ahead and try it" to their lusers, knowing that it won't work.
Those peop
Duh (Score:2)
Stupid question.
Of course any system builder will tell you they'd "consider" ARM for Windows 8. They'd also "consider" building 9.6GHz 8088 systems running MS-DOS powered by the blood of virgins if that's where it looked like the market might go.
Re: (Score:2)
Stupid question.
They'd also "consider" building 9.6GHz 8088 systems running MS-DOS powered by the blood of virgins if that's where it looked like the market might go.
Is there a website I can pre-order on?
Re: (Score:2)
> Is there a website I can pre-order on?
No, but if you send me your credit card information I'll see if I can get you on the beta list...
What kind of devices? (Score:2)
Editors, please, don't allow publish such articles (Score:2)
What's aim of this article? What's reasoning to begin with? Right, ARM is next hot cake, and Microsoft have no presence whatsoever on this platform. Therefore it must fall back to PR companies which tries to push articles like "Waiting for Windows 8", "ARM will be supported in Windows 8", "Hey, did you know Windows 8 is next best thing?" on portals like Slashdot.
Of course manufacturers will try to support any major operational system in the market - that includes Windows - if suddenly full blown Windows on
Hope the taiwanese got a big warehouse (Score:2)
MS has in the past had its problems with delivering on time and companies have gotten burned if they planned a release of a product to need a unreleased MS product while MS was dragging its feet. Early Win95 games come to mind. There was a reason Quake was a DOS game. Blue Isle took a hit on making their next Battle Isle game require Win95.
I would be very hesistant to plan hardware yet on a completely unproven platform from a company that has never ever cared a tiny bit about its customers. See MS and the l
Re: (Score:2)
There is already a reasonably steady market for ARM-based android widgets, NAS devices, etc, etc. Microsoft will, presumably, have their own set of special requirements(as with tablet PCs needing a ctrl+alt+del key) and some sort of minimum spec floor; but the basic nature of the ARM SoC market means that they wo
Economics rule this out. ARM/MIPS Laptops... (Score:2)
he issue that you've got is that a) microsoft is not going to have windows for ARM until 2013, and even then it is impossible to get third party developers to do total rewrites of drivers b) emulation of x86, even with hardware assistance (similar to jazelle) only provides something like 30% equivalent performance. so you have a great processor, maybe 2ghz dual-core if you get the one from nufront, you smash its capabilities down to a staggering and mundane 700mhz, and you can only get up to about 1.5 gb of
Re: (Score:2)
Virtualizing any classic win32 x86 binaries on ARM is going to suck so much, in terms of performance, that they might as well not bother. By the time Windows 8 actually makes it out the door, Intel w
Re: (Score:2)
i did hear that ARM has a jazelle-like acceleration for CLR. it is not well-understood, and, crucially as you point out, there isn't much call for it because you can't run silverlight on a non-existent OS! :)
logo? (Score:2)
If this is a ARM story, why is the logo set to AMDs? they haven't bought them out yet have they?
Obvious OEM is obvious (Score:2)
And since when do Taiwanese OEMs have the slightest clue about anything besides cost-cutting ? Yeah, duh, they'll jump on ARM because it'll be loads cheaper than Intel/AMD/Via, so instead of charging a 5x premium to box it and ship it overseas, they will charge a 10x premium.
That's like asking: if you could bottle tap water and sell it to cretinous americans for $3.00 a litre, would you ?
Re: (Score:2)
WinCE + (Score:2)
Dont forget the embedded devices running windows too.
Two differences are the net and the .NET (Score:2)
One difference between Windows NT 4 and Windows 8 is that the latter has the .NET Framework. Once Microsoft ports the CLR and the UI toolkit, all fully managed applications are automatically ported. This includes any Silverlight application and any XNA game.
Another difference is that since the NT 4 days, home Internet access has become ubiquitous, mobile Internet access has become practical even if at a luxury price, efficient techniques for interpreting dynamic languages such as JavaScript have become know
Re: (Score:2)
Yes, but
is Office 100% .NET? Most likely not
MS Live Messenger?
(apart from that IE should be easier to convert, I guess)
At least MS has some experiences with ARM tools.
Microsoft will obviously recompile its own apps (Score:2)
is Office 100% .NET?
No, but that's not a deal killer. Microsoft Office or any other Microsoft application can and most likely will be recompiled for ARM, though the recompiled version won't work with third-party add-ons written in native code.
MS Live Messenger?
As far as I know, Windows Live Messenger has already been recompiled for both ARM (Windows Phone 7) and PowerPC (Xbox 360).
Re: (Score:2)
Re: (Score:2)
I'm not sure how it was on IA64, I guess it was a virtual machine kind of thing, but I remember people not being that happy
(guess what http://news.cnet.com/Intel-scraps-once-crucial-Itanium-feature/2100-1006_3-6028817.html [cnet.com])
Re: (Score:2)
On Windows, that subsystem was totally transparent. Running a Win32 x86 binary on IA64 would happen just like running one on any other Windows system, with no special steps.
Re: (Score:2)
Manufacturers manufacture hardware, it's up to users to decide what OS it will be on(or decline sales figures if such choice is not there). M$ made decision to have their future OS's to be compatible with ARM. Now what? Manufacturers will be on purpose create devices that are not Windows compatible?
For the most part, consumers don't care what OS they use. They just want their devices to work. Manufacturers may not care about developing software for their hardware, but they care whether their product has software. The lack of software would mean far fewer sales to consumers. In the past if Asus wanted to make an ARM based laptop, they had fewer choices on the OS and thus the software. Asus could either use Linux or BSD or come up with their own OS. And how many software makers would write softwar