W64devkit – Portable C and C++ Development Kit for x64 Windows(nullprogram.com)
nullprogram.com
W64devkit – Portable C and C++ Development Kit for x64 Windows
https://nullprogram.com/blog/2020/09/25/
28 comments
Not quite the same, but Stephan Lavavej, who maintains the C++ standard libraries at Microsoft, maintains a fairly good version of MinGW weighing in at 45MB. Build scripts are available on Github
https://nuwen.net/mingw.html
https://github.com/StephanTLavavej/mingw-distro
https://nuwen.net/mingw.html
https://github.com/StephanTLavavej/mingw-distro
weighing in at 45MB.
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?).
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?).
For anyone that hasn't needed openssl on windows: The package manager is an exceptionally nice feature.
I got some response to my question if Microsoft could allow redistribution of the cl.exe compiler: https://developercommunity.visualstudio.com/idea/975508/allo...
Regarding the issue of a special command prompt.. I haven't touched it in years and probably not up to date with the latest vs, but I had a small project that would scan the registry for VS installs and try to find cl.exe.
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.
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.
Have you used this with the newer VS versions? Starting from 2017 and on, they're using a private registry hive for storing configuration, so you have to first know where to load the private hive from before you can use it.
Thanks for the heads up. Maybe I will try it sometime and update that project.
There are two interesting aspects to this. The first, which I initially thought was the point, is cross compiling programs for Windows using Mingw-w64 (a fork of MinGW) in a container. Actually, this is just used as a dependable way to build the second, which is a portable archive of a Mingw-w64 development environment; portable in the sense that you extract, add to PATH, and use without any other installation required.
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.
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.
Aren't the compiler, linker and build tools still available seperately? They just bundle them differently now.
https://devblogs.microsoft.com/cppblog/introducing-the-visua...
https://devblogs.microsoft.com/cppblog/introducing-the-visua...
Whereas some of the previous packages were freely available, the build tools now require a Visual C++ license, as I understand it. If you aren't eligible for Visual C++ Community, and you don't have Visual C++ Professional (or equivalent), you can't use them.
Not sure how huge an issue it is, but in the past I noticed that mingw does not support Structured Exception Handling (SEH). I think clang on Windows may have made some progress there.
Also I am not sure about certain c++ libraries that are useful for writing COM code, like ATL or its successors.
Also I am not sure about certain c++ libraries that are useful for writing COM code, like ATL or its successors.
> The distribution does not have WinAPI documentation. It’s notoriously difficult to obtain and, besides, unfriendly to redistribution.
Is there no modern equivalent of good old win32.hlp?
Is there no modern equivalent of good old win32.hlp?
No, though depending on what you do, win32.hlp is still valid (you'll need to replace the Win10 winhelp stub with a real version from an earlier version of Windows though since Microsoft hasn't released a Win10 version of winhelp).
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...
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...
See https://github.com/MicrosoftDocs/win32
It's a work in progress, but will probably yield something that can be processed into various useful formats.
It's a work in progress, but will probably yield something that can be processed into various useful formats.
Good old evil Microsoft did documentation way better than anyone else. Since turning good, Microsoft's documentation is an ugly mess. I miss evil Microsoft.
> Use the included ctags to generate a tags database (ctags -R), then jump instantly to any definition at any time. No need for that Language Server Protocol rubbish. This does not mean you must laboriously type identifiers as you work.
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.
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.
Very refreshing to see this kind of initiative in this era of containers and endless dependencies.
Too bad it can't easily be done in suche a simple way on *nix systems.
Too bad it can't easily be done in suche a simple way on *nix systems.
i've been doing a SDK for quite some time with the libs & compiler I need for https://github.com/ossia/score - features statically-built Qt 5.15, Clang/LLVM 11, ffmpeg and a few other related to audio (so quite bigger). Only way to stay sane with win32 development. If anyone is interested:
https://github.com/ossia/sdk/releases/tag/sdk16
https://github.com/ossia/sdk/releases/tag/sdk16
I don't find the Windows SDK too bad, but I tried React Native for Windows and building each simple app took up 1GB+ of space.
| w64devkit -> Vim : powerful text editor
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?
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?
This is supposed to be a minimal, stand-alone dev kit. VS Code is large, wants you to download half the internet, brings in lots of dependences (a browser, a language runtime, graphics libraries etc.).
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.
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.
SciTE (also based on scintilla) has worked for me as a good, light-weight Notepad replacement.
Vim works offline, VS Code and many of its plugins do not.
Instead of state, it should have tutorial and example to build command line and a game etc.
This is really commendable, way to go. The post raises some terrific discussion points around the stability, security, and portability of a development toolkit.
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.