I fixed Windows native development

Posted by deevus 15 hours ago

I fixed Windows native development(marler8997.github.io)

649 points | 317 commentspage 3

jdthedisciple 12 hours ago|

Actually not that complicated: You simply check in a global.json [0] where you specify the sdk and workload versions.

Then you also specify target platform sdk versions in the .csproj file and VS will automatically prompt the developer to install the correct toolchain.

[0] https://learn.microsoft.com/en-us/dotnet/core/tools/global-j...

jcotton42 11 hours ago||

global.json is only for .NET toolchains.

What you’re actually wanting here is .vsconfig https://learn.microsoft.com/en-us/visualstudio/install/impor...

huflungdung 12 hours ago||

[dead]

remix2000 7 hours ago||

I don't really use Windows OS much, but why not just use MinGW? Then you have Clang on all platforms you can think of: Android, all the various Darwin flavors and of course Linux and Windows; as well as on platforms you can't think of like FreeBSD or even Haiku maybe? Like honestly what's the point of supporting MSVC at all?? Maybe I'm just not enough of a Windows nerd to understand? (so I'm basically wondering if mingw has any drawbacks)

marler8997 6 hours ago|

If you have a self-contained project, where you don't depend on anyone else and others don't depend on you, MinGW works great. Problems arise when you have dependencies that don't work with it. I'd love to see if MinGW could find a way to be binary compatible with MSVC-compiled binaries. Right now it's kind of an all or nothing solution which makes it hard to adopt.

remix2000 6 hours ago||

Ah, binary-only dependencies, right… That's very specific though, so unless you need to drive some proprietary hardware, why bother using stuff that forces you into MSVC hell lol? Also wouldn't LLVM based MinGW benefit from Clang's MSVC compat? Not sure about this at all, that's why I'm asking, heh… ^^"

criemen 14 hours ago||

This is amazing.

At $workplace, we have a script that extracts a toolchain from a GitHub actions windows runner, packages it up, stuffs it into git LFS, which is then pulled by bazel as C++ toolchain.

This is the more scalable way, and I assume it could still somewhat easily be integrated into a bazel build.

dgxyz 13 hours ago|

Keeping CI entirely out of windows desktop development is the biggest efficiency and cost improvement I've seen in the last 15 years. Our CI toolchain broke so we moved back to a release manager doing it manually. It takes him 20x less time to build it and distribute it (scripted) than it does to maintain the CI pipeline and his desktop machine is several times faster than any cloud CI node we can get hold of.

Edit: Uses a shit load less actual energy than full-building a product thousands of times that never gets run.

wwweston 10 hours ago||

This is really interesting. Do you think it’s possible server-deployed software could also get similar efficiencies with adequate testing?

dgxyz 7 hours ago||

Yeah it really doesn’t matter where you build stuff. The big push to CI is from companies that want to sell you a service to do it.

Software should build and test the same everywhere. If you have to use it, CI should only wrap that.

g947o 13 hours ago||

* Is this allowed per VS' ToS?

* I wonder if Microsoft intentionally doesn't provide this first party to force everyone to install VS, especially the professional/enterprise versions. One could imagine that we'd have a vsproject.toml file similar to pyproject.toml that just does everything when combined with a minimal command line tool. But that doesn't exist for some reason.

BearOso 12 hours ago||

Microsoft doesn't seem to care unless you're a company. That's the reason community edition is free. Individual licenses would be pennies to them, and they gain more than that by having a new person making things in their ecosystem. It's in their interest to make their platform accessible as possible.

Uvix 12 hours ago||

Visual Studio does have that functionality, via vsconfig files: https://learn.microsoft.com/en-us/visualstudio/install/impor...

g947o 12 hours ago||

Doesn't look like it's versioned, or installs Visual Studio itself.

Uvix 11 hours ago|||

For Visual Studio components that are versioned (like the C++ compilers/libraries), the version number is included in the component name.

You still have to install the tool that processes pyproject.toml so that doesn’t seem fair to hold against it. You are right that you still have to know whether to install 2022 or 2026.

jayd16 10 hours ago|||

Curl the VS Build tools exe, then run the build tools command to install what's in the .vsconfig.

drwu 11 hours ago||

I hope it would work with wine. Then cross compiling Win64 binaries from Linux would become convenient without requiring spinning up a Windows VM.

marler8997 11 hours ago||

Yeah I noticed wine wasn't able to execute the MSI files. It also had a problem with the lock files. Both problems should be fixable though.

forrestthewoods 10 hours ago||

Just use Clang. Cross-compiling Linux->Windows is super duper easy.

tehologist 3 hours ago||

I don't understand, just use scite editor with tcc. About a couple of megs download, no install required and your apps will run on everything from win 98 to linux with wine. And if the answer is c++ support then you get all the pain you deserve using that cursed language

yellowapple 7 hours ago||

I don't get why people go through all these flaming hoops and hurdles to deal with MSVC when MinGW and MinGW-w64/MSYS2 are options. In the latter case you even still get (mostly complete) MSVC ABI-compatibility if you compile with clang.

grub5000 7 hours ago||

MinGW and MinGW-64/MSYS2 are just as inscrutable, fragile and new-user-hostile. The fact that you have to choose between MinGW (which has a 64 bit version) or MinGW64 (completely separate codebases maintained by different people as far as I can tell) is just the first in a long obstacle course of decisions, traps, and unexplained acronyms/product names. There are dozens of different versions, pre-built toolchains and packages to throw you off-course if you choose the wrong one.

If you're just a guy trying to compile a C application on Windows, and you end up on the mingw-w64 downloads page, it's not exactly smooth sailing: https://www.mingw-w64.org/downloads/

duped 7 hours ago|||

Because it's fewer hoops and hurdles than using MinGW, in my experience.

forrestthewoods 5 hours ago||

MinGW/MSYS2 are flaming poop hurdles. That’s the bending over backwards to fake a hacky ass bad dev environment. Projects that only support MinGW on Windows are projecting “don’t take windows seriously”.

Supporting Windows without MinGW garbage is really really easy. Only supporting MinGW is saying “I don’t take this platform seriously so you should probably just ignore this project”.

jacobgorm 5 hours ago||

I’ve found that just installing LLVM, CMake and Ninja is enough to get started developing on Windows for most things C/C++.

borland 3 hours ago||

I thought the title was clickbait, but no, he really did fix it! Nice

m132 12 hours ago|

> On Linux, the toolchain is usually just a package manager command away. On the other hand, “Visual Studio” is thousands of components.

That package manager command, at the very least, pulls in 50+ packages of headers, compilers, and their dependencies from tens of independent projects, nearly each of them following its own release schedule. Linux distributions have it much harder orchestrating all of this, and yet it's Microsoft that cannot get its wholly-owned thing together.

More comments...