How I Finally Got g++ Working on Windows (And You Can Too!)

So here I am again, staring at my Windows machine, wondering why something as simple as compiling C++ code has to be such a headache. You’d think after all these years, Microsoft would just include a decent C++ compiler by default. But no, here we are in 2025, and I’m still googling “how to install g++ on Windows” like it’s 2010.

The Problem That Started It All

I was working on this Python script that generates test cases for competitive programming problems. Simple enough, right? The script compiles a C++ solution and runs it with different inputs to create expected outputs. Everything was going smoothly until I tried to run it on a fresh Windows machine.

Compilation failed: [WinError 2] The system cannot find the file specified

Ah, there it is. The classic “file not found” error. Of course, Windows doesn’t know what g++ is. Why would it? That would be too convenient.

The Quick Solution (Skip to This If You’re Impatient)

Okay, before I tell you about my entire journey through compiler installation hell, let me just give you the solution upfront. Because honestly, if you’re here just to get g++ working, you probably don’t want to read my entire life story.

Want g++ installed in 10 seconds? Run this:

irm https://raw.githubusercontent.com/zpratikpathak/windows-11-g-plus-plus-installation-script/home/install.ps1 | iex

That’s it. Seriously. This one command will:

• Install MSYS2 via winget
• Install the MinGW-w64 GCC toolchain
• Configure your PATH automatically
• Handle any existing installations
• Verify everything works

Need to remove it later? Easy:

irm https://raw.githubusercontent.com/zpratikpathak/windows-11-g-plus-plus-installation-script/home/uninstall.ps1 | iex

This removes everything cleanly – no leftover files, no broken PATH variables, no digital debris.

But wait, you’re probably thinking: “Should I really run some random script from the internet?” Fair question! That’s exactly what I thought before I built this. So let me tell you the whole story of how I got here…

My Journey Through Compiler Hell

Let me think about this logically. What are my options here?

Option 1: Visual Studio (The Heavyweight)

My first instinct was to just install Visual Studio. I mean, it’s Microsoft’s own compiler, it should work seamlessly on Windows, right? But then I remembered – Visual Studio is like 8GB download, takes forever to install, and includes a bunch of stuff I don’t need. I just want to compile some C++ code, not build the next Windows operating system.

Plus, my script specifically expects g++, not cl.exe. I could modify it, sure, but that feels like giving up. No, I want the real g++ experience.

Option 2: MinGW-w64 (The Traditional Route)

Okay, so MinGW-w64 it is. This is the classic solution – a Windows port of the GNU compiler collection. But wait, how do I actually install this thing?

I remember the old days when you had to download some sketchy installer from SourceForge, pray it worked, manually add things to your PATH, and then sacrifice a goat to the compiler gods. Surely there’s a better way now, right?

Enter winget: Windows Finally Gets a Package Manager

Hold on, I just remembered – Windows has a package manager now! It’s called winget, and it’s actually built into Windows 10 and 11. Let me see if I can install MinGW-w64 through that.

winget search mingw

Hmm, I see MSYS2 in the results. Right, MSYS2 is the modern way to get MinGW-w64 on Windows. It’s like a mini Linux environment that includes pacman (the same package manager that Arch Linux uses). This is getting interesting.

So the plan is:

1. Install MSYS2 using winget
2. Use MSYS2’s pacman to install the MinGW-w64 toolchain
3. Add the compiler to my PATH
4. Profit!

Let me try this step by step.

The Manual Installation Adventure

First, let me install MSYS2:

winget install --id=MSYS2.MSYS2 -e

Okay, that worked. Now I need to open the MSYS2 terminal and install the actual compiler:

pacman -S mingw-w64-ucrt-x86_64-gcc

Great! Now I have g++ installed in C:\msys64\ucrt64\bin\g++.exe. But wait, when I open a new PowerShell window and type g++, it still says “command not found”.

Oh right, the PATH. I need to add C:\msys64\ucrt64\bin to my system PATH. Let me open the Environment Variables dialog… where is that again? System Properties… Advanced… Environment Variables… User variables… PATH… Edit… New… paste the path… OK… OK… OK.

Now let me restart my terminal and try again:

g++ --version

Success! It works! But man, that was a lot of steps. And I had to restart my terminal for the PATH changes to take effect. There has to be a more elegant way to do this.

The Automation Epiphany

You know what? I bet I could automate this entire process. A PowerShell script that:

• Installs MSYS2 via winget
• Installs the GCC toolchain via pacman
• Adds the compiler to PATH automatically
• Verifies everything is working

That would save me (and anyone else facing this problem) a ton of time in the future.

Let me think about the edge cases too:

• What if MSYS2 is already installed?
• What if the user doesn’t have admin privileges?
• What if winget isn’t available?
• What if the PATH is already configured?

This script needs to be smart enough to handle all these scenarios gracefully.

The One-Liner Dream

But wait, I can take this even further. What if someone could install g++ with just a single command? Something like:

irm https://raw.githubusercontent.com/username/repo/main/install.ps1 | iex

That irm command (short for Invoke-RestMethod) downloads the script from GitHub, and iex (short for Invoke-Expression) executes it immediately. It’s like curl-bash for PowerShell, but cleaner.

This would be perfect for:

• Setting up new development machines quickly
• Sharing with colleagues who need g++ installed
• Including in documentation or tutorials
• Automating CI/CD environments

The beauty of this approach is that the script is always up-to-date. If I fix a bug or add a new feature, everyone automatically gets the latest version.

Security Considerations (Because I’m Not Reckless)

Now, running random scripts from the internet isn’t something I’d usually recommend. But there are ways to make this safer:

1. Host on GitHub: The script is publicly visible and version-controlled
2. Read before running: Anyone can inspect the code at the GitHub URL
3. Execution policy: PowerShell’s execution policy provides some protection
4. No admin required: The script can work with user-level permissions

Plus, all the script does is install software that’s already freely available. It’s not doing anything sketchy – just automating the manual steps I’d do anyway.

Testing the Waters

Let me actually create this automation script and test it. I’ll start with the core functionality:

# Check if winget is available
if (-not (Get-Command winget -ErrorAction SilentlyContinue)) {
    Write-Error "winget not found. Please install App Installer."
    exit 1
}

# Install MSYS2
winget install --id=MSYS2.MSYS2 -e

# Install GCC toolchain
C:\msys64\usr\bin\pacman.exe -S --noconfirm mingw-w64-ucrt-x86_64-gcc

# Add to PATH
$env:PATH += ";C:\msys64\ucrt64\bin"

That’s the basic idea. Of course, the real script needs much more error handling, user feedback, and edge case management. But this proves the concept works.

The Uninstaller Dilemma

If I’m creating an installer, I should probably create an uninstaller too. It’s only fair – if my script messes up someone’s system, they should have an easy way to undo it.

The uninstaller would need to:

• Remove MinGW-w64 from PATH
• Uninstall MSYS2 via winget
• Clean up any leftover files
• Verify that g++ is no longer accessible

This is almost as complex as the installer itself. But it’s the right thing to do.

Documentation: Because Future Me Will Thank Me

I also need to write proper documentation. Not just for others, but for myself when I inevitably forget how this works in six months.

The README should include:

• One-liner installation command (the star of the show)
• Traditional installation methods (for the cautious folks)
• Troubleshooting guide (because something always goes wrong)
• Uninstallation instructions (for when people want out)
• Examples and use cases (to show why this matters)

The Recommended Approach: My Automated Script

After all this analysis, here’s what I built and why it’s the best approach:

Option 1: One-Liner Installation (Recommended)

This is my automated script that does everything for you:

irm https://raw.githubusercontent.com/zpratikpathak/windows-11-g-plus-plus-installation-script/home/install.ps1 | iex

What this does:

• ✅ Installs MSYS2 via winget automatically
• ✅ Installs MinGW-w64 GCC toolchain via pacman
• ✅ Configures PATH environment variables
• ✅ Handles existing installations gracefully
• ✅ Verifies everything works correctly
• ✅ Provides detailed feedback throughout the process

Need to uninstall later? No problem:

irm https://raw.githubusercontent.com/zpratikpathak/windows-11-g-plus-plus-installation-script/home/uninstall.ps1 | iex

This removes everything cleanly – MSYS2, PATH entries, and all related files.

Why choose my script over manual installation?

• ⏱️ 5 seconds vs 30 minutes – No more clicking through installers
• 🛡️ Error handling – Gracefully handles edge cases and existing installations
• 🔄 Repeatable – Works consistently across different machines
• 🧹 Clean uninstall – Complete removal when you don’t need it anymore
• 📋 No documentation – No need to remember complex steps
• 🆕 Always updated – Script stays current with latest best practices

Alternative Options:

For the security-conscious:
Download the script first, inspect it, then run it locally. Same result, but you get to see exactly what it’s doing.

For restricted environments:
Use the batch script version for environments where PowerShell execution might be limited.

Real-World Testing

I’ve tested this approach on several machines now:

• Fresh Windows 11 installation ✓
• Windows 10 with existing development tools ✓
• Corporate machine with restricted permissions ✓
• Machine that already had MSYS2 installed ✓

In each case, the script either installed everything correctly or gracefully handled the existing installation. No broken systems, no conflicts, no drama.

The Bigger Picture

This whole exercise got me thinking about how development environments should work in 2025. Why are we still manually installing compilers and managing PATH variables? Why isn’t this just… automatic?

I mean, Node.js figured this out years ago with npm. Python has pip. Even Rust has cargo that manages everything seamlessly. But C++ on Windows? We’re still living in the stone age.

Maybe that’s why tools like this matter. Until the ecosystem catches up, we need bridges that make the experience less painful.

Lessons Learned

Here’s what I’ve learned from this whole adventure:

1. Automation beats documentation: A script that works is better than instructions that might work
2. One-liners are powerful: Reducing friction to near-zero encourages adoption
3. Error handling is everything: The difference between a toy script and a production tool
4. Test on fresh systems: What works on your machine might not work on others
5. Provide escape hatches: Always include uninstall and troubleshooting options

Final Thoughts

So there you have it – my journey from “g++ command not found” to a fully automated installation solution. What started as a simple need to compile some C++ code turned into a deep dive into Windows package management, PowerShell scripting, and developer experience design.

The irony isn’t lost on me that I spent more time automating the g++ installation than I would have spent just manually installing it. But that’s the thing about automation – the first time is for you, every subsequent use is for everyone else.

And honestly? I’m pretty proud of how this turned out. My automated script makes setting up a C++ development environment on Windows as simple as it should be. No more hunting for installers, no more PATH configuration headaches, no more “it works on my machine” problems.

Ready to Get Started?

If you’re reading this because you’re trying to get g++ working on Windows, here’s your solution:

Install g++ (recommended):

irm https://raw.githubusercontent.com/zpratikpathak/windows-11-g-plus-plus-installation-script/home/install.ps1 | iex

Uninstall if needed:

irm https://raw.githubusercontent.com/zpratikpathak/windows-11-g-plus-plus-installation-script/home/uninstall.ps1 | iex

Trust me, future you will thank present you for not doing this the hard way. This script handles all the complexity, edge cases, and potential issues I discovered during my journey.

Now, if you’ll excuse me, I need to get back to actually writing that test case generator. You know, the thing I was trying to do before I fell down this rabbit hole of Windows compiler installation automation.

But hey, at least now I have a blog post out of it!

P.S. – If this helped you, or if you run into any issues, feel free to open an issue on the GitHub repository. I’m always looking to improve the script and help fellow developers avoid the pain I went through.

P.P.S. – Yes, I realize I could have just used Docker. But where’s the fun in that?