OSDev.org

kerravon wrote:

eekee wrote: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.

Exactly.

I could continue to argue the point, but honestly, it would be nitpicking your wording

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.

I admire your willingness to be corrected, and feel under pressure to be accurate. That's not a bad thing. What am I trying to do? My thoughts have been influenced the other recent thread on cooperation, in which the OP didn't realise how different from each other operating systems might be. Because of that, I'm arguing against your statement, "From the point of view of a C application programmer, PDOS is no different from any other system." I'm using standard IO and printf as examples of things which differ. I think it would be better to say, "PDOS offers full C90 support," or "PDOS offers full support for standard C90." Something like that.

kerravon wrote:

rather than saying anything interesting about your OS.

Did you mean my C library?

I was thinking of the two together, especially thinking of your C library as part of your OS.

kerravon wrote:

In a pedantic sense, a GUI OS

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

I tried to use GUI OSs as additional examples of systems where printf may not make sense. I should have started with them as they're the strongest example.

kerravon wrote:

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.

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.

Examples of systems which have an odd way to conform to the standard are interesting, but not really my point. My point is that there have been real OSs whose principles of operation so conflict with certain things in the C standard that the standard has to give way. Standard I/O is one of those things. It was very much against the principles of GUI OSs in the 80s & 90s. I've just grepped through the source (that I have) of one such GUI, OpenGEM, and found no instances of printf which made into an executable program. There are many instances of sprintf and [v]fprintf, but only 1 printf. It's in a tiny program; nothing more than a wrapper around strtok(), and it hasn't been compiled for distribution. It's not in the makefile. Perhaps the only reason it was even written in that way was that GEM runs on top of DOS and thus, when a program runs in DOS mode, standard output is available. No GEM program would use printf even though C is the language of much of GEM's source.

Would an OS implementor today choose to do without standard IO? Perhaps. Chuck Moore, "discoverer" of Forth, was able to make colorForth's interpreter considerably simpler than standard Forths in part by having it read keys directly. Dealing with arbitrary-length input lines coming from a pipe created complexity. There could be all sorts of arguments over whether such changes and standards-defiance are worthwhile, but the point is strange operating systems exist. They have been popular IRL. Mac OS was one of them prior to the release of OS X, and I'm almost 100% sure it didn't have any form of standard output at all. GEM was in the ROM of the Atari ST, and the ST's niches in Germany, CAD and desktop publishing, surely included much software written in C. Now I think about it, I'm not even sure Microsoft Windows programs have anywhere to send standard output if they're not the sort of program which wants a console open. (Windows can tell from the binary, somehow.)

eekee wrote:My point is that there have been real OSs whose principles of operation so conflict with certain things in the C standard that the standard has to give way. Standard I/O is one of those things. It was very much against the principles of GUI OSs in the 80s & 90s. I've just grepped through the source (that I have) of one such GUI, OpenGEM, and found no instances of printf which made into an executable program. There are many instances of sprintf and [v]fprintf, but only 1 printf. It's in a tiny program; nothing more than a wrapper around strtok(), and it hasn't been compiled for distribution. It's not in the makefile. Perhaps the only reason it was even written in that way was that GEM runs on top of DOS and thus, when a program runs in DOS mode, standard output is available. No GEM program would use printf even though C is the language of much of GEM's source.

Would an OS implementor today choose to do without standard IO?

Mac OS was one of them prior to the release of OS X, and I'm almost 100% sure it didn't have any form of standard output at all. GEM was in the ROM of the Atari ST, and the ST's niches in Germany, CAD and desktop publishing, surely included much software written in C. Now I think about it, I'm not even sure Microsoft Windows programs have anywhere to send standard output if they're not the sort of program which wants a console open. (Windows can tell from the binary, somehow.)

Thanks for your thoughts.

Surely this is not something that the OS simply can't choose to do without? If the OS has no sensible interrupt to call, or callback function, or well-defined I/O port to write to, to display the output of printf, then it is up to the C library author to create functionality to open a graphical window and use the write text facility, if it exists, or write pixels, assuming that exists. Or write to the serial port and require an ANSI terminal to be connected in order to run this program.

You can't simply decide not to implement printf. Otherwise it isn't C. Not hosted C, anyway.

I don't believe you can say that a GUI-only environment doesn't allow for a C implementation to implement the concept of a stdout stream. The stream can exist, regardless of whether the OS author likes that fact or not.

You already agreed that printf could have been implemented on the Atari the same way BASIC was.

You are correct that PDOS is different from early Windows in that the OS provides an easy way of displaying a stream to the user.

So if that is the only thing that needs correction then yes, I agree that my statement that PDOS is no different from any other OS was incorrect. It implements a class of OS that provides a convenient/integral way to display a C stdout stream.

eekee wrote: Examples of systems which have an odd way to conform to the standard are interesting, but not really my point. My point is that there have been real OSs whose principles of operation so conflict with certain things in the C standard that the standard has to give way.

Many of them didn't have compliant C implementations built-in, true, but that doesn't mean that a compliant C implementation on top of those OSes was impossible. If the OS doesn't provide a terminal, a compliant application might have to roll its own, but every GUI I've ever heard of provides some means of displaying text, so that shouldn't be overly difficult.

rdos wrote:
I think you are generalizing principles too far. UNIX has some very particular ways to deal with processes, VFS, libraries and syscalls so it's not a fact that UNIX once defined these and now everybody are just coping their concepts.

For one, UNIX has a very ugly fork concept, and Windows (and RDOS) does not normally create processes with fork. They both have a CreateProcess function. Both these OSes had a need to implement fork on top of this, but that's legacy cruft not copying. Fork in UNIX also have implicit requirements for what functions must exist in the paging environment, like reference counting and copy-on-write. UNIX also has the ugly concept of "exec" which is built-into compilers.

Even without COW, if you want any kind of shared memory, you'll need to have reference counting.

For my part, I'd actually generalize the fork/exec model *further*, but there's only one architecture I know of with the MMU features I'd need, and it's not really accessible to hobbyists. The resulting system would depart fairly strongly from the Unix assumption of a flat address space, though.

Syscalls are typically implemented through a central service (interrupt or processor specific syscall instruction) in UNIX. This is inefficient because function numbers must be coded at the caller side and decoded at the kernel side. I use call gates instead, which avoid both coding & decoding. Unfortunately, Intel and AMD optimized for OSes that used central service points.

This is an implementation detail, not a core part of what it means for an OS to be Unixy. TBH, it probably just boils down to how much Unix-likes have been ported between architectures. There are some stupidly-designed ISAs that only provide one trap vector into kernel mode. On those ISAs, any OS must have a central entry point, and if you port your OS to any such architecture, then you end up with more architecture-specific code if you don't use a single entry point on every architecture.

I can understand your consternation, kerravon; 80s/90s GUIs really were just that bad. For many reasons, I thought they were well and truly horrible. But they existed, were used widely, and far too many programmers Believed In Them. It's a little disturbing to look back upon. I think that's why I initially downplayed GUIs as an example; my subconscious mind recalled the horror only too clearly! And yet some OS devs around here seem to want to reimplement these things! (I'm not naming names; I'm not even recalling who are doing it, the choices in any one hobby OS are the prerogative of its designer and I don't want to spoil the enjoyment of anyone who -- pardon me -- somehow manages to enjoy such a design. I just sometimes notice a mention of traditional GUI or some such.)

So was there anything at all like a simple printf ready-implemented in traditional GUIs? Actually, yes: the dialog box, but I'm sure you can imagine how bad it would be to implement your whole UI with dialog boxes. Traditionally, they popped up over whatever else the user was doing, grabbing the keyboard without warning. (Massive angry rant elided.) Besides, dialog box functions are not named printf and so don't exactly alleviate the conflict with C standards.

What about implementing your own terminal? You technically could, but it was very much Not The Done Thing. On a Mac, you'd never get such a program into an Apple Store. GEM is more interesting because it ran on top of command-line OSs and could execute programs for the underlying OS. Initially written for DR-DOS, Atari's port is interesting in that they chose to implement an OS capable of running text-only programs with a built-in VT52 emulator, though not a command-line shell. There was this dichotomy: A program could either be a GUI program without a proper printf, or a text program with it, not both. What's interesting is that such text-only programs were vanishingly rare. I ended up inheriting a mountain of Atari ST floppy disks, but amongst all that, only 1 or 2 programs were text-only. The only one I remember was the raytracer, POV-Ray. It seemed the majority of C application programmers didn't want standard output.

This last bit is just a matter of feelings, but it might shed some light on why so many application programmers embraced GUI and rejected standard IO. I myself feel a little strange every time I see "application programmer" in connection with standard IO because I grew up in a world where standard IO was considered obsolete. Every application programmer wanted to draw on the screen or at least use GUI features. There didn't seem to be any reason for character cell hardware any more, with the Atari ST -- launched in 1984 -- managing its VT52 emulation and much more complex tasks just fine without it. In 1982, Rob Pike of Bell Labs had shown off animation playing in a window as it was being dragged around the screen, and that was on a cheap graphics terminal connected over a serial line. (38400 baud, but still.) 8-bit computers had been happily drawing pixels since the mid-70s. The future was graphics; why would anyone want to restrict themselves to text? To a large extent, I agree; I just hate certain specifics of traditional GUIs which got in the way quite nastily. All of these have been moderated over the last decade or two, though there is still a little unpleasantness.

eekee wrote:What about implementing your own terminal? You technically could, but it was very much Not The Done Thing. On a Mac, you'd never get such a program into an Apple Store.

This is the only thing I don't have an answer for. If you are constrained by a manufacturer effectively rejecting any application with a C library that implements printf, then you are right, there are environments where printf can't be implemented. But all the other cases you mentioned it was simply either implementers not choosing to implement C, including printf, or programmers choosing not to use the actual C language, that included printf, or at least choosing to use a non-ISO GUI interface over the ISO-provided printf. This is sort of like argumentum ad populum, and straying from any technical or conceptual issue.

Argumentum ad populum describes a fallacy. I'm trying to explain a reality: Many programmers -- inevitably including many C programmers -- hated text-only interfaces. Many operating system implementors hated them too. (I'm not even sure I should be using past tense.) Thus, there have been many "C application programmers" who hated using printf as such, and I recommend avoiding that phrase when describing your OS's capabilities. It risks overgeneralization.

eekee wrote:Argumentum ad populum describes a fallacy. I'm trying to explain a reality: Many programmers -- inevitably including many C programmers -- hated text-only interfaces. Many operating system implementors hated them too. (I'm not even sure I should be using past tense.) Thus, there have been many "C application programmers" who hated using printf as such, and I recommend avoiding that phrase when describing your OS's capabilities. It risks overgeneralization.

Ok, so one level of classification of OSes is whether they provide:

1. A convenient, official way of presenting a text interface.
2. A convenient, official way of presenting a graphical interface.
3. Both 1 and 2.

PDOS and MSDOS only provide number 1. Although both run apps in kernel mode so you can directly manipulate the hardware to do number 2. But presumably an OS that runs apps in user mode it would be impossible to implement graphics. And if you had a physical VT100 etc terminal it would be impossible too.

Some systems only provide number 2 and there may be management policy (rather than technical) constraints in implementing a text interface on top of a GUI-only system.

And I believe GUIs have never been standardized in the same way that terminals were (ANSI X3.64). I don't know why.

And even ANSI X3.64 is beyond the line mode that the C standards actually guarantee.

So the issue is my terminology that PDOS is "just another OS from the perspective of a C programmer". And correct terminology would be "PDOS is an OS that allows C to be implemented, including printf". Although quite frankly, Apple (or any other arbitrary company) could ship a rebadged PDOS and have a policy that they only allow applications that directly manipulate the graphics hardware, you're not allowed to call INT 21H to output text, and you're also not allowed to create a terminal window, shutting down the ability to provide a C application that uses printf, thus shutting down standard C.

They may have difficulty enforcing that policy though, unlike what they manage to do with their iphones.

But once again, this is a management policy rather than a technical aspect of PDOS. So I'm still not sure my terminology is incorrect.

rdos wrote:

kerravon wrote: How do you suggest switching stdin from line mode to character mode, so that I can use a full-screen application like a text editor?

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.

I'll note that Kerravon was talking about a TUI on a (real or emulated) terminal hanging off a (real or emulated) serial line, not a GUI.

eekee wrote:What about implementing your own terminal? You technically could, but it was very much Not The Done Thing. On a Mac, you'd never get such a program into an Apple Store.

In the classic MacOS era, it was much easier for third-party software developers to sell arbitrary software for Apple devices (no centralized online storefront with code-signing, and a healthy industry of brick-and-mortar stores independent of any vendor), so if the demand was there, whether it fit Apple's vision for UX hardly mattered.

Not sure if OP wants this from the scratch, not shure how many bots are here.
Anyway, some tactical decisions known to every moderator on this forum.
1) Ability to receive events (linux epoll_wait) and forced sleep of process must be combined in one function. This leads to more interesting (but optional) things - no need to save process context on sleep/resume(you zero everything) and RIP (x86) reposition at runtime because app is aware of significance of sleep. Sleep is more important concept here than receiving events.
2) this leads to simple fact that dev interrupt handler ring0-trampaline -> ring3 doesnt need restore/save regs
3) linux made mistake by allowing more than one timer within the kernel. Want to tell me why?
4) Not at this hour.