Win32 Visual Styles backwards compatibility? - winapi

When I embed the Visual Styles manifest in my program like this:
// Embed visual style XML manifest
#pragma comment(linker, \
"\"/manifestdependency:type='Win32'" \
" name='Microsoft.Windows.Common-Controls'" \
" version='6.0.0.0'" \
" processorArchitecture='*'" \
" publicKeyToken='6595b64144ccf1df'" \
" language='*'\"" \
)
// Link common controls library
#pragma comment(lib, "ComCtl32.lib")
Does that mean my program will only run on Windows XP? Or if visual styles are not on the computer will they just use the operating systems default style? I ask because I enabled visual styles in my program that I am developing with Visual Studio 2008 and I want to know what is the earliest version of Windows it can be run on. Should I check WINVER to see if they are running a version that supports visual styles? If so, what version number should I check for in the preprocessor. Another thing I would like to know is, without visual styles, what is the lowest version I can run my program on?

Does that mean my program will only run on Windows XP? Or if visual
styles are not on the computer will they just use the operating
systems default style?
The latter is true and the documentation defines the exact behaviour (emphasis is mine):
If you want your application to use visual styles, you must add an
application manifest or compiler directive that indicates that
ComCtl32.dll version 6 should be used if it is available.
Another section in the same page describes some things you should watch out for in terms of backwards compatibility: Making Your Application Compatible with Earlier Versions of Windows. On visual styles, it states:
Much of the visual style architecture is designed to make it simple to
continue to ship your product on earlier versions of Windows that do
not support changing the appearance of controls.

This is not a problem. The manifest simply tells Windows that you want version 6 of the common controls DLL. The one that's stored in the side-by-side cache (c:\windows\winsxs), not the legacy one stored in c:\windows\system32. The side-by-side cache is a DLL Hell counter-measure, it can store different versions of DLLs with the same name.
The manifest has no effect on earlier versions of Windows, those versions didn't know anything about manifests so don't know to look for them.

Related

How do you install Microsoft Visual Studio 2017 with minimal features?

The reason I ask is I want a small installation size and I only use the product for writing code for school work. I will not need 3rd party software, web capability, or integration with other software and applications.
In a comment now you requested for "command line to run the web installer in a certain predefined way say only download and install visual studio core editor and.net components". BTW, the recommendation including installing .NET components was a part of my original answer- now I splitted the answers, one for minimal install and this one for what you requested secondly, including .NET Visual Studio components:
The command line to install core and .net minimal is:
vs_xxxx.exe --layout %CD%\vs2017offline --lang en-US --add Microsoft.VisualStudio.Workload.ManagedDesktop
(set your individual downloaded .exe name for 'vs_xxxx.exe', my downloaded name was for example 'vs_enterprise__873301792.1489161815.exe')
The new installer for Visual Studio gives you a lot of flexibility about which components to install. By default, you'll have no additional features selected. VS will only install what it calls the Visual Studio core editor, which is described as:
The Visual Studio core shell experience including syntax-aware code editing, source code control and work item management.
With this, you'll get support for TextMate language grammars (you can install any you want), but you won't have the overhead of installing any language services or project types. So far, VS is a glorified editor; this minimal install will take 600MB. If you're looking for something smaller, you should probably consider Visual Studio Code instead.
Workloads
The first tab of the new VS installer is the Workloads section. This gives you some pre-packaged feature groups targeted at specific development platforms. There are separate categories of workloads (Windows, Web, Gaming, and Other) and taking the Windows category for example, there are 3 different workloads available: UWP, .NET Desktop (like WinForms and WPF), and C++ Desktop development.
Each workload has required and optional features. Some of the optional features will be selected by default as they are "recommended". You can slim down by unselecting these.
If the workloads are too heavy-handed for you, you can use...
Individual components
On this tab, you can piece together any single components you want. If a workload seems too large, you can see what components it would install, then go to this tab and pick the smaller set you would like.
Note that some components do have dependencies (sometimes numerous), and the installer will show you all of the dependent packages added. If you try to remove them, it will notify you of dependent components that will also be removed.
You have the following alternatives:
1.
Minimal Visual Studio: Start the standard Visual Studio web installer, and select nothing, then you get the minimal installation for only the development environment (IDE), especially editor.
2.
If this is too big for you, you can use something similar to Visual Studio, for example, you can Visual Studio Code editor or you can use SharpDevelop as an alternative to Visual Studio. Open Source and smaller footprint.
You can work with every editor on the commandline using "csc.exe myhomework.cs" (CSharp compiler).
3.
The solution with smallest footprint (without Visual Studio):
Just use the editor you are used to, even notepad is possible: Depending on your .NET version and Windows directory, the compiler can be found for example here:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe
or
C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe
The 64 bit versions of those you get in the mirrored folders "Framework64" instead of "Framework"..
Normally you would like to download the whole .NET SDK (developer pack) additionally, but for a single homework, csc.exe might be enough.
Here is the developer pack for .NET 6.2 framework (Visual Studio uses that as kind of a kernel too).
https://www.microsoft.com/en-us/download/details.aspx?id=53321

How to deploy a Win32 API application as an executable

How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).

How to use GCC with Microsoft Visual Studio?

I am creating a very large project (a few thousand lines) and so would rather not use Notepad++. An IDE would make it so much easier. I have experience with Microsoft Visual Studio and love it. Is there some easy way to use Cygwin's GCC from within Microsoft Visual Studio?
Alternately, are there any other good Windows IDEs for GCC besides NetBeans and Eclipse? (I hate both of them with a passion.)
There are several ways to go here:
Option 1: Create a Custom Build Tool
Visual Studio 2005 and newer will let you register custom build tools. They tell the IDE how to transform files of one form (e.g. a .cpp file) into another form (e.g. an .obj file).
So far as I know, no one has done this yet for GCC. And, doing it yourself requires writing COM code, which is probably too deep a pool to dive into just for a single project. You'd have to have a compelling reason to take this project on.
You then have to manually adjust each project to tell it to use the custom build tool instead of the default, since you're using a file name extension (.cpp, probably) that Visual C++ already knows about. You'll run into trouble if you try to mix the VC++ and g++ compilers for a single executable built from multiple modules.
On the plus side, if you were looking to start an open source project, this sounds like a good one to me. I expect you'd quickly gather a big user base.
Option 2: Makefile Project
Start Visual Studio and say File > New Project.
In the Visual C++ section, select Makefile Project
Fill out the Makefile Project Wizard:
Build command line: make
Clean commands: make clean
Rebuild command line: make clean all
You can leave the Output (for debugging) field alone if you've named your executable after the project name and it lands where Visual Studio expects to find it.
Leave the rest of the fields alone unless you know what they are and why you want to change them. As an example, you might choose to pass a -D flag on the Preprocessor definitions line to get separate debug and release outputs. If you know you want this, you know how to set it up, so I'm not going to make this long answer even longer in order to explain it.
You'll be asked the same set of questions for the Release build. If you want to bother with separate debug and release builds, you'd make any changes here.
Having done all this, you still have to create the Makefile, and add a make.exe to your PATH. As with the debug vs. release question, going into that level of detail would push this answer off topic.
As ugly as this looks, it's still easier than creating custom build tools. Plus, you say you need to port to Unix eventually, so you're going to need that Makefile anyway.
Option 3: Cross-Platform Development
You say you want to port this program to Unix at some point, but that doesn't mean you must use GCC on Windows now. It is quite possible to write your program so that it builds under Visual C++ on Windows and GCC/Makefiles on *ix systems.
There are several tools that make this easier. One very popular option is CMake, which is available as an installation time option in newer versions of Visual Studio. There are many alternatives such as SCons and Bakefile.
Clang
You can use the Clang compiler with Visual Studio to target Android, iOS, and Windows.
If you are targeting Android, you can use the Clang/LLVM compiler that ships with the Android NDK and toolchain to build your project. Likewise, Visual Studio can use Clang running on a Mac to build projects targeting iOS. Support for Android and iOS is included in the “Mobile Development with C++” workload. For more information about targeting Android or iOS check out our posts tagged with the keywords “Android” and “iOS”.
If you are targeting Windows, you have a few options:
Use Clang/LLVM; “Clang for Windows” includes instructions to install Clang/LLVM as a platform toolset in Visual Studio.
Use Clang to target Windows with Clang/C2 (Clang frontend with Microsoft Code Generation).
GCC
If your project targets Linux or Android, you can consider using GCC. Visual Studio’s C++ Android development natively supports building your projects with the GCC that ships with the Android NDK, just like it does for Clang. You can also target Linux – either remotely or locally with the Windows Subsystem for Linux – with GCC.
Check out our post on Visual C++ for Linux Development for much more info about how to use Visual Studio to target Linux with GCC. If you are specifically interested in targeting WSL locally, check out Targeting WSL from Visual Studio.
Source: https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/
I'm from the future.
I keep (poking at) a C/C++ toolchain using Visual Code on Win/Lin/Mac and MinGW installed from Choclatey.
(This was done for my sanity - install GDB and GCC however you want)
I've run it with GCC and GDB with IntelliSense using MS's own weird JSON makefiles.
Someday, someone (you?) will write a Gradle or Python script to generate these; for now the examples online in the docs seem to work.
It seems to require three types of JSON thing;
a single IntelliSense configuration for the whole workspace
a Debugging Configuration entry for each binary you want to debug
these can invoke the build tasks
a Build Task per-artifact
I don't think that there's a "require" or "dependency" thingie-mah-bob; sorry

Why do 3ds Max plug-ins need to be built with a specific version of Visual C++?

The requirements listed in the 3ds Max SDK state that plug-ins for 3ds Max 2011 must be built with Visual C++ 9.0 (Visual Studio 2008).
If I create a DLL with a different version of Visual C++, won't the binary be identical? Is this simply a matter of choosing the right compiler settings?
What problems will I run into if I try to build a plug-in using Visual C++ 2010 (Visual Studio 2010)?
I don't know specifically for 3ds Max, but the usual reason is the C Runtime library. If the host application uses the DLL version of the CRT, then plugins will also need to use the same version.
Otherwise, imagine the case where your plugin creates some memory using malloc(), and passes it to the host application, which uses it and then calls free(). If your plugin and the host application are using different CRTs, the host's call to free() will fail or crash because it wasn't the host's CRT that malloc()ed that block of memory.
The binary won't be identical but the binary interfaces should be, which is what you need.
The reason you can't use VS2010 is because it is not yet production quality. They think you should wait for VS2010 SP1 at a minimum.
You think they are just being obstinate and stubborn, eh? Ruining all your fun. They have reasons. Good ones.
Because of bugs like this:
https://connect.microsoft.com/VisualStudio/feedback/details/565959
I use both visual studio 2008 and 2010 for plugin development.
Only difference I've seen is that the user need the vs c++ runtime version for 2010\2008.
But there might be pitfalls - but I have not encountered any problems with it yet.
C++ doesn't have a standardised binary interface. The compiler "mangles" each symbol name (i.e. each function or static data) to include information about namespaces and signature, so that namespaces, argument overloading, &c. can work. Each compiler is free to decide how to do this. Different MSVS compiler versions do name mangling in different ways, so in general you can't link a C++ library compiled with 2005 and a library compiled with 2008 together: this includes loading a 2008 DLL from a 2005 executable (for example). You can do this if the interface between the libraries is C, as long as the relevant functions are marked with extern "C" to prevent name mangling. And in practice the differences are not always that great: for example, I never had trouble using VS2005 SP1 to compile a library for 3ds Max 9, which supposedly requires VS2005 with no service pack.
Microsoft is trying to fix this incompatibility, so in VS2010 they introduced an option, so VS2010 can produce binaries compatible with VS2005 programs or VS2008 programs (maybe some earlier versions too, I forget). If you have to create a plugin to work with multiple 3ds Max versions, and you don't get caught out by any VS2010 bugs, this is probably a good option. Also, the Intel C++ compiler has a mode where it produces binaries that are compatible with an MSVS version of your choice, which might be a better option for you if it's for hobby use or you can afford the slightly expensive price tag. (They achieve this by copying the way MSVS does name mangling.)

What programming language/compiler/libraries should I use to create an app that runs on Windows XP without any additional software?

I need to create a basic app to check the availability of components and if necessary download them to any computer running Windows XP or above. Which language (preferably free or VS 2010) should I use to create such an application which can run without requiring any frameworks installed beforehand?
could you please elaborate? By static library, do you mean a dll that should reside alongside the exe? or do you refer to available dlls in windows/system32? Also, will programs compiled using this method require the 'Visual C++ Redistributable'?
When C++ executable links to a static library, then the linker includes the library's object code in the same file as the EXE. The result is a single *.exe file, and the library does not need to be shipped as a separate *.dll.
The DLLs in windows/system32 are typically O/S files. They're O/S-specific. You may/must/do not ship/redistribute these files (Microsoft does). Your EXE (or e.g. the C run-time library to which you have statically linked) depends on (requires) some of the functions which are exported from these DLLs. These O/S DLLs tend to be backward-comptible, so that if you target the O/S API which exists on XP, your code will also run on Vista.
I'm guessing that by 'Visual C++ Redistributable' you mean "the Visual C run-time library", whose DLL filename is something like msvcrt80.dll. This is what I talked about in my first paragraph: if you choose the build option (available under project/properties) to statically link to the C run-time library, then the code you require is statically linked into your EXE and you don't require (don't run-time link to) this DLL.
Visual C++ 6 with MFC. If you use a later version of Visual C++ then your Windows XP targets will need libraries for them.
Edit: Comments pointed out that the CRT and MFC library can be linked staticly even in later versions. That is right and I forgot.
While not specifically designed for this, I recommend InnoSetup for setup bootstrappers. It doesn't require any libraries, provides functionality for common setup requirements and has PascalScript to extend it. There are a lot of plugins available, and you can do anything left with a custom script (basically like Delphi). PascalScript can import API functions, so you can really do anything. With InnoCallback, you can even get callbacks from the API - I used this to bootstrap a lot of MSI setups into a single package using the MSI API.
If you download it, get the QuickStart Pack, which includes a good editor and the InnoSetup preprocessor.

Resources