I fixed Windows native development

Posted by deevus 17 hours ago

I fixed Windows native development(marler8997.github.io)

678 points | 329 commentspage 4

ivanjermakov 14 hours ago|

One day I decided to port my text editor to Windows. Since it depends on pcre2 and treesitter, these two libraries had to be provided by the system.

In the span of ~2hrs I didn't manage to find a way to please Zig compiler to notice "system" libraries to link against.

Perhaps I'm too spoiled by installing a system wide dependency in a single command. Or Windows took a wrong turn a couple of decades ago and is very hostile to both developers and regular users.

okanat 13 hours ago||

I think providing purely-functional libraries as system dependencies that's tied to the whole tool chain at the time was the wrong decision by the Unix world.

The system libraries should only ship system stuff: interaction with the OS (I/O, graphics basics, process management), accessing network (DNS, IP and TLS). They should have stable APIs and ABIs.

Windows isn't hostile. It has a differnt paradigm and Unix (or more correctly usually GNU/Linux) people do not want to give up their worldview.

PCRE is basically only your apps's dependency. It has nothing else to do the rest of the operating system. So it is your responsibility to know how to build and package it.

lmz 14 hours ago|||

If you depend on a library and can't figure out how you would compile against it, it's probably better for the end user that you don't make anything because you'll still need to package it up later unless you link statically.

the__alchemist 13 hours ago|||

I suspect the pitfall is how you or the zig compiler is linking. Unless you're involving things which vary by OS like hardware interaction, networking, file systems etc, you should not, with a new Lang in 2026, need to do anything special for cross-platform capabilities.

ivanjermakov 12 hours ago||

My understanding that "linkSystemLibrary" abstraction in build.zig only holds for Unix systems. And this in turn makes it impossible to build my program on Windows without modifying the build script.

forrestthewoods 11 hours ago||

System wide dependencies is fundamentally an awful idea that is wrong and you should never ever do it.

All dependencies should be vendored into your project.

pyrolistical 6 hours ago||

This is the answer. I don’t know what is the best practise but for windows the easiest solution is to put the DLL in the same directory as the exe

jacobgorm 7 hours ago||

I’ve found that just installing LLVM, CMake and Ninja is enough to get started developing on Windows for most things C/C++.

int0x29 9 hours ago||

Last I checked the license for the headless toolchain requires that a full licensed copy of Visual Studio be installed somewhere. So I think this violates the license terms.

A bug got opened against the rustup installing the headless toolchain by itself at some point. I'll see if I can find it

edit: VSCode bug states this more clearly https://github.com/microsoft/vscode/issues/95745

xvilka 15 hours ago||

Please add also the support for the clang-cl[1][2].

[1] https://clang.llvm.org/docs/MSVCCompatibility.html

[2] https://clang.llvm.org/docs/UsersManual.html#clang-cl

reactordev 15 hours ago||

And here I was messing with MingW64…

This is fantastic and someone at Microslop should take notes.

Borg3 15 hours ago|

Exacly.. I avoid Visual Studio.. I try to build everthing using Mingw..

xvilka 15 hours ago||

Clang is the better alternative to MinGW because it can use standard Windows libraries and avoids the need for additional runtime.

dwroberts 14 hours ago|||

Can you actually do cross compilation (on Linux host to win64 binary) with clang in the same way as MingW does out of the box though?

okanat 14 hours ago||

No. You cannot even do direct compilation on the same host and target with clang only.

LLVM doesn't come with the C library headers (VCRuntime) or the executable runtime startup code (VCStartup).Both of which are under Visual Studio proprietary licenses. So to use Clang on Windows without Mingw, you need Visual Studio.

jezek2 14 hours ago||||

I use MingW without any extra libs (no msys), it just uses the ancient msvcrt.dll that is present in all Windows versions, so my programs work even on Windows 2000.

Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.

okanat 14 hours ago||

You can use Mingw-w64 UCRT or CLANG environments that come with MSYS2.

Compared to older Mingw64 environments those link with the latest UCRT so you get almost the same style executable as Visual Studio.

The only difference for C is that it uses Mingw exception handling and global initialization code, and it uses Itanium ABI for C++.

jezek2 14 hours ago||

But that's the point, I don't want the same style executable as Visual Studio. Having to distribute bunch of DLLs and having worse compatibility is pretty bad.

A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.

reactordev 12 hours ago||

yeah, you can get away with this now a days because Git itself installs 2/3rds of the things you need anyway. You just need to finish the job by getting the package and putting the binaries in your git folder. Bam! mingw64, clang, what ever cc you need. It all links to standard windows stuff because you have to tell the linker where your win32.lib is. But this is true no matter the compiler, it's just Visual Studio supplies this in some god awful Program Files path.

reactordev 14 hours ago||||

Just msys2 it all

delta_p_delta_x 14 hours ago||

MSYS2 is horrible. It brings a massive runtime environment and is a bad idea to foist on users.

michaelsbradley 13 hours ago||

Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)?

The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.

reactordev 13 hours ago|||

He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…

okanat 12 hours ago||

MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw.

Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.

delta_p_delta_x 12 hours ago|||

> MSYS2 just enough development environment

Doesn't it come with `pacman` too?

okanat 6 hours ago|||

You need to update stuff somehow. `pacman` is a beautifully simple package manager. It covers the complexity just enough without going overboard.

michaelsbradley 12 hours ago|||

Yes, it’s wonderful.

1718627440 9 hours ago||||

A repacked Cygwin is one environment, but the default uses the UCRT from Microsoft.

okanat 6 hours ago||

They all have to use MSVCRT or UCRT to stay compatible with other Windows programs and APIs like COM. And AFAIK nobody has developed a C library that's purely dependent on Win32 system APIs (it is possible just really hard). The difference is that Cygwin is trying to create this semi-isolated Unix environment to programs to think they are running under a complete Unix system like Wine does.

MSYS2 is there to just provide the basics so you can develop programs that are Windows native but use some of the tools that have really strong Unix dependence like shells or Make. They depend on the existence of syscalls like `fork` or forward slash being the directory seperator.

michaelsbradley 12 hours ago|||

I think you’re underestimating or discounting the work the MSYS2 team put into their layered environments mechanism:

https://www.msys2.org/docs/environments/

okanat 6 hours ago||

I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2]

Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays.

The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals.

[1] "Cygwin POSIX emulation engine", https://packages.msys2.org/base/msys2-runtime [2] https://github.com/msys2/MSYS2-packages/tree/master/msys2-ru...

delta_p_delta_x 12 hours ago|||

It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.

michaelsbradley 12 hours ago||

Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for.

It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.

michaelsbradley 12 hours ago||

Example:

I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10.

Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.

delta_p_delta_x 11 hours ago||

> MSYS2 CLANG64

I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]:

  > (gci Env:PATH).Value.Split(';') | sort
  > clang-21.exe --version
  clang version 21.1.2 (https://github.com/llvm/llvm-project.git b708aea0bc7127adf4ec643660699c8bcdde1273)
  Target: x86_64-w64-windows-gnu
  Thread model: posix
  InstalledDir: C:/Users/dpdx/AppData/Local/Microsoft/WinGet/Packages/MartinStorsjo.LLVM-MinGW.UCRT_Microsoft.Winget.Source_8wekyb3d8bbwe/llvm-mingw-20250924-ucrt-x86_64/bin
  Configuration file: C:/Users/dpdx/AppData/Local/Microsoft/WinGet/Packages/MartinStorsjo.LLVM-MinGW.UCRT_Microsoft.Winget.Source_8wekyb3d8bbwe/llvm-mingw-20250924-ucrt-x86_64/bin/x86_64-w64-windows-gnu.cfg

[1]: https://github.com/mstorsjo/llvm-mingw

michaelsbradley 9 hours ago||

I think you have it backwards, but I may misunderstand what you're saying.

I'm certain I haven't misunderstood the point of MSYS2's CLANG64 and other environments.

> These binaries themselves are built to run in the MSYS2 environment

I'm not sure if you're referring to the toolchain binaries or the binaries one produce's with them.

The CLANG64, etc. environments are 100% absolutely for certain for building software that can run outside of any MSYS2 environment!

You can, of course, build executables specifically intended to run inside those environments, but that’s not the primary use case.

> (gci Env:PATH).Value.Split(';') | sort

I don't want to use PowerShell or Cmd.exe when doing dev stuff on Windows. I want to do CLI work and author scripts in and for modern Bash, just like I would for Linux and macOS. I want to write Makefiles for GNU make, just like...

Now, sometimes there are bumps and sharp edges you have to deal with via `if [[ -v MSYSTEM ]]; then`, similar in Makefile, cygpath conversion, template/conditional code in sources, and so on. But that's a small price to pay, from my perspective, for staying in the same mental model for how to build software.

reactordev 5 hours ago||

All msys2 does is give you a unified BSD experience and toolchain for compiling applications for any architecture and platform. Windows included.

There. I think that sums it up.

1718627440 9 hours ago|||

MSYS2 UCRT also uses the native Windows libraries (aka. UCRT).

ww520 14 hours ago||

I was just setting up a new machine and was setting up the Rust environment. The very first thing rustup-init asked was to install Visual Studio before proceeding. It was like 20-30gb of stuff installed before moving forward.

This tool would be a great help if I knew beforehand.

tehologist 4 hours ago||

I don't understand, just use scite editor with tcc. About a couple of megs download, no install required and your apps will run on everything from win 98 to linux with wine. And if the answer is c++ support then you get all the pain you deserve using that cursed language

whatever1 11 hours ago||

“Build Requirements: Install Visual Studio”.

You’ve never experienced genuine pain in your life. Have you tried to change the GCC compiler version in Linux?

kristjansson 11 hours ago|

   apt install gcc-11

   CC=gcc-11 make

If it’s not packaged and you’ve got to build it yourself, Godspeed. An if you’ve got to change libc versions…

Pay08 11 hours ago||

GCC is surprisingly simple to build, fortunately.

kristjansson 10 hours ago||

Yeah it’s not too bad, but it does pull away from “so trivial it fits in a flippant HN comment”

Pay08 9 hours ago||

Does it? Admittedly, it has been a while but I don't remember it differing too much from the good old ./configure && make paradigm with a few flags to both commands.

kristjansson 9 hours ago||

It’d fit in a comment, but not a flippant one ;)

ddtaylor 8 hours ago||

As someone who is out of the loop on Windows development, is this related to the Windows Driver Kit (WDK, I think it used to be DDK)? That's a certain type of hell I don't wish upon most.

dundarious 13 hours ago|

I'll just keep using Mārtiņš Možeiko's script, portable-msvc.py, that this tool is based upon. It does everything this does, except a lock file and the autoenv. I'm not particularly interested in the former, and definitely not the latter.

https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cd...

More comments...