I know that file system access in WinRT is different (read: isolated), but I'm curious if we still have to worry about MAX_PATH, or has that restriction been avoided?
No, the MAX_PATH restrictions haven't been lifted - if you pass a path longer than MAX_PATH to a windows runtime API which accepts a path, it is still possible it will fail. But MAX_PATH is far less likely to be relevant, since windows runtime APIs typically operate on strings, and not on buffers of characters.
In addition, since metro style apps are typically restricted in the directories that they access, deep paths are less likely to be encountered.
Related
Trying to fix up an old Firefox addon which makes extensive use of the Google Maps API. However, AMO CSP disallows ALL remote scripts and evals. AMO CSP compliance required for addon to be signed, only signed addons allowed to be installed and run.
From AMO's validation feedback:
Security Tests 0 errors, 6 warnings, 0 notices
Scripts must not be remote
Warning: <script> tags must not be referenced to script files that are hosted remotely.
chrome/content/file.html
4 <script src="http://maps.google.com/maps?file=api&v=3&key=<...>" type="text/javascript"></script>
Is there any way to download, and modify the API into files for use in this environment? The project has had an API key for many years and used code remotely. I am just stepping in to help revive the obsolete addon. Beyond the technical, are there licensing issues with the code usage in this context? Currently licensed under MPL-1.0 but it could trivially be changed to MPL-2.0, which I am advocating as the path of least resistance.
To answer my own question, after further research, the best option is simply not to use Google Maps API, due to all the reasons mentioned above.
Not open source compatible [related question]
Not available for embedded applications
Not Mozilla Firefox Addons CSP compatible
EXTREMELY slow to fix SERIOUS security problems (eval-soup)
Inadequate update frequency or support
Prohibitively restrictive barriers to access
Inflexibile, unsuitable, undesireable.
What ever happened to the mantra, "Do no harm?" Has it become, "Do no good?" Anyways...
One of the many other free software libraries will achieve what I want.
I could bypass the whole issue entirely, and just present a text list of regions with check boxes for areas of interest, build a combined - possibly non-contiguous - polygon(s), and use any Geo capable polygon lib to check if arbitrary points fall inside or outside the boundaries of a polygon.
It seems that media pipeline in Windows Phone 8.1 is broken because of a lot of memory management issues.
When you create a background audio app that uses IMediaSource to stream audio in Windows Phone Runtime 8.1, the app's components eventually throw OutOfMemoryException and even StackOverflowException under some circumstances. When looking through the memory dumps, there's a lot of uncollected garbage inside.
The discussion has started on MSDN forums and progressed to this conclusion. I have created a WPDev UserVoice suggestion in order Windows Phone team could notice this, but I still hope it's me (and other guys from MSDN forums) who's wrong and there's a solution for the issue.
I also have a small CodePlex project that also suffers from this, and there's actually an issue report there regarding this exact problem.
I hope that with the help of the community this issue can be worked around or passed directly to Microsoft development team to investigate and eliminate. Thanks!
Update 1:
There's a kind of workaround for StackOverflowException, but it doesn't help against OutOfMemoryException.
Okay, so it seems that the problem is actually with byte array's lifetime in .NET.
In order to resolve the memory problem, one shoud use Windows Runtime's Windows.Storage.Streams.IBuffer. Don't create many new .NET byte arrays in any form, neither by simple new byte[], nor by using System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeBuffer class as it is a managed implementation of IBuffer interface.
Those byte arrays, being once allocated, live long because of being pinned by OverlappedData structures and overflow the memory threshold for background audio task. IBuffers (the real Windows Runtime ones, like Windows.Storage.Streams.Buffer class) contain native arrays that are being deallocated as soon as IBuffer's reference count reaches 0 (zero), they don't rely on GC.
What I've found out is that this problem is not only background audio specific. Actually, I have seen a lot of other questions about similar problems. The solution is to use Windows Runtime backend where possible because it's unmanaged and frees resources as soon as they have zero references.
Thanks to #Soonts for pointing me in the right direction!
They had memory issues with the way MSS manages its memory, but they have silently fixed it during some update: WP7 Background Audio - Memory Leak or Not?
I’m not sure, but I think the problem is your code. You just shouldn’t call var buffer = new byte[4096]; each time a sample is requested. Doing so may work on the PC, but for the embedded platform, I don’t think it’s a good idea to stress the memory manager that much.
In my MediaStreamSource implementation, I use a single circular buffer that is allocated when the MSS is constructed, and the portions of the buffer are infinitely reused during the playback. In my GetSampleAsync, I construct an instance of my Stream-implementing class, that doesn’t own any memory, but instead only holds a reference to a portion of that circular buffer. This way, only a few small objects are allocated/deallocated during the playback, thus the audio stream data does not load the memory manager.
Is it possible to detect that I am running under Virtual Machine from the code of Action Script3 (or lower)?
I know there is Capabilities class that providers some info about the system, but it doesn't seem to fit my needs fully.
Perhaps there is no such a flag anywhere, but I can count on some indirect information to understand that environment is virtualized?
Regards,
Sergey.
I doubt that checking this would be easy, especially from such an isolated enviroment as browser plugin sandbox. Modern virtual machines can emulate everything very accurately down to CPU registers and it is often hard to detect a vm even when you can access regular OS APIs. And when running in a browser you don't even have that (with AIR, you could write a native extension). You can check this thread for some info that may prove useful.
I have to build (obviously using flex) an AIR application that must be linked to a given hardware (i.e. hard-disk), so it can't be copied elsewhere..
Usually using others languages, every time you open the application, a comparison between HardDisk or CPU ID and the value stored in the application itself...
Using Flex this is not possible (as far as I know)...
User/Password check obviously won't work..
I can't use a webservice, the application needs to work offline too..
How could I do?
With AIR you can integrate native apps - either indirectly (start a process and get its result) or directly (as a library).
Any of these techniques allow you to achieve your goal the same way you would in the case you described as "other languages"... BUT BEWARE: this makes your app platform-dependent AND can potentially lead to problems since it is prone to permissions issues etc.
Another point: no such technique is 100% secure (can be circumvented AND can lead to unsatisfied legitimate users!) - so you should really consider whether this is the way to go...
I was reading up on Midori and kinda started wondering if this is possible.
On a managed OS, "managed code" is going to be native, and "native code" is going to be...alien? Is it possible, at least theoretically, to run the native code of today on a managed OS?
First, you should start by defining "managed" and "native". On a "managed" OS like Midori, the kernel is still ngen-ed (precompiled to machine code), instead of being jit-compiled from IL. So, I would rule that out as a distinction between "managed" and "native".
There are two other distinctions between "managed" and "native" code that come to my mind - code vrifiability and resource management.
Most "native" code is unverifiable, thus a "managed" OS loader might refuse to even load "native" images. Of course, it is possible to produce verifiable "native" code, but that puts a lot of limitations and in essence is no different from "managed" code.
Resources in a "managed" OS would be managed by the OS, not the app. A "native" code usually allocates and cleans up its resource. What would happen with a resource that was allocated by an OS API and given to the "native" code? Or vice versa? There should be quite clear rules on who and when will do the resource management and cleanup. For security reasons, I can't imagine the OS giving any direct control to the "native" code to any resources besides the process virtual memory. Therefore, the only reason to go "native" would be to implement your own memory management.
Today's "natve" code won't play by any of the rules above. Thus, a "managed" OS should refuse to execute it directly. Though, the "managed" OS might provide a virtualization layer like Hyper-V and host the "native" code in a virtual machine.
By managed I assume you mean the code runs in an environment which does some checks on the code for type safety, safe memory access etc. And native, well, the opposite. Now its this execution environment that determines whether it can allow native code to run without being verified. Look at it this way: The OS and the application on top both need an execution env to run in. Their only relationship is that the top application is calling the underlying OS for lower level tasks but in calling the OS, its actually being executed by the execution env(which may/may not support code verification depending on say, options passed in compiling the code for example) and when control is transferred to the OS, the execution env again is responsible for executing the OS code(this environment might be another envionment all together), in which case, it verifies the OS code(because its a managed OS).
So, theoretically, native code may/may not run on a managed OS. It all depends on the behaviour of the execution environment in which its running. Whether the OS is managed or not will not affect whether it will run on it or not.If the top application and the OS both have the same execution env(managed), then the native code will not run on the OS.
Technically, a native code emulator can be written in managed code, but it's not running on bare hardware.
I doubt any managed OS that relies on software verification to isolate access to shared resources (such as Singularity) allows running unmanaged code directly since it might be able to bypass all the protections provided by the software (unlike normal OSes, some managed OSes don't rely on protection techniques provided by hardware).
From the MS Research paper Singularity: Rethinking the Software Stack (p9):
A protection domain could, in principle, host a single process
containing unverifiable code written in an unsafe language such as
C++. Although very useful for running legacy code, we have not
yet explored this possibility. Currently, all code within a
protection domain is also contained within a SIP, which continues
to provide an isolation and failure containment boundary.
So it seems like, though unexplored at the moment, it is a distinct possibility. Unmanaged code could run in a hardware protected domain, it would take a performance hit from having to deal with virtual memory, the TLB, etc. but the system as a whole could maintain its invariants safely while running unmanaged code.