This driver (https://github.com/Microsoft/Windows-driver-samples/tree/master/audio/sysvad) works only under MS Windows 10. Did anybody try to move it to early Windows(7 or 8.1)? WDK 10 supports those OS.
Unfortunately my attempts were fail.
Yes, It can be done but you need to exclude lots of features and code, since windows 7 or 8 may not supports new apis that are targeted for win 10.
If you are using Visual Studio simple workaround would be:
Go to property page > Driver setting > Set Target OS version to Winows 7 and Target platform to Dektop.
This will give you lots of error while compiling, now keep on removing code those can't be used targeted for win 7.
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 use Windows 11 but all apps I install report that I am running Windows 10. How can applications read the correct OS data for Windows 11?
Windows 11's version number is very similar. It's still major version 10, minor version 0. The difference between "Windows 10" and "Windows 11" is the build number being larger 22000. See this blog post.
Basically, unless the application was updated to know about Windows 11, it's going to think it's Windows 10.
It's also important to note that for application compatibility between major versions of Windows, many existing applications are subject an automatic "shim" that lies about the version number in any case. For more, see this blog post.
We are facing critical situation about signing our drivers.
I am wondering, is it possible to pass windows HLK test successfully for the drivers which are compiled with WDK 7.1
Because we were able to sign them using HCK but now after some bug fixes, the new version has to pass HLK test for windows 10 support, which can't !
Any advice is highly appreciated.
Thank you very much.
The answer is Yes.
The best thing you can do is just compile your drivers using wdk10 using VS2015 keep target OS as windows7 install it on windows10 and test it using HLK.
Or secondly you know that drivers are forward compatible if they are compiled for windows 7 they will work on windows 8.1 or windows 10 as well.
You just install your wdk7.1 compiled drivers on windows 10 OS. Then setup the client server for HLK and put the test for windows 10.
After that whichever tests fails just read the errors and solve them.
Some modifications will be there if you want to give support for windows 10 OS Ex: NonPagedPool should be replaced with NonPagedPoolNx etc.
But yes you need to change the code according to errors you are getting on test fails and fix them on your own there is no easy way.
Yup there will be lot of work but that is possible for sure, I have done that for PCI serial port drivers.
I am trying to work out the least disruptive way of beginning to experiment with Windows 8 development. I currently have a Windows 7 Ultimate PC (plenty of disk space, RAM and i7 CPU), and I have a copy of Windows 8 (not 8.1).
I have considered various options:
Convert my whole machine to Windows 8. (Not ideal right now, as I am in the middle of other work, but I may have to do this eventually).
Dual boot Windows 7 & 8. (Can't get this to work. Windows 7 is already installed, and though I can get Windows 8 to install on the second HD, I can't get its boot menu to see Windows 7. I suspect this would be easier if I installed Windows 8 first, but that would be a huge pain.)
Run either OS using a virtual machine. (I haven't looked into this yet, and I have no idea what is involved.)
As a final option, I wondered if it is possible to develop Windows 8 applications on a Windows 7 PC and remote debug on an attached Windows 8 device? (I'd prefer to do this, as it is a way I have worked often in the past while doing console development.)
Does anyone have any experience of any of this - positive or negative? It takes ages to experiment with this stuff, with the constant threat of recking my existing work environment. I'd really appreciate any advice or pointers to articles that deal with any of this stuff.
Microsoft do their loyal developers no favours. I've paid hundreds for modern hardware, Windows versions and Visual Studio, and still it seems difficult to say the least to develop for their latest OS.
Kind wishes ~ Patrick
Option 4 is not possible. In similar situation I went with option 2 and gratually migrate myself completly to windows 8.
If you have problems with boot try to ask on superuser.com or better search the web for guideline.
If you want to develop applications for Windows 8 don't go with option 3.Please see this post on installing Visual studio in VM.
Regarding option 2,verbatim from Microsoft
You must install the older operating system first, and then install the more recent operating system. If you don't (for example, if you install Windows Vista on a computer already running Windows 7), you can render your system inoperable. This can happen because earlier versions of Windows don't recognize the startup files used in more recent versions of Windows and can overwrite them.
But as #Antonio said there may be roundabout for option 2.
I'm looking for an OS abstraction library to use for my next project and I would like to know if ACE (Adaptive Communication Environment) can be used on a windows 7 environment. I've checked the ACE site (www.cs.wustl.edu/~schmidt/ACE.html) but the last version of windows supported is XP. As it seems a big and influent project, this seems strange to me.
Do any one have specific information on ACE support for windows seven or have tried to use it on that system?
Windows 7 will work with ACE, we do build/test it, but only in XP mode, not using the new Windows 7 API features