15 ms·

I fixed Windows native development

• anaisbetts 8mo ago
  Came in getting ready to hate on this article, but was actually pleasantly surprised, this is great. Good work OP.
• deafpolygon 8mo ago
  Step 1. Wipe computer Step 2. Install your preferred flavor of Linux Step 3. Set-up dev tools Step 4. Profit??
• criemen 8mo 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 8mo 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 8mo ago
      This is really interesting. Do you think it’s possible server-deployed software could also get similar efficiencies with adequate testing?
      • dgxyz 8mo 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.
• dgxyz 8mo ago
  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/releases/2022/release-history#fixed-version-bootstrappers https://learn.microsoft.com/en-gb/visualstudio/releases/2022... - you should use these if you are not a single developer and have to collaborate with people. Back like in the old days when we had pinned versions of the toolchain across whole company. [1] https://download.visualstudio.microsoft.com/download/pr/5d23a358-8ed7-4560-81e7-fb52d6a3ae02/2b25d9b457dfaf84fcb2af5b21264322b029b6efafd3178b1a4a8a7b79a18105/vs_BuildTools.exe https://download.visualstudio.microsoft.com/download/pr/5d23...
  • aleph_minus_one 8mo ago
    > The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though. You only get access to the LTSC channel if you have a license for at least Visual Studio Professional (Community won't do it); so a lot of hobbyist programmers and students are not aware of it. On the other hand, its existence is in my experience very well-known among people who use Visual Studio for work at some company.
    • dgxyz 8mo ago
      You can install the LTSC toolchain without a license. Just not the IDE.
      • foepys 8mo ago
        That's not correct. You don't have to give your credit card details or even be logged in but you are still required to have any Visual Studio license. For hobbyists and startups the VS Community license is enough but larger companies need a VS Professional license even for the VS Build Tools. How strict Microsoft is with enforcement of this license is another story.
• jen20 8mo ago
  This is a serious quality of life improvement for people forced to deal with Windows! Great job.
• reactordev 8mo ago
  And here I was messing with MingW64… This is fantastic and someone at Microslop should take notes.
  • Borg3 8mo ago
    Exacly.. I avoid Visual Studio.. I try to build everthing using Mingw..
    • xvilka 8mo ago
      Clang is the better alternative to MinGW because it can use standard Windows libraries and avoids the need for additional runtime.
      • reactordev 8mo ago
        Just msys2 it all
        • delta_p_delta_x 8mo ago
          MSYS2 is horrible. It brings a massive runtime environment and is a bad idea to foist on users.
          • michaelsbradley 8mo ago
            Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)? The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.
            • reactordev 8mo ago
              He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…
• pjmlp 8mo ago
  It starts by not looking into Windows through UNIX developer glasses. The only issue currently plaguing Windows development is the mess with WinUI and WinAppSDK since Project Reunion, however they are relatively easy to ignore.
  • dgxyz 8mo ago
    Yes. Any user interface toolkit that isn't at least 10 years old should be ignored on windows unless you want to rewrite everything one day.
    • glimshe 8mo ago
      I wonder if people still use WinForms, MFC and WPF...
      • dgxyz 8mo ago
        We still use win32! (granted we made our own MFC around it)
      • shigawire 8mo ago
        Still migrating an enterprise app off WPF to this day.
        • dgxyz 8mo ago
          What are you moving to out of interest? I’ve seen people talking of moving ours to Electron which seems to just be more problems waiting.
      • pjmlp 8mo ago
        They certainly do.
      • marcosdumay 8mo ago
        I'd guess WinForms is still the most popular widget library in Windows.
    • 8mo ago
• rzr 8mo ago
  next, wrap it with wine and eventually share a bottle/winetrick
• NSUserDefaults 8mo ago
  So this fixes the problem when msvc is the required compiler. Does the zig C++ compiler bring anything to the table when clang is an option?
  • feverzsj 8mo ago
    You still need headers and libraries that ship with MSVC.
• eptcyka 8mo ago
  Is this even legal?
• 6581 8mo ago
  > No Visual Studio installation. No GUI. No prayer. Just a script that does exactly what it says.
  • never_inline 8mo ago
    Yeah its obvious clanker writing. I don't even mind using LLM for code but this rubs the wrong way.
  • deleted 8mo ago
    [deleted]
• Philpax 8mo ago
  At the risk of being that guy, I haven't had any issues onboarding people onto native projects written in Rust. rustup does a great job of fetching the required toolchains without issue. I'd imagine the same is also true of Go or Zig.
  • the__alchemist 8mo ago
    You have to do this for certain rust things too. I can't remember which, but I inevitably run into a need to install the MSVC toolchain to compile rust. I think it might be related to FFI, or libs which use FFI? The same thing comes up in Linux, but the process to install it is different. I got anxiety reading the article, describing exactly why it sucks. It's nice to know from the article and comments here there are ways around it, but the way I have been doing it was the "hope I check the right checkboxes and wait a few hours" plan. There is usually one "super checkbox" that will do the right things. I have to do this once per OS [re]install generally.
    • pjmlp 8mo ago
      It makes use of MSVC linking infrastructure, and import libraries.
  • ww520 8mo ago
    Before rustup can run, the very first message rustup-init spits out is asking to install the visual studio tool chain.
  • g947o 8mo ago
    I'm pretty people who write and build C++ on Windows do it for good reasons, often reasons that are out of their control. Your comment is not going to make any difference.
  • pjmlp 8mo ago
    While Microsoft <3 Rust, there are still some quality tooling parity to reach versus Visual Studio abilities for .NET, Python and C++. Incremental compilation, and linking, parallel builds, hot code reloading, REPL, graphical debugging optimised builds, GPU debugging.... Go is better left for devops stuff like Docker and Kubernetes, and Zig remains to be seen when it becomes industry relevant beyond HN and Reddit forums.
• ewuhic 8mo ago
  Nix on Windows when...
  • itishappy 8mo ago
    Since roughly September 2022 with the release of WSL 0.67.6!
    • dataflow 8mo ago
      Have you actually attempted to use it recently? Are you familiar with the WSL1 bugs that surface when running random Linux distros? (To be clear, I haven't tried this with Nix, but I have with other distros.)
      • itishappy 8mo ago
        Fair question! Nope. I'm not endorsing it, and certainly don't know (or even suspect) it would solve this issue. I just recently installed NixOS and was surprised to see Windows mentioned on the downloads page, so looked into it a bit. Maybe soon.
        • dataflow 8mo ago
          Okay well, if you do, good luck with glibc (and likely other) issues. WSL1 feels kind of dead unfortunately, neither Windows wants to support newer Linux syscalls nor do Linux projects seem to care for including fallbacks.
    • ewuhic 8mo ago
      Let me paraphrase: nix FOR windows
• deleted 8mo ago
  [deleted]
• xvilka 8mo ago
  Please add also the support for the clang-cl[1][2]. [1] https://clang.llvm.org/docs/MSVCCompatibility.html https://clang.llvm.org/docs/MSVCCompatibility.html [2] https://clang.llvm.org/docs/UsersManual.html#clang-cl https://clang.llvm.org/docs/UsersManual.html#clang-cl
• __alexander 8mo ago
  Another option is explore winget and chocolaty. Most build tools and compilers can be installed via the command line on windows. Ask your favorite LLM to create a powershell script to install them all.
• its_notjack 8mo ago
  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.
  • evanjrowley 8mo ago
    Perhaps people have mimicked the style because LLMs have popularized it and clearly it serves some benefit to readers.
    • mkoubaa 8mo ago
      Life imitates art, even when that art is slop
    • ludwik 8mo ago
      Perhaps LLMs have mimicked the style because authors have popularized it and clearly it serves some benefit to readers.
      • evanjrowley 8mo ago
        It's a cycle.
    • PKop 8mo ago
      > have popularized it It's hated by everyone, why would people imitate it? You're inventing a rationale that either doesn't exist or would be stupider than the alternative. The obvious answer here it they just used an LLM. > and clearly it serves some benefit to readers. What?
      • evanjrowley 8mo ago
        Then why does every vibe-coded "Show HN" app have it in README.md? Surely authors would edit it out if it was true that everyone hates it.
• g947o 8mo 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.
  • Uvix 8mo ago
    Visual Studio does have that functionality, via vsconfig files: https://learn.microsoft.com/en-us/visualstudio/install/import-export-installation-configurations?view=visualstudio#use-a-configuration-file-to-automatically-install-missing-components https://learn.microsoft.com/en-us/visualstudio/install/impor...
    • g947o 8mo ago
      Doesn't look like it's versioned, or installs Visual Studio itself.
      • Uvix 8mo 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 8mo ago
        Curl the VS Build tools exe, then run the build tools command to install what's in the .vsconfig.
  • BearOso 8mo 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.
• thrownaway561 8mo ago
  I'm just asking, but is there really a need for a native programs anymore? Where I worked a decade ago, we started porting all our native programs over to the browser and this was when MVC beta was just being released. At this point with Electron and Tauri, is there even a need to write a native program Now with AI, I would think that porting a native program to the browser wouldn't be the chore it once was.
  • PlatoIsADisease 8mo ago
    I use COM and DLLs to extend software/automate. Using Visual Studio gives me some really nice debugging options. I did try using python and js but the variable explorer is garbage due to 'late binding'. I thought this was just my ignorance, but I've asked experts, AI, and google searched and they unfortunately agree. That said, some people have created their own log/prints so they don't need to deal with it.
  • well_ackshually 8mo ago
    > is there really a need for a native programs anymore As long as you don't give a shit about the fact that your baseline memory consumption is now 500MB instead of 25MB, and that 80% of your CPU time is wasted on running javascript through a JIT and rendering HTML instead of doing logic, no. If you don't give a shit about your users or their time, there's indeed no longer a need to write native programs.
    • botusaurus 8mo ago
      what if caring about users means giving them features instead of fighting with obsolete unproductive native GUI frameworks funny how Electron apps tend to have many more users than their native "performant" counterparts, isn't it?
  • MomsAVoxell 8mo ago
    Yes, very definitely. There has always been a need for high performance native applications. Even in the beginning of the desktop computing revolution, these questions have been asked .. and yes, there is a balance between native and cloud/browser-based computing - some of it is personal, much of it is industrial and corporate, and yet more of the spectrum where both methods are applicable exists, even still, decades later.
• deleted 8mo ago
  [deleted]
• ww520 8mo ago
  I was just setting up a new machine and was setting up the Rust environment. The very first thing rustup-init asked was to install Visual Studio before proceeding. It was like 20-30gb of stuff installed before moving forward. This tool would be a great help if I knew beforehand.
• jjkaczor 8mo ago
  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-command-line-parameters-to-install-visual-studio?view=visualstudio 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 connectivity it was over traditional slow/low-latency satellite connections), so part of the process was also to build an offline install package.
  • 486sx33 8mo ago
    [dead]
  • jjkaczor 8mo ago
    (ugh - "high-latency" connections...)
  • KTibow 8mo ago
    I tried this once. It downloaded way more stuff than needed and still required admin to actually install.
    • jjkaczor 8mo ago
      Well - "run as admin" wasn't a problem for that scenario - as I was also configuring the various servers. (And - it is better on a shared-machine to have everything installed "machine-wide" rather than "per-user", same as PowerShell modules - had another client recently who had a small "C:" drive provisioned on their primary geo-fenced VM used for their "cloud admin" team and every single user was gobbling too much space with a multitude of "user-profile" specific PowerShell modules...) But - yes, even with a highly trimmed workload it resulted in a 80gb+ offline installer. ... and as a server-admin, I also had physical data-center access to load that installer package directly onto the VM host server via external drive.
• PlatoIsADisease 8mo ago
  I havent run into this problem yet... but my oldest .net software is only 1 year old... Is this something that happens over the course of a few years?
  • Uvix 8mo ago
    This is about native development (C++), not .NET.
    • PlatoIsADisease 8mo ago
      Thank you
• torginus 8mo ago
  What we did for out build agents was to just install the required version of build tools via chocolatey. But cool approach!
  • MomsAVoxell 8mo ago
    Same. Choco solves this with a one-liner for me.
  • pjmlp 8mo ago
    Nowadays you can also use winget for it.
• ivanjermakov 8mo ago
  One day I decided to port my text editor to Windows. Since it depends on pcre2 and treesitter, these two libraries had to be provided by the system. In the span of ~2hrs I didn't manage to find a way to please Zig compiler to notice "system" libraries to link against. Perhaps I'm too spoiled by installing a system wide dependency in a single command. Or Windows took a wrong turn a couple of decades ago and is very hostile to both developers and regular users.
  • lmz 8mo ago
    If you depend on a library and can't figure out how you would compile against it, it's probably better for the end user that you don't make anything because you'll still need to package it up later unless you link statically.
  • okanat 8mo ago
    I think providing purely-functional libraries as system dependencies that's tied to the whole tool chain at the time was the wrong decision by the Unix world. The system libraries should only ship system stuff: interaction with the OS (I/O, graphics basics, process management), accessing network (DNS, IP and TLS). They should have stable APIs and ABIs. Windows isn't hostile. It has a differnt paradigm and Unix (or more correctly usually GNU/Linux) people do not want to give up their worldview. PCRE is basically only your apps's dependency. It has nothing else to do the rest of the operating system. So it is your responsibility to know how to build and package it.
  • the__alchemist 8mo ago
    I suspect the pitfall is how you or the zig compiler is linking. Unless you're involving things which vary by OS like hardware interaction, networking, file systems etc, you should not, with a new Lang in 2026, need to do anything special for cross-platform capabilities.
    • ivanjermakov 8mo ago
      My understanding that "linkSystemLibrary" abstraction in build.zig only holds for Unix systems. And this in turn makes it impossible to build my program on Windows without modifying the build script.
• jevinskie 8mo ago
  Were you around before the new installer came out? It was light speed compared to what was before!
• droelf 8mo ago
  Thank you, this might be a great way to improve the developer experience in the conda/conda-forge ecosystem.
• jordand 8mo ago
  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.
  • jayd16 8mo ago
    Yeah, seems like this is just ignorance around .vsconfig files. Makes life way easier. You can also just use the VS Build Tools exe to install things instead of the full VS installer, if you plan to use a different IDE.
    • scotty79 8mo ago
      Can you use .vsconfig to tell Build Tools what your project needs? Can you generate .vsconfig with Build Tools?
      • jayd16 8mo ago
        You pass in the --config param to import it. Exporting this way might be possible but it wouldn't be as useful seeing as it would just grab everything you have installed instead of some minimal set used by some project.
• tgtweak 8mo ago
  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.
  • giancarlostoro 8mo ago
    I went from POP OS (Ubuntu) to EndeavourOS (Arch) Linux because some random software with an appimage or whatever refused to run with Ubuntus “latest” GLIBC and it ticked me off, I just want to run more modern tooling, havent had any software I couldnt just run on Arch, going on over a year now.
    • moogly 8mo ago
      Indeed. As late as 2 hours ago I had to change the way I build a private Tauri 2.0 app (bundled as .AppImage) because it wouldn't work on latest Kubuntu, but worked on Fedora and EndeavourOS. So now I have to build it on Ubuntu 22.04 via Docker. Fun fun. Had fewer issues on EndeavourOS (Arch) compared to Fedora overall though... I will stay on Arch from now on.
  • pjmlp 8mo ago
    Which has been fixed on .NET 5 and later. .NET Framework should only be used for legacy applications. Unfortunately there are still many around that depend on .NET Framework.
• mkoubaa 8mo ago
  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.
• claimred 8mo ago
  Perhaps winget is enough? winget install Microsoft.VisualStudio.2022.BuildTools
  • debugnik 8mo ago
    The Build Tools installer first installs the Visual Studio tool to select the workloads you want as well.
    • josephernest 8mo ago
      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.
      • debugnik 8mo ago
        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.
• evanjrowley 8mo ago
  Fantastic work! It's a long-needed breath of fresh air for the Visual Studio DX. I wish msvcup was existed when they made us use it back during Uni. Alternatively, there's this: Install Visual Studio Build Tools into a container to support a consistent build system | Microsoft Learn https://learn.microsoft.com/en-us/visualstudio/install/build-tools-container?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/install/build...
• jezek2 8mo ago
  I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs. I don't understand how open source projects can insist on requiring a proprietary compiler.
  • sitzkrieg 8mo ago
    if you want to link msvc built libraries (that are external/you dont have source), mingw may not be an option. for an example you can get steamworks sdk to build with mingw but it will crash at runtime
  • delta_p_delta_x 8mo ago
    There are some pretty useful abstractions and libraries that MinGW doesn't work with. Biggest example is the WIL[1], which Windows kernel programmers use and is a massive improvement in ergonomics and safety when writing native Windows platform code. [1]: https://github.com/microsoft/wil https://github.com/microsoft/wil
    • vitaminCPP 8mo ago
      I fail to see why this would not work with gcc if it works with clang. The runtime?
      • delta_p_delta_x 8mo ago
        'MinGW' is not GCC; it's an ABI, and from the developer perspective it is also the headers and the libraries. You can have GCC MinGW, Clang MinGW, Rust MinGW, Zig MinGW, C# AOT MinGW. To answer your question, the headers.
  • quikoa 8mo ago
    Agreed I also like to see more support for MingW especially from open source projects. Not even a passing mention in this blog post.
  • forrestthewoods 8mo ago
• jdthedisciple 8mo 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-json https://learn.microsoft.com/en-us/dotnet/core/tools/global-j...
  • huflungdung 8mo ago
    [dead]
  • jcotton42 8mo ago
    global.json is only for .NET toolchains. What you’re actually wanting here is .vsconfig https://learn.microsoft.com/en-us/visualstudio/install/import-export-installation-configurations?view=visualstudio#use-a-configuration-file-to-automatically-install-missing-components https://learn.microsoft.com/en-us/visualstudio/install/impor...
• dvfjsdhgfv 8mo ago
  I like the tool, I like the article, but I'd prefer it it was half as long but without AI touch.
• m132 8mo 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.
• bob1029 8mo ago
  You can do a lot of "native" windows development from modern C#/.NET via win32 interop. Newer C# features like ref returns, structs, spans, et. al., make the overhead undetectable in many cases. https://github.com/prasannavl/WinApi https://github.com/prasannavl/WinApi https://github.com/microsoft/CsWin32 https://github.com/microsoft/CsWin32
  • pjmlp 8mo ago
    Exactly, the major pain point remains the .NET allergy from Windows team, but it is workable.
• drwu 8mo 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 8mo 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 8mo ago
    Just use Clang. Cross-compiling Linux->Windows is super duper easy.
    • account42 8mo ago
      Clang is a compiler, not a whole toolchain.
• cissikatt 8mo ago
  I just avoid Windows and Windows development. If I get paid to do it I don't mind the shittyness.
• dimgl 8mo ago
  > The build.bat above isn’t just a helper script; it’s a declaration of independence from the Visual Studio Installer. I am so fed up with this! Please if you're writing an article using LLMs stop writing like this!
  • cmovq 8mo ago
    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].”
    • crazygringo 8mo ago
      The purpose isn't information, the purpose is drama. Er, sorry. I meant: the purpose isn't just drama—it's a declaration of values, a commitment to the cause of a higher purpose, the first strike in a civilizational war of independence standing strong against commercialism, corporatism, and conformity. What starts with a single sentence in an LLM-rewritten blog post ends with changing the world. See? And I didn't even need an LLM to write that. My own brain can produce slop with an em dash just as well. :)
      • voxelghost 8mo ago
        This is actually the scariest part. Because lately even authors and creators who are not using LLM are starting to pick up some of these ways of expressing themselves.
        • j16sdiz 8mo ago
          I wonder where did LLM learnt that...
        • crazygringo 8mo ago
          Oh, I didn't learn it from LLM's, believe me. That style of writing has been around forever. LLM's learned it from us. I'd basically call it "American sales pitch". It's a little bit product landing page, a little bit political opinion column, a little bit self-help book or motivational blogger. It's always been a style of writing that tries to maximize engagement. The issue is that now we see it creeping into areas that never used to use it. It's not how developers tend to write. But now developers toss their original draft into an LLM asking it to "punch it up for engagement" -- or the LLM has just been trained to assume that's what someone wants by default -- and so now it stands out like a sore thumb. And obviously, it's an appeal to emotion. Whereas developers tend to be looking for just the cold hard facts. So it's doubly off-putting.
• 0938682796 8mo ago
  [dead]
• dundarious 8mo ago
  I'll just keep using Mārtiņš Možeiko's script, portable-msvc.py, that this tool is based upon. It does everything this does, except a lock file and the autoenv. I'm not particularly interested in the former, and definitely not the latter. https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cde9977 https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cd...
• BrouteMinou 8mo ago
  [dead]
  • dang 8mo ago
    Trollish usernames aren't allowed on HN, so we've banned this account*. If you want to pick a different username that isn't trollish, we can rename the account and unban it. It would be best to email hn@ycombinator.com for this, to make sure we get the message. (It would have been better for us to catch this sooner, but in this case someone had to explain the name to me. Out of respect for HN's many Francophone readers, I think it's best to apply the rule.) * https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=true&page=0&query=by:dang%20trollish%20username https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
• a-dub 8mo ago
  it's been 14 years since i've used msvc for anything real. iirc the philosophy back then was yearly versioned releases with rolling intermediate updates. this seems to go down the road towards attempts at determinsticish builds which i think is probably a bad idea since the whole ecosystem is built on rolling updates and a partial move towards pinning dependencies (using bespoke tools) could get complicated.
• mmargerum 8mo ago
  If you are looking to rapidly build windows native apps just use Delphi. Superlative tool for this. Been using since ‘95
• anankaie 8mo ago
  Why not use winget to do it? `winget install --id Microsoft.VisualStudio.2022.BuildTools`. If you need the Windows(/App) SDK too for the WinRT-features, you can add `winget install --id Microsoft.WindowsSDK.10.0.18362` and/or `winget install --id Microsoft.WindowsAppRuntime.1.8`
  • easton 8mo ago
    Having been the person that used to support those packages, it’s not that simple. You need to pass what workloads you need installed too, and if it’s a project you’re not familiar with god help you. I used to just install the desktop development one and then work through the build errors until I got it to work, was somewhat painful. (Yes, .vsconfig makes this easier but it still didn’t catch everything when last I was into Windows dev).
• beanjuiceII 8mo ago
  these seems overly dramatic...i just setup a windows 11 box and installed the needed tools quite quickly via winget and I was up and running
• GeoAtreides 8mo ago
  >The key insight are we doomed to only read AI slop from now on? to get a couple paragraphs in and suddenly be hit with the realization that is AI? it's all so tiresome
  • Graziano_M 8mo ago
    I literally came to post the exact same line as my indicator that this was AI-generated. I ctrl-f'd first and sure enough I'm not alone in using 'key insight' as the canary.
• delta_p_delta_x 8mo ago
  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 separately in VS; just use the above-mentioned llvm-mingw clang.exe as `clang.exe --driver=cl /winsysroot <path\to\Windows SDK> /vctoolsdir <path\to\VC>`. Or you can use it in GNU-driver-style mode, and use -Xmicrosoft-windows-sys-root. This causes it to target the Windows ABI and links against the VS SDK/VC tools `clang.exe` that targets the Itanium ABI and links against the MinGW libraries and LLVM libc++. Done and dusted. Load these into a CMake toolchain and never look at them again. People really like overcomplicating their lives. At the same time, learn the drawbacks of all toolchains and use what is appropriate for your needs. If you want to write Windows drivers, then forget about anything non-MSVC (unless you really want to do things the hard way for the hell of it). link.exe is slow as molasses, but can do incremental linking natively. cl.exe's code gen is (sometimes) slightly worse than Clang's. The MinGW ABI does not understand things like SAL annotations[3], and this breaks very useful libraries like WIL[4] (or libraries built on top of them, like the Azure C++ SDK[5] The MinGW headers sometimes straight up miss newer features that the Windows SDK comes with, like cfapi.h[6]. [1]: https://github.com/mstorsjo/llvm-mingw https://github.com/mstorsjo/llvm-mingw [2]: https://learn.microsoft.com/en-gb/visualstudio/ide/reference/command-prompt-powershell?view=visualstudio https://learn.microsoft.com/en-gb/visualstudio/ide/reference... [3]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-annotations?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-... [4]: https://github.com/microsoft/wil https://github.com/microsoft/wil [5]: https://github.com/Azure/azure-sdk-for-cpp https://github.com/Azure/azure-sdk-for-cpp [6]: https://learn.microsoft.com/en-gb/windows/win32/cfapi/build-a-cloud-file-sync-engine https://learn.microsoft.com/en-gb/windows/win32/cfapi/build-...
  • shevy-java 8mo ago
    LLVM-MinGW sounds external to Microsoft though. I think the blog focused on in-Microsoft solutions. And I am not sure the "contrary to the blog content" is valid - compared to Linux, the Microsoft stack is much more annoying to install. I installed it, but it was annoying to no ends and took ages. Good to know LLVM works on windows too though.
• forrestthewoods 8mo ago
  > msvcup is inspired by a small Python script written by Mārtiņš Možeiko. This script is great. Just use it. The title saying “I fixed” is moderately offensive glory stealing.
• mschuster91 8mo ago
  > On Linux, the toolchain is usually just a package manager command away. If you are compiling for your native system, yes. But as soon as you try cross-compiling, you are in for a lot of pain.
• phendrenad2 8mo ago
  I seriously doubt that people who get confused by the MSVC++ Installer will be able to handle a CLI app that installs a mystery MSVC++ toolchain version to a versioned directory. They're still going to click the Visual Studio icon on their desktop and scratch their head why your script didn't magically fix their problems.
• Aurornis 8mo ago
  Looking at the script: > curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/download/v2026_02_07/msvcup-x86_64-windows.zip https://github.com/marler8997/msvcup/releases/download/v2026... No thanks. I’m not going to install executables downloaded from an unknown GitHub account named marler8997 without even a simple hash check. As others have explained the Windows situation is not as bad as this blog post suggests, but even if it was this doesn’t look like a solution. It’s just one other installation script that has sketchy sources.
  • hiccuphippo 8mo ago
    I know Jonathan Marler for some of his Zig talks and his work in the win32 api bindings for Zig[0], they are even linked from Microsoft's own repo[1] (not sure why he has 2 github users/orgs but you can see it's the same person in the commits). [0] https://github.com/marlersoft/zigwin32 https://github.com/marlersoft/zigwin32 [1] https://github.com/microsoft/win32metadata https://github.com/microsoft/win32metadata
    • 8n4vidtmkvmk 8mo ago
      I would guess one of his accounts is his corporate employee account and his other is personal.
  • dotancohen 8mo ago
    You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script. Just like those complaining about curl|sh on Linux, you are confusing install instructions with source code availability. Just download the script and read it if you want. The curl|sh workflow is no more dangerous that downloading an executable off the internet, which is very common (if stupid) and attracts no vitriol. In no way does it imply that you can not actually download and read the script - something that actually can't be done with downloaded executables.
    • Groxx 8mo ago
      It is somewhat different when your system forces binaries to be signed... but yeah, largely agreed. The abject refusal of curl|sh is strange to me, unless the refusers are also die-hard GPL adherents. Binaries are significantly more opaque and easier to hide malware in, in almost all cases.
• shevy-java 8mo ago
  To me it seems as if Microsoft wants to make it deliberately harder to have software developers. Now - I installed all the required things and compiled on Windows too, but it is very annoying compared to Linux. Microsoft should simply have ONE default build, e. g. "download this and 80% of developers will be happy". No need for a gazillion checkboxes.
• functionmouse 8mo ago
  just use w64devkit, it's nice
• eboy 8mo ago
  [dead]
• throw_win32dev 8mo ago
  I will never cease to be amused by these 'Unixhead has to do windev. Reinvents the wheel' blog posts.
• Alifatisk 8mo ago
  > It’s so vast that Microsoft distributes it with a sophisticated GUI installer where you navigate a maze of checkboxes, hunting for which “Workloads” or “Individual Components” contain the actual compiler. Select the wrong one and you might lose hours installing something you don’t need. I have a vague memory of stumbling upon this hell when installing the ldc compiler for dlang [1]. 1. https://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC https://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_u...
• gaigalas 8mo ago
  Windows Native is fine. People in that space are comfortable with it. What needs to be fixed is the valley between unix and windows development for cross-os/many-compiler builds, so one that does both can work seamlessly. It's not an easy problem and there are lots of faux solutions that seem to fix it all but don't (in builds, the devil is in edge cases).
• fassssst 8mo ago
  You can also install visual studio build tools via the built in winget package manager.
• whatever1 8mo ago
  “Build Requirements: Install Visual Studio”. You’ve never experienced genuine pain in your life. Have you tried to change the GCC compiler version in Linux?
  • kristjansson 8mo ago
    apt install gcc-11 CC=gcc-11 make ? If it’s not packaged and you’ve got to build it yourself, Godspeed. An if you’ve got to change libc versions…
    • Pay08 8mo ago
      GCC is surprisingly simple to build, fortunately.
      • kristjansson 8mo ago
        Yeah it’s not too bad, but it does pull away from “so trivial it fits in a flippant HN comment”
        • Pay08 8mo ago
          Does it? Admittedly, it has been a while but I don't remember it differing too much from the good old ./configure && make paradigm with a few flags to both commands.
          • kristjansson 8mo ago
            It’d fit in a comment, but not a flippant one ;)
• kittbuilds 8mo ago
  [dead]
• juujian 8mo ago
  > Hours-long waits: You spend an afternoon watching a progress bar download 15GB just to get a 50MB compiler. What year is it?! Also, haven't heard any complaints regarding VS on MacOS, how ironic...
• OlympicMarmoto 8mo ago
  mmozeiko "fixed" windows native development, just use their script. Also PortableBuildTools already exists https://github.com/Data-Oriented-House/PortableBuildTools https://github.com/Data-Oriented-House/PortableBuildTools
• malkia 8mo ago
  Or... you can "winget install Microsoft.VisualStudio.BuildTools" "winget install Microsoft.WindowsSDK.10.0.26100"
  • tonymet 8mo ago
    Nearly all of the Windows hate i see comes from 20 year old takes . ( the bing/cortana / copilot / ads slop criticism is warranted, but is also easily disabled).
    • malkia 8mo ago
      it's not ideal, but much much much better!
  • macshome 8mo ago
    I thought for a moment I was missing something here. I always just use winget for this sort of thing as well. It may kickoff a bunch of things, but it’s pretty low effort and reliable.
  • scotty79 8mo ago
    But those are installed system wide. What if you have two different project with different requirements at the same time? Every language should have a tool like Python uv.
    • Const-me 8mo ago
      > What if you have two different project with different requirements at the same time? Install multiple versions of Windows SDK. They co-exist just fine; new versions don’t replace old ones. When I was an independent contractor, I had 4 versions of visual studio and 10 versions of windows SDK all installed at once, different projects used different ones.
      • malkia 8mo ago
        You can provide custom options to winget, and in there where to install it too (and additional components you need).
• asveikau 8mo ago
  Nitpick, "Windows Native Development" also refers to the NT native subsystem, which would be basically coding against private APIs instead of Win32. From the title I thought that's what this was. Then I realized it was about avoiding full use of Visual Studio when building C projects (something that a lot of people already do by the way)
  • smileybarry 8mo ago
    I would also read "Windows Native Development" as driver development or compiling directly with `nmake` (neither of which are described there).
• wosined 8mo ago
  Why not just use Linux?
  • jatari 8mo ago
    Because some developers would like to make money at some point.
    • zer0zzz 8mo ago
      Then why would they make applications for a dying platform? Is there some budding market for native win32 apps that I'm not aware of?
  • zer0zzz 8mo ago
    To play devils advocate, Linux does pose some issues as far as a stable platform base. They don't even guarantee glibc compatibility afaik.
• trilogic 8mo ago
  WOW such a great work. Myself I have been struggling with Mingw just to compile from source. Of course it works much cleaner then the hated visual studio, but then when it comes to cuda compile, that´s it. Visual studio or the magority our there, It is invasive and full of bloatware like you say. Same struggle with electron. How to match it with cuda to compile from source the repos?
• int0x29 8mo ago
  Last I checked the license for the headless toolchain requires that a full licensed copy of Visual Studio be installed somewhere. So I think this violates the license terms. A bug got opened against the rustup installing the headless toolchain by itself at some point. I'll see if I can find it edit: VSCode bug states this more clearly https://github.com/microsoft/vscode/issues/95745 https://github.com/microsoft/vscode/issues/95745
• yellowapple 8mo 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 8mo 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/ https://www.mingw-w64.org/downloads/
    • yellowapple 8mo ago
      > 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/ https://www.mingw-w64.org/downloads/ One of the options on that page is MSYS2, which I specifically listed above alongside MinGW-w64. And that download page is much smoother sailing: https://www.msys2.org/ https://www.msys2.org/ There are other options on the MinGW-w64 page, but most of those are for cross-compiling from non-Windows operating systems (which conceivably could include something running on WSL these days), and of the Windows-host options, the only two with “many” packages are Cygwin and MSYS2 (though WinLibs looks interesting).
  • duped 8mo ago
    Because it's fewer hoops and hurdles than using MinGW, in my experience.
  • forrestthewoods 8mo 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”.
• remix2000 8mo 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 8mo 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 8mo 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… ^^"
• zer0zzz 8mo ago
  Please people, stop trying to fix windows and just let it die.
• ManuLinares 8mo ago
  c3 does this automatically, I implemented the same thing :) https://github.com/c3lang/c3c/pull/2854 https://github.com/c3lang/c3c/pull/2854
• ddtaylor 8mo ago
  As someone who is out of the loop on Windows development, is this related to the Windows Driver Kit (WDK, I think it used to be DDK)? That's a certain type of hell I don't wish upon most.
• cptskippy 8mo ago
  I'm not trying to diminish or take away from this post but Visual Studio is an IDE and is not necessary to build an App. You just need the required build tools. If you've ever had to setup a CI/CD pipeline for a Visual Studio project then you've had to do this.
• kfsone 8mo ago
  Gross ignorance and incompetence. TLDR: I don't understand my native command line, see how lost I got when I tried to do my thing in a different environment. - Not a unique problem to Windows or even MSVC; He's gonna hate XCode, - Making Python a bootstrap dependency = fail, - Lacks self-awareness to recognize aversion vs avoidance, My background is distinctly non-Windows, but I survive around Windows so well that people think I'm a Mickeysoft type. And no, I don't use mingw, cygwin, ... If any of the obstacles this user faced were legitimate, nobody would ever make any money on Windows, including and especially Microsoft - a company whose developers have the same challenges. I'm being harsh because _mea quondam culpa_ and it's correctable. Everything this user went thru is the result of aversion instead of avoidance. To _avoid_ long deep dives into Windows, you need to recognize there is a different vocabulary and a radically different jargon dialect at play. 1. Learn a tiny minimum of Powershell; it's based on the same POSIX spec as bash and zsh, but like Python, Javascript, etc, instead of byte as the fundamental unit, they use objects. So there's less to learn to reach a greater level of convenience than soiling yourself with DOS/CMD/BAT. On Windows, pwsh has a default set of linux-like aliases to minimize the learning required for minimal operability. And never have to type \ instead of / for a directory separator. 2. Microsoft make money from training. To sell their meat-free steak (* ingredient: saw dust), they feed the suits an all-you-can-eat calorie, nutrition, and protein free buffet of documenting everything in great detail and routinely "streamlining" the names and terminology. Development on Windows is in a different reference frame, but relative to their own reference frames, they're ultimately not all that different. Approach in your "foreign language" mindset; English alphabet but the words mean different things. 3. What not how. "How do I grep" means you are trying to random access bytes out of a random access character stream. "What's the command to search for text in files?" well, if you're bloody mindedly using cmd, then it's "find". 4. Seriously, learn a little Powershell. I only approached Powershell hoping to gain material for a #SatansSphincter anti-ms rant while using it as a Rosetta Stone for porting shell scripts in our CI for Windows. I mean, it is based on the same POSIX spec as sh, bash, and zsh, with a little Perl thrown in. That can't not go horribly, insidiously, 30-rock wrong in the hands of MS, right? Turned out, it's the same paradigm shift perl/shell users have to make when coming into Python: from `system("ps | grep hung")` to `"hung" in system("ps")`; from `system("ifconfig -a | sed 's/\<192\.168\.0\./10.0.0./g'")` to `system("ifconfig -a").replace("192.168.0.", "10.0.0.")` `grep` is a command that applies an assumption to a byte stream, often the output of a command. In powershell, executing a command is an expression. In the case of a simple command, like "ps", that expression resolves to a String, just like system(...) does in Python. Learning even a small amount of Powershell is immensely helpful in better understanding your enemy if you're going to have to deal with Windows. The formal names for official things use "verb-singularnoun". That last part of the convention is the magic: the naming of things on Windows is madness designed to sell certifications, so crazy even MS ultimately had to provide themselves a guide.
• forrestthewoods 8mo ago
  > I fixed > msvcup is inspired by a small Python script written by Mārtiņš Možeiko. No. Martins fixed. OP made a worse layer on top of Martins great script.
• jacobgorm 8mo ago
  I’ve found that just installing LLVM, CMake and Ninja is enough to get started developing on Windows for most things C/C++.
• gnarlouse 8mo ago
  “Don’t do it” I fixed windows native development. Band together friends, force WSL3 as the backbone of Windows.
• userbinator 8mo ago
  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.
• _carbyau_ 8mo ago
  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.
• borland 8mo ago
  I thought the title was clickbait, but no, he really did fix it! Nice
• tehologist 8mo 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
• mathstuf 8mo ago
  We manage Visual Studio on our CI machines using Ansible. Chocolatey installs the full Visual Studio and then we use the APIs provided to manage components via Ansible. See our action here: https://galaxy.ansible.com/ui/repo/published/kitware/visualstudio/ https://galaxy.ansible.com/ui/repo/published/kitware/visuals...
• kreelman 8mo ago
  Wondering.... Has anyone tried doing this on ReactOS? I know this is a touch DIY, but it would be interesting to know if Win sofware could be built on ReactOS...
• worik 8mo ago
  rm -fr /
• bronlund 8mo ago
  The ironic part is that Visual Studio may be the best product Microsoft has ever made. Compared to the rest of their offerings, it is nothing short of amazing. It boggles the mind to know that this was developed in-house - well most of it anyways.
• liendolucas 8mo ago
  > 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.
• Lvl999Noob 8mo ago
  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.
• doctorleff 8mo ago
  In the 1990s, I taught GUI programming with the following two books (not necessarily those editions). Is this post the tool chain to do that program creation from the command line for these? Now that I am retired from a third of a century as a computer science faculty member, I would like to resurrect those notes for a comprehensive learning module on GUI programming. (At the turn of the century, my University had me teach GUI programming with Java Swing.) In my opinion, all are wonderful as is old-fashioned x-Windows GUI programming and Visual Basic form development, both of which I briefly introduced to my students. Programming Windows with MFC, Second Edition Subsequent Edition by Jeff Prosise (Author) Programming Windows®, Fifth Edition (Microsoft Programming Series) Subsequent Edition by Charles Petzold (Author)
• jesaemolisa 8mo ago
  [dead]