Solar wrote:In a system without CLI. What is in argc, argv? What is cin / cout referring to?
TL;DR: Code: Select all
argc == 0
argv == cin == cout == cerr = NULL
... and the program fails (possibly with a protection fault) at line 7. Assuming that the C++ compiler allows it at all when generating code for such a system (and perhaps just as relevant given several of the systems in question,
that there is a C++ compiler available in the first place).
This does call for a more detailed discussion, I think.
As a rule, such a program won't run as intended (if at all) on a GUI-only system, any more than it would on an embedded one with no UI at all. They can't be used, since they don't exist. This was the case for Mac System prior to OS X, and IIRC, was also the case for Pilot OS and Genera. Historically, most text-based command shells didn't have them, either. The fact that you feel you can ask this question is mostly indicative of the influence of Unix and C on later operating systems.
To give the most immediate example of a graphical-only operating system user interface, the Mac System x.y OS had no CLI, and thus didn't support either CLI arguments nor any sort of standard input streams (or indeed, any sort of standard buffered stream input, period, at least not at first). Native Mac System x.y applications
never used program arguments or 'standard' streams, both of which were explicitly rejected for use in Apple User Interface Guidelines compliant programs (as in, any program which did use them would have no upward-compatibility support, and would not be given Apple validation).
However, some Unix-like IDEs, such as MPW, faked it by having a menu item which popped up a textbox, which you could enter the command into. They usually would also have a window which the C/C++ style standard input and output streams would be directed to. They sometimes even had a mini-shell window. However, these were only to be used for testing and/or in code ported from Unix (or later, MS-DOS).
This approach is pretty much unchanged in most current graphical IDEs such as Visual Studio, Eclipse, Code::Blocks, or XCode, for those who haven't tried to use any of those.
That aside, though, the majority of Mac development tools simply didn't have a concept of such things, and didn't need them. It has to be remembered that Unix and C had no real impact on the design of the original Mac 128K, or most other systems of its era for that matter. The assumption on the early Macintosh was that most programming would be in assembly, and anything which wasn't would be written in Pascal (this was also true of early versions of Windows, which is why prior to Win95, Windows system calls all used the Pascal calling conventions). Later, the main development tool would be Hypercard, which was a truly GUI-based environment.
(As an aside, the original Mac Toolkit, which defined the widgets and other components of the GUI, was written in
incredibly tight M68K assembly, mostly by one person, and squeezed into a 64KB ROM. Even for the time, this was quite an accomplishment.)
They were not alone in this - even among the various systems where a shell or TUI were the default interface, input streams were generally not supported (buffering generally was, at least on multiuser systems, but solely for the purpose of improving throughput - it generally wasn't exposed to the client-programmer in any meaningful way). The idea of always having a stdin, stdout, and stderr were assumptions of C mainly because they were part of the Thompson shell and its successors; most operating systems before the mid-1980s didn't have anything of the sort, including MS-DOS 1.x. The popularity of C was the main reason for the adoption of them later by the few CLIs developed after that time.
Note that the support for them
is a shell feature, not a Unix feature
per se. Unix did introduce buffered streams and piped IPC as kernel features to support them, some time around 1970 I think, but it was initially just a feature of the CLI. There is no real requirement for a Unix shell to support them, though one which didn't would be considered very poor indeed.
Similarly, while many operating systems had some form of program parameters (maybe most, but certainly not all), they generally worked very differently from the way C assumed it would. I don't know how it was done in, say, Tenex, ITS, or VMS, but I would hazard a guess that none of them resembled either the Unix shell's approach, or each other's. I don't know much about how they were used in CP/M or MS-DOS prior to 2.0, either.
I
know that none of the IBM operating systems prior to AIX had anything of the sort - certainly the batch-processing ones didn't, while the less said about their timesharing systems prior to VM/CMS, the better. As far as I know, CMS still doesn't have those.
In many cases - as I know you are aware, being familiar with the Commodore 64 and other 8-bit micros - the default interface was just a prompt for the programming language interpreter, whether that be a BASIC dialect (as with the above-mentioned micros, the original Dartmouth Timesharing System, and various business oriented OSes such as Pick), Forth, APL, Smalltalk (in the case of Pilot OS), or some flavor of the Lisp family (in the case of the various LispMs).
For that matter, the Tripos kernel which AmigaDOS would be based on assumed that the systems language would be BCPL, and I am pretty sure its UI used an interpreted subset of BCPL prior to it being ported to the Lorraine hardware in 1985.
So the question really isn't as obvious of one as you seem to expect, or at least wouldn't have been prior to the late 1980s. How would a
current-day OS developer handle this case? Well.... they could handle it however they choose, really, but they would probably want to consider the principle of least surprise when formulating their solution.
![[1]](http://rootdirectory.ddns.net/static/termux1.jpg){kind=link}
![[2]](http://rootdirectory.ddns.net/static/termux2.jpg){kind=link}
