I'm using JxBrowser version 6.2.
When I try to open two instances of this application and the JxBrowser is opened in one of them the other is totally hanging, and continues processing.
How can I open two instances of Jxbrowser from two different applications simultaneously?
JxBrowser 6 didn't handle a case when it's initialized from multiple Java processes simultaneously. We added such possibility in JxBrowser 7. For example, in 7.24 we fixed that latest "Synchronize the concurrent Chromium binaries extraction between multiple JVMs" issue regarding such use case. I recommend that you take a look at 7.24 or higher.
Related
I have a GUI application which contains a websocket server QWebSocketServer. I also have a python script which sends messages and the application processes them. Everything works well. During testing I wanted to run the application in headless mode using -platform offscreen command line argument added to the app executable name (I changed nothing else). But the problem is that when the application runs off-screen, the client script cannot establish connection with the web socket server. I tested this on localhost only. I do not understand how this two things, visibility of GUI and websockets, can interfere. Any ideas what could go wrong?
Note: I am using Qt 5.11.1 64-bit with VS 2017 on Windows 10 Pro.
A platform plugin is a bit more than merely "GUI". The -platform option selects a family of platform-specific plugins. Perhaps some plugins that make networking work are absent on that platform spec. That's very likely, since the offscreen platform is only a proof-of-concept: it's to show how you'd write a platform plugin. It's example code, and it does the bare minimum needed. It's nothing that you should be using for production without fully understanding what's there and how it works - it wasn't not meant for it, at least not the last time I looked at it. It shouldn't be hard to make it work, but you'd need to clone the source and start hacking on it.
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
I'm wondering what exactly this argument do? and know about potencial downsides that this argument could cause.
I tried searching this VM argument on internet but I couldn't find anything of it.
By default, on macOS JxBrowser initializes Chromium engine in Java process. It's required to support heavyweight rendering mode when Chromium window is embedded into Java frame. In macOS native window from one process (Chromium) cannot be embedded into a native window from another process (Java).
Initializing Chromium in Java process might cause deadlock issues on macOS. It's because SWT, JavaFX, and Chromium share the same Cocoa native thread in Java process.
The java.ipc.external=true VM option tells JxBrowser to initialize and run Chromium engine in separate native process. In this case Java and Chromium don't share Cocoa native thread. It allows solving deadlock issues on macOS platform.
As you may see, in this case heavyweight rendering mode cannot be used. So, in this case only lightweight rendering mode is used. This is the only downside of using this VM option.
I am looking for a way to monitor changes to Microsoft Edge Web driver programmatically.
Some possiblities:
* Would be great if there is an API (REST) to monitor latest available Edge webdriver.
* Since Edge driver is dependent on windows build version. some information about windows 10 build version in the API would be useful.
* Or Even better.. Since Edge driver depends on windows 10 build version, is there any chance for the Edge driver to get shipped with windows 10 builds. something like the native calc.exe in the system32 folder...
Any guidance/information would be very helpful.
Thank you..
Primary versions of Web Driver can always be found on dev.microsoftedge.com. Presently, this includes versions for 10240, 10586, and the Fast Ring of the Windows Insider Program. Monitoring that page will give you insight as to when a newer version of Web Driver is available for Edge.
With regards to your other questions:
Can we have a REST API to identify latest/supported Web Driver / OS versions
Can Web Driver be shipped in Windows 10 directly
I'll reach out to the appropriate team member(s), and see if this is something they've considered.
For the time being, you may be able to infer the machine's build of Windows by leveraging common APIs. For instance, via Node, you could do the following:
require("os").release().match(/\d+$/);
Depending on your build of windows, this will return, [10240], [10586], or some newer build number, like [14379]. You could then use this to instruct the user as to which version of Web Driver they should download.
I have a problem with connecting to remote graph from DirectShow Filter Graph Editor. When I run application that creates a direct show graph, on my Windows XP machine graph is shown in the list of remote graphs, but on the Windows 7 (x64) machine list of remote graphs is empty. I have registered proppage.dll and also registered directshowspy.dll ... but still no results. Any ideas?
There's a proppage.dll and an x64/proppage.dll and you'll need to register both to ensure that both x64 and x86 apps work.
The DLL files should be available with the Windows SDK. In case of the Windows 10 SDK, for example, the files will typically reside in the x64 and x86 folders in the %ProgramFiles(x86)%\Windows Kits\10\bin\%version% folder, with %version% being the installed version of the SDK (e.g. 10.0.18362.0).
I ran into this issue when I first moved to Windows 7. A DirectShow is composed of filters that are either built for x86 or x64 architecture.
If you're registering the x64 version of DirectShowSpy.dll, don't expect to be able to spy on a graph that uses x86 filters.
Get the x86 version of DirectShowSpy.dll, unregister your installed version and then install the x86 version.
I keep both versions of DirectShowSpy.dll on my machine and register the appropriate one for working on specific graphs.
I also recommend RadScorpion's GraphStudio ;)
Hope this helps!
Is this the same application that works in XP but not in Windows 7? The app needs to manually expose its graph to the Running Object Table so that GraphEdit will see it.
Example here: http://forum.inmatrix.com/index.php?showtopic=4439&view=findpost&p=19994
Well, I got same problem and figure out that GraphEdit must be run at the Admin level.
Otherwise, I can not see any remote graph.