Problem: installed plugins limit decreases over time
Reply #18 –
Taken to that extreme, yes. However nothing much stops you from sharing a host, like Windows services do and Firefox plugin-container.exe.
You would distribute relevant parts of the fb2k API into the processes at suitable boundaries.
I don't expect existing components to take well to being segregated, but if there was a way to volunteer components to use a limited or full API for separation in the future, I'd sure consider authoring separable components. Some types of components are prime candidates for separation like inputs, DSPs and outputs.
The thing is, current-day foobar2000 architecture is butting up against several limits to in-process hosting. Real-life configurations run out of address space, we run into OS limitations on handle counts and exhaust scarce resources like FLS slots.
Component authors have to not only deal with their own problems, but with the problems inherent in sharing a process with other parties. You cannot as a component reliably spawn processes with inheritable handles, as that requires full control over all inheritable handles in the process. You can also not mess with other global state, even on a per-thread basis as you don't own much at all.
All this reflects in the crash reports we get. Most of the crashes I have are impossible to debug due to the wide variety and interaction of components inside the process.
I don't know what design would better serve the community in the future, but I know it's getting rather tiresome having someone reorganize your sock drawer whenever you look away.