In Windows SDK v.10.0.14393.0, in winerror.h, there is a SQLite section, line 57116 and below. Is SQLite officially a part of Win32 now?
EDIT: there's a winsqlite3.h under um\winsqlite, introduced some time between SDK v.10.0.10240.0 and v.10.0.10586.0. And winsqlite3.lib under um.
EDIT: changed an existing Win32 application to use that, works like a charm. Needed to redefine _WIN32_WINNT to 0xa00 though - explicitly targeting Windows 10.
Thanks for noticing, because it's interesting!
Microsoft made it part of the Windows 10 Anniversary Edition and it's available for UWP apps: https://blogs.windows.com/buildingapps/2016/05/03/data-access-in-universal-windows-platform-uwp-apps/
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).
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.
Since the DIFx Guidelines state that: "the Driver Install Frameworks (DIFx) tools were removed from the Windows 10 Version 1607 WDK" and the WiX Driver Element relies on the WixDifxAppExtension, is the use of the Driver Element still the way to go to install a driver? Or should I use the SetupAPI directly (e.g. as a DLL which is called in the MSI)?
A bit late but I just wanted to state that the WixDifxAppExtension works fine in 2022 on Windows 10.
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).
Does anybody know if Delphi (Win32) works with XP embedded
Yes it does, is the short answer
We use Delphi 5 with WePos (windows embedded for point of sale) and it works fine.
Running Interbase 5.5 via the BDE
The only thing we have to do is install an extra file. the file is called "libraryfiles.exe" , not very descriptive I know, here is more info to help you find it
Ascentive Libary Files
Version: 2.0.0.24
Product name: Libraryfiles Install Program
In general, it seems to work (example Delphi program for XPE), but there could be some problems when using some specific libraries (i.e. XML) where XP embedded could differ from an usual XP installation.
I recently finished a project with an ActiveForm, making heavy use of OpenGL and has a ton of third party libraries inside and everything works like a charm on XP embedded.
BTW, I wasn't told that this thing was meant to run on XP embedded...
XP Embedded is XP, with the ability to remove lots of stuff. Almost anything that runs on XP can be made to run on XPE. Often the key is finding the libraries as #Re0sless did.