OSDev.org

Of all the uses for ioctl(), that is probably the weakest one. The simplest solution is to have specialized calls to handle the terminal independent from stdin. You know, like how DOS does it, which might have been a big inspiration for someone called RDOS.

No, I do agree that ioctl() is a pretty big wart, but I see no other way to solve the problems it solves (namely driver-specific requests for device files), without breaking up all those requests into their own system calls, which has its own warts.
That does not allow you to insert data. It allows you to overwrite data in the middle, but not insert it.

The point I was trying to make is that every OS I am aware of only allows you to read and write in the middle or the end of a file, but not insert stuff. If you want to take an existing file and insert a new block some place in the middle, the only option you have is to create a new file, copy the data from the old file you want to keep, insert the new block, copy the tail of the file, then replace the old file with the new one. This is true on DOS, Windows, UNIX, OS-9, managarm, Fuchsia, and probably RDOS. I have yet to see anyone trying for an insert() system call. And for removal it is basically the same thing.

And indeed, that is how I would try to solve this problem, by adding a new system call that inserts new data at the current position, moving back the tail of the file. Or removes data at the current position, moving the tail of the file forward.
Can't say I'm a fan. It adds another special character that now cannot be used in file names anymore. This is a design limitation that will fall on your feet sooner or later. On Linux, the solution would have been to set up a loop device with a size limit, i.e. to create a new special device file that mirrors all the properties of the source file but has a smaller size. I think in this case the special problem requires a special solution rather than a general one.

DOS has INT 21 AH=44H, AL=01H.


My main goal is to have a purely public domain base system, from which the rest of the computer industry, including snazzy operating systems that you approve of, could be generated.

Without having to know or use any other language than C90.

Since none of the code base is dependent on filenames supporting semicolon, I don't believe it is possible for me to fall on my feet. It's basically all working already, unless you want to quibble that you need to start by only using the subset of C90 that is supported by SubC, as you begin your quest.

That's simple. A GUI should not use stdin, rather the native keyboard API that will give you key press & key release events. Implementing this through ioctl rather than defining a generic keyboard API is a bit insane. I'd even say that printing to screen should have it's own API. The only exception is if you want the user to be able to redirect output to a file, in which case you need to use stdout.

Disagree. You should define APIs for devices that have nothing to do with file IO since you want a consistent interface to the device and not hacks through ioctl.




I'd rather implement it by reading all the file data from the insert point to memory, write the new file data and then append the saved context. Of course, privided the content is not too large to buffer in memory.

Another file IO function that I find questionable is rename. I decided not to support it since it only works in certain contexts, and instead a file copy is always necessary.

I think we have completely different goals, and ioctl simply doesn't fit your goals.

The only thing available in C90 is stdin. If you have a ANSI/VT100 running a full-screen application, using ANSI escape sequences, the only thing available is stdout too.

The way I (at least choose to) interpret C90's setvbuf NBUF (in my C library, PDPCLIB) is to switch off character echo. That is good enough to get micro-emacs working, without doing anything outside of C90, unless you want to quibble about the ANSI escapes being outside of C90.

Well, C90 is not everything. You can decide to declare your OS syscalls in a header file (in my case: rdos.h), which will define a more suitable keyboard API that allows you to create GUI applications. Of course, it's also possible to use classes part of the rdos distribution that defines various widgets to make it easier to create a GUI app. I mostly create character mode applications for debugging purposes.

There is a saying "Money may not be everything, but it's a hell of a lot better than whatever comes second". So too with C90. C90 exists for a reason - not all systems can support GUIs. Even ANSI escape sequences are beyond what C90 guarantees. C90 is the minimal system. ANSI escapes is above minimal. Yes, you don't need ioctl or even C, if all you want to do is Turtle Graphics. Me, I'm trying to get micro-emacs to run on environments like IBM mainframes. C90 is available on IBM mainframes. ANSI escape sequences are sort of available too, but not if you're using a 3270 terminal. Is the rdos API available? If the rdos API is available is there any reason it isn't an ISO standard already?

That's a curious statement. My first reaction was an umbrageous, "C90 is a language, not an operating system," but then I remembered something. In what may have been the first ever book on the C language, (it was by Dennis Ritchie,) certain features, especially stdio, were described as being implemented by the underlying Unix. It went on to state that implementations of C on other systems should emulate these Unix-like features if not supported by the underlying system. C has been through a few changes since those early days, but I think it's still no great surprise that if you want C, you get some semblence of Unix. This may especially be true on mainframes as they share the same serial terminal user I/O that Unix was designed for.

IOctls are the sort of feature you'd expect the original authors of Unix to hate. I and several others in a community were very surprised when our resident Unix historian reported that they didn't think ioctls were particularly evil. Still, when they implemented Plan 9, they went with a different approach: sending messages to control files.

As for my opinion, redirection is awesome, but redirecting the output of a full-screen terminal program makes no sense. Why complexify stdio and not give it another API to talk to? And why require programs to link in a terminal control library when hardware drivers are the operating system's job? The latter particularly bothers me as I've had terminal compatibility issues. This and a lot more I could say in a rant against normal Unix practice and the kind of programs PDOS evidently aims to support. I'll use them if I have to, but I hate their IO design. Terminal control is the operating system's job but, especially in the relatively low-budget Unix, some operating system jobs have been left to application programmers to figure out.

I'm interested in this comment.

Ideally I would like a mathematical proof of which thing belongs in the OS and which thing belongs in the application, and to be able to prove that Unix stuffed up.

I don't think I'll get mathematical proof in computing (there's a thing called "axiom semantics" - but that's a different thing, and I'm not sure it's maths - and I know basically nothing about it anyway).

But I am after some sort of evidence that something is an OS's job. Or at least - start with a clear statement of which thing is an OS job, even if it is difficult to prove.

So far I haven't found an issue with PDOS-generic. I did find an issue with PDOS/386, hence the intended redesign.

I decided, without mathematical proof, that the fundamental thing was a distinction between block mode devices and character mode devices, and again, without mathematical proof, that the appropriate place to mask the difference was in the C library rather than the OS.

The MVS (mainframe) OS presents blocks directly to the application, but the C library comes to the rescue to hide that from the application programmer.

Unix only presents character mode devices to the application, so the C library's stdio.c is quite different - almost a rewrite.

However, Unix needs to access blocks itself (mainly sectors on a disk), so it can leverage the block mode flavor of the C library to do this translation instead of attempting to do it itself. So in PDOS-generic, the OS can sort of do an fopen("0x80", "r+b"); to access the first hard disk on a PC.

I have only really considered command line applications (like gcc) so far. Which is all that C90 documents.

Out of semi-necessity (fullscreen editor) I have also implemented ANSI escapes.

I still have a long way to go before I have finished everything I want to do with the above.

But I'm curious what OS model you are proposing that Unix has apparently failed at.

Oh, now you're making me think! Well, after some thought, I realized it's an opinion founded on things i no longer believe. When I formulated the opinion, I expected Unix to be like Plan 9, where many libraries are just shims to interface C to services. I thought of libraries as outside the OS; an unnecessary conceit. I also had ideas about complexity which I no longer believe. Particularly, my idea for terminals would have been to give programmers a very simple and clean interface, but this would have make it difficult to do some nice things with terminals connected over slow serial lines. Informing programs of limited terminal capabilities would also not be natural in my idea, though fits perfectly into the ncurses library. So it was all just an obsolete opinion I'd failed to reconsider. I'm sorry for the noise.

I reserve the right to dislike terminals anyway, but this has nothing to do with your OS. I have to use escape sequences myself in some Forth environments I'm stuck with. I have to admit full-screen editors are a necessity. Ken Thompson never needed one, but I guess he never had lead poisoning in childhood or had to deal with the kind of stresses we've seen more and more of as time goes by. I tried hard to imitate him, but I was born in London at what may have been the very peak of leaded fuel use and I'm not going to talk about my stress.

Regarding character versus block devices, I never quite understood why Unix needs that distinction. In Plan 9, you just have instructions on how to use each virtual file, documented in the server's man page. I guess the same is true of PDOS if you're only making the distinction in a library. I like that.

Thanks for the updated opinion, but just a clarification on this.

From the point of view of a C application programmer, PDOS is no different from any other system. Did I mislead you to think there was?

The thing that I am (starting to) do differently now is the relationship between the OS and the BIOS/HAL/higher level. In PDOS-generic (as distinct from PDOS/386 and presumably most other OSes), is that not even the OS has to deal with block mode. It gets to leverage the C library just as application programmers already do.

This might have eventuated because I am in the unusual position of having control of a C library. Other people could control one they obtained from elsewhere, but that's presumably not their main interest.

Thank you.


Ah, this is where we differ; I grew up with an operating system without a concept of standard input or output. (Atari 800 & related micros.) BASIC reserved i/o control block #0 so it could use it for PRINT and INPUT, but that was just BASIC. All through the 90s, I failed to understand tutorials because they assumed standard output was so universal, they didn't need to describe it. They just called it, "the output". I had no idea what this unnamed, unspecified output was. Only in 1999 or so did I finally figure it out from Linux documentation. I did get an MS-DOS machine in the 90s and quickly learned to like redirection, but my roots were in drawing pixels to the screen and command-line programs were just one class of software. Half the programs I used were full-screen TUI which, in MS-DOS, works by writing directly to screen memory. I could understand that just fine, but it took time to comprehend this stream-of-text utility software which was layered on top. It didn't help that Atari had a complex interface for it while MS-DOS and BIOS had clunky and inconsistent interfaces.

With all that as my background, I had no way of knowing standard output was some kind of universal truth to those tutorial writers, but of course those writers would think that way if they'd learned to code on mainframes with terminals. (Or minicomputers; many universities had a VAX.) You're talking the same way they did, so I feel obligated to say that PDOS is indeed different from any OS which lacks a concept of standard input and output. These days, I think it's a rather clever feature, but I understand those GUI OSs which eschew it altogether.


I always like to look at different ways of doing things. If it leads to easier development, it's a very good thing for the likes of us.

I wonder a little bit about non-C programs interacting with device files. I recall that when Linux needed to increase the size of the major and minor numbers of device files, there was a lot of fear of this causing incompatibility, and I don't know if things would be the same now. If, say, a Fortran program required block devices, would it be hard to port? Then again, the set of programs written in Fortran or Pascal which care about the intricacies of Unix device files is probably very small indeed.


That's not so unusual, I don't think. Anyone who wants to write a POSIX microkernel OS will have at least looked at it, I'm sure. And non-POSIX OS devs could do anything.

Interesting, but I don't think that changes what I said. It is the job of the C library author to convert "printf" into drawing pixels on screen for you. Note that redirection doesn't need to exist, and doesn't on PDOS.


I have not given any consideration to anything other than C90. I'm creating a starter system written entirely in C90 plus a little bit of necessary assembler. To run on arbitrary hardware.

I'm glad you found it interesting. I suppose my explanation doesn't change anything. A hypothetical C implemetation on an Atari 800 could do just as BASIC did. I could continue to argue the point, but honestly, it would be nitpicking your wording rather than saying anything interesting about your OS. In a pedantic sense, a GUI OS without a logging facility may have no all-purpose output for printf to use, but that is hardly interesting when programs under such an OS can use snprintf to create a string to display or fprintf to write to a file.

Exactly.


I don't mind you doing that. I'd like to know if I'm not using the correct terminology or whatever. So if I've said something slightly wrong, please let me know.


Did you mean my C library?


Are you classifying PDOS/386 as a GUI OS, or the Atari 800?


The programmer shouldn't have to do either of those things to display "hello world". printf is expected to do something sensible on that environment. When run in MVS batch, the printf output goes to the JES2 spool where it may be purged without ever being read, or printed out onto real paper, etc.