Summary

What to do about tasks that involve OS specific functions such as disk I/O or graphics.

Discussion

Just wondering: some tasks require some kind of system call. In C and assembly for instance, this means the syntax may vary greatly from system to system. Is it ok to give several solutions then? Examples: Create a file#C or Hello world/Graphical#C. I wrote a few things for DOS, OS/2 and Windows, and I have seen on several tasks that Linux and to a lesser extent Windows are frequent among answers. Is it ok to write things for DOS and OS/2? (or mainframes, but I have no access to that kind of machine) Woud they be considered too much obsolete, or too little known, or of no interest for the purpose of learning a language? (debatable, FreeDOS is maintained and so is ArcaOS, and there are stll many enthusiasts). I understand that if we allow every legacy system, things can quickly grow out of control, as there have been thousands of platforms, most of historical interest today. On the other hand, if we only allow POSIX/Windows, it seems very limited. Another obvious example of current "nonstandard" machine would be mainframes.

Of course, this shouldn't apply to tasks where the system call is only loosely related to the task: for instance, "print Fibonacci to screen" should probably not be shown for all kinds of screen I/O, as the task is mainly about Fibonacci. But for tasks which are specifically about a system feature, it seems sensible to show how it's done on lesser known systems.

Additionnally, for this kind of "system" task, for a given platform it's likely the answer will be similar in most languages, as it often involves some kind of system call available to most languages. This can be annoying - though this would not be the first time several answers on RC are similarly written: in some cases the same algorithm has been translated to dozens of languages.

Any thoughts on this?

While no authority on these matters I would say it is better to have multiple entries (for say win32, win64, lin32, and lin64) under one category, not scattered between categories. Speaking of which, I'm far from convinced that X86 and X86-64 Assembly should be different categories. --Pete Lomax (talk) 16:19, 25 February 2021 (UTC)

Yes, x86 is yet another matter... There are 16, 32 and 64 bit variants, and many OS-specific variations. On RC, I have mainly seen DOS (16 or 32 bits), Linux (32 or 64) and Windows (32 or 64), but it's far from complete: the UNIX versions will have different system calls, there are also 16-bit Windows (Windows 3.1 era), 16 and 32 bit OS/2, but also Minix, BeOS and Haiku, Plan9 etc. And OpenVMS is being ported. See also the Wikipedia categories wp:Category:X86_operating_systems and wp:Category:x86-64 operating systems. If we were to provide assembly source for all of these, we would need another RC site! Not even mentioning the CPU peculiarities such as SSE2/3/4, AVX, etc. which could matter on CPU-intensive tasks (linear algebra for instance). Now, I don't think it's the purpose of the site to show everything, and anyway to achieve this we would need people with the knowledge and motivation. My point was that programming chrestomathy can span to other matters related to libraries and operating systems, and while there are already examples of this on RC, it's not entirely clear where the limit may be, if there is one. I don't plan to go beyond DOS, OS/2, Windows and possibly the most common POSIX operating systems. However, thinking about it, it would be interesting to provide good code for LU decomposition (for instance), on various generations of Intel CPUs, to show the difference and benefit of the newer ones. I might work on it, but not right now. Bastet (talk) 18:56, 25 February 2021 (UTC)