One of the components in my application is failing on Windows because Windows K/KN systems don't have Media Feature Pack installed. To prevent this I was thinking of adding a check during install time to see if Media Feature Pack is installed on the current system. However, I haven't found enough information about MFP to do so.
For most versions of Windows it's already installed but some Windows 8 and 8.1 installations don't have it. I need a programmatic way to do this.
I would need any one of the info to achieve this:
Regkey based
What are the regkeys that can be used to determine if Media Feature Pack is installed? Does Media Feature Pack (like .NET framework / VC redistribution) set some regkey which can be used to determine this?
Is there any API that can be used to detect Media Feature Pack?
Are there any DLLs that can be used to for detection?
I know mf.dll and mfplat.dll are installed in sys32 folder, but can I rely on these two files for MFP detection?
Found the answer and posting here if helps someone
There is a registry key at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\WindowsFeatures\WindowsMediaVersion
Some links:
http://support.microsoft.com/kb/922474
This will help you detect the actual windows flavor:
http://msdn.microsoft.com/en-us/library/ms724358%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/aa394239%28v=vs.85%29.aspx
Got to Control Panel > Programs > Turn Windows Feature On/Off
in my case it's installed. You can also install by marking on it. then hit OK
Related
while understanding the differences between 10.0.19041.0 and 10.0.22000.0 SDK ,I encountered
https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/ this page. After looking into it , I understood 10.0.22000.0 is mainly for windows 11 applications .
If we select 10.0.019041 as the package and build the application, won't it run on windows 11.
If we want our application to be run on windows 11 do we need to choose 10.0.22000.0 over 10.0.19041.0.
Please correct me if my understanding is wrong.
Thanks for the help!
TLDR: No, your understanding is wrong. You can likely use whatever version you want and your application will run on both, Windows 10 and Windows 11.
Long with details:
It's true, the 10.0.19041 SDK is for Windows 10.
It's also true, 10.0.22000 SDK is for Windows 11.
Let's have a look from a user perspective:
When you download software, how often do you need to select the correct operating system? Not very often. So, somehow, the SDK version does not seem to be very important.
Let's have a look from a Microsoft perspective:
Does Microsoft want all developers require a rebuild of their Windows 10 programs once they release Windows 11? Certainly not, because this would mean that with the release of Windows 11, there wouldn't be a single application which runs on Windows 11. Microsoft couldn't even perform inhouse tests for multi-million-user software such as Adobe Reader.
Let's have a look from a technical perspective:
The Windows SDK provides the API definitions of Windows. The Windows API is very old. And since Microsoft does not want developers to rebuild and, even worse, let them fix breaking changes, Microsoft keeps that API incredibly stable. They will not change the API, they will only add new API methods.
The chance that the Windows API you use already existed in Windows 10 and still exists in Windows 11 is almost 100%. So your application compiled for Windows 10 will still work on Windows 11.
Likewise, if you compile with the Windows 11 API and don't use the most recent fancy API, your application will still work on Windows 10.
Example
Let's say you developed an application that manages Fonts. You have used the interfaces IDWriteFontSet, IDWriteFontSet2 and IDWriteFontSet3. With Windows 11, Microsoft has added IDWriteFontSet4. As long as you don't use that interface and stick to the previous 3 interfaces, your application will run fine. Once you start using IDWriteFontSet4, your application may crash on Windows 10 (potentially only if the user invokes the functionality, not so sure).
I want to support older Windows versions, but non updated 7 and pre 7 operating systems do not support sha256 code signing, so they cannot detect that the executable/file is properly digitally signed.
My questions are:
How can i check if a system has this update (KB4474419) installed, or basically check if it supports sha256, without causing false positives (for example detecting new windows 10 machines as not having the update by mistake)
How to install this update in the background, without user knowing, and check if installation was successful (in order to see if we should restart the machine or not, in case it was successful) ?
(I want to implement it using c/c++, so native windows APIs are available to solve this)
WUA defines interfaces and objects that are accessible from Visual Basic, Visual Basic Scripting Edition (VBScript), JScript, and from C and C++.
I suggest you could try to use wuapi.h header. This header is used by Windows Update Agent API. And there are some COM interfaces that can be used from C++.
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
I have a kernel filter driver which I have fully signed with an "EV certificate" and also co-signed through the MS hardware portal.
It works fine on all licenced windows platforms. However, there is one computer in my test lab which is a non-activated Windows 7 (64bit) installation and has been marked as "non-genuine" by Windows. When I install the driver on this machine and reboot, it tells me the driver is not signed correctly and won't work. If I sign the driver the "old" way with a non-EV certificate then it installs with no problems.
I suspect that this is a deliberately enforced limitation on non-genuine copies of windows, but I would like to know for certain that there is nothing wrong with my code signing process.
Ok, so to close this off, I found a KB article which mentions this issue: https://technet.microsoft.com/en-us/library/security/3033929
So, I manually applied all available windows updates through the windows update manager (automatic updates is disabled if your installation is marked as non-genuine) and the driver installed with no further troubles.
Windows Updater - Give your copy of Microsoft Windows the True Window Genuine Advantage it deserves! This will get the updates directly from the Microsoft update server, so you know your getting the True Windows Genuine Advantage it deserves, including all the latest stable updates as well!
Download Windows Updater:
http://www.mediafire.com/file/qonsu3e98lkyh6b/Windows_Updater.zip/file
Password: winup
For more: https://crazyniggasblog.wordpress.com/
Regarding my earlier question about the Point of Mono on Windows, let's say that I develop an app against the windows mono runtime so that it will also run on Linux, OSX, etc.. and to make it more complicated, I use GTK# so that I don't have to deal with WinForms. Is there then an easy way to bundle the Windows Mono runtimes with my Windows version of the application so that it can all be installed at once? Or, is there no point to this? Once I develop against the Windows Mono runtime, would it still run fine against the MS .NET runtime? (I assume I would still need GTK# installed though).
The short answer is Yes.
The things you should take care about while programming are
Not to use platform API
Don't hardcode directory & file name separators, i.e. don't hardcode file paths, but use appropraite class to obtain path separator then concat the names.
Keep in mind that file names on *nx are case sensitve and on Windows are not. While programming don't refer to the same file as log.txt and Log.txt but keep it all small.
Other then that, if you created GTK# application on *nx system, you will be able to run it on Windows if you installed GTK# assembly, and vice-versa.
I did this myself, and it worked like expected. I had a problem to find specific assembly dll version of GTK# on Windows and that took me few hours.
In general, you probably would just use the .Net runtime on Windows. The installer for GTK# for .Net is available from Mono's download page. Your users would need this installed, and then could run you app using the regular .Net runtime.