MAMEDEV Forum

To someone that hasn't gone deep in MAME design and how it has evolved over the years, being a single exe, looks monolithic and less "modern".
There are other multi-emulation attempts, the prefer the use of "cores".
Of course in reality MAME is super-modular in almost its entirety. The single exe just hides that.
This has advantages and disadvantages.
- A single package is usually more portable.
- A single package is cleaner (*).
- A single package forces the update of all critical components (that cooperate), at once.
- External modules allow the evolution of separate components independently of core system.
- External modules organized in folders are cleaner (*).
- External modules allow for easy customization.
- External modules allow for partial implementation (for example someone might just want to use the components that make up Atari home consoles and nothing else - something that now can only be done with customized compilation).

(*) Yes, both, depending who you ask.

I wonder how easy it would be either switch to a design where modules are external (for example a folder with "CPU", a folder for "peripheral IC", a folder "storage peripherals" or whatever - all with separate libraries -, even a folder "machine" that each file describes the set of components from other folders needed to comprise the machine and its variations), or be able to use when those exist (over the internal). After all MAME already supports plenty of folders for its content.

To clear things out, I am not asking anything to be done NOR saying one is better than the other - I just wonder if this has been discussed and what is the current team's "take" on the matter - just a subject for casual discussion.

Well as I'm not a developer myself I may be wildly mistaken, but to my untrained eye it looks like the *source*code* is very well laid out and 'modular', as you put it. Just because building all that ends up in a single binary seems to have little to do with it.

https://github.com/mamedev/mame/

Yes already said that.

Shortly after I first joined MAMEdev eons ago (2000), a newcomer to the team privately submitted a proof-of-concept idea for rearchitecting MAME so that it could be "plugins" based as you have generally described.

His proposal was soundly rejected by the project's founder, Nicola Salmoria, as well as others.

"Dependency hell" is not something we're interested in supporting.

I understand. The problem is having to have all the parts in place, else a tiny something missing, would not allow a machine to work (or more).
I guess it needs tiny files.
Referencing the parts (the dependencies) is done anyway, but they are packaged inside "problem free".

That said MAME is nowhere close to the size it was in 2000.

It's not just that, it's that our end users would probably update "plugins" but not "the core", or vice-versa. We'd need versioning to enforce compatibility. Error reports would increase tremendously because users would try using newer "cores" with older "plugins" and vice-versa.

Haze has a good rant against "modular MAME" somewhere in his history...

I read you.
Thanks.

It would also be rather difficult to actually implement MAME as a bunch of dynamically loadable cores in a way that would work on OSX. Keep in mind that the Mach-O loader that OSX uses doesn't allow shared libraries to have undefined symbols. Users of devices call out-of-line non-virtual methods all the time, so any devices would have to be in shared libraries, and you'd have to somehow arrange them so there are no circular dependencies. The core itself would also need to be a shared library that everything else calls into. The dependencies between everything would be a massive spiderweb and making changes to drivers could require big changes to the build system to get everything to link properly.

It would probably be possible to break out the OSD layer (filesystem access, video output, audio output, font rendering, MIDI, etc.) as this stuff is relatively self-contained with well-defined interfaces, but they're a very small part of the project, and I really don't see much interest in that.

As has been stated, people would mix and match DLLs from different MAME versions and create an unsupportable nightmare.

If your concern is over the size of the MAME executable, all modern operating systems only load the pages of an executable that are actually being used.