2018-03-07, the new version of API (Vulkan 1.1) was released.
I want to know:
which console command can display currently installed API version.
$ /usr/bin/vulkaninfo | head -n 5
===========
VULKAN INFO
===========
Vulkan Instance Version: 1.1.70
WARNING: radv is not a conformant vulkan implementation, testing use only.
how to determine the same thing in C# language programmatically.
The Vulkan version is determined by multiple factors. It depends on what your device supports, the header you're using and the api version you request when creating your application. The "installed" version is either the SDK you're using or (one of) the runtime(s) your driver did install.
Checking via command line can be done using the vksjon_info tool from the LunarG SDK.
Checking via code (no matter what language, as long as you got headers) can be done by querying device properties via vkGetPhysicalDeviceProperties. The apiVersion member of the VkPhysicalDeviceProperties struct contains the maximum supported version for that device. Just shift the bits or use the version macros from the headers to get a humnan readable version (major.minor.patch).
Related
I am new to ISIS.
When I run the ./qview application
the following error display.
[libprotobuf FATAL google/protobuf/stubs/common.cc:68] This program requires version 3.9.0 of the Protocol Buffer runtime library, but the installed version is 3.5.1. Please update your library. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".)
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): This program requires version 3.9.0 of the Protocol Buffer runtime library, but the installed version is 3.5.1. Please update your library. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "google/protobuf/any.pb.cc".)
Aborted (core dumped)
I am wondering why I am getting this error. Please help.
Many applications have known security or stability issues if you link them against old versions of libraries. This is a common issue when building from source rather than downloading a precompiled container, because you often have to upgrade the versions of a dozen libraries that were previously installed on your system, but are not at the most current revision level. For example, perhaps the newer versions of google’s GRPC library has some feature that was not supported in older versions, and Isis cannot be used without this feature because it requires it. By trying to compile against an old version of the library on which it depends, you end up with a broken qview application, but luckily for you, it self diagnosed the issue and tells you exactly what went wrong.
So, you need to upgrade to the new version of the GRPC library, then rebuild it, then rebuild Isis. Alternatively, download a container or VM that has the entire system already built for your computer architecture and operating system.
I'm trying to revive some old software: it was developed on Windows XP, and I'm trying to get it working on Windows 10.
However, this software is dependent on api-ms-win-core-wow64-l1-1-1.dll, which isn't co-operating: Dependencies states that api-ms-win-core-wow64-l1-1-1.dll is missing imports, while Visual Studio's dumpbin states that it has no dependencies.
I'm aware that Microsoft has migrated its functionality and that nobody should link to the implementations directly, but is there any way to get api-ms-win-core-wow64-l1-1-1.dll functionality for this old software on Windows 10? Alternatively, is there an accessible way to rewrite old .dlls to link to Microsoft's Win32 APIs?
(For those who need the file: I got api-ms-win-core-wow64-l1-1-1.dll by running $ locate api-ms-win-core-wow64-l1-1-1.dll on a linux machine with wine installed on it.)
I'm not sure whether this directly addresses your issue. I'm supporting a Java app which uses JNI with some native Windows libraries. I used Dependencies to check what was missing and it turned out to be api-ms-win-core-wow64-l1-1-1.dll (through WS2_32.dll).
The solution for me was to install the latest VC redistributable from MS.
Getting libraries from Wine is probably not a solution, in case you seek to use them outside the linux environment. (They are wrappers and obviously not using native Windows assemblies)
You can get some success by using extracting them from the ReactOS live CD. However, you should be aware that many of these are umbrella libraries, as explained here:
An umbrella library is a single static-link library that exports a subset of Win32 APIs. For example, an umbrella library named OneCore.lib provides the exports for the subset of Win32 APIs that are common to all Windows 10 devices.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-umbrella-libraries
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis
My application needs to determine whether it is running on Windows PE.
Neither the deprecated GetVersionEx function nor the preferred alternative Version Helper APIs offer any indication whether I am operating on WinPE, only indicating the version of the OS.
This reference lists the compatible APIs for WinPE, so I need to be able limit my app to those APIs.
How can I programmatically determine from my App whether I am on WinPE, and which PE version is running?
If you simply need to determine whether you are running WinPE or not, you can check for the presence of the key MiniNT in HKLM\System\CurrentControlSet\Control or HKLM\System\ControlSet001\Control. If it is present, you are on WinPE 2.x or higher.
Cited in MSDN docs here, you can see which version of Windows PE youare running at the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE. That reference also gives a table of features and functionality each version will provide you.
For very old versions of Windows/WinPE before 2.0, check the version of %SYSTEMROOT%\SYSTEM32\FACTORY.EXE.
My application uses Firebird 2.5 and the installer needs to check whether any previous version of Firebird is installed on the system.
Earlier I was checking particularly version 2.0.1 by registry methods, but now I need to check for any version.
I have found some service API to retrieve version no, but that requires writing a small c/c++ program. I'm looking for some registry / other methods. Any clues ?
Go to:
Control Panel -> Programs
You will see Firebird with version number installed
I have requirement to create cocoa framework/Libarary in Xcode 4 and support it on 10.3.9.I know it was 10 years older mac.But It is the requirement.
I have gone through the apple's sdk compatibility guide,document was saying that if we set the deployment target to 10.4,unconditionally it will work on 10.3.9 version.I did not understand what is "unconditionally" refers here.
If I need to be supported on 10.3.9,What precautions I need to be taken.Any help would be appreciated.
If your version of Xcode doesn't have a 10.3 SDK, then it will be very hard for you to avoid accidentally using APIs and features which aren't available on 10.3.9. Setting the deployment target makes it so that your program may load on 10.3.9 – the executable won't use dynamic loader commands which are unknown to the loader on 10.3.9 and any references to symbols that aren't available on 10.3.9 will be weak references – but it doesn't mean it will run.
In order to run without crashing, you have to avoid actually dereferencing any of those weak-linked symbols or calling any unavailable methods. The only reliable way to avoid that is to get the compiler's help, but that's only possible if you have the appropriate SDK, which isn't available in Xcode 4. (Honestly, I don't know when a 10.3 SDK was last available.)
Finally, it is folly to try to support a deployment target if you can't test on that platform. You need a machine running 10.3.9. If you have that, then you can use the version of Xcode native to that version of the OS. You can have a code base that can be built in either environment using conditional compilation, although the Xcode project files themselves aren't compatible.