4 ms·

Just curious if someone has done OS dev in top down manner. That is, work within a modern multi-tasking OS like Windows or Linux and develop a collection of OS

Just curious if someone has done OS dev in top down manner. That is, work within a modern multi-tasking OS like Windows or Linux and develop a collection of OS components (in the form of host OS modules?) that gradually replace functionality of the host OS? I imagine this would be much easier to do under Linux rather than Windows since the ABI/API for hooking into is open and documented. This way one can start developing just those components that interest you first, although I imagine key areas like memory management, scheduling and interrupts may not be replaceable from within a running OS?

bsenftner 7y ago
If one is writing cross platform enterprise software, any aspects of the underlying OSes get abstracted away and replaced with logic specific to your product's business cases. It is not unheard for an enterprise vendor to promote specific hardware, OS or other environment aspect because their software has been developed with knowledge of error and performance situations native to that configuration. In many ways, a mature enterprise application is software that has been written to include all popular hardware and software environments.
dredmorbius 7y ago
GNU: https://en.wikipedia.org/wiki/GNU_Project https://en.wikipedia.org/wiki/GNU_Project
pjmlp 7y ago
That is what rich language runtimes are all about. When you do Common Lisp, Smalltalk, Java, .NET, Go, D, ... the underlying OS kind of loses its meaning. The standard library can bind to OS primitives, or you can implement your hardware abstraction layer that allows for the language runtime to run bare metal. If you squint a bit, UNIX is C's runtime, and gets everywhere via POSIX.
- jstimpfle 7y ago
  That's a misleading comment, and I can't find a valid point in there. You can run C on a different platform than UNIX, or "run it on bare metal", just as well. If you write C, you make reasonable abstractions, to achieve some amount of OS independency, just as well. And typical usage of "rich language runtimes" is on one of the mainstream OSes, just as well. You even often have some OS specific code in there, because the OS is not entirely interchangeable. So, the OS does not lose more of its meaning if you move to rich language runtime environments. Those language environments are mostly about garbage collection. Most other things that make the OS "lose its meaning" are just libraries (that you can write in any language).
  - pjmlp 7y ago
    Those language runtimes exist since the 60's, 10 years before C created the urban myth of being the first systems language, and many of them did not have anything to do with garbage collection. Developing on Windows, and deploying across several UNIX flavours, mainframes and embedded targets has been pretty much OS independent for me during the last two decades, regardless how much OS specific code those runtime libraries might have inside of them. Even if the CI/CD pipeline had to do OS specific builds.
    - jstimpfle 7y ago
      > Those language runtimes exist since the 60's, 10 years before C created the urban myth of being the first systems language I don't know what's your point here, or why you keep repeating this on HN hundreds of times. I didn't ever hear anyone claiming it was the "first systems language". Nor do I care. (We all want a better language. I haven't tried many, but any other systems language I've seen I've found awkward, starting with Pascal with its mess of 1-based vs 0-based indexing, case insensitivity, weird mix of ref-counted / manually managed, weird syntax choices, mess of basic string types, requirement to create tons of typealiases... going to older languages that have upper-case only identifiers, for example). As to rest - it's just a matter of libraries. Not runtimes. EDIT: it seems some definitions of runtime include standard libraries. So, whatever.

bsenftner 7y ago

If one is writing cross platform enterprise software, any aspects of the underlying OSes get abstracted away and replaced with logic specific to your product's business cases. It is not unheard for an enterprise vendor to promote specific hardware, OS or other environment aspect because their software has been developed with knowledge of error and performance situations native to that configuration. In many ways, a mature enterprise application is software that has been written to include all popular hardware and software environments.

dredmorbius 7y ago

GNU: https://en.wikipedia.org/wiki/GNU_Project https://en.wikipedia.org/wiki/GNU_Project

pjmlp 7y ago

That is what rich language runtimes are all about. When you do Common Lisp, Smalltalk, Java, .NET, Go, D, ... the underlying OS kind of loses its meaning. The standard library can bind to OS primitives, or you can implement your hardware abstraction layer that allows for the language runtime to run bare metal. If you squint a bit, UNIX is C's runtime, and gets everywhere via POSIX.

jstimpfle 7y ago
That's a misleading comment, and I can't find a valid point in there. You can run C on a different platform than UNIX, or "run it on bare metal", just as well. If you write C, you make reasonable abstractions, to achieve some amount of OS independency, just as well. And typical usage of "rich language runtimes" is on one of the mainstream OSes, just as well. You even often have some OS specific code in there, because the OS is not entirely interchangeable. So, the OS does not lose more of its meaning if you move to rich language runtime environments. Those language environments are mostly about garbage collection. Most other things that make the OS "lose its meaning" are just libraries (that you can write in any language).
- pjmlp 7y ago
  Those language runtimes exist since the 60's, 10 years before C created the urban myth of being the first systems language, and many of them did not have anything to do with garbage collection. Developing on Windows, and deploying across several UNIX flavours, mainframes and embedded targets has been pretty much OS independent for me during the last two decades, regardless how much OS specific code those runtime libraries might have inside of them. Even if the CI/CD pipeline had to do OS specific builds.
  - jstimpfle 7y ago
    > Those language runtimes exist since the 60's, 10 years before C created the urban myth of being the first systems language I don't know what's your point here, or why you keep repeating this on HN hundreds of times. I didn't ever hear anyone claiming it was the "first systems language". Nor do I care. (We all want a better language. I haven't tried many, but any other systems language I've seen I've found awkward, starting with Pascal with its mess of 1-based vs 0-based indexing, case insensitivity, weird mix of ref-counted / manually managed, weird syntax choices, mess of basic string types, requirement to create tons of typealiases... going to older languages that have upper-case only identifiers, for example). As to rest - it's just a matter of libraries. Not runtimes. EDIT: it seems some definitions of runtime include standard libraries. So, whatever.