Nitpick, the article’s suggestion that Git badly supports Windows strikes me as about 2 decades out of date. I dev on native Windows (only using WSL for key tools like sl and cowsay) and Git has Just Worked pretty much ever since I began using it.
Maybe the only speedbump is that you gotta remember to turn off the “autocrlf” setting, which has a default from way back when there were still editors on Windows that choked on \n.
Windows can't handle symlinks in a sane way because they're a source of privilege escalation exploits on Windows. So git repos with symlinks in the require a security degradation to use them natively.
Performance also still sucks, although the VFS stuff in the Microsoft fork kinda helps I guess.
Having only recently dropped Windows as my OS of choice for professional matters, I can get behind this statement. On rare occasions, the line ending stuff got weird. Other than that, it was smooth sailing.
As a primarily Windows developer of video games I find developing on Linux far more frustrating, fragile, and error prone than Windows.
However it's less about which is better or worse, and more about the devil you know. Setting up a brand new macOS for development is excruciating. Learning Linux is an extremely long, time consuming, and painful experience. But once you've built up some scar tissue it doesn't seem so bad!
> The cleanest way is to just use Linux on Windows
Hard hard hard disagree. I could not possibly disagree more strongly. I violently and disrespectfully disagree.
> The other option is to use Windows proper
This is the way. Don't use Cygwin or MinGW-64. That is bad advice.
I write a lot of C++ code. It typically needs to run on Windows, macOS, Linux, and Android. My experience is that Windows developers are generally content to step out of their comfort zone and work on macOS and Linux "natively". My personal lived experience is that Linux-first developers are far and away the least likely to even think of Windows or other platforms. They frequently refuse to request a Windows machine so they can even test another platform. Which means I have to fix all their broken code, grumble grumble. If you hard coded /usr/lib or similar you're a bad person.
My recommendation is to simply learn Windows and do things the native Windows way. Stop assuming all platforms are Linux. Cross-platform is a solved and relatively simple problem. Trying to force everything to behave The Linux Way is pain and suffering.
Personally I think "The Linux Way" is generally quite bad. Try something different! Be open to new experiences! Don't dip your toes in the water, jump in the deep end! You might learn a thing or two. And who knows, you may even discover it's quite pleasant.
Having done multi system projects you are spot on. Even those libs that cover over some of the differences tend to have a lot of interesting edge cases. For example threading will act one way on windows and a subtly different way on linux if you happen to use one of the popular threading libs. Even the CRT can have different cases for something simple like 'printf' (always re-read the docs for your compiler and platform before you port). So you end up with this weird glue abstraction layer anyway and quickly end up with config files for your paths.
In my experience doing systems programming across Windows, macOS, and Linux, there are a few specific areas where developing on Windows is the best platform. Game development is one of them: DirectX 12 is the industry standard graphics API, and the first- and third-party tooling related to it is cream of the crop on Windows.
.NET development is another area where Windows shines. And if you're comfortable living in Visual Studio and not really venturing into the CLI world, I can see Windows development being very nice. VS is truly the premier IDE.
With that said, for most other types of development, Windows is unergonomic or an outright PITA compared to Linux and macOS. Web development, data science, embedded, scientific computing, general scripting, and anything related to CLI tooling and development. This isn't a secret either: it's why WSL was launched to such acclaim from developers.
What you're developing makes a big difference. If you're making games and writing C++ in UE, or used to working with blueprints, or developing for graphics, then trying to do the same in Linux will be a horrible experience. This is why people don't tend to use Linux to write games. However, if you're developing for the cloud or writing applications or anything involving servers and scale (arguably the majority of software being developed today), then the exact opposite is true.
I think the reason that this post exists is that, sadly, software devs don't always get to choose their OS. Many (lazy, old-fashioned) organisations with huge managed fleets of CrowdStrike-infected Windows laptops still insist on shipping the same machines to their software teams as they do to their salespeople, forcing the former to figure out how to get stuff built while effectively working in shackles. I think that's who this post is targeted at and the problem it tries to solve.
I disagree with you that cross-platform is a solved and relatively simple problem. That may be the case for UIs/desktop apps/games, but it certainly isn't for cloud-relevant software.
I 'violently and disrespectfully disagree' that somehow developers are trying to 'force everything to behave The Linux Way'. The software that powers the modern world and that we end up talking about on here most of the time, simply doesn't run on Windows, it runs on Linux. Windows may be a very popular desktop OS, but it is also a huge steaming pile of candy-crushed turd, and I don't think 'simply learning Windows and doing things the native Windows way' is advice I would ever give anyone, ever.
_Unless_ you're a game dev.
On that point, I do think this post is titled badly, and suffers a bit from the HN bias that 'development' always means clouds and data and scale. Maybe a better title, something like 'coercing Windows into building software that it isn't itself capable of running in production' would have saved you a few clicks.
It depends on what you are making more than anything. If you're writing services that will be deployed on Linux servers (to save cost, increase availability, etc), then using WSL2 is probably the best bet if you must use Windows.
I've done a fair amount of Windows services development as well as services deployed to Linux. I'll honestly take the Linux way, in particular Docker/containers as a target. It works when you build, works when you deploy, no surprises, no separately installing a dozen dependencies that blow each other up, like in Windows a lot of times.
We've gotten to the point where outside of some consumer-facing niches like gaming, or industries with vendor locked-in tooling, it's largely true that it's all Linux
despite being an extremist fan of free software, i pretty much agree with you. i ported patch(1) to cygwin back in the 90s (though i never did try to get my changes merged into the mainline)
the native windows way is often even worse than the linux way, but sometimes it's actually better and it's too bad linux doesn't do some things the windows way. exhibit a: the x11 protocol
what do you think of .net core? because as far as i know that's the only native-code-generating compiler for windows other than mingw-64 (and proprietary compilers)
I agree with your general sentiment that leaning into the platform and away from compatibility layers is a good strategy. There are reasons these things are differently and compatibility layers by you little and cost a dependency.
I think we disagree on some details. I don't think windows is a serious server OS, and never has been. Look at the crowdstrike failure, solar winds leak, or the yearly issues that are biting millions of people and there is no sane way to avoid.
So I am just surprised when you said:
> fragile, and error prone than Windows.
Are we living in the same universe?! Crowdstrike aside, every windows shop I have worked at, including EA and the USAF, had massive and constant CI failures if they could get CI working at all. Often they had teams of dozens working on remediating this stuff perpetually. These places also have infrastructure go down for the dumbest of reasons, like unscheduled updates or impossible version mismatches.
The Linux shops generally had predictable,repeatable, and knowable causes for failures. Places like TD Ameritrade and Nationwide Insurance go down because they screw up.
It isn't always like that, but the Unix/Linux shops I have worked at measure yearly downtime in seconds and windows shops measure uptime as a percentage.
> If you hard coded /usr/lib or similar you're a bad person.
1000% agree, but I also see plenty of hardcoded "c:\\" in code also written by bad people. I also find the amount of people who claim that "include "windows.h"" is always valid C++ is infuriating, like other platforms don't exist. The people including "dirent.h" (Unix DIRectory ENTries) are so common that the MSVC saw fit to implement it some time about VC6 and VC2022.
Writing cross platform code isn't that hard if you just test. 99% of the time it works to just write a wrapper around the platform call to do a thing and call that wrapper.
> My personal lived experience is that Linux-first developers are far and away the least likely to even think of Windows or other platforms.
I mean, it doesn't help that until 2019, the choice was unambiguously between "do it according to international standards and useful features" and "do it according to the Microsoft way and annoying bugs".
(support for Apple, by contrast, is largely a matter of whether you can afford the extortion fees)
The author's recommendation of a MinGW-W64 toolchain + Cygwin build utilities is the workflow I followed for several years before moving to MSYS2, before ditching Windows entirely a few months ago.
WSL did its job quite well, but asking a user to set up WSL is out of the question. It isn't well-suited for anything a non-technical person might want to touch.
One thing the author doesn't make clear is that MinGW-64 does not fully implement a Linux compatibility layer. For example, if you try to use MinGW to compile a program that calls fork(), you're going to have a bad time.
That's why Cygwin is still relevant today - its compatibility layer is much more comprehensive than MinGW, at the cost of an extra DLL that has to follow your program around. Also bear in mind that Cygwin has to do some really nasty things [1] to do everything it does. Whenever you run into a situation where the Unix API doesn't align with the Windows view of the universe, Cygwin runs the risk of introducing severe performance issues.
A great summary that should encourage more Linux developers to use Windows. Lots of utility with WSL2 and Hyper-V built in, you can run any Linux distro you like with a single click from the MS Store, while enjoying the great performance and UX on Windows 11 (once you turn off the ads -- yeah I know).
I use a combination of VS Code with WSL2 Debian -- so it's identical to my prod environment. It's polished, consistent with prod and efficient on my hardware.
Compared to the Mac I find the Windows experience to be far better, because of the native Hyper-V VM support, better Linux compatibility with WSL2 and the much more diverse hardware options. The PC ecosystem is incredible.
Even the Windows ecosystem is nice, Visual Studio Community is free, the CLI compiler is available, winget makes installs easier, Powershell has a lot of utility and Windows Terminal is excellent.
Given that you can pick up a capable mini PC for about $200 , it's worth testing out. Windows is great for Linux development.
I've been developing on Windows the last year and a half. I came from a Linux background and wanted to learn how to use Windows in the same way I used Linux, that is to say, I wanted to avoid finding "bash on Windows" solutions and calling it a day.
My advice, install Visual Studio (or just the build tools), fire up the developer command prompt for your architecture, then learn the cl (compiler) and ml (the assembler) command line invocations. Many common Unix commands have an equivalent command prompt command you can learn. It just takes some repetition to remember them.
I will be the first to admit, it's very funky. Copy and move have some quirks (use xcopy or robocopy). Batch scripts execute in a really uninituitive way. There are a lot of rough edges but you can develop C and C++ like you would on Linux with a terminal and text editor, it just takes some getting used to.
My go to on Windows is LLVM using the Windows SDK for libc. Before Microsoft had solved the whole msvcrt redistributable mess I used mingw-64 as the libc which worked pretty well actually.
This article doesn't quite land for me.
It could perhaps use an introductory paragraph explaining who it's for / what the goal is.
For example, are we trying to build cross-platform software, with a single build system?
> If you want to develop C or C++ on Windows, your options get more complicated.
This is a weird thing to say.
If you want to build software for Windows -- especially so in C or C++! -- your choice is simplified.
The best way to build software for Windows is to use Windows tooling.
MSVC is excellent at compiling standard portable C and C++ code to a native windows executable.
If you write portable code, it will compile with any of the major compiler suites, for any of the platforms they (fully) support.
I'm working on software, that was originally written in CORAL and running on mainframes and then translated to C to run on UNIX.
Company policy is, that all programs have to run on Windows, so nowadays we work with Cygwin
Don't get me wrong, it works, but there a thousand annoying things, bugs an inconveniences.
I'm currently spearheading an effort to migrate to wsl2 (and docker). The developer experience is vastly better on wsl.
After falling out of love with macOS a couple decades ago, I've been using WSL/VMs on Win{7|10|11}. While I sort of detest the ads on my corporate Win11 laptop, it's what the corporation requires I use. VirtualBox on Win7 was a very usable solution. WSL1 on Win10 was a tiny bit rough, but WSL2 on Win10/11 has been pretty decent. The only problem I have is it's unclear who "owns" mDNS: windows side or leenucks side. For most of the last several years it just plain didn't work on the leenucks side. Then a work-around was published, but it seems to not work now.
But... I love small charts like this. I hadn't been thinking about cygwin or MinGW. It's good to be reminded they still exist.
The only issues I have when developing natively on Windows are when other developers on macOS don't use cross-platform tools (bash scripts). Scoop is a great package manager, and with windows-terminal + powershell you can't really ask for anything better.
Something about synchronicity, serendipia, Jung, David F.Peat... must be true, because I've been trying to compile stuff with mingw for days and then it's not odd to see that either at HN, Reddit or the Spanish Digg/Reddit clone.
Jokes being put aside, I've got to cross-compile Kristall for MinGW (Windows 32 bit target, for W7), but it required tons of deps and it the end it gave me errros on some libs, so I will rebuild it statically with the full src in a parallel tgz. At least it launched with an error under Wine (dynamic binary), so I can say mingw32 works fine.
I tried to the same with Lagrange, but it gave me an error on libUnistring. As the $DISTRO I use didn't provide it as a MinGW package, I gave up.
Just download the latest visual studio, no need for gimmicks or trying to reproduce the unix dev experience on windows, just embrace the platform, warts and all, and call it a day.
If you are going to develop on Windows and you aren't developing for Windows, you are what the construction and film production industries call "green".
I don’t like this article as it seems the author did not dive a bit into some of the topics he mentions.
As an example I wanna point out WSL2 and USB support:
Honestly, Qt C++ & QML is the best way to develop on Windows (and Linux). Soon enough, I'll also prove it's the best for macOS (under some specific expectations).
I've been using MinGW and MSYS for Windows development since the early 2000's, mainly to keep the build process consistent with Linux. A couple of years ago I gave Visual Studio / MSVC a second chance and have stuck with it ever since.
MSVC generates significantly faster & smaller code, doesn't require additional DLLs in the final build, and the C++ compiler behaves predictably. Critically it also works very well with CMake, so my build process is seamlessly aligned with Linux.
The VS debugger is a major help too - gdb can do the same stuff, and there are UIs for gdb, but debugging through VS is just more productive and convenient. Times change!
[+] [-] skrebbel|1 year ago|reply
Maybe the only speedbump is that you gotta remember to turn off the “autocrlf” setting, which has a default from way back when there were still editors on Windows that choked on \n.
[+] [-] pxc|1 year ago|reply
Performance also still sucks, although the VFS stuff in the Microsoft fork kinda helps I guess.
[+] [-] ryukoposting|1 year ago|reply
[+] [-] Kenji|1 year ago|reply
[deleted]
[+] [-] twiss|1 year ago|reply
A bit off-topic but this particular example becomes less surprising if you look up who created git :)
[+] [-] forrestthewoods|1 year ago|reply
As a primarily Windows developer of video games I find developing on Linux far more frustrating, fragile, and error prone than Windows.
However it's less about which is better or worse, and more about the devil you know. Setting up a brand new macOS for development is excruciating. Learning Linux is an extremely long, time consuming, and painful experience. But once you've built up some scar tissue it doesn't seem so bad!
> The cleanest way is to just use Linux on Windows
Hard hard hard disagree. I could not possibly disagree more strongly. I violently and disrespectfully disagree.
> The other option is to use Windows proper
This is the way. Don't use Cygwin or MinGW-64. That is bad advice.
I write a lot of C++ code. It typically needs to run on Windows, macOS, Linux, and Android. My experience is that Windows developers are generally content to step out of their comfort zone and work on macOS and Linux "natively". My personal lived experience is that Linux-first developers are far and away the least likely to even think of Windows or other platforms. They frequently refuse to request a Windows machine so they can even test another platform. Which means I have to fix all their broken code, grumble grumble. If you hard coded /usr/lib or similar you're a bad person.
My recommendation is to simply learn Windows and do things the native Windows way. Stop assuming all platforms are Linux. Cross-platform is a solved and relatively simple problem. Trying to force everything to behave The Linux Way is pain and suffering.
Personally I think "The Linux Way" is generally quite bad. Try something different! Be open to new experiences! Don't dip your toes in the water, jump in the deep end! You might learn a thing or two. And who knows, you may even discover it's quite pleasant.
[+] [-] sumtechguy|1 year ago|reply
[+] [-] dlivingston|1 year ago|reply
.NET development is another area where Windows shines. And if you're comfortable living in Visual Studio and not really venturing into the CLI world, I can see Windows development being very nice. VS is truly the premier IDE.
With that said, for most other types of development, Windows is unergonomic or an outright PITA compared to Linux and macOS. Web development, data science, embedded, scientific computing, general scripting, and anything related to CLI tooling and development. This isn't a secret either: it's why WSL was launched to such acclaim from developers.
[+] [-] boomskats|1 year ago|reply
I think the reason that this post exists is that, sadly, software devs don't always get to choose their OS. Many (lazy, old-fashioned) organisations with huge managed fleets of CrowdStrike-infected Windows laptops still insist on shipping the same machines to their software teams as they do to their salespeople, forcing the former to figure out how to get stuff built while effectively working in shackles. I think that's who this post is targeted at and the problem it tries to solve.
I disagree with you that cross-platform is a solved and relatively simple problem. That may be the case for UIs/desktop apps/games, but it certainly isn't for cloud-relevant software.
I 'violently and disrespectfully disagree' that somehow developers are trying to 'force everything to behave The Linux Way'. The software that powers the modern world and that we end up talking about on here most of the time, simply doesn't run on Windows, it runs on Linux. Windows may be a very popular desktop OS, but it is also a huge steaming pile of candy-crushed turd, and I don't think 'simply learning Windows and doing things the native Windows way' is advice I would ever give anyone, ever.
_Unless_ you're a game dev.
On that point, I do think this post is titled badly, and suffers a bit from the HN bias that 'development' always means clouds and data and scale. Maybe a better title, something like 'coercing Windows into building software that it isn't itself capable of running in production' would have saved you a few clicks.
[+] [-] tracker1|1 year ago|reply
I've done a fair amount of Windows services development as well as services deployed to Linux. I'll honestly take the Linux way, in particular Docker/containers as a target. It works when you build, works when you deploy, no surprises, no separately installing a dozen dependencies that blow each other up, like in Windows a lot of times.
[+] [-] autoexecbat|1 year ago|reply
We've gotten to the point where outside of some consumer-facing niches like gaming, or industries with vendor locked-in tooling, it's largely true that it's all Linux
[+] [-] kragen|1 year ago|reply
the native windows way is often even worse than the linux way, but sometimes it's actually better and it's too bad linux doesn't do some things the windows way. exhibit a: the x11 protocol
what do you think of .net core? because as far as i know that's the only native-code-generating compiler for windows other than mingw-64 (and proprietary compilers)
[+] [-] sqeaky|1 year ago|reply
I think we disagree on some details. I don't think windows is a serious server OS, and never has been. Look at the crowdstrike failure, solar winds leak, or the yearly issues that are biting millions of people and there is no sane way to avoid. So I am just surprised when you said:
> fragile, and error prone than Windows.
Are we living in the same universe?! Crowdstrike aside, every windows shop I have worked at, including EA and the USAF, had massive and constant CI failures if they could get CI working at all. Often they had teams of dozens working on remediating this stuff perpetually. These places also have infrastructure go down for the dumbest of reasons, like unscheduled updates or impossible version mismatches.
The Linux shops generally had predictable,repeatable, and knowable causes for failures. Places like TD Ameritrade and Nationwide Insurance go down because they screw up.
It isn't always like that, but the Unix/Linux shops I have worked at measure yearly downtime in seconds and windows shops measure uptime as a percentage.
> If you hard coded /usr/lib or similar you're a bad person.
1000% agree, but I also see plenty of hardcoded "c:\\" in code also written by bad people. I also find the amount of people who claim that "include "windows.h"" is always valid C++ is infuriating, like other platforms don't exist. The people including "dirent.h" (Unix DIRectory ENTries) are so common that the MSVC saw fit to implement it some time about VC6 and VC2022.
Writing cross platform code isn't that hard if you just test. 99% of the time it works to just write a wrapper around the platform call to do a thing and call that wrapper.
[+] [-] o11c|1 year ago|reply
I mean, it doesn't help that until 2019, the choice was unambiguously between "do it according to international standards and useful features" and "do it according to the Microsoft way and annoying bugs".
(support for Apple, by contrast, is largely a matter of whether you can afford the extortion fees)
[+] [-] tomas_impressi|1 year ago|reply
[deleted]
[+] [-] ryukoposting|1 year ago|reply
WSL did its job quite well, but asking a user to set up WSL is out of the question. It isn't well-suited for anything a non-technical person might want to touch.
One thing the author doesn't make clear is that MinGW-64 does not fully implement a Linux compatibility layer. For example, if you try to use MinGW to compile a program that calls fork(), you're going to have a bad time.
That's why Cygwin is still relevant today - its compatibility layer is much more comprehensive than MinGW, at the cost of an extra DLL that has to follow your program around. Also bear in mind that Cygwin has to do some really nasty things [1] to do everything it does. Whenever you run into a situation where the Unix API doesn't align with the Windows view of the universe, Cygwin runs the risk of introducing severe performance issues.
[1] https://cygwin.com/cygwin-ug-net/highlights.html
[+] [-] tonymet|1 year ago|reply
I use a combination of VS Code with WSL2 Debian -- so it's identical to my prod environment. It's polished, consistent with prod and efficient on my hardware.
Compared to the Mac I find the Windows experience to be far better, because of the native Hyper-V VM support, better Linux compatibility with WSL2 and the much more diverse hardware options. The PC ecosystem is incredible.
Even the Windows ecosystem is nice, Visual Studio Community is free, the CLI compiler is available, winget makes installs easier, Powershell has a lot of utility and Windows Terminal is excellent.
Given that you can pick up a capable mini PC for about $200 , it's worth testing out. Windows is great for Linux development.
[+] [-] carom|1 year ago|reply
My advice, install Visual Studio (or just the build tools), fire up the developer command prompt for your architecture, then learn the cl (compiler) and ml (the assembler) command line invocations. Many common Unix commands have an equivalent command prompt command you can learn. It just takes some repetition to remember them.
I will be the first to admit, it's very funky. Copy and move have some quirks (use xcopy or robocopy). Batch scripts execute in a really uninituitive way. There are a lot of rough edges but you can develop C and C++ like you would on Linux with a terminal and text editor, it just takes some getting used to.
[+] [-] invokestatic|1 year ago|reply
[+] [-] qwery|1 year ago|reply
> If you want to develop C or C++ on Windows, your options get more complicated.
This is a weird thing to say. If you want to build software for Windows -- especially so in C or C++! -- your choice is simplified. The best way to build software for Windows is to use Windows tooling. MSVC is excellent at compiling standard portable C and C++ code to a native windows executable. If you write portable code, it will compile with any of the major compiler suites, for any of the platforms they (fully) support.
[+] [-] osigurdson|1 year ago|reply
You likely have git installed anyway and this works very well. I use this all the time.
[+] [-] chrisweekly|1 year ago|reply
I use windows only bc I have no choice at work. the DX is painful.
[+] [-] majoe|1 year ago|reply
I'm working on software, that was originally written in CORAL and running on mainframes and then translated to C to run on UNIX.
Company policy is, that all programs have to run on Windows, so nowadays we work with Cygwin Don't get me wrong, it works, but there a thousand annoying things, bugs an inconveniences.
I'm currently spearheading an effort to migrate to wsl2 (and docker). The developer experience is vastly better on wsl.
[+] [-] OhMeadhbh|1 year ago|reply
After falling out of love with macOS a couple decades ago, I've been using WSL/VMs on Win{7|10|11}. While I sort of detest the ads on my corporate Win11 laptop, it's what the corporation requires I use. VirtualBox on Win7 was a very usable solution. WSL1 on Win10 was a tiny bit rough, but WSL2 on Win10/11 has been pretty decent. The only problem I have is it's unclear who "owns" mDNS: windows side or leenucks side. For most of the last several years it just plain didn't work on the leenucks side. Then a work-around was published, but it seems to not work now.
But... I love small charts like this. I hadn't been thinking about cygwin or MinGW. It's good to be reminded they still exist.
[+] [-] tomas_impressi|1 year ago|reply
[deleted]
[+] [-] vips7L|1 year ago|reply
[+] [-] rock_artist|1 year ago|reply
(I use winget as it seems to be now available out of the box)
[+] [-] anthk|1 year ago|reply
Jokes being put aside, I've got to cross-compile Kristall for MinGW (Windows 32 bit target, for W7), but it required tons of deps and it the end it gave me errros on some libs, so I will rebuild it statically with the full src in a parallel tgz. At least it launched with an error under Wine (dynamic binary), so I can say mingw32 works fine.
I tried to the same with Lagrange, but it gave me an error on libUnistring. As the $DISTRO I use didn't provide it as a MinGW package, I gave up.
[+] [-] CLiED|1 year ago|reply
[+] [-] commercialnix|1 year ago|reply
[+] [-] atVelocet|1 year ago|reply
https://github.com/dorssel/usbipd-win
This is the recommended way and works as expected. It is also possible to directly mount WSL2 drives with near native performance.
[+] [-] axus|1 year ago|reply
Installing git-for-windows was an easy way to try it out, to see if that rabbit hole is for you.
[+] [-] michaelsbradley|1 year ago|reply
https://www.msys2.org/docs/environments/
[+] [-] rubymamis|1 year ago|reply
[+] [-] anthk|1 year ago|reply
[+] [-] paul_manias|1 year ago|reply
MSVC generates significantly faster & smaller code, doesn't require additional DLLs in the final build, and the C++ compiler behaves predictably. Critically it also works very well with CMake, so my build process is seamlessly aligned with Linux.
The VS debugger is a major help too - gdb can do the same stuff, and there are UIs for gdb, but debugging through VS is just more productive and convenient. Times change!