In the .NET API for Windows Store Apps the SecureString class is missing. Also PasswordBox does not store the password in a secure string. What's the equivalent to store strings securely in a Windows Store App? Or do Windows 8 have some secure mechanism to prevent others from reading the application's memory (or memory dump after deliberately crashed)
There is none. The omissions in the .NET api for Store apps were made either because a class just could not work in a WinRT app because it relied on unavailable OS support, because the opportunity was there to cut some dead wood in the framework or because the class just plain doesn't make sense in a Store application.
The omission of SecureString heavily favors the "doesn't make sense" explanation. No attacker would ever go through the trouble of trying to dig the string out of multiple gigabytes of swap file data. It is much easier to just download your app from the store and use a debugger in the comfort of his own home.
Related
The UWP infrastructure seems to have everything what's needed for a portable model.
Clear separation between os and application
Clear separation between different applications
Less dependencies
Support portable class libraries
As far I know portable scenario's are not supported right now. Is it something that we can expect in the future or is it intrinsic impossible due the architecture of UWP/WinRT
How hard would it be to create some kind of host executable that can run any local UWP app. At the moment I'm looking for portability between different Windows 10 PC's. Not so much cross device or cross OS.
I'm aware you can side load UWP apps, but that's not what I'm looking for.
Is it something that we can expect in the future or is it intrinsic impossible due the architecture of UWP/WinRT
I don't see any major technical limitations that would prevent this scenario. UWP apps can register to some global mechanisms (which is something portable apps shouldn't do), like push notifications or background tasks, but the whole application model has been designed so that users can limit access to those features on a per-application basis. So every developer publishing an app is supposed to have considered beforehand that those code-paths may fail.
But "technically possible" doesn't mean that Microsoft will do it. In fact, I seriously doubt they ever will. The reason is simple: they're pushing the store with all their might, even seeking to put Win32 apps on it. Clearly, they're moving towards putting more apps on the store, not the other way around.
As to know whether it'd be possible to make a third-party standalone runner, I think so. When running unit tests for an UWP app, Visual Studio is launching a sort of "shell" hosting the app (it has become very apparent recently because after an update of Windows 10, the API that allowed to hide the splashscreen wasn't working anymore). I don't know what API is used to create this shell, but I'd definitely dig that way if I wanted to make a portable UWP host.
Although I haven't done this myself (will update answer if and when), reading this article makes it look like there is an easy way to create an installer that calls that command.
In short, an appx package can be installed locally using the command:
C:\Program Files (x86)\Windows Kits\10\bin\x86\WinAppDeployCmd.exe
Which can probably be wrapped in a UI or CMD installer.
Here's nice example of it (not mine).
Recently I began working in WinRT for Windows Store Apps (and the upcoming Windows 10 Universal Apps) using C#. After working in .NET for awhile previously, I was excited to work with .NET on mobile devices, only to find that WinRT did not feel like home at all.
Constantly I find myself having to search for alternatives to certain classes that I'm familiar with in .NET since often they're not the same or even implemented in WinRT. I figure that the lack of implementation derives from the fact that WinRT at its core is unmanaged, even though the CLR binds to it from managed code.
My question is: What is stopping Microsoft from allowing developers to import and use all of the familiar .NET classes from managed code, even with WinRT running from behind? I know it's not a limitation of the device because my Surface Pro can run desktop .NET apps just fine and the Mono project has succeeded in porting almost the entire .NET API to devices of every kind.
Thanks for your input!
This is a big topic but there are three basic reasons why you don't get the full .NET API from a Windows Store app.
The APIs don't fit on smaller devices like phones. Since the purpose of the Universal Windows Platform is to have apps that can run everywhere, it can't include APIs that are too resource-intensive (disk, memory, CPU, etc.) to run on smaller devices. (Note that even if the managed API appears to be small, it might have a dependency on a large underlying Win32 API).
The APIs aren't compatible with the Store app model. Many APIs that require permissions not granted to Store apps fall into this category, as do APIs that would enable apps to do "unwanted" things to your machine (the degree of "unwantedness" is subjective).
The APIs are deprecated or there are newer alternatives. This was the case with a lot of APIs in Windows 8, where things like file-system access and network sockets were blocked from Store apps because there were newer WinRT equivalents.
Note that Microsoft is always open to re-evaluating whether a specific API should be included or not. For example, Windows 10 brings back many APIs that were banned from Windows 8.1 (such as System.IO and System.Net.Sockets) and has expanded the capabilities granted to apps. You can file feedback via the Windows Feedback app or on UserVoice if you want additional APIs brought back (adding detailed justification never hurts).
Im developing a new WP8 app(using C#). In that i need to do file manipulation. Seems to be both of them have similar functions. so, Which is best and easy for simple file manipulation?
If you're dealing with a lot of files, and you only want to use files in your own private folder, and you don't care about portability to Windows desktop, and performance is a concern, I would consider IsolatedStorageFile since it is significantly faster. But for most use cases the performance difference should not be a concern (if in doubt, write a quick sample app and see if it matters), and I would use StorageFile for future portability to Windows (plus ability to adapt to brokered files like photos etc. in the future).
Two other considerations are portability to non-Windows platforms and whether you need to deal with existing code that can't be made async-aware (both count as votes against StorageFile).
Both APIs are used to manipulate file. StorageFile is available for both Windows Phone and WinRT, but IsolatedStorage type is available just for Windows Phone. I think you can go with IsolatedStorage.
We are in the process of deciding whether our port of a legacy Compact Framework/Windows CE app (potentially cross-platform, thus using Xamarin in Visual Studio) should be done first for Android or Windows Phone 8 (iOS is on the "back burner").
I imagine the port of the existing (C#) code would be easier if we targeted WP8 (as opposed to Android), nevertheless welcome rebuttals/refutations. Am I right?
Even better would be some sample code of how such manipulation (sending PCL* from the PCL**) is accomplished. Does anybody have any they'd like to share (has anybody done this yet)?
If it is relevant, the device we would probably be writing to is a Zebra QL220, and we would be sending a barcode and related info.
* Printer Control Language
** Portable Class Library
Android Bluetooth socket with Xamarin exposes System.IO.Stream for both input and output. As long as you target the stream with the communication protocol you should be able to swap out Android BT socket with a virtual serial port on a computer or any other option that also provides a Stream to write to and read from. You could abstract it even further but I feel Stream is probably the most convenient target.
Is there any way to override Win32 File API such as CreateFile()? I want my app to see a virtual file solely for my app, however, the virtual file does not exist actually.
There exist two approaches - with a kernel-mode driver (documented one) and without such driver (a hacky way).
With a kernel-mode driver you have two ways - (1) create a virtual filesystem driver (or take existing one) and (2) create a filesystem filter driver (or take existing one). Driver development = a year or so of work to do right and completely. Driver development is fully documented in MSDN.
Without a kernel-mode driver you need to employ API hooking. Libraries such as Detours, MadCodeHook and Boxedapp SDK do this (and let you do this as well).
Hooking an API topic is quite large to describe it here fully, but there's a good CodeProject article on this topic.
System-wide? Bad idea. If it's just your app, don't use the standard APIs and implement it yourself. But if the data must persist between sessions, you'll have to store the data somewhere (file, registry, etc.).