I used to work for a (no defunct) company, ARDI, that made a Mac emulator. We dynamically translated 68K to x86 and did a clean room reimplementation of Mac OS 9. (Yes, crazy.) Much of the job involved debugging the OS when running 3rd party software (binaries). The first step was to collect a syscall trace. Then lots of thought experiments. It was a great way to develop extreme debugging skills.
As a business? No. As a hack? It was compatible with quite a bit of software and with syn68k on a Pentium whatever of the time, it was faster than any Mac.
Your my hero, I used this to play Escape Velocity before the Windows port. Anyways, Mac OS 9 doesn't run on 68k and exucator didn't run PPC applications?
Haha, awesome! Glad you enjoyed it. Yeah, we did a lot of "testing" on games. Yeah, I misremembered, it was OS 7. As far as I know, there was no PPC version.
Syscall tracing works well for debugging applications or pieces of one that interact externally, or for ensuring that the OS is doing what you think it should, but I've found that more often than not the buggy part is "inside"; e.g. if an output file is incorrect, you would be able to see the incorrect data being written to it via the OS (which would've been clear from inspecting the file itself), but not what lead to that.
Coincidentally, I prefer to use an Asm-level debugger (WinDbg, OllyDbg) whenever I need to use one - which for debugging something I wrote, is not very often. Maybe it has to do with the fact that I started with Asm and disassembling other programs, so it's relatively straightforward to map between source code and the instructions the compiler generated. This also helped with figuring out a very subtle compiler bug - I know that they're quite rare, but when they do occur, they tend to be extremely difficult to figure out otherwise.
As someone who seldom leaves higher-abstraction languages, I've had some fun using Cheat Engine against old single-player games. I remember being pretty proud of the first time I managed to replace a few instructions with a larger set sitting in a code-cave. (Nothing impressive for those who learned assembly in a structured way, of course.)
Ah, Cheat Engine. I used to use it for multiplayer flash or shockwave games, as well as a couple other games along the years. Poor Nitto 1320, we killed that game. Got me into disassembly and hacking at that level, which was a lot of fun too.
That's actually how the auto assembler in CE works. It replaces the selected instruction with a jump to a code cave and places a jump back to the original code at the end.
From what I understand it report all interactions with the filesystem after its launch, it does tell you what process is currently accessing which file. lsof does a pretty good job for that.
For those on Windows, the excellent System Internals suite contains "Process Monitor", which does pretty much what you'd expect, allowing you to see all sorts of file (and registry) activity.
SysInternals procmon.exe and procexp.exe are the only things I really miss when on Linux (either developing or just troubleshooting Firefox being slow again.)
A few procmon features you probably weren't aware of:
- It can log your boot process (by loading a driver very early in the boot process)
- It stores a lot of details about every line of output, including a stack trace (!), accessible by doubleclicking
You could setup something almost like it. mlocate is the defacto indexed filename search for linux, and the update script skips directories that haven't been updated - so an update call is quite cheap. You could run it every 15m, and have 'almost' uptodate indexed search.
Most systems should have it setup to run daily out of the box.
Agreed. I get by without having things I'm used to on my linux system like strace, lsof and so forth with it. It has a pane that displays pretty much everything with a handle from non-IP IPC sockets, normal sockets, files, registry, threads, DLLs and even obscure stuff like event handles and security context tokens.
