The biggest purpose for DLLs (or "shared libraries") is when you plan to share your library (go figure) among multiple applications/processes, not multiple developers.

Normally, it's done to improve build times on large projects (static libs can takes an age to link....).

Second Important Point: There are many, many, many problems with DLLs, and many complicated systems have been invented to try and resolve them (start your learning journey with the search phrases "Windows COM", and "DLL hell"), and the problems just keep getting more and more complex as the solutions do. Deciding whether you want a bunch of DLLs is really an easy ask: would you rather manage 4 files to distribute, or 400? DLL's serve a purpose, but most of those purposes remain down lower than you need to worry about. VC runtimes make great DLL's. OS code makes great DLL's. Things that a LOT of apps need access to, and need frequent updates - THESE make great DLLs.

When you say 'many problems' I assume you basically mean: STL. If you avoid using STL in your DLL headers (or any other class that changes size between release and debug), most of the issues are relatively trivial. Even then, this only really applies if you start mixing debug and release code (the debug and release CRTs can get into arguments). If you just replace a static lib with a DLL, and you properly export the functions (and data), then you won't have problems....

Now, let's say you're building a game engine. Unless you plan to a) use that engine in several games; and b) want to be able to update the engine with application X and allow application Y to benefit from the improvements - then you don't need a DLL. In fact, it can cause a lot of problems if you TRY to share a DLL between two different apps like this, when they end up being incompatible (see "DLL hell", referenced above).

Nonsense. Set up your build rules properly so that doesn't happen.

In general, what really happens is you have version 1 of an engine that you ship with App X. Then when you make App Y, you improve the engine, and ship Engine version 2 with App Y, and so on. If you now try to run App X and it loads Engine 2, well, unless you're World-Class good at forward-design (also known as "psychic", "lucky", or "liar") - then you will have not anticipated something. Then you've either got multiple versions of the same interface all doing different things, or some other kludge - but all to the same effect: different engine code for different apps.

The days of writing a shit installer that blindly copies DLLs to system32 are long gone. If you are still doing this, then really you should maybe stop doing it? Most people would include the DLL in the installer, and it would be installed in the same dir as your exe. Doing anything else is completely mental.....

Current best practice is to create a small bootstrapper exe, and then gob as much stuff as makes sense into a single DLL. For a great example of this, see Google Chrome. They have a few DLLs, but most of their code ships in one (relatively) large chrome.dll.

That is not best practice, that's just mental. One would imagine that chrome.dll is actually a series of DLLs that has been combined into a single dll for release only (there are tools included with every compiler that do this!). If the devs of chrome had all of their code in a single dll, a single change would take hours to re-link!

I've come down pretty hard on DLLs, so I'll try to advocate for them at least a little. A great use for DLL's is if you are creating something that you want to sell to someone else, like an SDK. Then, you package your stuff up in a DLL, give them the header files and (hopefully) expanded documentation, and then they can use your code without having access to it, so you can retain the IP.

.... if you ever experience a problem with DLL's, it will be because you try to do ^^this^^. DLL hell begins and ends with plugin architectures (It's something I could talk about for hours, but I'll spare you the details....). Simply using a DLL instead of a static lib won't cause problems.

The biggest purpose for DLLs (or "shared libraries") is when you plan to share your library (go figure) among multiple applications/processes, not multiple developers.

Normally, it's done to improve build times on large projects (static libs can takes an age to link....).

Second Important Point: There are many, many, many problems with DLLs, and many complicated systems have been invented to try and resolve them (start your learning journey with the search phrases "Windows COM", and "DLL hell"), and the problems just keep getting more and more complex as the solutions do. Deciding whether you want a bunch of DLLs is really an easy ask: would you rather manage 4 files to distribute, or 400? DLL's serve a purpose, but most of those purposes remain down lower than you need to worry about. VC runtimes make great DLL's. OS code makes great DLL's. Things that a LOT of apps need access to, and need frequent updates - THESE make great DLLs.

When you say 'many problems' I assume you basically mean: STL. If you avoid using STL in your DLL headers (or any other class that changes size between release and debug), most of the issues are relatively trivial.

Now, let's say you're building a game engine. Unless you plan to a) use that engine in several games; and b) want to be able to update the engine with application X and allow application Y to benefit from the improvements - then you don't need a DLL. In fact, it can cause a lot of problems if you TRY to share a DLL between two different apps like this, when they end up being incompatible (see "DLL hell", referenced above).

Nonsense. Set up your build rules properly so that doesn't happen.

In general, what really happens is you have version 1 of an engine that you ship with App X. Then when you make App Y, you improve the engine, and ship Engine version 2 with App Y, and so on. If you now try to run App X and it loads Engine 2, well, unless you're World-Class good at forward-design (also known as "psychic", "lucky", or "liar") - then you will have not anticipated something. Then you've either got multiple versions of the same interface all doing different things, or some other kludge - but all to the same effect: different engine code for different apps.

The days of writing a shit installer that blindly copies DLLs to system32 are long gone. If you are still doing this, then really you should maybe stop doing it? Most people would include the DLL in the installer, and it would be installed in the same dir as your exe. Doing anything else is completely mental.....

Current best practice is to create a small bootstrapper exe, and then gob as much stuff as makes sense into a single DLL. For a great example of this, see Google Chrome. They have a few DLLs, but most of their code ships in one (relatively) large chrome.dll.

That is not best practice, that's just mental. One would imagine that chrome.dll is actually a series of DLLs that has been combined into a single dll for release only (there are tools included with every compiler that do this!). If the devs of chrome had all of their code in a single dll, a single change would take hours to re-link!

I've come down pretty hard on DLLs, so I'll try to advocate for them at least a little. A great use for DLL's is if you are creating something that you want to sell to someone else, like an SDK. Then, you package your stuff up in a DLL, give them the header files and (hopefully) expanded documentation, and then they can use your code without having access to it, so you can retain the IP.

.... if you ever experience a problem with DLL's, it will be because you try to do ^^this^^. DLL hell begins and ends with plugin architectures (It's something I could talk about for hours, but I'll spare you the details....). Simply using a DLL instead of a static lib won't cause problems.