Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I fixed Windows native development

marler8997.github.io

Post reply on HN
Print view View original

171–180 of 406 posts

Re: I fixed Windows native development

#171

Post by hiccuphippo »

Aurornis wrote: post #162

Looking at the script: > curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/download/v2026... No thanks. I’m not going to install executables downloaded from an unknown GitHub account named marler8997 without even a simple hash check. As others have explained the Windows situation is not as bad as this blog post suggests, but even if it was this doesn’t look like a solution. It’s just one other insta…

I know Jonathan Marler for some of his Zig talks and his work in the win32 api bindings for Zig[0], they are even linked from Microsoft's own repo[1] (not sure why he has 2 github users/orgs but you can see it's the same person in the commits).

[0] https://github.com/marlersoft/zigwin32 [1] https://github.com/microsoft/win32metadata

Re: I fixed Windows native development

#172

Post by vitaminCPP »

delta_p_delta_x wrote: post #148
jezek2 wrote: post #75

I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs. I don't understand how open source projects can insist on requiring a proprietary compiler.

There are some pretty useful abstractions and libraries that MinGW doesn't work with. Biggest example is the WIL[1], which Windows kernel programmers use and is a massive improvement in ergonomics and safety when writing native Windows platform code. [1]: https://github.com/microsoft/wil

I fail to see why this would not work with gcc if it works with clang. The runtime?

Re: I fixed Windows native development

#173

Post by michaelsbradley »

okanat wrote: post #140
reactordev wrote: post #117

Earlier quoted context omitted.

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

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…

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

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

Re: I fixed Windows native development

#174

Post by Alifatisk »

> It’s so vast that Microsoft distributes it with a sophisticated GUI installer where you navigate a maze of checkboxes, hunting for which “Workloads” or “Individual Components” contain the actual compiler. Select the wrong one and you might lose hours installing something you don’t need.

I have a vague memory of stumbling upon this hell when installing the ldc compiler for dlang [1].

1. https://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_u...

Re: I fixed Windows native development

#175

Post by michaelsbradley »

delta_p_delta_x wrote: post #155
okanat wrote: post #140

Earlier quoted context omitted.

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…

> MSYS2 just enough development environment Doesn't it come with `pacman` too?

Yes, it’s wonderful.

Re: I fixed Windows native development

#176

Post by dotancohen »

Aurornis wrote: post #162

Looking at the script: > curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/download/v2026... No thanks. I’m not going to install executables downloaded from an unknown GitHub account named marler8997 without even a simple hash check. As others have explained the Windows situation is not as bad as this blog post suggests, but even if it was this doesn’t look like a solution. It’s just one other insta…

You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script.

Just like those complaining about curl|sh on Linux, you are confusing install instructions with source code availability. Just download the script and read it if you want. The curl|sh workflow is no more dangerous that downloading an executable off the internet, which is very common (if stupid) and attracts no vitriol. In no way does it imply that you can not actually download and read the script - something that actually can't be done with downloaded executables.

Re: I fixed Windows native development

#177

Post by delta_p_delta_x »

shevy-java wrote: post #168
delta_p_delta_x wrote: post #158

No one should use any of these weird Frankenstein monstrosities in 2026. And a batch script? :( PowerShell exists. Install: - contrary to the blog post, the entirety of Visual Studio, because the IDE and debugger is *really damn good*. - LLVM-MinGW[1] Load the 'VSDevShell' DLL[2] for PowerShell, and you're good to go, with three different toolchains now: cl.exe from VS clang-cl.exe—you don't need to install this sepa…

LLVM-MinGW sounds external to Microsoft though. I think the blog focused on in-Microsoft solutions. And I am not sure the "contrary to the blog content" is valid - compared to Linux, the Microsoft stack is much more annoying to install. I installed it, but it was annoying to no ends and took ages. Good to know LLVM works on windows too though.

> compared to Linux, the Microsoft stack is much more annoying to install.

Not really. It's just different. As a cross-platform dev, all desktop OSs have their own idiosyncracies that add up to a net of 'they are all equally rather bad'.

Re: I fixed Windows native development

#178

Post by gaigalas »

Windows Native is fine. People in that space are comfortable with it.

What needs to be fixed is the valley between unix and windows development for cross-os/many-compiler builds, so one that does both can work seamlessly.

It's not an easy problem and there are lots of faux solutions that seem to fix it all but don't (in builds, the devil is in edge cases).

Re: I fixed Windows native development

#180

Post by delta_p_delta_x »

michaelsbradley wrote: post #170
michaelsbradley wrote: post #163

Earlier quoted context omitted.

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.

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.

> 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
Post reply on HN