Im developing an application that would detect the DirectX versions installed on my system. For example if DirectX 9 and DirectX 11 are installed on my system then my program must detect these installations and display the installed versions. But I've no idea on how to accomplish this
EDIT:
I dont want to use dxdiag UI to detect the versions, I want my program to detect the versions. And all installed versions must be detected not just the one that is pre-installed with the OS or the highest level supported by the OS
You'll most likely not be able to list all installed DirectX versions. I came across this interesting article in the support pages of the gaming platform called Steam:
Trying to manually check for the correct versions is extremely complicated because there are numerous files that must all be present and individual system configuration options like dll search paths complicate the situation. In addition, the dependencies and required checks may change in each new version of the D3DX runtime.
As mentioned by Hans Passant you can get the highest installed version by running dxdiag /x <output file> to generate an XML file containing various entries of your computer information, then parse or deserialize that file in your application.
Related
Trying to set up IntelliJ IDEA with the Lua plugin. This requires me to direct it to the location of a Lua SDK. All instructions I have been able to find for this are on a Windows system, pointing to a specific directory in Program Files. I am running a Linux system. I've built and installed Lua 5.3.4 (newest version at time of writing) from source, but as far as I can tell that doesn't include any equivalent to the SDK needed – it just drops a variety of necessary files in /usr/local/{bin,include,lib,man/man1} and creates two empty directories /usr/local/{lib,share}/lua/5.3.
Am I missing something conceptual? Do I need to get something else (the existence of which I have been unable to confirm)? Should I just give up on this and find another IDE? The plugin seems to come with two SDKs, Kahlua and LuaJ, but I don't know how well either of these match up to either standard Lua or LuaJit, which are what I would be using.
This is assuming you are using this Lua plugin for IntelliJ:
If you have installed Lua via DNF or yum simply guide IntelliJ to /urs/bin and it'll find it. (I assume this also works for other installers like apt or brew.)
It looks like the SDK is just looking for two files lua and luac which both live in /usr/bin.
I'm on windows 7 64bit, trying to run some software and I am getting an error indicating that I am missing qt5widgets.dll. I tried to find this dll from different websites but didn't have any luck. Where can I find the files to resolve this dependency ?
You should contact the person who gave you the application. The necessary libraries should have been included in the distribution.
Failing that, you may want to try here you will need to get the version that the application is expecting, and potentially match the compiler that was used to build the application.
You would expect the required dll's would come bundled with the application. This application is a QT application and the aforementioned dll's can also be found at QT5 official website.
Looking for a download to MONO Runtime 3.2 but I just can find this for Mac.
See HERE
Are there no releases for Linux/Windows ?
Are there no releases for Linux?
The tarball is all you need to use/install Mono in Linux.
If what you want is that your favourite distro imports this version of Mono into its packaging system (e.g.: apt-get), then you would need to ask in the forums, mailing lists or other online resources about that distro.
Are there no releases for Windows?
First, I will ask you another question, are you sure do you really need Mono for Windows? For most use cases, Windows already bundles .NET into the last versions. Furthermore, Mono for Windows is not a top priority platform for the Mono team and may lack features or have worse performance than on Linux/Mac. Therefore Mono for windows is only really useful for certain uncommon scenarios.
If you're really interested in those uncommon use cases, then keep bugging Mono maintainers in their forums, mailing lists or IRC, to remind them to package it (it's not really a priority anymore since this platform is not something they target with their commercial offerings).
UPDATE: A Xamarin employee stated that the installer would be available when version 3.2.3 is released, and they complied with their promise because 3.2.3 has been released and the windows installer is available in the download page.
I'm trying to build an embedded simple web browser for an embedded device and I've decided to use WebKit / WebKitGTK+. However, our device uses a Linux environment somewhat based on CentOS 5.8. I haven't been able to find any RPMS or mention of support for WebKit / WebKitGTK+ for CentOS 5.8 while doing several web searches.
Does anybody know if it's possible to build an older version of WebKitGTK+ such as 1.2.6-2.el6_0 which works well on CentOS 6.3? Are any RPMS available for CentOS 5.8?
The goal here is to be able to run a relatively current, at least 1.2.6 version of WebKitGTk on CentOS 5.8
Note: I was able to sort everything out. Just took a long time compiling all of the dependencies in the correct order with the correct options. I was able to get WebKitGTK 1.6.0 running on Centos 5.8.
You shouldn't have any problems building an old version of webkit if you can install the older versions of libraries that it requires.
If you have older or newer versions of GTK+ etc installed than the old version of webkit requires it may need quite a bit of porting to compile.
I'm not aware of any RPMs that meet your requirements
Depending on the compilation options you should be able to compile the dependencies in an isolated directory. With each library you typically use the --prefix option to specify the destination. Then when compiling something that depends on that library, you typically have an option to specify where to look for that library - something like --with-libraryname=/path/to/library. You want to check ./configure --help of each thing you're compiling to get the correct options.
It'll be quite a bit of work, but you should be able to compile everything you need into an isolated directory without replacing anything on the system. I would highly recommend you avoid doing this in root to ensure you have the right options.
With the new firefox we are shipping more and more libraries as the XPom interfaces we interact with are changing. We are at 10 dlls and increasing, each with a size of almost 2M.
This size is a concern for some users.
While we look at restructuring the library to seperate the parts we can make common between them, we are thinking about how we might reduce space on the disk while supporting version upgrades.
For instance, user has FireFox 3.6 and 4.0 installed and when our product is installed we install a dll for each version. When Firefox is 4.0 upgraded (say to 6.0) how might we now install from the msi the missing dll for 6.0 support.
Any ideas on how we could achieve this?
Are we worrying for no reason?
My first thought was we 'AllowAdvertise' and when FF tries to load the dll as directed by chrome it will cause the install, it doesn't seem to work.
My first reaction is to suggest that you move away from XPCOM and towards js-ctypes. After all, this is the direction that Mozilla is pushing extension developers (see Wladimir Palant's comments for example). If there isn't anything in your binary code that absolutely positively requires use of XPCOM, you'll be much happier to ship a DLL that interfaces with JS when needed via js-ctypes.
I guess that your extension is Windows-only so supporting multiple platforms is not an issue. A possible short-term solution:
Have a separate extension package for each Firefox version, mark it as compatible with this Firefox version only (e.g. minVersion 4.0 and maxVersion 4.*).
When your extension is installed, install the version that is compatible with user's installed Firefox version.
Make sure that your extensions have an updateURL entry that is pointing to your server. It is important to have %APP_VERSION% in the URL.
Make sure to test Firefox betas and prepare a new extension version in time for the next Firefox release (releases are scheduled on Tuesdays every 6 weeks, next release being on September 27th).
Configure your server to indicate different packages as updates depending on the Firefox version used. So an update check with %APP_VERSION% 4.0.1 would be sent to extension-ff4.xpi while %APP_VERSION% 6.0 would get extension-ff6.xpi.
Firefox will always check for extension updates when the application is updated. If you can give it a compatible update it will install it. But preparing new packages every six weeks requires tons of effort and I guess that you want to refactor your code/move to js-ctypes ASAP. Oh, and I think that you need to ignore the unlikely scenario that some user has more than one Firefox version installed.