Live data from Hacker News

I fixed Windows native development

marler8997.github.io

61–70 of 406 posts

Re: I fixed Windows native development

#61

Is this post AI-written? The repeated lists with highlighted key points, the "it's not just [x], but [y]" and "no [a] just [b]" scream LLM to me. It would be good to know how much of this post and this project was human-built.

Perhaps people have mimicked the style because LLMs have popularized it and clearly it serves some benefit to readers.

Life imitates art, even when that art is slop

Re: I fixed Windows native development

#63
For big C++ projects, the .vsconfig import/export way of handling Visual Studio components has worked well for the large teams I'm on. Tell someone to import a .vsconfig and the Visual Studio Installer does everything. Only times we've had issues is from forgetting to update it with components/SDK changes.

Re: I fixed Windows native development

#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. Remember patching openSSL when heartbleed came around (libssHELL).

Visual studio is a dog but at least it's one dog - the real hell on windows is .net framework. The sheer incongruency of what version of windows has which version of .net framework installed and which version of .net your app will run in when launched... the actual solution at scale for universal windows compatibility on your .net app is to build a c++ shim that checks for .net beforehand and executes it with the correct version in the event of multiple version conflict - you can literally have 5 fully unique runtimes sharing the same .net target.

Re: I fixed Windows native development

#65
post #28
post #12

Earlier quoted context omitted.

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

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

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.

Re: I fixed Windows native development

#67
Say what you want about coding agents, when the cost of writing code goes to near-zero, the cost of wrangling tools becomes a much bigger fraction of development effort. This is an amazing opportunity to address long-standing frictions.

Re: I fixed Windows native development

#68
post #28

Earlier quoted context omitted.

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

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?

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.

Re: I fixed Windows native development

#70

While this is great - Visual Studio installer has a set of "command-line parameters" for unattended installs. You can then build a script/documentation that isolates your specific requirements and workloads: https://learn.microsoft.com/en-us/visualstudio/install/use-c... Had to do this back in 2018, because I worked with a client with no direct internet access on it's DEV/build machines (and even when there was conne…

[dead]
Post reply on HN