This sounds great. Got to try if that is compileable with mingw. I also wonder if that would work when you run Windows 3.1 in Dosbox 😀

Is the patch against 0.65 release or "current" CVS?

Also if there are two patches to download and apply you are not linking to the second one but two times to the same one.
Edit2: Ah, I found it, you submitted your patches to the bug section of Dosbox and not the patches. But I'm sure a developer can move it to the right section (and maybe a mod can move the topics here to the patch section 😀)

I moved all my patches to one place. Please refer to Access to device names LPT1, LPT2, LPT3, LPT4 in DosBox

This clipboard patch sounds good. I wanted to be able to write an application in VBDOS that would run under DOSBox, and have it transfer data with a Windows application. I was thinking about putting a trap door in the DOSBox source code, and using it to transfer control to a Windows application. Seems like DOSBox intercepts internal commands in "dos_programs.cpp", in lines like:

PROGRAMS_MakeFile("IMGMOUNT.COM", IMGMOUNT_ProgramStart);

It seems like it is there that it intercepts the command "IMGMOUNT.COM" from the command line and then transfers control to the function "IMGMOUNT_ProgramStart ()". So seems like I could drop in an extra command there, which could transfer control to a Windows app. Not sure what kind of side effects it would have, but seems like that would work.

It would be cool to be able to create a data type called 'DOSBox', where .Net applications could instantiate a DosBox object:

Dim myDOSBox As DOSBox
myDosBox = new DosBox ("config.bat")

The constructor would just start DOSBox with the config file. Then the trap door would suspend DOSBox and relinquish control to the calling application. Then the calling could transfer control back to the DOSBox program again, and back and forth.

Then, sub-routines could be written in VBDOS