7 ms·

It's interesting that libraries and executables always have been considered different things by the mainstream operating systems. In Oberon systems object file

by eterps 4y ago

It's interesting that libraries and executables always have been considered different things by the mainstream operating systems. In Oberon systems object files are executable files. Every object file can have subcommands, like the git command has init, add, commit etc. but it also contains the library functions (like libgit has) in that same object file. In Oberon all those concepts are the same thing.

magnio 4y ago
As someone born in the 21st century, I've always found this to be a weird distinction. Why can't we unify them in just one concept?
- pjmlp 4y ago
  Because they cover different scenarios. If you want the previous one concept, you can get it via static linking alongside OS IPC. However it requires more OS resources and is complexer to program. Now every shared functionality has to do a shared memory or pipe configuration dance, to expose their functionality.
- astrobe_ 4y ago
  Maybe it looks weird now because libraries were collections of subroutines, then have evolved as sub-programs (some spawn their own threads to do their job), and then eventually got so big that they became the main program in which you plug your own moving parts: frameworks. Moreover, it is interesting to note that in the same time, the opposite trend exists: some libraries used to be the "meat" of a program, but as connecting two programs in flexible ways is not always easy, that core was extracted and made available directly to other programs. Well-known examples are libCurl and zlib.
  - eru 4y ago
    I think grep was an example of the latter, too?
    - astrobe_ 4y ago
      Definitely, and your example makes me understand the point of view of OP better: why wouldn't programs also be loadable libraries?
      - classichasclass 4y ago
        TempleOS works like that. You can just call functions directly in any program. http://www.codersnotes.com/notes/a-constructive-look-at-templeos/ http://www.codersnotes.com/notes/a-constructive-look-at-temp...
- jayd16 4y ago
  If I import a library, I probably don't want to spend the overhead importing a gui I won't be using. Code stripping could handle it but that assumes you know how to strip the libraries safely. Another way to look at it is other needs outstrip the mild convenience of packaging library and exe code together.
  - throwaway09223 4y ago
    What GUI? I think you're misunderstanding. No one is proposing changing how things link. The concept here is that executables and objects are the same structures and there's no reason why we shouldn't be able to link to a routine found in /bin/ls as we would link to a routine found in libm.so. This has nothing to do with "packaging library and exe code together."
    - jayd16 4y ago
      I suppose I extrapolated a bit too far but I don't really see the point if not to package them together. If you wanted to link against an executable such that it was safe to do so, why not go further and pull apart a library for that executable and others anyway?
- mike_hock 4y ago
  Doesn't TFA demonstrate that they are, in fact, the same concept?
- layer8 4y ago
  With executables you know they have one and only one entry point that conforms to the OS’s process execution conventions, which is a useful property to have be immediately apparent. Libraries can be seen as either a superset (any number of such entry points, most often zero) or as the separate category of binaries having no such entry point. In the world of client-side rendering, one could ask a somewhat similar question of why HTML and JS files are a different thing, and why you can’t just load a JS file to run your SPA in a browser.
  - charcircuit 4y ago
    You could just error out if you tried to run something without a main function.
- arinlen 4y ago
  > As someone born in the 21st century, I've always found this to be a weird distinction. Why? I mean, what use do you see in executing a shared library? It sounds like adding complicated and unnecessary usecases.
  - eterps 4y ago
    It's the other way around that can be suboptimal. If some application wants to integrate git it could execute in a subshell (which is frowned upon for good reasons) or use libgit instead. This works great in the case of git, but for all other useful stuff that doesnt have its own lib that provides that basic functionality you're out of luck.
    - arinlen 4y ago
      > It's the other way around that can be suboptimal. If some application wants to integrate git it could execute in a subshell (which is frowned upon for good reasons) or use libgit instead. What's wrong with invoking an executable or using libgit? It seems you're totally missing the whole point. The problem was never that you could not consume libraries from an executable. The actual problem is that you're somehow expecting to consume a third-party package in a way that the project maintainers do not support, let alone maintain. Adding a build flag that supports a convoluted and arguably useless usecases of linking with symbols shipped in third-party executables change nothing.
pjmlp 4y ago
You can still have something like that on Windows, thanks to PowerShell. All shared libraries, .NET and COM objects can be consumed by PowerShell scripts and REPL in such way. It isn't as deeply integrated, but close enough.
- FreakLegion 4y ago
  And in the opposite direction Windows executables can always be loaded as libraries. There's also rundll32 for libraries designed to be run like executables.
  - RajT88 4y ago
    .net core builds apps as *.dll's too.
  - jsmith45 4y ago
    For classic .NET, yes, all executables are fully valid libraries. (For .net core, the executables actually compile to dlls with a native runner executable sometimes included alongside it. (Depends on exact build command used). For win32, loading executables as code libraries is not officially supported. Now, it does sort-of work, but there are limitations that are totally undocumented. What is officially supported is dynamically loading executables to access resources.
  - pjmlp 4y ago
    Yes, PE format is quite flexible.
- pjc50 4y ago
  > All shared libraries, .NET and COM objects can be consumed by PowerShell scripts and REPL in such way How? (I've always had great difficulty with the discoverability of powershell features)
  - pjmlp 4y ago
    .NET by definition, as PowerShell is .NET based, then by making use of .NET interop capabilities into native libraries and COM. https://docs.microsoft.com/en-us/powershell/scripting/samples/creating-.net-and-com-objects--new-object- https://docs.microsoft.com/en-us/powershell/scripting/sample... https://devblogs.microsoft.com/scripting/learn-how-to-use-net-framework-commands-inside-windows-powershell/ https://devblogs.microsoft.com/scripting/learn-how-to-use-ne...

by eterps 4y ago

magnio 4y ago

As someone born in the 21st century, I've always found this to be a weird distinction. Why can't we unify them in just one concept?

pjmlp 4y ago
Because they cover different scenarios. If you want the previous one concept, you can get it via static linking alongside OS IPC. However it requires more OS resources and is complexer to program. Now every shared functionality has to do a shared memory or pipe configuration dance, to expose their functionality.
astrobe_ 4y ago
Maybe it looks weird now because libraries were collections of subroutines, then have evolved as sub-programs (some spawn their own threads to do their job), and then eventually got so big that they became the main program in which you plug your own moving parts: frameworks. Moreover, it is interesting to note that in the same time, the opposite trend exists: some libraries used to be the "meat" of a program, but as connecting two programs in flexible ways is not always easy, that core was extracted and made available directly to other programs. Well-known examples are libCurl and zlib.
- eru 4y ago
  I think grep was an example of the latter, too?
  - astrobe_ 4y ago
    Definitely, and your example makes me understand the point of view of OP better: why wouldn't programs also be loadable libraries?
    - classichasclass 4y ago
      TempleOS works like that. You can just call functions directly in any program. http://www.codersnotes.com/notes/a-constructive-look-at-templeos/ http://www.codersnotes.com/notes/a-constructive-look-at-temp...
jayd16 4y ago
If I import a library, I probably don't want to spend the overhead importing a gui I won't be using. Code stripping could handle it but that assumes you know how to strip the libraries safely. Another way to look at it is other needs outstrip the mild convenience of packaging library and exe code together.
- throwaway09223 4y ago
  What GUI? I think you're misunderstanding. No one is proposing changing how things link. The concept here is that executables and objects are the same structures and there's no reason why we shouldn't be able to link to a routine found in /bin/ls as we would link to a routine found in libm.so. This has nothing to do with "packaging library and exe code together."
  - jayd16 4y ago
    I suppose I extrapolated a bit too far but I don't really see the point if not to package them together. If you wanted to link against an executable such that it was safe to do so, why not go further and pull apart a library for that executable and others anyway?
mike_hock 4y ago
Doesn't TFA demonstrate that they are, in fact, the same concept?
layer8 4y ago
With executables you know they have one and only one entry point that conforms to the OS’s process execution conventions, which is a useful property to have be immediately apparent. Libraries can be seen as either a superset (any number of such entry points, most often zero) or as the separate category of binaries having no such entry point. In the world of client-side rendering, one could ask a somewhat similar question of why HTML and JS files are a different thing, and why you can’t just load a JS file to run your SPA in a browser.
- charcircuit 4y ago
  You could just error out if you tried to run something without a main function.
arinlen 4y ago
> As someone born in the 21st century, I've always found this to be a weird distinction. Why? I mean, what use do you see in executing a shared library? It sounds like adding complicated and unnecessary usecases.
- eterps 4y ago
  It's the other way around that can be suboptimal. If some application wants to integrate git it could execute in a subshell (which is frowned upon for good reasons) or use libgit instead. This works great in the case of git, but for all other useful stuff that doesnt have its own lib that provides that basic functionality you're out of luck.
  - arinlen 4y ago
    > It's the other way around that can be suboptimal. If some application wants to integrate git it could execute in a subshell (which is frowned upon for good reasons) or use libgit instead. What's wrong with invoking an executable or using libgit? It seems you're totally missing the whole point. The problem was never that you could not consume libraries from an executable. The actual problem is that you're somehow expecting to consume a third-party package in a way that the project maintainers do not support, let alone maintain. Adding a build flag that supports a convoluted and arguably useless usecases of linking with symbols shipped in third-party executables change nothing.

pjmlp 4y ago

You can still have something like that on Windows, thanks to PowerShell. All shared libraries, .NET and COM objects can be consumed by PowerShell scripts and REPL in such way. It isn't as deeply integrated, but close enough.

FreakLegion 4y ago
And in the opposite direction Windows executables can always be loaded as libraries. There's also rundll32 for libraries designed to be run like executables.
- RajT88 4y ago
  .net core builds apps as *.dll's too.
- jsmith45 4y ago
  For classic .NET, yes, all executables are fully valid libraries. (For .net core, the executables actually compile to dlls with a native runner executable sometimes included alongside it. (Depends on exact build command used). For win32, loading executables as code libraries is not officially supported. Now, it does sort-of work, but there are limitations that are totally undocumented. What is officially supported is dynamically loading executables to access resources.
- pjmlp 4y ago
  Yes, PE format is quite flexible.
pjc50 4y ago
> All shared libraries, .NET and COM objects can be consumed by PowerShell scripts and REPL in such way How? (I've always had great difficulty with the discoverability of powershell features)
- pjmlp 4y ago
  .NET by definition, as PowerShell is .NET based, then by making use of .NET interop capabilities into native libraries and COM. https://docs.microsoft.com/en-us/powershell/scripting/samples/creating-.net-and-com-objects--new-object- https://docs.microsoft.com/en-us/powershell/scripting/sample... https://devblogs.microsoft.com/scripting/learn-how-to-use-net-framework-commands-inside-windows-powershell/ https://devblogs.microsoft.com/scripting/learn-how-to-use-ne...