Actually, the whole concept of cancer screening is questionable. For example, you often hear the idea that catching cancer early extends your life span. However, the reality is that cancer has a time line of something like 20 years between the time you get it and the time it kills. If you catch the cancer at year 15, you will have five years to live, even without treatment. If you catch it at year 5, you have 15 years to live even without treatment. This biases the treatment statistics and makes it appear that catching it at year 5 gave the patient 10 extra years of life. This makes everyone think catching early is always best, but unless you take into account the natural life time of the disease, really don't know if treatment helps. Now if catching it early gave you 30 more years of life on 20 year disease, that would be real evidence of successful treament.
Actually, a "CPU Driver" would probably contain code to handle specialize features of certain CPU's. For example, in order to take full advantage of Hyperthreading, you would need different code to distribute threads between the two virtual processors. Likewise, there could be additional code to take advantage of extended instructions sets like MMX, SSE, 3DNow, etc. At the very least, it could contain information about which features are available in the CPU.
This thread misses an important point. Even though Ptolemy's theory was wrong, it was a lot closer to the truth than previous ideas like "the lights in the sky are gods with flashlights." The point is that even theories that are wrong add to our knowledge by providing a starting place for deeper inquiries.
"Windows attempted to execute something and failed...paying attention only to the extention till that failure occured."
Maybe we have different definitions of what the word "execute" means. To me it means that the Operating System points the Program Counter at the first byte of executable code in the program and allows the CPU to begin fetching and executing machine language instructions.
In the above mentioned scenario, this does not happen. What does happen is that Windows looks for two pairs of signature bytes in the file. The first, is "MZ" which is the signature for DOS programs. The second is "PE", which is the signature of Windows programs. Here is a description of these bytes:
"...paying attention only to the extention till that failure occured."
Actually, the operating system looks at both the extension and the signature bytes to make a decision about how the file should be handled. If the extension indicates that the file should be some kind of executable file, the operating system then looks at the signature bytes to see what to do next. If no signature byte are found, it gives the error message:
"File is not a valid Win32 application."
If only the first signature is present, Windows will attempt to "execute" the file as a DOS-style file, by calling the DOS loader. If both the first and second signature are present, it will attempt execute the file as a Windows program, by running the PE loader. Other data in the header gives more information about how the program should be executed. For example, whether the program should be executed in 16- or 32-bit mode etc. Only after going through all these steps, could the operating system "execute something" and "fail".
Linux uses a similar "magic number" system, which is just as easy to fake and trick a program into executing code. In fact, because Windows also checks the extension, it provides an extra layer of protection from accidental or malicious execution.
"Additonally, if a data file is renamed it can't be used; rename a.doc file to.whatsup_doc and it will be useless. Do the same under Unix, and nothing has changed but the name."
This only true of a relatively recent versions of Linux. Up until about 2001, Linux/Unix did not have any file association mechanism at all:
Like most operating systems, Unix/Linux has its history rooted in the "Program-Centric" model of operating systems. As a result, it did not have a need for a complete system of file associations. It has only adopted a "Document-Centric" model very recently in order to help it compete with Windows and the Mac OS.
Originally, all operating systems were "program-centric". In the 1980's, Apple (or maybe Xerox), invented the "document-centric" model. Microsoft immediately saw the advantage of the model and began to add file associations to Windows 3.1.
There are two models of file associations: "Hidden" and "Overt." In the hidden model, the file association information is contained within the file itself, which is hidden from the user. That way the user does not have to think about the details and the correct program is automatically executed to manipulate the file. As a result, it is ideal for computer novices. On the other, you cannot just look at the file and see what it is used for. Also, on some operating systems, changing association can be difficult, particularly when you want to change applications. It also does not work very well for ordinary ASCII files because it usually requires embedding a non-ASCII compatible binary signature in the file.
In the overt model, the association information is contained within a visible part of the filename, usually the ext
"If a file ends in.exe,.vbs,.bat,.scr, or one of lots of other extensions, Windows assumes it's executable and will load and run it when the user clicks on it."
This is factually incorrect. Windows looks at a signature bytes at the bigging of a file to tell if it is executable. You can verify this by creating a text file, changing its extension to "EXE" and then double clicking on it. Windows will give the error: "File is not a valid Win32 application." The same thing happens with SCR.
BAT files are actually text scripts, so Windows does execute them by extension, but then again Unix/Linus will do the same thing.
Slashdot Mirror
Actually, the whole concept of cancer screening is questionable. For example, you often hear the idea that catching cancer early extends your life span. However, the reality is that cancer has a time line of something like 20 years between the time you get it and the time it kills. If you catch the cancer at year 15, you will have five years to live, even without treatment. If you catch it at year 5, you have 15 years to live even without treatment. This biases the treatment statistics and makes it appear that catching it at year 5 gave the patient 10 extra years of life. This makes everyone think catching early is always best, but unless you take into account the natural life time of the disease, really don't know if treatment helps. Now if catching it early gave you 30 more years of life on 20 year disease, that would be real evidence of successful treament.
The 45-billion dollars in royalties must be the reason that tuition are going down.
Actually, a "CPU Driver" would probably contain code to handle specialize features of certain CPU's. For example, in order to take full advantage of Hyperthreading, you would need different code to distribute threads between the two virtual processors. Likewise, there could be additional code to take advantage of extended instructions sets like MMX, SSE, 3DNow, etc. At the very least, it could contain information about which features are available in the CPU.
This thread misses an important point. Even though Ptolemy's theory was wrong, it was a lot closer to the truth than previous ideas like "the lights in the sky are gods with flashlights." The point is that even theories that are wrong add to our knowledge by providing a starting place for deeper inquiries.
"Windows attempted to execute something and failed...paying attention
.doc .whatsup_doc and it will be useless. Do the same under Unix, and
only to the extention till that failure occured."
Maybe we have different definitions of what the word "execute" means. To
me it means that the Operating System points the Program Counter at the
first byte of executable code in the program and allows the CPU to begin
fetching and executing machine language instructions.
In the above mentioned scenario, this does not happen. What does happen
is that Windows looks for two pairs of signature bytes in the file. The
first, is "MZ" which is the signature for DOS programs. The second is "PE",
which is the signature of Windows programs. Here is a description of
these bytes:
http://msdn.microsoft.com/msdnmag/issues/02/02/P E/ default.aspx
"...paying attention only to the extention till that failure occured."
Actually, the operating system looks at both the extension and the
signature bytes to make a decision about how the file should be handled.
If the extension indicates that the file should be some kind of executable
file, the operating system then looks at the signature bytes to see what
to do next. If no signature byte are found, it gives the error message:
"File is not a valid Win32 application."
If only the first signature is present, Windows will attempt to "execute"
the file as a DOS-style file, by calling the DOS loader. If both the
first and second signature are present, it will attempt execute the file
as a Windows program, by running the PE loader. Other data in the header
gives more information about how the program should be executed. For
example, whether the program should be executed in 16- or 32-bit mode
etc. Only after going through all these steps, could the operating system
"execute something" and "fail".
Linux uses a similar "magic number" system, which is just as easy to fake
and trick a program into executing code. In fact, because Windows also checks
the extension, it provides an extra layer of protection from accidental or
malicious execution.
"Additonally, if a data file is renamed it can't be used; rename a
file to
nothing has changed but the name."
This only true of a relatively recent versions of Linux. Up until about
2001, Linux/Unix did not have any file association mechanism at all:
http://www.pcquest.com/content/linux/handson/199 06 0101.asp
Like most operating systems, Unix/Linux has its history rooted in the
"Program-Centric" model of operating systems. As a result, it did not
have a need for a complete system of file associations. It has only
adopted a "Document-Centric" model very recently in order to help it
compete with Windows and the Mac OS.
Originally, all operating systems were "program-centric". In the 1980's,
Apple (or maybe Xerox), invented the "document-centric" model. Microsoft
immediately saw the advantage of the model and began to add file
associations to Windows 3.1.
There are two models of file associations: "Hidden" and "Overt." In the
hidden model, the file association information is contained within the
file itself, which is hidden from the user. That way the user does not have
to think about the details and the correct program is automatically
executed to manipulate the file. As a result, it is ideal for computer
novices. On the other, you cannot just look at the file and see
what it is used for. Also, on some operating systems, changing association
can be difficult, particularly when you want to change applications. It
also does not work very well for ordinary ASCII files because it usually
requires embedding a non-ASCII compatible binary signature in the file.
In the overt model, the association information is contained within a
visible part of the filename, usually the ext
"If a file ends in .exe, .vbs, .bat, .scr, or one of lots of other extensions, Windows assumes it's executable and will load and run it when the user clicks on it."
This is factually incorrect. Windows looks at a signature bytes at the bigging of a file to tell if it is executable. You can verify this by creating a text file, changing its extension to "EXE" and then double clicking on it. Windows will give the error: "File is not a valid Win32 application." The same thing happens with SCR.
BAT files are actually text scripts, so Windows does execute them by extension, but then again Unix/Linus will do the same thing.