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.
Related
I'm deploying an app developed by Qt for both Windows and Linux:
On Windows I'm using built-in Qt windeployqt tool:
windeployqt.exe app.exe --qmldir %NS_REPO_DIR%\qml\
On Linux I'm using linuxdeployqt:
linuxdeployqt_EXE="${NS_REPO_DIR}/scripts/linuxdeployqt/linuxdeployqt-7-x86_64.AppImage"
${linuxdeployqt_EXE} app -qmake=${NS_QT_QMAKE_EXE} -qmldir=${NS_REPO_DIR}/qml/
The deployment size for Windows is around 70 MB and for Linux is around 300 MB. Is it normal? Is there anything I might be missing?
Thanks!
Update
This is my deployment on Linux whose content is sorted by size. The Qt files don't look like to be debug mode. Also, there is a huge libQt5WebEngineCore.so.5.12.7 file of 111 MB:
We would have to blame here to all the GNU/Linux distributions makers for changing so many things.
Unlike Windows that there are only few version Windows 7,8, 10 and that is it. In GNU/Linux we have so many versions and variants that we have to include "almost" everything that an application needs to ensure it will run on the majority of the existent system variants.
Said that, you can manually check the files deployed in your AppDir manually and remove those you know that your application will not require.
Side note: While linuxdeployqt is still functional there are other tools that do a better job. Consider checking https://github.com/linuxdeploy/ and https://github.com/AppImageCrafters/appimage-builder
I need to migrate an enterprise production database from a Windows source machine running Postgres 9.5 to an Ubuntu destination machine running Postgres 11.6 with < 15 mins downtime. I plan to do this with pglogical, which requires the extension being loaded on both source and destination. I am having trouble with the source side because it is Windows.
I have very little Postgres-Windows experience and can neither find any helpful literature on the specific situation nor can I figure out for myself how to presumably install from source.
I've dug and dug and so far the only answer I've been able to find is "ugh... Windows". It seems like the only way to build from source is using Visual Studio, which I don't have or know how to use.
Sources:
https://www.2ndquadrant.com/en/blog/compiling-postgresql-extensions-visual-studio-windows/
https://postgrespro.ru/list/thread-id/1835275
Alex, the 2ndQuadrant article you link to in your own comment solves this. A few of the project or build options noted there have moved a little bit in the newer VisualStudio Community editions, so I can see where you got hung-up.
Just for kicks I compiled 32-bit DLL on my oldest Windows instance. I included the /Release path so you can grab my DLL & see if it works for you. It's (a) 32-bit because I'm assuming worst-case for an old v9.5 install, and (b) targets Postgres 9.6 because that's what I had installed. Unless there were major API changes though, it should connect to v9.5 without any issues:
https://github.com/mbijon/winpglogical/tree/master
If you find you need a version that entirely matches Postgres 9.5, grab my solution files & VS Community 20xx. Load the project & update the Additional Include Directories in Project Config to target your v9.5 paths. That should be all that's needed to link v9.5 Postgres libs.
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 am trying to build a cross platform (vista, xp, mac, Linux).
I need to put the application in the USB drive formatted in FAT-32 and it should run on any OS computers.
Planning to use Java/JavaFx to do it.
Any advice how we can run on the multiple platforms.
Hi, Can anyone advice use of uber-jar for the above requirment. Would that be good fit.
A few things to take into consideration:
The USB must be formatted with a filesystem compatible with all the OS you need to work with.
A Java application would be able to run on any OS that is able to run Java, but each OS needs a different Java runtime. There's a Java runtime for Linux, one for Windows, one for OSX, etc.
My suggestion would be to define which OS you want to support and create launcher scripts for each one of them on the root of the USB. For instance you would have at least a couple like: myapp.cmd (for Windows), myapp.sh (for Linux), etc.
Additionally you may want to have different Java Runtimes in the same USB, so with the launcher scripts you execute your Java application running it with the corresponding JRE in the USB filesystem.
A twist in the launcher script would be to somehow check if the OS has already a JRE available (Like checking for a variable JAVA_HOME in the environment, or checking the output of "java -version") and act accordingly (although, running a Java application from your own JRE would be safer).
In Advanced Installer, how can I know if a 32bit process is running within a 64bit machine? I need to know this in order to prevent final users to install our application in given scenarios. Our approach is to use custom actions to detect if a given process is running, but it seems that Advanced installer isn't able to recognizes the ".exe *32" in the string end. Does someone know how to proceed in this situation?
This is not the correct approach. To stop users from installing the application on 64 bit machines you need to go to Launch Conditions page and uncheck all the 64-bit OS-es from the list. This will make your package to stop from installing on 64-bit machines.
Of course, for clients running a 64-bit OS you need to create a new setup package, that contains the 64-bit version of your application. For this package set the package type 64-bit AMD from Install Parameters page. Also, in Launch Conditions page make sure you uncheck all the 32-bit OS-es.
If you're really using a custom action to detect a particular 32-bit process, it's nothing to do with Advanced Installer. Your code enumerates the processes to find the one you want, does an OpenProcess() to get a handle and then calls IsWoW64Process, and closes the handle. If you have an x64 MSI file it won't install on a 32-bit system anyway, so I'm assuming that you are trying to prevent your x64 MSI file from installing on a 64-bit system if a certain 32-bit process is running.