In old days, computers that came from manufacturers like IBM, DCE was refrred to as system. The operating software for the system was referred to as “system software”. People who created that software were called “systems programmer”. Much of it invariably involved writing direct to metal/assembly code which is why systems programming has been associated with low level programming. People using this term to refer to task of doing some complex application architecture are doing it wrong.
What Is Systems Programming, Really?
91–93 of 93 posts
Re: What Is Systems Programming, Really?
#92Earlier quoted context omitted.
It seems a bit telling that you described one as "kernel" systems programming and the other as "system" systems programming.
Well, I think the distinction is fair, kernel systems programming is largely concerned with things a kernel would normally do (ie, a kernel or µC code), very close to the metal or such. Maybe bare metal systems programming would have been more accurate but I feel it doesn't convey the same meaning. System systems programming is what it says on the tin; it's about constructing systems, multiple objects interacting wit…
You can make a distinction between the kernel and the shell (shell = all the system tools between the kernel and the applications, cf. https://www.tutorialspoint.com/operating_system/images/linux... not only sh or bash), but this distinction remains an implementation detail, and you can change the position of this interface at will. From microkernels who handle only the messaging between processes, to OSes like Multic or Windows-NT that include even GUI operations in the kernel...
You cannot either count on the hardware protection to make the distinction. Some systems may use the hardware to protect objects at a different level of granularity. For example, capability based OSes will use a single address space, and use the hardware to protect not processes, but smaller objects (capabilities). Accesses and communications is not managed to prevent processes to access objects of other processes, but to prevent or allow access to capabilities. In a softer way, it's also the case of Lisp OS (including eg. GNU emacs). There's not much specific protection on these systems, but it still works safely, because you can access only the objects to which you have a reference, and you cannot compute random addresses (it's a controlled execution environment).
Re: What Is Systems Programming, Really?
#93> You should be able to forge a number into a pointer, since that’s how hardware works. It's a C-centric view of the world and I wonder what old school FORTRAN77 people or lispers would think of this. Anyway, I think the right to do this should be a privilege of the compiler. As soon as you claim this right, you abandon all possible support she can give you in battling all kinds of silly mistakes.
Pointers are not even necessary for writing operating systems or memory allocators. The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support so…
It is as unsafe as pointer, if those PEEK and POKE operations don't perform any control. But there's no reason to allow random PEEK and POKE from random processes. The system process that manage memory may be given the access rights to PEEK and POKE the memory manager registers. But not the IDE registers. And application processes won't have the right to PEEK and POKE anything.