Microsoft Surface - WTF?
-
@TheCPUWizard said:
Thus Surface Pro. It ships with an active stylus and supports touch. It will disable the touch imput when the tip of the pen gets close so you don't accedentally invoke a command via touch with your hand while holding the stylus.@Mo6eB said:
I really miss touchscreens that were made to be operated with a pen, instead of a finger. You could do things like write on them or click small buttons and so on.
Alas, as a cost effective decision, it is very expensive to make a single device the supports *both* well, and devices which were restricted to a pen saw only limited adoption..
-
@spamcourt said:
It's still wrong that you can't install any fucking OS you want in your own fucking computer.
Your average mom/yuppie/building crew boss/spoiled teenager does not care about which OS they use. All they want is for their device to be able to run Angry Birds and open Facebook.
Do you care about which OS your car's GPS or your programmable microwave uses? Do you refuse to use Windows ATMs?
I read an interesting article in the paper (!) about why cars are getting less popular in Europe - their role as a teenager/twen symbol of freedom has been replaced with the internet as a whole, so people only buy cars when they actually need transportation so hard that they want to sink thousands of bucks into it. So I shouldn't be surprised that FREEDOM OF OS is a big thing for many people. But in the end, just like it doesn't matter which brand of car you buy, it doesn't matter which OS you use unless you are a car geek cq. programmer. You get the freedom of a car/the internet either way.
Or perhaps the writer has good pay, job security and isn't aware that there is a crisis in Europe.
-
On a slightly different note, the Surface has now been jailbroken - at least to the point where you can install your own apps onto it. Apparently Microsoft acknowledged that it had happened and does not appear to be quick to patch it because the break does not present a security issue (according to them).
-
@The Bytemaster said:
On a slightly different note, the Surface has now been jailbroken - at least to the point where you can install your own apps onto it. Apparently Microsoft acknowledged that it had happened and does not appear to be quick to patch it because the break does not present a security issue (according to them).
Will post the same thing I have written elsewhere....
The "jailbreak" only bypasses the store. The programs to be loaded must still be Windows RT applications and this has nothing to do with "regular desktop applications" which require x86/x64 Intel. WinRT applications are inherently "safer" as they only have "sandbox" access.
So after all is said and done, the only change is that apps from another location can be loaded. If one believes that Microsofts [or any vendors] Store review process is going to catch 100% of problem applications they are living in a dream world.
Regardless of source, one needs to caerfully consider applications, especialy considering the vendor of the application and their reputation.
-
By your logic...
The programs to be loaded must still be iOS applications and this has nothing to do with "regular desktop applications" which require x86/x64 Intel. iOS applications are inherently "safer" as they only have "sandbox" access.
The programs to be loaded must still be Android applications and this has nothing to do with "regular desktop applications" which require x86/x64 Intel. Android applications are inherently "safer" as they only have "sandbox" access.
The programs to be loaded must still be HTML5 applications and this has nothing to do with "regular desktop applications" which require x86/x64 Intel. HTML5 applications are inherently "safer" as they only have "sandbox" access.
EDIT: One more!
The programs to be loaded must still be Windows CE applications and this has nothing to do with "regular desktop applications" which require x86/x64 Intel.
-
Miff - I dont get your point...
-
@TheCPUWizard said:
Miff - I dont get your point...
RT is NOT Windows. Stop saying it should be able to run Windows software with no modifications. Android can't run Linux-distro software, iOS can't run OSX software, and Windows CE can't run Windows software. Just because it's based on Windows and is Windows branded doesn't mean it is Windows.
-
@TheCPUWizard said:
The "jailbreak" only bypasses the store. The programs to be loaded must still be Windows RT applications and this has nothing to do with "regular desktop applications" which require x86/x64 Intel. WinRT applications are inherently "safer" as they only have "sandbox" access.
The jailbreak actually allows regular desktop applications to run. Yes, they have to be compiled for Arm, but they have access to the unrestricted Win32 API (admittedly, Microsoft did purge some parts of that on Arm, but not enough to present significant problems, except for .net applications that use WPF - that's not available, while Windows Forms are; .net applications that are marked as AnyCPU [and don't rely on specific native DLLs] also run without modifications, as long as they don't use WPF).
-
@ender said:
Yes, they have to be compiled for Arm, but they have access to the unrestricted Win32 API (admittedly, [b]Microsoft did purge some parts of that on Arm[/b], but not enough to present significant problems, except for .net applications that use WPF - that's not available, while Windows Forms are; .net applications that are marked as AnyCPU [and don't rely on specific native DLLs] also run without modifications, as long as they don't use WPF).
Based on the PUBLIC information I have gathered, the restrictions at the Win32 API level are quite significant. From a security persepective it is largely about accessing data that is NOT owned by the application in question. Do you have documentation that there is this ability that is accessible via the BCL/CLR as deployed on RT.
-
@MiffTheFox said:
@TheCPUWizard said:
Miff - I dont get your point...
RT is NOT Windows. Stop saying it should be able to run Windows software with no modifications. Android can't run Linux-distro software, iOS can't run OSX software, and Windows CE can't run Windows software. Just because it's based on Windows and is Windows branded doesn't mean it is Windows.
Apparently you did not read what I wrote:
[b]The programs to be loaded must still be Windows RT applications [/b]
-
My boss once said to our team: "It sounds like you're in violent agreement."
-
@ender said:
except for .net applications that use WPF - that's not available, while Windows Forms are; .net applications that are marked as AnyCPU [and don't rely on specific native DLLs] also run without modifications, as long as they don't use WPF).
Damn, I actually liked WPF. The origional Surface big-ass-tables basically depended on it.
-
@TheCPUWizard said:
Based on the PUBLIC information I have gathered, the restrictions at the Win32 API level are quite significant. From a security persepective it is largely about accessing data that is NOT owned by the application in question. Do you have documentation that there is this ability that is accessible via the BCL/CLR as deployed on RT.
You are talking about Metro^W^W^W^WodernUI^W^W^W^W^W^W^W^WWindows Store applications. I'm talking about desktop applications running on jailbroken Windows RT.
-
@ender said:
@TheCPUWizard said:
Based on the PUBLIC information I have gathered, the restrictions at the Win32 API level are quite significant. From a security persepective it is largely about accessing data that is NOT owned by the application in question. Do you have documentation that there is this ability that is accessible via the BCL/CLR as deployed on RT.
You are talking about Metro^W^W^W^WodernUI^W^W^W^W^W^W^W^WWindows Store applications. I'm talking about desktop applications running on jailbroken Windows RT.No I am NOT. I am talking about .NET applications, such as those based on WinForms. There is no "P/Invoke" capability on RT, so unless the BCL/CLR has an API then a .NET application can not access physical resources [amon other things].
-
@TheCPUWizard said:
There is no "P/Invoke" capability on RT, so unless the BCL/CLR has an API then a .NET application can not access physical resources [amon other things].
Are you sure that this limitation isn't only for Windows Store applications? People have gotten regular desktop applications to work on RT (and I was talking about desktop .NET applications):
-
1) Once an appliction is on the system it does not matter where it came from. What matters is if the code in the application tries to access code in the runtime libraries that no longer exists or is blocked. So there is nothing special about "store" apps once loaded.
2) Other editions support "side loading" (loading applications without the store) for use in business [so called enterprise] senarios. So the capability has been there, but was not intended for immediate exposure [IMHO to have a better handle on apps and quality, which is a good thing]. So the exposure of this capability (the so called jailbreak) is not really suprising or important.
3) If someone wants to hide "malware" in an application that is going through the store, I am confident that they can. No review is going to ever be 100%. So cavaet emptor (what is latin for downloader beware???) ALWAYS applies, even though many try to convince the world of "safety".
-
@TheCPUWizard said:
cavaet emptor (what is latin for downloader beware???)
caveat onerator descenditum?
the fuck do I know about latin.
-
@TheCPUWizard said:
1) Once an appliction is on the system it does not matter where it came from. What matters is if the code in the application tries to access code in the runtime libraries that no longer exists or is blocked. So there is nothing special about "store" apps once loaded.
You normally can't get code onto Windows RT in any other way than through store (even if you copy an executable onto it, you can't run it).
@TheCPUWizard said:2) Other editions support "side loading" (loading applications without the store) for use in business [so called enterprise] senarios. So the capability has been there, but was not intended for immediate exposure [IMHO to have a better handle on apps and quality, which is a good thing]. So the exposure of this capability (the so called jailbreak) is not really suprising or important.
Sideloading capability only lets you install Windows Store apps (that is, the full-screen applications limited to WinRT subset of Win32 API). Jailbreak allows you to run applications with full access to Win32 API (which is nearly complete - missing stuff so far seems to be OpenGL, D3dx, DirectInput, DirectMusic, DirectPlay, DirectShow, TWAIN and WinHelp viewer). There's no import libraries in the SDK for the regular Win32 API, but those can be generated from the live system.
