caseih wrote:DLLs simply don't make sense in MS-DOS. There's no mechanism, either in the OS, or the hardware platform to work with them. DLLs only make sense when the OS supports multiple processes, and the CPU supports protected memory and virtual memory mapping and addressing (MMU). 16-bit real mode (even huge, flat, 32-bit real mode) does not support those features on the CPU.
Back in 2006/7, one guy did some unofficial changes to DJGPP to get .so support. It was called DJELF, the successor of DXE3. Normally, DJGPP uses COFF, but he optionally used ELF instead. It's on most DJGPP mirrors under /djelf/ . It does work, I've tried it. Unfortunately, it's unmaintained and thus not mainlined, so it only supports old G++ 4.0.0 and DJGPP 2.04. There was little interest in reviving it.
For one thing, it makes keeping track of dependencies harder. While some may lament having to rebuild an .EXE from scratch, it's not that hard (normally). Having only a single .EXE is much more convenient than having tons of .DLLs. Even more important, IMO, is the fact that UPX for DJGPP doesn't support ELF. So you're looking at bigger binaries, which loses one of the other obvious advantages.
While I don't direly want DLLs for DJGPP, it would still be cool. Of course, even switching to ELF might have some benefits. But there are only very few developers left, and nobody cares about such niche projects.
Having said that, DXE3 is more robust than you think. I don't know the details and honestly am not familiar with it very much, but I think it is heavily used in such projects as UHexen2 (Hammer of Thyrion) and that one guy's port of Quake2. So you could look closer there if direly curious.