Because paying $99 for a developer licence as well as purchasing a Mac is a perfectly acceptable expectation to be able to install a free application that Apple didn't approve of...
I can't see much point in it either, other than the "because we can" factor. Which, since they choose to do the work themselves voluntarily, is all the justification they require.
At the moment it's just to use KDE apps on Windows, but work is underway to replace the Windows shell entirely (I doubt it will ever fully work though).
Intel has also promised OpenCL support on Sandy Bridge and later integrated GPUs.
As far as I'm aware, Intel promised that they'd get OpenCL running on the CPU (for Sandy Bridge) as opposed to the GPU after Apple pressured them for OpenCL support. OpenCL on GPU is scheduled for Ivy Bridge.
x86 itself has been around for a while, but recent developments such as x86-64 and other various instruction set extensions still have a long way to go before coming remotely close to expiring.
When I was programming on Windows CE for ARM, it used big endian whereas x86 is little endian (I wasn't aware until now that ARM supposedly is bi-endian). As for memory alignment, I've found that misaligned code on x86 runs (albeit with a performance penalty) but on ARM an exception is thrown - nuances like this will prevent simple recompiles from working. I'm not sure about primitive sizes, I've encountered issues where recompiling from x86 to x64 broke due to primitive size differences.
As for your comment that inline assembly code is not C++ code - yes you are correct. But I've seen zero non-trivial C++ applications that are pure C++ (whether it's using inline assembly or something else entirely).
I believe most open source applications should recompile fairly easily, whereas applications like AutoCAD or Photoshop or virtually any game are likely to run into issues.
...whereas every single Windows application has to be recompiled by its own developers, and then you have to buy it again.
Not entirely true. If you have already paid for the licence, you may be able to get a copy of the ARM binary for free (or for a minimal shipping charge). Autodesk applications ship these days with both 32bit and 64bit install disks in the one package, it's certainly possible to ship ARM versions in such packages too. They will of course still need to be recompiled, but you may not have to buy it again.
Porting a C++ program from x86 to ARM doesn't require any programming at all - you just select a different target and recompile. Perfect CPU port every time.
Not true. Memory alignment requirements, endianness, primitive sizes (eg 32bit vs 64bit pointers), inline assembly etc almost always come into play with non-trivial applications.
It's not something you can say "Will be done by Christmas" - they obviously just finished fleshing out the last class, so now the whole motion of implementing it is under way, and then you've got scores of beta testing to go through.
I don't think that's obvious at all. For all we know, they fleshed out the class a long time ago and have just been drip feeding information to the public. Why would they reveal all their cards in one go when they don't know when the game will ship?
Yes, of course a dedicated graphics card will help for that sort of thing. The original post I was replying to claimed that they would help Windows 7 itself and "normal everyday applications" run better, which is just nonsense.
The Intel one plays 1080p H.264 with no issues. CPU usage is higher, but unless you're watching task manager while watching your movies you'd never know.
It's an Intel GMA 4500MDH vs an ATI HD 5670 for those that are interested.
Another problem is with subpixel rendering of fonts - the rendering engines are optimised for the pixels in their horizontal configuration and it doesn't quite look right when aligned vertically.
Slashdot Mirror
After Half-Life the FPSs were all just whizz-bang.
But I chose Portal because your complaint was about the FPS interface. Portal makes good use of that interface to deliver a decidedly non-FPS game.
It may have been non-FPS, but it was still all whizz-bang. The story was appalling.
Because paying $99 for a developer licence as well as purchasing a Mac is a perfectly acceptable expectation to be able to install a free application that Apple didn't approve of...
Damn, I was hoping no-one else said that. You beat me to it...
Seriously - this is a guy who claims that if enough people in a city do TM meditation, crime rates will fall
This could easily be true. The criminals are too busy meditating to be able to commit the crimes...
And they should sue themselves for making devices such as DVD burners et al.
I can't see much point in it either, other than the "because we can" factor. Which, since they choose to do the work themselves voluntarily, is all the justification they require.
For those that would argue that the x stands for an unknown digit -- Wow, just wow, use a variable
In algebra, x is the most commonly used variable name. Many math oriented programmers tend to use C or C++, so what do you really expect?
At the moment it's just to use KDE apps on Windows, but work is underway to replace the Windows shell entirely (I doubt it will ever fully work though).
MS already has DirectCompute which is an alternative to OpenCL/CUDA and already runs on existing NVIDIA and ATI GPUs.
Intel has also promised OpenCL support on Sandy Bridge and later integrated GPUs.
As far as I'm aware, Intel promised that they'd get OpenCL running on the CPU (for Sandy Bridge) as opposed to the GPU after Apple pressured them for OpenCL support. OpenCL on GPU is scheduled for Ivy Bridge.
x86 itself has been around for a while, but recent developments such as x86-64 and other various instruction set extensions still have a long way to go before coming remotely close to expiring.
Kangaroo meat is delicious (I'd say more so than beef), but it's just too damn chewy.
Good thing this didn't have a flux capacitor at that speed...
When I was programming on Windows CE for ARM, it used big endian whereas x86 is little endian (I wasn't aware until now that ARM supposedly is bi-endian). As for memory alignment, I've found that misaligned code on x86 runs (albeit with a performance penalty) but on ARM an exception is thrown - nuances like this will prevent simple recompiles from working. I'm not sure about primitive sizes, I've encountered issues where recompiling from x86 to x64 broke due to primitive size differences.
As for your comment that inline assembly code is not C++ code - yes you are correct. But I've seen zero non-trivial C++ applications that are pure C++ (whether it's using inline assembly or something else entirely).
I believe most open source applications should recompile fairly easily, whereas applications like AutoCAD or Photoshop or virtually any game are likely to run into issues.
...whereas every single Windows application has to be recompiled by its own developers, and then you have to buy it again.
Not entirely true. If you have already paid for the licence, you may be able to get a copy of the ARM binary for free (or for a minimal shipping charge). Autodesk applications ship these days with both 32bit and 64bit install disks in the one package, it's certainly possible to ship ARM versions in such packages too. They will of course still need to be recompiled, but you may not have to buy it again.
They are just mobile (i.e. stripped down) versions of Windows XP.
No they aren't. They use a completely different code base and really only share the name.
Porting a C++ program from x86 to ARM doesn't require any programming at all - you just select a different target and recompile. Perfect CPU port every time.
Not true. Memory alignment requirements, endianness, primitive sizes (eg 32bit vs 64bit pointers), inline assembly etc almost always come into play with non-trivial applications.
Vista has the same framework architecture (Media Foundation) but it doesn't include the array of codecs that were added in 7 (such as H.264).
I'm assuming by Win7 only they're including the beta version they called vista.
Unlikely, Vista doesn't include the H.264 Media Foundation codec that ships with Windows 7.
Considering this article is revolving around the Taiwanese, you just broke it...
It was never meant to work? Are you claiming that they designed it with the intent to fail?
It's not something you can say "Will be done by Christmas" - they obviously just finished fleshing out the last class, so now the whole motion of implementing it is under way, and then you've got scores of beta testing to go through.
I don't think that's obvious at all. For all we know, they fleshed out the class a long time ago and have just been drip feeding information to the public. Why would they reveal all their cards in one go when they don't know when the game will ship?
Yes, of course a dedicated graphics card will help for that sort of thing. The original post I was replying to claimed that they would help Windows 7 itself and "normal everyday applications" run better, which is just nonsense.
The Intel one plays 1080p H.264 with no issues. CPU usage is higher, but unless you're watching task manager while watching your movies you'd never know.
It's an Intel GMA 4500MDH vs an ATI HD 5670 for those that are interested.
Another problem is with subpixel rendering of fonts - the rendering engines are optimised for the pixels in their horizontal configuration and it doesn't quite look right when aligned vertically.