Forty years ago I had a Sinclair QL with an 8086 emulator. Because the Sinclair QL had preemptive multitasking, I could easily search memory for patterns, monitor locations, stop and start the emulation, or change memory programmatically and easily from the QDOS side. It was worlds easier than using a debugger, particularly since I didn't own an 8086 system.
I always thought it was a clever way to get insights in to software while it was running that wasn't available to people with 8086 systems, and it's interesting to see this idea so many years later.
Bochs and MAME both have superb and widely-used debuggers, while Qemu is more limited but still has some debugging capabilities in its monitor, as well as a gdb integration. (Can’t say anything about PCem/86Box.) It seems that developers of emulators targeting good coverage of old stuff simply can’t not build a debugger, because it’s an integral part of their task to figure out what the hell the devs of the latest failing thing did to make it fail. Bochs is (was?) also quite popular in the OSDev scene as a debugging tool.
DOSBox can be configured to include a debugger. The feature is not enabled in the official binary but the enhanced derivative projects probably have it (DOSBox-X definitely does):
- https://www.vogons.org/viewtopic.php?t=3944
- https://github.com/joncampbell123/dosbox-x/wiki/DOSBox%E2%80...
DOSBox-x on FreeBSD at least has is disabled by default, but it can be enabled when building from ports (make config).
https://github.com/joncampbell123/dosbox-x/blob/master/READM...
Hey because I don't feel like making a phone call to my BSD expert, is that a flag? Like in Gentoo it would be like
USE="debugger" emerge -vaD bochs #portage reads env and will set flags this way or in /etc/portage/packages.use/bochs (folder name packages.use is arbitrary and I'm old school.)
Curious if BSD is like that too and I am way to tired to attempt to search for it with correct words...
You don't do that systemwide in FBSD, instead during the build from source for that single port. Optionally even interactively by curses interface.
Oh yeah, that is right. thank you! i didn't want to have to install a bsd just to check, i don't have one handy right now!
to clarify: USE="debugger" would be a flag that the package has, when you call the package manager to build it from source it just enables that in the make or whatever. package.use is if you want to make sure that some other package doesn't uninstall/modify your package. I am doing a poor job of explaining.
package.use is useful for maintaining your flags during upgrades. USE="debugger" or USE="-debugger" are one off, and i should have specified by putting emerge -va1D bochs (or whatever)
gentoo is a source-based OS, in a similar way to at least the bsds i've used.
Gentoo does have "system wide USE flags" they go in /etc/portage/make.conf, where you would set like USE="-gtk -alsa -X" or whatever, and portage will balk if some package tries to pull in masked packages. "Package has been masked by USE -X"
make.conf makes sure that specific tech stacks won't be pulled in as dependencies unless you specifically unmask the flag for that package in package.use or USE="" emerge[...].
package.use is where you keep your "this is how i want this software built when you do it for me" {this part is wrong, but i don't feel like explaining all of the portage package dot whatever weirdness, because anyone who started using gentoo in the last decade or so might strongly disagree with my assertions about naming and other convention - Ed.}
USE="" is if i need to install some package with a specific feature that isn't enabled by default. Such as debugging real mode or whatever. I generally only USE="" if it's something i need for a few moments and then gets uninstalled. On a source based OS keeping oddball archive support packages or whatever adds time and heat to your updates.
De nada. There is more to ports, as described in here: https://docs.freebsd.org/en/books/handbook/ports/#ports-usin...
In general, compared to gentoo, things like buildflags, for CPU(-features/levels/generations), general compilerflags like -02 or -O3, and linker-flags would be set for the build of the kernel, or additionally the 'world'.
IF you are building from source at all. 'World' meaning the complete basic userland, in sync with the kernel, as one cohesive thing, (or in linux-speak the base image of the 'Distro/Distribution')with individual choices of 'ports' runnig atop of that.
That's less granular than gentoo. OTOH gentoo can be used with binaries too, or not?
Anyways, the fine granularity of gentoos use-flags isn't replicated anywhere else, afaik.
(Yah well, Paludis on Exherbo possibly, but too much hassle for me)
If you ask nixers (Nix-Os) about it, they don't get it, because of reproducible builds.
And on FBSD, I had the feeling that too much 'ricing' is being frowned upon.
Though I did that, a looong time ago, with both Free- and NetBSD.
Nowadays I'm just relying on others doing the 'tuning' and compiling for me(mostly), and in case of CachyOS that works really well for me, atm.