Is it possible to enable Luna theme under Win XP or corresponding UI in Win7/10 using manifest file for Win16 application? For any Win32 executable using Common Controls library (COMCTL32), a detached manifest file with the same name will enable these UI extras. I need the same thing but for 16-bit app - if manifests are supported.
No. Manifest files are not supported for 16 bit processes, and 16 bit process have no support for XP themes.
Related
I have added desktop extension to my UWP app that gives some extra functionality if it runs on Windows 10 desktop platforms. But for other platforms it won't be used. Hence I want to make sure that the desktop extension isn't installed on other platforms thereby saving users some disk space. I have looked into app extension but it won't be viable for my use cases since the UWP app and desktop component communicate via named pipes and memory mapped files. Is there any other way I can control the installation of desktop component depending upon the platform it is being installed??
Update 1
From researching further I have found that this should be possible with optional packages/related sets, to be accurate related sets for my scenario. The examples provided in docs only show scenarios for packaging uwp apps as related sets and no example for packaging win32 apps as related sets was given. Is there any way to package a win32 application as related sets??
I'd like to use some functions that are only available in Windows 7 or higher in my application but I also want my app to remain compatible with Windows XP. The app should check at runtime if at least Windows 7 is available and offer some advanced features (like Media Foundation support) in that case.
Is the only way to do this to manually check for Windows 7-only DLLs using LoadLibrary and then importing all the functions I need using GetProcAddress()? This would be very inconvenient but I don't see any other way. Statically linking against Windows 7+ DLLs will cause the application to refuse to start on XP because of missing DLLs so this won't work. But doesn't the Windows SDK offer some more convenient technique for programmers who want to remain compatible with older Windows versions and optionally use features of newer Windows versions?
Note that my application is written in plain C so I'm looking for a solution in C.
Don't ever check for OS versions. Check for available features instead.
The most convenient way to keep your code compatible with earlier versions of Windows while still allowing it to opt-in to newer features is to use delay-loading of modules (see Linker Support for Delay-Loaded DLLs). This allows you to benefit from import resolution as you would with compile-time dynamic linking, yet allows you to respond to import failures at runtime.
There are 2 options:
LoadLibrary / GetProcAddress. It is not so inconvenient - you can define and assign function pointers and use them like normal functions.
Compile 2 versions for XP and 7. The installer chooses the right executable or XP version is started by default and it runs second executable if OS is Win7.
project propertiesI have an existing C++ unmanaged Win32 dll project (i have the source code for it), but this project uses a third party win32 dll for logging (log4cplus) whose source code i don't have. Is it possible to create a UWP (Universal Windows Platform) app that can use these dlls.
This can be done for app packages using the Desktop Bridge (http://aka.ms/desktopbridge), but for pure UWP packages you need to link the library with the /APPCONTAINER flag in order to pass the WACK (Windows App Certification Kit) test for Store onboarding.
Once linked with that flag you will get past that certification test and then the WACK will also verify that the library only calls UWP-compliant APIs. This may or may not require additional changes in order to make the library compliant for Store submission.
Environment:
Visual Studio 2015/Visual C++
OS: Windows 10 TH2 10586 / Corresponding Windows SDK
Since GetVersionEx is deprecated in Windows 8 and later, I wanted to use version helper APIs (IsWindows10OrGreater) to detect the OS in my DLL to decide the flow. However, as per the MSDN documentation, I will need to have a manifest (with compatibility section for supported OS versions) without which this API (IsWindows10OrGreater) will return false even if running in Windows 10.
I have added a manifest with the required compatibility sections but I could not still get it to work. It always returns false. (I have defined manifest ID as 2 in my resource.h as it is DLL)
To cross check, I implemented a sample standalone application with same manifest which works perfectly for this version helper API.
I need your help to understand what am I missing here in the DLL? Unfortunately, none of the discussions available online talk about DLL manifests for compatibility.
Thanks,
The answer comes a bit late, but I had a similar problem, see my question here.
The problem is that the compatibility section of a manifest is ignored when applied to a DLL, it only works when applied to an EXE.
So if you don't control the EXE that will use your DLL and can't be sure that it has the correct manifest, the way to get around it is to get the ProductVersion from the kernel32.dll file. This neatly corresponds with the Windows version and seems pretty reliable (it is also recommended on MSDN).
I would like to write some QtC++(BB10) and C#(Windows 8 Mobile) code for distribution.
What is the best way to package up the output. In Java(Android) one can package up the code in a JAR file and distribute that.
What would be the equivalent in BB10 and Windows 8 mobile?
For BlackBerry 10, you can use standard shared objects (.so files) or archives (.a files). They are standard C/C++ libraries.
On Windows 8/Windows Phone 8, using C#, you can create a Portable Class Library.