On 10/17/2013 10:32 PM, Miles Fidelman wrote:
berenger.morel@neutralite.org wrote:So, what you name an OS is only drivers+kernel? If so, then ok. But some people consider that it includes various other tools which does not require hardware accesses. I spoke about graphical applications, and you disagree. Matter of opinion, or maybe I did not used the good ones, I do not know. So, what about dpkg in debian? Is it a part of the OS? Is not it a ring 3 program? As for tar or shell?Boy do you like to raise issues that go into semantic grey areas :-)Not specially, but, to say that C has been made to build OSes only, you then have to determine what is an OS to make the previous statement useful. For that, I simply searched 3 different sources on the web, and all of them said that simple applications are part of the OS. Applications like file browsers and terminal emulators. Without using the same words for the same concepts, we can never understand the other :)I'm pretty sure that C was NOT written to build operating systems - though it's been used for that (notably Unix).
Yes, it was. It was developed in the late 60's and early 70's at AT&T's Bell Labs specifically to create Unix.
To quote from the first sentence of the Preface to the classic C book, "The C Programming Language" by Kernighan and Ritchie, published by Bell Labs in 1978 (pretty authoritative given that Ritchie was one of C's authors): "C is a general-purpose programming language ...."
Yes, the book came out around 1978 - several years AFTER C was initially developed (and used to create Unix), and after people had started to use C for applications programs.
Now there ARE "systems programming" languages that were created for the specific purpose of writing operating systems, compilers, and other systems software. BCPL comes to mind. PL360 and PL/S come to mind from the IBM world. As I recall, Burroughs used ALGOL to build operating systems, and Multics used PL/1.
I don't remember an OS built on ALGOL. That must have been an experience? :) I didn't use PL360, but PL/S was basically a subset of PL/1 with inline assembler capabilities. It was nice in that it took care of some of the "grunt work" (like do and while loops and if statements).
<snip>
I'd simply make the observation that most SQL queries are generated on the fly, by code - so the notion of building SQL requests to "experts" is a non-starter. Someone has to write the code that in turn generates SQL requests.
Not in my experience. I've found far more SQL statements are coded into the program, with variables or bind parameters for data which changes.
Think about it - the code following a SELECT statement has to know what the SELECT statement returned. It wouldn't make a lot of sense to change the tables, columns, etc. being used.
And in some RDBMS's (i.e. DB2), the static SQL statements are parsed and stored in the database by a preprocessor, eliminating significant overhead during execution time.
<snip> Jerry