You're better of just calling it x86 to describe the 32-bit instruction set.
I love the connections between jumps and landing sites though, very helpful!
How hard would it be to port this to Linux? What would need to be ported? I don't have much free time, but I might be able to contribute to a port for Linux, given enough free time.
Is there a word for open source that has no revision history? (there's just a .rar file on that site). 7zip does it too and it drives me crazy.
Open Crap?
And indeed, a similar GUI-based debugger for Linux would be awesome as well.
The remote debugging support is also phenomenal, though you need a culture to support it. I've only seen it work really well on the MS campus.
There are many Windows users who prefer to use FOSS despite the OS itself not being so, and have more pragmatic reasons for using Windows over some other (possibly FOSS) OS.
IMO gdb isn't very good for binary-level debugging, which is pretty much a euphemism for reverse-engineering anyway. It'd be nice to have something like that. I tinkered around with building such a thing years ago[0] but I wanted it to be cross-platform (I was using PPC at the time). But found libdisasm to be a bit limited as a disassembler suitable for such a thing.
[0]. http://www.scaramanga.co.uk/stuff/debugger/l33t-debugger.png
Maybe it's just the way I use debuggers, but I don't find this to be a particularly compelling reason; I use instruction-level debugging quite often even when I have the source (debugging a program I wrote, when simpler methods fail), to [1] verify that the high-level language statements are doing the expected, [2] ensure that the compiler is generating the expected instructions, and [3] to observe where exactly the bug is.
> IMO gdb isn't very good for binary-level debugging
Having come from a Windows background, I'd say using gdb for that is an absolute nightmare - it appears to almost be designed to actively make it harder to do instruction-level debugging, despite the fact that the implementation of a debugger for source code is far more complex than one that doesn't. E.g. the "disassemble" command absolutely requires a symbol table, and will still complain if there's no "function" at some address, when all it really needs to do is start reading the bytes at the address it's given as a parameter - which could be the name of a symbol - and interpret them as instructions. Instead the somewhat unintuitive "workaround" is to use "x/i".
I highly recommend MinGW if you do any serious work on a Windows machine.
I had previously commented [6] on stability issues using mingw-w64. After some snooping using vmmap, Dependency Walker, and PE Explorer, I found that disabling the Windows Superfetch service dropped memory usage significantly. It turns out that this has been observed by cygwin devs [7]. I also disabled the Program Compatibility assistant, and my system now stays stable even after rebuilding LLVM and OpenBLAS multiple times.
[1] http://www.mingw.org/ [2] http://mingw-w64.sourceforge.net/ [3] http://msys2.github.io/ [4] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ [5] http://sourceforge.net/projects/mingwbuilds/ [6] https://news.ycombinator.com/item?id=7740930 [7] https://cygwin.com/ml/cygwin/2011-12/msg00058.html
1. Visual Studio is not free. Yes there is Visual C++ express but for a while it didn't have C99 support because in general it was only a C++ compiler. I believe C99 support was added with VS2013.
2. It's just really nice to use the same compiler on Linux, BSD and Windows. This is possible with GCC and LLVM but not Visual C++.
Microsoft tools are not bad (in fact I like SQL server over MySQL or Postgres) but because they aren't cross platform it's very difficult to adopt. them.
