I need to wrap a C library with Adobe AIR native extension API (ANE).The extension should target IOS and Android.First,I realize that for Android , if not using NDK API , I have to port that library to Java.But my main concern is IO operations like read and write to file system which exist in that library.I read through the ANE development manual but found no note on restriction of native lib communication with the host file system.Does it mean my native library is allowed to read and write files inside AIR extension freely ?
You definitely can access the filesystem to read and write files.
The only thing of note here is that you'll only have access to the parts of the filesystem that the application has permission to access. So you basically just have to obey any restrictions that a normal native application developer has.
I've used the java.io.File to access files in ANE's no problem.
Based on what I see scanning through that too it reads to me like it's doable but I can't confirm 100%
When you create a native extension, you provide the following:
ActionScript extension classes that you define. These ActionScript classes use the built-in ActionScript APIs that allow access to and data exchange with native code.
A native code implementation. The native code uses native code APIs that allow access to and data exchange with your ActionScript extension classes.
sounds to me like you have whatever native API available for writing your native extension in and they're just providing a "bridge" or "data tunnel" to communicate between the actionscript code and the native extension. They have one import from the android library for log in their example as well so I imagine you can use whatever objects/methods are available for each platform, I suppose the only real question is then what access the native process has on the file system for each platform. If you don't get an answer please try and post back (if I have time I'll do the same).
Related
I'm working on a UWP app (C++/WinRT) that must communicate extensively with a background process. Unfortunately, the background process must remain a full trust "Win32" process. Both are packaged in an MSIX.
For performance and programmability reasons, my first choice would be to turn the background process into an out-of-process WinRT component. App Services is a possibility but not ideal.
I've found numerous code samples for creating an OOP WinRT component via WRL. However, activation is performed via CoreApplication::RunWithActivationFactories(), which (as far as I know) requires an AppContainer.
I know I can consume a WinRT component in a Win32 process. Can I create one? If so, what would activation look like in C++/WinRT?
Yes, from the Windows 10 Version 1903, May 2019 Update, the windows have added support for non-packaged desktop apps to make use of user-defined (3rd party) Windows Runtime (WinRT) Components, which means that we can consume a Winrt component from the Win32 process directly. To successfully reference a C++ Windows Runtime component from a Win32 app, you need to use C++/WinRT to generate projection header files of your component. You can then include these header files in your app code to call your component.
For the detailed information, please refer to this article:
https://blogs.windows.com/windowsdeveloper/2019/04/30/enhancing-non-packaged-desktop-apps-using-windows-runtime-components/.
For the detailed sample, please refer to here:
https://github.com/microsoft/RegFree_WinRT/tree/master/Cpp.
Thanks.
I would like to build a Chrome multimedia extension.
I would like this extension to communicate with another process (using a "memory-mapped file" (https://msdn.microsoft.com/en-us/library/ms810613.aspx). Is it possible?
From the NaCl FAQ:
If I want direct access to the OS, should I use Native Client?
No—Native Client does not provide direct access to the OS or devices,
or otherwise bypass the JavaScript security model. For more
information, see later sections of this FAQ.
If it is not possible to use memory-mapped files in NaCl's sandbox, is there any other way to build such plugin?
My extension would be used only by me, so I can accept security flaws.
Short answer: No. The sandbox is designed to prevent that kind of thing. The only way to use APIs other than the Pepper APIs (or of course those available in JavaScript) would be to install a native app in the OS, and communicate with it from a web app or extension using Native Messaging:
https://developer.chrome.com/extensions/nativeMessaging (that might be a good solution for you since it sounds like communicating with another process is what you want to do anyway).
First of all, I haven't started the implementation of the system I'm about to describe, as I didn't want to commit on implementing something I did not know if was possible.
So, what I'm trying to achieve is to build a chrome-app to download the audio from certain websites (e.g. youtube and soundcloud) using youtube-dl, post process it using ffmpeg and then upload it to a cloud service via some api. The reason I want to do it via a chrome-app is because I could do all the work on the client side (no need for servers) and I'd have the ability to insert javascript into the pages using content scripts, which would make the app pretty simple to use (I could create buttons such as 'download song' and stuff like that).
Although I have already read the documentation explaining the NaCl Technical Overview and some of the Application Structure, I still am not sure as to whether I would be able to make these calls via some C/C++ module or if I would get denied due to security reasons.
To summarize: considering that the user has the needed dependencies in his system (youtube-dl, python, ffmpeg and etc.), is it possible to make calls to third party APIs such as the ones described before via a chrome-app using NaCl ?
Thank you all in advance,
Chrome apps are normally sandboxed.
Less so than extensions - they can reach much more system resources via app APIs.
But still, what you mention is executing libraries / utilities out of browser, and it's not normally allowed.
(P)NaCl is tightly sandboxed in this regard. See this old question, it still applies: you can only use 3rd-party code that compiles into NaCl along with your app, not just link to a library. There are some library ports to NaCl, but it's not automatic.
Normally, a few years back you would use a mechanism like NPAPI to reach out and use a library out of browser. It's deprecated, and won't work anymore. In its place, Chrome offers a pipe-like (through stdio) connection to an external program called Native Messaging. You could use it to perform operations with system-level libraries and tools, but the downside is that you can't bundle the native host with your app, you'll need a separate installer.
I'm new to Chrome Application development and the Native Client/PNaCL pipeline. I'm a bit confused over the process of using existing C code/libraries in a chrome application. The FAQs and NaCL official docs suggest that using existing code is easy, and one of the advantages of developing Chrome applications.
However, there is also mention of nacl-ports, an official list of ported C libraries to be used in Native Client apps.
If I have some random C library I've used, what is the process for actually using it in my Chrome application? This question feels silly, but I'm quite confused over the process. Do I have to recompile the source with a NaCL compiler? Where in the SDK can I find this?
The FAQ also mentions that things like forks, file i/o is not allowed in the library, so I will have to rewrite any code that does these things, is that correct?
Bottomline: I have an existing C library. What is the process for using it correctly, and making calls to it, in a Chrome application?
The short answer is that you'll have to recompile your library with a NaCl C compiler.
You may want to take a look at naclports: this repository contains ports of many common C libraries to Native Client. You can browse the source more easily here.
As for File I/O, we often suggest using the nacl_io library when porting existing code. This provides a POSIX interface (e.g. fopen/fclose/fread, etc.) Many ported libraries require no modifications when using nacl_io.
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.).