True Windows programs usually spend most of their time suspended, waiting for an os operation to finish or waiting for a mouse click or some other async event. So the os is in charge most of the time and can run a low-power idle process. If you write a program that runs compute-bound, as in a tight loop, it gobbles up CPU power.
My embedded programs (68K assembly, no OS) occasionally run a foreground WAIT instruction to reduce power consumption and do most of their work at interrupt level, typically running at a low average duty cycle. They can check, say, a pushbutton occasionally, without having to run a full-time tight loop. In fact, if you check a pushbutton, say, 10 times a second, you don't have to debounce it.
I had a bit of a turn the other day - I _have_ to use Windows, for certain software; just to plug a hole, I downloaded firefox to use for browsing. I was kind of astonished when W2K did the whole install, and I was only a normal user. The _ONLY_ files that are protected from other users are the ones on the system drive, under "my documents" or some such.
Echo: "I am NOT sure what you're talking about." I am yet in "kindergarten" and the permissions that I learned are in the last portion of alphabeth rwx repeated few times. When those were established "object-oriented" was maybe in last stages of pregnancy. Your "certainly" accepted 101%, they simple invested a little time to know what they are doing.
If you've logged on as an administrator or power-user, this sounds correct. I believe that "regular" users even in Win2K already didn't have the ability to modify system files (assuming an NTFS file system -- FAT32 has *no* security, realistically).
I agree that the default installation of Windows has pretty lousy security settings, but if you're actually going to sit around and try to secure a system, Window's security flexibility is actually a lot more sophisticated that UNIX's. As someone pointed out the other day, the problem is that realistically Microsoft had to wait until the problems with the lack of security made enough headlines that they could -- by default -- have Windows be locked down enough that people wouldn't immediately complain when they're prompted for a password every time they installed new software. If you're a stockholder in Microsoft, I suspect you might figure selling a billion copies of Windows and having a million of them be hacked is perhaps unfortunates but far better than only selling a million copies and having none of them hacked.
Windows was also slow to get around to having the OS more or less seamlessly prompt users for passwords when elevated prvileges are needed -- that was poor; Linux and OS/X definitely seem better in that respect. (Yet the Liunx GUI guys still can't get together and agree on a standardized method to have applications add icons to their start menus... sheesh... and at least on KDE, the start menu is still pre-historic compared to Windows'...)
(1) You did a single-user install. Some software packages can be installed for an individual user with only a user account. They are not accessible to other users.
(2) Your machine is not secure. Ordinary users should not be able to write in C:\\Program Files. This presumes the NTFS file system. A computer that was upgraded from Windows 98 may not have NTFS in use.
(3) You have a privileged account without knowing it. What are your group memberships?
krw's comments have good information. Here is a bit more detail, and some places you can look for more information:
The opcode in x86/ia32 is called "HLT" (no 'A'). As krw points out, this opcode has been in x86 for a long time (actually, since the 8086). Around the Pentium era, chip makers started to make a real effort to make the chip go into a lower power state when this instruction is executed. There are lots of ways to achieve this. Early chips would only stop various clock trees (with very respectable power decreases). Later generations added more and more platform facilities to help lower the power. As mentioned elsewhere in the thread, this includes voltage and frequency scaling, as well as techniques to reduce leakage.
A good description of what "HLT" should do is in the ACPI spec. The ACPI spec is freely downloadable at acpi.info. The HLT instruction corresponds to the C1 CPU state in ACPI terms. The main gist of the definition is that the latency for exit has to be small enough to be negligible, and cache coherency must be maintained while in the state. An interrupt should transition the CPU to C0 (full on state), but masters to memory do not (they just must be snooped properly).
The C2 CPU state is an even lower power state. The requirements are similar to the C1 state, but the biggest difference is that that wake time can be up to 100us. Cache coherency must still be maintained. On an x86, this state is entered by reading an I/O location (this I/O port could be implemented in several different places). The exact location to read is reported to the OS through the ACPI tables.
C3 is meant to be even lower power, and can have a wake time of up to
1ms. The difference between this state and C2 is that cache coherency does not have to be automatically be maintained; bus masters are actually "held off" in this state, and when one is detected, the system must sequence to a higher power state to allow the master and proper snooping to occur. The ACPI spec also describes a facility to flush the cache before entering this state (so masters don't have to be held off), but this isn't really a very optimal implementation.
Windows XP will use 'HLT' in its idle loop by default on an ACPI compliant system. If C2 is available (the OS knows this from the ACPI tables), XP will use it instead of C1. XP has some sort of prediction algorithm to know which of C2 or C3 to use, based on the latencies for each (also communicated to XP through the ACPI tables.)
A further level of performance/power management is with CPU "P-States". These are states that can be entered that lower the relative performance of the processor, while still running code. These can be implemented with clock throttling or with frequency scaling (or maybe some other way). The important difference between P and C states is that P states are used when code still needs to be running, but it is ok to run it at a reduced performance level. C states are used in "idle loops", where no code is running, and the system is waiting for an interrupt.
As a tangent to the original question, "WAIT" on an x86 is used to wait for an x87 FPU result. It doesn't really have anything to do with idle loops.
A bit more tangential: the P4 added a "PAUSE" opcode, which waits for "a while" before proceeding. The time waited is not specified in any databook. This instruction was added to be used in spin-lock loops, where a (logical) processor is spinning polling on a memory location. The PAUSE opcode is a hint to the processor that it is in a spin-wait loop, and it avoids a particular memory order violation that reduces performance. This was really added to help Intel's HT technology. Details are sort of scant, but you can find some information if you google for it. The relevant point is that a lower power state can be entered on the PAUSE instruction. It looks like it has been added to at least some version of the Win32 API:
formatting link
A good place to look for more information about "HLT" in in the Intel manuals:
formatting link
For more about C2, C3, and the fancy scaling stuff, you'll have to look at southbridge datasheets (ICHx for Intel stuff)
Sure it could. It didn't natively, IIRC, but there were several power saving add-ons available for any of the P54s/K6s/M1s/M2s.
So am I. If you modulate the clock one buys the 'F' term in P~CV^2. If you're going to modulate 'F' one can also modulate 'V' (since Max(F) is a function of V) and buy the V^2 term, as well. I believe TMTA was the first to do this, but it's commonplace now.
All pipelines consume less if you shut the clocks off. It's common for 40-50% of the active power to be dissipated by the clock trees. so developers have gotten quite aggressive with dynamic power management. Unfortunately, static power problems are here to stay (adding to the need for power supply modulation).
What brain-damaged design team decided to make a major processor state change happen when a location is *read*? That explains why my little i/o port scanner program hangs some PCs when it accesses certain port addresses.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.