Vergleiche mit dem rezenten Windows enden stets mit der weisen Festellung, daß es eben einfach ganz anders ist.
Allein dadurch, daß das Programm in einem Flash gespeichert ist, entfällt alles, was bei Prozessore in Richtung "dynamisch" ablaufen kann, bzw. wird nicht praktikabel.
Beim Bascom ist der Unterschied "Inline" und "library" klein, aber fein.
"Inline" ist IMHO ganz gut mit MACROS vergleichbar, die zur Compile-time parametrisiert generiert werden.
"Library" sind fest programmierte Routinen, die letzlich unique an einem festen Platz im Speicher stehen, und die zur run-time aus den Call Argumenten variiert werden (können).
Dabei macht das Bascom trickreicherweise noch so, daß er auch die eigentlich bereits kompilierten LBX-en nochmal übersetzt, damit er Variablen/Konstanten (z.B. $Crystal) einarbeiten kann.
Es wird in der LBX ja nur das kompiliert, was sich nicht mehr ändern kann (taucht in der lbx als ".OBJ xxx" auf). Mit den gewohnten Object libraries haben die nix am Hut.
Dadurch erspart sich Bascom immerhin einen "linker"
Schwierigkeit, die daraus folgt: Es gibt kaum allgemeine anwendbare Regeln, wie man zwischen "include sourcefile", Inline assembler und Libraries auswählen soll. Kommt immer ganz drauf an.