Loading an Extension DLL From an Extension DLL

It's not clear what exactly do you mean by "extension DLL" (plug-in DLL?), but this is not a stupid idea. But one pretty silly idea is making a problem out of it. You can load any reasonable number of DLL into the same host process; and it does not really matter if some DLL are loaded no directly, but through other DLLs. It could be some resource-only DLL, not a very rare practice.

The other thing is important, the plug-in or extension mechanism itself. If this is just statically linked DLL, it's not a problem at all. But essential plug-in or extension mechanism works in a way agnostic to the host application. The DLLs are loaded during runtime, and the detail of this DLL is not known during compile time. There should be the mechanism where the host and the plug-in pass some interface to each other and call functions through them. (In special cases, it can be one way only: the host can call the DLL's functions; but the other way also happens in general case.) Such plug-ins or extension architectures can be good or bad (some are amazingly bad, by the way). But you did not share any information, so I cannot advise anything certain. The "secondary" DLL can be just the implementation detail of the "primary" DLL, so, for the host application, it does not matter anything special. The length of such chain could be more then three steps you are concerned with. It's just should better be something reasonable, not pathological.

—SA