Arguably, this *is* an alternative voting system. There's a few ways it could be implemented, too.
1) In each race, you may cast one positive vote for a candidate, or one negative vote. 2) In each race, you may cast one each positive and negative vote. 3) In each race, you may cast two votes, in any combination of positive or negative, but they must be for different candidates. 4) As #3, but without the restriction against voting for (or against) a candidate twice. 5) In each race, you may cast a positive vote, and half of a negative vote (positive votes have twice the impact of negative ones). variations on all of the above are possible......
#1 is simple, and addresses the problem of "You all suck, nobody deserves this vote" well enough... but also risks some serious instability if there are so many negative votes that even a relative handful of positive ones (for a candidate nobody bothered to vote against) is enough to put them on top. #2 addresses that problem somewhat, although it's an interesting question whether the possible outcome (in a close race) of "both major parties were hammered by negative votes, to the extent that they came out at approximately zero and a third party who got 2% of the positive vote won it" is really proper. #3 allows for "Fuck the two-party system!!" or for "I'm going to vote for the candidate who should win, and the candidate who has a chance" (in which case the latter candidate may actually win, if they don't garner large numbers of negative votes). #4 allows those who feel strongly in favor or opposition toward a given candidate to express that preference... but "the most beloved by a subset of the population" as opposed to "the widest support of the population as a whole" isn't necessarily an outcome we want to make too easily achievable. #5 is my favorite, personally. Elections are meant to indicate a preference, not a rejection. Under this system, I could still say "candidate X is a nutcase, but candidate Y isn't much better, I'm voting third-party" while nonetheless impacting the two-party system. The odds of a given candidate going negative are very low, but it's a reasonable expectation that the two major parties would garner almost all the negative votes, bringing their pedestals over all the third parties a lot lower.
Numerous variations on #5 are also possible. Negative vote is -.75 instead of -.5, to bring the major parties lower still. Apply the weighting of negative votes, then use any of #1-#4 or a variant thereupon.
The AMD hybrid CPU/GPU chips are great from the perspective of a low-cost chip that can handle moderate gaming, but they don't have the ultra-low power designs that Intel does. They also are less powerful as CPUs than an i7 (4 hardware threads vs. 8). They might be suitable (if the power consumption can be held in check) for a mid-range device capable of some gaming, but this is intentionally a fairly high-end model (its GPU is nothing to write home about... except that they shoehorned it into such a compact package, and that there's a discrete GPU at all).
Excellent point. This device is a very well-specced ultra-portable computer... that also happens to be a tablet, and to be designed to support gaming. Not everybody who wants such hardware specs in a compact form factor is going to want the touchscreen or the gaming power, but in a market of a thousand look-alike low-end devices, it's nice to see somebody branching out.
My one concern from a productivity standpoint is the size of the keyboard. The Surface manages to (barely, or perhaps almost... it's missing a couple keys) squeeze a full-size keyboard onto its cover, with the spacing correct for touch typing from muscle memory and even usable for light coding (well, scripting on the Surface RT), but it's not ideal. A 12" laptop or tablet can fit a proper keyboard without needing to map so many keys onto Fn+[other key].
You have a gaming laptop that weighs less than two pounds?? I mean, this isn't even two pounds, (~900g) so if you know of a gaming laptop (dedicated GPU, decent CPU, at least 4GB of RAM) that weighs less, please let me know. Even the lightweight ones tend to be at least 2.5lb.
FWIW, there are touchscreen games for Win8. Completely leaving aside the Windows Store games (some of which are pretty fun, but which play more like oversized smartphone games than "serious" PC games), there are some other games which explicitly support touch on Win8. The first one that comes to mind is Civilization 5, which has an explicitly touch-enabled-and-friendly UI option which is intended for use on Win8 touchscreen devices.
That said, I understand that this is/. and all, but assuming that it's touchscreen-based gaming just because the description uses the word "tablet" is stupid. "Read" the article (i.e. look at the picture) and you'll see that it's not targeting touchscreen gaming at all. The thing has grips with hardware controls (buttons/analog sticks/probably triggers) on the sides, intended to effectively substitute for a gaming controller or joystick. Additionally, it can use Xbox 360 or PS3 (or probably Wii) controllers without any trouble (as any Windows system with USB ports and Bluetooth can do), and many PC games are designed to be playable with such a gamepad (unsurprising, considering how many are console ports).
Christian "Scientists" believe that all modern medicine is inherently fraudulent, and participating in it is a lack of faith in God keeping you healthy. On the one hack, yeah, they aren't likely to want to take vaccinations. On the other hand, while I could easily imagine them caring for the sick in general (this is one of the things Christian Scientists are supposed to do, in fact, in the same way that many Christian sects instruct their followers to care for the unfaithful and bring them back to the "right" path), I have a hard time imaging one becoming a registered nurse and working in a hospital.
Besides, while I can kind of see the argument against flu shots (their effectiveness varies, some people do have reactions to the mostly dead virus causing short-lived flu-like symptoms after getting the injection, death from influenza is mostly preventable today, etc.) I can't imagine any hospital worker not having received some of the truly standard and often mandatory (even in day-to-day life, such as going to public school) vaccinations. Measles/mumps/rubella? Tetanus? Vaccinations like that are a lot less on the minds of most people (you get them as kids, and then maybe a booster a decade later), but I sure as hell don't want to be treated by any hospital staff who hasn't had them, especially if I need to be put on immuno-suppressants or am for some other reason immuno-compromised......
The important point here, other than that yes, you can sideload and debug on RT without paying extra for the privilege, is that the value which must be changed is in kernel mode, but RT only allows user-mode debugging. The kernel debugger is disabled via Secure Boot (the bootloader understands the debug switch, but if you attempt to set it, Secure Boot will block you).
Typically, attaching a debugger to a user-mode process still doesn't let you modify kernel memory; the debugged process and the debugger itself are both running in ring 3, which means they can't write to ring0-only memory (the kernel's address space). The hack here is that there's a security bug in Windows where a trusted system process can make a call into the kernel which, due to lax parameter checking, can be used to overwrite a part of kernel memory. While the kernel *does* verify that it is this trusted process calling the vulnerable function, the kernel does not check that the process hasn't been modified by a debugger. Attaching a debugger to a system process requires Admin, but Windows RT allows running processes as Admin so that is not a problem.
There is some code injected, but it's injected into the user-mode process CSRSS.EXE using the debugger, not injected into the kernel. The injected code modifies a struct which is then passed as a parameter to the kernel via a system call. This call can only be made by the CSRSS (Client/Server Runtime SubSystem) process, and the kernel "trusts" it more than it should (lack of sanity checks on the parameters). When the kernel processes the modified struct, it will change the required signing level flag within the kernel.
Pretty easy, the task scheduler is included in Windows RT. It's a single Powershell command (must be run as Admin): Show-WindowsDeveloperLicenseRegistration. That pops an interactive dialog, but it's easy enough to get through.
I actually hadn't bothered to do this before (I have MSDN access, so the developer registration lasts for 3 months each time) but for those using the 1-month registrations, a scheduled task to renew it makes a lot of sense.
So far as I'm aware, just the application name (specifically, the package name that it is registered on the system with) and possibly a binary list; I haven't fully explored it yet. This appears to be intended as an anti-piracy protection. I've got a number of sideloaded apps, including some which are relevant to this type of work and completely unsuitable for Windows Store development (I'm looking into an alternative approach that doesn't require a kernel security hole, but I'm nonetheless on the periphery of the developers who were working on this). If MS wanted to block the developer license I use for sideloading them, they could have done so any time in the past few months.
Of course, I could then just get another one... it's not like the licenses cost anything.
Visual Studio 2012 (including the free Express variants) can compile for ARM. In fact, they have to, otherwise you couldn't write native apps (games, usually) for Windows RT at all..NET code and HTML5+JS apps will run natively on RT without recompiling, but C++ apps - which is how most games are written, and some other software - require a recompile. It's trivial to do this recompile in VS, though - there's a drop-down option to build for x86, x64, or ARM.
Now, with that said, by default Visual Studio won't let you build an ARM *desktop* app, only a "Windows Store" (The Interface Formerly Known As Metro) app. This is very easy to work around, though - you either need to set one #define (or/D in the build command) or change the relevant header (the error tells you which one) and also change one XML build configuration (again, you'll get an error telling you which one). The instructions for doing so have been posted on XDA-Developers for months.
It's not actually really running arbitrary code in kernel, just changing some kernel memory which causes the kernel to run different code. All the code running is already present in the kernel - this isn't a code injection attack, or even ROP - but instead merely flipping a switch that isn't supposed to be accessible from user-mode. Very minor nit-pick, but I wanted to be clear on that. If (for example) Microsoft had decided to not permit the "Unsigned" level at all, and had removed the code which executes that path, this exploit would not work in its current state. However, that would be a non-trivial change to the program loader, which is a pretty core part of the OS. By just changing a flag that the program loader already understands, MS is able to keep the source for Windows RT pretty nearly identical to that of Windows 8.
Ummmm.... no. You can sideload "Metro" applications just fine (after running one command to unlock this capability). The packages must be signed, but they can be signed by anybody (including self-signed), so long as they chain to any trusted certificate. Visual Studio generates an install script for the package that checks whether its (also auto-generated) signing cert is trusted, and if not, offers to install the cert for you. You can also do so manually (just double-click the cert file and follow the usual import steps).
So,.APPX (Metro application bundle) files don't require "Microsoft" signing level. What about the binaries they contain, though? It turns out that those don't need to be signed at all. At least a month back, a different branch of the "run everything on Windows RT" project bore fruit; we could run "desktop" apps within the AppContainer of a "Metro" app. (WinRT isn't supposed to include the APIs to launch new processes directly, but you have to be linked against the system call interface on Windows anyhow, which means it's possible to just scan the address space for the NtCreateProcess entry point and call it.) These apps don't have to be signed *at all* even without anything like the hack posted here. They run with low Integrity Level and have (by default) extremely limited permissions (access the System32 directory, their install directory, and their data directory, and only the last of those with write permissions), but they do not have to be signed.
You do realize that sideloading "Modern" (a.k.a. "Metro") applications is fully possible and officially supported, right? The difference is that those have to run in an application sandbox that limits their capabilities and restricts the APIs they can call... in particular, they aren't supposed to be able to access the Win32 API, which is needed for making something that is recognizably Windows software (what Microsoft is calling a "desktop app" because it runs in the Desktop view of Win8 / Windows RT).
The breakthrough here is twofold: 1) Run homebrew / non-Windows-Store software outside of the application sandbox (at whatever permission level you like, all the way up to Admin, which is already possible for any desktop app that you can run on Windows RT). 2) Port legacy software to Windows RT with merely a recompile, rather than forcing people to re-write the software to use the new APIs.
There isn't really anything else that this hack permits which wasn't already possible on RT... but both of those are pretty big achievements.
Office for Mac and Office for Windows are at least 70% the same code, and that was a few years ago. They were targeting 90%, I believe. Already, all of the document rendering/layout/document format code (at least for 2010/2011) is supposedly identical, just recompiled for OS X. The GUI and certain features specific to each platform obviously must be different, and there's a compatibility layer which abstracts the core APIs used by Office from the OS they run on (supporting things like using the Windows Common Controls on Win32 to display file open/save/print/etc, and using the analogous controls on OS X when on that platform) and that compatibility layer obviously needs to be platform specific.
Are you on crack, or just talking out your ass? There are at least 15 reasonably general-purpose YouTube clients on the Windows Phone app store, and many more that are specialized to things like specific channels, or downloading just the audio track, etc. Where the hell did you get the idea that MS doesn't allow third-party YouTube apps?
The Radeon HD 7xxx series cards, such as the 7950 in my PC, are manufactured using a 28nm process. It's actually smaller than what AMD uses for their CPUs, oddly enough (the current CPUs are 32nm). 40nm is a couple generations back.
"Fundamentally broken" is BS. It would be fundamentally broken if the cards didn't *work* with the old drivers. You *might* even get away with that claim if the cards were unplayably slow, or the spikes were serious enough to make Windows think the driver had stopped responding, or some other such problem. "Benchmarks show that there is a specific performance problem, even though the overall performance is quite acceptable, and the issue was traced to an un-optimized memory manager which nevertheless was working correctly" is not even to "broken" by any reasonable definition, much less "fundamentally" so.
You can't patch them out, because it's not actually a vulnerability; the APIs are just being accessed in an unusual way. Just because Windows Store apps don't normally have access to the CreateProcess APIs doesn't mean that it's a bug that you can call them anyhow when the system call entry library is mapped into the process; that's just the way C works (literally... the app is just scanning the process address space for the entry point, then creating a function pointer with the found address and correct signature, and calling it). At worst, they might add a heuristic scan for that behavior to Windows Defender, but you could always just whitelist the relevant binaries or turn off Defender.
As for what the quoted paragraph means, it means somebody at ZDNet is speculating about Microsoft's intentions and putting those speculations on the web. Nothing more, nothing less. It certainly doesn't mean that they are going to start cracking down on "improper" sideloading. It also doesn't mean that they won't, but that would be very, very tricky to do without breaking the entire value of the developer license... and they can hardly afford to impede or otherwise piss off Windows Store developers. Out of curiosity, have you read the actual MSDN Dev Center page? The relevant portion is quoted below, emphasis again mine:
Microsoft can detect fraudulent use of a developer license on a registered machine. If Microsoft detects fraudulent use or another violation of the software license terms, we might revoke your developer license. The monitoring process helps ensure the overall health of the app marketplace.
My own speculation, based on both what I've read and on personal experience: 1. Microsoft is only worried about the "overall health of the app marketplace" (which basically means preventing piracy) and doesn't really care about stuff that would never be allowed in the store anyhow. 2. Microsoft's recourse if they decide they don't like what you're doing is to revoke your developer license (the one that you got for free and can make an effectively unlimited number of...) 3. Microsoft is not automatically revoking these licenses whenever anybody does anything they might not like. Even assuming they can detect "fraud" other than pirating apps, they may just not care.
The Wii U doesn't have a particularly impressive CPU compared to the 360 or PS3, but its GPU is notably better (which is sort of an embarrassing position for the "hardcore gaming" consoles to be in) and - possibly most critically - it has vastly more RAM. In 2005, 512MB of RAM was an acceptable amount for a gaming system. Today, it's a low-end smartphone... or a "serious" gaming console. Consoles could do *so* much with more RAM. Even if it's not used for anything more than heavy background pre-caching to eliminate load screen and so forth once and for all, that would be major progress. More realistically, though, it could but used for everything from bigger maps with more in-depth environments to vastly more advanced AIs to much better-quality textures and models and possibly even things like custom sound packs, serious character customization options, and all the other little tricks that PC gaming has had for at least half a decade and is gimped if present at all on the console.
Umm... are you just really phenomenally bad at reading comprehension, or actually trolling? To quote the entire paragraph you extracted that quote from:
Apple has perhaps the most famously restrictive app store. When you sign up for a developer account you're allowed to push out builds of apps that you write to up to 100 devices. But you categorically cannot run production apps in this mode -- you can only allow testing.
Emphasis mine. What does the awful state of sideloading on Apple devices have to do with Microsoft or Windows RT? Microsoft may *prefer* people to use the "official" sideloading channel (which requires a paid license and top-down control) instead of developer license sideloading, but they don't enforce that in any way, and they even take the time to point out that dev licensing can be used to install untrusted apps:
If you acquire and run Windows Store apps from sources other than the Windows Store, take the same precautions you normally do when acquiring desktop apps from the web.
So far as I can tell, the only "abuse" that MS actually cares about is piracy of paid apps. This was a problem on Windows Phone, even with the much more-restrictive developer registration (paid account required for most users, limit 10 sideloaded apps unless you hacked it), and is expressly called out as something that a dev license can be revoked for (although, so what if they do; you can get another, for free, at any time). After all, an app which goes behind the WinRT API's back to find the NtCreateProcess system call (CreateProcess isn't supposed to be available) using techniques most commonly observed in malware, and then uses that to launch unsigned desktop-mode applications... well, that's pretty far from a "legit" use of a developer license, but it's exactly the kind of thing that people *should* be allowed to do via sideloading if they want to, and it works fine*.
* For loose values of "fine" - the unsigned native EXE still runs in the AppContainer sandbox, which severely constrains what it can do. Still, if you statically link everything and are careful about the ACLs, it works.
Probably the hot corners. The "Charms" bar, in particular, is a crucial way of interacting with "modern" apps - most of them offer no other way to access either their settings or their search functionality, because those are required to be built in - and while there is a keyboard shortcut (Win+C) to display the bar, it's intended to display on the right side of the screen (which is also where you put the mouse to access it) and I don't know how well that would go over with windowed apps. Additionally, there's the resolution issue. at 1024x768 (the minimum resolution most apps are designed to expect, although they will scale to other resolutions with varying degrees of grace), most monitors even today would have difficulty displaying many of them at once. Sure, you could switch between them... but that's already supported, and the touch gesture used for it (swiping in from the left) would be very odd for switching between windowed apps.
Slashdot Mirror
Arguably, this *is* an alternative voting system. There's a few ways it could be implemented, too.
1) In each race, you may cast one positive vote for a candidate, or one negative vote.
2) In each race, you may cast one each positive and negative vote.
3) In each race, you may cast two votes, in any combination of positive or negative, but they must be for different candidates.
4) As #3, but without the restriction against voting for (or against) a candidate twice.
5) In each race, you may cast a positive vote, and half of a negative vote (positive votes have twice the impact of negative ones).
variations on all of the above are possible......
#1 is simple, and addresses the problem of "You all suck, nobody deserves this vote" well enough... but also risks some serious instability if there are so many negative votes that even a relative handful of positive ones (for a candidate nobody bothered to vote against) is enough to put them on top.
#2 addresses that problem somewhat, although it's an interesting question whether the possible outcome (in a close race) of "both major parties were hammered by negative votes, to the extent that they came out at approximately zero and a third party who got 2% of the positive vote won it" is really proper.
#3 allows for "Fuck the two-party system!!" or for "I'm going to vote for the candidate who should win, and the candidate who has a chance" (in which case the latter candidate may actually win, if they don't garner large numbers of negative votes).
#4 allows those who feel strongly in favor or opposition toward a given candidate to express that preference... but "the most beloved by a subset of the population" as opposed to "the widest support of the population as a whole" isn't necessarily an outcome we want to make too easily achievable.
#5 is my favorite, personally. Elections are meant to indicate a preference, not a rejection. Under this system, I could still say "candidate X is a nutcase, but candidate Y isn't much better, I'm voting third-party" while nonetheless impacting the two-party system. The odds of a given candidate going negative are very low, but it's a reasonable expectation that the two major parties would garner almost all the negative votes, bringing their pedestals over all the third parties a lot lower.
Numerous variations on #5 are also possible. Negative vote is -.75 instead of -.5, to bring the major parties lower still. Apply the weighting of negative votes, then use any of #1-#4 or a variant thereupon.
The AMD hybrid CPU/GPU chips are great from the perspective of a low-cost chip that can handle moderate gaming, but they don't have the ultra-low power designs that Intel does. They also are less powerful as CPUs than an i7 (4 hardware threads vs. 8). They might be suitable (if the power consumption can be held in check) for a mid-range device capable of some gaming, but this is intentionally a fairly high-end model (its GPU is nothing to write home about... except that they shoehorned it into such a compact package, and that there's a discrete GPU at all).
Excellent point. This device is a very well-specced ultra-portable computer... that also happens to be a tablet, and to be designed to support gaming. Not everybody who wants such hardware specs in a compact form factor is going to want the touchscreen or the gaming power, but in a market of a thousand look-alike low-end devices, it's nice to see somebody branching out.
My one concern from a productivity standpoint is the size of the keyboard. The Surface manages to (barely, or perhaps almost... it's missing a couple keys) squeeze a full-size keyboard onto its cover, with the spacing correct for touch typing from muscle memory and even usable for light coding (well, scripting on the Surface RT), but it's not ideal. A 12" laptop or tablet can fit a proper keyboard without needing to map so many keys onto Fn+[other key].
http://apps.microsoft.com/windows/en-US/app/angry-birds-star-wars/c7628194-ce39-4a18-97e9-590af59c2fd0
http://apps.microsoft.com/windows/en-US/app/angry-birds-space/8ece2571-91e0-4f2f-b7e5-b0b7944ced2d
Clearly, you know a great deal about the Win8 app ecosystem...
Remarkably enough, that's where I do a non-trivial portion of my tablet gaming... what features would one *made* for such an activity offer, I wonder?
You have a gaming laptop that weighs less than two pounds?? I mean, this isn't even two pounds, (~900g) so if you know of a gaming laptop (dedicated GPU, decent CPU, at least 4GB of RAM) that weighs less, please let me know. Even the lightweight ones tend to be at least 2.5lb.
FWIW, there are touchscreen games for Win8. Completely leaving aside the Windows Store games (some of which are pretty fun, but which play more like oversized smartphone games than "serious" PC games), there are some other games which explicitly support touch on Win8. The first one that comes to mind is Civilization 5, which has an explicitly touch-enabled-and-friendly UI option which is intended for use on Win8 touchscreen devices.
That said, I understand that this is /. and all, but assuming that it's touchscreen-based gaming just because the description uses the word "tablet" is stupid. "Read" the article (i.e. look at the picture) and you'll see that it's not targeting touchscreen gaming at all. The thing has grips with hardware controls (buttons/analog sticks/probably triggers) on the sides, intended to effectively substitute for a gaming controller or joystick. Additionally, it can use Xbox 360 or PS3 (or probably Wii) controllers without any trouble (as any Windows system with USB ports and Bluetooth can do), and many PC games are designed to be playable with such a gamepad (unsurprising, considering how many are console ports).
Christian "Scientists" believe that all modern medicine is inherently fraudulent, and participating in it is a lack of faith in God keeping you healthy. On the one hack, yeah, they aren't likely to want to take vaccinations. On the other hand, while I could easily imagine them caring for the sick in general (this is one of the things Christian Scientists are supposed to do, in fact, in the same way that many Christian sects instruct their followers to care for the unfaithful and bring them back to the "right" path), I have a hard time imaging one becoming a registered nurse and working in a hospital.
Besides, while I can kind of see the argument against flu shots (their effectiveness varies, some people do have reactions to the mostly dead virus causing short-lived flu-like symptoms after getting the injection, death from influenza is mostly preventable today, etc.) I can't imagine any hospital worker not having received some of the truly standard and often mandatory (even in day-to-day life, such as going to public school) vaccinations. Measles/mumps/rubella? Tetanus? Vaccinations like that are a lot less on the minds of most people (you get them as kids, and then maybe a booster a decade later), but I sure as hell don't want to be treated by any hospital staff who hasn't had them, especially if I need to be put on immuno-suppressants or am for some other reason immuno-compromised......
The important point here, other than that yes, you can sideload and debug on RT without paying extra for the privilege, is that the value which must be changed is in kernel mode, but RT only allows user-mode debugging. The kernel debugger is disabled via Secure Boot (the bootloader understands the debug switch, but if you attempt to set it, Secure Boot will block you).
Typically, attaching a debugger to a user-mode process still doesn't let you modify kernel memory; the debugged process and the debugger itself are both running in ring 3, which means they can't write to ring0-only memory (the kernel's address space). The hack here is that there's a security bug in Windows where a trusted system process can make a call into the kernel which, due to lax parameter checking, can be used to overwrite a part of kernel memory. While the kernel *does* verify that it is this trusted process calling the vulnerable function, the kernel does not check that the process hasn't been modified by a debugger. Attaching a debugger to a system process requires Admin, but Windows RT allows running processes as Admin so that is not a problem.
Self-reply with more info...
There is some code injected, but it's injected into the user-mode process CSRSS.EXE using the debugger, not injected into the kernel. The injected code modifies a struct which is then passed as a parameter to the kernel via a system call. This call can only be made by the CSRSS (Client/Server Runtime SubSystem) process, and the kernel "trusts" it more than it should (lack of sanity checks on the parameters). When the kernel processes the modified struct, it will change the required signing level flag within the kernel.
Pretty easy, the task scheduler is included in Windows RT. It's a single Powershell command (must be run as Admin): Show-WindowsDeveloperLicenseRegistration. That pops an interactive dialog, but it's easy enough to get through.
I actually hadn't bothered to do this before (I have MSDN access, so the developer registration lasts for 3 months each time) but for those using the 1-month registrations, a scheduled task to renew it makes a lot of sense.
So far as I'm aware, just the application name (specifically, the package name that it is registered on the system with) and possibly a binary list; I haven't fully explored it yet. This appears to be intended as an anti-piracy protection. I've got a number of sideloaded apps, including some which are relevant to this type of work and completely unsuitable for Windows Store development (I'm looking into an alternative approach that doesn't require a kernel security hole, but I'm nonetheless on the periphery of the developers who were working on this). If MS wanted to block the developer license I use for sideloading them, they could have done so any time in the past few months.
Of course, I could then just get another one... it's not like the licenses cost anything.
Visual Studio 2012 (including the free Express variants) can compile for ARM. In fact, they have to, otherwise you couldn't write native apps (games, usually) for Windows RT at all. .NET code and HTML5+JS apps will run natively on RT without recompiling, but C++ apps - which is how most games are written, and some other software - require a recompile. It's trivial to do this recompile in VS, though - there's a drop-down option to build for x86, x64, or ARM.
Now, with that said, by default Visual Studio won't let you build an ARM *desktop* app, only a "Windows Store" (The Interface Formerly Known As Metro) app. This is very easy to work around, though - you either need to set one #define (or /D in the build command) or change the relevant header (the error tells you which one) and also change one XML build configuration (again, you'll get an error telling you which one). The instructions for doing so have been posted on XDA-Developers for months.
It's not actually really running arbitrary code in kernel, just changing some kernel memory which causes the kernel to run different code. All the code running is already present in the kernel - this isn't a code injection attack, or even ROP - but instead merely flipping a switch that isn't supposed to be accessible from user-mode. Very minor nit-pick, but I wanted to be clear on that. If (for example) Microsoft had decided to not permit the "Unsigned" level at all, and had removed the code which executes that path, this exploit would not work in its current state. However, that would be a non-trivial change to the program loader, which is a pretty core part of the OS. By just changing a flag that the program loader already understands, MS is able to keep the source for Windows RT pretty nearly identical to that of Windows 8.
Ummmm.... no. You can sideload "Metro" applications just fine (after running one command to unlock this capability). The packages must be signed, but they can be signed by anybody (including self-signed), so long as they chain to any trusted certificate. Visual Studio generates an install script for the package that checks whether its (also auto-generated) signing cert is trusted, and if not, offers to install the cert for you. You can also do so manually (just double-click the cert file and follow the usual import steps).
So, .APPX (Metro application bundle) files don't require "Microsoft" signing level. What about the binaries they contain, though? It turns out that those don't need to be signed at all. At least a month back, a different branch of the "run everything on Windows RT" project bore fruit; we could run "desktop" apps within the AppContainer of a "Metro" app. (WinRT isn't supposed to include the APIs to launch new processes directly, but you have to be linked against the system call interface on Windows anyhow, which means it's possible to just scan the address space for the NtCreateProcess entry point and call it.) These apps don't have to be signed *at all* even without anything like the hack posted here. They run with low Integrity Level and have (by default) extremely limited permissions (access the System32 directory, their install directory, and their data directory, and only the last of those with write permissions), but they do not have to be signed.
CLR = Common Language Runtime = "things using .NET". You basically just re-stated his comment...
You do realize that sideloading "Modern" (a.k.a. "Metro") applications is fully possible and officially supported, right? The difference is that those have to run in an application sandbox that limits their capabilities and restricts the APIs they can call... in particular, they aren't supposed to be able to access the Win32 API, which is needed for making something that is recognizably Windows software (what Microsoft is calling a "desktop app" because it runs in the Desktop view of Win8 / Windows RT).
The breakthrough here is twofold:
1) Run homebrew / non-Windows-Store software outside of the application sandbox (at whatever permission level you like, all the way up to Admin, which is already possible for any desktop app that you can run on Windows RT).
2) Port legacy software to Windows RT with merely a recompile, rather than forcing people to re-write the software to use the new APIs.
There isn't really anything else that this hack permits which wasn't already possible on RT... but both of those are pretty big achievements.
Office for Mac and Office for Windows are at least 70% the same code, and that was a few years ago. They were targeting 90%, I believe. Already, all of the document rendering/layout/document format code (at least for 2010/2011) is supposedly identical, just recompiled for OS X. The GUI and certain features specific to each platform obviously must be different, and there's a compatibility layer which abstracts the core APIs used by Office from the OS they run on (supporting things like using the Windows Common Controls on Win32 to display file open/save/print/etc, and using the analogous controls on OS X when on that platform) and that compatibility layer obviously needs to be platform specific.
Are you on crack, or just talking out your ass? There are at least 15 reasonably general-purpose YouTube clients on the Windows Phone app store, and many more that are specialized to things like specific channels, or downloading just the audio track, etc. Where the hell did you get the idea that MS doesn't allow third-party YouTube apps?
The Radeon HD 7xxx series cards, such as the 7950 in my PC, are manufactured using a 28nm process. It's actually smaller than what AMD uses for their CPUs, oddly enough (the current CPUs are 32nm). 40nm is a couple generations back.
"Fundamentally broken" is BS. It would be fundamentally broken if the cards didn't *work* with the old drivers. You *might* even get away with that claim if the cards were unplayably slow, or the spikes were serious enough to make Windows think the driver had stopped responding, or some other such problem. "Benchmarks show that there is a specific performance problem, even though the overall performance is quite acceptable, and the issue was traced to an un-optimized memory manager which nevertheless was working correctly" is not even to "broken" by any reasonable definition, much less "fundamentally" so.
You can't patch them out, because it's not actually a vulnerability; the APIs are just being accessed in an unusual way. Just because Windows Store apps don't normally have access to the CreateProcess APIs doesn't mean that it's a bug that you can call them anyhow when the system call entry library is mapped into the process; that's just the way C works (literally... the app is just scanning the process address space for the entry point, then creating a function pointer with the found address and correct signature, and calling it). At worst, they might add a heuristic scan for that behavior to Windows Defender, but you could always just whitelist the relevant binaries or turn off Defender.
As for what the quoted paragraph means, it means somebody at ZDNet is speculating about Microsoft's intentions and putting those speculations on the web. Nothing more, nothing less. It certainly doesn't mean that they are going to start cracking down on "improper" sideloading. It also doesn't mean that they won't, but that would be very, very tricky to do without breaking the entire value of the developer license... and they can hardly afford to impede or otherwise piss off Windows Store developers. Out of curiosity, have you read the actual MSDN Dev Center page? The relevant portion is quoted below, emphasis again mine:
My own speculation, based on both what I've read and on personal experience:
1. Microsoft is only worried about the "overall health of the app marketplace" (which basically means preventing piracy) and doesn't really care about stuff that would never be allowed in the store anyhow.
2. Microsoft's recourse if they decide they don't like what you're doing is to revoke your developer license (the one that you got for free and can make an effectively unlimited number of...)
3. Microsoft is not automatically revoking these licenses whenever anybody does anything they might not like. Even assuming they can detect "fraud" other than pirating apps, they may just not care.
The Wii U doesn't have a particularly impressive CPU compared to the 360 or PS3, but its GPU is notably better (which is sort of an embarrassing position for the "hardcore gaming" consoles to be in) and - possibly most critically - it has vastly more RAM. In 2005, 512MB of RAM was an acceptable amount for a gaming system. Today, it's a low-end smartphone... or a "serious" gaming console. Consoles could do *so* much with more RAM. Even if it's not used for anything more than heavy background pre-caching to eliminate load screen and so forth once and for all, that would be major progress. More realistically, though, it could but used for everything from bigger maps with more in-depth environments to vastly more advanced AIs to much better-quality textures and models and possibly even things like custom sound packs, serious character customization options, and all the other little tricks that PC gaming has had for at least half a decade and is gimped if present at all on the console.
Umm... are you just really phenomenally bad at reading comprehension, or actually trolling? To quote the entire paragraph you extracted that quote from:
Emphasis mine. What does the awful state of sideloading on Apple devices have to do with Microsoft or Windows RT? Microsoft may *prefer* people to use the "official" sideloading channel (which requires a paid license and top-down control) instead of developer license sideloading, but they don't enforce that in any way, and they even take the time to point out that dev licensing can be used to install untrusted apps:
So far as I can tell, the only "abuse" that MS actually cares about is piracy of paid apps. This was a problem on Windows Phone, even with the much more-restrictive developer registration (paid account required for most users, limit 10 sideloaded apps unless you hacked it), and is expressly called out as something that a dev license can be revoked for (although, so what if they do; you can get another, for free, at any time). After all, an app which goes behind the WinRT API's back to find the NtCreateProcess system call (CreateProcess isn't supposed to be available) using techniques most commonly observed in malware, and then uses that to launch unsigned desktop-mode applications... well, that's pretty far from a "legit" use of a developer license, but it's exactly the kind of thing that people *should* be allowed to do via sideloading if they want to, and it works fine*.
* For loose values of "fine" - the unsigned native EXE still runs in the AppContainer sandbox, which severely constrains what it can do. Still, if you statically link everything and are careful about the ACLs, it works.
Probably the hot corners. The "Charms" bar, in particular, is a crucial way of interacting with "modern" apps - most of them offer no other way to access either their settings or their search functionality, because those are required to be built in - and while there is a keyboard shortcut (Win+C) to display the bar, it's intended to display on the right side of the screen (which is also where you put the mouse to access it) and I don't know how well that would go over with windowed apps. Additionally, there's the resolution issue. at 1024x768 (the minimum resolution most apps are designed to expect, although they will scale to other resolutions with varying degrees of grace), most monitors even today would have difficulty displaying many of them at once. Sure, you could switch between them... but that's already supported, and the touch gesture used for it (swiping in from the left) would be very odd for switching between windowed apps.