W64devkit – Portable C and C++ Development Kit for x64 Windows
nullprogram.com
nullprogram.com
The way I "sync" my dev environment between machines: Copy a single compressed directory by whatever means - usb stick, some server, whatever - to a new machine, extract it, and I'm done.
I also rarely update my dev tools, my arm gcc cross compiler is apparently from 2017 - and it works just as well today as it did then, no reason to update.
That's the packed size though, which is indeed pretty small. Unpacked is 540mb which is roughly the same as mingw-w64 which comes with MSYS2, just with added make/boost etc. Installation is (a bit) simpler than MSYS2 though, the possibility of just downloading/extracting/usbale is really nice. Though for actual longer term applications this could get annoying quickly with respect to updating (just downloading again?), installing additional packages (not possible?).
https://github.com/asveikau/clwrapper
It is a hackish solution and I would be weary deploying it to customers. New versions of VS would break it. It was good enough for my own use on 1-person projects though.
Reading through the previous discussion, I think the biggest consideration for something like this is whether Mingw-w64 suffices for your needs.
https://news.ycombinator.com/item?id=23292161
The issue isn't whether the tools are capable enough, but whether they integrate well enough with the platform and any other dependencies your project may have. I'd be interested to hear from people who are using MinGW or Mingw-w64 on purpose. What works well, and what doesn't?
With Visual Studio Community, Microsoft has made its tools broadly accessible. However, if all you want is a compatible linker, this is in a lot of ways a regression from Visual C++ Express, which is no longer offered. Indeed, the compiler and linker used to be bundled in the freely available platform SDK. As someone responsible for testing C and C++ APIs, the licensing and packaging in Visual C++ 2019 will be a much bigger hassle than in previous versions.
https://devblogs.microsoft.com/cppblog/introducing-the-visua...
Also I am not sure about certain c++ libraries that are useful for writing COM code, like ATL or its successors.
Is there no modern equivalent of good old win32.hlp?
However your best best is to find some MSDN CD/DVD image that still uses CHM and use that. Also note that the Win32 documentation apparently went through a ton of conversions and in the process some entries were lost (in that the API docs are there but the docs are missing parts).
The official docs site has PDFs for download but those are automatically generated from the section you are reading and they have cutoff points that feel arbitrary (so you can't go to the highest section for Windows and download all docs). You can find a PDF for the Win32 API reference for handling windows[0] but it contains only the reference and you need to go to another place for the guide (in comparison the win32.hlp and MSDN documentation had both).
These PDFs are also awful, they look like printed websites, they have zero grouping (the sidebar bookmarks are per header file) and the bookmarks are even broken (clicking on one will move you +/- 1 page off).
The "source code" for the docs is apparently on GitHub[1] but it looks like a conversion to markdown and not the real source. Though theoretically it could be possible to parse it and create a proper CHM (or whatever) file out of it since the docs are there [2]. Sadly it only includes the reference and not the guides (but they might be somewhere else on that GitHub account, there are 2300+ repositories, so good luck finding it :-P).
[0] https://docs.microsoft.com/en-us/windows/win32/api/_winmsg/
[1] https://github.com/MicrosoftDocs/sdk-api/
[2] https://github.com/MicrosoftDocs/sdk-api/blob/docs/sdk-api-s...
It's a work in progress, but will probably yield something that can be processed into various useful formats.
Kind of a contentious point being made here.
I come from an era where we would disable Visual Studio's intellisense because it was cripplingly slow on large projects. I prefer Emacs, and in the time between then and now I went from using etags, even on unreal engine projects, to global, and have landed on ccls.
_Only_ ccls was able to reliably comprehend and suggest dereferenced members; global could, occasionally, but usually not. And ccls is incredibly fast; even on my Pinebook Pro it seems to never be an undue burden.
And ccls is just _loaded_ with other handy productivity features. Not using it, or an equivalently powerful tool, is to choose to reduce your productivity.
Too bad it can't easily be done in suche a simple way on *nix systems.
apt install build-essential
This looks like a very opinionated choice these days, as Vim seems more kind of a specialty item (UNIX/Linux specific). Why not, say, VSCode?
Git wasn't on the menu because it included perl, which is orders of magnitude smaller than VSCode's dependencies.
So of the somewhat popular crowd, vim seems like a good fit, and the project creator uses it regularly, if I remember his blog correctly.
Not sure what the current equivalent of a small, dependency-free native Windows editor would be. Notepad++ is popular, but has the scintilla engine as a requirement and seems to require Visual Studio for building, not make. Guess the same is true for a lot of other candidates.