💾 Archived View for soviet.circumlunar.space › zwatotem › diff › syscalls.gmi captured on 2023-01-29 at 03:06:33. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
It just recently struck me, that system shell is really just a program, just like every other program. It has no wider or narrower range of possibilities.
Taking the assembly course has been very eye opening so far.
It looks like system calls has been the primary way of communicating with an operating system, so good design of these is a deciding factor on the success of the entire OS. In particular we know, that Unix and Windows have very limiting standard for these. I'm not claiming to know everything about system calls in these operating systems, but limiting them only to use of registers sounds just like a bad idea. As far, as I know, however, Windows has "recently" rolled out a new official way of communicating with the OS through system functions. I don't know, how much they differ from usual system calls, but generally I think this is the way industry should be heading. The pinnacle of the bad consequences coming from this syscall oriented design is the exit syscall in Linux. Linux allowes for programs to only return single integer value (it may be long on 64 bit version, but I'm not sure about that). This has severe consequences on the way text-based shells for this system were designed. If programs cannot be treated as functions, that have one (possibly tupled) input at the beginning and one (possibly tupled) output at the end, other means of connecting programs together hard to be found. And it just so happened that the best thing that existed for it was file descriptors. Because once someone thought it's a good idea to say that everything is a file, console output was one as well, and thus shells started to fetch these streams and use them to emulate these functional behauviours. And from here we go straight to the unspecified format hell, that we get to see, with outputs being human readible just in case they are last in the chain, but that resulting in adding amount of noise and lack of machine readibility, that we have to deal with by using exploits, like sed, grep, wc, etc. Also I want to point out, that there was no other alternative. Inside a process it is a common practice (at least in C-like languages) to pass large arguments to functions via pointers, if they are particularly large, to avoid the overheard of copying. Even ignoring the fact that this is a terrible idea for data safety, this was impossible anyway, because memory, that the returning value would point to was paged, and managed by operating system, and safety concerns don't allow cross process memory access anyway.
I'm just wondering what the state of computer engineering would be right now, if there were any mechanism to return arbitrary structure to the system. Perhaps we'd see less side effects and more function and pureness orientation at the low level, cross-process/cross-language standard for types and memory alignment, and less time and budget of the world being dedicated to the conversion game at all the existing boundries.
I plan to issue the next update on the aforementioned problem, as I think ther e is a significant inherent tention between the authors of the modules and libraries of the world, but that'sfor the next one.
In the meantime I'm glad to let you know, that this episode of Zwatotem's gemlog was produced almost entirely with handwriting, which I feel is a major milestone in the development of human interfacing. This may have imposed a bit different style on the article, I wonder if it's better like this or not.