The version compatibility of Vulkan SDK is documented in LunarG's whitepaper, but I'd like to know whether those extensions controlled by the flags listed below are following the same rule as well.
VK_USE_PLATFORM_DIRECTFB_EXT
VK_USE_PLATFORM_ANDROID_KHR
VK_USE_PLATFORM_FUCHSIA
VK_USE_PLATFORM_IOS_MVK
VK_USE_PLATFORM_MACOS_MVK
VK_USE_PLATFORM_METAL_EXT
VK_USE_PLATFORM_VI_NN
VK_USE_PLATFORM_WAYLAND_KHR
VK_USE_PLATFORM_WIN32_KHR
VK_USE_PLATFORM_XCB_KHR
VK_USE_PLATFORM_XLIB_KHR
VK_USE_PLATFORM_XLIB_XRANDR_EXT
VK_USE_PLATFORM_GGP
VK_USE_PLATFORM_SCREEN_QNX
VK_ENABLE_BETA_EXTENSIONS
I believe if the VK_ENABLE_BETA_EXTENSIONS is enabled, then the version compatibility is not guaranteed, but how about those platform extensions?
For the time being, SDK copies the versioning of the specification. If the SDK version is same or higher, the headers should include all the functionality published with a given spec version(and protected by an appropriate macro, as you listed them), and layers should not break (exept for an occasional bug).
Related
is it possible to reduce/limit the Qt API features to specific earlier versions?
In the API documentation there is e.g. information that methods are introduced with version major.minor.
Can you restrict the API features of an installed newer version to the earlier ones without installing?
I don't think so, because there are no version conditions in the header files.
But maybe you know for sure...
Is there a tool which detects the usage of incompatible API to a specific version?
Thanks
Markus
When "mavenizing" a Flex SDK (convert the Flex SDK to Maven artifacts) you need to indicate the Flash Player version. Does it mean that I can only create Flex swf web (not air) applications which run on that version of the Flash Player or can I still target earlier versions?
I was wondering if I can simply select the most recent Flash Player version or if I should keep in mind that some of the users are still using an older version.
Actually the mavenizer creates artifacts for whatever it finds. Usually you installed a Flex version with the version you selected in the Installer. The Mavenizer can only create artifacts for what he finds. If you have multiple versions in your FDK, it will generate mutliple versions.
So if you want to target 9.0 for example, you have to have the playerglobal for that in the "FDK-home/frameworks/libs/player/9.0" directory and the Mavenizer will create artifacts for 9.0. You can then simply reference playerglobal in version 9.0 and as long as you only use parts of flex that don't need anything beyond 9.0 you should be good to go.
You can still target earlier versions. Just think of that version selection as the minimum required flash player version. Certain bits of functionality were exposed to the FlexSDK in certain versions of the flash player. For example feature X is available in Flash Player 10.0 but not in Flash Player 9.0, so if you use feature X then you will require at least Flash Player 10.
No you can target other versions. You can also change the target version after the fact (look at the scripts in the ide directory).
Newer versions of the Flash Player have security fixes and better performance, but it's not the version you compile the SDK has any effect on this, it's the version that you run the swf in that matters. Given that I'd compile for a older version of the Flash Player to give a wide user base, (for instance target 11.1) unless you need to use some of the very latest Flash Player features.
Each version of the SDK was tested with several versions of the FP but not all of them, so it may be possible (but unlikely) bugs exist on a version the Flash Player that the SDK wasn't tested with.
I'm playing around a little bit with a hooked DirectX 9 application. As you may know, the D3DX framework has been deprecated in Windows 8. Microsoft advises us to "investigate alternative solutions to working with the Direct3D API". What are alternative solutions to using the handy D3DXCreateFont in Windows 8? I am working with DirectX version 9. If I am still able to reference the D3DX framework somehow in Windows 8, this is my preferred solution.
Use D3DX.
In this particular case, because you are hooking an application already using DirectX 9, using the libraries and resources provided by that version of the API is your best solution. When working with D3D9, using D3DX for the utility functions is perfectly acceptable and recommended practice.
The recommendations apply to software designed for Windows 8. While your software may be intended to work on that platform, hooking into applications that was not imposes significant restrictions. You have to work with what's already in use, and in this case, D3DX is going to be far more compatible than trying to rope in new libraries. In fact, given how many D3D9 and earlier apps use D3DX, there's a good chance it's already in use, and you may be able to just reuse that.
Note that this does not mean the D3DX DLL(s) you need are present; depending on the application, there may only be a single version present, so you may need to provide the DLL(s) or installer.
I'm planning to write a C library which will act as an umbrella "wrapper" around several other libs. Some of the libraries will be GPL and some will be proprietary. Moreover, some of the libraries may not be available at compile time, so I plan to have autotools detect them during configure. I'm also wondering if I should build in support for these weak dependencies and then also detect them at run-time -- particularly for the proprietary libs. Here's why:
Without going into specifics, the library is intended to provide an API for talking to various devices, some of which don't have open source drivers. Currently it's difficult to program for these devices because there is no standard, easily available API to use. Each vendor provides its own. There are a few other APIs available that attempt to wrap them, but they are by and large
C++-only.
Designed for a Windows environment, with *nix as an afterthought.
Fail to build unless you have dependencies in the right places, i.e., complete lack of a proper configure/build system.
Most importantly, designed in such a way that they often link directly to proprietary libs, making me almost 100% sure it would be impossible to get these APIs into Debian.
Therefore my end-goal is to build a very simple and straight-forward C API that has a chance in hell of making it into distros so that people can actually write programs for these devices with a simple apt-get.
My question is, how should I best design the library to be GPL-compatible and Debian-friendly, but still be able to call out to proprietary libs when necessary?
Ideally I'd like the user to be able to apt-get a program using this library, and then as long as the vendor's user-level driver is installed to the expected place, everything should work out of the box.
My concern is two-fold:
having dependencies on optional, proprietary libs means the binary distro of the library can't be compiled to dynamically link to these libs, since they may or may not be available.
the user should not have to install dependencies for devices he does not have, open or proprietary.
How do other packages handle this problem of linking to proprietary libs and having run-time weak dependencies? Is dlopen the right way to go for everything? Should I dlopen only the proprietary stuff? What are reasons why or cases when Debian might reject such a package?
Lastly, I realize this probably isn't the right forum for this question about Debian policy, so can anyone point to me a better place to ask this question?
Thanks.
I have no relationship to Debian and cannot speak about their policies. However, for your framework, this seems a reasonable approach:
Define a simple header file that expresses the functionality you need from these plugins
Create a useful GPL/LGPL/BSD plugin that uses that interface
Have your main program load that using libdl, as you mentioned (if your main program is GPL, you need to have a licence exception to allow linking proprietary plugins)
Submit those for inclusion in Debian, and don't mention about the proprietary stuff
The main point is that your plugin system should be useful for free software, and not just be a Trojan horse to allow proprietary code to be loaded.
Using dlopen does not change the fact that you are writing a program to deliberately link to proprietary libraries and GPL libraries at the same time, it just shifts the linking from compile time to run time. While common consensus among the masses is that the GPL does not cover linking dynamically at runtime in this way, it is not safe legal advice to rely on such common understanding. The way I would solve the problem is to write a program with a single generic API for plugins (which can use dlopen, but the key is that you have not specifically written this program to link to proprietary libraries). The program must be under a free license that is compatible with all the plugins you eventually want it to be used with (ie LGPL, or GPL with exception for that API). Then write separate plugins for the GPL libraries and the proprietary libraries, and distribute them separately. If only one plugin can be loaded at a time, then there is no legal problem. If it is necessary to allow more than one plugin at once, then you need to be careful to separate your distribution. As the GPL is a distribution license, what the end users do is not a concern.
I'm working on a cross-platform solution currently. The solution uses XmlMtomReader and XmlMtomWriter from .NET framework 3.0.
Now i need to know if these two classes (and all the nessasary infrastructure around them) are fully supported in Mono project from the porting-it-to-linux point of view. :)
You can check it on the mono status:
http://go-mono.com/status/
You can also check your code using the mono migration analyser
http://www.mono-project.com/MoMA
I checked they are currently not implemented
The APIs are available on the current Mono 2.6 preview, but they are not available on the 2.4 release (the current official release).