I have a DLL that is an npapi plugin that is from another application, this application only opens if it is executed by the plugin that is executed by the browser, however as this type of plugin is no longer supported, I have been researching alternatives to create an application c++ that can call this DLL and do the same function that browsers did, I read a little about the mozilla gecko but from what I see the documentation for this is almost non-existent, is there another alternative to make this call? or just embedding browser functions in c++ application, is it possible?
You can host it yourself, but implementing the host side of NPAPI can be non-trivial -- it would take some work, it really depends on what the plugin wants exactly. Most documentation around NPAPI seems to be down these days as well, so finding the details may take some work.
Related
I am writing an application using Qt and want to try and deploy it as a web-application. I want user's to be able to use my application by accessing it through a web browser. I'm guessing that's what a web-application is? What kind of options do I have? I've never looked into doing anything like this but I'd like to learn something new.
EDIT: What if I deployed my application on a Linux server and had users access/run it through a terminal? I think writing web application is going to be more complicated than I had originally thought.
If all you have is a Qt application, then the best you can do is use Qt 5 and run it using a remote visualization package:
Use WebGL streaming, introduced in Qt 5.10. Qt exposes a browser-connectible interface directly, without need for third-party code.
For Qt 5.0-5.9, you can use the vnc platform plugin. Then connect using a web-browser based vnc client.
For many uses it might be sufficient, and certainly it's much less effort than coding up a web app.
You're looking for Wt which provides a different set of drawing routines for many Qt GUI elements, turning them from lines on screen to HTML controls.
http://www.webtoolkit.eu/wt
It also handles websocket calls to provide interactivity. It seems a great idea, let us know how it works in practice.
For the case of QML there is QmlWeb which is a JavaScript library that is able to parse QML-code and create a website out of it using normal HTML/DOM elements and absolute positions within CSS, translating the QML properties into CSS properties.
QmlWeb is a small project by Lauri Paimen that he’s already developing for a few years now. QmlWeb of course doesn’t yet support everything Qt’s implementation of QML does, but it already supports a quite usable subset of it. It supports nearly all of the most basic QML syntax. Moreover it has support for HTML input elements (Button, TextInput, TextArea are currently supported, more to come).
Well, QmlWeb is not finished. I hope Digia help with this project to make it ready with mature features.
Interestingly, it is possible to compile Qt applications to javascript using emscripten-qt. These run fairly fast with Firefox's asm.js interpreter:
http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki
Try "Qt for Webassembly".
Webassembly allows the C/C++ code to be compiled and run natively inside majority of the browsers:
WebAssembly (Wasm, WA) is a web standard that defines a binary format and a corresponding assembly-like text format for executable code in Web pages. ... It is executed in a sandbox in the web browser after a verification step. Programs can be compiled from high-level languages into Wasm modules and loaded as libraries from within JavaScript applets ... Its initial aim is to support compilation from C and C++, though support for other source languages such as Rust and .NET languages is also emerging.
To run a Qt application unchanged over the web so users can operate it in a browser, you can compile it for Android using the x86 Android ABI, run it inside an Android emulator on a server and supply the Android Cast videostream to users' browsers. You'll also need to have JavaScript in place that records the keyboard and mouse events on the web clients and relays them back to the server.
I had previously tried Qt WebGL streaming and found it to be good over the local network but too slow over the Internet. A 10 s application startup time is acceptable, but 3 s to show a new screen is rather not. I had the exact same experience with the Qt VNC platform plugin. Compared with that, the Android Cast streaming based appetize.io solution (see below) was much faster, providing a well usable user experience even over my 8 Mbit/s connection.
Existing solutions
Here is an overview of commercial products and open source software components that I found that can help you with this approach:
appetize.io. This is a commercial product to run Android applications over the web for demo and testing purposes. I have just done this with a Qt QML based application and liked the outcome. When choosing an Android 9 / 10 device you can see that the "Screencast" setting is on; which is why I believe that this solution uses the Android Cast technology.
runthatapp.com. This is another commercial offer. Not as sophisticated (yet) as appetize.io, but providing a nice pay-as-you-go scheme.
ScreenStream. An open source Android app that provides a web server to view the screen of one Android device in a web browser, also relying on the Android Cast technology. That Android device could be an emulator running on a web server. And to make this multi-user capable you can employ a small load balancer similar to a technique that I developed for Qt WebGL streaming. The ScreenStream README shows that the application might consume up to 20 Mbit/s per client in short bursts.
Ideas for future improvements
Serving your Qt app as an interactive live video stream seems a promising idea to me, given that I found it already less sluggish than VNC and similar solutions. There are ways to make this even faster, such as using a hardware H.265 video encoder to create a video stream with very little delay. By operating multiple such encoders on a single server, the server could serve multiple clients and still keep its CPU load low. Maybe there are even better video formats for such a purpose, given that user interfaces of programs lend themselves well to lossless compression.
Some hints for appetize.io
Finally: since I used the appetize.io product for a Qt application over the last few days, here are some tips from that experience:
It is necessary to compile your Qt application for the x86 Android ABI. The default armeabi-v7a ABI will not work because most appetize.io devices are actually server-based Android emulators and the only ARM based device ("Nexus 5 Physical") failed to start any Qt application I tried to use with it.
The x86_64 ABI may also work, but you might then have to also compile Qt yourself for it, as not all versions of Qt come pre-compiled for that architecture.
All appetize.io links (both for standalone pages and embeddable iframes) support GET parameters to configure the app presentation format. Especially relevant here is screenOnly=true to show the app without a picture of a phone or tablet around it.
Features that rely on phone hardware (camera, position etc.) will not work or only show dummy data. But if you really wanted, you could create a hybrid application combined with client-side JavaScript. It would run device-dependent code in the user's browser, for example to take a photo with the webcam, and then provide the results to the Qt application via the appetize.io cross-document messaging protocol. The following message types seem suitable to build a simple communication protocol: pasteText(value), keypress(key, shiftKey) and openUrl(value).
In the default appetize.io standalone app demo pages, only the key events of ordinary letter keys are sent to the app, not keyboard shortcuts or function keys like F2 and Esc. This might be possible to fix with JavaScript on an own page embedding the appetize.io iframe, as their cross-document messaging protocol provides the keypress(key, shiftKey) message type.
Qt does not support writing browser based web applications. Unfortunately.
You need to use common web programming technologies for this. There are a lot of ways, but Qt is not one of them.
What I am trying to do is create an exe (not .hta) that can be programmed to open a local html file and have it work just like it was in IE (handle styles, scripts and etc), only without actually loading IE. The exe must also be run without installation requirements, and no dependencies (other than recent IE obviously), needed on the host machine.
The purpose is to create an interactive e-book type document, that can be edited without recompile, and also be run from cd/usb on the fly.
I can't just open IE, because it will look unprofessional with the big E, the toolbar and tabs all at the top. know what I mean?
I have experience with HTA, and this was my first suggestion, however I would like to take advantage of the auto run from cd, and also to make the form border a little different, less plain.
I also have experience in VB. Which I could accomplish the look and functionality, however those vbruntimes are not installed on some machines :(
Is it possible to use the IE webBrowser control from c++ or even assembly?
Thanks in advance!
It appears, Lucian Wischik's Webform can be a good starting point to meet your minimalistic project requirements. Alternatively, you could host WebBrowser ActiveX control directly using ATL AxHost. ATL can be linked statically and adds a very low size overhead to the final EXE. Here is a sample project of WebBrowser host app which only depends on ATL.
Yes, you can use the browser component from C++.
C++ however will again need runtime libraries, similar to VB. The good news is, you can statically link those runtime libraries with the executable.
You will not be able to statically link the browser component with your executable, but that wont be an issue unless you try to support ancient Windows versions (pre NT 4.0). For all more recent Windows versions, you can pretty much assume that this component is available.
For more details on that component, you may refer to the CHtmlView class reference - that is the MFC wrapped version of that WebBrowser activeX component.
Using that component from assembler certainly is possible as well, but unless you are deeeeeeep into system programming on the windows platform, you will fail.
I'm currently working on a cross-platform application (Win/OSX/iOS) which has a C++ (with Boost) back end. On iOS and OSX I'm using the Cocoa Net Service Browser Delegate functions to discover an embedded device via mDNS, then pass the information to the back end to create the objects it needs to communicate with it.
I wanted to take a similar approach with my Windows MFC front end and I found this article which seemed to do exactly what I want. However, it seems that using the Bonjour SDK has some really nasty side effects - forcing you to static link to MFC and in my case the only way I can get it to link properly is to not use debug DLLs at all, which is not ideal.
So, the Bonjour SDK isn't really any good for me because it imposes too many restrictions on my project. With Cocoa I'm actually using very little of the functionality - just didFindService and netServiceDidResolveAddress really. All I want to do is find the devices of a given type and get their IP addresses.
Can anyone suggest another way around this that will work with an MFC front end on Windows?
From what I have been able to gather from researching this topic just goto http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-333.10/ and grab the source. There is a VC project file which will let you build the dll how you want.
I would like to write a Chrome plugin that will communicate with my native C++ process,
to invoke it and capture its return output.
What options do I have in the Chrome browser using npapi?
im using firebreath for npapi so mybe something with boost?
NPAPI doesn't restrict you; it's just native C++ code. That means you can use any IPC mechanism that you would used for any two processes. There won't end up being anything NPAPI-specific about what you end up with. (Given that, you might want to ask a new version of this question without mentioning Chrome or NPAPI, since you'll get more answers to a general question about IPC.)
How do you debug lua code embedded in a c++ application?
From what I gather, either I need to buy a special IDE and link in their special lua runtime (ugh). Or I need to build a debug console in to the game engine, using the lua debug API calls.
I am leaning toward writing my own debug console, but it seems like a lot of work. Time that I could better spend polishing the other portions of the game.
There are several tools floating around that can do at least parts of what you want. I have seen references to a VS plugin, there is a SciTE debugger extension in Lua for Windows, and there is the Kepler project's RemDebug, as well as their LuaEclipse.
RemDebug may be on the track of what you need, as it was built to allow for debugging CGI scripts written in Lua. It does require access to the LuaSocket module to provide a communications channel between the target script and a controller as well as a couple of other modules.
A bigger issue might be the ability to load arbitrary modules from within whatever sandbox the game engine has put around your scripts. If you have some control over the engine, then that won't be as big an issue.
This isn't currently possible for developers of Adobe Lightroom plugins, for example, because Lightroom does not expose require inside the plugin's sandbox.
A surprise to me has been how rarely I have felt a need for a debugger when working with Lua. I've built several small applications in it for various projects and have been surprised at how well a combination of complete stack backtraces and the occasional print call works to locate the bugs that require "strict" didn't prevent in the first place.
How about Decoda?? there is a video that explains how to use it, and it works pretty darn well for embedded lua source. (i am a happy customer). and it's pretty cheap.
You don't need to write your own console as you may want to start with one of the existing ones. RemDebug has already been suggested; I have been developing MobDebug, which is a debugger based on RemDebug, but with a host of new features and bug fixes. The detailed list of the changes is in the README.
Enabling debugging in your script may be as simple as adding require('mobdebug').start() (if you are running your app and the debugger server on the same machine). This should try to connect to the debugger listening on a default port on localhost. You can use a command-line interface included in MobDebug, or you can use a ZeroBrane Studio, which is a Lua IDE that integrates with MobDebug to provide debugging capabilities. The IDE supports debugging for Love2d, Moai, and other Lua engines and may well work for your set up too.
You can use my debugger: GRLD (graphical remote lua debugger). Like RemDebug it uses a socket connection, but unlike RemDebug it has a nice graphical interface. The source code is provided, so you can make it work on any platform. It works with the standard lua runtime. Free of charge for non-commercial use.
EDIT: sorry, I had to close the website, so the software is not available for download anymore. I might release it as open source software later, if I ever find the time.
EDIT 2: link updated, now hosted in github under the MIT license (open source)
I don't see how calling DebuggerBreak should work, since that is .NET specific. I would assume that only works with the forked Lua targeting the CLR.
If you are using standard Lua you have some rudementary debugging facilities through the lua function call debug.debug(). That will throw Lua into your console, so if you are running lua from a console, you should be able issue lua commands interactively to inspect your current state. debug.debug() wont put you into the current stack frame, so you have to use debug.getlocal() to read the values of your variables.
I haven't tried it myself yet, but I actually don't think making your own workable debug console is that much work. Remember Lua is not as complicated language as C++, so doing this is a lot easier than making a real C++ debugger like say gdb.
I think there are a lot of people who have done similar things already, whos code you could look at. Here is CLI debugger written in only lua. Just one lua file. Shouldn't be to hard use and modify for your needs.
If you are using windows and VS - Can you use the trick we use?
Copy the lua code in a file. Then in the lua code make a call to the Debugger api (in C++ this is DebuggerBreak() I think - see here). then when the lua code executes the debugger will fire up and you should be able to specify the file. Then debug as normal?