That might be hard (or even impossible) to pull off because as I understand it, DosBox was designed to work as a virtual machine, and as such the degree that it can interact with external programs is quite limited.

I plan to implement a custom driver that is loaded before the game starts and then have the driver handle synchronization with the game and the external program. Would this sort of setup even be possible?

You could register a custom I/O handler in Dosbox and use port I/O from within dosbox to execute the native I/O handler. Just choose some unused I/O location. See keyboard.cpp for example:

1static void write_p61(Bitu port,Bitu val,Bitu iolen) {
2    // Native code here
3}
4IO_RegisterWriteHandler(0x61,write_p61,IO_MB);

Now when the emulated program does an "out" on port 0x61, write_p61() is executed.

ripa wrote:

You could register a custom I/O handler in Dosbox and use port I/O from within dosbox to execute the native I/O handler. Just choose some unused I/O location.

Thanks for the info, now I at least know that what I want to do is possible.

I understand some people are already using gamewiz32 in Windows to change values in DOSBox's memory (and hence affect programs running within DOSBox).

Using WriteProcessMemory on game code doesn't turn out well IF using dynamic core. WriteProcessMemory on data works AFAIK however it can be at different memory locations for every user/session/version, you'll have to search memory for a game string or something and use that as a base address.

IPX and the parallel port are some others ways to talk to things outside of the box. However, dosbox is open source so you can integrate with it directly as needed.

(system shock?)

The emulated memory is a contiguous block so using the recompiler doesn't change that you
can read/write/search the target visible physical memory. Whether or not that's useful is a different story
(setgmented memory, paging etc).