Live data from Hacker News

I fixed Windows native development

marler8997.github.io

361–370 of 406 posts

Re: I fixed Windows native development

#361

Earlier quoted context omitted.

The Build Tools installer first installs the Visual Studio tool to select the workloads you want as well.

Let's say I want to compile a helloworld.cpp with no build tools installed yet. What is the minimal winget command to get everything installed, ready for : cl main.cpp ? Ps: I mean a winget command which does not ask anything, neither in command line, nor GUI ? Totally unattenfed.

The winget installer just downloads vs_buildtools.exe and runs it, which first installs vs_setup.exe and then that one prompts you for the workloads you want. I believe passing --silent to the winget installer will install vs_setup unattended but not any workloads from the Build Tools.

To install it all in a single step, and beware I haven't tested this, you're better off downloading and running yourself

  vs_buildtools.exe --quiet --add Microsoft.VisualStudio.Workload.VCTools
adding whatever workloads you need.

Then you'll need to locate and run vcvarsall.bat to setup the environment, which will require some clever code if you're doing it from PowerShell instead of a .bat, and then you can finally call the compiler.

Re: I fixed Windows native development

#362
post #3

This is harder than what I do. Just install LTSC Visual Studio build tools from [1], then chuck this in a cmd file: cl yourprogram.c /link user32.lib advapi32.lib ... etc etc ... I've built a load of utilities that do that just fine. I use vim as an editor. The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though. see: https://learn.microsoft.com/en-gb/visualstudio/relea…

I worked with VC++ 6.0 up until Windows 11 when it really, really wouldn't run any more, then switched to VS 2008. The code is portable across multiple systems so it didn't really matter which version of VS it's developed with, and VC++ 6.0 would load, build the project, and have it ready to run while VS 2022 was still struggling through its startup process.

VS 2008 is starting to show the elephantine... no, continental land-mass bloat that VS is currently at, and has a number of annoying bugs, but it's still vastly better than anything after about VS 2012. And the cool thing is that MS can't fuck with it any more. When I fire up VS tomorrow it'll be the exact same VS I used today, not with half a dozen features broken, moved around, gone without a trace, ...

Re: I fixed Windows native development

#363
> You spend less time on your project because you’re too busy being a human-powered dependency resolver for a 50GB IDE.

Really? A 50GB IDE? How the heck one knows what goes in there?

My beloved FreeBSD 15.0 PLUS its Linux VM PLUS its docker env PLUS its dependencies and IDE are close to 26Gb and pretty sure I'm taking into account a lot of things I shouldn't, so the actual count is much less than that.

Developing software under a Windows platform is something that I cannot understand, since many many many years ago.

Re: I fixed Windows native development

#364
I am not too into windows dev but I am currently using msvc at work. We are told to import a config file into the installer and it automatically selects all of the components any of our projects will need. Wouldn't that solve the problem too? Just distribute a project level config file and add documentation for how to import and install the stuff.

Re: I fixed Windows native development

#365

Earlier quoted context omitted.

> 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.

The problems with pip that uv fixes:

1. It's easy to install.

2. It's not dog slow.

3. It automatically sets up venvs.

4. It automatically activates the venv before running commands.

5. It supports a lock file out of the box.

6. It lets you specify the index for private packages. This fixes a major security issue with pip that they continue to ignore.

7. It installs your code in the venv in editable more by default.

8. It lets you install Python tools outside the venv (`uv tool install`).

9. It works reliably.

There's probably more that I've forgotten. If pip had all of that nobody would have felt the need for a rewrite. And if you've never run into any of those issues I guess you either haven't used Python much or didn't consider that there might be a less shitty way to do things.

Re: I fixed Windows native development

#366
post #3

This is harder than what I do. Just install LTSC Visual Studio build tools from [1], then chuck this in a cmd file: cl yourprogram.c /link user32.lib advapi32.lib ... etc etc ... I've built a load of utilities that do that just fine. I use vim as an editor. The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though. see: https://learn.microsoft.com/en-gb/visualstudio/relea…

I worked with VC++ 6.0 up until Windows 11 when it really, really wouldn't run any more, then switched to VS 2008. The code is portable across multiple systems so it didn't really matter which version of VS it's developed with, and VC++ 6.0 would load, build the project, and have it ready to run while VS 2022 was still struggling through its startup process. VS 2008 is starting to show the elephantine... no, continen…

Yeah recent VS is awful. I recently tried VS2022. What a mess.

Re: I fixed Windows native development

#367

Earlier quoted context omitted.

> Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers. But this isn’t true. Many distros package major versions of GCC/LLVM as separate packages, so you install and use more than one version in parallel, no Docker/etc required It can indeed be true for some things-such as the C library-but often not f…

The closest thing I saw to this was some vendors shipping their SDKs with half the desktop userland (in a similar 'blob' fashion the post complains about), with shell scripts setting up paths so that their libs and tools are found before system ones.

To give a concrete example of what I was talking about, RHEL has “gcc-toolset” for installing multiple GCC versions in parallel:

https://developers.redhat.com/articles/2025/04/16/gcc-and-gc...

Re: I fixed Windows native development

#368

Earlier quoted context omitted.

> https://sourceware.org/bugzilla/show_bug.cgi?id=32653 dlopen and dlmopen no longer make the stack executable if a shared library requires it I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I wo…

A few recent examples: many distros changed the flag for emuTLS on Windows, which gcc implemented as a hard ABI break for no essential reason. If you compile for enough platforms, it will print various notes that various alignments have changed in the struct, which has caused grief numerous times in the past few years for people I work with (many of the changes don’t come with notes, they just change alignment since…

I was talking about glibc; none of the things you mention relate to that. (Note glibc is not used on Windows.) I'm painfully aware of some of the breakage GCC occasionally causes (the atomics fall into that — but to be fair ARMv6 is also >10 years ago at this point, unless you're doing embedded, in which case you generally build the whole system anyway and don't care about these breaks.)

Also, just in case it's not clear, glibc has nothing to do with GCC.

Re: I fixed Windows native development

#369
post #215

Earlier quoted context omitted.

I never understood this sentence structure, it adds zero information, it always goes like: “This isn’t just [what the thing literally is]; it’s [hyperbole on what the thing isn’t].”

It’s a perfectly fine sentence structure. It’s been around for years and years. That’s why LLMs use it! In the UK, Marks and Spencer have a long-running ad campaign built around it (“it’s not just food, it’s...”) Em dashes are fine too.

> long-running ad campaign

So you confirm the previous point about zero information

Re: I fixed Windows native development

#370

Earlier quoted context omitted.

> The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it What? There was a huge breakage literally last year: https://sourceware.org/bugzilla/show_bug.cgi?id=32653 Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first la…

> https://sourceware.org/bugzilla/show_bug.cgi?id=32653 dlopen and dlmopen no longer make the stack executable if a shared library requires it I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I wo…

You can have one of "they're so serious about forward and backward compat you should remove version pins because things won't ever break" and "well, I'm not counting intentional breaks" but not both.
Post reply on HN