I have a product that I ship with static libraries for use by third party integrators. I have seen compatibility problems with other versions of VS so I was wondering if there is any info about library compatibility from 08 to 10 and vice versa?
This is with Standard Windows Libraries (no mfc) and not ATL.
you are using MFC as shared dll or using ATL?
The best information I can find says that there is no library compatibility between 2008 and 2010.
Related
Some libraries are available to download as pre-compiled binaries, usually in specific architecture (x32 or x64) but I have also noticed that some pre-compiled binaries are splitted based on visual studio version, for example: vc17_x64. Let's assume that I use visual studio 2019. Does it mean that I have to use binaries precompiled for vc2019 or build a library from source when apropriate version is not available ? It's not clear for me because some pre-compilied binaries don't contain information about visual studio version.
If a pre-compiled library has Visual Studio version info you should use that version of Visual Studio to work with the library. This is not always the case though, as often enough happens that an older (with respect to VS version) library contains code that is a subset of the newer VS's header and runtime SDK files (.NET, C/C++, Windows SDK, etc). The other way around, when the library is newer can also work but it's far less frequent. You can try, if it doesn't work for your particular library and VS version then you should consider matching versions, rebuilding not always works for the same reasons of code changes.
If a library doesn't contain VS version info then it's reasonable to assume that it's portable/compatible up to operating system (Windows, Linux, etc) and programming language version (C++ 11, C++ 14, C# 7, C# 8, etc). However, VS version comes into play here as well, not every VS runs in every Windows, neither it supports the same runtimes, SDKs, and language(s) version. You should always check the library documentation for recommended working environment, if this info doesn't exist then it's trial and error and/or community consulting.
On loading up a direct x 11 SDK project example, after linking all Libs./includes ETC that I was given an error from; I came across the following within an fx file.
VS version : VS ultimate 2013
Example name : 'DepthOfFeild10.1'
SDK : 'Microsoft DirectX SDK (February 2010)'
fx file name : 'DepthOfField10.1.fx'
error : Error 1 error X3000: syntax error: unexpected token 'cb0'
Perhaps I'm missing a lib/tool/set-up procedure ?
(Running Debug, X64)
Advice appreciated.
First of all, if you are trying to use VS 2013 and the legacy DirectX SDK together, be sure to read MSDN.
You need to use a different include/lib/executable path order with VS 2012 and later than the default VS 2010 projects that come with the legacy DirectX SDK February 2010 and June 2010 releases.
Many of the legacy DirectX SDK samples have been updated to remove the need to use the legacy DirectX SDK at all since VS 2013 and the Windows 8.1 SDK are generally sufficient. These are published to GitHub. See DirectX SDK Samples Catalog. DepthOfField10.1, however, is not one of these because it's an AMD sample. You can find AMD's version of it in their archive.
Start with the DirectX SDK (June 2010) version of DepthOfField10.1 (install it from the sample browser).
Open the DepthOfField10.1_2010.sln file and let it Upgrade the VC++ Tools and Libraries to v120.
Edit the Project Properties -> VC++ Directories:
For all configurations and the Win32 Platform, set it to:
Executable Directories: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x86
For all configurations and the x64 Platform, set it to:
Executable Directories: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86;
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x64
If you were using VS 2015, then you also need to add the blog version of DXERR and remove the legacy DirectX SDK version of dxerr.lib from the project. A quick hack of DXUT is needed to resolve the ASCII/UNICODE differences. This is needed because VS 2015 includes some C99 related standard library changes that fail to link with the old version of strsafe.h used to build the legacy DirectX SDK.
Once this is done, it builds and runs as is.
Note: Most of the Direct3D 10 samples in the legacy DirectX SDK make use of the old Effects (FX) system. There's a Direct3D 11 version of Effects available, but the HLSL compiler support for Effects is officially deprecated. See Effects for Direct3D 11.
If the problem is happening in our own projects, then likely you have mis-configured the FXC command-line for building that .fx file.
I'm looking at using the TeeChart library for Compact Framework AND Full Framework (3.5) I'd like to know if there are any differences in API to support both platforms from the same source? (my current charting lib, different vendor, is not supported on Win32)
Question for Steema Software: I can't find the teechart.pocket.dll in the evaluation download? are you dropping CFNet support? where to get a cf eval dll?
No API differences between both versions, except for those specific to each platform.
Compact Framework and ReportingServices assemblies are currently not being included in the production version of TeeChart unless future customer demand signals its need. That's because CF doesn't work with .NET Framework 4.0 and 4.5 which means it doesn't compile with Visual Studio 2010 and Visual Studio 2012. In the meantime we are prepared to work with any customer that demands the assemblies on a case by case basis to certify its compatibility and featureset. In the meantime, you can use the assemblies included with previous versions.
I found some information regarding Windows 8 Metro and c++/cli. Windows 8 Metro does not support c++/cli.
However I am having trouble finding explicit documentation that states whether Windows 8 Desktop supports c++/cli (the linked question is not explicit enough IMO). Does Windows 8 Desktop support c++/cli?
Please make sure to provide a link to your relevant source.
Windows 8 does not support C++/CLI.
It is the other way around, the support does not come from the Windows team (they did not ship a compiler) but from the Visual Studio team. Each Visual Studio version has a list of supported platforms that your application can target if you use that version of Visual Studio to build your app.
So does Microsoft support writing C++/CLI apps for Windows 8 Desktop? The answer is yes if you use the right version of Visual Studio*. Does the support come from Windows? The answer is no.
*You can continue test and provide support to your customers even without Microsoft's support to you, for example you can write C++/CLI code in Notepad then compile it using the cl.exe from VS2012 Express for Windows 8. There's really nothing to prevent this use case to work, despite Microsoft's statement that VS2012 Express for Windows 8 does not support desktop development (and I don't think there's any reason why Microsoft should provide support on this use case with VS2012 Express for Windows Desktop out there) .
The Windows 8 Desktop supports everything that Windows 7 supported. C++/cli included. There really isn't much that talks about this, but here is a link to VS 2012 support for C++/cli which implies the same thing.
Question from a Linux/Mac developer: I have compiled a 32-bit .dll (release flavor) under Windows 7 using Visual Studio 2010. Should this .dll be usable under all flavors of Windows 6 (a.k.a. Vista, if I'm not mistaken)?
Many thanks and RTFMs appreciated,
John Clements
In general: yes.
All current versions of the .Net framework run on both Vista and Win7.
Note that if you make calls into the native platform, either directly or via the Windows API Code Pack, you could have portability problems if you use functions available only in Win7. But for just straight .Net development, you should have no issue in running on any supported version of Windows.
Yes, the dll format didn't change for Windows 7. Only thing to remember is that if it's a .Net dll, the target system must have the proper .Net installed or the appropriate C/C++ runtime.
You're supposed to #define the _WIN32_WINNT macro to tell what version of Windows you want to support. The default in the SDK that ships with VS2010 is 0x600 which avoids you ever linking to an API function that is not available in Vista. So, yes, you're probably good to go.