Having a DLL would mean that any other application could simply load the DLL and use it as an interface with FS2Open, rather than forcing every single person writing an application to implement the entire API each time using Win32 messaging, or somesuch.
However, TCP/IP is much more flexible, so that is what I think I'd prefer in that regard. It uses a relatively well-documented protocol that's also nonplatform-specific, and can easily be redirected across a LAN or something similar - a capability that direct memory management simply wouldn't have.
Aha, so you want an extra library to make talking to fs2_open easier. That would be very nice. Like extra admin UIs to remote control dedicated servers? Or maybe even an api to program a bot so it doesn't eat up resources on the server?
Anyway, the problem with DLL support is not in simply getting them to load. You have to provide support for each one. That's an extra chunk of executable that can be release or debug. We're now up to 6 variations. Or it can be 32-bit or 64-bit. Now we're up to 12. This is all in addition to the original fs2_open executable.
OK, I get it. Even though I am not so sure how to manage it with less effort as a static part of fs2_open. See last comment below.
In addition, campaigns or mods that want to release DLLs will either have to support them on all platforms, and/or compile them on all platforms, or simply support only one configuration. It also means that anyone can insert malicious, or further platform-specific code, into their DLLs. And they can go closed-source on us, so there's no way for anyone to verify DLLs.
Hmm, the linux kernel does it somehow (preventing proprietary kernel modules, same thing really), so it can work. You are right about malicious code, but since this all is open source anyway, you can't be sure the total conversion people didn't patch their source before release anyway. Mods would have a little harder time.. That's true.
Malicious code would be very hard to add. Remember, symbols (i.e. functions, classes, etc) are loaded explicitly from such a DLL. I.e. funcPtr = getSymbol(library, "ai_*"). There would be exactly one entry point, and we would only allow people to change the AI behavior. There is not much room for malicious code. Apart from things that just make the thing crash, you can only make super hard AI that always kills you. But that's the point, isn't it?
Basically, it inserts a big chunk of complexity that seems completely contrary to what taylor's been trying to do, to make FS2_Open work and function the same on every single platform.
So in the end, I'm not sure what having DLLs would really accomplish. If they're meant to provide modders with a method of access to fs2_open, they're an extremely poor choice. Campaigns are left either having everyone compile from source, or compiling from source themselves and supporting every single platform under the sun. This bumps individual modders out of the loop, for the most part, and makes it even more difficult for people to get into modding - because they have to learn coding.
That's not true. You can pick and choose your favorite AI implementation DLL without having to know how to program. In some sense, it's the same as editing table files (AFAIU).
If they're meant to be released alongside the EXEs, what do they really gain? You can have a DLL for each AI version, but now people have to keep track of having the right DLLs for the right campaign. The modularity is nice - so all versions don't have to be loaded into memory - but I don't think that there would be any noticeable difference if things were coded properly. Plus, now you've got an extra component running around along with fs2_open and FRED that can develop oh-so-many extra bugs.
EDIT: Not to mention the inconsistencies that can easily develop when you've got CVS builds of both running around.
I think modularity here also means that it is much easier in code to keep track of these AI implementations. Symbol tables are local to DLLs if you load them programmatically, so we don't have to prefix all symbols in the main app (i.e. ai001_*() up to ai999_*() instead of just ai_*()) or make sure we have unique symbols in some other way so it compiles.
Additionally, as karajorma pointed out before, missions rely
on the AI to behave a certain way so they make sense or are playable at all. So, giving the MOD/FREDer a way to say "give me AI version x.y.z" is by lengths better implemented as loading versioned DLLs (they could be automatically downloaded from the web?) than having a thousand IFs in the code checking if the AI is allowed to do things in this specific version or not or having a thousand prefixed versions of the AI floating around at any time (i.e. ai001_*(), etc). This means, modularity also brings a lot of maintainability. And of course freedom of choice, as it is conceivable to assign different AI versions to different ships/wings/difficulty levels.
And I am talking major rewrites/changes between major versions of the AI. We could even have different ways to approach AI (e.g. the FEAR way, a learning way, etc, there are many!) implemented, all to the same interface. That would also attract AI students to use fs2_open in their AI class projects, which means we get even cooler AIs implemented for free. This happened (partially) to Quake II when it was made open source. I know this because I know a guy who did his AI Master thesis on learning in Quake II bots.
But of course it comes at a cost. However, when you do releases of fs2_open, you will have to compile them 12 times as well. So, there must be an infrastructure to do this. Why not use the same for official AI releases?
Sorry for the long post...
I didn't realize it got this long.