It's a performance issue!

[Geek King]

and then some people would submit tickets complaining of "x-rated popups" (even while surfing g-rated sites). only problem is... again a behavioral issue... generic g-rated sites don't give you x-rated popups.

In their slight defense, you can't really make that kind of judgement anymore, as there are certain virus types that can spread through the streaming ads. Sites that don't have anything to do with porno could be infecting a viewer with popups. Not to long ago, I helped clean a popup virus from a friends computer, and we can almost certainly track it to You Tube, as that was all he did the day before it showed up. You can get these things from the oddest places now.

[otakuneko]

Because, older computers can't get ahead of itself.... seriously.

Windows is not really built for multi-processors, regardless of what microsoft wants to hype. Newer computers have nifty dual-processing and things get done before it needs to be done. Compound that over and over again, you'll get a flaky system.

My older computers, I don't have to wait to start queuing stuff to do. However, my main one. Oh no, I must wait until it's completely ready. Otherwise, errors start coming out. It's my own fault, I like my old software too much.

I do not buy it.

Multiprocessing has been around far longer than Windows.



As for defragging,
Sure. Wear out your disk all that much quicker for some infinitesimal, if any, gain.

[BlackIronCrown]

I love a good smack down:
.

*reads log*

Oh, shit. That person is going to get WHAMMED.
*shakes head*
Oh, n00b. When will you learn not to pull a fast one?

[PepperElf]

at my company a lot of those frivolous sites are blocked now - including many banners on "safe" sites, so they can't claim popups from ads. (no youtube or myspace at work)

[LostMyMind]

I do not buy it.

Multiprocessing has been around far longer than Windows.

Multiprocessing been around since the first computer... However, early PC OS (not mainframe OS) are not designed for multiprocessing neither is windows. The only PC OS that supported multiprocessors in those days were written for personal use by computer/physic science grad students. Commercial personal computer OSes don't multiprocess correctly, it still depends on the app to properly access the multiprocessing functions. Once XP placed 9x as the most common OS, software developers started to use those functions. Even then XP not really multiprocessing correctly, it's cheating. If you don't believe me, watch your multiprocessor CPU usage while running a older app/game. You'll see that one CPU will be practically doing nothing. True multiprocessing OS will spread the workload across all processors under the OS control.

Now that multiprocessors are common. Up until Vista, microsoft was just starting to stabilizing multiprocessing, however there are still several programs (and programmers) that still process (or code) the old way which gets messed up when things are done out of order.

While I personally dislike Vista, at least it better at internally support multiprocessing as long the software that you're running is done correctly. But it's still not true multiprocessing; each application is assigned a thread, which is assigned to a processor, which runs until that thread "finish" and gives control back to windows. Which is why "slow down" application still work for windows.

Now mainframe OSes are a different story, when you run an app under an mainframe. That app is not in control of it's data stream. The OS will move the data to whichever processor/time slice it determine that user/app has at that moment. Once that time slice is up, the OS gives the next guy in the queue access to the processor regardless of the state of the first app process. Which is a true multiprocessing OS. Processors still can only do one command at a time.

[Pedersen]

If you don't believe me, watch your multiprocessor CPU usage while running a older app/game. You'll see that one CPU will be practically doing nothing. True multiprocessing OS will spread the workload across all processors under the OS control.

I'm sorry, but this is incorrect. A multiprocessing OS is incapable of doing anything other than this. For proof, I point you to Linux, and any other UNIX. If you run a program that does its processing in a single thread, you will see one CPU run that job, period. Which CPU is running that job can change over the course of the job, but only one CPU can run it.

If you'd like, I'll write some long running single threaded demo apps for you that generate a lot of CPU usage and you can run them on a host of different operating systems. You will see the same behavior across all of them.

As to why the program won't switch to running on a different CPU? Modern CPUs have a highly predictive pipeline architecture. They break down any given single instruction into a series of steps. That pipeline architecture means that, on modern CPUs (say, post Pentium II) the CPU will be running many instructions simultaneously (I've even heard of 32 stage pipelines). Setting up such a pipeline is an expensive operation, and jobs will not be moved between CPUs without a very good reason.

Now that multiprocessors are common. Up until Vista, microsoft was just starting to stabilizing multiprocessing, however there are still several programs (and programmers) that still process (or code) the old way which gets messed up when things are done out of order.

I am no fan of Windows, of any variety. However, I will defend them here: Windows XP is built from Windows 2000 which is built from Windows NT, which is a completely different code lineage from Windows ME/98/95/3.1. Windows NT was built to handle multi-CPU from the ground up (amongst other things).

As such, Windows XP was, basically, waiting for it to become common place.

But it's still not true multiprocessing; each application is assigned a thread, which is assigned to a processor, which runs until that thread "finish" and gives control back to windows. Which is why "slow down" application still work for windows.

This is the difference between cooperative multi-tasking and preemptive multi-tasking. Cooperative multitasking was used by Windows 3.1 and MacOS until (I believe) version 9 (though, for some reason, version 7 is sticking in my brain as I type this).

Cooperative multitasking requires programs to return control to the operating system before other jobs can resume.

Preemptive multitasking sees the operating system decide when to take control back from programs.

The whole page on Computer Multi-Tasking is actually very informative on these topics.

Windows NT, 95, 98, 98SE, ME, 2000, XP, XP64, 2003, and Vista are all preemptive multitasking. As are Mac OSX, Linux, and all varieties of UNIX, plus the various mainframe OSes (z/OS, S/390, AS/400, and others).

Now mainframe OSes are a different story, when you run an app under an mainframe.

See above for differences between cooperative and preemptive. You've described preemptive here.

Processors still can only do one command at a time.

And, as I showed above, modern processors are actually executing many instructions in parallel on a single CPU, simultaneously, using instruction pipelines.

I hate to defend Windows, I really do. But, if you want to tear it down, do so using valid reasons. I'll help you there. But the reasons listed above simply aren't on that list.

[LostMyMind]

I'm sorry, but this is incorrect. A multiprocessing OS is incapable of doing anything other than this. For proof, I point you to Linux, and any other UNIX. If you run a program that does its processing in a single thread, you will see one CPU run that job, period. Which CPU is running that job can change over the course of the job, but only one CPU can run it.

Pulling out Linux as a trump card while discussing how window works internally, don't give you points. However, I'm going to assume since you made this statement you never worked on a old mainframe. Also you reinforced my point that regardless of how well the OS is "faking" multiprocessing, if the app is not coded to play along, only one CPU is doing the work. Old mainframe OS don't care if the app not coded correctly or not. The processor timeslice is on the OS terms not the app. Which is not the case with windows. Unix is better at it, but it's still not true multi-processor OS.

If you'd like, I'll write some long running single threaded demo apps for you that generate a lot of CPU usage and you can run them on a host of different operating systems. You will see the same behavior across all of them.

I can do that myself. I also can write an application to properly use multiple CPUs and you won't see that behavior. However, it would require quite a bit of OS overrides.

As to why the program won't switch to running on a different CPU? Modern CPUs have a highly predictive pipeline architecture. ...Setting up such a pipeline is an expensive operation, and jobs will not be moved between CPUs without a very good reason.

Not quite true, all processors still work the same way as they did back in the 70s. They have registers. you fill the register with data. Issue a processor command (you know assembly). Then the processor spits out a result in the register. Granted, the list of commands is bigger as well as the register. But the process is the same. You are correct in saying that each "process" is on one CPU, but there is no reason the OS can't pull the results off the register and copy it to another CPU and have that CPU do the next command. Other than the time it takes to copy the data from the register.

I am no fan of Windows, of any variety. However, I will defend them here: Windows XP is built from Windows 2000 which is built from Windows NT, which is a completely different code lineage from Windows ME/98/95/3.1. Windows NT was built to handle multi-CPU from the ground up (amongst other things).

Personally I like windows, it is my OS of choice. However, I'm not going to believe the media hype that microsoft put out. NT, 2000 as well as XP all have code from win9x/3.1 in their system. Granted alot of been replaced. But there is a difference between being able to support having more than one CPU and being an multi-CPU OS. Windows NT/2000/XP is not an multi-CPU OS. In fact, an common trick in those days was to set NT "network" dlls (which are apps) to run on the 2nd CPU (for those lucky few that had funds to buy multi-CPU boards) while the file system ran on the 1st CPU. Win9x/me/3.1 (imo) are not true OS. It's a graphical interface to DOS. Which really sets of another off-topic annoyance of mine which I'm not going to get into.

This is the difference between cooperative multi-tasking and preemptive multi-tasking......The whole page on Computer Multi-Tasking is actually very informative on these topics.

Multi-tasking have nothing to do with how many processors you have. Multi-tasking is purely the rules of having multiple applications playing nice to each other. I'm talking purely OS. And window OS itself, is not an multi-processor OS. It supports having access to more than one CPU. But the OS don't say what CPU does what work, the apps running on top of the OS do.

Windows NT, 95, 98, 98SE, ME, 2000, XP, XP64, 2003, and Vista are all preemptive multitasking. As are Mac OSX, Linux, and all varieties of UNIX, plus the various mainframe OSes (z/OS, S/390, AS/400, and others)......
I hate to defend Windows, I really do. But, if you want to tear it down, do so using valid reasons. I'll help you there. But the reasons listed above simply aren't on that list.

While it's nice that you list quite a few modern mainframe (or mini-mainframe) OSes. Now that CPU are faster, OS cheat more. However, I'm talking older than that. Again, I was speaking purely on the multi-processing, not multi-tasking. My reasons are valid, and I don't live by some wiki list. I was there in those days. I lived it. I code for all those OSes. I've decompiled and tracked down issues with windows dlls (not by choice, I hated doing that). Wrote overrides to get around those issues. I know exactly how the internal processes work regarding windows. Since Vista came out after I retired, it's the only window OS I can't speak regarding it's internal process from experience.

If windows was a true multi-processor OS, it would be impossible to "lock" up the OS. But for personal PCs, the overhead to have a true multi-processor OS would be pricey (performance wise) and would not come about. Maybe one day it will, when quad processors become common.

However, back to the topic....

If you have a dual processor computer with windows XP on it, it can and will have issues if apps try to do things while the OS (more accurately, the graphical interface) isn't completely loaded. This don't happen with single CPU running XP. Because the app that trying to do something can't jump the line by running on the 2nd CPU.

Which is why media player crashes on my computer if I don't wait until the explorer dlls are completely loaded. I have to wait until windows switches to idle before starting up media player or it crashes explorer.

[otakuneko]

So the OS isn't multiprocessing because not all apps in the world are aware of or capable of using multiple processors.

Okay.

[Pedersen]

I'm impressed, I'll admit it. It's not often to see a post like this. However, I believe we are mixing up some terms due to age differences. As such, I'll now define how I've been using them. I invite you to do the same.

Multiprocessing: A system that has more than one CPU and runs separate programs on separate CPUs.

Multitasking: A system that runs multiple programs on one CPU, dividing the time that each program has on that CPU.

Cooperative Multitasking: A method of multitasking in which the program is in control of the amount of time it runs. For example, a program running on a cooperative multitasking system has the ability to monopolize all CPU, never letting another program run.

Preemptive Multitasking: A method of multitasking in which the operating system is in control of the amount of time a program runs. For example, a program running on a preemptive multitasking system is unable to tell if the instruction running immediately prior on the CPU came from that same program.

Multithreading: A way of creating what is known as a lightweight process which allows one program to have several sub-programs running under its control. More advanced operating systems have the capability to run separate threads on separate processors when they are available.

A system which is purely a multiprocessing system would be only capable of running as many programs as it has CPUs. So, if you have two CPUs, only two programs can run. Since the operating system has to have someplace to run, it would use one of them, and a single other program would run on the other one. Due to this, extremely few systems will ever be built which are purely multiprocessing systems. Instead, they will be multiprocessing and preemptive multitasking systems.

Now, with that out of the way, let's examine your post, shall we?

Pulling out Linux as a trump card while discussing how window works internally, don't give you points. However, I'm going to assume since you made this statement you never worked on a old mainframe. Also you reinforced my point that regardless of how well the OS is "faking" multiprocessing, if the app is not coded to play along, only one CPU is doing the work. Old mainframe OS don't care if the app not coded correctly or not. The processor timeslice is on the OS terms not the app. Which is not the case with windows. Unix is better at it, but it's still not true multi-processor OS.

You're right, I have never worked on a mainframe. Also, what you are describing is named by the rest of the computer industry (currently) as preemptive multitasking, not multiprocessing.

Your description of "faking" is rather misleading, as you are implying that older "mainframe" operating systems did not do the preemptive multitasking I described above. They did, and still do.

As such, when I say "single threaded demo app", I mean an application that, as far as both the application and the operating system are concerned, spawns no other applications or threads. It just does one task (for instance, a program that simply calculates digits of pi will be a single threaded application). A multi-threaded application will be something like a web server or database server, which needs to respond to multiple incoming requests simultaneously.

Finally, if you doubt what I am saying about the preemptive multitasking on a multiprocessing system, I suggest you contact your buddies who administer those mainframes. They will confirm for you that those operating systems are doing exactly what you have described (below) as "cheating".

Though, now that I think about it, there is one other possibility: You're referring to even older systems which ran in a batch mode only. They could well be multiprocessing systems without any sort of multitasking going on. I concede to the possibility of their existence, though doubt that more than a handful are still in use today.

Not quite true, all processors still work the same way as they did back in the 70s. They have registers. you fill the register with data. Issue a processor command (you know assembly). Then the processor spits out a result in the register. Granted, the list of commands is bigger as well as the register. But the process is the same. You are correct in saying that each "process" is on one CPU, but there is no reason the OS can't pull the results off the register and copy it to another CPU and have that CPU do the next command. Other than the time it takes to copy the data from the register.

Actually, processors have augmented that method quite a lot. As I said, they now include pipelines which allow them to execute several steps in parallel. To use your example, the pipeline allows the cpu to break the processing of a single instruction into the following stages:

1. Load Register
2. Execute op-code
3. Store Regsiter

By splitting things in this way, and designing the CPU appropriately, each of those phases can be executed independently in the same clock cycle for three different instructions. This is called pipelining. That article covers the subject in a great deal more depth. Coupled with everything else I have to say, I'd run out of space in this post (only a 15000 character limit).

Personally I like windows, it is my OS of choice. However, I'm not going to believe the media hype that microsoft put out. NT, 2000 as well as XP all have code from win9x/3.1 in their system. Granted alot of been replaced. But there is a difference between being able to support having more than one CPU and being an multi-CPU OS. Windows NT/2000/XP is not an multi-CPU OS. In fact, an common trick in those days was to set NT "network" dlls (which are apps) to run on the 2nd CPU (for those lucky few that had funds to buy multi-CPU boards) while the file system ran on the 1st CPU. Win9x/me/3.1 (imo) are not true OS. It's a graphical interface to DOS. Which really sets of another off-topic annoyance of mine which I'm not going to get into.

Well, we happen to agree on something there. Actually got into an argument with a college professor who told the class that Windows 95 was a true OS. Was greatly annoyed that I had to take his class because I didn't finish my degree some years before. And here I was dealing with someone who clearly didn't know what he was talking about. Glad he retired a couple years later.

Oh, and your belief is not required for Windows NT code line to be preemptive multitasking and multiprocessing. It has been so for an extremely long time (longer than I've been working with it, which goes back to 1995). You do not have to believe it for it to be fact. Much like the moon landings.

Multi-tasking have nothing to do with how many processors you have. Multi-tasking is purely the rules of having multiple applications playing nice to each other. I'm talking purely OS. And window OS itself, is not an multi-processor OS. It supports having access to more than one CPU. But the OS don't say what CPU does what work, the apps running on top of the OS do.

Actually, the Windows OS does dictate which CPU will run which application. The applications have the ability to request a specific CPU. The user has the ability to request that a specific app run on a specific CPU. But Windows, as an OS, very much does have that ability (and uses it).

While it's nice that you list quite a few modern mainframe (or mini-mainframe) OSes. Now that CPU are faster, OS cheat more. However, I'm talking older than that. Again, I was speaking purely on the multi-processing, not multi-tasking. My reasons are valid, and I don't live by some wiki list. I was there in those days. I lived it. I code for all those OSes. I've decompiled and tracked down issues with windows dlls (not by choice, I hated doing that). Wrote overrides to get around those issues. I know exactly how the internal processes work regarding windows. Since Vista came out after I retired, it's the only window OS I can't speak regarding it's internal process from experience.

Nice slam there. "I don't live by some wiki list". Very creative. I don't live by one either (that list was from memory). Instead, I live by my own experiences, and by learning from others, like Knuth (a name that I would sincerely hope you remember). I admit to not managing to understand even half of what he writes (mainly because I don't have the mathematical background to understand it all. The man is an absolute genius, and I genuinely hope he manages to complete the entire "Art of Computer Programming" set, I truly do). I've found my own problems with other people's code at all levels (application, driver, and OS modules). I've had to write workarounds for them, too. You're right, that stuff sucks.

If windows was a true multi-processor OS, it would be impossible to "lock" up the OS. But for personal PCs, the overhead to have a true multi-processor OS would be pricey (performance wise) and would not come about. Maybe one day it will, when quad processors become common.

So, you're saying that it is impossible to lock up Solaris, Linux, AS/400/ z/OS, S/390? After all, they are true multi-processor OS'es. Reality check: All of them can be locked up by a regular application if that application is coded properly. Heck, it's possible to lock up anything if you have enough information about it. None of these systems are perfect. Being a multiprocessor OS won't fix that. If anything, it will make it easier, as these systems get ever more complex.

If you have a dual processor computer with windows XP on it, it can and will have issues if apps try to do things while the OS (more accurately, the graphical interface) isn't completely loaded. This don't happen with single CPU running XP. Because the app that trying to do something can't jump the line by running on the 2nd CPU.

Actually, that is something else entirely. Since you've coded on multiprocessor systems and written programs that used multiple processors simultaneously, you don't need me to define a race condition for you, I'm sure. However, here's the definition of race condition that I use:

Race condition: A condition wherein two programs compete to get access to a resource. This will result in an intermittent bug. Sometimes, things will work smoothly, as the resources are accessed in the proper order for both programs to get what they need in the order they expect. Other times, they will not work, as other processes on the system slow down one of them, and the necessary resources are not acquired in the required order, resulting in crashes.

Now, what you've described is a race condition. When everything is running on one CPU, the OS scheduler manages to complete its resource acquisition correctly, and everything works. But, add in the second CPU, and suddenly the other application is able to work a little bit quicker, and the OS doesn't complete its resource acquisition correctly. Boom, crash.

This has nothing to do with whether or not Windows is a multiprocessor OS, and everything to do with a bug, either in Windows itself or a 3rd party app or driver. It should be fixed. But it does not remove the multiprocessor or the multitasking status from Windows as an operating system.

Which is why media player crashes on my computer if I don't wait until the explorer dlls are completely loaded. I have to wait until windows switches to idle before starting up media player or it crashes explorer.

In which case, have you reported this bug to Microsoft? I'm sure they'd love to prevent this, as (at a minimum) it results in a local denial of service attack that can possibly be exploited by a malware author.

[LostMyMind]

I'm impressed, I'll admit it. It's not often to see a post like this. However, I believe we are mixing up some terms due to age differences. As such, I'll now define how I've been using them. I invite you to do the same.

I kinda figure you were going to go there.

For simplicity stake, they don't exist anymore. Since CPUs have gotten so fast. It's most likely not going to exist again. (outside special OS made by math and physic grads, which I don't think they do anymore either)

As such, when I say "single threaded demo app", I mean an application that, as far as both the application and the operating system are concerned, spawns no other applications or threads. It just does one task (for instance, a program that simply calculates digits of pi will be a single threaded application). A multi-threaded application will be something like a web server or database server, which needs to respond to multiple incoming requests simultaneously.

This is getting into my little annoyance I didn't want to go into.

You are correct in the fact that an app coded will now days be ran on a single processor regardless of how many CPUs is attached to the machine. However, lets say you ran that heavy computing pi application on a 10 CPU computer that was running windows NT that has 500 other applications running at the same time.

A true multi-processor (CPU) OS, will move your app to around to whichever CPU is free. When the timeslice comes around again, the same CPU may not be free and moves the register (or pipeline which is just a bigger register) data to a free CPU. Windows does not do this. Which is why I say it's "faking/cheating".

However web/database servers still respond to 1 incoming request at a time. Once it accepts the incoming request, it spawns a thread (which is a fancier way of starting another copy of the same program in the same memory space) and transfer it to that thread. Then the "thread" competes the request and terminate itself. At least that how I wrote my database server..... If we go back in time before "threads", you actually had to write 2 apps. The first just watch the incoming port, when a request came in. It launch a new copy of the 2nd app with the reassigned port that it told the incoming request to redirect to.

though doubt that more than a handful are still in use today.

I did say older. Maybe I should have said ancient.

Actually, processors have augmented that method quite a lot. As I said, they now include pipelines which allow them to execute several steps in parallel.

Yes, and I did say the register gotten bigger too. But it's still a register, the pipeline was designed to remove the time it takes to copy data from the memory to the register for each command. So they gave processors the ability to run a batch from the much larger register.

And the parallel thing, is just spliting the 64 bit processor into two 32bit processors for a short time to process two 32bit commands in parallel.

Well, we happen to agree on something there. Actually got into an argument with a college professor who told the class that Windows 95 was a true OS.

I'm glad someone out there agrees with me on that. Graphical interfaces shell are not OS, it's just another application. But now days, it's common to accept that even the graphical interface shell is an OS. And we all have microsoft to thank for that.

Oh, and your belief is not required for Windows NT code line to be preemptive multitasking and multiprocessing. It has been so for an extremely long time (longer than I've been working with it, which goes back to 1995). You do not have to believe it for it to be fact. Much like the moon landings.

Also just because microsoft says it's the truth don't make it fact. NT does support multiple applications running at the same time. I never said that it didn't. I only said that windows is not a multi-processor (CPU) OS. It's not, just giving apps the ability to access multiple CPUs does not make the OS a multi-processor OS. A true multi-processor OS will have it's apps think there is only one CPU even if there is 10 CPUs available.

It's possible, I may just not be explaining it clearly enough.

Nice slam there.

a slam deserve a slam

I've found my own problems with other people's code at all levels (application, driver, and OS modules). I've had to write workarounds for them, too. You're right, that stuff sucks.

However sometimes is fun to find that little thing that makes blue screens.

So, you're saying that it is impossible to lock up Solaris, Linux, AS/400/ z/OS, S/390? After all, they are true multi-processor OS'es.

We'll agree to disagree. Nothing is bullet proof, in fact the moment you think you written something that is. It will take a bullet and break... At least in my experience.

Solaris and Linux while may support multi-processors. I don't include them in my list of true multi-processor OS.

AS/400, z/OS, and S/390 are mini-mainframe OS. They were designed to be a branch from the old (or should I say ancient) mainframes to the modern faster smaller systems. They have their problems. However it takes alot to crash em. But locking them up, no. It's crash (system wide) or that single app is in a continual loop (which don't effect any other app).

Reality check: All of them can be locked up by a regular application if that application is coded properly. Heck, it's possible to lock up anything if you have enough information about it. None of these systems are perfect. Being a multiprocessor OS won't fix that. If anything, it will make it easier, as these systems get ever more complex.

Outside exploiting hardware/OS software flaws, it's not possible to lock up an mainframe OS. Because the app does not have direct control of the CPU/hardware. You are correct in the fact that anything can be crashed. But locking up, no.

Just in case, I'll define "locking up" as in the OS lost control to an application and the OS can't take it back. And "crash" as in blue screen (since everyone knows what a blue screen is).

Actually, that is something else entirely.....Now, what you've described is a race condition. When everything is running on one CPU, the OS scheduler manages to complete its resource acquisition correctly, and everything works. But, add in the second CPU, and suddenly the other application is able to work a little bit quicker, and the OS doesn't complete its resource acquisition correctly. Boom, crash.

Yes, it's a race condition only because microsoft made explorer (in my case) a important part of the OS which has API calls outside of explorer hooking into explorer.

This has nothing to do with whether or not Windows is a multiprocessor OS, and everything to do with a bug, either in Windows itself or a 3rd party app or driver. It should be fixed. But it does not remove the multiprocessor or the multitasking status from Windows as an operating system.

Again, referring to what I already said. I never said that windows did not support multi-tasking. Nor did I say that windows does not support multi-processor (CPU). All I said is windows itself is not a multi-processor OS. The OS itself, not the 100 little apps that creates the "shell", does not utilize more than one CPU. It depends on all the apps to utilize the multiple CPUs, if it doesn't. It gets queued up on the primary CPU.

In which case, have you reported this bug to Microsoft? I'm sure they'd love to prevent this, as (at a minimum) it results in a local denial of service attack that can possibly be exploited by a malware author.

you're funny. They didn't care at least back in those days. Microsoft could care less about little math issues in their dlls that causes blue screens or race conditions. Since it'll bring up dr. watson and reboot explorer. What they care about the inconveniences of making someone wait until the computer goes into idle before they can actually start running apps that hook into explorer.

I actually talked to one of the lead developers of NT 3.5, talking about their "redesigned" vector drawing functions. Which I can plug in numbers and it will draw it in win9x but under NT I get an error. And she said, "I'll put it on my bugs list but it's unlikely that it'll change." So I had to include pre-math functions to "conditions" the numbers before sending it off to the GUI API.

The only bugs that get fix are ones that open holes to allow outside control of the OS. Or a exploit that virus writers are using. As long as nobody uses it and the legimate apps writers just work around it. It'll never get looked at.

[Pedersen]

You are correct in the fact that an app coded will now days be ran on a single processor regardless of how many CPUs is attached to the machine. However, lets say you ran that heavy computing pi application on a 10 CPU computer that was running windows NT that has 500 other applications running at the same time.

A true multi-processor (CPU) OS, will move your app to around to whichever CPU is free. When the timeslice comes around again, the same CPU may not be free and moves the register (or pipeline which is just a bigger register) data to a free CPU. Windows does not do this. Which is why I say it's "faking/cheating".

Ah, finally I see where the communication block lies. To everybody else, I apologize. This is now going into the realm of CPU arcana that most of you will simply watch your eyes glaze over.

First off, preemptive multitasking and the multiprocessor OS are doing something very similar here that you are ignoring (and that I neglected to account for in my earlier posts. For that, too, I apologize).

Dangit, must address something else first:

And the parallel thing, is just spliting the 64 bit processor into two 32bit processors for a short time to process two 32bit commands in parallel.

I have spelled this out as best I can. I have given links that spell it out in even more detail. This is flat out wrong. You are either failing to comprehend me, or refusing to read the links I have posted which go into more depth, or failing to comprehend them, or simply ignoring reality.

Here's yet another one: Instruction Pipelining. This one deals specifically with how instruction pipelines work in modern CPUs (both RISC and CISC). Please, read and comprehend that before spouting off more misinformation about what pipelining is.

It is not "splitting a 64 bit processor into two 32 bit processors". It is not even remotely similar to that.

I'm sorry, but this is really getting on my nerves the level of misinformation you are spreading on this topic. By refusing to pay attention to what pipelining is in modern CPUs, you are allowing other prejudices as regards mainframe vs non-mainframe to cloud your perception of what else is going on.

So, to return to the previous topic: Compilers (and operating systems) are written to try to take advantage of the pipeline. However, when the operating system stops a given process from running (for instance, one of the 500 other applications that you mentioned above), that pipeline is destroyed. Current CPU state information is copied off the CPU. The application is suspended. At that point, when the operating system comes back to that application, the state will be restored on whichever CPU is best suited for it (a choice made by the operating system, not by the application). For ease of potential problem diagnosis, the operating system will try to place that program back onto the same CPU. As a result, you will see cases where one application is using up all of one CPU, while the other CPU remains mostly idle.

This is by design, and does not alter the multiprocessor state of the operating sytem.

So, multiprocessor and preemptive multitasking both can move a job between CPUs. Both are likely to put it back on the same CPU when feasible.

However web/database servers still respond to 1 incoming request at a time. Once it accepts the incoming request, it spawns a thread (which is a fancier way of starting another copy of the same program in the same memory space) and transfer it to that thread. Then the "thread" competes the request and terminate itself. At least that how I wrote my database server..... If we go back in time before "threads", you actually had to write 2 apps. The first just watch the incoming port, when a request came in. It launch a new copy of the 2nd app with the reassigned port that it told the incoming request to redirect to.

Actually, this is how Apache works by default. You might have heard of it, as it is either most popular or second most popular web server around right now (forget if it, or MS IIS, is number 1 at the moment).

Outside exploiting hardware/OS software flaws, it's not possible to lock up an mainframe OS. Because the app does not have direct control of the CPU/hardware. You are correct in the fact that anything can be crashed. But locking up, no.

And now I will ask a very simple question: How is that any different from a non-mainframe OS? Here, I'll rephrase it to make the question more apparent:

"Outside exploiting hardware/OS software flaws, it's not possible to lock up a non-mainframe OS."

You can even quote it and explain why I'm wrong.

Again, referring to what I already said. I never said that windows did not support multi-tasking. Nor did I say that windows does not support multi-processor (CPU). All I said is windows itself is not a multi-processor OS. The OS itself, not the 100 little apps that creates the "shell", does not utilize more than one CPU. It depends on all the apps to utilize the multiple CPUs, if it doesn't. It gets queued up on the primary CPU.

Well, now we start to see a better picture of what you're talking about. Allow me to provide proof for you that you're wrong.

Start up a video encoding program. Doesn't matter what you're encoding. Just encode something that takes a long time. Oh, and make sure it's a bad encoder, that only runs on one processor. Now, while that's going on, start up a video playback program. Ideally, the codec should use a lot of CPU to decompress the video for playback. H.264 is good for this. Start playing a video while the decode is going on.

Finally, open the Windows task manager, and look at your CPUs. You will see that both of them are busy, even though neither of those apps are running on multiple cores.

[MadMike]

lastly... the dreaded "computer doesn't work" trouble call. much nicer when they actually say what's happening, like "computer doesn't turn on" or ... at least SOMETHING more than "doesn't work". bleh

I've gotten quite a few of those at my job. I don't deal with customers, I just do programming. However, every so often I have to deal with a user or marketing asshole person who has a problem or a question with a transaction, a report, etc.

While I like it when I can just sit at my desk, listen to some tunes, and do my job, I don't mind answering questions or helping solve a problem. However, it gets frustrating when they won't give me any useful info. One day, I got a report that one of the users was using a certain transaction, which ended up going down.

I couldn't recreate the problem or figure anything out from the log, so I requested information from the user, asking them what they were doing when the transaction when down. I got a reply back with something useless like, "I was using such-and-such transaction, and it went down."

Well, no shit, Sherlock! I can see that much! How about some information I can actually use? No, I didn't say that, but I wanted to. I did, however, vent my frustration to my supervisor, who contacted the user herself and asked the user for some information we could actually use (i.e. what keys were pressed, what kind of data was being added/changed/viewed, etc.) Never got a reply back.

[LostMyMind]

Here's yet another one: Instruction Pipelining. This one deals specifically with how instruction pipelines work in modern CPUs (both RISC and CISC). Please, read and comprehend that before spouting off more misinformation about what pipelining is.

That's from your link.

Instruction fetch
Instruction decode and register fetch
Execute
Memory access
Register write back

That sounds very much like. A larger register (CPU memory space), storing a batch of data and command, execute the commands, write the results to memory space.

You can try to cloud it with more details, but down at the very bottom. That's what its doing.

It is not "splitting a 64 bit processor into two 32 bit processors". It is not even remotely similar to that.

While some CPUs do have hyper-threading, which is basically CPU level based multi-CPU for a few commands. While I was talking about when before "hyper-threading", when 64bit processors came out and everyone was still on 32bit processing. That was a trick that was used, splitting 64bit into two 32bit. And Hyper-threading is basically using 2 CPUs via assembly level (which again bypasses OS).

Which still has nothing to do with pipelining.

Actually, this is how Apache works by default. You might have heard of it, as it is either most popular or second most popular web server around right now (forget if it, or MS IIS, is number 1 at the moment).

Apache that popular now Yes, I've heard of it. They were one of many different web servers that you could choose from back in the days. Or you wrote your own, it just happens that I rather write my own than depend on someone else "possible" flawed code. (in those days, now days I'm too lazy)

"Outside exploiting hardware/OS software flaws, it's not possible to lock up a non-mainframe OS."

I can write a simple application that will take control from windows, using windows API, not using any flaws or exploits. And windows will be locked out until my app returns control.

Try doing that with AS/400, z/OS.
To quote you,

First off, preemptive multitasking and the multiprocessor OS are doing something very similar

Which seems to me that you're agreeing with me that they're "cheating" to achieve a similar result.

Well, now we start to see a better picture of what you're talking about. Allow me to provide proof for you that you're wrong.....Finally, open the Windows task manager, and look at your CPUs. You will see that both of them are busy, even though neither of those apps are running on multiple cores.

That's because both apps are written to run only on one CPU. Have a app that is written to work on multi-CPUs and then run an app that will only run on a single CPU. And you'll see that one CPU is getting a bigger workout.

I'm going to guess that you don't have apps that have problems running on multi-CPU computers? I have several apps that I have to tell windows to "ignore" the extra CPUs while those are running. If windows was a true multi-CPU OS, this would never happen because the apps should not care how many CPU there are.
Until windows restrict access to hardware and force apps to process through the OS. This problem will always remain. Way too many apps are allowed to bypass the OS and access the hardware manually (including the CPU).

But like you said, we're getting into "realm of CPU arcana" (or OS arcana) and we can just agree to disagree.

[protege]

I've gotten quite a few of those at my job. I don't deal with customers, I just do programming. However, every so often I have to deal with a user or marketing asshole person who has a problem or a question with a transaction, a report, etc.

My favorite sort of calls...where the ones where the (l)user begs me to look at their screen, and then can't understand why I have no idea what's going on. I mean, all that's up there is their boring desktop photo, a few icons, etc. All looks perfectly normal to me... Pisses me off when they start complaining about how I "won't" help them

[Pedersen]

we can just agree to disagree.

I've tried, and as of now I've given up. I won't agree to disagree. I will just agree that attempting to use facts to penetrate your version of reality is pointless.