DOS ain't dead

.DXE .DLL .SO (etc.) (Developers)

posted by Rugxulo , Usono, 16.12.2019, 20:04

> The bad thing in DLLs in DOS is that they are a little bit usesless. What
> advantage give it against static linking in the single-task OS?

It would only be for replaceable (newer/alternate/faster/bugfixed/enhanced) code, maybe (un)loaded at runtime. So, if anything, I would think (oft-maligned) segmentation would help with this kind of thing! (Not for DJGPP, but you know what I mean, in 16-bit DOS.) Recompiling and redistributing an entire binary program (of multiple MB) just to change a few bytes is silly. Hex editing/byte patching/binary diffs are much more brittle but also unappreciated.

> The DXE1 modules in the FPC has severe limitation that it has almost no
> connection with other parts of the program.

It's still good for ("simple"?) leaf functions or even assembly (see paq8f with MMX or SSE2 speedups), especially if they will change later or target newer instruction sets (SSE 4.2?). But my patch made that optional (fallback to static code) so you could still use the .EXE without the external .DXEs. I think that's a better way and doesn't negate the stability and independence of static linking.

> The EXE sees the inside of the DXE but the DXE sees nothing from EXE.
> The practical impact is the the DXE modules can not use any procedures (or
> functions) from any system or user unit. Nothing from unit CRT, nothing
> from DOS, even nothing from unit SYSTEM.
> So it is an extreme limitation for using this stuff.
>
> So it is so painful that nobody uses it.

I agree it's limited, that's why I mentioned newer DXE3. (Remember that DJGPP 2.04 was never finalized beyond /beta/ since 2003, so barely kinda sorta 2.03p2 from 2001 was still official since it was /current/, even if you could still use both. But 2.05 in 2015 improved all of that, thankfully.)

> Maybe in theory could be possible the implement into FPC the DXE3 handling
> which should not suffer by this limitation but it would need some
> DOS-and-pascal-megaguru...

DXE3 is better, yes, but most people don't really understand how to use it or don't find it worth the hassle. Obviously I'm not quite smart enough to do everything myself. Still, I'm vaguely interested.

Everybody else is obsessed with .DLLs (and .so). It's considered old-fashioned and flawed to never use them. But clearly some compilers do without anyways, even on Linux (ACK, FPC, OpenWatcom)! I do think static is good sometimes, but mostly nobody cares. Snap/Flatpak/etc. will probably simplify distributing multi-file programs like this in the long run, if not already.

Complete thread:

• .DXE .DLL .SO (etc.) - Rugxulo, 14.12.2019, 14:00 (Developers)
  • .DXE .DLL .SO (etc.) - Laaca, 15.12.2019, 22:50
    • .DXE .DLL .SO (etc.) - Rugxulo, 16.12.2019, 20:04
    • .DXE .DLL .SO (etc.) - marcov, 16.12.2019, 23:16
      • .DXE .DLL .SO (etc.) - Laaca, 18.12.2019, 21:30
        • .DXE .DLL .SO (etc.) - marcov, 19.12.2019, 20:39
        • .DXE .DLL .SO (etc.) - Rugxulo, 20.12.2019, 10:39
          • .DXE .DLL .SO (etc.) - marcov, 20.12.2019, 18:06
  • .DXE .DLL .SO (etc.) - sezeroz, 16.12.2019, 06:15