
W64devkit: A Portable C and C++ Development Kit for Windows - pmarin
https://nullprogram.com/blog/2020/05/15/
======
simfoo
_My unusual application of Docker here is no exception. Most software builds
are needlessly complicated and fragile, especially Autoconf-based builds.
Ironically, the worst configure scripts I’ve dealt with come from GNU
projects. They waste time doing useless checks (“Does your compiler define
size_t?”) then produce a build that doesn’t work anyway because you’re doing
something slightly unusual. Worst of all, despite my best efforts, the build
will be contaminated by the state of the system doing the build._

Completely agree, Autoconf needs to die. C++ builds don't _need_ to be complex
and fragile, even if many environments are supported. Just use a minimal CMake
build and resist the urge to implement "clever" things in it.

~~~
pornel
If you do only minimal things, you will have fragile builds. The hacks are
there not because people like adding complex code for no reason, but they're
scars from broken builds.

For example, requirements for what has to be static and what dynamic are
different on Linux (distros want unbundling) and macOS and Windows (you can
link to handful of things that ship with the OS). macOS is especially
annoying, because if you're not careful, you'll link dynamically to homebrew's
non-permanent locations. `find_package` doesn't do the right thing without
clever non-minimal things around it.

~~~
CJefferson
The problem is, autoconf does a terrible job of supporting Windows, and
actively rejects patches which would improve things (for example, it does very
badly with spaces in filenames, which are common in Windows, for example
"Program Files" and "My Documents")

~~~
vbezhenar
"My Documents" are called "Documents". You can also install your application
into user directory, something like
"C:\Users\Vladimir\AppData\Local\YourApplication", so no spaces necessary
unless user name contains spaces (not sure if it's even possible).

I'm not claiming that spaces should not be supported, but you can live without
them.

~~~
fomine3
It's shame that it still needs workaround in 2020.

------
josephg
I've been eyeing off the new zig compiler for making portable binaries. I'm
tempted to set it up for cross-compiling a native nodejs library I develop.
The work Andrew Kelley has done to make zig cross compile is phenomenal.

[https://andrewkelley.me/post/zig-cc-powerful-drop-in-
replace...](https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-
gcc-clang.html)

~~~
txdv
Don't you need C++ for native node nodejs libraries?

~~~
josephg
Nah the napi API is pure C:

[https://nodejs.org/api/n-api.html](https://nodejs.org/api/n-api.html)

------
fsloth
Advice to young devs: If you don't have a good professional reason why you
absolutely need to use gnu tools on windows, and you have no technical reason
not to use Visual Studio, use Visual Studio. It's good enough, and for me,
even good.

~~~
jmiskovic
Your advice would have more weight if you provided some arguments. GNU tools
are also good enough, and this kit seems like a lot easier way to get started
with your C lab exercise than installing Visual Studio and getting lost in it.

I dislike Visual Studio because to set things up you have to compare online
screenshots to your settings and click around multiple tabs of configurations.
In the end you (as beginner) don't know what libraries get included and if it
will work on another computer. GNU tools are text-driven, so easier to
replicate and to reason about.

~~~
marcoperaza
The GNU tools are not fully compatible with the Windows ABI and they don't
support some important Windows features. There are great reasons to use the
GNU tools, like compiling unix programs that do not otherwise target Windows.

But you are swimming upstream if you use the GNU tools for general Windows
development. Windows is a complex, integrated system that has evolved over a
long period of time and is very different from unix-like operating systems.
The peculiarities that exist in MSVC and associated tools are not just the
whimsies of Microsoft devdiv engineers and product managers, but often tie in
to operating system functionality. If you try to develop Windows applications
with mingw, you will eventually hit weird problems and errors that simply
would not exist if you used Microsoft's toolchain.

If you want an alternative to Microsoft's compiler, then consider llvm, which
is aiming for full ABI compatibility and even produces PDBs (though I'm
skeptical that they're as complete as the ones generated by Microsoft's
tools). But the compatibility is incomplete, so ymmv.

~~~
danieldk
I wonder how long this stays true though.

Microsoft seems to aim for deep integration of Linux in Windows per WSL. They
even showcased that they are working on Wayland support for WSL, which would
enable using Linux GUI applications directly on Windows.

We may soon get at a point where Linux applications feel as native on Windows
as native Windows applications (which use quite a variety of toolkits anyway),
as the integration deepens.

Now WSL still uses larger distribution images. But very little holds them from
supporting thin Linux images with just the necessary dependencies that
launches in Windows as any other application.

Using LLVM for ABI compat is a good tip though!

~~~
qppo
WSL is more a solution for users that want to have Linux software on Windows.
It's not a solution for developers that want to target Windows, which is what
I take this thread to be about.

I don't know if it will ever come with a vanilla Windows Home edition install
but somehow I doubt that.

~~~
strmpnk
WSL is available on Home (including WSL2, you just don’t get access to all of
hyper-v even if it’s running).

~~~
qppo
Sorry if I was unclear, I meant as in "installed by default" on a user's
machine.

~~~
danieldk
Not yet, but I think it is very likely that in the future installing a Linux
distribution from the store will automatically install/enable WSL. Micro-
distributions with a specific applications are only a small step from there.

I don't see what they have to lose. Windows is still used widely in business.
But their lock-in has drastically reduced with the rise of iOS, Android, and
web apps. Making Windows more attractive as a platform for developers to
deploy applications, even if it is through the WSL subsystem will make Windows
as a platform more competitive to these other ecosystems.

I am currently writing scientific software. But we have stopped building
Windows versions, since these programs work great with WSL and it is far less
effort than building these applications separately with Visual C++.

~~~
qppo
I write software that's used by human beings in businesses and _building_ for
Windows is trivial compared to maintaining additional docs and training
material for managing a WSL install on users machines.

I'm currently in a weird spot with the software I distribute because the
majority of the users "know enough to be dangerous" but aren't software
engineers/IT professionals. We want them running code and using Linux like a
pro, but there's a lot of training/documentation overhead just for our *nix
builds and the friction to getting that up and running for WSL is daunting.

Luckily MS understands B2B native more than anyone else so I'm hopeful they'll
have a solution eventually, but I'm not holding my breath until then.

------
fefe23
My biggest problem with gcc for Windows is that libstdc++ does not support
threads. There is a workaround with a pthread compatibility layer but that is
just horrible and awful. I can't bring myself to do that.

This has been an open issue for literally years now. But apparently nobody
cares enough to fix it.

~~~
matthewbauer
My understanding is that while pthreads don't work, c++11 threads are
supported.

~~~
fefe23
If only that were so! At least up to gcc version 9.3 it does not work. I will
try gcc 10 soonish but I don't have high hopes.

The whole reason I installed a cross compiler to Windows is so I could cross
compile some search engine code I wrote that uses C++ threads. But if you have
a copy of the header and run-time files from Visual Studio (there is a free
edition of that now) you can actually use clang to cross compile for Windows
from Linux just fine, including C++ threads.

~~~
spacechild1
gcc on Windows uses winpthreads for C++11 threads, which works just fine (it
automatically links with libwinpthread)... I can basically use the same
threading code for all platforms (except the stuff that is necessarily
platform dependent and therefore not part of C++11). I should note that I use
msys2. So I'm wondering what you are missing?

That being said, I often use my own STL like mutex class which wraps SRWLock
on Window and pthtead_mutex_t on Linux/macOS.

~~~
fefe23
The reason (for me) to use msys in the first place would be so I can create
binaries that do not depend on obscure DLLs like winpthread. If depending on
3rd party DLLs was no problem, I could have used Cygwin.

Also, as I heard it, winpthread combines the warts of windows threads with the
warts of pthreads, doing neither justice.

~~~
spacechild1
You can link both libstdc++ and libwinpthread statically if you want. Both
libs come with msys2, so I wouldn't really call them obscure third-party
DLLs... In practice, threading is not a problem at all with gcc on Windows. I
agree, however, that libwinpthread is not the most efficient implementation
(that's why I roll my own), but for most purposes it's good enough.

------
dvfjsdhgfv
Note that it's "portable" in the Windows sense, i.e. you can unzip it and it
should work. It has nothing to do with cross-platform portability.

~~~
zoomablemind
Portable in a sense of have it on a flash-stick in your pocket, all working
without need to install.

I once created such a pocket-development setup, throwing in Fossil [0] for
version control and project tracking, Notepad2 (notepad2-mod) [1,2] for
editor. Actually, Git can also be set up for pocket, which then brings the
whole MinGW for this.

I wanted to fit Geany [3] for more like IDE experience. It's also Scintilla
based, but needed GTK, so I chose not to bother back then.

Android NDK can be set up this way too. It packs LLVM, so here it is another
capable compiler to do the lab-work.

Just learn to program in portable C way, that is know the platform-specific
ways to do certain things (threads, network) and #ifdef it properly. However
this is a whole other story about how this sort of portability could be
handled.

[0] [http://fossil-scm.org](http://fossil-scm.org)

[1]
[https://xhmikosr.github.io/notepad2-mod/](https://xhmikosr.github.io/notepad2-mod/)

[2] [http://www.flos-freeware.ch/notepad2.html](http://www.flos-
freeware.ch/notepad2.html)

[3] [http://geany.org](http://geany.org)

------
dominicl
Regarding msys2, for those who use GitHub the big news is that since 7 days
msys2 is by default installed on the windows-latest target of GitHub actions:
[https://github.com/actions/virtual-
environments/commit/c6114...](https://github.com/actions/virtual-
environments/commit/c61145f2de073f08e8ce5316e31cdf2a5e0ddaa5)

I'm doing all local development on Linux and since msys2 is there by default
getting the windows compile done is a bliss. Just need to bring msys2 to your
path and all the rest (git, g++, linking, etc) is the same as in your Linux
env. E.g. this is my prefix for the cross-build
[https://gist.github.com/dominicletz/5e50c49aa1bf30d2485f5bec...](https://gist.github.com/dominicletz/5e50c49aa1bf30d2485f5bece177c82f)

~~~
stinos
This has been the case for a long time on Appveyor which was is one of the
reasons we stick to it for CI. Do you happen to have experience with it? I'm
wondering if and why we should switch to github actions, for the repositories
we have on github anyway.

~~~
dominicl
Haven't tried Appveyor so can't compare experience. I'm a travis convert came
for Windows with my open source project. Just glancing at the Appveyor pricing
chart I guess my open source project would only get one parallel job on
Appveyor while on GitHub Actions it's unlimited.

------
matthewbauer
Note that this kit is using MinGW. That's not necessarily a bad thing but
comes with all of the caveats you can read about. I wish the author mentioned
it because it should definitely be a choice you make deliberately.

------
jcelerier
In the same vein I've been using [https://github.com/mstorsjo/llvm-
mingw](https://github.com/mstorsjo/llvm-mingw) \+ lld + cmake + ninja on
windows for over a year with great success, dev experience is much better than
with MSVC.

------
seventh-chord
If you install visual studio, and then copy together all the files it adds to
%PATH%, %INCLUDE% and %LIB%, and create a .bat script to set environment
variables to point to your copies of these files you get a fully portable
first-class compiler for windows with needed headers and libraries, zipped up
to around 75 mB. Add remedybg as a debugger, and your editor of choice, and
you never have to touch visual studio again.

~~~
Koshkin
Or you could just get the "build tools":

[https://visualstudio.microsoft.com/downloads/#build-tools-
fo...](https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-
studio-2019)

~~~
seventh-chord
Which you need the visual studio installer for, which only works half of the
time. Just to check if it still is as bad as last I tried, I downloaded the
build tools and started the installer. Currently downloading 1 GB of data...

Edit: To nobodies surprise, the installer still doesn't work. The command line
shortcuts it installs fail to properly set up the path. At least it looks like
they are trying to print a sensible error message in the command prompt now
though. Still not quite sure how they manage to fail this badly though.

------
mbeex
Mmmh Docker: It's still a problem to run Docker and VMware Workstation
peacefully in parallel on Windows. The one prefers Hyper-V, the other the
opposite:

[https://www.kauffmann.nl/2019/03/04/how-to-install-docker-
on...](https://www.kauffmann.nl/2019/03/04/how-to-install-docker-on-
windows-10-without-hyper-v/)

[https://blogs.vmware.com/workstation/2020/01/vmware-
workstat...](https://blogs.vmware.com/workstation/2020/01/vmware-workstation-
tech-preview-20h1.html)

This has to change first (the links giving some kind of hope).

~~~
speedgoose
If you don't want Hyper-V, you can run easily run docker in virtualbox with
boot2docker, using docker-machine. Or you can setup a docker linux vm in
vmware.

~~~
noisem4ker
>docker in virtualbox with boot2docker

It comes packaged as Docker Toolbox.

~~~
speedgoose
It's legacy though. But I also notice that docker-machine isn't really updated
anymore.

------
txdv
[https://github.com/libgit2/libgit2/pull/5507](https://github.com/libgit2/libgit2/pull/5507)
I think git will get a stand alone git command line client in the future with
no need for perl and such

------
heresie-dabord
For the OP, many projects are a "mess" that don't agree with his opinions.
"bash is a mess, git is a mess, cygwin feels wrong..."

And M-Windows is a pristine example of orderly genius?

I support his right to his opinions. But here he is, running Docker and a pile
of opinions to build himself a portable C&C++ env on M-Windows. (To use gcc,
no less.)

Software in general is a mess. But that doesn't prevent great tools from being
developed. There's a reason for the success of GNU and FOSS.

~~~
txdv
What is M-Windows?

~~~
heresie-dabord
You are probably being facetious about this facetious short-form for the
Redmond product.

------
Jaruzel
Worth pointing out that this is a dockerfile, and not something you can just
unzip-and-run on Windows.

~~~
lucideer
The 5th sentence in the linked article is:

> _For most users, the value is in the 78MiB .zip available in the “Releases”
> on GitHub._

immediately followed by:

> _It’s “portable” in that there’s no installation. Just unzip it and start
> using it in place._

