Windows SDK 7.1 was the last version that included the baseclasses direct show sample. But later Windows SDK have strmbase.lib with the compiled library. What use is the library without the headers?
It might be included without good reason waiting for its cleanup time, or there is unobvious reason such as reference to this static library when linking other legacy libraries.
Either way you are correct in the part that DirectShow bases classes are no longer in Windows SDK. Those interested in DirectShow development would typically get DirectShow BaseClasses and samples from Windows-classic-samples/Win7Samples and build the code including strmbase.lib themselves.
Related
The Android app I am working on is completely written in C++. I need to integrate it with a static library that also is written in C++. There is no dependency on STL in any of the projects.
The static library uses cmake to build. Unfortunately, the app is based on an old AOSP version of Android NDK and has no support for cmake.
I also have a newer version of Android NDK in a different directory. This version does support cmake toolchains.
I am thinking I will build the static library against the new NDK and use it in my main project. The ABI is the same for both the projects - armv7a.
I have tested this logic with a sample code. It seems to work. I am able to invoke methods in the static library from my main app.
Also, there are no name-mangling issues.
The question I have is if there is any issue I am overlooking.
I am thinking it should not matter that the compilers used to build the sources are different. As long as they are producing arm-compatible code, I should be able to able to integrate them.
As a matter of fact, another library that I am using, gstreamer, is available for download as pre-built binaries at https://gstreamer.freedesktop.org/data/pkg/android.
Please advice.
For those interested, mixing NDKs doesn't seem to be an issue as long as you follow certain guidelines. Some of them are listed at https://developer.android.com/ndk/guides/cpp-support.
Essentially, there is no problem if your project is 'C' based. However, if you are using C++, you must not use STL.
I have managed to build part of my code with two NDKs and I am not seeing any link time or runtime errors.
I need to consume a library that doesn't yet have CoreCLR support (RabbitMQ.Client, to be specific). Is it possible to utilize a mono-based port of that library on a Linux system from inside a CoreCLR executable? If so, how is that achieved?
It is impossible at binary level (unless using a proper PCL profile). .NET Core has a different approach to arrange classes in assemblies, so some assemblies on desktop .NET Framework are broken into smaller assemblies, and types are moved. A desktop targeting assembly (from .NET or Mono) won't work on .NET Core due to such changes.
But it is obviously possible at source code level, as there was an attempt to port Mono's WinForms to .NET Core,
http://forums.dotnetfoundation.org/t/anyone-porting-winforms-mono-to-net-core/898/4
Once a new .NET Core library project is created, the source files should be able to be carried over (with some modification or even none).
However, .NET Core has been evolving too fast, and that attempt might be now out of date. Anyone would like to explore in this area can follow that example and try once again. Good luck.
I am trying to build a project using NDK media sdk, but I need it to run on older phones too (to support 90% of the market...). Now, I am able to include the libmediasdk.so & libOpenMAXAL.so manually, and it seem to link properly, but I am not sure this is a correct practice.
Moreover, the libraries (libmediasdk.so & libOpenMAXAL.so) are expected to be available on the target device, so unless I do copy them manually to the project/libs/arch-arm the application complains libraries are not found.
Have I gone too far ? :) hope not..
You can write code that optionally uses the new native media functions (libmediandk.so), but you can only use it on Android 21+. So if you want to support older android versions, you must make this codepath optional, allowing it to fail cleanly on other devices where libmediandk.so doesn't exist.
If the MediaCodec APIs are optional within your app and you are ok with them only being available on Android 21+, you can just make sure you build this into a separate lib (like libyourapp-media.so), and be ready to handle the case when System.loadLibrary() for this library fails.
However, if you want to use other native code components in your app, there's a few gotchas you need to know. If you build your app targeting android-21 and your native code uses certain functions (such as atof), it will only run on android-21 or newer (even if code using the function atof would build just fine for the older platforms). The reason for this is that the atof function didn't exist before, and calls to it were redirected to strtod. If you build your library targeting android-21, it will actually do the calls to atof instead, which doesn't exist in the older platform versions. This also goes for quite a number of other functions, not only atof. See http://b.android.com/73725 for details on this.
Therefore, if you want to use the new native media APIs in a library that should be loadable on older versions (except for the native media APIs that obviously won't work on older versions), you need to build your native components targeting an older android version. You'd need to duplicate the media/* headers from android-21, but instead of linking to libmediandk.so (-lmediandk in LOCAL_LDLIBS), you'd need to load this library at runtime using dlopen.
If you need to do the same on older platforms as well, you should use the MediaCodec API in java (which you can call via JNI). Then, there's little point in doing all of this extra work just to use the native version of the API on Android 21+, when you can use the java API on all versions (it works from Android 16, and more reliably since Android 18).
In my DirectShow application I have a third party DLL (a 32bit DirectShow filter) that I don't have source for that links against the 32bit Windows version of Intel Threading Building Blocks (tbb.dll).
If I want to use Threading Building Blocks in my own DLL in the same process (e.g. another 32bit DirectShow filter) does this force me to use the same version of Visual Studio that the author of this third party DLL used?
EDIT - I've realised that the version independent _mt library is probably the best one to use in this scenario. What happens if third party vendors haven't built for this _mt dll?
In my own Threading Building blocks installation I notice that there are different versions of tbb.dll for different versions of Visual Studio - 2005, 2008, 2010 and 'MT' (not sure what that is yet). One obvious reason for this is that the different versions of tbb.dll link against different versions of the Visual Studio runtime library DLLs. Is it possible to tell which version of tbb.dll is required by inspection or do I have to grub around looking for strings in the binary indicating the compiler version used (the third party DLL appears to be linking the visual studio runtimes statically)?
As far as I can tell tbb.dll doesn't use manifests and side by side versioning and is given the same name for different compiler versions. A last resort would be to rename the different tbb.dlls and hack the import library or imports to reference the renamed dlls but I'd really rather avoid this. Is there a clean way to redirect the imports with linker options?
As these DLLs are well behaved DirectShow filters they won't be passing Visual Studio runtime or TBB objects between them which would clearly be dangerous. Their interaction will be limited to calling each other via standard COM DirectShow calls.
If you are not using TBB, the question is only about Visual Studio versions, then you don't have to worry: Visual C++ Runtime DLLs have different names across versions, e.g. MSVCR70.DLL, MSVCR90.DLL etc. And, as you already discovered, /MT switch will compile/link a static version of runtime and will embed the stuff into your DLL without having to worry about sharing right DLL with a peer DLL.
The RtAudio documentation says.
Windows (DirectSound):
The configure script provides support for the MinGW compiler. DirectSound support is specified with the "--with-ds" flag.
In order to compile RtAudio under Windows for the DirectSound API, you must have the header and source files for DirectSound version 5.0 or higher. As far as I know, there is no DirectSoundCapture support for Windows NT. Audio output latency with DirectSound can be reasonably good, especially since RtAudio version 3.0.2. Input audio latency still tends to be bad but better since version 3.0.2. RtAudio was originally developed with Visual C++ version 6.0 but has been tested with .NET.
The DirectSound version of RtAudio can be compiled with or without the UNICODE preprocessor definition.
It says I must have a header and source files for DirectSound. So do I need to write these headers and source files in C++ or I can get hold of them from somewhere.
You can get the DirectSound headers and libs as part of the DirectX SDK from Microsoft. I went to the Microsoft Download Center, searched for "DirectX SDK", sorted by release date, then downloaded the most recent one. Here's a direct link to it: DirectX SDK - (June 2010).