Live data from Hacker News

I fixed Windows native development

marler8997.github.io

371–380 of 406 posts

Re: I fixed Windows native development

#371

Earlier quoted context omitted.

This does not apply if you're developing closed source: > if you and your team need to compile and develop proprietary C++ code with Visual Studio, a Visual Studio license will still be required.

That just confirms the parent comment's point. If you're just using the build tools directly, you're fine. If need to develop "with Visual Studio" i.e. the IDE, not just the command line tools, then you need the paid license.

It's actually not. It's complicated, but they're explicitly allowing Build Tools to be used to compile open source dependencies of closed source projects that do not need the MSVC toolchain for proprietary components.

It's why the example they give in the article is a Node.js application with native open source dependencies (e.g. sqlite3).

EDIT: it's clearer when read in context of the opening paragraph:

> Visual Studio Build Tools (VSBT) can now be used for compiling open-source C++ dependencies from source without requiring a Visual Studio license, even when you are working for an enterprise on a commercial or closed-source project.

Re: I fixed Windows native development

#372
post #233
post #224

Earlier quoted context omitted.

It sure sounds very Debian-ish, at least. I’m a Fedora user, and Fedora stays veeeery close to upstream. It’s not rolling, but is very vanilla.

Agreed, but I don't think that has to do with either it's "vanillaness" or the 6 month release schedule. Fedora does a lot of compatibility work behind the scenes that distros not backed by a large company more than likely couldn't afford.

"Vanillaness" is exactly what's in-scope here:

> ...every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.

Applying non-vanilla flavor (patches) to libraries in able to make new packages work with old packages. (It's not just a library thing of course--I've run into packages on Debian where some component gets shimmed out by some script that calls out to some script to dynamically build or download a component. But I digress.)

Maybe I'm just out of the loop here, but I'm not aware of this being a general practice in Fedora. Yes, Fedora does a lot of compatibility work of course, but afaik the general practice isn't to add Fedora-flavored patches.

Re: I fixed Windows native development

#373
post #27

Earlier quoted context omitted.

Why? You may end up with something that doesn't get much attention anymore, but none of the official gui approaches have ever been removed as far as I know. Win32, MFC, winforms, wpf, winui, maui are all still available and apps using them are functional. Even winjs still works apparently, even if it was handed over. I wouldn't start an app in most of them today, but I wouldn't rewrite one either without a good reaso…

Well a number of them have horrific bugs in them which have zero attention. At least win32 has an abstraction level which allows you to work around them. There’s a fun bug on WPF and form backgrounds for example which means on fractional DPI screens the background is tiled unpredictably. Had to patch that one up rather quickly one day and it was a mess due to how damn complicated WPF is.

I don't believe we'll get any toolkit without bugs in our lifetime. There are bugs in everything, but it doesn't prevent millions of different apps running using WPF every day.

Re: I fixed Windows native development

#374

Earlier quoted context omitted.

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

> 2. It's not dog slow.

That’s very subjective. I have ADHD and I’m very sensitive to things that break my flow, but I don’t run pip frequently while I’m writing code, and the couple extra seconds it takes to do its job don’t bother me that much.

> 3. It automatically sets up venvs.

Remember: explicit is better than implicit.

> 4. It automatically activates the venv before running commands.

Again: explicit is better than implicit.

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

Some (me included) would say it’s a bug, not a feature.

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

This is good - a lot of organisations concerned with that will block access to PyPI altogether and offer a selected cache for approved dependencies. Alternatively you can declare private dependencies as Git URLs with tags, bypassing the need for a private index.

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

That’s a nice touch, but goes against the explicit/implicit rule- a different behaviour automatically triggered by something environmental.

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

I always recommend not messing with the system’s Python.

> 9. It works reliably.

I’ll need you to elaborate on that. I might be used to the way pip works, but it’s been a while since I had it fail to do something I asked without there being a very good reason (an impossible conflicting requirement).

This brings me to another concern - I wouldn’t want Python development to become more like JavaScript post-npm. Every external dependency you bring in must be justified and understood. This goes for simple ones and especially for complex ones with lots of secondary dependencies. Any external dependency you bring is now your responsibility to manage forever. I’m fine not having to reimplement NumPy’s MSE function or Django’s ORM, but I’ve moved away from things like click because they save me just a little extra work at the cost of having to remember it’s there forever.

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

Or, perhaps, I’ve been using Python since 1.5 and have a deep understanding of why things are the way they are, having experimented with different ways, and just learned that new and convenient isn’t always the best in the long term.

Re: I fixed Windows native development

#375

Earlier quoted context omitted.

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

this seems to be the same approach I saw with other SDKs (for example Qt), which I wrote about in my previous post - the official versions ship half the userland dependencies in a directory under /opt/

and use some scripts (chroot or LD_LIBRARY_PATH maybe, not an expert) to create a separate environment for the given toolset.

Re: I fixed Windows native development

#376
post #339

Earlier quoted context omitted.

>MingW is evil Care to elaborate?

I've been shipping Windows software for 20+ years. Not one project I have ever worked on was based on MinGW. It's a gross hack that is ABI incompatible with the predominate ecosystem. In the year 2026 there is no reason to use MinGW. Just use Clang and target MSVC ABI. Cross-compiling Linux->Windows is very easy. Cross-compiling Windows->Linux is 1000x harder because Linux userspace is a clusterfuck of terrible desig…

I think the issues you're referring to are related to C++ ABI which is inherently incompatible between different compilers (and sometimes versions). This can be sometimes issue for plugins, though sane programs always use C wrappers.

I never had issues with C ABI, calling into other DLLs, creating DLLs, COM objects, or whatever. I fail to see what is fundamentally incompatible here.

Re: I fixed Windows native development

#377

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.

"No Visual Studio installation. No GUI. No prayer. Just a script that does exactly what it says."

https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...

https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...

The shitty AI writing is so distracting I had to stop reading.

Re: I fixed Windows native development

#378

Earlier quoted context omitted.

They've completely reworked release plans. 2026 LTSC will come out a year after the initial VS 2026 release (at the same time as VS 2027) and be supported for 1 more year. You pretty much have to get on the rolling updates train for the IDE, which is why the C++ toolchain now follows a different schedule and you're supposed to be able to install any specific toolchain side by side.

So in this new Microsoft world, “long term” means “one or two years, depending on how you count”? Ohhkay.

No, LTCS means the version after the end of public beta.

Re: I fixed Windows native development

#379
post #339

Earlier quoted context omitted.

>MingW is evil Care to elaborate?

I've been shipping Windows software for 20+ years. Not one project I have ever worked on was based on MinGW. It's a gross hack that is ABI incompatible with the predominate ecosystem. In the year 2026 there is no reason to use MinGW. Just use Clang and target MSVC ABI. Cross-compiling Linux->Windows is very easy. Cross-compiling Windows->Linux is 1000x harder because Linux userspace is a clusterfuck of terrible desig…

>> It's a gross hack

*taps on the name of this site*

If I'm writing some cross-platform bit of software, my interest in supporting Windows is naturally in producing binaries that run on Windows.

Why on earth should I give a flying toss how "almost all Windows software is developed", or which kinds of ABIs are BillG-kissed and approved? Good god. Talk about fetishising process over outcome.

Re: I fixed Windows native development

#380

Earlier quoted context omitted.

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

> 2. It's not dog slow. That’s very subjective. I have ADHD and I’m very sensitive to things that break my flow, but I don’t run pip frequently while I’m writing code, and the couple extra seconds it takes to do its job don’t bother me that much. > 3. It automatically sets up venvs. Remember: explicit is better than implicit. > 4. It automatically activates the venv before running commands. Again: explicit is better…

> Remember: explicit is better than implicit.

It's not implicit. When you run `uv run ...` or `uv sync` you are explicitly asking it to automatically set up a venv.

> Some (me included) would say it’s a bug, not a feature.

Some (you included) would be wrong.

> This is good

What is good? That Pip doesn't have a way to avoid dependency confusion? What??

> but goes against the explicit/implicit rule

No it doesn't. It just does the right thing by default.

> I always recommend not messing with the system’s Python.

The reasons to avoid `pip install pre-commit` (outside a venv) are precisely because Pip can't do that in a sane way! `uv tool install pre-commit` suffers from none of the reasons to avoid `pip install pre-commit`.

You definitely have stockholm syndrome. Give uv a try.

Post reply on HN