I'm using VS2019 for C and C++ under win7
I would like to build (x32bit or x64bit?) binaries which will run correctly under all later OS, including Windows Server 2019
Do I have to set WINVER/_WIN32_WINNT ? Does this concern the building env or the target env ? and if yes, with which value ?
https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=vs-2019
On Windows, unlike Linux, the building environment is almost entirely irrelevant. When linking, you don't link against the libraries in the build environment, but you link against the Windows SDK.
Strictly speaking, you probably don't need WINVER and _WIN32_WINNT. They mainly help to hide functions from <windows.h>, so you don't end up calling functions that you didn't intend to call.
But there are a few rare structures where the layout changed over Windows versions, in which case you want to use the old layout. Windows 10 supports both layouts; typically by inspecting the .cb member of the structure. You set this field to sizeof(type), and this size will depend on the WINVER variable.
Related
Are the dynamic runtime libraries for Visual C++ (more specifically 2008) part of the Windows OS nowadays? I noticed that at least on Windows 8 you no longer need to ship these with your application or have the user install the redistributable package from Microsoft.
Is this true? If so, for what Windows versions and for what versions of Visual C++ does this apply to?
No, they've never been part of the Windows distribution. Deploying them yourself is a hard requirement.
It certainly may seem that they are. Starting with msvcrt.dll in the system32 directory, it has the same name as the C++ runtime dll in Visual Studio versions prior to VS2002 (VS6 and earlier). It is however a private copy of the CRT that is used by Windows executables. And protected by the File System Protection feature in Windows, preventing old installers from destroying the operating system.
It certainly often works by accident. There are many programs that need the Microsoft CRT so it isn't unlikely that the user has run an installer before that got the DLLs installed. Clearly you cannot depend on that common accident.
Similarly for Windows 8, the pre-installed Microsoft.VCLibs.110 package matches the package you need for a Store app written in C++. But that's for the same reason as above, Microsoft Store programs were also built with VS2012, just like yours. What's going to happen in the upcoming VS2013 is a bit muddy right now, we'll know soon.
In my opinion, the answer would be both: Yes and No.
Yes: More recent Windows OS are generally shipped with VC runtimes pre-installed (along with more recent versions of the .NET framework). It is because Microsoft uses the latest/newer Visual Studio before they release VS to the public (or even to MSDN subscribers). If not this way, whenever you install some application (legacy application or some downloaded application), the setup would anyway install the required VC++ runtime. Another way is through automatic updates.
No: In case where none of the above mentioned rules applies. Or, when the VC runtime shipped with a new service pack or a patch. You might have developed your application with newer patch/SP, and that must be installed (as Side-by-Side, of course).
I have built a program in Microsoft Visual Studio 2005 and it works fine.
The problem I am having is the the machine it needs to be used on is running windows 98. As far as I can tell I need to install the re-distributable for vc++. Can I install the re-distributable on windows 98 or is there a way to make it work on windows 98?
Yes, apps compiled with VS 2005 work perfectly fine on Windows 98 and Me. I've run several of them myself, and keep VS 2005 around and installed for precisely this purpose. Version 2005 of the CRT redistributable is supported as far back as Windows 98.
The trick is that you must compile the application for the multi-byte character set (MBCS). It will not work when compiled as Unicode, which is the default project setting. Windows 9x platforms do not support Unicode without some extra help. You should be able to change the project settings and be fine, but if you've written your code to assume Unicode, then you'll have a problem.
This is why you need to use generic character types and functions defined in tchar.h, rather than their wide character equivalents that are preferred for Unicode builds. Always define strings using the TCHAR type (or LPTSTR or LPCTSTR types), which is conditionally defined to wchar_t or char, as appropriate. Use string manipulation functions that begin with _tcs..., rather than the ones specific for wide or narrow characters. Make sure that when you call functions, you always call the generic typedef'ed versions, rather than the ANSI- or wide-specific ones that end with an A or a W suffix.
It may be a lot of work to go back and fix this if you haven't done it from the start. If that's the case, you might look into the Microsoft Layer for Unicode on Windows 95/98/ME Systems, which provides an abstraction layer that allows you to call Unicode functions on the legacy Windows 9x operating systems where they are not natively supported.
Beyond Unicode/MBCS, the only thing to watch out for is that you're not calling any functions that didn't exist in the Win32 APIs way back in the Windows 98 days. You can't trust what the online MSDN documentation tells you for the "minimum supported client version" anymore, because Microsoft is no longer supporting Windows 98. All of the SDK docs say that the minimum supported version is Windows 2000 now, and you know that's not correct. The entire API was not introduced as late as W2K. In order to get accurate information, you'll need to obtain an old version of the SDK documentation; what came with your installation of VS 2005 should be fine. The information there goes back at least as far as Win 98, if not 95 (I don't remember exactly).
For instances where you want to call functions that didn't exist back in Windows 98 when you're running on newer systems where they are available, you'll need to take extra care to call them dynamically, rather than adding them to your application's DLL import table (what the linker generally does for you automatically). That means defining function pointers yourself, and using the LoadLibrary and GetProcAddress functions to call them. It's not fun, but it does work.
Alternatively, you can configure the linker to "delay load" the libraries (check your project's properties). This is much more convenient, but obviously you'll need to ensure that you only call the functions that are available on your target operating system, otherwise the application will crash.
Either way, the GetVersionEx function will tell you everything that you need to know about the current host operating system so that your code can take different paths (calling newer functions if available, or falling back to older ones if not) depending on the environment. This allows you to support new functionality on new systems, while still retaining whatever degree of support for legacy operating systems is appropriate. You'll find a lot of if statements in the code base when this is done right. :-)
Yes, you can http://www.microsoft.com/download/en/details.aspx?id=3387 (Microsoft Visual C++ 2005 Redistributable Package (x86))
Supported Operating Systems: Windows 2000 Service Pack 3, Windows 98, Windows 98 Second Edition, Windows ME, Windows Server 2003, Windows XP Service Pack 2
Did you check the system requirements? According to this link, Windows 98 should be fine.
There is more than distributing CRT with your application. All functions you use in the program must be available in Windows98. For all the functions you find on MSDN you will find a "Minimum supported client". This is tricky ...
To get over CRT issue you can statically link the application (/MT linker option). Will result in a bigger binary but will work.
I'm modifying a large C++ project whose first release was Windows 7-only to work on Vista and XP.
The main work will be to change the W7 API calls to use GetProcAddress at runtime (to avoid static linking with methods that are not available on the other platforms), and so I'm wondering if there are any tools that can help identify which calls need to be changed -- hopefully by examining the C++ code itself.
Failing that, would it be best to try building the project against an older Windows SDK? -- for example: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6510
#define WINVER 0x501
Now everything that is newer than Windows XP will cause a compilation error.
Replace everything that causes an error until none remain.
If you have some sed-fu, you can probably write a filter that directly finds all #if WINVER > 0x501 blocks in the windows headers, but for me, this is a bit out of my scope :-)
I would open your binaries using the depends.exe tool (either from your VS install or from here) under WinXP and Vista to see which functions can't be statically linked under these OSes. These would be the functions which your binary is using, but which are missing in older releases of the OS. You'll have to deal with them somehow: either implement them by yourself, replace them with something else or disable some of the functionality of your app.
I have been working on a VS 2005 project and have successfully generated an exe file which works fine on my system. However when I tried to run it on some other pc it didnt run. It throws up the error message "the system cannot run the specified program". Can someone tell me how to make my code immune to such message i.e. system independent?
platform used: Windows XP, VS 2005
the extension of all my code files is cpp but I know only c and thats what I wrote inside them.
I have seen before exe created on Windows Sp1 not working on SP2 and problems such as that.
This should help you perhaps.
I've seen this when you run on a different version of Windows that doesn't have some DLL you depend on. The easiest thing to do is statically link the C runtime (that's the usual culprit) and use depends.exe to see if there are any others.
You will almost certainly need to create an installer that installs your executable and any non-OS-included DLL's it relies upon. It is not always possible or desirable to statically link all dependencies. You can in many cases simply copy the DLL's to the same folder as the executable.
By default, even the C/C++ standard library is provided by a DLL. While the MSVCRT.DLL used by VC++ 6 is included with the OS since later editions Win95, the MSVCRT required by VS2005 is not included with XP installations (other versions I do not know). The run-time support is included VC redistributes package. You may need to arrange for your installer to include that installation, or you could be more selective is you know your dependencies.
Some Win32 API calls if you are using them are dependent on the OS version (check the documentation), but if you built and rin it on XP, it should normally work of any subsequent version of Windows. You need to define various API version macros if you want to extend support to earlier versions of Windows (which seems unlikley).
You might need to install the VS 2005 redistributables on the other machines, depending on how you have compiled your program.
What's in MS Visual C++ runtime library? I mean, I googled it, and I always found things like help, app xxxx gives me MS Visual C++ runtime library error, with no explanation.
I thought that Windows C runtime libraries come with Windows? Not with VC++? Thanks.
EDIT:
First, thanks for answers. I thing now I have bad idea of runtime libraries in windows. I mean, the first part, that Windows internally has its win32 API and so, that's OK, I knew it. Also, that Win32API are from kernel and user parts.
But I always thought that functions like GDI are accessed as DLL (which I still believe they are). But I thought even functions like printf and so are in some windows file.
So, am I right, when I know get it that "simple" functions like printf need to be linked directly and than use only Kernel part of OS directly, and more sophisticated Windows API functions are linked as dlls, therefore ARE NOT distributed with compiler but with OS? And they subsequently access Kernel?
I mean, lets say GDI, I tell it to draw picture, it makes all the hard work in user mode and than call kernel function which puts it all in framebuffer?
And last thought, why is this even solved this way? I mean, if VC++ runtime is just layer between C and WinAPI, why cant VC++ call directly WinAPI?
This is an oversimplification, but it will give you the gist. The MSVCRT is a set of DLLs that implements parts of the C++ language. Functions like printf, memcpy and the like are implemented in these DLLs.
Every program that is compiled with a particular compiler and dynamically linked to the C++ runtimes must somehow have the correct version of the CRT binaries on the target machine. As a result, applications that ship to end users are often (usually?) also shipped with a package of these DLLs. This package is called a "redistributable" (or "redist"), and there is a different one for every combination of exact compiler version and target platform. For example, there are seperate and distinct redists for each of the following:
MSVC 10, 64-bit windows
MSVC 10, 32-bit windows
MSVC9, 64-bit windows
MSVC9 SP1, 64-bit windows
et cetera.
Yes, Windows usually "comes with" some version of the CRT. However, it comes with the version(s) that it needs in order to run the apps that shipped with Windows. If Windows and all it's apps were compiled in MSVC8 SP2 and your app is compiled in MSVC10, the CRT you require won't be present on the box simply because it's running Windows.
This is why its common practice to ship apps along with redists.
EDIT:
By way of Houdini like magic, I predict your next question will be "where do I get the redists?"
The answer is, from MicroSoft. Try a google search for "msvc 9 x64 redist" and you will find:
http://www.microsoft.com/downloads/en/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&displaylang=en
A brief answer would be that the MSVS C/C++ runtime implements functions like malloc/free, stdio, iostream and some c++-stuff like dynamic_cast and exception handling. These differs between versions of visual studio, so there are different runtimes for different versions.
Windows ship mostly with a C API (the Win32 API) which rather different from the C/C++ standard library. The MSVS C/C++ runtime calls into this API to allocate memory, etc etc.
(I suppose some of the applications included with Windows are written with MSVS and in C++, so they do include the MSVS runtime for that version.)
Also, the runtime changes as new Visual Studio versions are released. A Windows release lasts much longer than that.
They are the libraries that implement the C and C++ standard library functions. Standard functions such as printf are implemented in these libraries.
The core Windows libraries only provide interfaces to system calls, i.e. the Win32 API, since that is all you need to build a full-featured Windows application. The VC++ libraries are mostly wrappers around this API, and are analogous to the glibc library on Linux.
As an example, malloc from the C library might in turn use the VirtualAlloc API to allocate memory.
Programs compiled with Visual C++ require a "runtime" - this is a bit of code that handles application startup/shutdown, memory allocation/deallocation, support for reading and writing files, etc.
This is not part of the operating system, and not part of the final application - Because all C++ applications can share it, by default the runtime is a separate installation.
In addition, each version of Visual C++ has its own runtime installer, because with each version there are slight differences and improvements in the way all this works. There are also different verisons of the runtime for different platforms (e.g. x86 and x64)
Hence, there are a number of "Visual Studio XXXX runtime installer (YYY)" downloads available from Microsoft, where the XXXX is the visual studio version (2005, 2008, 2010, etc), and YYY is usually "x86" or "x64".
Most applications that need the runtime will automatically install it if needed, so generally end-users are not very aware of these redistributables.