Operating systems are different and they handle software installation in a different fashion. Next-next installers are a very Windows thing. Other OS-es handle adding software quite differently. Do not belive that there is a magic pill that will help you distribute your software in a uniform way (well, apart from Steam maybe). At the very least, users of different OS-es *expect* that adding software will be done differently.
the classic is to use Windows Installer (a.k.a. .msi)
many companies use WIX, an abstraction over WI. It is free, and also open source, if you care about that.
some use InstallShield
many use the Nullsoft installer (NSIS) - also free and open source
you can write your own from scratch, it is relatively easy (if you have even modest Win32 experience). Time consuming if you haven't written an installer before.
On Linux dstributions - there is no such a thing as universal installer They all go out of their way to make it difficult to provide binary packages that can survive more than a few releases/years, let alone compatible across distributions. There are alternatives to WI, such as .deb and .rpm, but I would recommend against going that route if you depend on other packages being installed, as packages get split or renamed over the years. Most software that works even after decades is to basically statically link against everything and do not depend on OS filesystem layout besides ~ and your installation directory. Also, limit your use of OS libraries to the bare minimum - prefer building all dependencies on your own and bundle them with your app (as you would on Windows). Plan to include a shell script that will force the loader to use your libraries instead of the system libraries (as they will be built with a different compiler version, etc).
If you want graphical installer for Linux - there used to be the Loki installer, but I'd recommend to try Steam and link to their libraries. It will be easier for both you and your users.
I've never owned a Mac, so I can't say anything about that.
For game development, C# + WinForms is the easiest way to integrate with native code (if you're writing an editor or just need a lot of P/Invoke).
For business applications, C# + WinForms isn't dead either. Visual Studio's WinForms designer makes it easy to very quickly write small utility applications, which is ofthen what IT departments would do, especially for state institutions.
WPF can achieve impressive visuals, but suffers from internal Microsoft power struggels (the guys that do tools vs the guys that do the OS). If it is updated to more easily support newer DX withouth the Windows Runtime, I guess it will be used even more.
All the flashy news are for web technologies, and Microsoft try to follow with ASP.NET MVC. Last time I wrote a site with MVC, I was impressed with how easy it was. You get ORM + template engine + great debugging experience. Recentely, they've been going to the world of "stuff happeing automagically if you follow The Convention". Whether or not you like that is a matter of preference. In my opinion, their web stack is a good piece of technology, and it has its following.
ASP.NET WebForms is dated technology. People hate on it too much, IMO. Still, a few years ago it was VERY popular, and lots and lots of sites were written using it. Which means they'll have to be supported. Also, some .NET CMS-es were based on WebForms. I guess they've isolated those parts over the years, but that means even more sites depend on WebForms. Again, my own opinion is that this is not a very good implementation, but the idea of reusable components is a good one.
When it comes to databases... I haven't done that in years. What most people around me use these days are either ORMs that are related to the framework/language of their choice, or a very small population of very vocal hipsters that use alternative storages, like MongoDB. IMHO most sites can do with SQLite, but many people want to engineer big and complicated setups for sites with less than a thousand visitors a month. My advice would be: get familiar with basic SQL syntax. You don't need to be a wizard or anything, but if you use an ORM, you will have to go down to SQL when debugging. Also, regardless of what database engine you use, the basic SQL is mostly the same. When you are at it, take some time to look at MongoDB - it is the most popular alternative storage in my dev circle.
In summary: .NET ain't dead yet. If you work with .NET, you'll be most likely doing business apps/sites or supporting such. This is not bad, as it is usually a very stress-free job that pays well.
If you want to do web, forget two years of studying. Start writing simple sites ASAP and learn on the go. Blog would do - the ability to write blog posts & comments in a site is a nice test to see if you can handle security (logging in, setting up https), storage (can go with simple files, any SQL engine, or the new document storages), templates and client-side programming. When you do a veeeery simple blog post, do one-pager site (e.g. https://onepagelove.com/) and make it mobile-friendly with responsive design. If you pull these off, you're ready for 99% of web development jobs. Plus, you've immediately hireable, as you have something to show for your words.
IIRC, an variable of an empty struct would also be at least one bit, beacuse the stardard says every variable must be addressable (via the & operator). I do not remember if it is one bit or whatever the compiler decides, though.
x86 can and does process 8 bits via the original A, B and C registers, this is used for casting between ints of different size, IIRC. Also, nothing stops you from using bitwize operations to store and extract bits from an unsigned integral type. As others have said, vector<bool> is supposed to do that for you; the implementation depends on unique values being a power of 2; you store with bitwize | (result is assigned to storage) and extract with bitwize & (result is tested flag if present).
It explains what Valve recommends. Mostly, SDL2 libraries handle most of the OS/DirectX stuff, and OpenGL replaces Direct3D. Also, one advise I've found on my own: if your game is not too complex, you can do almost all the work on Windows. Booting to a Linux distro just to make sure it compiles and runs properly has been my strategy so far for small personal projects.