Live data from Hacker News

I fixed Windows native development

marler8997.github.io

311–320 of 406 posts

Re: I fixed Windows native development

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

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

Re: I fixed Windows native development

#312
post #55
post #45

Earlier quoted context omitted.

[flagged]

Well, let's say this is the world view of all companies about open-source software. Then what happens. If people "tend to not give crap" about licenses, all the nice guarantees of GPL etc also disappear.

Very weird comparison.

GPL was made in response to restrictive commercial licensing. Yes is uses the same legal document (a license): but is made in response!

So is propriety seizes to exist, then it's not a problem GPL also seizes to exist.

Also: it's quite obvious to me that IP-law nowadays too much. It may have been a good idea at first, but now it's a monster (and people seem to die because of it: Aaron Swartz and Suchir Balaji come to mind).

Re: I fixed Windows native development

#313

Earlier quoted context omitted.

Real humans don't speak in LinkedIn Standard English

"LinkedIn Standard English" is just the overly-enthusiastic marketing speak that all the wannabe CEOs/VCs used to spout. LLMs had to learn it somewhere

Humans don't, but cocaine does speak "LinkedIn Standard English".

Re: I fixed Windows native development

#315
As someone who has been doing Win32 development for literally decades, I'm not particularly convinced this is a problem that needs more code to solve. You don't need VS to get the compiler (which is available as a separate download called something like "build tools", I believe); and merely unpacking the download and setting a few environment variables is enough to get it working. It's easy to create a portable package of it.

Re: I fixed Windows native development

#316

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…

CMD.EXE is fine. I'd rather use bash than the abomination that is PowersHell.

Re: I fixed Windows native development

#317

Earlier quoted context omitted.

you know why LLMs repeat those patterns so much? because that's how real humans speak

Real humans don't speak in LinkedIn Standard English

Real humans write like that though. And LLMs are trained on text not speech. Maybe they should get trained on movie subtitles, but then movie characters also don't speak like real humans.

Re: I fixed Windows native development

#318
post #64

Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager…

> python in another realm here as well uv has more of less solved this (thank god). Night and day difference from Pip (or any of the other attempts to fix it honestly). At this point they should just deprecate Pip.

I have never experienced issues with pip, and I’m not sure it’s whether I’m doing something that pip directly supports and avoiding things it doesn’t help with.

I’d really love to understand why people get so mad about pip they end up writing a new tool to do more or less the same thing.

Re: I fixed Windows native development

#319
I am not exactly bounding with eagerness and time to contribute to an open source project but the few times I have looked I stop at the "how do I configure my dev environment to match" step.

Just give me a VM. Then you will know, and I will know, every facet of the environment the work was done in.

Re: I fixed Windows native development

#320

Earlier quoted context omitted.

> 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 (htt…

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 t…

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.

Post reply on HN