Actually you can treat MUNT as a plugin
A plugin not only for DOSBox, but a universal plugin for everything 😀

After all from the time since Dosbox started to emulate MPU-401 we use this type of "plugins" for General MIDI/Sound Canvas. And even a real card/module can be treated as a "plugin" of this type, that works with DosBox without any problem. 😀

So no need to add anything to dosbox. You can use it with any MIDI emulator or any real MIDI hardware.

Different video cards plugin.....

a parallel pass through plugin?
a printer plugin (based on the patch)?

Joystick emulation plugin? I mean, something like CH emulation, Thrustmaster emulation... more than 2 axis, 2 buttons emulation.

hmm already present ?

Didn't know... I have a Gravis Phoenix (joystick port) and a Saitek X45 (USB)... maybe I'll give them a new try...

NE2000 plugin, real IPX plugin

Zup, don't forget to update your dosbox.conf as well. This change is in CVS only, btw.

A Plugin system could have a huge impact, if the plugin interface would stay mostly constant and not change too much in between versions.
For example the printer patch needs to be maintained and you really need to know something about coding to make it compatible with Dosbox CVS. Hopefully with a plugin interface there wouldn't be that much need for doing this.

but then a plugin system is just trouble waiting to happen. Dosbox crashes or won't start up because of an old incompatible plugin (say the graphics card interface changes so much in between versions that a graphics card plugin just crashes Dosbox).

And AFAIR it has been stated before that it would not really be doable anyway...

AFAIR there had already been a plugin system but they removed it because nobody used it.

There was indeed a plugin system that was scrapped a few month after the DOSBox source was released on sf.net.

Dominus wrote:

but then a plugin system is just trouble waiting to happen. Dosbox crashes or won't start up because of an old incompatible plugin (say the graphics card interface changes so much in between versions that a graphics card plugin just crashes Dosbox).

You do make a valid point. I've had that kind of trouble with other programs that support plugins, but let's face it, there is no such thing as a crash-proof computer and there never will be, either.

Now, don't go saying that consoles never crash, as I have successfully crashed a game on the Playstation 1 and interestingly enough, I've managed to duplicate this crash in a couple of emulators, too. I can't remember which emulators I managed to duplicate the crash with, though.

As for the problem with old plugins that could crash DOSBox, well there's nothing stopping anyone from including a note in the documentation (or perhaps on the welcome screen) saying that users should keep their plugins up-to-date and also having DOSBox come with a few official, stable plugins.

It seems to me, and as only an amateur programmer I’m more than willing to admit that I could be wrong, the best solution would be to program a highly standardized interface for the plug-in.

Since DOSBox is designed around running in a modern OS, then I believe all of them (with the possible exception of Linux,) are multitasking environments. So, if you set it up so that the plug-in is actually an external program that runs separately from DOSBox then a lot of the backwards compatibility issues could be avoided there by setting up a standard form of communication. As all plugins would use the same methods to communicate with DOSBox regardless of how old they are. The highly published and non-proprietary ISA expansion port seems ideal to use as a model or template for communicating between DOSBox and the plug-in(s). Then you could set up a variable that limits the number of “ISA” ports that are available to DOSBox. I would suggest setting that number to 6 or 8 (like the number of ISA ports in a physical x86 machine.) Then you could, if you wanted, design it so that the Plug-in could over-ride the DOSBox built in emulations if the user wanted.

For example, someone could write a plug-in that acts like a communications expansion card, replacing the COM and LPT ports that DOSBox currently emulates. Or even a Voodoo 2 card to replace the VGA emulation. This could end up opening up security issues (as the plug-in would actually be running outside of DOSBox.) However, those security issues would be separate from DOSBox itself, and not the responsibility of the DOSBox team (not that it would ever really be in the first place.) The sole responsibility would be on the shoulders of the person(s) that wrote that plug-in and on the end user that decided to use it.

As I mentioned above, though, I don’t know if all of the systems DOSBox is designed to run on are multitasking. Not knowing that much about Linux (or Unix,) I have absolutely no idea if it is or not. I know that Windows and the Mac OS X are both multitasking systems though. The problem would be setting up this sort of plug-in system to work on those other OSes as well.

On thinking of the Voodoo 2 example above, that would probably end up opening a second display window (in addition to the normal DOSBox display window.) Not sure if that would be a good thing or a bad thing. Good, if the Voodoo 2 plug-in had some way of automatically switching between itself and the DOSBox diplay window that spawned it. I just don't know enough about programming to know if that is possible.... Now this is going to bug me all night 🙁 Not enough to put the effort into learning a programming language just to find out, though.

p.s. Egads, I didn't mean to make it sound like ISA expansion card emulation was the only goal. Other plug-ins could be designed I'm sure, they would just use the ISA standard for comunications (only a lot faster than an ISA port.) Such plug-ins could include, a cheat GUI that monitors the registers and user selected memory locations while DOSBox is running. Such a plug-in could search for patterns, such as the code that marks a character's hit points in a game, and then the user could alter it on the fly. I used to have something that did that for a Windows game I used to play, don't remember the game though.

> possible exception of Linux,) are multitasking environments.

uh oh somebody might feel insulted now 😉

You don't even need multitasking for the plugins.

h-a-l-9000 wrote:

uh oh somebody might feel insulted now 😉

You don't even need multitasking for the plugins.

I certainly didn't mean to insult anybody....

That being said, if it's set up so that the plug-in is actually a totally seperate program that runs at the same time as DOSBox and just communicates with DOSBox as it runs, then wouldn't that require multitasking?

Yes but that would make things more complicated. Loading a DLL should be much more simple.

I don't think that a highly "standadised interface system" is necessary either. If there is one, fine, but otherwise way, people would write plugin for the official release rather than for CVS, and would update the interface when a new official version comes out.

It would be very hard (if not impossible) to get the interface perfect at the first try anyway..

As for a voodoo plugin, it could share the SDL window with DOSBox if the plugin system provided hooks to the "frontend" (the DOSBox mixer for a sound device plugin, the SDL window for a graphic card, and so on) as it provides hooks to the back end (various hardware ports or software ints, the timer, IRQs and DMA channels.. )

FeedingDragon wrote:

Or even a Voodoo 2 card to replace the VGA emulation.

Just to nitpick, but this would be "supplement", surely? Voodoo 2 still required a passthrough to another VGA card afaik.

Targaff wrote:

FeedingDragon wrote:

Or even a Voodoo 2 card to replace the VGA emulation.

Just to nitpick, but this would be "supplement", surely? Voodoo 2 still required a passthrough to another VGA card afaik.

just to be picky,too, but it's the other way around, your vga signal is passed through the voodoo. :)