Are binaries built on Windows 7 guaranteed to work on 8/Vista, 10, and 11?
Are binaries built on Windows 10 guaranteed to work on Windows 11?
I've seen some things that make me wonder if Windows 11 is still technically Windows 10 in at least some ways that might ensure apps built on Windows 11 be sure to run on Windows 10?
I'm worried not just about the EXE format but for instance the shared library APIs etc. One can build, I'm sure, on a newer Windows and use a DLL, or a function in a DLL, that doesn't exist on the older Windows.
All versions of Windows support the same "Portable Executable" format for EXEs, but it all comes down to (a) the linker settings in the metadata of the binary, (b) the architecture for the processor, and (c) the APIs it needs to import.
If you build a Win32 classic desktop application using _WIN32_WINNT=0x0601, the WINAPI_FAMILY_DESKTOP API partition (the default), and use a recent version of the VC++ toolset, it will set a linker value of "6.00 operating system version". The resulting binary is compatible with Windows 7 SP1, and depending on exactly what APIs you use it might work on Windows Vista SP2 as well. It will also be forward compatible to Windows 8.x, Windows 10, and Windows 11.
Both x86 and x64 Windows support 32-bit applications, although x64 Windows does not support super-old 16-bit Windows programs that technically work on 32-bit Windows.
There are many application compatibility bugs that can make a program that should technically work on a newer version of Windows fail, but these can be avoided by just testing on newer versions of the OS before shipping.
Officially the modern VC++ toolsets, the Visual C/C++ Runtime, and Windows SDKs do not support Windows Vista, Windows 7 RTM, or Windows 8.0 development.
See Microsoft Docs.
Related
I'm trying to compile a program as 64 bits, it works perfectly with a simple console program but if I use my directX program it says me: error LNK1181: cannot open input file 'd3dx9.lib'. When I compile my directX program as 32 bits it works but in x64 it doesn't. I think visual studio 2013 has a default directory of directx with is x86 but I don't know if I'm right or not. I need to use x64 directX libs. How could I link them? Thanks for read.
VS 2013 comes with the Windows 8.1 SDK, and as of the Windows 8.0 SDK the DirectX SDK is considered deprecated. All versions of D3DX (D3DX9, D3DX10, and D3DX11) are also deprecated and are only available with the legacy DirectX SDK. You can use the legacy DirectX SDK in combination with the Windows 8.x SDK, but it requires the reverse path setup of VS 2010 or earlier. See MSDN and this blog post.
In your case, you probably don't have your project's VC++ Directories properties set up correctly for the x64 configurations:
Executable path:
Win32 configs: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86
x64 configs: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86
Include path
Both configs: $(IncludePath);$(DXSDK_DIR)Include
Library path
Win32 configs: $(LibraryPath);$(DXSDK_DIR)Lib\x86
x64 configs: $(LibraryPath);$(DXSDK_DIR)Lib\x64
Note: If you were using the v120_xp Platform Toolset for Windows XP support, you'd actually be using the Windows 7.1A SDK, and would go with the same path order as VS 2010 which is the reverse of the ones shown here--i.e. the DirectX SDK paths would go first, then the standard paths. See this post if you are trying to target Windows XP.
This all said, unless you are specifically targeting Windows XP the recommendation is to (a) use Direct3D 11 instead of legacy Direct3D 9, (b) avoid using the legacy DirectX SDK at all, and (c) avoid using D3DX9/D3DX10/D3DX11.
See also:
Living without D3DX
DirectX SDK Tools Catalog
DirectX SDK Samples Catalog
DirectX SDKs of a certain age
Is there any way to statically link Direct3D so the program doesn't depend on any D3D DLLs? It seems impossible with Direct3D 9 and later (although I would like to be proven wrong), but I can't find any information on older versions. I'm making a small simple game and I really don't want a mandatory installer, but I want to use Direct3D.
No, there was never a time when you could statically link any version of Direct3D into your app. The same is true for OpenGL.
If what you are asking is "How do I create a Direct3D app that doesn't require an installer?", then this is actually quite easy to achieve as long as you give up on trying to support ancient and irrelevant versions of the Windows OS.
The simplest thing to do is target DirectX 11.0. Your system requirements would read:
Windows 8.1, Windows 8.0, Windows 7, Windows Vista Service Pack 2 with KB 971644
See Direct3D 11 Deployment for Game Developers
Use Direct3D 11.0 APIs
Use DirectXMath, DirectX Tool Kit, DirectXTex, and/or DirectXMesh which are all statically linked
If desired, you could use Effects 11 as it is also statically linked.
Avoid all use of D3DX9, D3DX10, and D3DX11
Use XInput 9.1.0; avoid XInput 1.3 (on Windows 8.0+ you could use XInput 1.4)
Avoid use of XAudio2.7 (On Windows 8.0+ you could use XAudio 2.8)
Avoid use of XACT
If you use VS 2010 or later, then you can deploy the required VCREDIST files side-by-side with your application with a simple copy
If you use the Windows 8.x SDK version of D3DCompile, you can deploy it side-by-side with your application with a simple copy.
Audio is the biggest challenge here since XAudio 2.8 is only on Windows 8.0 or later, and XAudio 2.7 requires the DirectSetup redist to deploy. Most audio middleware solutions use WASAPI directly on Windows Vista+, so these are reasonable options. You could use legacy DirectSound8, and the headers for that are at least in the Windows 8.x SDK that comes with VS 2012/VS 2013.
If you need Windows XP support, then require Windows XP Service Pack 3 as the minimum OS. This will include DirectX 9.0c and WIC components as part of the OS.
You'll need to use Direct3D 9 and DirectSound8
Avoid using D3DX9 at all so all HLSL shaders would have to be pre-built offline, and you can't use the Effects (FX9) system or D3DXMath.
If you are using VS 2012/VS 2013, you can target Windows XP using the *_xp Platform Toolset, but remember that that uses the Windows 7.1A SDK and not the Windows 8.x SDK so it has some implications for DirectX development.
Direct3D 9 debugging on Windows 8.0 or later is also a huge pain as there's no developer runtime available for it.
All of this assumes you are using C++. Using .NET is not realistic as the deployment story for .NET is rather complicated. You could in theory use .NET 2.0 if you require Windows Vista+ or later, but it may require enabling a Windows feature on some versions of the OS, and you can't count on any version of .NET to be present on Windows XP. .NET 4.0 is on by default for Windows 8.0+, but support for .NET 3.5 and earlier is off by default. However, all use of DirectX from C# requires additional assemblies which themselves likely have dependencies on the legacy DirectSetup deployment.
In order to deploy C++ application built with VS2013 compiler under Windows XP, the "v120_xp" platform toolset has to be set: this make it possible the deployment from XP to 8.1. So next come the question: why this platform toolset is not the only one and the default? The "v120" platform toolset is suitable starting from Windows Vista. Is there any performance drawback? I've tested an application built towards both the platform toolsets under Windows 8 but I've seen no difference in performance (apparently..).
There are quite a few things you just can't do with the XP-dedicated toolset - it makes use of old headers and libraries, and so apps built with it just can't call a lot of newer APIs and use some fancy newer tools. A notable example is DirectX - quoting this MS page:
When building applications that support the legacy Windows XP platform,
you are using a platform header and library set similar to those that
shipped in the Windows 7.1 SDK rather than the Windows 8.x SDK with
the integrated DirectX SDK content (see Where is the DirectX SDK?).
Many of the "DirectX" headers and libraries are included with these
Windows XP compatible platform headers (see DirectX SDKs of a certain
age) such as Direct3D 9, DirectSound, and DirectInput. You will,
however, need to continue to use the legacy DirectX SDK for Windows XP
compatible versions of the D3DCompile API (#43), legacy D3DX9,
XAUDIO2, XINPUT, and PIX for Windows tool (the Visual Studio 2012
Graphics Debugger does not support Direct3D 9 applications).
Windows SDK 7.1A is installed as part of VS 2012 Update 1 for use with
the "v110_xp" Platform Toolset, which contains the headers, libraries,
and a subset of the tools that originally shipped in the Windows SDK
7.1. There are older Direct3D 10 and Direct3D 11 headers as part of this 7.1 era toolset which are outdated compared to the Windows 8.x
SDK versions using the standard "v110" Platform Toolset, particularly
the SDK Debug Layers installed by the Windows 8.0 SDK on Windows 7 and
Windows 8. The Platform Toolset "v110_xp" is therefore not recommended
for developing DirectX 11 applications, but it can technically be done
with some caution. Windows SDK 7.1A does not contain a dxguid.lib so
must either locally define the required GUIDs in your project by using
define INITGUID in one of your .cpp files, or use the legacy DirectX SDK version.
I built a C++ based COM object using Visual Studio 2012. It registers and works fine on 64-bit machines (called by 32-bit code and calling a 32-bit out-of-process COM server) but does not register on 32-bit machines (neither XP nor Win7 32-bit). The message from regsvr32 is
LoadLibrary("comobj.dll") failed - The specified procedure could not be found.
The project was originally built with Visual Studio 6 (7 years ago). It uses ATL macros such as BEGIN_COM_MAP and BEGIN_SINK_MAP to declare its implementation of various interfaces. It had to be re-compiled because the COM server it was invoking changed (new ProgID, new GUID, new type library, etc). Other than making those adjustments, and using current VS, there were no (intentional) changes -- there certainly was nothing in the old equivalent of the project file that would have pointed to 64-bitness.
Examining the DLL with the 64-bit version of DEPENDS.EXE shows "64" icons next to the standard referenced DLLs like KERNEL32 and USER32. Other than having built the DLL on a 64-bit machine, there is nothing "64-bit" about the DLL that I can find. The target is explicitly Win32 (not X64).
Examining the DLL with the 32-bit version of DEPENDS.EXE (on Windows XP running under Virtual PC) shows KERNEL32.DLL with a red icon, apparently because there are references to FlsAlloc FlsFree FlsGetValue FlsSetValue that do not exist in the 32-bit KERNEL32.DLL. (I have no idea what those are and don't know where those references come from -- perhaps from the copy of MFC on the 64-bit machine where the compile was done?)
Could it be that I have to install VS2012 on XP and re-compile there? How could that really be what needs to be done to build a Win32 COM object in C++ using current Visual Studio?
Does anyone know where I might look? I've checked all the project and solution options and nothing seems set to 64-bit. The option under "Use of MFC" is set to "Use Standard Windows Libraries" -- that's probably the answer but if that's not portable to 32-bit Windows it's hardly using only "standard libraries". (I will be trying changes to that after sending this.)
Thanks in advance for any advice.
Default toolset coming with Visual Studio 2012 produces output incompatible with Windows XP, through using certain APIs introduced only later with Vista.
In order to both utilize the power and feature richness of the latest Microsoft C++ compiler, and be still compatible with Windows XP, you need to use an alternate toolset codename "v110_xp" introduced with Visual Studio 2012 Update 1. At the moment the latest update available is Visual Studio Update 3, and you might want to simply install latest available updates for Visual Studio.
You have the setting available under Project Settings:
See more here: Configuring C++ 11 Programs for Windows XP.
I am converting some 32-bit .Net apps to x64. Enterprise Library 5 (32-bit) is used in a bunch of our apps, so I am under the impression that when we re-compile those in x64, then we will need to pull in a x64 version of EntLib. Does anyone know if that exists? I keep searching and I can't seem to find a straight answer - I find burbs about x64 configuration manager tool, but no info about a installable 64-bit version of EntLib5.
The entlib assemblies are architecture neutral. They can be loaded by either 32 or 64 bit processes with no changes.
On a 32-bit process, they'll run as 32-bit. On a 64-bit process, they'll run as 64 bits. No changes needed.
Remember, they're IL, not native code, and don't call into anything native, so there's no bitness dependencies.