Hacker News new | past | comments | ask | show | jobs | submit login
W64devkit – Portable C and C++ Development Kit for x64 Windows (nullprogram.com)
87 points by zdw on Sept 25, 2020 | hide | past | favorite | 28 comments

I do this for any tool I can - it's without a doubt my preferred way of distributing software. Call me old school or crazy, but I absolutely hate: - Auto updaters (just STFU, stop nagging, I never want programs going online unless I explicitly ask it) - Installers or package managers - stop polluting my harddrive with garbage everywhere - Non-local config directories/registry/etc - when I `del` or `rm` a dir I want ALL traces of that program gone.

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.

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



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?).

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.


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.


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.


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.

> 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?

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...

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.

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.

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.

Is it? A week ago I've downloaded a gcc4.7(?) ARM toolchain, unpacked it, set CROSS_COMPILE and build some software for mine ARM board. It was quite easy.

    apt install build-essential
Or did you mean something else?

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:


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 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.

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.

This is really commendable, way to go. The post raises some terrific discussion points around the stability, security, and portability of a development toolkit.

Instead of state, it should have tutorial and example to build command line and a game etc.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact