Fwd: [crx] npapi replacement which can make native win32 and MFC api calls

364 views
Skip to first unread message

Rajesh Katalkar

unread,
Nov 18, 2013, 5:16:01 AM11/18/13
to native-cli...@googlegroups.com, Rajesh Katalkar
to https://groups.google.com/group/native-client-discuss

---------- Forwarded message ----------
From: PhistucK <phis...@gmail.com>
Date: Mon, Nov 18, 2013 at 12:48 PM
Subject: Re: [crx] npapi replacement which can make native win32 and MFC api calls
To: Rajesh Katalkar <rajesh...@gmail.com>
Cc: Chromium-extensions <chromium-...@chromium.org>, Joe Marini <joem...@google.com>


Just join the group and forward the e-mail to native-cli...@googlegroups.com, I am not familiar with any built in functionality that moves a thread across groups.


☆PhistucK


On Mon, Nov 18, 2013 at 7:33 AM, Rajesh Katalkar <rajesh...@gmail.com> wrote:
can anyone move this to https://groups.google.com/group/native-client-discuss

On Sunday, 17 November 2013 13:38:09 UTC+5:30, Rajesh Katalkar wrote:
Depending on what you said ,It means that google allow their friendly business partners Adobe  to use native calls with PPAPI and forbids
rest of world from using it and and even then tell others to use Pepperapi as it rhymes to npapi but expects them to use nacl in the end because pepper is not for us.Then you should clearly declare to the world that pepper is only for Adobe then.

Can you move this whole thread to https://groups.google.com/group/native-client-discuss  you said about.Or tell how to do it.Its too big to repeat or copy again.

On Sunday, 17 November 2013 04:21:24 UTC+5:30, Antony Sargent wrote:
Yes, my understanding is that we use PPAPI to interface with Flash, the PDF reader plugin, and NaCl, but aren't letting third-party plugins use it directly. But it's possible I'm not correct. You best bet is probably to check out the resources at:


There is a link there to the discussion list at https://groups.google.com/group/native-client-discuss - that would be the best place to get all your PPAPI / NaCl questions definitively answered. 




On Sat, Nov 16, 2013 at 9:25 AM, Rajesh Katalkar <rajesh...@gmail.com> wrote:
You are saying its to port .But then flash is pepper plugin or nacl plugin?
I have seen the hello world example where it show 1-6 steps to porting...But that's where its gets confusing...
It says with pepper we can use new pepper interface and make windows systems call which nacl cannot do as mentioned below.
It never mentioned any where that the .dll is not going to work in chrome.and cannot be deployed as it is.

If nacl is what the final thing should be then pepper should not even exist .
this porting thing is actually as good as rewriting whole plugin from scratch if native calls are not supported.Its actually double work...
first you spend time to make pepper and then spend time to remove native call and compile with nacl sdk.
If devs can develop napapi from scratch they can also develop nacl or pepper or whatever you want to say from scratch instead of spending double time.

Plus if you see my second comment of this thread....it says sometime in future pepper will supported in native client(nacl)..what does this mean.Do double work now and again in future do the same double work again.
///////////

Also i have read that in future pepperapi can be called only from a nacl module...
http://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics

Although traditional NPAPI plugins in Chrome run only out of process, Chrome 5 supports Pepper plugins only in process. Being a somewhat experimental feature, the only way to load trusted Pepper plugins is through the browser command-line options. In the future, Pepper plugins will only be supported within Native Client.

does it mean it cannot be called from html directly?
///////////////////////////

The PPAPI platform

The PPAPI platform builds your module as a dynamic library and launches a version of Chrome that’s configured to run the library as a plugin when it encounters an <embed> element with type=application/x-nacl (ignoring the information in the manifest file). When running in the PPAPI platform, you can use Windows system calls that are unavailable in a regular Native Client module built and running as a .nexe file. This offers the ability to port existing code incrementally, rewriting functions using the PPAPI interfaces one piece at a time. Since the module is built with Visual Studio’s native compiler (MSBuild) you can use the Visual Studio debugger to control and inspect your code

/////////////////////
I know you or others will say use this use that ..But i want to know why ..with what exactly is npapi is replaced with and how it works ,what it supports and does not.its future and it deployment requirement.

I have to understand properly the new interface and develop my plugin again because its not actually just porting if no native call supoort, its a lot of work.But that's to be cleared first.


On Saturday, 16 November 2013 02:41:57 UTC+5:30, PhistucK wrote:
Actually, I am not sure any correction is needed.
This is a section within the Native Client documentation, it is not the PPAPI documentation per se (or maybe it is, but PPAPI is not explained very well anywhere) and Rajesh assumed it is, probably because there is no real (up to date) PPAPI documentation anywhere. It also says it "launches a version of Chrome that’s configured to run the library as a plugin" in order "to port existing code incrementally, rewriting functions using the PPAPI interfaces one piece at a time".


☆PhistucK


On Fri, Nov 15, 2013 at 11:01 PM, Joe Marini <joem...@google.com> wrote:
Please file a bug on the docs at crbug.com



On Fri, Nov 15, 2013 at 12:47 PM, PhistucK <phis...@gmail.com> wrote:
Can you talk to the relevant people so they would update the documentation Rajesh mentioned? it does seem to imply that this kind (system call making) of PPAPI plugins is legitimate...


☆PhistucK


On Fri, Nov 15, 2013 at 10:44 PM, Antony Sargent <asar...@chromium.org> wrote:
My understanding is that you cannot install your own plugins that talk directly to the PPAPI interface and also run with unrestricted access to the rest of the OS (like NPAPI plugins); rather you must have your code running inside the NaCl/PNaCl sandbox, and cannot make direct Win32/MFC calls. 

If you need to have binary code directly using Win32/MFC, your best bet is to split things up into two pieces - a native binary that does the Win32/MFC stuff, and your extension that uses native messaging to exchange messages with your native binary. The extension should be hosted in the webstore or installed with enterprise policy.



On Fri, Nov 15, 2013 at 11:39 AM, PhistucK <phis...@gmail.com> wrote:
Sorry, it looks like you are right (I hope the documentation is up to date, though).
Antony, can you, please, advise here?


☆PhistucK


On Fri, Nov 15, 2013 at 8:54 PM, Rajesh Katalkar <rajesh...@gmail.com> wrote:
use the addin from pepper sdk

https://developers.google.com/native-client/devguide/devcycle/vs-addin

https://developers.google.com/native-client/pepper23/devguide/devcycle/vs-addin#ppai
https://developers.google.com/native-client/devguide/devcycle/vs-addin#ppai

The PPAPI platform

The PPAPI platform builds your module as a dynamic library and launches a version of Chrome that’s configured to run the library as a plugin when it encounters an <embed> element with type=application/x-nacl (ignoring the information in the manifest file). When running in the PPAPI platform, you can use Windows system calls that are unavailable in a regular Native Client module built and running as a .nexe file. This offers the ability to port existing code incrementally, rewriting functions using the PPAPI interfaces one piece at a time. Since the module is built with Visual Studio’s native compiler (MSBuild) you can use the Visual Studio debugger to control and inspect your code.

Then see my second comment of this thread...I don't want to copy it again.



On Friday, 15 November 2013 18:57:14 UTC+5:30, PhistucK wrote:
I have not found a document that states that PPAPI can be compiled using Visual Studio compilers.


☆PhistucK


On Fri, Nov 15, 2013 at 3:18 PM, Rajesh Katalkar <rajesh...@gmail.com> wrote:
Its not just the IDE ...after using addin there are preconfigured profiles .NACL,PPAPI ....
NACL uses nacl compiler...this is understood.
PPAPI uses vs2010 compiler..This plugin works also.

The question if PPAPI can use vs2010 compiler and can link to win32 and why calling native api's not valid.

If native is restricted then there should be only NACL which uses nacl compiler...

why so many options and behavior like nacl only

On Friday, 15 November 2013 15:09:12 UTC+5:30, PhistucK wrote:
Some people like Visual Studio better for its debugging, IntelliSense and other features.


☆PhistucK


On Fri, Nov 15, 2013 at 10:14 AM, Rajesh Katalkar <rajesh...@gmail.com> wrote:
new pepper sdk supports vs2010 and provides addin for it.so get integrated with it.
https://developers.google.com/native-client/pepper23/devguide/devcycle/vs-addin

Jeffrey if pepperapi cannot access win32 api i.e native api's whats the use of pepperapi compiling with vs2010 compiler.why even have pepperapi then



On Fri, Nov 15, 2013 at 12:41 AM, PhistucK <phis...@gmail.com> wrote:
1. I am not sure you can create PPAPI using Visual Studio. See http://stackoverflow.com/questions/19425728/how-to-create-a-ppapi-plugin-for-google-chrome-in-windows, for example.
2. You could load your extension an an unpacked extension, but the browser will (in the near future) show a prominent warning to users (who are basically extension developers) that run unpacked extensions.


☆PhistucK


On Thu, Nov 14, 2013 at 7:38 PM, Rajesh Katalkar <rajesh...@gmail.com> wrote:

Pepper api builds with vc++ compiler .then it should be possible to call win32 and mfc if i am not wrong.Also i have read that in future pepperapi can be called only from a nacl module...
http://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics

Although traditional NPAPI plugins in Chrome run only out of process, Chrome 5 supports Pepper plugins only in process. Being a somewhat experimental feature, the only way to load trusted Pepper plugins is through the browser command-line options. In the future, Pepper plugins will only be supported within Native Client.

does it mean it cannot be called from html directly.
Also it necessary that it loads in metro mode also .I have heard some devs reporting that it fails to load in metro mode.Is this true.

I know native messaging technique works in metro mode as i have tested its sample app.

Also loading crx manually will be present or not ? and does pepper needs nacl to be enabled from chrome flags to load if extension loaded out of CWS

On Wednesday, 13 November 2013 20:01:14 UTC+5:30, PhistucK wrote:
1. As far as I know, the Pepper API cannot make native system calls. Native messaging is the only way to make Win32 calls or use MFC (I presume it also makes system calls).
2. This is indeed true, you will have to upload it to the web store, or install via Enterprise policy (if any). Antony enumerates all of the options here - https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/PZaNR7obIdQ/fOCQRQbAG60J


☆PhistucK


On Wed, Nov 13, 2013 at 3:12 PM, Rajesh Katalkar <rajesh...@gmail.com> wrote:
I have a extension which uses npapi and i am planning in replacing npapi as its going to phased out.Possible alternatives found are
1)Pepperapi
2)native messaging api

Can someone help me decide which one is good and future proof and allow me to call windows native calls in both desktop browser and metro brower in win8 ,8.1

..Also i have used the pepper sdk and vs2010 sdk ..and the hello_nacl example gaol is to show how to convert from native to nacl...
but nacl uses native client sdk which is gcc ..which will not compile my win32 call if i am not wrong.........

this replacement interface is going to do IPC with desktop app using shared memory api and syncronization api's.


Another question is about deployment .There is news google will only allow extension only from webstore ..we currently use registry based technique for this.
http://www.zdnet.com/google-to-tighten-up-chrome-extension-security-on-windows-7000022950/
Is this true...Is there another alternative than CWS if this is true?




--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.



--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.



--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.



--
Joe Marini
Developer Advocate / Chrome



--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/f0d90fe8-5b12-4c6c-8280-f435e596a1bd%40chromium.org.


Victor Khimenko

unread,
Nov 18, 2013, 1:38:09 PM11/18/13
to Native Client Discuss, Rajesh Katalkar

I don't know how to move the discussion, but I can confirm that understanding you've reached is correct: PPAPI is used both for Chrome-internal plugins (which can do Win32 and other platform-dependent calls) and for externally-developed plugins (but these must be compiled as NaCl module if you want to make them available in web store), but only Chrome-inernal plugins can do native Win32 calls.

PPAPI and NaCl are kinda-independent technologies and all three combinations really exist:
1. PPAPI plugin with access to the underlaying native OS functions - Flash and PDF
2. PPAPI plugin written using NaCl - most developer are using that if they use PPAPI
3. NaCl plugins without PPAPI - not in Chrome, but there are ZeroVM, for example ( http://zerovm.org ).

PPAPI calls which are used by internal plugins are the same as PPAPI calls used by NaCl application - but as was already said Flash and PDF plugins are native plugins and thus can use native Win32 calls, too.

Note that it's not "friendly business partners Adobe", it's only internal plugins. Both PPAPI Flash and PPAPI PDF are developed in Google (although both are using technology licensed from other companies). They are passing the same process the other parts of Chrome are passing WRT security (fuzzing, etc). Also note that newer internal Chrome/ChromiumOS plugins (such as QuickOffice plugin) are not native PPAPI plugins, but normal PPAPI-on-NaCl plugins.

Also, as you've noticed, you can use native PPAPI plugins as an intermediate step when you are porting your program to NaCl. This is done by [ab]using the same infrastructure which is used to develop PPAPI Flash, NaCl (not NaCl programs but actual plugin which loads and executes NaCl programs) and PDF plugins, but these plugins can not be downloaded from CWS *and* they are not supposed to be used in different versions of Chrome thus they should be treated as an intermediate step in your development, not as something you can give to end users.

People have found out that it's often easier to do port in two steps: first to native PPAPI plugin and then to NaCl, but if you think it's easier for you to rip out all the calls to Win32 from your program in one go then it's legitimate approach, too: nobody *forces* you to use native PPAPI plugin as an intermediate step in a porting effort! If you think it's easier to skip this step then, of course, you can do that!

On Mon, Nov 18, 2013 at 2:16 PM, Rajesh Katalkar <rajesh...@gmail.com> wrote:

Hi ,
     can you please move my discussion at

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/groups/opt_out.

Reply all
Reply to author
Forward
0 new messages