>Hi Paul,
>Ponder this: Think about the Command Prompt utility in XP (I forget what it
>was called in prior versions). It pops up a window to allow the use of the
>command line. Does that not indicate that the OS is in fact running under the
>GUI? You need an OS to run command line programs. You can use the old MS-DOG
>commands such as dir, echo, etc. Are these a part of Windows?

That is the same as running in compatability mode. No proof one way or the other. If you want proof look for c:\\autoexec.bat it may be hidden or a system file so make sure those options are enabled. If your computer will boot without that file it is a windows OS if it will not boot you have a windows GUI. The XP computer I am typing on does not have that file, it will sometimes be created for compatability reasons even though it is not needed.

As I remember history up to win95 was a GUI on top of MSDOS. 98 and ME made windows progressivly less a GUI and more an OS. NT was the first real windows OS. XP is based on NT so it is also a real OS. 2000 I am not sure about but lean towards it being an OS.

---

BOINC WIKI

BOINCing since 2002/12/8

> 2000 I am not sure about but lean towards it being an OS.

Very crudely,
WinXP= Win2k+ eye candy.

---

Grant
Darwin NT

Siran,

> Hi Paul,

Hi!

> Ponder this: Think about the Command Prompt utility in XP (I forget what it
> was called in prior versions). It pops up a window to allow the use of the
> command line. Does that not indicate that the OS is in fact running under the
> GUI? You need an OS to run command line programs. You can use the old MS-DOG
> commands such as dir, echo, etc. Are these a part of Windows?

To me, the most critical aspect of the distinction of OS or not is the part of the definition where the OS controls the computer's resources. This means that the OS always and forever manages the resources, the most of important of which is the CPU and its allocation to tasks. In this case it means that the OS can, and will, prempt any task when its time limit is up. Most of the DOS multi-tasking shells, Non-NT windows varients, Mac OS-9 and prior, etc. is that the sharing of the CPU is cooperatively managed by the applications themselves.

In the early days many programs "cheated", on those occasions they would simply not step back and let other programs run. On the early Macs the use of the API was so important that a lot of this was made transparant because each call to the API might result in the loss of the CPU for that application. On other Task Switchers these API calls were less important and so, a program could "starve" other applications of CPU resources, especially if the other programs were "playing niice" ...

To a great extent this is semantics and is only important in a "technical" sense. And as a teacher we make a lot of these distinctions for accuracy. But JKeck has it right, but I would say that the Amiga followed closely by the Apple Lisa were the first PC class machines with an OS ... The Macintosh computers did not have one for like, forever. But the system was so good that no one noticed ...

---

@Paul and JKeck:

Ok, I accept both of your explanations in this discussion. They tend to make the most sense to me.

But, I also accept this explanation which supports my beliefs, if not somewhat.

Thanks.... and I'll let the discussion drop.

L8R....

---

My Time: Sunday, 26 December 2004 - 09:55 AM --800 (Pacific Standard Time)

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

Siran,

> But, I also accept <a> href="http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_Overview/index.html#//apple_ref/doc/uid/TP40001067">this[/url]
> explanation which supports my beliefs, if not somewhat.

If you are talking specifically about the layer diagram that shows up fairly early that is a general model for all OS, and suprisingly enough also for the task managers. In short, all computers have the same boxes and similar arrangements of the "chunks" of stuff. The exact organization is the devil in the details. For example, when NT 3.51 first came out it had the security model of a true micro-kernal. On the hardware of the day it was slower than desired for that very reason.

To increase system speed, the kernal model was compromised to allow device drivers to run at the same security level as the kernal. Thus starting the famed blue "screen of death" which is still with us. Small errors in a device driver can bring down the whole OS, in a true microkernal the device driver would kill its process, but not the kernal. This gives the OS stability, at the penalty of slower context switches as the OS moves in and out of the kernal mode.

> Thanks.... and I'll let the discussion drop.

Don't stop now! :)

I/we are not trying to say that you are wrong, nor that you are right, but to better understand each other and to increase everyone's knowledge. One of my tenents as a teacher was that there are no stupid questions, and that if you had/have one; there are 10 more people out there that have the same one and are too shy to ask it ...

Any way, I live to teach ... :)

---

Actually, it's a clear indication that the OS has more than one user interface.

While it's interesting to discuss what is part of the UI and what is part of the OS, the line is fairly arbitrary.

> Ponder this: Think about the Command Prompt utility in XP (I forget what it
> was called in prior versions). It pops up a window to allow the use of the
> command line. Does that not indicate that the OS is in fact running under the
> GUI? You need an OS to run command line programs. You can use the old MS-DOG
> commands such as dir, echo, etc. Are these a part of Windows?

---

> Siran,
>
> > But, I also accept <a>
> href="http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_Overview/index.html#//apple_ref/doc/uid/TP40001067">this[/url]
> > explanation which supports my beliefs, if not somewhat.
>
> If you are talking specifically about the layer diagram that shows up fairly
> early that is a general model for all OS, and suprisingly enough also for the
> task managers. In short, all computers have the same boxes and similar
> arrangements of the "chunks" of stuff. The exact organization is the devil in
> the details. For example, when NT 3.51 first came out it had the security
> model of a true micro-kernal. On the hardware of the day it was slower than
> desired for that very reason.
>
> To increase system speed, the kernal model was compromised to allow device
> drivers to run at the same security level as the kernal. Thus starting the
> famed blue "screen of death" which is still with us. Small errors in a device
> driver can bring down the whole OS, in a true microkernal the device driver
> would kill its process, but not the kernal. This gives the OS stability, at
> the penalty of slower context switches as the OS moves in and out of the
> kernal mode.
>
> > Thanks.... and I'll let the discussion drop.
>
> Don't stop now! :)
>
> I/we are not trying to say that you are wrong, nor that you are right, but to
> better understand each other and to increase everyone's knowledge. One of my
> tenents as a teacher was that there are no stupid questions, and that if you
> had/have one; there are 10 more people out there that have the same one and
> are too shy to ask it ...
>
> Any way, I live to teach ... :)
>

How 'bout this? There's an OS built into Windoze the GUI. Now that also makes sense to me. Hmmmm....

L8R....

---

My Time: Monday, 27 December 2004 - 05:44 PM --800 (Pacific Standard Time)

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

> How 'bout this? There's an OS built into Windoze the GUI. Now that also
> makes sense to me. Hmmmm....

Nope, that's just not the way it is. Operating systems have a bootloader (AKA bootstrap) that usually points to the kernel. The kernel is the core of the system and is where the process/resource management takes place. Generally, device drivers are loaded next, and these can be either executed in Ring0 (kernel space) or user space depending on the kernel design. Now, it's quite possible for there to be a framebuffer video device in the kernel that is initialized and used to display something to the user during the boot process. Under modern Linux, I see a cute little penguin and a bunch of text messages. Windows uses the same type of framebuffer device to display the now-famous boot screens with the scrolling progress bars.

Under Windows, the framebuffer device finally gets overloaded by the video drivers that match your video card and then the GUI is loaded to display the login screen (or you get automagically logged into an account). Under Linux, for example, the situation is pretty much identical, except that the system administrator can decide whether to use graphical framebuffers, pure text console and/or start a graphical display manager such as kdm, gdm or xdm. On the framebuffer front, it would be quite simple to create a Linux boot process that hid pretty much any hint that a console login were possible instead of GUI.

Bottom line: Windows is an OS that has a GUI. Remember that the kernel is the foundation upon which all else is built.

The Windows Command Prompt is nothing more than another -- albeit sophisticated program -- called a command interpreter in the DOS/Windows world and a shell in the UNIX world. Historically, the DOS kernel would finish initializing, then load the device drivers from CONFIG.SYS and, finally, load an instance of COMMAND.COM, the command interpreter. Windows 95/98/Me all offered this same basic functionality, giving the choice of booting to a text console (command interpreter) or loading the GUI. NT, which shared its roots with OS/2, gave up the possibility to load directly to a command interpreter and gave us a GUI-only login under Windows.

Fun stuff, eh? :)

---

> > How 'bout this? There's an OS built into Windoze the GUI. Now that
> also
> > makes sense to me. Hmmmm....
>
> Nope, that's just not the way it is. Operating systems have a bootloader (AKA
> bootstrap) that usually points to the kernel. The kernel is the core of the
> system and is where the process/resource management takes place. Generally,
> device drivers are loaded next, and these can be either executed in Ring0
> (kernel space) or user space depending on the kernel design. Now, it's quite
> possible for there to be a framebuffer video device in the kernel that is
> initialized and used to display something to the user during the boot process.
> Under modern Linux, I see a cute little penguin and a bunch of text messages.
> Windows uses the same type of framebuffer device to display the now-famous
> boot screens with the scrolling progress bars.
>
> Under Windows, the framebuffer device finally gets overloaded by the video
> drivers that match your video card and then the GUI is loaded to display the
> login screen (or you get automagically logged into an account). Under Linux,
> for example, the situation is pretty much identical, except that the system
> administrator can decide whether to use graphical framebuffers, pure text
> console and/or start a graphical display manager such as kdm, gdm or xdm. On
> the framebuffer front, it would be quite simple to create a Linux boot process
> that hid pretty much any hint that a console login were possible instead of
> GUI.
>
> Bottom line: Windows is an OS that has a GUI. Remember that the kernel is the
> foundation upon which all else is built.
>
> The Windows Command Prompt is nothing more than another -- albeit
> sophisticated program -- called a command interpreter in the DOS/Windows world
> and a shell in the UNIX world. Historically, the DOS kernel would finish
> initializing, then load the device drivers from CONFIG.SYS and, finally, load
> an instance of COMMAND.COM, the command interpreter. Windows 95/98/Me all
> offered this same basic functionality, giving the choice of booting to a text
> console (command interpreter) or loading the GUI. NT, which shared its roots
> with OS/2, gave up the possibility to load directly to a command interpreter
> and gave us a GUI-only login under Windows.
>
> Fun stuff, eh? :)
>

Well now....! Trane, if I'm understanding what you wrote here, (I do misunderstand at times), this would tend to support what I've been saying all along. Windoze is a GUI running on top of the operating system. Windoze itself, what we interact with the PC with, IS a GUI with the OS loaded before it.

The command interpreter was also called a shell in my first OS called OS-9 (not to be confussed with Apple's OS 9). OS-9 ran on a Motorola 6809 CPU and a Hitachi? 6309 CPU. Later it was called OS-68K when Motorola came out with their many 68xxx CPUs. OS-9 was based on Unix and was written/distributed by a company called Microware.

You're right, fun stuff....

L8R....

---

My Time: Monday, 27 December 2004 - 07:42 PM --800 (Pacific Standard Time)

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

> Well now....! Trane, if I'm understanding what you wrote here, (I do
> misunderstand at times), this would tend to support what I've been saying all
> along. Windoze is a GUI running on top of the operating system. Windoze

Well, not quite. What you wrote was:

Contrary to popular belief, Windoze is NOT an Operating System. Windoze is a Graphical User Interface built over the top of the operating system. Remember when Windoze first came out? You could run MS-DOG programs and Windoze programs, although not necessarily concurrently. You had to have MS-DOG in order to run Windoze.

This statement could be considered to be valid for Windows up to v3.11 and it could be argued that Win 95/98/Me also followed this particular definition. The problem comes with how you define "operating system". Let's look at IBM's "Dictionary Of Computing, Eighth Edition (c)1987": operating system (OS): Software that controls the execution of programs. An operating system may provide services such as resource allocation, scheduling, input/output control, and data management. Note: Although operating systems are predominantly software, partial or complete hardware implementations are possible. The Tenth Edition (1993) and International Edition (1994) of the same book offers the same definition, slightly reworded.

The Microsoft Press "Computer Dictionary" (c)1994 offers this definition: Abbreviated OS; somtimes called the executive. The software responsible for controlling the allocation and usage of hardware resources such as memory, central processing unit (CPU) time, disk space, and peripheral devices. The operating system is the foundation on which applications, such as word-processing and spreadsheet programs are built. Popular operating systems include MS-DOS, the Macintosh OS, OS/2, Windows, Windows NT, and UNIX.

Obviously, Microsoft considers Windows to be an operating system. ;-)

> itself, what we interact with the PC with, IS a GUI with the OS loaded
> before it.

I don't agree. Because Windows systems do include resource management and task scheduling, etc., Windows is absolutely an OS. Even Win 3.11 worked cooperatively with the DOS kernel to provide additional operating system functionality than could be found in DOS alone. Modern Windows, moreover, do not offer any way to use the system without the GUI. It's a complete package.

I think some of the confusion lay with the definition of OS. Many folks, for example, call Linux an OS when, in fact, it's a kernel. The kernel alone is not an operating system. You need drivers and a user interface of some sort for the operating system to be complete. Whether that UI is textual or graphical in nature is beside the point.

> You're right, fun stuff....

Indeed. :-)

trane

---

I agree with just about all that Trane wrote, though I do make the distinction that the OS must manage the resources. For me, and some of the definitions I have from historical roots all indicate that this is the key feature.

From there, the test is to ask if the system manages the CPU time with no outside assistance. What he identifies as the Kernal does this task. When the task switching takes place through the involvement of the applications cooperating, means (to me) that the OS is not performing management it is only provifing services.

But, as management is in the eyes of the user ...

At any rate, as I said before. For the user, this is a bunch of academic nonesense ...

---

How about this!

Windows has become just a NAME for a complete system from Microsoft.

My 2 pennies worth!

---

Red Bull Air Racing

Gas price by zip at Seti

I'll see your 2¢, and raise you +1.

Windows is nothing more than a UI. The Kernel itself is what defines an OS. And as I see it, a platform is defined as UI+OS+CPU. Unfortunately most people who use computers cannot make the distinction between the three (or at least UI/OS), and therefore smear everything as being "Windows".

---

If there is no user interface what good is it?

---

Fred
BOINC Alpha, BOINC Beta, LHC Alpha, Einstein Alpha

Let me amend: Graphical UI. I wasn't referring to text UIs - Those are simply programs. GUIs are more along the lines of "environments"

In all honesty, who (except for 8-bit die-hards like myself and Linux/UNIX/BSD-ers) doesn't use a GUI?

But to answer your question: Clusters. A UI takes CPU overhead.

---

It's not just die-hard Linux/UNIX/BSD-ers, I'm not aware of many servers running a gui and there are a few of them around on that thing called the internet ;)

I run 5 linux machines and only 2 have gui's installed and running.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

I do believe we're finally narrowing this down to the truth:

1) The OS manages running tasks and interposes between them and the hardware.

2) The UI, which can be a GUI or a command console, is a running task that gives the user some control over the OS and other running tasks.

3) Windows 3.1 and 9x loaded a 16-bit OS (the DOS environment), then ran a GUI on top of it (16-bit GUI for Windows 3.1; 32-bit GUI for 9x). In each case, Windows ran as a hybrid GUI/OS, as it provided some hardware drivers in addition to the UI, and it provided multitasking capability that the underlying DOS lacked.

4) Windows NT/2K/XP/Server 2003 load a 32-bit OS on which the GUI runs, and they also have 32-bit command console UIs that can be invoked from the GUI. The command console UI should not be confused with DOS. Although it accepts many of the same commands, it is a 32-bit environment that only emulates DOS, and not perfectly. Some things about it just don't work the same way.

5) Linux is a 32-bit OS that runs a command console UI by default, but many people choose to run a GUI on it (and different GUIs at that).

Is the mud any clearer now?

---

Help keep SETI@home alive! Join The Planetary Society and crunch for our team!

Is the mud any clearer now?
As far as 32-bit extensions on a 16-bit file system for an 8-bit operating system for a 4-bit processor made by a two-bit company that can't stand one bit of competition is concerned... yes: The kernel is the OS, the UI is an app that interfaces with kernel, and other apps call upon the UI.

Now throw a monkey wrench into everything: Under "Classic" Mac OSs the UI and OS are inseparable. If one crashes, the other does as well. You'll never see a System 1 through System 9.2.2 Mac give you a fallback console, a text-based "the shit hit the fan" screen like the blue screen of death, or a kernel panic screen (Remember, I'm talking about Classic Mac OS). The only "exception" to this rule is if the debugger (MacsBug) is installed, and very few regular Mac users have even heard of it, let alone installed it and know how to use it.

As for OS X, falls under the Linux category. If you log in as >console, you're going to be in the text-based UI. In fact, if you really want to drive a Mac weenie nuts, comment out SystemStarter -gr ${VerboseFlag} ${SafeBoot} from /etc/rc - That will leave the user stranded in a console. So in OS X, the UI and OS are separate. In fact, I'm still figuring out how to install KDE to run atop Darwin (QT keeps f'ing up)...

---

OS stands for Operating System which includes many components. One of the components is the kernal. Another component is the UI and it can be GUI, TUI, RPC or any combination.

Together with the other components, it is called an operating system.

If you don't have a UI then the system becomes basically a dedicated controller which can't be changed remotely or locally.

Did I stir up the mud?

---

Red Bull Air Racing

Gas price by zip at Seti

> ... and therefore smear everything as being "Windows".

Well, remember Microsoft said quite plainly that taking IE out of the OS was impossible ... so if it was "smeared" it is their fault ...

And I like what Clay said ... that matches my basic definitions ... with the "better" OS versions you usually get multiple ways to manipulate the system. CMD.com is an example, along with the "shells" from UNIX ... Most command shells have a programming language that can be used. In most OS they are procedurally based with UNIX being "stream" based.

Command langages include DCL for VAX VMS, REXX for OS/2 and IBM mainframes, etc.

Clay, to refine a little, #3 in the early days of PCs the UI and the underlying "stuff" simulated the multitasking in most cases. But there were a few true OS available, including a couple that allowed multiple DOS environments to run at the same time.

---