(*) One caveat with respect to third-party libraries is that RemedyBG uses Intel's XED for diassembly. However, if you take a look at their dependencies they list the following: memcmp, memset, memcpy, strcmp, strncat, and strlen. No memory allocation, etc. Beautiful. I can get behind a library like this. Also, for the user interface, I am using Dear ImGui which has been a joy to use.
RemedyBG is a 64-bit Windows debugger written from scratch with the goal of replacing the behemoth Visual Studio debugger. Formerly, the idea was to integrate RemedyBG into the Vim text editor. However, doing so has slowed down development due to Vim's underpowered scripting language Vimscript (I'm no Tim Pope) along with how integrating external C-code was done (through Vim 8's jobs feature and through stdin/stdout/stderr -- ouch). I finally decided to ditch Vim (for this project, not as a text editor!) and render text windows in the debugger, instead. This also gives me the flexibility of rendering some interesting things like control flow arrows and so forth. I, for one, fully support the handmade philosophy: RemedyBG doesn't use any third-party libraries (*). This includes Window's own Debug Help Library (DbgHelp), Debugger Engine (DbgEng), or even a library for reading symbol files (PDBs). I played around with these libraries to judge their effectiveness. Yes, using them can get you 80% of the functionality you need very quickly but after that you are forever 20% away from sweetness. And besides, Visual Studio is using these libraries and the whole point was to get away from this beast! All the code for RemedyBG is written from scratch which allows for a great deal of flexibility with respect to the functionality that can be implemented. There are a lot of interesting features coming down the pipe after realizing the wealth of information that compiler emits (and that Visual Studio hides from us).