Describe your dream OS

[bzt]

Hi,

This reminds me of my past. I used to think I wanted lightweight software, thinking disk space was an important part of that, but eventually I had to recognize that I really wanted software which was "light" in terms of time and intrusiveness. Disk and memory space was a much lower priority,

I have the same experience.

and trying to minimize them often made software worse in more important ways.

But interestingly I come to exactly the opposite conclusion. For example a game that has to load tons of textures, would load much slower if it were using uncompressed raw pixmaps instead of PNGs (the old Stronghold game pops into my mind which took ages to start). Also a program that's only 1M would load much faster than a 1G one. I'm also convinced that a simple windows ini like parser would finish much faster than any xml parser.

I think most people who use the term "lightweight" haven't realized the distinction.

And with that, I agree again.

Static linking was the touchstone which made me consider all this. I concluded I'm not opposed to static linking. It makes program execution much simpler and faster.

And I disagree again Consider this: there's a huge shared library to support the GUI (like Qt), let's say for the sake of the argument, it's 256M. There are two applications, A and B, each 1M. With static linking, your OS would need to load 514M into ram. With shared linking, you only load the lib once, when you start A (same speed as with static linking). Now when you start B, you only need to load an additional 1M, because the 256M lib is already in memory. Thus, loading 258M in total is much much faster, and dynamic linking beats static linking in program execution time. The time required by the dynamic linker to patch GOT entries is insignificant compared to accessing and reading sectors. It is more complex than static linking (which has absolutely no run-time requirement at all), but it's still relatively simple (applying some relocation offsets is not a rocket science).

Also maintenance is impossible with single binaries. If you install a fix for a shared library (like fixing a buffer overflow in jpeg comments), all programs using that library will benefit from the fix at once. With static linking you would have to recompile and reinstall ALL applications.

The only downside with shared libs is that developers and maintainers are incompetent, and they often can't guarantee backward API compatibility within a main version. This can be solved by allowing different versions of the same library to be installed at the same time (like Gentoo does), or by rejecting libraries from the repo that breaks compatibility (like Debian tries to do things with it's release cycles).

Static linking does make GUI programs reveal their true sauropodian scale, showing this is the Jurassic era of software -- unique skeletal structures to accomodate their immense weight. When I was still thinking of developing in C for Plan 9 I wanted to write servers rather than libraries for all this GUI bloat, but I'm not sure I consider it worthwhile any more.

I would say in a micro-kernel (or any server-client) architecture you'll need both. A server to accept messages, and a library to send them. Apps are using libs, they don't want to bother with constructing messages. For example, Xserver is the server, Xprotocol describes the messages, and application are using Xlib to send them (or they are using even higher abstraction level libraries, like Motif, GTK, Qt etc.).

The words "bloat" and "lightweight" are like "lag", they mean so many different things, it's not very helpful to use them. But this is a thread about dreams, and if you can't be vague in dreams, they're not dreams.

Agreed, just to put emphasis on this, those are not far-fetched dreams. As I've mentioned, OS/2 and BeOS can satisfy all the requirements, and they are not dreams, but real life OSes.

Cheers,
bzt

[zaval]

By the way, bzt, did you know, that OS/2 initially was entirely written at MS? I see, you praise that OS, thought, it would be funny to remind you that. That was stated by Gordon Letwin, one of the MS cofounders in about 95, in the letter, where he correctly predicts, that IBM will screw it up. he talked about that scandal between IBM and MS and mentioned, that OS/2 was started at MS, however it had another name. Made by DOS and Xenix engineers. Letwin by himself, was a HPFS creator - the main FS for OS/2.

may I make a little joke as a dishonored "abuser" of this forum filled with true gentlemen *wink wink?
bzt: OS/2 is cool, is da best, it fits all needs, brilliance, yummy, fap fap fap
me: but it has been created at MS and you hate it as much as every freaking moron at FSF does.
bzt:

[bzt]

By the way, bzt, did you know, that OS/2 initially was entirely written at MS?

Be precise, it was a collaboration between M$ and IBM.

I see, you praise that OS, thought, it would be funny to remind you that. That was stated by Gordon Letwin, one of the MS cofounders in about 95, in the letter, where he correctly predicts, that IBM will screw it up. he talked about that scandal between IBM and MS and mentioned, that OS/2 was started at MS, however it had another name. Made by DOS and Xenix engineers. Letwin by himself, was a HPFS creator - the main FS for OS/2.

I do not praise that OS. I've only said it fulfills all dreams of Octacone, as well as the other example I gave, the BeOS.

By the way, zaval, did you know, BeOS was not written by MS nor IBM?

may I make a little joke as a dishonored "abuser" of this forum filled with true gentlemen *wink wink?
bzt: OS/2 is cool, is da best, it fits all needs, brilliance, yummy, fap fap fap
me: but it has been created at MS and you hate it as much as every freaking moron at FSF does.

You may, but the joke is on you
I've never said OS/2 is the best, and I have never said I hate M$. I just gave two OS examples to Octacone's expectations, that's all.

And about my OS' logo, that's my own drawing, and I'm proud of that.
Can you draw a wolf like that?
Now I say:

Cheers,
bzt

[zaval]

Be precise, it was a collaboration between M$ and IBM.

you are inattentive. or just like to ignore things. this fact, that it was a collaboration is a well known fact. But I said got started, was born, thought out, devised, architected entirely at MS. I didn't say, that all its history it was being written only by MS. OS/2 was what MS intended to provide for IBM PCs, DOS was a quick and dirty solution for IBM, that wanted an OS ASAP as per the Letwin's letter, too bad, I can't find it now. Then, seeing that this way MS would own the entire API, IBM "joined" the development. The same fear of owning the API was the reason of that split - IBM saw extreme success of Windows and got afraid of that, demanding eventually that MS dropped it entirely in favor of only OS/2 one - that wasn't even close to the popularity of Windows those times. MS not being this stupid to kill a successful project and not being even that big then, had enough bravery to say IBM GTFO, and they won. It's irony, MS is being hated so much purely for its power, but then they stood against the monster, that looked at them as at lilliputs and demanded to behave as servants. They discarded their own OS and went making another one - NT with 32 bit Windows atop and won, isn't it a kind of stuff that folks should love? perhaps, but they got to know this story a little bit differently and MS became huge, so no love and appreciation for this act of standing on its own in front of a much stronger counterpart. not that MS ever seemed to care about that though. But now all these middle aged dudes hating M$ with passion and praising OS/2, meaning its an IBM child, no matter IBM killed OS/2 years ago, not being able to handle its evolvement properly, just like Letwin predicted in the letter - it's more than 20 years have flied away in fact, look as dumbasses, because the very same OS/2 were thought out exactly by the company they were taught to hate. for whatever reasons. I wouldn't be surprised if all this irrational hatred was born from a planned campaign. By the way, I was surprised to know that AIX, IBM UNIX, was NOT written by IBM too. I never thought they are lamers, they produced a lot of technologies but this fact confused me a little.

And about my OS' logo, that's my own drawing, and I'm proud of that.
Can you draw a wolf like that?
Now I say:

It's nice, really. I cannot draw at all.

[eekee]

My opinions expressed here and in my last post were formulated in an environment centered around shell scripting. I've moved on to more self-contained scripting environments, but still have more experience with shell scripts and I get nostalgic. Overall, I accept your explanations, bzt, but I do have one quibble which may be interesting. Operating systems only load the parts of programs which are actually run,* but dynamic linking is all done up front.# Thus, for example, a statically linked bash binary invoked to interpret a shell script would not have any of its readline code loaded (modulo page size). When bash is dynamically linked, all of libreadline needs to be loaded into memory and bash's links to it resolved for every shell script. If I'm not mistaken, all of bash also needs to be loaded to resolve the symbols. I have a vague memory of some other penalty; something like jumps into libraries not being optimizable. (Optimization in Plan 9 is done by the linker.)

*: At minimum, Linux and Plan 9 do this. I imagine most other OSs also do.
#: I hope I'm not propounding obsolete info here. It was true some years ago.

Edit: I just realized, when you use a library to access a fileserver, updating the fileserver could provide fixes. That is normal in Plan 9 by the way, just as much as in microkernels. Not that rebuilding the entire system was a problem on Plan 9. The old saying, "Unix compilers are slow" *definitely* no longer applied.

[nullplan]

Thus, for example, a statically linked bash binary invoked to interpret a shell script would not have any of its readline code loaded (modulo page size). When bash is dynamically linked, all of libreadline needs to be loaded into memory and bash's links to it resolved for every shell script.

Dynamic linking is bad, but not this bad. In your example, libreadline would be merely mapped into memory. OK, all dynamic interpreters I know read a bit of the file, but only the first 1k or so. And that is thrown away afterwards. The rest is mapped in with mmap() (which means the actual library content is faulted in, page wise). Only on a system without MMU is the lib even loaded, but on such a system, it would have to be loaded even with static linking.

No, the real issue is that after mapping libreadline into memory, the interpreter has to fix up the relocations. Thus the interpreter has to touch memory that wouldn't even exist if the program was statically linked: the GOT. In it, the interpreter gets to fix up all the relocations, which means it gets to look up all the symbols in the current symbol set. Since ELF doesn't allow you to specify which library a symbol is imported from, the interpreter gets to look through all the ones that are loaded already. So this problem gets worse the longer it goes on. For instance, Debian's copy of mpv links against 292 dynamic libraries. And takes around three seconds to actually start up.

Anyway, the GOT is usually in the same segment as the data section, meaning that writing to it triggers page faults that will cause the lib to be loaded. But since this is in the writable section, these loaded pages can't be shared. Every process gets its own maps.

Admittedly, some of this can be mitigated with lazy lookup, but lazy lookup is only possible for functions, not data objects, and requires the dynlinker to support it with architecture specific code. Namely the dynlinker entry point, which can be very convoluted to say the least.

So in summary, dynamic linking imposes additional storage cost (have to save a PLT and GOT in every lib and program), additional memory cost (the PIC overhead and the aforementioned PLT and GOT), additional runtime cost (dynlinker has to run), additional organizational cost (have to make sure all the libs are packaged together with the program). But hey, at least some processes can share text now.

[bzt]

Hi,

@nullplan: I'm seriously hope that you're joking. Otherwise viewtopic.php?f=6&t=33614

Cheers,
bzt

[nullplan]

@nullplan: I'm seriously hope that you're joking. Otherwise viewtopic.php?f=6&t=33614

Was any part of my response funny to you? Strike that, was any part of that response untrue? And what is your point? A link to the "OSDev in decline" thread doesn't mean a whole lot, especially since dynamic linking was never mentioned in there.

[bzt]

Was any part of my response funny to you?

No, much more like sad. Very sad. If you really meant it, OSDev is definitely in a decline. It is not funny at all when something so basic like the advantages of dynamic linking has to be explained on an OSDev forum.

Strike that, was any part of that response untrue?

How about all parts untrue? No serious programmer would ever think for a moment that deduplication of functions would require more storage space or more memory. I'm afraid you lack some required and pretty essential knowledge my friend.

But let's assume for a moment there's still hope for you to learn, and you are not just a sad little troll deliberately misleading other forum members. I'm an optimist, I don't assume the worst of people.

So let's examine your claims one by one with an example: libjpeg is 603K. Dynamically linking with it creates a 840 bytes PLT record (GOT is not stored in the files, and needs 214 bytes in memory, which includes libc relocations too).

But since this is in the writable section, these loaded pages can't be shared. Every process gets its own maps.

This is technically true, but since with static linking nothing can be shared, and every process gets its own maps anyway, this just makes absolutely no sense.

So in summary, dynamic linking imposes additional storage cost (have to save a PLT and GOT in every lib and program)

But you don't store the lib's functions. In our example that's -602K for every program that needs to deal with jpeg files.

What "additional storage cost" are you talking about?

additional memory cost (the PIC overhead and the aforementioned PLT and GOT)

Since every program is smaller by 602K, you'll need less memory for the processes. Furthermore libjpeg is only loaded once, and just mapped into their address space (no additional RAM allocated). If GOT gets its own page, even then that's -600K per process.

What "additional memory cost" are you talking about?

additional runtime cost (dynlinker has to run)

Yes it has to run, but you don't have to load an extra 602K from a slow disk for every process, just add an offset to 23 words (number of relocations for libjpeg). Loading half a megabyte from a slow peripheral vs. applying a few operations on a much-much faster peripheral.

What "additional runtime cost" are you talking about?

additional organizational cost (have to make sure all the libs are packaged together with the program)

What? You don't package libraries with the program! Quite the contrary, with dynamic linking you separate the libs into their own packages, and the OS takes care of them (more precisely the package manager like apt, port, pacman, brew etc. and the dynamic linker).

But hey, at least some processes can share text now.

But hey, what if you take into consideration all aspects of shared text? Like shared functions require less storage space, shared mapping requires less RAM, loading less means faster start up?

Dear Lord, what's up next? File systems with automatic file deduplication need bigger disks? >D (sarcasm)

Cheers,
bzt

[nullplan]

No, much more like sad. Very sad. If you really meant it, OSDev is definitely in a decline. It is not funny at all when something so basic like the advantages of dynamic linking has to be explained on an OSDev forum.

I don't need it explained, I just don't think the advantages outweigh the disadvantages.

No serious programmer would ever think for a moment that deduplication of functions would require more storage space or more memory.

Because miracles come for free. I'm not so naive. In order to support that, you need overhead (PLT, GOT, dynamic linker, PIC), and often that overhead is not worth it. Plus, in this day and age, optimizing for storage space or memory seems like a lost cause, when 16GB of RAM cost like 100€. I'd rather optimize for time.

I'm afraid you lack some required and pretty essential knowledge my friend.

Yes, please regale me with your stories, oh wise one. Could you try to be more arrogant next time?

libjpeg is 603K.

So that is the hill you wish to do battle on? Alright.

cjpeg is a little program using libjpeg to compress an image. You have to trick its build system pretty hard into generating a statically linked version (what is the point of libtool if it just gets in the way of actually linking the application?), but I managed to generate a statically linked executable. With a PLT and a GOT inside -- I don't know how that works. No, it is not a PIE.

Anyway, the file contains four LOAD segments. Rounding the memory size of each up to the next 4k line (because page granularity) and adding those up yields 1116 kB.

Now for the dynamic executable. Now, I could just score a quick victory here, because some genius set the alignment for all LOAD segments of libjpeg and all executables to 2 MB (meaning a single LOAD segment like that has outgrown the entire static application already), but I like to think I'm more professional than that. So, a quick recompilation later: cjpeg once again has four LOAD segments, weighing in at 72 kB. libjpeg has another four LOAD segments, at 492 kB together. The dynamic interpreter has another four LOAD segments (is that the new fad? I thought two of those ought to be enough for everyone), clocking in at 164 kB. And, finally, libc has another four LOAD segments, weighing 1792 kB in toto.

All in all, you have to map 2520 kB of virtual memory just to finish loading this file. The only saving grace is that 1792+164 kB of this are likely already in memory. Of which I have to immediately deduct 44 kB for being non-sharable data.

but since with static linking nothing can be shared,

And you claim I lack essential knowledge. With static linking, text is shared between all processes with the same executable. Which happens a lot. For instance, right now my laptop is running 28 instances of udevd (what are they DOING?), 5 gettys, 4 rdnssd, 4 dbus-daemon, 4 "Web Content" (which is a Firefox thing), etc. pp.

And all this sharing would be possible without any relocation processing (if I had linked everything statically, that is).

BTW: I am always claiming there is PIC overhead. Well, I have the static and shared libjpeg right here in front of me. And while the static library has a larger file size, this is mostly due to ELF header overhead (which the linker will strip away). Using "size", I can tell that the shared lib is 3.5% larger than the static one. That's for AMD64, by the way. I suppose for x86 it would be worse. (x86 PIC is horrible)

Since every program is smaller by 602K,

And how many programs with jpeg support are you running simultaneously?

you'll need less memory for the processes. Furthermore libjpeg is only loaded once, and just mapped into their address space (no additional RAM allocated). If GOT gets its own page, even then that's -600K per process.

Yes, I have noticed you chose a library with little changable data (< 4kB). Well done.

Yes it has to run, but you don't have to load an extra 602K from a slow disk for every process, just add an offset to 23 words

That is fuzzy enough to be true. However, it is not a constant offset.

cjpeg has 82 relocations of which 35 require a symbol lookup. My copy of libjpeg has 347 relocations of which 105 require a symbol lookup. ld.so has 49 relocations of which 9 require a symbol lookup, and finally libc.so has 1369 relocations, of which 77 require a symbol lookup. If LD_BIND_NOW is in effect (which has been suggested as a security hardening option for a long time now), that is 1847 relocations with 226 symbol lookups. Every time you start that application.

What? You don't package libraries with the program! Quite the contrary, with dynamic linking you separate the libs into their own packages, and the OS takes care of them (more precisely the package manager like apt, port, pacman, brew etc. and the dynamic linker).

On inspection, it turns out that most of the bundled libraries I had seen were actually specific to the application in question. I withdraw that complaint.

Also, the new fad is containers, where people not only bundle all libraries, but also the rest of the OS. It's all so wasteful.

But hey, what if you take into consideration all aspects of shared text? Like shared functions require less storage space, shared mapping requires less RAM, loading less means faster start up?

As given above, I don't care much about optimizing for storage or memory, so that last one is the only interesting one for me. It only works, however, if you assume the cost of looking up all the required libraries is negligible. If disk transfers are truly that slow, then surely, having to look up a lot of directories, almost all of which exist, only to find that the desired library is in another castle, cannot be so simply ignored. I am not convinced that this:

Code: Select all

execve(".libs/cjpeg", [".libs/cjpeg"], 0x7ffcc6868d80 /* 28 vars */) = 0
brk(NULL)                               = 0x559f64c00000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/tls/haswell/x86_64/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64/tls/haswell/x86_64", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/tls/haswell/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64/tls/haswell", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/tls/x86_64/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64/tls/x86_64", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/tls/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64/tls", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/haswell/x86_64/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64/haswell/x86_64", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/haswell/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64/haswell", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/x86_64/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64/x86_64", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/opt/libjpeg-turbo/lib64/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/opt/libjpeg-turbo/lib64", 0x7ffca849ccc0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=160735, ...}) = 0
mmap(NULL, 160735, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7efd09239000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libjpeg.so.62", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220<\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=428032, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efd09237000
mmap(NULL, 2523160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7efd08fce000
mprotect(0x7efd09035000, 2097152, PROT_NONE) = 0
mmap(0x7efd09235000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x67000) = 0x7efd09235000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260A\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 1837056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7efd08e0d000
mprotect(0x7efd08e2f000, 1658880, PROT_NONE) = 0
mmap(0x7efd08e2f000, 1343488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7efd08e2f000
mmap(0x7efd08f77000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a000) = 0x7efd08f77000
mmap(0x7efd08fc4000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7efd08fc4000
mmap(0x7efd08fca000, 14336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7efd08fca000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efd08e0a000
arch_prctl(ARCH_SET_FS, 0x7efd08e0a740) = 0
mprotect(0x7efd08fc4000, 16384, PROT_READ) = 0
mprotect(0x7efd09235000, 4096, PROT_READ) = 0
mprotect(0x559f630b8000, 4096, PROT_READ) = 0
mprotect(0x7efd09288000, 4096, PROT_READ) = 0
munmap(0x7efd09239000, 160735)          = 0

Is less work than just faulting in the pages from a statically linked executable.

[bzt]

I don't need it explained, I just don't think the advantages outweigh the disadvantages.

You still don't understand how dynamic libraries work and why they are used. Btw, advantages and disadvantages is not a matter of a subjective opinion. It's a matter of measurements, and comparition of objective test results.

If what you're saying were true, nobody would have implemented DLLs or SOs. But here's the news, they have (check out Win, Linux, MacOSX, BSDs, literally ANY mainstream OS, and BeOS, Haiku, Plan9, Ultrix, VMS, Solaris, ReactOS, just the name a few non-mainstream, and all successful hobby OSes if you don't believe me).

So that is the hill you wish to do battle on?

You couldn't be more wrong, my friend, there's absolutely no battle here. You should thank me, because I was hoping you are capable of learning and you're not just a troll.

I've told you the facts, I gave you a simple example, now it's up to you if you learn from that or not. OSDev is not for everybody. This discussion is over.

Cheers,
bzt

p.s.: To all of you who are constantly attacking me, just because I'm telling the truth, I would suggest to watch HBO's new mini series Chernobyl, and think about what is the real price of lies? Hopefully it will open your eyes. If not, well, not everybody ready to be awaken from the Matrix...

[kzinti]

So much arrogance from Bzt. it's starting to be very annoying.

[iansjack]

... but he does have a valid point. The idea that dynamic libraries lead to a larger memory footprint is plainly ridiculous. Just imagine if every program that used the standard C library were statically linked. How many copies of printf, malloc, and other common functions would there be in RAM?

Static linking has its place, particularly with functions that are very unlikely to be shared by many programs, but the advantages and flexibility of dynamic libraries make them an obvious choice in most situations.

[kzinti]

... but he does have a valid point.

I do agree with his point. It's the way he expresses it that is problematic for me. There is no need to be condescending and insulting when explaining something.

[bzt]

There is no need to be condescending and insulting when explaining something.

That was not my intention, if it sounded like condescending, that's only because I felt attacked defending the truth. Frankly I don't think OSDev forum is the place for explaining basic programming techniques, but I apologize if I sounded insulting.

Cheers,
bzt