DOS ain't dead

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

posted by marcov, 16.12.2019, 23:16

> Borland pascal 7.0 can use both - overlays in realmode and DLL libraries in
> DOS 16-bit protected mode. (and for windows, of course).
> The DLL stuff is described quite well in the help system in IDE.
>
> 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?

If you can't LoadLibrary() it is somewhat limited. Loadlibrary() is however difficult because then again you can only get main program symbols by probing for them.

> However the good thing ih the BP way of the DLL implementation is that it
> is quite straitforward and not much more complicated ovet normal
> static-linked unit.
>
> The DXE1 modules in the FPC has severe limitation that it has almost no
> connection with other parts of the program.

(it was straight port of Djgpp code by me, with some help of Pierre to get it debugged, I think I got it working within one week only working a good hour in the evenings or so)

> 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.
> The only way how to bypass this situation is using the procedural
> variables.

Freepascal is working for packages, that means that all shared units must be in a DLL/BPL.

It is starting to work for windows, but the libraries get quite big, since there is no smartlinking. Go32V2 would be smaller, but still quite sizeable.

e.g. for win32 quoted sizes are:

2633984 rtl.dll
414820 rtl.objpas.dll
247060 rtl.extra.dll
364625 rtl.generics.dll
389888 fcl.res.dll
788664 fcl.base.dll
962560 fcl.xml.dll
953676 chm.dll

(extension is DLL, but has extras like Delphi BPL and also extra metadata files that needed during linking only)

A simple binary like chmls.exe then goes back from 285kb to 68kb. But the main advantage is not binary size, but that all DLL/BPL packages use the same libraries and library state, and can be used almost as if you would just divide the program into multiple binary on unit boundaries.

I haven't heard about loadlibrary use yet (but delphi can). Usually the trick is that both the EXE and the loadlibraried BPL/DLL statically link to another BPL/DLL that contains a registration of e.g. customer specific objects. (like forms etc)

This way you can plug in customer specific behaviour in already compiled programs.

> So it is so paintful that nobody uses it.
> 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...

And for 16-bit and 32-bit separately.

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