CPU Identification
Debs
I know that some folk think it'sdaft to write code todetect older
processors, or that it's reinventing the wheel, or whatever, but I
ahve now completedmy ID code. It detects a wider range of processors
than I avhe sen on any site or any code example i avhe found elsewhere
(it has been successfully tested on a wide range of 32-bit x86
processors, and has correctly detected 40 or more models from 386 to
Socket 7).
Currently, it doesn't test the FPU (that's a lower priority, but will
be done as it is part of my OS initialisation code, and is needed to
make sure that the full range of instructions are available on all
systems). It also doesn't test the level of cache, as that is going to
be part of the code to initialise the processor (this code purely
detects what processor is in a system, and does nothing more).
It has been tested on the following range of processors:
Various Intel and AMD 386 and 486 (SX, DX, DX2, DX4)
Cx486DLC
TI 486SXL2 (detected as SXL as I don't know the difference)
Cx486DX
Cx486DX2
Cx486DX4
Cx5x86
AMD Am5x86
Cx6x86
Cx6x86L
Cx6x86MX
Cyrix MII
Pentium
AMD K5
AMD K6
AMD K6-2
Winchip C6
You'll note that doesn't include the more modern processors. If you
use this code and can confirm that it correctly identifies any later
processors, I'd be grateful (having 100+ old systems doesn't help much
when writing code for modern processors...).
The URL is:
<http://debs.future.easyspace.com/Programming/OS/index.html>
Note that the site layout (not the pages though) has been redesigned
recently, so it's easier to get around what little is on the site. I
expect to be adding to the site more than i avhe been, and will ahve
more ID information on there soon.There are a lot of sites with ID
data, but none that contain data relating to the full range of older
32-bit x86 processors. As such, I expect my site to be fairly unique
with regard to detecting obsolete processors (386 and 486 in
particular) because of the wide range that I have collected
information on.
The code does still need a certain amount of tidying up, but I'm
pretty pleased with myself for getting an excutable smaller than 10k
that can successfully detect all 32-bit x86 processors :) It is
written totally in x86 assembler (nasm code), and is not tied to any
specific operating system (that's because it's part of my OS set up
code).
Any comments will be welcome...
--
Debs
<debs> at <dwiles> <.> <demon> <.> <co> <.> <uk>
http://debs.future.easyspace.com/
----
I started out with nothing, and I still have most of it.
Aaron Gray
wow, great going, that is one megalithic bit of code. You are a very
brave person to have tackeled that.
How do you intend to maintain it, that is also a major feat. I might suggest
that you neaten it up, possibly modularize it, either into multiple files or
within the file. Then I would check with the Linux camp to see what their
cpu detection is like. They, the Linux kernel camp might want the code once
it is more mature. Another thing could it be migrated to C with minimal
inline
assembler ?
If you have not looked at it have a look at arch/i386/kernel/setup.c
It would be a good idea instead of just spooling out data to the screen to
produce a data structure with identification data, then to print that as a
separate task to the screen :)
I do not know whether you have came across it but another source of CPU
identification/detection source code is :-
Other thoughts, it might be worth compacting 8 bit ASCII into 6 bit for the
space gain ?
Your String style maybe worth putting into a macro, string compation could
possibly also be done as a macro, that way it could be transparent as to
whether it is compacted or not.
Better top level documenation may be a good idea. Macros are a bit odd
and not very clear at all.
oh, and, there is a reference to a "cpuid.txt" file in the header that is
not with the distribution.
(: I was thinking of a joint "operating system" project for
alt.os.development
which its only purpose is to identify and produce a report about the
hardware it is run on. This might unite the crew :)
That must have been fun !!!
Yay,
Aaron
Debs
On Fri, 5 Jul 2002 00:45:29 +0100, Aaron Gray spake thus:
>Hi,
> wow, great going, that is one megalithic bit of code. You are a very
>brave person to have tackeled that.
hehehe. thanks )
It looks more than it is - after preprocessing and removing all lines
which are not part of the code needed by the parser (ie leaving just
the required labels and instructions) it is only about 3000 or so
lines (I think maybe 3400) - I reckon over half of it is comments :)
Mind you, getting that much code and data down to 10k was fun!
>
>How do you intend to maintain it, that is also a major feat. I might suggest
>that you neaten it up, possibly modularize it, either into multiple files or
>within the file.
Currently it is intended to be compiled under nasm, which expects a
single input file when producing binary output (although I can
modularise it andthen cat the files together before assembling).
I plan ultimately to convert it so that as much as possible can be
done through C, with routines that are done in assembly being made
into object files and linked separately. Some of the code will be
easier to maintain if kept in separate files, so yes, I do plan to
modularise it before I incorporate it into an initialisation module.
I totally agree that in the longer term it will be easier to maintain
if more of the code is separated into functions, it just wasn't
necessary while initially writing and debugging the code. Large
portions of the code are only used once, so putting them into separate
functions will slow the code to a small extent, and once I ahve a lot
of other hardware detection code that small amount will add up. As
such, I'm considerign the option of placing functions that are only
used once into macros (without looking it up, I guess that would be
"inline" functions in C?) so that the overhead of a call isn't needed,
but the code can be read more easily.
> Then I would check with the Linux camp to see what their
>cpu detection is like.
I've had a look at some of the cpu detection codein Linux and *BSD.
It's nowhere near as complete as mine, so my code may be useful for
them once I've done more work tidying it up and changing the format.
>They, the Linux kernel camp might want the code once
>it is more mature. Another thing could it be migrated to C with minimal
>inline
>assembler ?
I'm sure it could. I'm seriously hoping it can, as that's what I
eventually intend to do with it. I plan on continuing to use nasm for
any modules I write in assembly, but that doesn't mean i can't inline
portions of assembly code where appropriate. The biggest problem with
that is that I ahve to learn the syntax for inline assembler for gcc,
as there is no other way I know to keep it portable across x86
systems.
>If you have not looked at it have a look at arch/i386/kernel/setup.c
>It would be a good idea instead of just spooling out data to the screen to
>produce a data structure with identification data, then to print that as a
>separate task to the screen :)
That is how I do it. Have you looked through the code to see how I set
it all up yet? I actually use a lot of arrays of pointers in various
places, and for the display data I ahve an array of pointers to the
relevant data that needs to be displayed for the various processors.
Then when displaying it, I scroll through the list grabbing each
pointer and the size of the respective string, and display that
string, and that all gets done in a single routine. If you're thinking
of a different way of doing that (especially if it would be as fast
and not much larger) then I'd be interested to know about it, as this
is the sort of routine that will be getting reused quite a lot.
>
>I do not know whether you have came across it but another source of CPU
>identification/detection source code is :-
>
> http://www.sysid.subnet.dk/
I hadn't come across that one. I'll be downloading it after I finish
my current download (a small ISO image - takes a while on a dial-up).
>
>Other thoughts, it might be worth compacting 8 bit ASCII into 6 bit for the
>space gain ?
I need to look into that sort of compression. I have thought about it,
but I haven't looked for any decent algorithms that may point me to
adecent, portable way of doing it yet. It may actually be an obvious
optimisation when I do start looking into it, but I'm not going to
assume that :) Also, it will meanhaving to write separate data files
and embed them after compressing the data, as I don't know of another
simple way to do that (especially if it's got to be fairly portable).
Of course, again, if you know a simple way of doing it that I haven't
considered, then I'd be grateful...
>Your String style maybe worth putting into a macro,
I had wondered about that. The only problem with that is that it would
be more difficult to keep reusing the same string where appropriate. I
may be going that way anyway at some stage, as it will make the code
more readable. OK, it will mean the data is duplicated in a few cases
(eg where stepping data is repeated, where a compatibility classis the
same as the processor model, etc), but that's not a major problem. It
would have the advantage that if a string needs to be altered, I don't
have to check if the same string is reused or not.
> string compation could
>possibly also be done as a macro, that way it could be transparent as to
>whether it is compacted or not.
That is an excellent idea, I hadn't thought of that at all. I'll have
to look into the capabilities of nasm's macro processor and seewhat it
could do in that area, as well as what I could do using gcc. Naturally
the compression would have to be done by the compiler or assembler,
but there has to be a way to do it (I assume that it's not an uncommon
thing, as a lot of executables which display text don't have readable
text strings embedded in them...).
>
>Better top level documenation may be a good idea. Macros are a bit odd
>and not very clear at all.
I'm not sure what you mean?
I hadn't actually thought about how odd the macros look, but now you
say it I suppose they are ) I wrote them for two reasons - they save
space throughout the file (some lines would wrap without them), and
they make it easier to write the code. ASs you say though, I ought to
give a better idea of what they do. I'll add comments there when I
update the code (not sure how soon that'll be, but it won't take as
long as it took me to update my FDC page after I originally uploaded
it)
>
>oh, and, there is a reference to a "cpuid.txt" file in the header that is
>not with the distribution.
Oops. I've now added that to the zip file, and I've also put a copy of
it online separately, accessible from the same page as the zipfile. It
needs a lot of tidying up, but does contain pretty much all the info
that I had access to while writing the code, and details of where I
got all my info. There are a couple of items missing (eg the code I
now use for detecting Nx586 processors without CPUID came from
information that was reverse engineered by Herbert Oppman, who I think
is possibly the expert on NexGen systems).
>
>(: I was thinking of a joint "operating system" project for
>alt.os.development
>which its only purpose is to identify and produce a report about the
>hardware it is run on. This might unite the crew :)
Well - you've seen the code, so you've seen the license. It can be
used for any purpsoe as long as I'm given credit for code I wrote :)
It's basically a BSD style license, so there are no real restrictions
other than a desire to be recognised for any work I put in.
>
>That must have been fun !!!
Yeah. The real fun is in testing as much as possible. I'm now using it
as a stand-alone loader, loaded by my boot sector, for testing a van
full of unknown systems I bought last week. So far 90% of them appear
to work, and it has correctly identified all of them (OK I've only
tested 10 of them, but I had already tested 50+ processors on 10+
motherboards). Gathering info is fun, but actually making use of it,
and then working my way through mistakes in some of the reference
sources, figuring out which sources are right when they conflict with
each other (even RBIL gets it wrong sometimes) and doing tests of my
own, all adds up to fun :)
Paul Hsieh
> It has been tested on the following range of processors:
>
> Various Intel and AMD 386 and 486 (SX, DX, DX2, DX4)
> Cx486DLC
> TI 486SXL2 (detected as SXL as I don't know the difference)
> Cx486DX
> Cx486DX2
> Cx486DX4
> Cx5x86
> AMD Am5x86
> Cx6x86
> Cx6x86L
> Cx6x86MX
> Cyrix MII
> Pentium
> AMD K5
> AMD K6
> AMD K6-2
> Winchip C6
What?!?! Where is *RISE* or *TRANSMETA*??? What about IBM's Blue
Lightning 486 clone?? Where is UMC or NexGEN?? And I thought both
UMC and Chips and Technology made x86 clones as well ... . Do you
detect a BOCHs or Virtual PC emulated processor? Your list has more
holes than swiss cheese!!! :) Just kidding.
Geez, everyone thought they were going to make an x86 clone at one
point -- now all that's left is AMD and the two stragglers (VIA and
Transmeta) who don't know when to quit. Oh yeah and Intel -- the big
bully everyone was trying to beat.
> You'll note that doesn't include the more modern processors. If you
> use this code and can confirm that it correctly identifies any later
> processors, I'd be grateful (having 100+ old systems doesn't help much
> when writing code for modern processors...).
On my 1.533Ghz Palomino based desktop Athlon CPU your program output:
Compatibility : Pentium
FPU type :
Identification method : CPUID
Vendor ID : AuthenticAMD
CPU Vendor : AMD
Processor ID : 0662
Processor type :
Family : K7
Model : Athlon Model 6
Stepping/Revision : A2
Core/Bus Clock Ratio :
Keep in mind that this CPU is actually compatible with the P-III. The
FPU is "built in" of course, and I don't know what you want for
"Processor type". The core is running 11.5 times the base BUS clock
speed, however in general you won't be able to fill that in on some
processors like the TransMeta CPU or Athlons with PowerNow! or Intel
processors with SpeedStep, as the multiplier will change depending on
the runtime conditions of the CPU.
--
Paul Hsieh
http://www.pobox.com/~qed/
Beth
> Hi all
>
> I know that some folk think it'sdaft to write code todetect older
> processors, or that it's reinventing the wheel, or whatever, but I
> ahve now completedmy ID code. It detects a wider range of processors
> than I avhe sen on any site or any code example i avhe found
elsewhere
> (it has been successfully tested on a wide range of 32-bit x86
> processors, and has correctly detected 40 or more models from 386 to
> Socket 7).
Debs, slow down! Your fingers are running AWOL all over the keyboard
there...hehehe ;)
Beth :)
Aaron Gray
> there...hehehe ;)
It is not debs, it is modern keyboards, see the thread 'modern.v.vold
keyboards'
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=af1rdi%
24893%241%40newsg4.svr.pol.co.uk
Aaron
Mark
screen, i suppose this is due to the ntvdm thingy not having none of them
detection routiens :)
--
Mark
If I aint got nuttin nice to say, i'll just say it anyway.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.371 / Virus Database: 206 - Release Date: 13/06/2002
ByrdKernel
> ON my Intel celeron 1ghz @ 1.55ghz (snip, wheeze)
I think my heart just seized...I was trying to overclock it to 3000bpm with a
liquid cooling system. :)
ByrdKernel (Mike)
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
ByrdKernel
ByrdKernel
ByrdKernel (Mike)
ByrdKernel wrote:
> Mark wrote:
>
> > ON my Intel celeron 1ghz @ 1.55ghz (snip, wheeze)
(snip, blah)
Debs
On 5 Jul 2002 00:45:54 -0700, Paul Hsieh spake thus:
>Debs <de...@spamfree.net> wrote:
>> It has been tested on the following range of processors:
>>
>What?!?! Where is *RISE* or *TRANSMETA*??? What about IBM's Blue
>Lightning 486 clone?? Where is UMC or NexGEN?? And I thought both
>UMC and Chips and Technology made x86 clones as well ... . Do you
>detect a BOCHs or Virtual PC emulated processor? Your list has more
>holes than swiss cheese!!! :) Just kidding.
LOL.
Well... some of those will be getting tested, some are just too
expensive for a pauper like me to get my hands on for now (of course,
I'll accept any donations of any hardware I don't have, new or
old...).
Actually half the reason for being as thorough as I have been is
boredom - doing things in that much detail helps me forget that I'm
housebound (I'm too busy to worry about what's going on outside :)
>
>Geez, everyone thought they were going to make an x86 clone at one
>point -- now all that's left is AMD and the two stragglers (VIA and
>Transmeta) who don't know when to quit. Oh yeah and Intel -- the big
>bully everyone was trying to beat.
I think National are still making the GX series of processors as well
(at least, the GX2 documentation has only recently appeared on their
web site, and that is an x86 compatible single-chip solution). I've
also yet to find anywhere that sells a system with a Transmeta
processor in it (and have also not seen anywhere here in the UK that I
could get a motherboard with Tm processor).
>
>On my 1.533Ghz Palomino based desktop Athlon CPU your program output:
>
Thanks. I'll update the compatability for the Athlon to P6, I'm not
sure with a lot of the Pentium class and later processors just what
the compatibility would be considered to be. Actually I ahdn't gopt
any of the post-Pentium processors (including P6) down as anything
other than Pentium compatible, as I've not been sure just whatthe
different processors are considered to be. I guess it should be aeasy
enough to change the P6 processors to be P6 compatible <G>, but for
the AMD is the Athlon the first to be considered P6, or would that be
the K6 or K6-2? Additionally, would the Pentium 4 be classed as P6 or
should P-IV be put down as a new compatability class?
FPU type isn't filled in yet as I ahven't done any work on FPU
detection for earlier processors (I know I could still put when a
processor has a built-in FPU, I just decided to leave everything to do
with FPU until I had added the 387 detection tests).
Processor type will be filled in once I start looking for overdrive
and dual-processor systems (the structure is basically a common
structure used for all processors at the moment, but that will change
as the code evolves).
For the core/bus ratio, I haven't looked into how to detect that on
most processors, so it's currently only filled in for things like
Cyrix CPUs (where the DIR values give that info). I need to look it up
sometime though, as I'm sure at some stage that doing so will help
with setting up an optimal system. The odds are that when I update the
display code, I'll be looking for NULL fields and actually leaving
that line out (that will probably be easier when I translate the code
to have as much done in C as possible).
>however in general you won't be able to fill that in on some
>processors like the TransMeta CPU or Athlons with PowerNow! or Intel
>processors with SpeedStep, as the multiplier will change depending on
>the runtime conditions of the CPU.
I need to try and figure out how to detect (and use, when appropriate)
the power saving features. It's not a high priority yet, but it would
be useful when my OS reaches a stage where power management is sueful
(ie when I have a kernel and enough other code to have it running for
any period of time - I don't think that's going to be soon though).
I think most of these points are arguements in favour of my
translating the code to C. I guess one of my next tasks should be
writing my standard library (especially the kernel library, as this
code will be used before the kernel is loaded, and so could use some
of the base kernel code...).
Debs
On Fri, 5 Jul 2002 13:10:56 +0100, Beth spake thus:
>Debs wrote:
>>
>> I know that some folk think it'sdaft to write code todetect older
>> processors, or that it's reinventing the wheel, or whatever, but I
>> ahve now completedmy ID code. It detects a wider range of processors
>> than I avhe sen on any site or any code example i avhe found
>
>Debs, slow down! Your fingers are running AWOL all over the keyboard
>there...hehehe ;)
hehehe. That's these damn sticky keyboards. They keep rearranging the
spellings and order of whatever I write...
ByrdKernel
> >Debs, slow down! Your fingers are running AWOL all over the keyboard
> >there...hehehe ;)
>
> hehehe. That's these damn sticky keyboards. They keep rearranging the
> spellings and order of whatever I write...
Yeah, you used that story on me, too. *to the audience* I know the real
story...*looks around furtively*...the keyboard e-mailed me. It told me what she
does to it when she's offline and it can't scream for help. *shudder* :)
hehehe
ByrdKernel (Mike)
Brent Ritchie
On my P3 Katmai 500, the test reports as follows:
Compatability :Pentium
FPU type :
Identification Method :
Vendor ID :Genuine Intel
CPU Vendor :Intel
Processor ID :0672
Processor Type :
Family :P6
Model :Pentium 3
Stepping Revision :B0
Core/Bus Clock Ratio :
Everything seems to be correct, hope this helps.
"Debs" <de...@spamfree.net> wrote in message
news:u0h9iugdnkmrh4v42...@4ax.com...
Piotr Wyderski
Very nice sources, it works on my machine too. But Debbie, just
a question: if it is supposed to be a part of your OS, why do you
need to distinguish the 16-bit CPU-s _so_ accurately? :-) I mean
that 86/88 code, etc. I'm curious, because my code needs to
know that the CPU is 386 or 486, but not SX, SLC, whatever. :-)
Best regards
Piotr Wyderski
Mark
Aaron Gray
Athlon XP 1700+ 1.46Ghz
---------------------------
Compatibility : Pentium
FPU type :
Identification method : CPUID
Vendor ID : AuthenticAMD
CPU Vendor : AMD
Processor ID : 0662
Processor type :
Family : K7
Model : Athlon Model 6
Stepping/Revision : A2
Core/Bus Clock Ratio :
AMD K6-2 500Mhz
----------------------
Compatibility : Pentium
FPU type :
Identification method : CPUID
Vendor ID : AuthenticAMD
CPU Vendor : AMD
Processor ID : 058C
Processor type :
Family : K6
Model : K6-2
Stepping/Revision : C rev.A
Core/Bus Clock Ratio :
Am5x86-P75-S 133Mhz
--------------------------
Compatibility : 486
FPU type :
Identification method : CPUID
Vendor ID : AuthenticAMD
CPU Vendor : AMD
Processor ID : 04F4
Processor type :
Family :
Model : 5x86 (WB Mode)
Stepping/Revision : A
Core/Bus Clock Ratio :
The program is terminal, right, you should either sort that out, or add an
obvious comment :(
Yay
Aaron
Andreas Kaestner
> <http://debs.future.easyspace.com/Programming/OS/index.html>
> Any comments will be welcome...
http://debs.future.easyspace.com/Programming/OS/cpuid.txt
Change "Enahnced" to "Enhanced". :-)
--
Gruß, | Bitte in der NG antworten | German MVPs:
Regards, Andreas | Please reply to the NG | http://www.ms-mvp.de
==================+=============================+=====================72
OE-QuoteFix 1.15.3 + OE ISO-8859-15 upgrade: http://jump.to/oe-quotefix
Maxim S. Shatskih
Any real computers made on them?
> UMC and Chips and Technology made x86 clones as well ... .
Buggy 486 clones, unable to run Windows 95.
Max
Beth
Yes, you're absolutely right because that's been my experience
too...the older keyboards don't cause me half as many problems and the
new stuff (see the other post in this group somewhere about how I
destroyed a crappy Microsoft keyboard within a week because it was so
poorly put together :)...
I was just joking around with Debs, is all...because that paragraph
had loads of typos...the rest of the post, if you look, was just fine
:)...
Beth :)
Beth
> Beth spake thus:
> >Debs wrote:
> >> I know that some folk think it'sdaft to write code todetect older
> >> processors, or that it's reinventing the wheel, or whatever, but
I
> >> ahve now completedmy ID code. It detects a wider range of
processors
> >> than I avhe sen on any site or any code example i avhe found
> >
> >Debs, slow down! Your fingers are running AWOL all over the
keyboard
> >there...hehehe ;)
>
> hehehe. That's these damn sticky keyboards. They keep rearranging
the
> spellings and order of whatever I write...
:)
Beth :)
Beth
> > What?!?! Where is *RISE* or *TRANSMETA*???
>
> Any real computers made on them?
No; But there were plenty of "fictious" computers that used
them...apparently...such as the "Fishcake 2000" computer, as made up
by me as I wrote this sentence...it used both a rise chip and a
transmeta chip, just to make the sarcastic point more
strongly...hehehe :)
> > UMC and Chips and Technology made x86 clones as well ... .
>
> Buggy 486 clones, unable to run Windows 95.
Oh...of course..._that's_ what you're using to define "real"...should
have guessed, Maxim, that the supposed measure of a "real" computer
has to be based on its capacity to run Windows 95...
I just like this concept of a "real" computer because if we define
that some computers are "real", what does this make all the other
computers? "Fictious"? "Ethereal"? "Figments of an over-active
imagination"?
Geez louise...
Beth :)
Maxim S. Shatskih
"real"...should
> have guessed, Maxim, that the supposed measure of a "real" computer
> has to be based on its capacity to run Windows 95...
Any really compatible x86 can run Windows 95. If some cannot, then the
CPU is buggy.
Max
Ralf A. Quint
<BethS...@hotmail.NOSPICEDHAM.com> wrote:
>Maxim S. Shatskih wrote:
>> > What?!?! Where is *RISE* or *TRANSMETA*???
>>
>> Any real computers made on them?
>
>No; But there were plenty of "fictious" computers that used
>them...apparently...such as the "Fishcake 2000" computer, as made up
>by me as I wrote this sentence...it used both a rise chip and a
>transmeta chip, just to make the sarcastic point more
>strongly...hehehe :)
>
Actually, there are PC's build with them. At least the Transmeta chip
is used in two laptop models i recently saw at an Expo (Sony was one
of them?), but i think the chip is mainly used in embedded stuff and
set-top boxes, rather than Joe Average's desktop computer (low power
consumption was one of the design goals of the Crusoe chip...)
Ralf
Debs
On Fri, 5 Jul 2002 19:04:19 +0100, Mark spake thus:
>ON my Intel celeron 1ghz @ 1.55ghz under 2k, it comes up with a blank
>screen, i suppose this is due to the ntvdm thingy not having none of them
>detection routiens :)
It's written to run under real mode, so needs to be run either with no
OS installed or under plain DOS. I wrote it as part of my OS
initialisation code,so haven't needed to get it running v86 (ie in a
Win2K DOS box or under Linux etc).
I don't know yet if it runs under bochs, as I have only just
downloaded bochs...
I'm currently working on rewriting it under C, and will be looking at
possibly running it in v86 mode, but as some of the code is priveleged
it may not be possible.
Debs
On Fri, 05 Jul 2002 21:03:46 GMT, Brent Ritchie spake thus:
>Hello,
> On my P3 Katmai 500, the test reports as follows:
>Compatability :Pentium
>FPU type :
>Identification Method :
>Vendor ID :Genuine Intel
>CPU Vendor :Intel
>Processor ID :0672
>Processor Type :
>Family :P6
>Model :Pentium 3
>Stepping Revision :B0
>Core/Bus Clock Ratio :
>
>Everything seems to be correct, hope this helps.
Thanks
Debs
On Fri, 5 Jul 2002 23:41:24 +0200, Piotr Wyderski spake thus:
It doesn't look at the 16-bit only processors. All the 386 and later
support 32-bit (apart from a few buggy 386's, of course), and the aim
is to be able to detect the buggy 386's(so that I don't try running
32-bit code on them). For things like SX, SLC etc, it will make a
difference to the processor initialisation.
Debs
On Fri, 5 Jul 2002 23:03:34 +0100, Aaron Gray spake thus:
>The program is terminal, right, you should either sort that out, or add an
>obvious comment :(
>
Thanks for the comments. I'll write more in a couple of days, I've
just had a car full of visitors arrive...
Debs
On Fri, 5 Jul 2002 23:03:34 +0100, Aaron Gray spake thus:
>Results :-
>
Thanks. They all look OK to me (apart from the fact that I now have a
better idea what the compatibility class of some of the post-Pentium
processors should be, and as mentioned previously I haven't done any
of the FPU tests yet).
>
>The program is terminal, right, you should either sort that out, or add an
>obvious comment :(
I'm not sure what you mean? The comments at the top of the source file
do say that it is a 16-bit real mode app that is designed to run with
no OS installed,so if that's whatyou mean thenit is stated.I guess it
might be good to add a small description file or something that
mentions that though, assomeone may wantto try it out that doesn't
automatically lookat the source code...
If you mean that the program doesn't exit neatly, then that's
something that will be sorted by the new version when I have finished
rewriting most of it in C (using asm it's impossible to have exit code
that will work on all operating systems). I've only just started on
the C version of it,and am still working on what compiler and linker
to use for creating 16-bit code (bearing in mind that most of the code
I write will be 32-bit code, it's only this and a couple of smaller
modules that will have 16-bit code). It shouldn't be too major a task
porting it, but as I'm writing it as part of my OS init code I'm going
to have to start working on my standard library code at the same time
(at least, the kernel portion of the library, for display code), which
will slow things a little.
Currently, the rewrite is being organised into3 files - onefor the
entry point into the code, one for the remaining assembly code and one
for the C code (whch will be the bulk of it, and will most likely be
further split into modules).
Debs
On Sat, 6 Jul 2002 03:40:33 +0200, Andreas Kaestner spake thus:
>Debs <de...@spamfree.net> schrieb/wrote:
>
>> <http://debs.future.easyspace.com/Programming/OS/index.html>
>
>> Any comments will be welcome...
>
>http://debs.future.easyspace.com/Programming/OS/cpuid.txt
>
>Change "Enahnced" to "Enhanced". :-)
Thanks. I've done that on my local copy now, and will have the
corrected copy uploaded later. I'll be surprised if that's the only
typo in there, watt with this darn keybroad rewiring evrything I
rite...
Aaron Gray
an
> >obvious comment :(
>
> I'm not sure what you mean? The comments at the top of the source file
> do say that it is a 16-bit real mode app that is designed to run with
> no OS installed,so if that's whatyou mean thenit is stated.I guess it
> might be good to add a small description file or something that
> mentions that though, assomeone may wantto try it out that doesn't
> automatically lookat the source code...
Sorry, I dumb I did not read that..
> If you mean that the program doesn't exit neatly, then that's
> something that will be sorted by the new version when I have finished
> rewriting most of it in C (using asm it's impossible to have exit code
> that will work on all operating systems).
Right
> I've only just started on
> the C version of it,and am still working on what compiler and linker
> to use for creating 16-bit code (bearing in mind that most of the code
> I write will be 32-bit code, it's only this and a couple of smaller
> modules that will have 16-bit code). It shouldn't be too major a task
> porting it, but as I'm writing it as part of my OS init code I'm going
> to have to start working on my standard library code at the same time
> (at least, the kernel portion of the library, for display code), which
> will slow things a little.
>
An old Borland compilers the old thing I can think of, I think they have put
their old stuff in their "museum".
> Currently, the rewrite is being organised into3 files - onefor the
> entry point into the code, one for the remaining assembly code and one
> for the C code (whch will be the bulk of it, and will most likely be
> further split into modules).
I tend to not like files that are too long, or contain too many (possibly
mixed) "sub" modules. If I were to tackel the job I would probably have a
separate file for each vendor (possibly assembly as wel as C), and the have
the generic stuff as the main backbone. That way you do not have to look at
anything that does not concern you actual task, wading through pages of
stangley names :)(
>
Have you had a chance to look at the other cpuid source code ?
Aaron
Daniel Camp
> Debs <de...@spamfree.net> schrieb/wrote:
> > > <http://debs.future.easyspace.com/Programming/OS/index.html>
>
> > Any comments will be welcome...
>
> http://debs.future.easyspace.com/Programming/OS/cpuid.txt
>
> Change "Enahnced" to "Enhanced". :-)
And, of cource (sic), "cource" to "source" :)
<G,D&R>
end
Campster, the chinese whisperer
daniel <Motty> camp <CatSatOnTheMat> btopenworld <Motty> com
---
Outgoing mail is certified Virus Free.
But Xpyd^WDR_Buddha isn't, he'll steal
your noodles, and eat them!
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.372 / Virus Database: 207 - Release Date: 20/06/02
Beth
> And, of cource (sic), "cource" to "source" :)
hehehe...mind you, I keep making that sort of typo all the time...I
usually make a folder called "source" to separate out my source code
from the run-time files (I like to keep files tidy on the disk...I'm a
touch obsessive about that, I'm afraid ;) and I always keep typing
"course" instead (Mrs. Malaprop would be proud ;)...and being a
legitimate word itself, it doesn't always register in my mind that
I've messed it up until I get error messages about "file not found"
and stuff :)...
Beth :)
Beth
Oh, yes...you're quite right...I was only sniping at this being used
as the measure of a "real" computer...if it can't run Windows 95 then
it's not fully x86-compatible, true, but that doesn't make it
"non-real" or "fictious" or anything...it just makes it a "real" buggy
CPU compatibility-wise...
In other words, a lack of compatibility with Windows 95 is a
compatibility problem...not an existentialist metaphysical
problem...if you said "correct" or "compatible" or something rather
than "real", there's no problems at all...but "real" has semantics
regards its existence or right to existence which don't
apply...there's the same problem with people saying "real" assembly
too...for example, HLA is "real" but it exists and you can go and
download it and it works...this is an entirely different matter to
whether you think it's "proper" or "standard" or "good" or anything
else :)...
Anyway, Maxim, don't take it too seriously...I was only making a joke
about it...I did know what you meant but, as you probably might have
noticed, I like making "word play" and silly pointless jokes :)...
Beth :)
Aaron Gray
Enough of this frivalry, be serious now :)
Matthias Paul
> My apologies. My news client seems to have gone insane for a
second.
BTW, some clients support cancelling of already sent articles, in
case you accidently hit the Send buttom. It doesn't always work, but
it is worth a try.
Greetings,
Matthias
Paul Hsieh
Are you aware of the "LOOP" bug in Win 95 that caused K6-2 at 350Mhz
and above to crash when loading some standard ethernet drivers (some
hard coded delay loop that did leave enough time once the CPU got fast
enough)? So technically, Win 95 didn't run on K6-2's after a certain
Mhz (a patch was eventually release by MS.) So are you saying that
K6-2's (specifically ones that run faster than 350Mhz) are buggy?
And unless Intel is willing to continue to let that LOOP instruction
in their CPU run at same speed as their i486@33Mhz, their CPUs will
eventually hit this bug too.
Paul Hsieh
> I think National are still making the GX series of processors as well
> (at least, the GX2 documentation has only recently appeared on their
> web site, and that is an x86 compatible single-chip solution).
Well, by that measure, technically Rise is still selling its x86's too
(see: www.rise.com) There is no active development though, so in the
long run they are dead.
> [...] I've also yet to find anywhere that sells a system with a Transmeta
> processor in it (and have also not seen anywhere here in the UK that I
> could get a motherboard with Tm processor).
Right ... I thought they were still trying to figure out which VLIW
core they wanted to use.
> >On my 1.533Ghz Palomino based desktop Athlon CPU your program output:
>
> Thanks. I'll update the compatability for the Athlon to P6, I'm not
> sure with a lot of the Pentium class and later processors just what
> the compatibility would be considered to be.
Well, you can go by the major generational type in general between AMD
and Intel. (I think Cyrix has been prone to exaggerate, so you have
to do further testing for those CPUs.)
> [...] Actually I hadn't gopt
> any of the post-Pentium processors (including P6) down as anything
> other than Pentium compatible, as I've not been sure just whatthe
> different processors are considered to be. I guess it should be aeasy
> enough to change the P6 processors to be P6 compatible <G>, but for
> the AMD is the Athlon the first to be considered P6, or would that be
> the K6 or K6-2?
This is what I know about AMD processors:
- I think K5 bills itself as a 5th generation, but does not have
complete P5 compatibility. (MSRs missing, possibly some instructions
missing.) I don't remember whether or not this CPU supports CPUID.
- K6 is a P55 clone (includes MMX) in that it implemented all
publically known and "discovered" MSRs (from Chris Ludlhoff's 4P
package and other sources.) Everything from this point forward
includes CPUID.
- The first Athlons (K7, K75, Thunderbird) were P-II clones (includes
all P6 instructions, MMX, PAE, and all known P6 MSRs including MTRRs,
and Syscall)
- The Athlon XP and Athlon MPs are P-III clones (includes SSE
instructions.)
- All public indications are that the Hammer's will be P4 clones
(includes SSE-2 instructions.)
> [...] Additionally, would the Pentium 4 be classed as P6 or
> should P-IV be put down as a new compatability class?
Pentium 4 is a "P7". Intel has never publically designated it that
way though (except in their compiler switches.)
> >however in general you won't be able to fill that in on some
> >processors like the TransMeta CPU or Athlons with PowerNow! or Intel
> >processors with SpeedStep, as the multiplier will change depending on
> >the runtime conditions of the CPU.
>
> I need to try and figure out how to detect (and use, when appropriate)
> the power saving features. It's not a high priority yet, but it would
> be useful when my OS reaches a stage where power management is sueful
> (ie when I have a kernel and enough other code to have it running for
> any period of time - I don't think that's going to be soon though).
The problem is that AMD, Intel and Transmeta did three different
things to implement clock multiplier power control. So good luck.
--
Paul Hsieh
http://www.pobox.com/~qed/
Maxim S. Shatskih
> instructions.)
And what is Opteron? Is it simplified Hammer or no?
Max
Maxim S. Shatskih
the
> > CPU is buggy.
>
> Are you aware of the "LOOP" bug in Win 95 that caused K6-2 at 350Mhz
> and above to crash when loading some standard ethernet drivers (some
> hard coded delay loop that did leave enough time once the CPU got
fast
> enough)?
UMC CPUs were not "fast enough". They were El Cheapo 486 clones, and
Win95 installed on them were spitting GP faults too often to be
operable.
Looks like they had bugs in protected mode stuff implementation.
Max
Marven Lee
Maxim S. Shatskih wrote...
> > - The Athlon XP and Athlon MPs are P-III clones (includes SSE
> > instructions.)
>
> And what is Opteron? Is it simplified Hammer or no?
I think it is the multiprocessor version of the Hammer.
I read that the uniprocessor version will use the Athlon name.
AMD have also applied for trademarks including
Opteron, Metaron, Multeon and others.
They sound like the names of the Autobot and Decepticon
leaders from the Transformers.
Transformers being toys from the 80s that you could
transform from a robot to either a car, airplane, gun,
cassette-recorder or dinosaur depending on the model.
Also had a cartoon series and a comic book, the plot
was different in each.
Marv
Beth
> Maxim S. Shatskih wrote...
> > > - The Athlon XP and Athlon MPs are P-III clones (includes SSE
> > > instructions.)
> >
> > And what is Opteron? Is it simplified Hammer or no?
>
> I think it is the multiprocessor version of the Hammer.
> I read that the uniprocessor version will use the Athlon name.
>
> AMD have also applied for trademarks including
> Opteron, Metaron, Multeon and others.
>
> They sound like the names of the Autobot and Decepticon
> leaders from the Transformers.
hehehe..."Transformers! Robots in disguise!" :)
Yes, what is it with these bizarre names? Intel's insistance on
"Pentium" was bad enough but at least it was once based on the idea of
just turning "586" into something more friendly for your average
person in the street...as "serial codes" tend to just get forgotten
when people aren't technology-obsessed or a programmer or
whatever...the idea, though, started to fall apart, I think, when it
dawned on them that "Sextium" (followed by the problem of whether to
use "Heptium" or "Septium", as seven can be either :) would probably
get miscontrued as a sex toy or something...and their marketing
department probably stressing highly that, with product names, you
don't just change things at a drop of a hat because you can build a
reputation and recongition around a name...so, they went with "Pentium
II/III/IV" instead (ironically, starting up future naming problems
with all that roman numeral crap instead..."Pentium IIX" or "Pentium
XXIV" will end up just confusing people which is which and they'll
have to come up with some other name to replace it again ;)...
Mind you, have you seen how desparate car names are getting? They
started off with okay and clever things like names of animals or those
fancy musical terms or whatever...but now, you can visibly see them
scraping the bottom of the barrel for any sort of distinctive name
that hasn't been used previously...
I can't wait to hear the next batch of names they invent...here's some
suggestions for them: "the AMD Klaxonerator Prime" (which "transforms"
into a Bacon Sandwich :), "the Ford Protracter" or "the Ford Pencil
Sharpener" (Why not? Base a range of names around items found in a
pencil case...it seems a desparate enough idea for them to try it out,
I think :), "the Citroen CX4793PZiii6"...what do you reckon? hehehe :)
I prefer the style astronomy uses...name the planets after ancient
gods (Luckily, the idea to call one of them "Herschel" after its
discoverer was thrown out or it would have totally spoilt the pattern
they were making...although, yes, they've mixed up Greek with Roman
gods but they can get away with it because most people can't tell the
difference...hehehe :), name the moons of Uranus after Shakespearian
characters...that sort of thing...I mean, there's absolutely hundreds
of names they have to come up with and almost all of them sound
fantastical and awe-inspiring: "Titania", "Prometheus", "Phobos",
"Deimos", "Ganymede", "Andromeda", "Orion", etc., etc....AMD and the
car manufacturers ought to borrow a few astronomers to come up with
their product names, as they seem quite good at coming up with clever
stuff...or, of course, they can note that, technically, these names
are public domain and there's plenty of them to go around, if you
catch my drift...I mean, doesn't "AMD Andromeda" or "Intel Prometheus"
sound a whole lot better than the usual crap they come up with ;)...
Beth :)
Paul Hsieh
> > - The Athlon XP and Athlon MPs are P-III clones (includes SSE
> > instructions.)
>
> And what is Opteron? Is it simplified Hammer or no?
"Opteron" is the current marketing name for a line of processors
currently code named "Hammer". AMD has publically stated that they will
be moving to the hammer core in all future micro processor lines, and
that at least one line of them will be called "Opteron".
Remember that AMD currently has Duron, Athlon XP, and Athlon MP product
lines. From a productization point of view, I would guess that "Opteron"
will replace the current "XP" line, and that they might go with something
like "Athlon 64" to replace their "Duron" line, and will go with
something else for their "MP" line (all using the same core -- the MP
version would have multiprocessor enabled and might have a larger on chip
L2 cache, and the low end version might have a smaller L2 cache.) But
that's just a guess.
I don't know what a "simplified Hammer" is. Hammer looks to be a very
sophisticated processor from a certain point of view (how it works
under the hood, and what its capable of), while very simple from another
(the programming requirements.)
Paul Hsieh
So your acid test for whether or not an x86 CPU is buggy is if it can run
Windows? Who cares about UMC, Intel litigated them to death before they
ever became a serious contender. If you read through Deb's text file you
will realize that Intel's 486 CPU was actually quite a troubled little
piece of silicon (bunch of Integer<->FPU synchronization issues, and a
bunch just plain broken instruction behaviors) -- yet it seems to have
been able to run Win 95 just fine.
Are you aware that Windoze has code in it that incorrectly detects for
the presence of the CMPXHG8 instruction and goes ahead and uses it based
on this incorrect determination? WinChip and Cyrix CPUs had to be respun
to lie about their support for this instruction to get Windows to work
correctly (thus making the data reported by the CPUID instruction not
100% reliable (attention Debs, take note of this).) AMD avoids the issue
by always reporting their CPUs and being compatible with a previous
generation Intel CPU (which technically they are) and having very very
close feature implementations to Intel (i.e, K6 advertises only P5-MMX
compatibility (Cyrix and WinChip tried to advertise a P-II compatible
with their MX6x86 and C6 processors), and the Athlon implements CMPXHG8
while reporting P-II compatibility).
CMPXHG8 is essentially a 64bit test and set instruction for use in
multiprocessor environments. Kind of useful for OSes -- you'd think they
would want to get this right.
Whether or not Windows runs correctly on a given CPU is not what I would
use to verify the correctness of a CPU.
Bo Persson
"Paul Hsieh" <q...@pobox.com> wrote
news:MPG.17958c526...@news.sf.sbcglobal.net...
[...]
>
> Are you aware that Windoze has code in it that incorrectly detects for
> the presence of the CMPXHG8 instruction and goes ahead and uses it based
> on this incorrect determination? WinChip and Cyrix CPUs had to be respun
> to lie about their support for this instruction to get Windows to work
> correctly (thus making the data reported by the CPUID instruction not
> 100% reliable (attention Debs, take note of this).)
So they just follow the spec, and not the reference implementation? :-)
I once worked for a PC company producing an IBM AT compatible machine. Our
hardware guys added a 287 socket according to Intel's guidelines, even
having an Intel guy present to help them. IBM did not!
So it turned out that Lotus 1-2-3 worked on the IBM machine (surprise! :-)
but not on our. Guess who had to modify their hardware...
Another time I had a problem with a video board for IBM PS/2s. On one of the
models it didn't load my national character set correctly. The manufacturer
said:
"It's done according to the spec, there is a bug in the BIOS for the PS/2
model 50. Ask IBM for an upgrade"
Of course not, it was a bug in the spec! It could have said:
"..., except for the model 50 (which accidentally is coded differently)
where you have to do it this way..."
> AMD avoids the issue
> by always reporting their CPUs and being compatible with a previous
> generation Intel CPU (which technically they are) and having very very
> close feature implementations to Intel (i.e, K6 advertises only P5-MMX
> compatibility (Cyrix and WinChip tried to advertise a P-II compatible
> with their MX6x86 and C6 processors), and the Athlon implements CMPXHG8
> while reporting P-II compatibility).
A sound decision!
> CMPXHG8 is essentially a 64bit test and set instruction for use in
> multiprocessor environments. Kind of useful for OSes -- you'd think they
> would want to get this right.
It works with Intel and AMD processors. So it *is* rights! :-)
> Whether or not Windows runs correctly on a given CPU is not what I would
> use to verify the correctness of a CPU.
It should be part of the package. A processor that does *not* run Windows
isn't going to be used much in PCs! :-)
It's not a question of being right or wrong, it's a question of reading the
map. Does it really match the reality?
Bo Persson
bo...@telia.com
Maxim S. Shatskih
My idea was that Opteron is to Hammer as Celeron is to Pentium. Looks
like I was wrong.
Max
Maxim S. Shatskih
for
> the presence of the CMPXHG8 instruction and goes ahead and uses it
based
> on this incorrect determination?
A CPU's problem and not NT's. if CPU claims CMPXCHG8 feature bit in
CPUID features (and this is how NT determines the support for this
opcode), it must support the opcode correctly.
>WinChip and Cyrix CPUs had to be respun
> to lie about their support for this instruction to get Windows to
work
> correctly
Sorry, but WinChip and Cyrix and much, much worse can of bugs than any
Microsoft software.
NT can and must work fine on CPU which does not support this opcode.
(thus making the data reported by the CPUID instruction not
> 100% reliable (attention Debs, take note of this).) AMD avoids the
issue
> by always reporting their CPUs and being compatible with a previous
> generation Intel CPU (which technically they are)
IIRC NT has code specially written for AMD CPUs.
> Whether or not Windows runs correctly on a given CPU is not what I
would
> use to verify the correctness of a CPU.
Its is the x86 compatibility of the CPU. x86 CPU is the one which runs
Windows and all other OSes written for x86 - from DOS to Solaris/x86.
Max
ByrdKernel
> A CPU's problem and not NT's. if CPU claims CMPXCHG8 feature bit in
> CPUID features (and this is how NT determines the support for this
> opcode), it must support the opcode correctly.
100% agreement. The CPUID bit isn't there to please Windows...it's there to
indicate the presence a specific instruction. If it indicates that presence, but
doesn't support the instruction, then the company who designed it deserves to go
down in flames for producing such a stupid design. It's been documented in the
Intel manuals, which are freely available, all the way.
> IIRC NT has code specially written for AMD CPUs.
Really? I wasn't aware of that. :) Good to know not everybody panders
exclusively to Intel. (even if it's the evil empire we're talking about here)
Do you have an example of where/how? Is it a "CPU support module"? I'd love to
find out.
ByrdKernel (Mike)
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Maxim S. Shatskih
>
> Really? I wasn't aware of that. :) Good to know not everybody
panders
> exclusively to Intel. (even if it's the evil empire we're talking
about here)
> Do you have an example of where/how? Is it a "CPU support module"?
I'd love to
> find out.
From what I have heard from people who has the source, it is both in C
and assembler code in different Kixxx and Kii386xxx functions which
manage the CPU state itself (all these control registers not used in
usual program - even kmode - flow, but influencing the CPU behaviour).
Max
Daniel Camp
> I prefer the style astronomy uses...name the planets after ancient
> gods (Luckily, the idea to call one of them "Herschel" after its
> discoverer was thrown out or it would have totally spoilt the pattern
> they were making...although, yes, they've mixed up Greek with Roman
> gods but they can get away with it because most people can't tell the
> difference...hehehe :), name the moons of Uranus after Shakespearian
> characters...that sort of thing...I mean, there's absolutely hundreds
> of names they have to come up with and almost all of them sound
> fantastical and awe-inspiring: "Titania", "Prometheus", "Phobos",
> "Deimos", "Ganymede", "Andromeda", "Orion", etc.
I like that idea.... why did noone come up with Ford Orion before?
end
Campster, the chinese whisperer
daniel <Motty> camp <CatSatOnTheMat> btopenworld <Motty> com
---
Outgoing mail is certified Virus Free.
But Xpyd^WDR_Buddha isn't, he'll steal
your noodles, and eat them!
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/02
TS
>the presence of the CMPXHG8 instruction and goes ahead and uses it based
>on this incorrect determination? WinChip and Cyrix CPUs had to be respun
>to lie about their support for this instruction to get Windows to work
>correctly (thus making the data reported by the CPUID instruction not
>100% reliable
Sounds interesting. Is there a more detailed description of this
behaviour?
>AMD avoids the issue
>by always reporting their CPUs and being compatible with a previous
>generation Intel CPU (which technically they are) and having very very
>close feature implementations to Intel (i.e, K6 advertises only P5-MMX
>compatibility
Well, K6 lacks PPro/PII instructions like CMOVxx and FCMOVxx, like the
PentiumMMX.
>(Cyrix and WinChip tried to advertise a P-II compatible
>with their MX6x86 and C6 processors), and the Athlon implements CMPXHG8
>while reporting P-II compatibility).
CyrixMX do support the (F)CMOVxx instructions and some other
extensions.
Generally, the processor family number is just as relevant as the
vendor string of the CPUID instruction, and the availbility of certain
CPU features should only be determined using the cpuid flags according
to them. However, many programs do not even test the cpu family but
just try to execute the instruction and either handle the exception or
crash right away (mostly using CPUID or RDTSC without checking its
availability, it was quite annoying before I wrote the "CPUID on"
program back in the time I used an Cyrix6x86...).
Paul Hsieh
> > for the presence of the CMPXHG8 instruction and goes ahead and uses it
> > based on this incorrect determination?
>
> A CPU's problem and not NT's. if CPU claims CMPXCHG8 feature bit in
> CPUID features (and this is how NT determines the support for this
> opcode), it must support the opcode correctly.
No -- given their instruction and feature support, what Cyrix/WinChip
was supposed to do was report themselves as 6th generation (they
supported CMOV and other 6th generation instructions, and Cyrix
plugged into some VIA based P6/P-II motherboards as I recall) but just
switch the CMPXCHG8 flag off (they could never test this instruction
properly (and thus never implemented it) since they did not support
multiprocessor environments.)
In fact I believe at least Cyrix did ship some CPUs with this
spec-compliant CPUID output. When they did this, Windows NT failed
(at the time Win NT had very little marketshare) because Microsoft
just blindly assumed that "6th generation" meant support for CMPXCH8
(true for all Intel and AMD processors, not true for Cyrix or
WinChip.) Interesting, Intel was compounding the problem because the
CPU feature detection code that they were recommended detected all
clones as "486" chips (for a comparison take a look at AMD's CPU
feature detection sample code -- it detects SSE-2 even though AMD does
not yet ship a CPU which has such a feature.)
> >WinChip and Cyrix CPUs had to be respun
> > to lie about their support for this instruction to get Windows to work
> > correctly
>
> Sorry, but WinChip and Cyrix and much, much worse can of bugs than any
> Microsoft software.
You are so full of shit. There is no way in hell either of those
chips have anywhere near the number of bugs of the most stable
fragments of code inside of Microsoft.
CPUs, like any complex software, have potential for things like
"buffer overflows", "hangs" and just plain garbage results. The main
thing to notice about CPUs is that they generally do not "buffer
overflow" or "hang" (the dan0411 Intel bug, as well as some of their
marginal multiprocessor bugs are the only instances I am aware of) and
"garbage" is also pretty rare (P5 FDIV bug, the later masked FPU
exception problem, WinChip's slightly defective PFRCPT 3DNow!
instruction.) The one AMD problem that I recall was on their K6's
where you had multiple masters and you issued a particular "lock"
overriden instruction, you may hit a race condition on the actual
fetch and end up with an illegally ordered sequence of reads/writes.
CPU bugs are typically very hard to find/reproduce, because the kinds
of testing that goes on for CPUs is so exhaustive of all the lowest
hanging fruit. That is in fact one of the major expenses of building
an x86 CPU (the compatibility testing.)
I'll give you an example from my inside knowledge. Inside of one CPU
vendor there is a group of workstations that are running 24/7 on
groups of 3 "machines" at a time that performs the following: Throw
random (but biased in a way to improve coverage) instruction sequences
and compare the results between 1) the company's CPU, 2) the company's
(compatible) competitor CPU, 3) the simulation of the company's CPU.
Any discrepency between the results of any pair of these immediately
raises a red flag and senior designers are brought in to diagnose the
problem. Once stabilized this test would run for 4 months at a time
without finding anomolies.
All CPU vendors engage in similar levels of testing. They have to --
people, and OEMs that figure customer support calls into their
expenses, rely on them to be perfect.
Intel and AMD have publically disclosed their CPU bugs (thanks to the
PR fiasco re: Intel and the FDIV bug) and reading them gives you some
insight into the sheer quality of their testing. The scenarios in
which you have to put yourself into just to see these strange bugs
reveals what kind of strange corner cases they are looking at in their
testing. While Intel's disclosures actually contain some problems
where you wish they had done a better job (with the understanding that
even those bugs are marginal), AMD's disclosure are amazing -- you
have a hard time even understanding the scenario of bugs themselves,
let alone have any worry about how they would creep into your
software.
I crashed Window 2000 (hard) within the first 5 minutes of me touching
it (not *trying* to crash it -- I was just trying to run Netscape, and
a few other non-MS products on this system.) I have witness
confirmation of this. I had to reboot my Win 2K box yesterday because
the keyboard simply stopped responding (it had an uptime of about 3
months which is actually not bad.) Microsoft is releasing a never
ending stream of patches, and buffer overflows is a way of life for
the Microsoft programmer. My inside knowledge into Microsoft is that
they use standard QA engineers (who don't know how to create buffer
overflow conditions, or where to even look for them) for their
testing, and they have various degrees of bugs including "not
serious". Microsoft will ship product once the level of bugs is low
enough as opposed to zero bugs.
Microsoft will never ever release a product with the stability of a
Cyrix CPU or any other serious x86 CPU vendor.
> NT can and must work fine on CPU which does not support this opcode.
But it did not. That is the point of my story. Cyrix and Centaur did
not make the same design mistake -- they made the same strategic
mistake (assuming MS would write good software.)
> > (thus making the data reported by the CPUID instruction not
> > 100% reliable (attention Debs, take note of this).) AMD avoids the issue
> > by always reporting their CPUs and being compatible with a previous
> > generation Intel CPU (which technically they are)
>
> IIRC NT has code specially written for AMD CPUs.
Yes because AMD's K6 and Intel P6 generation CPUs used different
strategies for write combining though both have a similar very
desirable effect. This is not related to the CMPXCHG8 problem I am
referring to above. AMD's CPUs can and does run the Intel code path
on that issue no problem, since it doesn't cause the defective CPUID
check to pick the wrong path.
> > Whether or not Windows runs correctly on a given CPU is not what I would
> > use to verify the correctness of a CPU.
>
> Its is the x86 compatibility of the CPU. x86 CPU is the one which runs
> Windows and all other OSes written for x86 - from DOS to Solaris/x86.
So Intel 386s which don't run Windows 2000 are not x86's then? Are
Alpha's, which use FX!32 to run Windows, considered x86 CPUs? How
about people who use BOCHs or Plex86 or Virtual PC? This is not a
question for your MS indoctrinated political views. You have no idea
who you are speaking to when you try to tell me the definition of what
an x86 CPU is.
Running OS's is a high level product viability test, but 1) is not a
particularly difficult test and 2) cannot be relied upon to be
intrinsically bug free anyway.
Paul Hsieh
> >Are you aware that Windoze has code in it that incorrectly detects for
> >the presence of the CMPXHG8 instruction and goes ahead and uses it based
> >on this incorrect determination? WinChip and Cyrix CPUs had to be respun
> >to lie about their support for this instruction to get Windows to work
> >correctly (thus making the data reported by the CPUID instruction not
> >100% reliable
>
> Sounds interesting. Is there a more detailed description of this
> behaviour?
There was a description on Cyrix and Centaurs old CPU sites. But VIA
doesn't seem to be maintaining that info any more. In the end Cyrix
and Centaur said that they *did* support the CMPXCHG8 instruction even
though they did not, and both reported 6th generation compatibility --
combined with the "Is this an Intel CPU" logic in Microsoft's code,
this somehow got it to conclude that they did *NOT* support the
CMPXCHG8 instruction (which was true.) We could draw up a table and
try to reverse engineer what the MS logic might have looked like, but
I think the point is made.
> >AMD avoids the issue
> >by always reporting their CPUs and being compatible with a previous
> >generation Intel CPU (which technically they are) and having very very
> >close feature implementations to Intel (i.e, K6 advertises only P5-MMX
> >compatibility
>
> Well, K6 lacks PPro/PII instructions like CMOVxx and FCMOVxx, like the
> PentiumMMX.
Yes, so AMD is both correct and *safe*.
> >(Cyrix and WinChip tried to advertise a P-II compatible
> >with their MX6x86 and C6 processors), and the Athlon implements CMPXHG8
> >while reporting P-II compatibility).
>
> CyrixMX do support the (F)CMOVxx instructions and some other
> extensions.
Yes, so Cyrix was correct but *unsafe*. They "fixed" it so that they
became incorrect but *safe*.
> Generally, the processor family number is just as relevant as the
> vendor string of the CPUID instruction, and the availbility of certain
> CPU features should only be determined using the cpuid flags according
> to them.
Yeah, but who's going to tell this to Microsoft?
It also turns out that under Win 9X, Microsoft will sometimes emulate
the EFLAGs behavior (if there was some kind of page fault on the code
segment where the POPF instruction was executed or something like
that) and indicate that the CPU *DOES* support CPUID even if it
doesn't.
Its a rare and very difficult situation to reproduce -- but I suspect
that's why nobody with the knowledge to do so has ever tried to write
a totally 100% comprehensive CPU ID check, for *every* x86 CPU. Maybe
Debs will be the first to write such code (but it has to take stupid
things like this into account), who knows?
> [...] However, many programs do not even test the cpu family but
> just try to execute the instruction and either handle the exception or
> crash right away (mostly using CPUID or RDTSC without checking its
> availability, it was quite annoying before I wrote the "CPUID on"
> program back in the time I used an Cyrix6x86...).
This is actually the method Intel advocates for testing for the
presence of SSE and SSE-2. I have not looked too deeply into the
setup of these instructions, but if this is required I would suspect
that there is state for whether or not these instructions are
supported by the OS that is either only RING-0 accessible or which
will itself fault of accessed while disabled. Think of Windows
versions *before* the existence of SSE running on an SSE enabled
processor (and failing to save and restore SSE registers.) At least
there the faulting method will work on older versions of Windows as
well as later versions.
Maxim S. Shatskih
> just blindly assumed that "6th generation" meant support for CMPXCH8
No. There is a separate CPUID feature bit for CMPXCH8, not just the
common notion of "6th generation".
> > Sorry, but WinChip and Cyrix and much, much worse can of bugs than
any
> > Microsoft software.
>
> You are so full of shit. There is no way in hell either of those
> chips have anywhere near the number of bugs of the most stable
> fragments of code inside of Microsoft.
People do running MS's OSes, and run them fine. As about WinChip and
Cyrix - having them means asking for "adventures" to one's orifice.
:-) They were always considered to be as Mekosonic or Powasonic is to
Sony. El Cheapo worse quality clones.
> serious". Microsoft will ship product once the level of bugs is low
> enough as opposed to zero bugs.
Surely, as any business company will do. Reaching "zero bugs" level
will require enormous time to be spent on it, which is unacceptable
from business point of view.
Sun does the same with Solaris, BTW.
I suspect VMS is the same - it is just old and mature enough to have
bugs, it was not released bug-free.
> Microsoft will never ever release a product with the stability of a
> Cyrix CPU or any other serious x86 CPU vendor.
Cyrix and "serious" is oxymoron.
> But it did not. That is the point of my story. Cyrix and Centaur
did
> not make the same design mistake -- they made the same strategic
> mistake (assuming MS would write good software.)
No, the mistake was - to not clone Intel 100%. I suspect they
deliberately decided to "fix" some Intel issues which they considered
to be bad. Woe to them :-)
> So Intel 386s which don't run Windows 2000 are not x86's then?
They are old and obsolete x86.
> Are Alpha's, which use FX!32 to run Windows, considered x86 CPUs?
A correct emulation of x86.
> who you are speaking to when you try to tell me the definition of
what
> an x86 CPU is.
It is the CPU which can run all x86 binary code directly, without
emulation software, and without bugs. x86 CPU is the CPU works the
same way as Intel's. AMD reached this compatibility, while Cyrix or
WinChip did not.
Note that there is even an attitude against AMD - to have more
compatibility issues then Intel. Not so strong attitude, but it
exists.
Max
Maxim S. Shatskih
but
> I think the point is made.
MS logic is - to check the feature bit for CMPXCHG8B support. The
"generation" is irrelevant.
> Yes, so Cyrix was correct but *unsafe*. They "fixed" it so that
they
> became incorrect but *safe*.
Safe is correct. They were incorrect and unsafe, then did correct and
safe.
Max
Scott Wood
>No -- given their instruction and feature support, what Cyrix/WinChip
>was supposed to do was report themselves as 6th generation (they
>supported CMOV and other 6th generation instructions, and Cyrix
>plugged into some VIA based P6/P-II motherboards as I recall) but just
>switch the CMPXCHG8 flag off (they could never test this instruction
>properly (and thus never implemented it) since they did not support
>multiprocessor environments.)
If they don't support SMP, then all they need to be correct is the behavior
on a single processor (i.e. atomic with respect to interrupts). Why could
they not test this?
>CPUs, like any complex software, have potential for things like
>"buffer overflows", "hangs" and just plain garbage results. The main
>thing to notice about CPUs is that they generally do not "buffer
>overflow" or "hang" (the dan0411 Intel bug, as well as some of their
>marginal multiprocessor bugs are the only instances I am aware of) and
Surely you're thinking of the f00f bug; dan0411 was a minor FPU bug.
>> Its is the x86 compatibility of the CPU. x86 CPU is the one which runs
>> Windows and all other OSes written for x86 - from DOS to Solaris/x86.
>
>So Intel 386s which don't run Windows 2000 are not x86's then? Are
>Alpha's, which use FX!32 to run Windows, considered x86 CPUs?
FX!32 runs x86 Windows *apps* running under the *Alpha* version of NT.
-Scott
Paul Hsieh
> > just blindly assumed that "6th generation" meant support for CMPXCH8
>
> No. There is a separate CPUID feature bit for CMPXCH8, not just the
> common notion of "6th generation".
Correct. Do you have comprehension problems or something? Windows NT
3.X screwed this up. They had some mish mash of logic that had them
detecting non-Intel CPUs with CMPXCHG8 support iff they were 6th
generation CPUs. This is just a Microsoft bug. This screwed up Cyrix
and WinChip as far as the feature sets they chose to implement. So
they had to misreport the support for this instruction to match the
screwed up logic in Win NT 3.X. This of course leads to interesting
problems for other OS's which didn't use Microsoft's defective CPU
detection code.
Centaur and Cyrix didn't have some kind coincidental mistake in their
designs. They both ran into the same bug that was in Windows.
Suddenly I have a sense of Deja Vu ...
> > > Sorry, but WinChip and Cyrix and much, much worse can of bugs than any
> > > Microsoft software.
> >
> > You are so full of shit. There is no way in hell either of those
> > chips have anywhere near the number of bugs of the most stable
> > fragments of code inside of Microsoft.
>
> People do running MS's OSes, and run them fine. As about WinChip and
> Cyrix - having them means asking for "adventures" to one's orifice.
> :-) They were always considered to be as Mekosonic or Powasonic is to
> Sony. El Cheapo worse quality clones.
Dude just read this:
http://developers.slashdot.org/developers/02/07/10/2139207.shtml?tid=109
That's pathetic. They are wasting their time writing SCM tools, with
random degrees of expertise amongst their developers at various times.
CPUs are not designed in such "fly by night" hack jobs.
Why is it so easy for me to cite references and actual cases for my
claims, but you can't back up a single thing that you say?
> > serious". Microsoft will ship product once the level of bugs is low
> > enough as opposed to zero bugs.
>
> Surely, as any business company will do. Reaching "zero bugs" level
> will require enormous time to be spent on it, which is unacceptable
> from business point of view.
Serious CPUs typically ship with 0 known bugs. (Bugs are eventually
discovered over time while they are shipping.)
> Sun does the same with Solaris, BTW. I suspect VMS is the same - it is just
> old and mature enough to have bugs, it was not released bug-free.
I was not addressing other OSes. I am comparing CPU stability versus
software stability (specifically the poster child of unstable software
-- Microsoft software.)
> > Microsoft will never ever release a product with the stability of a
> > Cyrix CPU or any other serious x86 CPU vendor.
>
> Cyrix and "serious" is oxymoron.
Tell that to the OEMs that bought and sold them. Cyrix is not serious
today, because they got beaten in the market.
> > But it did not. That is the point of my story. Cyrix and Centaur did
> > not make the same design mistake -- they made the same strategic
> > mistake (assuming MS would write good software.)
>
> No, the mistake was - to not clone Intel 100%.
Nobody has ever cloned Intel 100%. Not even Intel has cloned Intel
100%.
> [...] I suspect they deliberately decided to "fix" some Intel issues which
> they considered to be bad. Woe to them :-)
If you don't even read what is written then why do you bother
responding? Cyrix wasn't trying to do anything other than to create a
P6 clone, but without some of the esoteric features/instructions like
CMPXCHG8. Look at the documentation for the CPUID instruction --
Cyrix was well within spec to do this. Their other "features", like
L1 cache line locking and some extra MMX instructions have, to my
knowledge, never had an issue (but that could be because they were
used in such isolation.)
> > So Intel 386s which don't run Windows 2000 are not x86's then?
>
> They are old and obsolete x86.
Then fix your logic. A CPU running any particular version of Windows
is not a reasonable test of whether or not that CPU is an x86.
> > who you are speaking to when you try to tell me the definition of what
> > an x86 CPU is.
>
> It is the CPU which can run all x86 binary code directly, without
> emulation software, and without bugs.
So you are saying that CPUs such as the Pentium 4 is not an x86 -- it
uses microcode (which is software) to emulate numerous instructions,
and has known documented architectural differences with all other
x86s, specifically in the FPU op count state. Intel has also
documented dozens of errata for the Pentium 4, indicating that there
is software that in theory would not run without bugs.
The Xeon probably had far more serious problems as there were some
protocol failures that could cause the system enter a race in MP
scenarios. These sorts of bugs disqualify it from being an x86?
And so no matter how accurately or how well a Transmeta executes x86
code, you are saying its not an x86 because it in fact emulates
*every* instruction it executes with software?
And are you saying the K6 is not an x86 because its LOOP instruction
ran too fast to let it execute a delay loop slowly enough? We're
talking about desktop CPUs here, not game consoles.
> [...] x86 CPU is the CPU works the same way as Intel's.
You are confusing x86 with IA32. If you search for documentation
about "x86s" on Intel's web site, you won't find anything. If you ask
them, I'm sure they will disavow any designation such as "x86".
Similarly the clone companies will not mention IA32 anywhere in their
documenation (but are confortable with the designation "x86") probably
because of copyright/trademark reasons.
So does AMD's inclusion of 3DNow! (which allows it to work differently
from Intel's CPUs) make it not an x86?
> [...] AMD reached this compatibility, while Cyrix or WinChip did not.
Well, Intel did not reach compatibility with itself either.
> Note that there is even an attitude against AMD - to have more
> compatibility issues then Intel. Not so strong attitude, but it
> exists.
Its pure paranoia. The Athlon's are pure clones, and probably closer
to P-II's and P-III's (K7X, Palomino respectively) than even the P4.
Nevertheless Microsoft continues to screw up their CPUID detection
code. See:
http://athlonxp.amd.com/benchmarks/overallComputing/digitalMPerformanceOverall.jsp
Notice how AMD is citing a special "modified" Media Player for
measuring their performance? Do you know what that is? Its another
Microsoft screw up detecting the SSE instructions. The Athlon XP has
support for the SSE instructions (the previous Athlons did not.)
Fortunately, AMD has enough clout these days that they could convince
Microsoft to create a patch for Media Player, rather than be forced to
do what Cyrix/Centaur did in their CPUs. (The disadvantage of AMD's
strategy is that many of these software bugs are incorrectly
attributed to the CPU.)
Paul Hsieh
> On 10 Jul 2002 19:49:48 -0700, Paul Hsieh <q...@pobox.com> wrote:
> >No -- given their instruction and feature support, what Cyrix/WinChip
> >was supposed to do was report themselves as 6th generation (they
> >supported CMOV and other 6th generation instructions, and Cyrix
> >plugged into some VIA based P6/P-II motherboards as I recall) but just
> >switch the CMPXCHG8 flag off (they could never test this instruction
> >properly (and thus never implemented it) since they did not support
> >multiprocessor environments.)
>
> If they don't support SMP, then all they need to be correct is the behavior
> on a single processor (i.e. atomic with respect to interrupts). Why could
> they not test this?
Well, they also have to get it right in the multiple master scenario
(a graphics card such as 3DLab's Permedia can master the system
memory.)
> >CPUs, like any complex software, have potential for things like
> >"buffer overflows", "hangs" and just plain garbage results. The main
> >thing to notice about CPUs is that they generally do not "buffer
> >overflow" or "hang" (the dan0411 Intel bug, as well as some of their
> >marginal multiprocessor bugs are the only instances I am aware of) and
>
> Surely you're thinking of the f00f bug; dan0411 was a minor FPU bug.
Yes, I misrembered them by name. The dan0411 is the masked exception
problem, while f00f was the opcode crash.
Beth
> Beth created an almost never ending sentence ...
> > I prefer the style astronomy uses...name the planets after ancient
> > gods (Luckily, the idea to call one of them "Herschel" after its
> > discoverer was thrown out or it would have totally spoilt the
pattern
> > they were making...although, yes, they've mixed up Greek with
Roman
> > gods but they can get away with it because most people can't tell
the
> > difference...hehehe :), name the moons of Uranus after
Shakespearian
> > characters...that sort of thing...I mean, there's absolutely
hundreds
> > of names they have to come up with and almost all of them sound
> > fantastical and awe-inspiring: "Titania", "Prometheus", "Phobos",
> > "Deimos", "Ganymede", "Andromeda", "Orion", etc.
>
> I like that idea.... why did noone come up with Ford Orion before?
hehehe...oh yeah...oops! :)
But, anyway, that goes to prove my point, I think...because that's one
of the best memorable names that they've come up with (not memorable
to me just then but then, I confess, I'm no great car
expert...although, when you reminded me, it was a case of "oh yeah!"
realisation and only one of the long-running memorable names would
have that effect because I really am a dunce when it comes to
cars...where most people say "look at my Ford Escort v6.345iii
fuel-injected turbo-boosted time machine" or whatever, I say "that
biggish blue car parked on the left"...I only know any model names
because of all the adverts and how everyone else keeps saying them all
the time (usally expecting me to know what car they mean but I
don't..."which car is yours?"..."oh, my car's the Ford
Escort"..."Cool! So...ummm...which one's the Ford Escort? That red one
by there?" ;))...
Beth :)
Beth
Well, that's starting to cement this "can't run Windows 95" acid test
as being a touch ill-conceived...this only goes to back up what I was
saying...which was simply that if I had a 2.4GHz Pentium-4 clone that
had issues with Windows 95, it would be annoying, perhaps, but it
doesn't mean that it's totally useless...
Or, in short, the "Designed for Windows 95" badge isn't a designation
of infallible godhood or anything...in fact, if anything, it's more
likely to mean "we've hard-wired hacks and hardware only compatible
with Windows 95 into the system...if you try using something other
than Windows 95 (including, sometimes, later OSes by MS even :), it'll
probably fall apart quite ungracefully"...it's a sort of "we rushed
headlong into doing what the big bully said regardless of consequence
or compatibility with anything else because that's the biggest
market...in fact, if it becomes 'obselete' or 'incompatible' just
after the short warranty period, that's perfect for us because then we
can milk more money out of people who would then have to buy their
hardware as frequently as their OS"...
I had a great idea that some of the Linux people ought to do...well,
they have those "I use Red Hat" stickers and Linux penguin coffee mugs
and the cheeky "Powered by Red Hat" stickers (which delibrately are
the same style as the "designed for Windows 95" badges :) and all that
sort of stuff...so, the simple addition to that range of mostly
pointless but "patriotic" merchandise would be "peguin key"
stickers...just little squares of sticky paper with small, fat
penguins on them, which you stick on top of your "Windows keys" so
that they become "Penguin keys"...cool, huh? :)
Beth :)
Beth
> Paul Hsieh wrote:
> > Whether or not Windows runs correctly on a given CPU is not what I
would
> > use to verify the correctness of a CPU.
>
> It should be part of the package. A processor that does *not* run
Windows
> isn't going to be used much in PCs! :-)
>
> It's not a question of being right or wrong, it's a question of
reading the
> map. Does it really match the reality?
You're indeed correct...but - and here's the actual major issue behind
saying it's "wrong" - how is it that a software manufacturer is the
one drawing up the map for hardware people to follow?
Following this sort of thinking could eventually lead to absurd
notions like an instruction set that has a "WinSysCall" instruction,
specifically for making Windows API calls in special "Windows"
registers specially included for the purpose (other OSes be
damned)...sounds unlikely? This style of thinking has already put the
Microsoft(R)TM) Windows(R)(TM) logo on almost every keyboard in
existence and "branded" an input device and a system that MS, in
truth, have no rights or claim or anything at all (writing the main OS
that everyone uses can, at a stretch, justify the "Designed for WinXX"
sticky labels, even if they are ugly things, because that's just a
selling point...but that should be the _limit_ of their influence, not
just a starting point)...
Continuing along this path unchallenged secures MS's monopoly, in
short...because, as if good ol' MS don't have enough influence, it's
basically other companies manufacturing what people end up thinking of
as "Microsoft(R)(TM)" hardware on their behalf...it's a ludicrous
situation, to be honest, and only the infantile and immature computing
industry could fall for such crap...I mean, Pepsi would put a large
sticker on the side of all their cans saying "Coke-compatible clone",
would they? Even if it might actually be true...
It's a gross violation of one of the first rules of marketing: Don't
give someone else free advertising...although, it's actually a bit wor
se than this because they are almost giving all the credit to MS too
and they'll be lucky if people spot the HP or Compaq logo under the
mountain of MS(R)(TM) Windows(R)(TM) branded logos covering every
surface of their machine...Microsoft must love this, as in any other
field, they'd have to work to earn their bread...but, no, not in
computing...instead, they sit in their ivory tower and say "you must
earn your Windows logo for the side of the box" and then sit back
while everyone else jumps to their tune...they must be rolling about
laughing their cotton socks off at this situation...
Imagine me doing something similar...in order to earn your "Beth
approved" badges to stick on your PCs, you must do everything I say
when I say it...first, you must brand your keyboard to have "Beth
keys" (two of them as well, so that I've got one more logo on _your_
hardware than you are likely to have ;)...you must conform to my "Beth
PC" specification where you must add loads of proprietary hacks
specifically to work with my quirky OS software (just to make the
bluff work better, I hand money over to some other organisation to
host the specification on their website and call it the
"super-compatible absolute PC specification", so people think this is
some sort of industry standard...but, in truth, I invent 99% of it and
it's just a "statement of what Beth wants" :)...of course, I'm quite a
shrewd little person so I've delibrately put a few "Beth-isms" into
the specification which will make it work slow and horribly with
anything other than my super-fantastic OS :)...
Then I sit back and giggle as everyone everywhere jumps to my tune and
sticks my name on everything...as I hear people in the street say
"have you got one of those 'Beth' machines?" rather than "have you got
a PC?"...as my sales figures rise on the hardware I do make because
with all that brands and logos with my name on it, a lot of people
didn't even realise that the last keyboard they bought wasn't actually
my own brand keyboard...and, mistakenly, they think they'll buying the
latest model from the same reliable manufacturer they bought from last
time (there is a concrete reason why marketing people blankly refuse
to put any reference to other companies on their products...there are
plenty of people who don't care to find out exactly what's what and
will jump at the sight of any recognisable logo :)...even if they
realise that it was a Compaq keyboard or something, they'll still
think about buying a "Beth" keyboard because, as my logo appears on
every keyboard, they automatically assume this is some sort of
endorsement from me...that every other manufacturer is just trying to
copy my designs which are the state of the art (after all, the machine
is called an _IBM_ PC in full for similar reasoning...so, those who
aren't aware are totally forgiven for thinking that it was Microsoft
who made the first keyboards and all the others are "MS keyboard
clones"...that would be somewhat following what happened with IBM and
it wouldn't be stretching things for people to believe the same thing
is happening again)...
And, without doubt, it's market image suicide to do this...Microsoft's
name and logos become almost "immortal" as they are stuck on every
brand and the company's own logo fades in the memory because it's only
a tiny thing in the corner that most people get used to and cease to
see is there after about a day...I'm a programmer and pay attention to
these things and I'd have to stretch my memory to remember who made
every keyboard I've had (the only two I can remember without effort
are a Microsoft keyboard I bought that fell apart within a week and an
IBM keyboard that I've had for what must be a decade now...and, as you
may guess, I only remember those because MS's keyboard was so
pathetically miserable that I'd never go near their hardware ever
again...and IBM's keyboard seems utterly invincible to everything
and - if they could only improve the looks of the thing - is how every
piece of hardware should be...so robust and reliable that it's
approaching being a touch silly how well put together it is :)...
Anyway, yet again, the computing industry has fallen for yet another
Microsoft bluff...that's totally how they are where they are
today...Bill's a really, really good poker player, I have to confess:
IBM need an OS so he agrees (buys it off some hobbyist that, really,
IBM should have done themselves and got rid of the pointless,
troublesome and expensive middle man :) and then holds them to ransom
when they were left with no choice but to comply with his demands (we
have DOS :)...then, Bill strolls over to Apple and agrees to make
software for them...then, again, when Apple have little time and no
other choice, he ransoms them for the rights to use some of Apple's
user interface technology (which Jobs so loved, he purchased it all
off Xerox :)...the threat being that he'll pull all his software and
Apple would have to release the machine without any real software for
it (to pour salt into the wound, MS re-implement the VisiCalc
spreadsheet software because, at the time, copyright's so poor on
software, you could steal anyone's good ideas)...this second bluff
transforms into Windows...both times IBM and Apple should have thought
things through: a software company that develops software but pulls it
and never sells it? Microsoft would have been dead as a dodo if anyone
had called their bluff...like many poker players, they use high stakes
to make people think they "must" have a winning hand when they
actually have diddly-squat...later, MS pull another fast one on IBM
with OS/2...basically, they get IBM to finance developing Windows for
them and then, once they've got what they wanted, they jump ship...
Further along, Microsoft go for the highest stakes of all and try to
bluff the entire universe - at great expense - that Windows 95 is the
Messiah returned (note, though, that all the ads were "pretty colours"
and people smiling when looking at a monitor - which, interestingly,
we never get to see what's on the monitor (reminds me of the "gold
glow" when John Travolta opens that case in Pulp Ficition...the oldest
cinematic trick of the lot...don't show the audience what it is and
let their imaginations fill the gap...just suggest "good" and people
start imagining something fantastic...just suggest "evil" and people
imagine a terrible monster...really, check out a horror flick...the
best ones refuse to show the monsters and let you conjure up your own
bogeyman ;))...then, after bluffing everyone that Microsoft and the PC
are synonymous (although, where did they ever earn this? Sorry, but
you've just been "psycho-babbled", people...they just talk utter crap
but project the "I know what I'm talking about" image at you and,
suddenly, everyone trusts them without any reason to do so...Hitler
was a master of this...just look at the Nurenburg rally
footage...confident as anything, even if completely full of crap and
pulling a major bluff on an entire peoples from top to bottom, start
to finish)...Microsoft then pull out the "you must earn our logo on
your hardware" scheme to bluff the entire industry into giving them
free advertising and, usually, full credit for everything a user
sees...
And this is not to mention how Microsoft have somehow bluffed their
way into making people think that hundreds of dollars for the most
sold, general-purpose, non-specialist, mass-produced commercial
software is "reasonable"...sorry, as much as I'd also like to bluff
otherwise, software is not _that_ important to justify the price tags
Microsoft have...they also invented the standard wording for the "we
disclaim _all_ responsibility - good or ill - for anything that
happens" EULAs...well, they know and outrightly admit that they spend
zero time fine-tuning and debugging their software so it stands to
reason that they'd be the leaders in protecting their butts from
prosecution for what is, quite frankly, usually just negligence and
incomptence...
It's the very definition of a "tin god"...all shiny surfaces to dazzle
you but absolutely no real substance to justify their position...and
certainly very little to justify the adoration...
Really, it's this simple: They've hoodwinked and bluffed the whole
industry for decades and got themselves into an untouchable
position...if they'd got there fairly and honestly then, really -
though some might not believe it - I'd be one of their supporters
(when the "boy does good", I'll gladly give credit...Bill personally
donated a sum of money about equal to entire European nations(!!)
towards an AIDS in Africa charity...for that, I'll applaud him
publically and pour praise...shame about the other stuff, in fact, or
I wouldn't have to switch sides elsewhere...really, I _want_ to be
able to say "Bill's an okay guy"...like Fox Mulder, "I _want_ to
believe" but the facts suggest completely otherwise)...
Have you ever seen those ads for washing powder where they show how
white the old formula got clothes in comparison to their brand new
formula? The old formula still has stains on it but the new formula is
so brilliant white that you have to shield your eyes from the TV
screen...amazing, right? But, then, a few years later, they bring out
"New Formula Mark 2" and do the same "old formula vs. new formula"
comparison...and, oddly, now their old new formula has stains on it
and the brand new, new formula is brilliant white...ummmm, when did
the new formula become crap all of a sudden? One advert it's brilliant
white but, once they have an even newer formula, it's suddenly become
really crap...remind you of any operating systems sales pitches?
Windows 98, apparently, is infallibly perfect and allows you to "do
anything"..._until_, of course, they want to sell you Windows ME,
when - all of a sudden - Windows 98 is the black plague and will rot
your brain and lose you friends and is completely evil...ummm, huh? It
was only last week when it could do no wrong? Do people's word
processing or games playing needs really alter that radically in the
space of a year?
The Emporer has new clothes, basically ;)...
Beth :)
Maxim S. Shatskih
> software, you could steal anyone's good ideas)...
Yes. Ideas are not legally protected, only the products are. Read the
copyright law.
If they stole the existing DLL by other vendor - yes, illegal.
If they borrowed some other's look-and-feel - a normal practice.
>this second bluff
> transforms into Windows...
Windows is very, very much visually different from Mac OS, the only
common thing is that both are the windowed GUIs.
> actually have diddly-squat...later, MS pull another fast one on IBM
> with OS/2...basically, they get IBM to finance developing Windows
for
> them and then, once they've got what they wanted, they jump ship...
No. IBM sponsored OS/2 development in MS. MS - secretly from IBM -
developed their own Windows, and, on Windows release, threw OS/2 away.
Note they also had NT in development in the same time.
> bogeyman ;))...then, after bluffing everyone that Microsoft and the
PC
> are synonymous (although, where did they ever earn this?
MS's OS is installed on the majority of PCs, thus, MS + Intel = PC,
and other OSes are neglectable. A normal attitude.
Also note that PC hardware vendors will better obey MS's and Intel's
recommendations then some "open" spec like POSIX.
> to finish)...Microsoft then pull out the "you must earn our logo on
> your hardware" scheme to bluff the entire industry into giving them
> free advertising and, usually, full credit for everything a user
> sees...
No, the motivation is to relax the life for their development to avoid
them dealing with lame and buggy chipsets, PCI bridges and such.
> Microsoft have...they also invented the standard wording for the "we
> disclaim _all_ responsibility - good or ill - for anything that
> happens" EULAs...
Shrink-wrapped EULAs are null and void legally, there were several
court decisions on this.
As about such claims by themselves - if the purchaser is agree on
them, then they are legal. Otherwise, if there is no such claim during
the deed - then the vendor _is_ responsble for damage its product
causes.
>well, they know and outrightly admit that they spend
> zero time fine-tuning and debugging their software
Nevertheless, their software is better debugged then the vast majority
of other commercial software, not to say on being more usable.
> Really, it's this simple: They've hoodwinked and bluffed the whole
> industry for decades and got themselves into an untouchable
> position...
They just won. Period.
Max
Alexei A. Frounze
news:YyvX8.14153$fJ2.1...@news11-gui.server.ntli.net...
> Or, in short, the "Designed for Windows 95" badge isn't a designation
> of infallible godhood or anything...in fact, if anything, it's more
> likely to mean "we've hard-wired hacks and hardware only compatible
> with Windows 95 into the system...if you try using something other
> than Windows 95 (including, sometimes, later OSes by MS even :), it'll
> probably fall apart quite ungracefully"...it's a sort of "we rushed
> headlong into doing what the big bully said regardless of consequence
> or compatibility with anything else because that's the biggest
> market...in fact, if it becomes 'obselete' or 'incompatible' just
> after the short warranty period, that's perfect for us because then we
> can milk more money out of people who would then have to buy their
> hardware as frequently as their OS"...
Exactly. Just as any other business, ppl must create some product or
"enhance" the existing and sell it or offert a paid support of something,
because just as in any other business, ppl want money and this is the way to
get it. There are unfortunate businesses that do not enhance any existing
products because they either don't really produce those (like the fish
fished out by a trawler in the sea: "buy our fish, fish 2000 is tastier than
fish 98" or lumbering: "wood 2000 is better than wood 98, now 50% off, big
sale!") or those products are so simple, cheap and have clear function that
it doesn't make sense to improve or enhance them ("with these matches 2000
you can set on fire the whole district, which you were not able to do with
matches 98, so trash matches 98, buy matches 2000!"). Milking money is an
art that has come to our lives and doesn't seem to go away anytime soon.
Can't figure out how to "improve" or "enhance" the damned thing and make
everyone (or most) believe it's so real good? -- If so, die the business.
Some function doesn't work? The function is not very important or it's
noticable in the beginning that it doesn't work? -- Doesn't matter, now sell
it quickly, get the money and then start working on the next n-th edition
(which will have more those functions (including those to be fixed) and
probably yet more ways to improve/enhance, such a bright future of the
product)... Seems to be the way of doing business by selling a-priory
bloated and/or faulty stuff, right? :) This is where much of the software
is.
> I had a great idea that some of the Linux people ought to do...well,
> they have those "I use Red Hat" stickers and Linux penguin coffee mugs
> and the cheeky "Powered by Red Hat" stickers (which delibrately are
> the same style as the "designed for Windows 95" badges :) and all that
> sort of stuff...so, the simple addition to that range of mostly
> pointless but "patriotic" merchandise would be "peguin key"
> stickers...just little squares of sticky paper with small, fat
> penguins on them, which you stick on top of your "Windows keys" so
> that they become "Penguin keys"...cool, huh? :)
Bravo! Btw, you could probably start thinking on making money on this. A
buck for a sticker or something... Or maybe even KBDs with real penguin keys
:)
But that all doesn't make sense anyway. Designed for windows... Looks like
windows is working on my computer, not me. Should be designed for me! :)
Good Luck
--
Alexei A. Frounze
http://alexfru.narod.ru
http://members.tripod.com/protected_mode/
Beth
> Paul said:
> > Are you aware that Windoze has code in it that incorrectly detects
> > for the presence of the CMPXHG8 instruction and goes ahead and
> > uses it based on this incorrect determination?
>
> A CPU's problem and not NT's. if CPU claims CMPXCHG8 feature bit in
> CPUID features (and this is how NT determines the support for this
> opcode), it must support the opcode correctly.
Now wait a minute! Paul said that NT gets it's detection routine
wrong...assuming that this is true, then how on Earth can you assert
that a bug in MS's detection software is a CPU problem? I mean,
Microsoft corporate thinking might assert this rather than face the
truth of the situation...but it defies any sort of standard logic...
If my car has spikes in the wheels - like those chariots in Benn
Hurr - and, as I drive past other cars, it explodes their tyres and
they go flying off the road and crash...then this is the fault of the
other car manufacturers for not putting in "anti-spikes" devices into
their wheels?!? If Pepsi put poison into their drinks without any
warnings and I drink it and die, then this is my fault for not taking
the antidote first? If I put an axe through your skull then it's your
own fault for not always wearing an "anti-axe" helmet all the time?
Microsoft's "BubbleWorld" is a very interesting place indeed (the
disclaimer of responsibility in the EULA is just a way not to get
sued, it's not a statement of reality, Maxim ;)...
This takes the biscuit, Maxim...you're now advocating Microsoft beyond
what logic dictates...I'm more and more tempted to simply think that
you're a paid spokesman for Mr. Gates and his mates...you do seem to
know an awful lot about NT's internals as absolute fact...you utterly
refuse to ever consider even the smallest and most forgivable of
things because MS seem unable to ever be at fault for anything...I did
think "no, MS wouldn't be that transparent" but, on further
reflection, MS have their heads so far up their own...well, it just
fits the MS style so perfectly...although, be careful, Maxim, if you
utterly reject everything beyond even what logic dictates, people will
simply stop listening to any of your pro-MS arguments (much like I
also confess to switching off when some of the Linux advocates start
doing the "Linus has never made a mistake in his entire life"
argumentation)...
If MS have a bug in their CMPXCHG8 detection routine, then they
do...but, especially knowing MS's code verification policy (i.e. as
long as no-one notices that it'll sell, then don't bother doing
anything much about it...and this policy has been mentioned
innumerable times by different Microsoft employees at different
times...even if not an official policy, it's obviously an internal
attitude of MS because all MS spokesmen and women seem totally agreed
on this), this is understandable...
Alcoholics also have this level of utter denial beyond all logic and
reason...but, in truth, you can only cure the problem when you accept
that there is a problem and do something about it...for MS's own sake,
they've at least internally (if not publically) got to admit to these
problems and deal with them...it's self-destructive
behaviour...really, I'll just sit back and watch it happening...it's a
self-fulfilling prophecy...feel free to mark my words on this and
review back to it in a decade or so...if MS will fall, it'll be
because of it's arrogance and this whole "denial" thing...it's a
"compatibility problem" with reality and those can get very nasty, if
you're not careful...
Anyway, you've just contradicted your own logic beautifully,
Maxim...if, as you assert, CPU design should reflect its ability to
run Windows...then if Windows has bugs, they must reflect this in
their design also...but, here, you say that regardless of the Windows'
bugs, they should implement the opcodes correctly, anyway...which, of
course, will make them Windows incompatible...so, their designs aren't
reflecting Windows...which means changing the design to reflect
Windows...but Windows has a bug, so this means implementing the opcode
incorrectly...which you say is wrong...so, you change the opcode to
implement things correctly...but, no, this doesn't work because then
it's Windows incompatible...ad infinitum...ad absurdum...
So, the only way to avoid this paradox - this infinite loop - is to
assert that Microsoft can never make any mistakes or include any
bugs...oh, now I understand your rationale that it's not MS's
fault...if you admit to them making any mistakes then, logically, we
open up one of two possibilities...either we enter a paradox (which
obviously can't be right) or it means that MS aren't infallible
gods...hence, you _must_ totally and utterly refuse MS's fault in
anything regardless of whether it is true or not...
The logic here is now starting to make sense...MS are your "tin gods"
and cannot ever be challenged or this would be confession that they
aren't gods...it becomes "blasphemy" to even suggest it and the
"taboo" holds for all time...
"Elvis was a hero to most
But he never meant s*** to me...
He was a straight out racist
The sucker was, simple and plain,
Motherf*** him (and John Wayne)..."
[ "Fight The Power", Public Enemy...edited for public consumption ;) ]
Beth :)
Beth
> "Maxim S. Shatskih" wrote:
> > A CPU's problem and not NT's. if CPU claims CMPXCHG8 feature bit
in
> > CPUID features (and this is how NT determines the support for this
> > opcode), it must support the opcode correctly.
>
> 100% agreement. The CPUID bit isn't there to please Windows...it's
there to
> indicate the presence a specific instruction. If it indicates that
presence, but
> doesn't support the instruction, then the company who designed it
deserves to go
> down in flames for producing such a stupid design. It's been
documented in the
> Intel manuals, which are freely available, all the way.
Of course...but haven't you spotted the flaw in the argumentation yet?
As you say, "The CPUID bit isn't there to please Windows"...but
Maxim's earlier argument was that Windows is the measure of all
PCs...if your CPU doesn't work with Windows then your CPU isn't,
apparently, "real" or something (quite how it suddenly becomes ethreal
from a physical implementation, I'll leave to the philosophers to deal
with...as to all my sensibilities, this logic is far beyond what I can
deal with in my little brain ;)...
So, if Windows is not detecting the CPUID bit properly, where does
this leave these hardware designs? They _should_, of course, be
implementing it 100% correctly...but, if they do, their machines are
no longer "real" and are incompatible with the main operating system
software (which effectively makes them useless...which, to be fair to
Maxim, is what I think he meant to say but worded it badly..."real"
and "useful" have quite separate semantics to them :)...
Damned if you so, damned if you don't...and, better yet, Maxim - in
his assertion - is denying that this could ever be an MS problem...no
way, no how...so, MS are free to fill their OS with incompatibilty
bugs that create this utter paradox for the hardware manufacturers -
they are the _source_ and absolute _cause_ of this paradox - but at no
point is this ever their responsibility?
Of course, a CPU should implement the instruction set fully and
correctly...but, by the same token, an operating system should
interface with the hardware just as fully and correctly...anything
less is "incompatibility"...but, the crucial point is simply "it takes
two to tango"...Windows can be just as incompatible with the hardware,
as the hardware can be incompatible with Windows..."compatibility" is
achieved when _both_ parties are speaking the same lingo...any
deviation from either party introduces "incompatibility"...
But, as you've stressed, "It's been documented in the Intel manuals,
which are freely available, all the way." and that a hardware
manufacturer _must_ follow these Intel designs (as should MS)...which,
of course, means - by proxy - that if MS is incompatible with what's
in the Intel manuals, then it's _MS_ who's being "incompatible"...it
also stands conclusively as proof that being able to run Windows is
NOT the measure of a "real" PC...it's its conformance to what is
clearly and unambiguously stated in the Intel manuals...
Simply, Maxim cannot logically stand by all of his arguments here
simultaneously because they're logically paradoxical...he must drop at
least one of them or he's completely contradicting himself...I
nominate that he should drop the "MS have no responsibility" argument
because, to my mind, that's what's most nonsensical...but it's up to
him, of course, which argument he chooses is wrong...because, simply,
_one_ of them must be wrong as they contradict each other...
> > IIRC NT has code specially written for AMD CPUs.
>
> Really? I wasn't aware of that. :) Good to know not everybody
panders
> exclusively to Intel. (even if it's the evil empire we're talking
about here)
> Do you have an example of where/how? Is it a "CPU support module"?
I'd love to
> find out.
Huh? Now you're doing it...is this disease catching? I agree with
"good to know not everybody panders exclusively to Intel" in
spirit...but you've gone and contradicted yourself in the same post
because you stated that "compatibility" (and, in fact, like Maxim,
you're resting a CPU's legitimate right to exist on this
completely...if they don't keep with this, then they are not "real" or
that they "deserve to go down in flames for producing such a stupid
design")...is solely dependent on: "It's been documented in the Intel
manuals, which are freely available, all the way."...
So, if a CPU isn't 100% compatible with Intel's designs then its
spawning company should be torched in flames (nice "fire and
brimstone" imagery there, btw :)...but, somehow, it's also "good to
know not everybody panders exclusively to Intel"...
hehehe...this is very ironic, as you're earlier assertion was an
amazing display of "pandering" to Intel...absolutely _zero_ tolerance
for any deviation from Intel designs...in fact, you would advocate
that they should be eliminated from the face of the Earth in roaring
flames for not "pandering" exclusively to Intel's designs...
How men dare to say "women are illogical", I don't know? I read posts
where you men contradict your own logic in the very next
paragraph...I mean, I'm sure I mess up my logic too but I'm nowhere
near _that_ bad *...hehehe :)
Beth :)
* This is a joke; Men, in the wider context from what I've seen, are
not any more or less illogical than women...at different times, we're
as bad as each other...I'm just "riding" the infamous sexist saying
that "all women are illogical" to make my joke...so, there's really no
need for defence of masculinity, as I don't have a problem with it (in
more ways than one...hehehe :)...
ByrdKernel
arguments myself. (Easy to do, considering the sheer amount of "rah rah
Microsoft" and conflicting arguments. hehe)
The CPUs should follow the Intel spec. In other words, the CPUID bit means the
CPU has CPUID, period. If the CMPXCHG8B bit is not set, it doesn't have that
instruction, and you can't assume it does. Period.
Windows should follow the Intel spec as well...NT is at fault for the whole thing
in the first place, but adjusting the CPUs by breaking them (i.e., making them
not follow the Intel spec) doesn't seem a particularly productive solution to
me. Just because at the time, all Intel CPUs either had both CPUID and CMPXCHG8B
or neither does NOT excuse them, since Intel provided a separate bit for each.
(Note I say "Intel spec", not "clone of Intel's chips".)
And BTW, you're one of the most logical people I've seen around, Beth. ;)
ByrdKernel (Mike)
Beth wrote:
> (some stuff that felt like napalm)
ByrdKernel
> Just because at the time, all Intel CPUs either had both CPUID and CMPXCHG8B
> or neither does NOT excuse them, since Intel provided a separate bit for each.
Er...dammit, you know what I meant..."was either 6th generation and has CMPXCHG8B or
wasn't and didn't"...
It's too late for this kind of crap. :)
ByrdKernel (Mike)
Beth
Paul, I agree with you but calm down a little...both Maxim and
ByrdKernel have contradicted themselves royally in what they've
said...let them stir in their own juices, I say...let Maxim work out
how he's going to explain things, now that he's gone and contradicted
his own arguments (I'm sure he'll work something else out but I'll
just wait for the next contradiction and point that out...there is
_one_ way to avoid making further contradictions, though...simply tell
it like it is in the first place...lies and false assertions require
more lies and false assertions to cover up the problems they created
by not telling the truth in the first place...that's how you can
recognise the truth, you see, it stands clear and unpolluted all by
itself...it cannot be contradictory by definition :)...
> There is no way in hell either of those
> chips have anywhere near the number of bugs of the most stable
> fragments of code inside of Microsoft.
Indeed; The "compatibility problem" here is MS's code...amusingly, by
their _own_ admission, it's MS's responsibility because they both
stated specifically that Intel's designs are the absolute law on the
instruction set (not necessarily their "recommended" detection code
because, as you point out, it's full of obvious "bias" to their chips
:)...so, if NT's detection code isn't working, this 100% is MS's
fault...
How on Earth they can divine that if NT has bugs, this is AMD's fault,
I don't know...what about MS's other "issues"? Who do we blame here?
Bin Laden? The Pope? Mrs. Smith down the road? The conductor on the
local bus because he always tries to shortchange us? Who exactly? I
reckon it must be Phil Mitchell off the "EastEnders" TV show...he's
always up to no good ;)
> CPUs, like any complex software, have potential for things like
> "buffer overflows", "hangs" and just plain garbage results. The
main
> thing to notice about CPUs is that they generally do not "buffer
> overflow" or "hang" (the dan0411 Intel bug, as well as some of their
> marginal multiprocessor bugs are the only instances I am aware of)
and
> "garbage" is also pretty rare (P5 FDIV bug, the later masked FPU
> exception problem, WinChip's slightly defective PFRCPT 3DNow!
> instruction.) The one AMD problem that I recall was on their K6's
> where you had multiple masters and you issued a particular "lock"
> overriden instruction, you may hit a race condition on the actual
> fetch and end up with an illegally ordered sequence of reads/writes.
>
> CPU bugs are typically very hard to find/reproduce, because the
kinds
> of testing that goes on for CPUs is so exhaustive of all the lowest
> hanging fruit. That is in fact one of the major expenses of
building
> an x86 CPU (the compatibility testing.)
Yup; But the comparable process in software design is
mocked...whenever I suggest formal, exhaustive testing or anything
similar, it's not even a case of "such-and-such a practical issue
makes this a bad idea"...nope, it's just mocked and laughed at...like
I've just suggested growing "moon beans" on Mars or something...
In fact, as many of the software solutions that counter-acted the FDIV
flaw show, formal software testing could even be employed to cover up
hardware mistakes (not recommmended...better that the hardware is
fixed than sticking a "band aid" over it...but it's a possibility and
faulty hardware could get out before people notice there's a
problem...so cure rather than prevention ends up as the only
option)...
In truth - but no-one on this group is going to like me saying this
one bit - an operating system has no real excuse at all for not being
formally and exhaustively tested...all flaws in the OS are fully
inherited by all applications running on it (if Windows hangs, then
all the applications hang with it :)...
MS's policy that bugs are not important is their (dumb) choice...but
it is actually in direct violation of what makes any sense...operating
systems software requires a lot _more_ debugging than any other piece
of software because it's so fundamental to the operation of the entire
system...
Yes, OS software is big and complex...but, again, this means it
requires _more_ testing, not less...would people find NASA saying
something like: "Our space shuttles are really big and complex
designs...therefore, we've reduced testing and verifying those designs
by 200% in proportion to how much more likely it is that we've got
problems and bugs in the designs" as "reasonable" or even "common
sense"? So, why is it considered "just fine" for MS to claim just
that?
It's a pure indication of only one thing...MS have no concerns at all
but to make stupid amounts of money...and, congratulations, they've
done just that...they make oil barons, gold and diamond merchants -
even small countries - look pathetically small...but this benefits
no-one but _them_...pure and simple and plain...
> I'll give you an example from my inside knowledge. Inside of one
CPU
> vendor there is a group of workstations that are running 24/7 on
> groups of 3 "machines" at a time that performs the following: Throw
> random (but biased in a way to improve coverage) instruction
sequences
> and compare the results between 1) the company's CPU, 2) the
company's
> (compatible) competitor CPU, 3) the simulation of the company's CPU.
> Any discrepency between the results of any pair of these immediately
> raises a red flag and senior designers are brought in to diagnose
the
> problem. Once stabilized this test would run for 4 months at a time
> without finding anomolies.
At least this good...but, if possible, do better...I know, I know...in
this world, there's no chance...it's all "time to market", even if
what you give that market is utterly crap that they don't want
it...it's all "we must sheep MS, even if they walk off a cliff"...it's
all orientated to stupid psycho-babble and money-grabbing regardless
of consequence...but, really, this style of exhaustive testing should
be the _minimum_ people put things through...
I worked on a project where we used a neural network to make life or
death situations...in otherwise, a not-so-reliable system to decide
whether people live or die...a totally _zero tolerance_ situation
because a mistake translated into someone dying...and it gave me an
insight that, perhaps, many in this industry could benefit from
having...I would look through the results of our test runs and there
was a column with "pass" or "fail" in it...every time I saw "fail",
this was symbolic of a corpse...a family torn apart by grief...dreams
shattered...hearts broken...a life irretrivably lost forever...in
fact, one of the people who wrote the testing programs wrote it to
read "alive" and "dead" but was ordered to change it to "pass" and
"fail" because, simply, it was too much emotion to look at it that
way...
Despite working against the odds in so many directions, we got a
generally unreliable technology to produce results in the 95-98% range
(this was still considered "not good enough", btw ;)...and, no, it
_wasn't_ that expensive...and certainly NOT expensive compared to the
costs we'd be asking customers to pay if the system failed...they'd
likely be paying with their very lives...
Now, okay, OS software isn't that important...or is it? The connection
isn't direct, granted, but what about when - as happens in many places
around the world - they store medical records on Windows-based
machines? Yes, MS place the "don't use this in a life or death
situation" disclaimer on their machines...but, well, people do,
anyway...and even where they don't, a seemingly unimportant system can
effect actually important systems...
Would you consider a banking system to be "life critical"? Many
wouldn't but, thankfully, the law and the banks consider it very much
otherwise...banking information centres are put inside mountains,
manned by heavily-armed security officers and try to never disclose
their locations...in fact, where they actually keep the physical
money - the notes - is nowhere near as well defended...the information
is much, much more important...lose some bank notes and this is bad
but it can be replaced...lose the information about who's got what
money in their accounts and you're in big, big trouble because it's
irretrievable information...the penalties in law for a bank making
these sorts of mistakes might surprise some people...if their systems
go down for only a few days, then they lose their licence immediately
with no chance of ever being reinstated...their managers forever
blacklisted...they could ruin the world economy and plunge the world
into unknown troubles...there really is _zero tolerance_ for them...
Then there's local doctors putting their medical records on
computer...medical records are crucial and really do mean life or
death...the military, basically, refuse to deal with _any_ software
that hasn't been 100% formally proved and verified...and, thank
goodness, or all the nukes could have gone AWOL and wiped out human
civilisation...
The list is endless and that's only the "life or death" type of things
out there...if we have "sink or swim" situations, where systems
crashing can badly damage companies...if we include all the lost
revenues from hangs and system crashes...if we total up _everything_
directly or indirectly related with an operating system, the actual
cost is astronomically large...stupidly big...and the only real excuse
you can give is: "we don't pay that cost"...but, watch out, because
banks never used to have such severe penalties on them either...all
it'll take is _one_ right royal cock-up somewhere and they'll draft
laws to take the decisions out of the developers' hands...
And Microsoft simply have the least excuse in the entire
universe...they are the richest company in the world...if they can't
afford it, then it can't be afforded...period..._if_ Microsoft used
proper exhaustive testing then perhaps they can start justifying their
stupidly high price tags (which defies any logic, save "if we can get
away with it..." :)...
You reap what you sow...and there's no way to avoid that, as much as
you try...the longer you try to postpone the inevitable, the more
it'll hurt when it inevitably hits home...ask the accountants of all
those massive companies who've been fiddling their books to project a
rosier image than is true...the penalty now they've fallen is much,
much, much worse than the penalty they'd have faced if they'd tackled
the problems then and there...they now cease to exist...their
employees black-listed...utterly self-destructive behaviour that has
been preached for so long that these companies are all falling like a
fragile house of cards around us...
> All CPU vendors engage in similar levels of testing. They have
to --
> people, and OEMs that figure customer support calls into their
> expenses, rely on them to be perfect.
Oh...don't undersell it...that's the _direct_ consequences...the
indirect ones are monumentally expensive...and every little mistake
chips into a company's image...most companies do not fall like
flies...they let things slide and gradually fade out of
existence...you might not see or want to recognise the connection but
if you live on borrowed time, trying to be clever, it _will_ come back
to you eventually...
"Live 4 Love, because without Love u don't live...
And how u make it is based on what you're givin' back...
In fact, only a few of us slip through the cracks...
Through generations, the cards have always been stacked against us...
2 love each other is a must, if we just trust and cut the fuss
Believe me, unity is a _must_...
Listen everybody, as I spread the word:
Everything is hazy when your vision's blurred...
I'm kickin' reality in the streets of the city,
There's this mentality what goes around comes around...
And gangk any clown who ain't down
With the colors that u're sportin' 'round...
Listen, G, u are supposed 2 be strivin'
2 be the best that u can be...
So stop tryin' 2 dominate and push and shove
C'mon y'all, we got 2 live 4 Love"
[ rap part in "Live for Love" by Prince / Symbol / whatever, "Diamonds
and Pearls" :) ]
> Intel and AMD have publically disclosed their CPU bugs (thanks to
the
> PR fiasco re: Intel and the FDIV bug) and reading them gives you
some
> insight into the sheer quality of their testing. The scenarios in
> which you have to put yourself into just to see these strange bugs
> reveals what kind of strange corner cases they are looking at in
their
> testing. While Intel's disclosures actually contain some problems
> where you wish they had done a better job (with the understanding
that
> even those bugs are marginal), AMD's disclosure are amazing -- you
> have a hard time even understanding the scenario of bugs themselves,
> let alone have any worry about how they would creep into your
> software.
On a philosophical level, though, the approach to debugging and
testing employed by the entire industry is but an afterthought...even
in good cases like this, the reliance on randomly stumbling into
problems is hardly the best approach...if architects approached
designing buildings with the approach used in software, then the cases
of houses collapsing in on people would be vastly increased that it
would be considered, rightly, a systemic problem that needs
_immediate_ addressing...
Debugging is done as an inconvenient afterthought...it's approached in
a "cure rather than prevention" manner, waiting for things to go wrong
instead of ensuring that they couldn't possibly go wrong in the first
place...there's a total reliance on testing by individual actual cases
and, yes, that attitude is flawed...you can't test everything in all
situations one by one...it's impractical...
But then, it's a somewhat naive (well, computing is very immature
compared to many, many other practices :) attitude to assume that this
is the only approach...an architect doesn't ensure that a building
will stand by building "prototypes" and smashing them with wrecking
balls to see how much they could stand...only cowboy builders would
build something and then patch over the cracks and mistakes
afterwards...
This isn't just because it's impractical to approach things in this
fashion...it's ludicrously expensive to build a "prototype" building,
destroy it and then use it to create a better one, which you destroy,
etc. until you reach an acceptable design...but this style and
attitude completely _dominates_ software development...in fact,
getting anyone to adhere to coding standards, testing policies or
whatever is an uphill struggle...the whole "software lifecycle" is
based on the _wrong_ fundamental...you're lucky if you see "debugging"
and "testing" listed in the usual "lifecycle" descriptions and it's
always added as an afterthought...no efforts made to fully describe
it...
The so-called "software crisis" was NOT solved...it was patched over
with quick fixes and the need for conformance and consensus _forced_
itself as crucial that no-one could deny it...
The building you're in now stands and is trusted and reliable because
it was designed _mathematically_...it makes planes fly...it keeps
bridges from falling down...every single thing you can think of is
based in mathematics because it's proved its worth...in fact, when
things do go wrong, it's almost inevitable that this is because
someone took a "shortcut" somewhere or violated the fundamental
process or something like that...
Not that actual testing is never needed...mathematical models aren't
always 100% accurate...but, trust me, they're a million times more
reliable than "hack it together any old way then run some 'single
case' debugging tests and retroactively fix problems"...I know, I
know..."seeing is believing" and all that bullcrap...but, "newsflash",
most of the things we trust implicitly - like the buildings we're
currently sitting in - were never proved by anything but maths...
Not any good at maths? Well, don't worry...I know something that's
really good and quick and simply adores working out loads of tedious
mathematical problems...it doesn't complain about doing it
either...yup, computers are made to measure...yes, there's the old
"chicken and egg" problem here that you use a machine to test
software...but, look at the current alternative: you just trust it to
be right regardless...
Developmental tools need to incorporate this stuff...then it can be
done _proactively_...prevention rather than cure...the impractical
becoming very practical indeed (you don't see architects complain
about testing whether their buildings will fall down as "impractical"
;)...
It won't be perfect...it can never be perfect...but that's not the
point at all...you still strive towards getting it as good as it can
be...so, you can't be the richest person in the world...doesn't mean
you should give up your job and wither away in poverty...we do what we
can, as best we can...we'll leave perfection to the gods :)...
But if you look at the attitude and the practices, then it's little
wonder we have such a problem...really, it's patently obvious when you
follow a "hack it out, fix things when they show up" process then
you'll have unreliable systems...you are, in fact, _asking_ for an
unreliable system because you've elected to fix it afterwards...but,
yet, people seem surprised to see that maintenance costs of software
are the biggest costs...they're surprised to see buggy software...
But this should not be any sort of a surprise...currently, this
situation is what we are _asking_ for...if you implement a "cure
rather than prevention" system, then you must expect for patients to
walk through your door with illnesses asking you to cure them...you've
done _nothing_ to prevent these illnesses, so they will inevitably
occur...if you rely on single case actual execution testing, then you
are asking for an untested case to come back and haunt you...
Really, take off the "software engineer" hat for a second and let's
look over to another field for a second...think of it as a "day trip",
a tour of someone else's factory...simply, in maths, there are only
_two_ ways of ever proving something...the first way is what software
people attempt but is completely impractical...this is to try to
"prove" the software by testing every single possible case...for most
non-trivial software, this is barking up the wrong tree...yes, it's
impratical and, very often, simply impossible...
The second way - the way maths tends to prefer to prove its own
assertions - is that of "range testing" (my terminology there
:)...algebraic stuff...you prove "y = mx + c" rather than try to prove
each and every possible instance of a line (there's an infinity of
them...taking that approach, you're doomed to failure...you simply
_cannot_ prove it that way :)...and, where it gets used, it's tried
and tested as being very, very reliable...even if it does violate some
people's "seeing is believing" attitudes...
Can this second approach be applied to software? Yes, it can with
certainty...it's a closed deterministic system where we not only know
all the rules, we actually invented those rules...well, let's change
that from "rules" to "equations" and the approach should be
obvious...we test those "equations" against each other...we test what
"equation" our code fits to the overall "equations" of what we want
and the "equations" of how we know the system to be...unlike the
impractical first approach, this really isn't that much
bother...probably equal to doing it the "run, test, debug, run, test,
debug, etc." cycle, if not actually cheaper on occasion...the system
will be a set of equations, each subroutine, say, is another
one...test them against each other and bugs (even logic design flaws)
will be caught mercilessly, as we would like :)...
It can be achieved...it will be achieved...become an expert before it
becomes fashionable and stand head and shoulders as _the_ guru of
reliable software...they'll beat a path to your door :)
> I crashed Window 2000 (hard) within the first 5 minutes of me
touching
> it (not *trying* to crash it -- I was just trying to run Netscape,
and
> a few other non-MS products on this system.) I have witness
> confirmation of this.
Oh, don't worry about that...we've all got "witness confirmation" of
that...even Microsoft advocates don't ever shout too loudly about
"reliability"...they know that their case would quickly fall
apart...they tend to take the "yes, but Linux is unreliable when doing
such-and-such" (which, no doubt, is true because _all_ software, as I
mention above, takes the _wrong_ approach and still expects quality
and reliability)...
XP's quite good, though...I tend to be, like you, someone who always
crashes a machine without trying because I push it until it breaks
(well, you find out the limits and then can work comfortably within
those limits :)...it does crash but in comparison to the other
Microsoft OSes, it's a god-send...although, I joke to my little
brother all the time: "At last! Microsoft is approaching the levels of
reliability I've come to expect from everyone else"...that is, not
perfect - none are perfect - but at least you can use it most of the
time without much worries or problems...that's the other reason why
I'm so sharp toungued with regards to Microsoft...because I _know_
they are capable, if they'd only get their attitude right...I mean,
with the resources they command, they are capable of a great
deal...designing a "somewhat reliable" operating system should be
child's play...and they could afford testing procedures that make the
CPU stuff you've mentioned look pathetic..._if_ they only would put
their mindset into alignment with what is implicitly demanded of
them...
> I had to reboot my Win 2K box yesterday because
> the keyboard simply stopped responding (it had an uptime of about 3
> months which is actually not bad.) Microsoft is releasing a never
> ending stream of patches, and buffer overflows is a way of life for
> the Microsoft programmer.
Did you see the major Internet Explorer 5/6 cock-up? A handful of
lines of JavaScript could do the most worrying of things...because,
basically, there was a major cock-up in the JavaScript DLL that
effectively made a lot of the security simply non-existent...steal
files straight off a hard drive, website impersonation, "cookie"
issues and, top of the list, a "buffer overflow" problem that made it
possible to execute code...
Now, okay, MS have released a fixed version of the DLL that you can
download to fix this...but, let's take a step back here...look at the
resources MS command...look at the criticisms they always know they'll
come in for...no-one spotted the lack of security? Not one indication
at all in their testing procedures? Wouldn't this mean that there
wasn't a single test case of a large, large chunk of the JavaScript
DLL's security features?
Hello?!? The JavaScript DLL in their flagship Internet Explorer and
not even one reasonable test of these security features? They had to
have users give them "feedback" that it even exists? In short, did
they do _any_ testing at all on it?
Do you see what I'm getting at? As you point out, CPU testing does
find bugs but they mostly tend to be obscure things...that, as you
say, require a bit of effort to even find...it's not just the fact
that there's such an awful bug in the system, it's that it's one that
should have been spotted almost immediately...really, three or four
lines of JavaScript (not even complex JavaScript) exploits it...to
have not picked this up, there couldn't have been any testing of this
aspect of the DLL whatsoever? It's like having a spelling mistake of
"Micorsoft Windows" as the operating system boots up...if you only
actually looked at it, the mistake is glaring you in the face...
In short, and to be fair to MS (they're just the worst...which doesn't
mean everyone else is flawless by any means) software development
itself is _all wrong_...it needs a major overhaul because it's
emphasising all the wrong things...it's encouraging all the wrong
behaviours...as I say, it's actually patently _asking_ for this to be
the case..._nothing_ is done in any appreciable way to prevent it or
avoid it...companies like MS even proudly wear their "we rely on user
feedback" badges with pride that they send it out the door almost
_knowing_ it's buggy and then just wait for people to complain...
Even people, with no real building experience, who put together wooden
sheds for their gardens tend to take more care in the construction
than software developers do...they'll at least bother to lay out the
materials to check their all there...even this sort of careful
attitude is beyond many programmers...
Software development is, simply, backwards and retarded...and that's
the "kind" and "tactful" way to express this ;)...
> My inside knowledge into Microsoft is that
> they use standard QA engineers (who don't know how to create buffer
> overflow conditions, or where to even look for them) for their
> testing, and they have various degrees of bugs including "not
> serious". Microsoft will ship product once the level of bugs is low
> enough as opposed to zero bugs.
That's actually not the worst of it...that's, for better or worse,
pretty much "standard" practice in a worrying amount of places...what
the real issue here, I think, is, is: Where is the attempts made to
prevent bugs emerging in the first place? Surely, if you don't put
bugs in in the first place, then it's cheaper...it's quicker...it's
more reliable...theoretically, at least, if you catch bugs
_immediately_ then we could save on QA altogether (in reality, no
system could be good enough to warrant the removal of QA
altogether...but, in truth, the _programmers_ should be taking every
step to, in fact, make the QA job completely redundent...it should be
a "last resort" and not the "first port of call" for debugging, right?
:)...
If a product doesn't work then it's totally irrelevent how cheap it
was or how quickly you built it...if you spend only two seconds
developing Office XP for three dollars fifty cents (a mightily
impressive task, right? Quite impossible to beat, basically :) but it
doesn't work at all, then the fact that you did it quickly and the
fact that it was cheap is a completely useless fact...
Of course, in reality, it wouldn't be a case of "doesn't work at
all"...there's "degrees and measures" of incorrectness...but,
fundamentally, the same notion applies...if a feature doesn't work
then it doesn't work...you can try to hide this fact with as much
psycho-babble as you like but you can't avoid this patently obvious
self-evident fact...how quickly you achieve _failure_ or how cheap it
was to _miserably achieve nothing useful_ is quite, quite
_irrelevent_...it's _wasted_ money and time regardless of the quantity
of money and time that was wasted...
> Microsoft will never ever release a product with the stability of a
> Cyrix CPU or any other serious x86 CPU vendor.
No doubt, an accurate prediction...with the inherent attitudes rampant
throughout Microsoft, only a "I've found God" type of life changing
experience could ever come close...in short, it'll never happen but
I'm the sort who refuses to ever say "never"...to quote some lyrics:
"I won't promise because I don't want to lie"...so, never say never
again, right? Just in case it's wrong :)
[ snip ]
> > Its is the x86 compatibility of the CPU. x86 CPU is the one which
runs
> > Windows and all other OSes written for x86 - from DOS to
Solaris/x86.
>
> So Intel 386s which don't run Windows 2000 are not x86's then? Are
> Alpha's, which use FX!32 to run Windows, considered x86 CPUs? How
> about people who use BOCHs or Plex86 or Virtual PC? This is not a
> question for your MS indoctrinated political views. You have no
idea
> who you are speaking to when you try to tell me the definition of
what
> an x86 CPU is.
>
> Running OS's is a high level product viability test, but 1) is not a
> particularly difficult test and 2) cannot be relied upon to be
> intrinsically bug free anyway.
To be honest, with the way I see software and hardware tending to be
developed, I am almost tempted to laugh at the notion of the phrase
"bug-free" being used by _anyone_...I'll hand it to you, Paul, that
you far and away are much closer to the mark and, no doubt, it's your
experience with all that CPU testing that is making you understand the
issues...
But, if we're really talking "bug-free" and _zero tolerance_, I don't
see anyone who can validly make any claims to even approach such an
ideal...really, it's _all_ wired up the wrong way...attitudes are not
even in the right ballpark...everyone prefers to wear the blinkers so
that they can keep hacking out code without accepting the true
responsibility that goes with it...
Yes, I'm no better and can't make any claims...but I've seen the
problem and recognise it...I'm out of the "denial" phase and can now,
hopefully, proceed to do something about it...that's really what the
BethTool ideas I've had is all about...I took a long hard look and
realised that it's 99% bullcrap...that we cannot make the sort of
demands that people do of a process inherently and fundamentally wired
up the wrong way...it needs to start to be re-wired up the right
way...time to get the house rewired, as the old wiring is now becoming
a fire hazard :)
Beth :)
Alexei A. Frounze
> Have you ever seen those ads for washing powder where they show how
> white the old formula got clothes in comparison to their brand new
> formula? The old formula still has stains on it but the new formula is
> so brilliant white that you have to shield your eyes from the TV
> screen...amazing, right? But, then, a few years later, they bring out
> "New Formula Mark 2" and do the same "old formula vs. new formula"
> comparison...and, oddly, now their old new formula has stains on it
> and the brand new, new formula is brilliant white...ummmm, when did
> the new formula become crap all of a sudden? One advert it's brilliant
> white but, once they have an even newer formula, it's suddenly become
> really crap...remind you of any operating systems sales pitches?
> Windows 98, apparently, is infallibly perfect and allows you to "do
> anything"..._until_, of course, they want to sell you Windows ME,
> when - all of a sudden - Windows 98 is the black plague and will rot
> your brain and lose you friends and is completely evil...ummm, huh? It
> was only last week when it could do no wrong?
Read Orwell's 1984? Time to time the party issued claims that the plans were
overfullfilled, even though they were not (according to the previous party
claims about what's gonna be done) and everytime such a descrepancy was
found, all old documents (newspapers, magazines, etc etc, from which one
could find out the truth) were rewritten. Every time the big brother's
company arrested and/or killed somebody, every little evidence of his/her
life was eliminated. The past was rewritten, there was no past.
Orwell was right about many things. And he wrote that long before 1984 and
2002.
Do ppl want his book's horrors to really come true? Or they just never read
it...?
> Do people's word
> processing or games playing needs really alter that radically in the
> space of a year?
Games might be. Word processing, I doubt it.
> The Emporer has new clothes, basically ;)...
Yeah, nude :)
Beth
> Paul wrote:
> > serious". Microsoft will ship product once the level of bugs is
low
> > enough as opposed to zero bugs.
>
> Surely, as any business company will do. Reaching "zero bugs" level
> will require enormous time to be spent on it, which is unacceptable
> from business point of view.
You're essentially right, Maxim...but don't wear a grin or a badge of
pride about it...it's basically an admission of failure, isn't it?
You're admitting that things _should_ be this good but aren't because
of where priorities lie (whether we agree with those priorities is
another matter)...
Although, following a process that has no preventative policies within
it to ensure that bugs are incredibly hard to enter into the code in
the first place...that simply blinkers itself that they're saving
money by transferring it all from development to maintenance...
Maintenance costs are known and have been shown to be stupidly big
with all software...of course, if software was reliable and bug-free,
it patently wouldn't need quite so much maintenance (not necessarily
none but as close to what we can achieve :)...
It's NOT cheaper, the expense is simply being transferred to a later
stage...it's "passing the buck"...the developers rush it out quickly
and then present their bosses with small figures and the bosses are
too short-sighted to realise that the expense saved there is just
being thrown out into their product (which actually damages company
image...so, if anything, this is _costing_ the company a lot more than
they think in real terms...MS's reputation is so damaged, that if
there was a comparable rival - which there isn't at the moment (as
much as those rivals try, they cannot be seen to be _true_ rivals) -
then they would have very, very few loyal users standing by
them...many are even starting to migrate to systems that they know are
actually "lesser" for their requirements - but can do most things - to
avoid MS and that's _without_ having a rival competing fairly and
equally with them...as I've said before, MS certainly sell the most
units...this does NOT equate to being most popular and that everybody
loves them, though ;)...
Further, bugs are postponed...it's also been categorically shown that
a bug solved sooner is cheaper to fix than one solved
later...distributing patches is NOT free of cost, you know...product
recall - if things get truely bad - is a stupidly large expense...if
the software is out there and other software begins depending on
it...if companies start basing their operations around the
software...then fixing those bugs increases in cost almost
exponentially...this is why maintenance costs massively dwarf
development costs...everyone rushes out cheapy products and spends no
time fine-tuning it so that they're effectively throwing out their
bugs to the public and fixing them all retro-actively...and this isn't
expense-free...quite the contrary, it's a lot more expensive than if
caught in development and removed then...
It's a cheap psychological trick that managers should be amazingly
embarrassed that they fall for it each and every time; The developers
rush it out and their costs look fantastically good on the bosses'
spreadsheet of costs...how fantastic these developers are to have
saved them so much money!! Then, later, they need to issue patches,
fixes, new versions, revisions, product recalls, support helplines are
swamped with users facing "issues", etc., etc., etc....simply, the
connection between those development costs and the maintenance costs
isn't recognised because it's not put on the same spreadsheet to show
to the boss...he or she fails to make the connection...
The developers get away with issuing crap, buggy software that's
_guaranteed_ to massively inflate the product support and maintenance
budgets but look angelic because the actual _direct_ costs of
development seem cheap and fast...and, when the statisticians have
looked at this, maintenance costs are stupidly big...all those bugs
that were left be _must_ eventually be addressed in successful
software that lasts the distance (the longer its lifetime, the more
the software will be put through its paces and be pushed to its
limitations :)...
It's just putting it all off for tomorrow...except this really isn't a
wise move, as it'll be more expensive to tackle the problem
tomorrow...common sense tells you this...actual statistics tell us
this too...in this case, though, tomorrow does eventually come
round...it can't be postponed forever (unless you're software fails to
stick in the market, anyway)...
It's NOT cheaper...it's vastly more expensive but you're falling for
the simple psychological trick that, by postponing it, the costs are
no longer _direct_ costs...you just look at the development figures
and think you're saving money...but, simply, you are NOT saving money,
you're just going to be throwing bad money after worse at things that
could have been dealt with quickly, cleanly and much less expensively
during development...
How much more expensive would it have been to spend a while longer
running some software through an extra-long period of QA and testing
and debugging, in comparison to having to develop "patches" for the
software at the companies own expense (you can't legitimately charge
for a patch to fix bugs...so this all actually figures into the
overall cost of _development_, even if usually thought of as
"maintenance", which also tends to be thought of as "separate" but
isn't :) and distributing these patches free of charge to your
customers? Worse, if it's a really bad bug, you might have to make a
massive change to the software - perhaps even a full or partial
product recall (or something effectively the same, such as issuing a
"patch" that replaces the vast majority of the software ;)...in these
sorts of cases, you are actually paying costs for the same thing
_twice_...as the second "patch" development will be out of your own
pockets...
Worse, this postponement is not only likely to actually prove more
costly in the long-term but it's perpetuating the actual technical
problems...that is, for example, if I'm writing browser software and
spot the bug in development, I can fix it there and then...this adds a
little to intial development costs but that bug is gone...I've fixed
it completely, no versions released to the public will ever contain
the bug...I've stamped on it, it's now one very dead and squashed
bug...
If I release my browser software, though, the bug is loose...yes, at
my own expense, I can issue a "patch" to fix the bug...but, basically,
there's no chance of me getting away with charging my users for a
stupid bug of my own doing...I _must_ - to retain a good reputation -
release this "patch" at my own expense - perhaps through my company's
website or something :)...basically, by now, it's got to be costing me
at least the same expense as if I'd fixed it in the first place during
initial development...although, most probably, it's actually costing
me a lot _more_ because I'm effectively _duplicating_ the publicity,
distribution (and possibly manufacturing too, if this is going to be
issued on a CD or something :) costs for this "patch" as well as the
original software...
Worse still, I now have to have my support team deal with issues
regarding _both_ the patched and unpatched versions of the
software..."patching" also inevitably "pollutes" the actual software
code...during initial development, I can perform a "seamless mend" of
the bug...it can, basically, be totally _annihilated_ for once and for
all...with a "patch", it tends to be very much as the name
suggests...a quick "band aid" to cover over a bug...
This makes further development of new versions based on the old...and,
perhaps, further patching all the more difficult and costly...say I
release this "patch" only to discover that there is yet another
bug...I have to patch over the patch...again, we're now effectively
_tripling_ some of the greatest software development costs: publicity
for the new patch, distribution of the new patch, additional support
for what is now three possible versions of the same software (the
people on the support helpline are now having their "expertise" pushed
keeping track of everything...that means they're not helping people as
well...which, again, knocks onto company image very directly...the
point of "first contact" between company and user must be as close to
flawless as possible or people will just walk off and deal with
someone else)...
My source code is now looking stupid...I've also got to maintain
back-ups for effectively three versions (a relatively minor cost but
it's a grand annoyance and will take up developer time, which costs
money...after all, that was the whole point of rushing out
development, wasn't it? To reduce developer time to an absolute
minimum ;)...making further revisions will now actually start to be
almost painful to do...
Worse, because the source code is now an ugly patchwork quilt, we're
making all the more likely that yet more bugs will develop out of
further work on it...just keeping track of which patches were issued
to which versions becomes a pain to deal with...let alone all that
source code behind them...possibly developed by different developers
because once the original development was finished, those developers
have gone onto other things (a different product by your company...or,
dread of dreads, they've moved to a different company altogether and
can't be reached any more)...
This is growing more and more unmanageable every second...and, let's
remind ourselves, the alternative would have cost an extra week of
developers' wages and would have buried that bug completely and
forever...it would have _annihilated_ the bug and left clean, seamless
code in its place...because we took that tiny bit of extra time to
make it "just right" before release...
It's a false economy...it's simply "Fool's gold"...you are not
reducing the costs...you are transplanting them from development into
maintenance...and, worse, things tend to be a lot messier and more
expensive in the maintenance phase than in the development
phase...when you're coding something up and you find a bug, it takes a
little more time but is relatively painless (after you've finished
pulling your hair out and have worked out a nice, clean solution to it
:)...but, trust me, this is _definitely_ the lesser of two evils
here...trying to fix your mistakes post-release and you have an
absolute nightmare to contend with, that's all going to cost straight
out of your pocket and, statistics categorically show, it will cost
you _more_ then that it would earlier...
Still hold "time to market" as most precious? You shouldn't be...if
you do, you've fallen for "spin" and "psycho-babble"...a simple
psychological trick that programmers can use to make it look like
they're costing a company less...when, in truth, they've directly
contributing to costs that are sky rocketing out of control...
If, of course, you can manage cheap and fast development BUT have not
compromised an inch on removing bugs, this is the best
situation...that truely _is_ cheaper...but, you see, what we have here
is that we've got the "ship it out full of bugs" situation being
falsely labelled as the ideal situation...but, really, look at those
maintenance costs...that's a misdiagnosis for the vast, vast majority
of software, which is just rushed out full of bugs as long as they
don't qualify as "fatal bugs" which mean that the software is
completely unuseable (that it won't even load without crashing, for
example :)...
I say again, the entire attitude is misplaced...it's "Fool's gold" and
a complete false economy...look at the _whole_ cost of the _entire_
development and you can see that it's just moving it from development
into maintenance...where, worse, it will actually cost a damn sight
more to fix...don't think "tommorrow never comes", think "Hasta
Manana"...you deal with tomorrow's problems today but do so quickly
before tomorrow comes..._preventation_ rather than cure :)...
> Sun does the same with Solaris, BTW.
All software developers tend to the exact same thing with
everything...the only difference is that MS are developing
_fundamental systems software_ here so every bug or minor problem is
amplified into a major problem for applications running on top of it
and for users using it...I've an application where if I click on a
menu item, the application tends to crash...no problem, I avoid that
menu item until they issue a "patch" or a new version or something
(I'm not pleased with this - as I appear to have paid for complete
crap - but it can be dealt with :)...but if Windows crashes whenever a
menu is clicked on, this makes the _entire_ system quite, quite
unuseable...I can't avoid using menus in all applications...that's
just silly...
If Windows can't deal with my soundcard and blue screens all the time
(which, btw, is actually true and not just a made-up
example...whenever XP crashes, it's always because I've been using the
soundcard...the soundcard drivers seem to be the problem, confirmed by
the fact that other people with similar hardware are reporting exactly
the same problem as me on various websites I looked at for a fix :),
then all applications are brought down with it...
It is more serious with OS software because applications _inherit_
fully the OS's underlying behaviour...worse, without an OS or when
it's got a serious flaw in it, the hardware becomes effectively
useless (if my OS can't, for example, handle my new video card then -
short of switching to an OS that can - the video card for all its
"polygon acceleration" and fancy tricks is totally useless to me...an
OS interfaces between hardware, software and user...if it's broken
then these three things - which are totally dependent on each other to
get work done - stop communicating properly :)...
Basically, OS software is _fundamental_ and what MS (and others from
the way they talk about their OS development at times :) don't appear
to appreciate that, for OS software, the quality bar needs to be
raised...you need to go to _greater_ lengths than you would for
application software...I sometimes get garbled graphics in a computer
game...not much of a problem...I get grabled graphics inside the
Windows display driver for my card, the system becomes effectively
unuseable because the graphics keep on messing up all the time...
When developing OSes, you need to go to a _higher_ and _greater_ level
of intolerance to bugs...but, basically, MS's main problem is that
it's seems not to recognise this and develops Windows as if it were
just ordinary applications software...in fact, you even sometimes here
"OS software is big and complex" used as an excuse (not only by MS,
btw :) not to do as much debugging...no, no, no..."OS software is big
and complex" means that you _must_ do more, not less...it means
there's more room for bugs...but it's an OS, so bugs cannot be
tolerated as much...
MS haven't got their mindset out from when they used to make
applications for the Mac...or still think in a "Windows 3.x"
way...which, yes, was basically just a jumped-up piece of applications
software...but they have to realise that when they changed territory,
the rules became a lot more serious...
> I suspect VMS is the same - it is just old and mature enough to have
> bugs, it was not released bug-free.
I would not take any claims of "bug-free" seriously at all...unless it
was Ada Lovelace herself because, as I predicted before, her
mathematical mind (and dare I say her feminine mind :) are exactly in
tune to what's really demanded of software...her programs were "bug
free"...ironically, of course, Ada's mathematical mind would probably
have meant that she would _never_ have dared claim "bug free", despite
that very same mind meaning that her software was the closest to
achieving that claim...
I don't take even Knuth's claim of "bug free" as anything beyond a
somewhat sarcastic joke...though, no doubt, again, he's likely to be
head and shoulders over most people because he knows and tries to
achieve that...rather than hacking out some code which paasses a
handful of simple tests and then stating "I am infallible!!!", as so,
so many others seem to think is the right thing to do...
Beth :)
ByrdKernel
> Paul, I agree with you but calm down a little...both Maxim and
> ByrdKernel have contradicted themselves royally...
Hold it just a damn minute. I will now quote for you the only thing I said on
the subject before my "Beth, I'm agreeing with you" message:
Max> A CPU's problem and not NT's. if CPU claims CMPXCHG8 feature bit in
Max> CPUID features (and this is how NT determines the support for this
Max> opcode), it must support the opcode correctly.
Me> 100% agreement. The CPUID bit isn't there to please Windows...it's there to
Me> indicate the presence a specific instruction. If it indicates that presence,
but
Me> doesn't support the instruction, then the company who designed it deserves to
go
Me> down in flames for producing such a stupid design. It's been documented in
the
Me> Intel manuals, which are freely available, all the way.
I agreed with the ONE POINT that if a CPU shows a CPUID bit that indicates
support for an instruction, it'd better damn well support the instruction. I
also agree with the point that if NT's code assumes things it shouldn't,
Microsoft should be strangled...what else is new? I didn't bring that up,
because I thought Paul did a pretty good job of it already. If I overquoted a
little, so what? I stated my specific point quite clearly.
MS> IIRC NT has code specially written for AMD CPUs.
Me> Really? I wasn't aware of that. :) Good to know not everybody panders
Me> exclusively to Intel. (even if it's the evil empire we're talking about
here)
Me> Do you have an example of where/how? Is it a "CPU support module"? I'd love
to
Me> find out.
Here I was expressing interest in something I wasn't aware of...I didn't know
there was ANY AMD-specific code in NT. I was just asking for some information
about where it was. I was also commenting on the fact that lots of companies
have exclusive agreements with Intel which essentially goes "We'll write code for
your horrible P4, and ignore the superior performance of AMDs, because you're
giving us a Big Check."
It turns out I was a lot less confused than I thought I was...I was convinced
that I had posted something while half-asleep agreeing with something else he
said. But I didn't, at least not on this subject.
So *DO NOT* go tossing me in with Maxim's rabid pro-Microsoft fervor, or his
incessant argument-switching. I despise that company, and I have ever since they
started stealing technology for fun and profit, gobbling up companies whole just
so they could destroy them and their products, and essentially telling consumers
"You don't matter...we have an agenda, and you will bow before us and give us
more money".
Watch where you drop the verbal napalm, Beth. Immolating the innocents in a
thread is *NOT* one of the finer principles of debate.
Maxim S. Shatskih
1984 and
> 2002.
He described the Stalin's USSR more-or-less exactly. Real 1984's USSR
was much, much milder.
> > processing or games playing needs really alter that radically in
the
> > space of a year?
>
> Games might be. Word processing, I doubt it.
Vice versa, abandonware games are still interesting to many, not so
with ancient versions of Word.
Max
w m r
> [mostly repetitive stuff snipped]
> If I release my browser software, though, the bug is loose...yes, at
> my own expense, I can issue a "patch" to fix the bug...but, basically,
> there's no chance of me getting away with charging my users for a
Can we say "New and Improved - Upgrade version $99.95!"
> stupid bug of my own doing...I _must_ - to retain a good reputation -
> [more repetitive stuff snipped]
Mike
Maxim S. Shatskih
NT do this properly. I don't know from where this "NT does not use
CPUID" crap is from.
Maybe some ancient version.
> Of course, a CPU should implement the instruction set fully and
> correctly...
Note: this set is defined by commercial vendor (Intel) only, and thus
depends on their will.
Only Intel can provide a sane definition of x86 opcode set.
> But, as you've stressed, "It's been documented in the Intel manuals,
> which are freely available, all the way." and that a hardware
> manufacturer _must_ follow these Intel designs (as should
MS)...which,
> of course, means - by proxy - that if MS is incompatible with what's
> in the Intel manuals
No. Even if NT did not use CPUID in the past - the only meaning of
this is - "P6 CPU must support CMPXCHG8B". This means - manufacturing
a CPU which claimed to be P6 and did not support CMPXCHG8B - means
manufacturing a buggy CPU.
Cyrix should implement CMPXCHG8B properly or stop claiming P6
compatibility.
> also stands conclusively as proof that being able to run Windows is
> NOT the measure of a "real" PC...
Tell this to a customer. "Yes, this is a Real PC, but it cannot run
Windows". The customer will not buy such a machine, and will be very
much surprised on your notion of "Real PC".
I'm thinking _marketing_ notions here. Only they determine what
standards are, not some commitees.
> Simply, Maxim cannot logically stand by all of his arguments here
> simultaneously because they're logically paradoxical...
Absolutely not so. My main argument - "the leading market forces are
always right. By definition. They define what is a Real PC".
For instance, MS is turning to declare any PC without APIC as
"non-real" - and this will really be so.
Linux, having a significant market share (on servers), can also
participate in this definition. The real products, and not
speculations or on-paper standards. Real products (even if
proprietary) are always more influenced then on-paper specs.
> nominate that he should drop the "MS have no responsibility"
argument
> because, to my mind, that's what's most nonsensical...
What kind of responsibility do you mean? For software bugs? Hey, you
have been warned that MS disclaims this responsibility. You still use
MS's products? Fine, than this disclaimer works.
You can use any other products which you consider better if you do not
like this.
Nevertheless, millions of people use MS's products, and note! - all
efforts of commercial companies on winning MS failed. Does this speak
on nothing?
Turn back to reality from the ivory tower of "abstract perfectness".
There is no such thing and will never be, at least in production of
any kind.
> > Do you have an example of where/how? Is it a "CPU support
module"?
> I'd love to
> > find out.
Kexxx/Kei386xxx/Kixxx functions in NT kernel.
Since AMD is significant and respectful enough (and "respect" here
means market share only) - they are "blessed" by MS (one of the 2
companies who earned the right to define x86/PC) to extend the x86
definition in their proprietary way. As about lesser-respectful
companies like Cyrix - make a 100% x86 clone or be buggy.
Business takes only the large players into account. Smaller players
must either play with the rules the large players created (as a result
of their competition) or go down. It's not this bad, since the small
player in one world can be a "figure" in another - for instance, the
CAD vendor is unlikely to have influence over Windows or x86 design,
but is a renowned vendor for its customers.
> So, if a CPU isn't 100% compatible with Intel's designs then its
> spawning company should be torched in flames (nice "fire and
> brimstone" imagery there, btw :)
Why torched? Just dis-respected.
Only the market force decides what is "compatible" and what is not.
For customers, PC = Windows, and not QNX. Period.
> How men dare to say "women are illogical", I don't know?
I never said so.
The correct statement is - "emotions are illogical" (unless you're a
skilled psychologist :-) they can see the logic even in
schizophrenia), and women are more emotional.
Also, Beth, you're not an average woman. For instance, average women
do not go in for computers :-)
> * This is a joke; Men, in the wider context from what I've seen, are
> not any more or less illogical than women...
Maybe. My logic is very simple - "marketing force is the ultimate
jugde in terms of compatibility, and maybe even product quality".
Max
Maxim S. Shatskih
of
> pride about it...it's basically an admission of failure, isn't it?
An admission of reality.
> You're admitting that things _should_ be this good but aren't
because
> of where priorities lie (whether we agree with those priorities is
> another matter)...
I'm admitting that there is limited amount of "production power" you
can apply to the product.
So, low-priority things are thrown overboard. If you will achieve 100%
bug-free - then product can be either slow or suck in usability or
lack some very important features.
Yes, for years, bugginess was a low-priority thing for MS. Thus the
famous Bill's statement.
And note! This worked! _For the target market of that-days MS_, this
was fine! MS was already the winner with this ideology!
MS changed only in attempt to win some part of the server market, with
NT and BackOffice.
Now let's see the servers. MS seems to play the following game there -
being not so able (or unwilling) of changing the Excel-based business
model to the one server software vendors use, they concentrated on
their traditional strong point - usability - there. Server software
usually sucked in usability, since server software vendors
traditionally had other priorities, and usability was "overboard".
And what MS does? Provides _usable_ server software! With lesser
efforts to administer!
This can please lots of people, and thus MS's market share on servers.
Note that MS more or less holds the competition there _even against
the free software_! Usability seems to be the only case. Do you know
any other?
Some (and lots of ) people consider it is better to save on sysadmin's
salary fund by paying MS for OSes. :-)
This is not so bad. What is bad is another MS attitude. Their powerful
points are not only usability, but the great ability of adding more
and more new features to the product - "feature race" and "version
race". This is again "Excel business style", and not the style of
server systems vendors - IBM, Digital, Sun and such. Nevertheless, MS
introduces this style to server software, due to the same reason of
applying the own strong points.
Most atrocities by MS like Code Red are directly derived from this
style. Note that these bugs are neither in W3SVC nor in ASP, but in
some not-necessary crap which, due to Excel-style marketing reasons,
is always on by default.
Funny but they even provide "IIS security tool" to _downgrade_ IIS and
eliminate the non-necessary stuff, instead of making the default
installation W3SVC+ASP only, without .HTR, .IDQ and such.
> Although, following a process that has no preventative policies
within
> it to ensure that bugs are incredibly hard to enter into the code in
> the first place...
Or maybe there is no such processes efficient enough, only puny
attempts to create such?
No tool will save you from mixing "Socket" and "AcceptSocket" names in
the code, for instance.
Only the code _age_ ("code maturity") can help there. This is the only
cause of VMS's and mainframe's stability. The "feature race" (which is
the main reason of MS's bugs) is bad, since it does not give the time
to stabilize the code, and thus the code is always immature.
PHP has feature race and thus buggy, while Apache is "no" in both
items.
>that simply blinkers itself that they're saving
> money by transferring it all from development to maintenance...
First of all, for MS's developers, there is a weak border between the
two.
They always work, fix bugs and add features. At some moment, some
supreme boss (often Bill himself) says - "this build will be RTM
release" (even if it has bugs). Nevertheless, the work continues, the
newer builds are provided as Service Packs.
They always do development, and some milestones are published as
product versions or service packs.
> with all software...of course, if software was reliable and
bug-free,
> it patently wouldn't need quite so much maintenance (not necessarily
> none but as close to what we can achieve :)...
No, the costs are the same :-) the question is only in - what amount
of maintenance is done before the public release, and what - after.
:-)
Bugfixing and QA is the same maintenance, but done before public
release.
> It's NOT cheaper, the expense is simply being transferred to a later
> stage...
Exactly.
>it's "passing the buck"...the developers rush it out quickly
> and then present their bosses with small figures and the bosses are
> too short-sighted to realise that the expense saved there is just
> being thrown out into their product
A common case is tiny and stupid companies, but I have doubts MS is
such.
MS's bosses IMHO are more concerned with "time-to-market" and not
short-sighted.
> they think in real terms...MS's reputation is so damaged, that if
> there was a comparable rival - which there isn't at the moment (as
> much as those rivals try, they cannot be seen to be _true_ rivals) -
> then they would have very, very few loyal users standing by
> them...
Maybe. But - Linux is NOT a comparable rival due to weak usability
(look! Linux is there for years, and is FREE, and is still not a
winner on desktops! You can conclude why), and any commercial
companies trying to rival with MS failed - Be (a pity that Be, BeOS is
great) and IBM.
History tells us that, to bring down such a market leader, a complete
technology shift is necessary - like from propeller airplanes to jet
ones or such. For computers, palm-sized devices could be such a shift.
Nevertheless, MS are smart enough to monitor the new technologies and
move money to them. Thus they won over Palm with WinCE (the cause is
also visible - Palm tends to reduce the number of features due to some
"smart" ivory-tower-based statements, while WinCE wants to be
feature-rich), so, even such a "paradigm shift" did not damage MS
significantly.
In fact, the web technology was surely such a "shift". And again MS
survived it. Now we run Windows and MSIE, and not the sci-fi "network
computers" by Oracle.
So, you can wait for yet another paradigm shift. :-)
> exponentially...this is why maintenance costs massively dwarf
> development costs...everyone rushes out cheapy products and spends
no
> time fine-tuning it
That is based on another notion called "time to market".
> isn't recognised because it's not put on the same spreadsheet to
show
> to the boss...he or she fails to make the connection...
This is a usualy thing in extremely stupid companies only. If MS would
be _this_ stupid - they would not survive.
> It's NOT cheaper...it's vastly more expensive but you're falling for
> the simple psychological trick that
Again - it is based not on boss stupidity, but on "time to market"
issue, which is much less stupid and more important.
> and think you're saving money...but, simply, you are NOT saving
money,
Monetary losses from being later then the competitor can be larger.
> isn't :) and distributing these patches free of charge to your
> customers?
It is not this expensive. Distributing is done via web, and also -
patch production is tightly connected with new version production, as
it was with NT4 SPs - many of them contained w2k's components in
them - NTFS and NDIS, for instance.
>Worse, if it's a really bad bug, you might have to make a
> massive change to the software
Such things occur very, very rarely. Designers are not this stupid.
>- perhaps even a full or partial
> product recall (or something effectively the same, such as issuing a
> "patch" that replaces the vast majority of the software ;)
Product are never recalled, but such patches are really popular and
called Service Packs.
> _twice_...as the second "patch" development will be out of your own
> pockets...
It is connected with the development of the next version.
> Worse still, I now have to have my support team deal with issues
> regarding _both_ the patched and unpatched versions of the
> software...
Since patches are free, you can just respond - "this is fixed in
latest patch".
>"patching" also inevitably "pollutes" the actual software
> code...
Again not necessary, again - it is connected with updates for the next
version.
> This makes further development of new versions based on the old...
This is nearly the only way. Rewriting the product from scratch is
rarely used - for MS, nearly the only such effort was MSSQL 7.
> _tripling_ some of the greatest software development costs:
publicity
> for the new patch,
Yes. This is a loss.
On the other hand, better QA cycle before release costs time to
market, which is also bad.
>distribution of the new patch
Extremely cheap, just put it on the web and possibly notify the
appropriate newsgroups.
>, additional support
> for what is now three possible versions of the same software
You can stop support of the unpatched version - "go download the free
patch".
> (the
> people on the support helpline
They are poor support anyway, only the public forums are good support.
> further work on it...just keeping track of which patches were issued
> to which versions becomes a pain to deal with...
No, the process is linear.
Version N.0 module.
Version N.0 module with patch 1 - internally, named Version N.1
The same with patch 2.
Then - Version N+1 module.
> remind ourselves, the alternative would have cost an extra week of
> developers' wages
Not a week.
Compare your QA to the world of customers in terms of bug-seeking
abilities. I can expect that QA can be 100 times worse in this.
So, easy-to-find bugs are easily fixed before release. As about
hard-to-find bugs - the world of customers will find them 100 times
quicker then your QA. So, finding them in your QA will inevitable lead
to huge time-to-market loss, not a week.
> code in its place...because we took that tiny bit of extra time to
Again - not "tiny" bit.
While QA progresses, the number of bugs decreases, sometimes vastly
(exponentially). So, the product is released when this curve goes
slower. Doing more QA will not refund itself due to lots of time spent
and lesser bugs found.
Note that open source can offload not only bug-hunting, but bug
_fixing_ to the customers too. :-) this is why it is successful.
> It's a false economy...it's simply "Fool's gold"...you are not
> reducing the costs...
You do not take into account the "time to market" issue, which is VERY
important.
> here...trying to fix your mistakes post-release and you have an
> absolute nightmare to contend with
In fact, the bug fixing costs are the same pre-release as
post-release, the only thing which really suffers is company's good
name.
> Still hold "time to market" as most precious? You shouldn't be...
Agree, but the reality is that it _is_ important, especially under
strong competition. Having _no_ product is worse then having
moderately buggy one.
> you do, you've fallen for "spin" and "psycho-babble"...
Time-to-market is surely a "psycho-babble", but the "psycho-babble" of
customers. It is more profitable to follow customer's "psycho-babble"
then to change their minds :-)
> don't qualify as "fatal bugs" which mean that the software is
> completely unuseable (that it won't even load without crashing, for
> example :)...
Usual QA goes far beyound MATS. Always. MATS is done for intermittent
code drops to source control.
> I say again, the entire attitude is misplaced...
Since you cannot change minds of millions of customers, it is better
to follow their desires, even if they are false.
> If Windows can't deal with my soundcard and blue screens all the
time
> (which, btw, is actually true and not just a made-up
> example...whenever XP crashes, it's always because I've been using
the
> soundcard...the soundcard drivers seem to be the problem
So why MS to blame? Blame the card's vendor.
MS cannot debug all drivers themselves, though they really try to do
this with WHQL.
In fact, MS know that people tend to blame MS for driver's bugs. Thus
WHQL.
And as about the driver quality - it is often atrocious, due to the
same "time to market" issue. Cards violating the PCI spec are also
such.
> to appreciate that, for OS software, the quality bar needs to be
> raised...
And it is really raised.
> free"...ironically, of course, Ada's mathematical mind would
probably
She had no "time to market" issue above her.
Max
Maxim S. Shatskih
> lines of JavaScript could do the most worrying of things...because,
OK.
NTBugTraq had a vote once - "do you want MS to remove all VBA macros
from Office for safety and security?". The answer was - "NO! Our
company's internal software depends on it heavily".
People prefer having the feature with security flaws to not having the
feature at all. By adding more and more DHTML features, MS pleases web
designers. And as about bugs - people will think on them only after
:-)
Max
Maxim S. Shatskih
> disclaimer of responsibility in the EULA is just a way not to get
> sued, it's not a statement of reality, Maxim ;)...
You do not know laws. You judge from your personal overly emotional
feelings. The laws are other.
A vendor _can_ sell things with such a disclaimer. If the consumer do
purchase them, having explicit agreement to the disclaimer - then yes,
the vendor is not responsible legally. For instance, using MS's
software for life and death situations (and medical databases are not
such for sure - anyway databases are backed up and such, and MS's
software is enough good for databases with regular backups) - the user
is responsible. He/she was warned.
But, by default, if the consumer have not seen the disclaimer and did
not explicitly agree with it - then the "default" from Roman Law
works, under which the vendor is civilly responsible for the monetary
losses caused by the product (you must also prove this fact!).
The only thing is that shrink-wrapped form of the legal document is
null and void though :-)
> know an awful lot about NT's internals as absolute fact...
:-))) I just know some people with source access.
I also have enough personal experience with strange flaws in
open-source software - installed according to HOWTO, not working
nevertheless due to some minor detail. I could spent major amount of
time to figure the small detail out, nevertheless, I have MS software,
which is nearly always free from such flaws. Installation is easy, and
works according to the documentation.
Usability is another pro-MS thing.
In real life, one can usually trust MS software to not start ill
behaviour. Not so with many other commercial products. Netscape
crashes with AV faults much, much more often then MSIE.
Sorry, I have no anti-monopolic notions, and just silently prefer the
browser which do not crash this often.
I also have no "blind following to sacred-cow open standards" notion,
thus I prefer more developed HTML (and starting with MSIE3 in 96, MS
is more advanced then NN), and the "this is proprietary!" thing is a
no-op for me :-). After all, other vendors are free to repeat these
proprietary things, which are well-documented BTW (MS always had great
HTML reference).
Also please stop these "illegal browser war" thing. Yes, a bit illegal
de-jure. Nevertheless, in 95-96, Netscape was a de-facto standard for
Windows. The mere fact of including browser to the OS would not be
enough for MS to win. There could be an attitude of "MSIE is in the OS
but sh*t, download Netscape for a Real Browser". This did not occured
too, surely due to MSIE being technically superior to NN.
I also very much satisfied with MS's quality of documentation, which
is among the best computer-related documents I ever saw
(SunSoft/Solaris's and Borland's are good also, BTW. In fact, Borland
is good. I can say nothing bad on BC++ 3.1. A good product. But
MSVC1.5 is even better! The integrated debugger and a bit more
convinient UI, not to say on optimizer).
I also had some experience with Java once around 97. The thing which
Sun did to JDK1.1 vs. JDK1.0 (throwing away the backward compatibility
and requesting re-coding of existing code) is really an atrocity. Even
the despisable MS did not do this. :-)
I also saw how differently the same applet behaves in MSIE and NN -
yes, the image rendering pipeline and AWT. After this, the
"cross-platform nature of Java" is null and void for me, at least for
UI (maybe EJB servlets are better, don't have personal experience). As
about server-side Java in case of Sun's NetDynamics - oh yes, 128MB
RAM instead of 32 for the same app on ASP, much more often crashes and
the necessity do restart the web server to recompile the .class.
Great.
Also - Sun's lawsuit against MS's speed improvements to Java's garbage
collector is really atrocious, and hindering the technical progress.
Also - Sun's Java IDE was a visually noticeable clone of older MSVC.
:-)
Also - compare the MS J++ debugger to contemporary Sun's one, or
compare the JVC compiler speed.
So, JavaSoft (not SunSoft who produces Solaris) is much more
despisable company for me then MS.
I also saw Oracle Webserver of 1996 making stupid things like hangs
with inability to restart and being unable to start on multihomed
server. Surely no ASP and nothing similar :-)
That's why I have a good opinion on MS.
> refuse to ever consider even the smallest and most forgivable of
> things because MS seem unable to ever be at fault for anything...
Sorry, Beth, but I, for instance, really cannot understand this
"monopoly is evil" thing.
Monopoly means - standards. So, if the monopoly provides good
standards, the monopoly is good. Good (and even satisfactory)
standards is better then lack of them (or several contradicting and
incompatible).
Thus, any cries about "nasty MS monopoly" are just content-less
histrionic loudcries for me. I consider them as being based on
psycho-babblic "hatred to big guys", which is based either on envy or
on childish attitudes of self-greatness (which causes punks and other
junkies, for instance).
> If MS have a bug in their CMPXCHG8 detection routine,
Sorry. w2k had no this bug for sure. Maybe previous versions had.
Anyway, let's see:
- Paul claims old NTs judge the fact of CMPXCHG8 presense by
_generation_ and not by feature bits.
- nevertheless, Intel and AMD never produced any P6 CPUs with no
CMPXCHG8 and no feature bit set, so, NT worked fine on all these CPUs.
- thus, NT had a flaw of not following the Intel's document
exactly, and making a wrong assumption. Nevertheless, the flaw never
occured on Intel CPUs. It did not reduce the NT's quality.
- you see - the x86 standard is _proprietary to Intel_. So, x86
clonemakers must match Intel in all documented _and undocumented_
details. Otherwise, the market will not accept them.
- Cyrix would implement CMPXCHG8 instead of loudcrying on MS's
problems.
> self-fulfilling prophecy...feel free to mark my words on this and
> review back to it in a decade or so...
Let's see. Let's see. The thing is that most other commercial software
vendors have the _same_ problems with bugs as MS. For instance, Oracle
had the same security flaws as MSSQLServer once.
MS is just the largest and most noticeable.
> Anyway, you've just contradicted your own logic beautifully,
> Maxim...if, as you assert, CPU design should reflect its ability to
> run Windows...then if Windows has bugs, they must reflect this in
> their design also...
This is the _market_ logic. The market-based opinion on the issue is -
"Cyrix is smaller then MS, so, if NT does not run on their CPU and
runs on more trustworthy CPUs - then this is Cyrix's fault". Company
size does matter. Period.
I can imagine the consumer saying - "sorry, NT works fine on all sane
CPUs, this is your CPU problem". This is very, very real.
If NT would not run on _Intel_'s CPU - the other talk, hardware
vendors - if the same "rank" of Big Guys - are more trustworthy then
MS, so, in this case, the public opinion would be to blame MS.
> bugs, they should implement the opcodes correctly, anyway...which,
of
> course, will make them Windows incompatible...
Cyrix did nothing correctly. They just did the thing doubtful, not
explicitly banned by the docs, but not as in Intel's product.
The correct implementation (Intel-compatible) would be - either
implement CMPXCHG or do not claim to be P6.
> Windows...but Windows has a bug
...which did not manifest on CPUs by trustworthy vendors. :-) and also
does not contradict Intel's documents. It is a bit hard to call this
"a bug".
> incorrectly...which you say is wrong...so, you change the opcode to
> implement things correctly...
This leads to a question on what is "correct" and what is "incorrect".
:-)
Remember - this is a proprietary CPU (note! all other CPUs are
proprietary, either manufactured by single vendor, or designed by
single vendor and manufactured by several others under explicit
license, accompanied by complete internal documentation) by Intel.
So - what is "correct"? Doing by violating some thing forgotten in
Intel documents, but used in reality? Or doing by cloning the Intel's
_implementation_ one by one?
Producing x86-compatible CPUs without explicit license from Intel is a
risky business (and also doubtful a bit in terms of intellectual
property), you see. So is producing any El Cheapo clones - Cyrix and
especially UMC (which started the thread) is this for sure, so was AMD
till they restructured the execution units in Athlons.
Blaming the major vendor (MS) in ignoring El Cheapo clones is a bit
strange. "Get yourself a genuine real CPU" - can be the answer. Or
better - "is Cyrix is on our hardware compatibility list?".
Then maybe some bosses in MS decided to put Cyrix to such a list - and
in this moment, NT was patched to pay attention to feature bit and not
generation number.
Let's see the Rowenta washing vacuum cleaners or Epson jet printers.
Try to claim "you device is bad! I used it with El Cheapo washing
liquid or ink cartridge, and it failed!". They will immediately
denonce this claim. Cyrix is to Intel as Chinese El Cheapo cartridge
producer is to Epson or Novomoskovsk detergent factory is to Rowenta
(well, the latter one licensed Tide IIRC).
> So, the only way to avoid this paradox
Paradox is in your mind only.
First, what is "correct" in Cyrix? Risky decision, contradicting the
GenuineIntel implementation, though not contradicting the docs?
Second, what is "bug" in MS? The decision, again risky, again not
contradicting the docs, and not causing problems on GenuineIntel?
Now tell me why MS's decision is "the bug" and Cyrix's one is
"correct".
Third, the market reality. For consumers, if Cyrix and Windows are
incompatible - this is Cyrix's fault, since Intel is compatible, and
MS is larger then Cyrix. MS is the leader, while Cyrix is Intel's
follower. And people know this.
> gods...hence, you _must_ totally and utterly refuse MS's fault in
> anything regardless of whether it is true or not...
MS has lots of faults, but not in this doubtful case.
IIS metabase, for instance, is really an atrocious design.
Including lots of not-so-debugged (hey, they are not core!) additional
components to IIS default install is another.
Stealing (yes, directly. IIRC they had the code, but were not licensed
by Stac to include it in their products) code from Stac in 1993 - yet
another :-)
Max
ByrdKernel
> NT do this properly. I don't know from where this "NT does not use
> CPUID" crap is from.
> Maybe some ancient version.
You're still not reading whole messages, are you?
Paul already spelled out what the problem was: When NT sees a 6th generation CPU,
it assumes the presence of the CMPXCHG8B instruction, which is *NOT* a valid
assumption. A valid assumption is that you can use CPUID and test the CMPXCHG8B
bit. Microsoft did not do this, and pretty much destroyed a CPU vendor as a
result of their unwillingness to fix or even admit this mistake.
By the way, the version Paul mentioned was 3.x...I presume he means all 3.x
versions, or he wouldn't have said it that way. That's a pretty impressive span
of years to be mis-detecting CPUs.
> Note: this set is defined by commercial vendor (Intel) only, and thus
> depends on their will.
> Only Intel can provide a sane definition of x86 opcode set.
Yes, and the CPU makers followed it. Microsoft screwed up. Then the CPU vendors
UN-followed it and hardwired the CPUs to report incorrectly. Bad choices on both
parts, but MICROSOFT SCREWED UP FIRST and then wouldn't fix it.
> No. Even if NT did not use CPUID in the past - the only meaning of
> this is - "P6 CPU must support CMPXCHG8B". This means - manufacturing
> a CPU which claimed to be P6 and did not support CMPXCHG8B - means
> manufacturing a buggy CPU.
> Cyrix should implement CMPXCHG8B properly or stop claiming P6
> compatibility.
No. There is a mechanism for detecting 6th generation, and a mechanism for
detecting the presence of the CMPXCHG8B instruction. Both are separate, and are
CLEARLY defined in all Intel manuals. Microsoft took the short way, and screwed
up.
In short, they *DID* implement it properly...Microsoft didn't, and that doomed
Cyrix.
> Tell this to a customer. "Yes, this is a Real PC, but it cannot run
> Windows". The customer will not buy such a machine, and will be very
> much surprised on your notion of "Real PC".
> I'm thinking _marketing_ notions here. Only they determine what
> standards are, not some commitees.
Yes. Microsoft often breaks things for marketing purposes, and they have for
years. Remember the old phrase, "DOS ain't done till Lotus won't run"?
> What kind of responsibility do you mean? For software bugs? Hey, you
> have been warned that MS disclaims this responsibility. You still use
> MS's products? Fine, than this disclaimer works.
> You can use any other products which you consider better if you do not
> like this.
MS can disclaim this responsibility if they want, to try to avoid lawsuits, but
it's common sense...they wrote it. If they wrote it wrong, it's their fault.
Are you a lawyer now, as well as a marketing execute? (If you are, that might be
an automatic signal that you ARE an M$ rep. I think it's almost a given that all
employees must earn their MBA and law degree before they ever learn C++.
> Nevertheless, millions of people use MS's products, and note! - all
> efforts of commercial companies on winning MS failed. Does this speak
> on nothing?
Efforts to compete against M$ fail mostly because the company will do anything
illegal, immoral, unethical, or just plain wrong to win. Period.
> Turn back to reality from the ivory tower of "abstract perfectness".
> There is no such thing and will never be, at least in production of
> any kind.
So now that you've described your ivory tower of Microsoft's innocence and
perfection, you're attacking someone else's? HA!
> Kexxx/Kei386xxx/Kixxx functions in NT kernel.
> Since AMD is significant and respectful enough (and "respect" here
> means market share only) - they are "blessed" by MS (one of the 2
> companies who earned the right to define x86/PC) to extend the x86
> definition in their proprietary way. As about lesser-respectful
> companies like Cyrix - make a 100% x86 clone or be buggy.
Your use of the term "respect" instead of "popular" makes me believe you DON'T
just believe it's market share. You actually think Microsoft should people
should bow and scrape in M$'s presence.
> Business takes only the large players into account. Smaller players
> must either play with the rules the large players created (as a result
> of their competition) or go down. It's not this bad, since the small
> player in one world can be a "figure" in another - for instance, the
> CAD vendor is unlikely to have influence over Windows or x86 design,
> but is a renowned vendor for its customers.
Business takes the bottom line into account. There are no rules, thanks to
companies like Microsoft who blew the rest of corporate "ethics" away in the '80s
and '90s. Because of bastards like them, no small players who actually make a
profit can survive very long without getting bought out or destroyed.
> Why torched? Just dis-respected.
> Only the market force decides what is "compatible" and what is not.
> For customers, PC = Windows, and not QNX. Period.
No...whether something WORKS determines compatibility. You're really going nuts
on this marketing angle, aren't you?
> Maybe. My logic is very simple - "marketing force is the ultimate
> jugde in terms of compatibility, and maybe even product quality".
And it's also wrong. Marketing force means consumers get screwed, because they
get sold something that is usually inferior, both in compatbility and quality.
ByrdKernel
> NTBugTraq had a vote once - "do you want MS to remove all VBA macros
> from Office for safety and security?". The answer was - "NO! Our
> company's internal software depends on it heavily".
Max, that DOESN'T mean that people LIKE having these security holes lying open
like sieves! It just means that people have taken advantage of them for good as
well as for ill. And you wouldn't need to eliminate ALL the VBA macros to
tighten security.
There's an ENTIRE SCIENCE devoted to phrasing questions so that you get the
answers that you want. Whoever wrote the survey (probably Russ, I imagine)
favors the functionality of VBA macros, and wanted it to come out "no".
> People prefer having the feature with security flaws to not having the
> feature at all. By adding more and more DHTML features, MS pleases web
> designers. And as about bugs - people will think on them only after
> :-)
People are not all of a piece. Generally, users who don't know any better want
goodies. Unfortunately, they are the majority, and they were given the least
secure, most troublesome and buggy goodies possible by M$ before anyone in
Redmond woke up and thought about security. And then they only woke up because
the screaming was so loud that they couldn't just put their fingers in their ears
and go "LA LA LA LA" anymore.
ByrdKernel
> > Microsoft's "BubbleWorld" is a very interesting place indeed (the
> > disclaimer of responsibility in the EULA is just a way not to get
> > sued, it's not a statement of reality, Maxim ;)...
>
> You do not know laws. You judge from your personal overly emotional
> feelings. The laws are other.
Are you even listening? She said "a way not to get sued". That includes by the
government. That's ALL it's there for.
Just because Microsoft says they're not responsible doesn't mean they aren't.
Just because I say I"m a ham sandwich doesn't mean I want to be assaulted by
mayonnaise.
> A vendor _can_ sell things with such a disclaimer.
Not if he/she wants to stay in business very long.
> If the consumer do
> purchase them, having explicit agreement to the disclaimer - then yes,
> the vendor is not responsible legally. (blah blah)
Yes. It's the law...NOT reality. There are other considerations beyond what the
politicians are paid by corporations to pass.
> time to figure the small detail out, nevertheless, I have MS software,
> which is nearly always free from such flaws. Installation is easy, and
> works according to the documentation.
*rolling on the floor, laughing* What reality do you inhabit?...I'd love to
vacation there sometime.
> Usability is another pro-MS thing.
Okay, granted on that point.
> Also please stop these "illegal browser war" thing. Yes, a bit illegal
> de-jure.
Isn't that like "sort of pregnant"? They destroyed Netscape with illegal tying
of products. Period.
> Sorry, Beth, but I, for instance, really cannot understand this
> "monopoly is evil" thing.
> Monopoly means - standards.
Monopoly means no competition, which means $200 OSs that are way too big, force
corporations to license them for a fixed period instead of forever, that contain
lots of "buy me too" features like .NET, force upgrades by obsolescence whenever
the vendor feels like it, and generally make consumers into slaves. How is this
good? Because stuff works? That's nice...I heard once that when a certain
German dictator was in power, the streets were safe. So what??!?! Did that make
him good?
> - thus, NT had a flaw of not following the Intel's document
> exactly, and making a wrong assumption.
Holy crap! Look, everybody, Maxim admitted a Microsoft flaw!!!!!!
> Nevertheless, the flaw never
> occured on Intel CPUs. It did not reduce the NT's quality.
Aw, I knew he'd ruin it.
> - you see - the x86 standard is _proprietary to Intel_.
You just said in a previous message that AMD had earned the right to dictate the
spec as well. So you're being inconsistent again.
> - Cyrix would implement CMPXCHG8 instead of loudcrying on MS's
> problems.
They implemented Intel's specs correctly, and Microsoft did not. That's the
fact.
> This is the _market_ logic. The market-based opinion on the issue is -
> "Cyrix is smaller then MS, so, if NT does not run on their CPU and
> runs on more trustworthy CPUs - then this is Cyrix's fault".
No, that's YOUR opinion.
> Cyrix did nothing correctly.
Except implement Intel's specs the right way.
> The correct implementation (Intel-compatible) would be - either
> implement CMPXCHG or do not claim to be P6.
No...the correct implentation is "declare what you have". It had 6th generation
features, but not CMPXCHG8B, which was clearly an OPTIONAL part of the 6th
generation architecture, or it WOULD NOT HAVE ITS OWN CPUID BIT!
> ...which did not manifest on CPUs by trustworthy vendors.
So now you're deciding who it trustworthy. It must be nice to have such a
simplistic and egomaniacal view of the world.
> This leads to a question on what is "correct" and what is "incorrect".
Obviously. Because you haven't been sure of that throughout this whole
discussion.
> (blah blah)
I'm not even going to bother responding to the rest. It's the same thing.
"Market determines compatibility. Intel is righteous. Microsoft is righteous.
No one else matters." Whatever.
Martin Str|mberg
: again...and IBM's keyboard seems utterly invincible to everything
: and - if they could only improve the looks of the thing - is how every
: piece of hardware should be...so robust and reliable that it's
: approaching being a touch silly how well put together it is :)...
Try pouring some Coca Cola onto (into) it. Let's know if it survived.
(Sun keyboards don't like coffe much either.)
Right,
MartinS
David J. Craig
"ByrdKernel" <byrdk...@yahoo.com> wrote in message
news:3D308EDE...@yahoo.com...
> "Maxim S. Shatskih" wrote:
>
> > NTBugTraq had a vote once - "do you want MS to remove all VBA macros
> > from Office for safety and security?". The answer was - "NO! Our
> > company's internal software depends on it heavily".
>
> Max, that DOESN'T mean that people LIKE having these security holes lying
open
> like sieves! It just means that people have taken advantage of them for
good as
> well as for ill. And you wouldn't need to eliminate ALL the VBA macros to
> tighten security.
>
> There's an ENTIRE SCIENCE devoted to phrasing questions so that you get
the
> answers that you want. Whoever wrote the survey (probably Russ, I
imagine)
> favors the functionality of VBA macros, and wanted it to come out "no".
>
applications for some degree of security?
2. Is it acceptable that VBA macros have no restrictions on access to the
system and would prefer this be corrected even if it requires VBA to be
removed?
3. Another question even more pro security and minimizing the positive
effects of VBA.
This is a little like the question about Bill Clinton and his 'private life'
as compared to a question about an employer taking advantage of an employee.
> > People prefer having the feature with security flaws to not having the
> > feature at all. By adding more and more DHTML features, MS pleases web
> > designers. And as about bugs - people will think on them only after
> > :-)
>
> People are not all of a piece. Generally, users who don't know any better
want
> goodies. Unfortunately, they are the majority, and they were given the
least
> secure, most troublesome and buggy goodies possible by M$ before anyone in
> Redmond woke up and thought about security. And then they only woke up
because
> the screaming was so loud that they couldn't just put their fingers in
their ears
> and go "LA LA LA LA" anymore.
>
> ByrdKernel (Mike)
>
The virus writers prefer the security holes even more than the web designers
like the features they provide.
David J. Craig
> "Maxim S. Shatskih" wrote:
>
> > > Microsoft's "BubbleWorld" is a very interesting place indeed (the
> > > disclaimer of responsibility in the EULA is just a way not to get
> > > sued, it's not a statement of reality, Maxim ;)...
> >
> > You do not know laws. You judge from your personal overly emotional
> > feelings. The laws are other.
>
> Are you even listening? She said "a way not to get sued". That includes
by the
> government. That's ALL it's there for.
>
> Just because Microsoft says they're not responsible doesn't mean they
aren't.
>
> Just because I say I"m a ham sandwich doesn't mean I want to be assaulted
by
> mayonnaise.
>
sold to work as promised. That is why M$ tried to get the UCC changed in
the US so they could do what they wanted. Sell you a version of Windows and
a few months later, change the license to say it has expired with any notice
to you other than posting it on their web site.
> > A vendor _can_ sell things with such a disclaimer.
>
> Not if he/she wants to stay in business very long.
>
> > If the consumer do
> > purchase them, having explicit agreement to the disclaimer - then yes,
> > the vendor is not responsible legally. (blah blah)
>
> Yes. It's the law...NOT reality. There are other considerations beyond
what the
> politicians are paid by corporations to pass.
>
I do like some of the rules in the EU and am happy they won't permit US
companies to not conform. They do move slowly, but I suspect they will
eventually beat up on M$.
> > Also please stop these "illegal browser war" thing. Yes, a bit illegal
> > de-jure.
>
> Isn't that like "sort of pregnant"? They destroyed Netscape with illegal
tying
> of products. Period.
>
This has already been decided in US courts. M$ engaged in the illegal
protection and expansion of its monopoly. The appeals court only overturned
the remedies. M$ is trying to do what IBM did during its antitrust problem
or giving a little as slowly as possible. I would probably do it too if I
had the capability.
Martin Str|mberg
pushing development costs onto maintainence costs.]
Beth, you missed the fact that Microsnoft is pushing the costs of
maintainence onto the poor producers of systems (any problem is
redirected to those who put the hardware together, not Microsnoft).
Hence Microsnoft is extremely happy that the costs move from
development to maintainence!
Right,
MartinS
Martin Str|mberg
:> isn't recognised because it's not put on the same spreadsheet to
: show
:> to the boss...he or she fails to make the connection...
: This is a usualy thing in extremely stupid companies only. If MS would
: be _this_ stupid - they would not survive.
But they _are_ this stupid! Or actually, not this stupid, because they
push first support calls to the PC system builders. If their crap works
they win. If it doesn't, they don't loose _that_ much.
It's a win-win situation, except for Microsnoft's reputation that
actually shows their true colour.
Right,
MartinS
Martin Str|mberg
: lines of JavaScript could do the most worrying of things...because,
: basically, there was a major cock-up in the JavaScript DLL that
: effectively made a lot of the security simply non-existent...steal
: files straight off a hard drive, website impersonation, "cookie"
: issues and, top of the list, a "buffer overflow" problem that made it
: possible to execute code...
: Now, okay, MS have released a fixed version of the DLL that you can
: download to fix this...but, let's take a step back here...look at the
: resources MS command...look at the criticisms they always know they'll
: come in for...no-one spotted the lack of security? Not one indication
: at all in their testing procedures? Wouldn't this mean that there
: wasn't a single test case of a large, large chunk of the JavaScript
: DLL's security features?
: Hello?!? The JavaScript DLL in their flagship Internet Explorer and
: not even one reasonable test of these security features? They had to
: have users give them "feedback" that it even exists? In short, did
: they do _any_ testing at all on it?
You seem to be missing the fact that Microsnoft happily want to show
how insecure and bad this java-script is (SUN sw).
Of course there wouldn't have been any problem finding the bug if it
had been in a sw. they cared about, like C#-shit or .NET-more-shit.
: In short, and to be fair to MS (they're just the worst...which doesn't
: mean everyone else is flawless by any means) software development
: itself is _all wrong_...it needs a major overhaul because it's
: emphasising all the wrong things...it's encouraging all the wrong
: behaviours...as I say, it's actually patently _asking_ for this to be
: the case..._nothing_ is done in any appreciable way to prevent it or
: avoid it...companies like MS even proudly wear their "we rely on user
: feedback" badges with pride that they send it out the door almost
: _knowing_ it's buggy and then just wait for people to complain...
Yes. Of course it's buggy. They want to de-credit anything
non-Microsnoft.
: Software development is, simply, backwards and retarded...and that's
: the "kind" and "tactful" way to express this ;)...
And who made this the fact it is today?
Right,
MartinS
Martin Str|mberg
: from Office for safety and security?". The answer was - "NO! Our
: company's internal software depends on it heavily".
: People prefer having the feature with security flaws to not having the
: feature at all. By adding more and more DHTML features, MS pleases web
: designers. And as about bugs - people will think on them only after
: :-)
Ha! Let them sort out their viruses, then! It's unacceptable that that
crap-sf go mailbombing me.
Right,
MartinS
Scott Wood
There's a rather blatant selection bias in that survey, though, in that
these are people that already decided to use Microsoft's software. Many
people who place a higher value on security, surprisingly enough, opt for
software which *has* greater security, and thus wouldn't be hanging around
on NTBugTraq.
-Scott
Martin Str|mberg
: Windows. The mere fact of including browser to the OS would not be
I suppose I live in reverse-reality. The only browsers that is
defacto-standard for me i Netscrape and lynx. (I only use Linux
on-line.)
: enough for MS to win. There could be an attitude of "MSIE is in the OS
: but sh*t, download Netscape for a Real Browser". This did not occured
: too, surely due to MSIE being technically superior to NN.
You must be kidding!
1. There's no Internet Exploder (recent version) for me. (See above.)
2. Even if there was one I wouldn't be crasy to be trying running the
crap. Microsnoft have time onto time showed they don't care a shit
about security. I _won't_ have their crap-ware inflict my system.
: I also had some experience with Java once around 97. The thing which
: Sun did to JDK1.1 vs. JDK1.0 (throwing away the backward compatibility
: and requesting re-coding of existing code) is really an atrocity. Even
: the despisable MS did not do this. :-)
You guess! They would take any oportunity to break Java!
: Monopoly means - standards. So, if the monopoly provides good
No. It means volatilie standards. Just look at how Microsnoft is
trying to turn well know web standards to it's own doing.
: Sorry. w2k had no this bug for sure. Maybe previous versions had.
: Anyway, let's see:
: - Paul claims old NTs judge the fact of CMPXCHG8 presense by
: _generation_ and not by feature bits.
: - nevertheless, Intel and AMD never produced any P6 CPUs with no
: CMPXCHG8 and no feature bit set, so, NT worked fine on all these CPUs.
: - thus, NT had a flaw of not following the Intel's document
: exactly, and making a wrong assumption. Nevertheless, the flaw never
: occured on Intel CPUs. It did not reduce the NT's quality.
: - you see - the x86 standard is _proprietary to Intel_. So, x86
Your mistaken there!
: clonemakers must match Intel in all documented _and undocumented_
: details. Otherwise, the market will not accept them.
: - Cyrix would implement CMPXCHG8 instead of loudcrying on MS's
: problems.
So why did Intel add that tiny buit telling if CMPXCHG8 was availble
or not to CPUID? Semed utterly unecessary in your view.
: If NT would not run on _Intel_'s CPU - the other talk, hardware
: vendors - if the same "rank" of Big Guys - are more trustworthy then
: MS, so, in this case, the public opinion would be to blame MS.
Yes. The public opionion _is_ blaming MS.
: Cyrix did nothing correctly. They just did the thing doubtful, not
: explicitly banned by the docs, but not as in Intel's product.
: The correct implementation (Intel-compatible) would be - either
: implement CMPXCHG or do not claim to be P6.
Again what that CMPXCHG8 bit in CPUID for?
It can't be for verifying that CMPXCHG8 is available, can it? It must
be for "I'm not running an Intel CPU". Why did Intel (or MS) so
mistakennly label it the CMPXCHG8 bit then?
: Remember - this is a proprietary CPU (note! all other CPUs are
: proprietary, either manufactured by single vendor, or designed by
: single vendor and manufactured by several others under explicit
: license, accompanied by complete internal documentation) by Intel.
: So - what is "correct"? Doing by violating some thing forgotten in
: Intel documents, but used in reality? Or doing by cloning the Intel's
: _implementation_ one by one?
: Producing x86-compatible CPUs without explicit license from Intel is a
: risky business (and also doubtful a bit in terms of intellectual
: property), you see. So is producing any El Cheapo clones - Cyrix and
: especially UMC (which started the thread) is this for sure, so was AMD
: till they restructured the execution units in Athlons.
So Intel could document what-the-fuck-it-wants and claim this is our
CPU, even if every op mapped to "xchg %eax, %eax". Then the cloners
had to implement _all_ that IA86 behavour from what the chip really
does.
1. That could perhaps be ok, if Intel didn't say this is the behaviour
of our CPU (which I don't think they did. They said this is _the_
_instruction_ _set_ of out CPU).
or
2. Again why that CMPXCHG8 bit? That was just to prevent cloners to
make "real" (as in Maxim's real) clones of the CPU, or what?
Did Intel _ever_ say that P6-compatibles must implement CMPXCHG8? I
don't think so, Again that CMPXCHG8 bit, tells us that they _didn't_.
: Blaming the major vendor (MS) in ignoring El Cheapo clones is a bit
: strange. "Get yourself a genuine real CPU" - can be the answer. Or
: better - "is Cyrix is on our hardware compatibility list?".
Look here. Either you think that Intel is always right, no matter the
strange (in)compatiblities they might invent.
If so, we don't have much to discuss. (You're a lost cause. How much
are you paid by Intel? (Just kidding!))
If not, you need to sort that P6 without CMPXCHG8 (which _isn't_
present according to CPUID) issue out.
: Let's see the Rowenta washing vacuum cleaners or Epson jet printers.
: Try to claim "you device is bad! I used it with El Cheapo washing
: liquid or ink cartridge, and it failed!". They will immediately
: denonce this claim. Cyrix is to Intel as Chinese El Cheapo cartridge
: producer is to Epson or Novomoskovsk detergent factory is to Rowenta
: (well, the latter one licensed Tide IIRC).
Thes might be. But if so Intel is LYING in there publicly disclosed
documents. (IANL, but that would surely goad me on if I was.)
: Second, what is "bug" in MS? The decision, again risky, again not
: contradicting the docs, and not causing problems on GenuineIntel?
But it is contradicting the docs. That's the point!
: Third, the market reality. For consumers, if Cyrix and Windows are
: incompatible - this is Cyrix's fault, since Intel is compatible, and
: MS is larger then Cyrix. MS is the leader, while Cyrix is Intel's
: follower. And people know this.
Fuck market! That'll only bring us shit. Look at what we got now. One
OS that only is good for games. No wonder Microsnoft is trying to
penetrate _game_ _consol_ market. That's what it's good for.
Right,
MartinS
Martin Str|mberg
: Just because I say I"m a ham sandwich doesn't mean I want to be assaulted by
: mayonnaise.
Here's some mayonnaise for you (in case you'd need it).
Right,
MartinS
Martin Str|mberg
: nomai...@deinmeister.de (TS) wrote:
:> >Are you aware that Windoze has code in it that incorrectly detects for
:> >the presence of the CMPXHG8 instruction and goes ahead and uses it based
:> >to lie about their support for this instruction to get Windows to work
:> >correctly (thus making the data reported by the CPUID instruction not
:> >100% reliable
:>
:> Sounds interesting. Is there a more detailed description of this
:> behaviour?
: There was a description on Cyrix and Centaurs old CPU sites. But VIA
: doesn't seem to be maintaining that info any more. In the end Cyrix
: and Centaur said that they *did* support the CMPXCHG8 instruction even
: though they did not, and both reported 6th generation compatibility --
: combined with the "Is this an Intel CPU" logic in Microsoft's code,
: this somehow got it to conclude that they did *NOT* support the
: CMPXCHG8 instruction (which was true.) We could draw up a table and
: try to reverse engineer what the MS logic might have looked like, but
: I think the point is made.
I'm confused. Are you saying that those CPUs claimed CPUID CMPXCHG8
bit set? _And_ still did not _support_ it?
Right,
MartinS
Martin Str|mberg
: of infallible godhood or anything...in fact, if anything, it's more
: likely to mean "we've hard-wired hacks and hardware only compatible
: with Windows 95 into the system...if you try using something other
Yes. To me it means _really_ look into the compabily of ordinary PC
software. So I can use it in Linux.
So "Designed for Windows XX" means "crap" until proven otherwise,
Right,
MartinS
Martin Str|mberg
: 1. Would you accept loosing the flexibility of VBA macros to customize M$
: applications for some degree of security?
Probably, as I don't use VBA macroes. That sounds like the highway to
breaking Microsnoft crap.
: 2. Is it acceptable that VBA macros have no restrictions on access to the
: system and would prefer this be corrected even if it requires VBA to be
: removed?
See 1.
: 3. Another question even more pro security and minimizing the positive
: effects of VBA.
See 1.
Right,
MartinS
Chewy509
"David J. Craig" wrote in message...
> 1. Would you accept loosing the flexibility of VBA macros to customize M$
> applications for some degree of security?
No, many Access databases that integrate with Word/Excel rely on VBA...
Removing VBA would kill Office integration features...
> 2. Is it acceptable that VBA macros have no restrictions on access to the
> system and would prefer this be corrected even if it requires VBA to be
> removed?
My personal opinion is that all macro's should be sand-boxed, with
restrictions set by the user (like ActiveX in IE5/6).
> 3. Another question even more pro security and minimizing the positive
> effects of VBA.
Pro-security is good, but can also kill a product, so a balance between the
two must be sort, and something like in my answer to 2 would be appropriate.
Chewy509...
ByrdKernel
> Here's some mayonnaise for you (in case you'd need it).
Thanks, Martin. Never let it be said that you didn't give me anything. :) hehehe
Marven Lee
Beth wrote...
> Microsoft's "BubbleWorld" is a very interesting place indeed (the
> disclaimer of responsibility in the EULA is just a way not to get
> sued, it's not a statement of reality, Maxim ;)...
Talking about BubbleWorlds, ever tried FS2002?
Microsoft delayed the release of FS2002 to give the British government
enough time to relocate the Millenium Dome from it's current position in
Greenwich to a site across the river from the Houses of Parliament,
thereby allowing London to conform to Microsoft's View of Reality (TM).
Unfortunately the British government did not have time to relocate the
Dome. This one mistake has cost the taxpayer's millions, it is said that
the non-conformance of the Dome to Microsoft's View of Reality (TM) was
the primary reason for the poor attendance rates and the final closure
of the doomed Dome.
It is widely known that Microsoft is the official supplier of maps to the
US Navy. We can see evidence of this when during the Balkan conflict
the Chinese Embassy in Belgrade was hit by an air-to-ground missile
from a US aircraft. The Chinese had not asked Microsoft for permission
to locate the Embassy in that particular area of the city. A spokesman
for Microsoft said in a press conference, "The Chinese Embassy quite
clearly did not conform to the Microsoft View of Reality (TM) specification.
If it had done so they would have been allowed to place the official, neon-lit
View of Reality (TM) billboard on top of the Embassy's roof, visible to all
US navy aircraft flying overhead."
The Chinese Government refused to comment on the issue.
Marv
Maxim S. Shatskih
generation CPU,
> it assumes the presence of the CMPXCHG8B instruction, which is *NOT*
a valid
"Have seen". w2k is not such.
Also, if Paul talked about NT3.x - they are very old, much older then
P6. P6 appeared nearly at the same time as NT4, and, if you will not
count unsuccessful PPro - a year after NT4. Clones were later for
sure.
> Yes. Microsoft often breaks things for marketing purposes, and they
have for
> years. Remember the old phrase, "DOS ain't done till Lotus won't
run"?
Anti-monopoly laws fit exactly this. Have you read Jackson's ruling?
Anti-monopoly law starts when:
- a) the company is a monopoly. MS was a monopoly with DOS.
AND
- b) the company uses predatory business practices, i.e. the business
practice directed not to revenue, but to hurting a competitor. Making
DOS deliberately incompatible with Lotus (who was a competitor) is
exactly this.
Surely, this occurs only if _deliberately_ is proven. If Lotus used
undocumented stuff which ceased in next DOS, and thus became
incompatible with next DOS - sorry, but MS is clean. Removing the
undocumented things is not "deliberately". They are considered
internal details - yes, encapsulation. That's why MS warns against
using undocumented things. They will possibly cease to exist in next
version, and MS will not be legally to blame. The only solution will
be to rewrite the product for next OS.
Not so with Cyrix, who is not MS's competitor.
> MS can disclaim this responsibility if they want, to try to avoid
lawsuits, but
> it's common sense...they wrote it. If they wrote it wrong, it's
their fault.
And if you agree that they are not responsible - then they are not
responsible.
> Are you a lawyer now
My wife is a future one :-) and I know what she studies.
> an automatic signal that you ARE an M$ rep. I think it's almost a
given that all
> employees must earn their MBA and law degree before they ever learn
C++.
Not necessary for any programmers.
> Efforts to compete against M$ fail mostly because the company will
do anything
> illegal, immoral, unethical, or just plain wrong to win.
Ha-ha-ha! So what? Also be "illegal, immoral, unethical, or just plain
wrong"? Business often uses the good old Jungle Law. :-)
> So now that you've described your ivory tower of Microsoft's
innocence and
> perfection, you're attacking someone else's? HA!
The word "moral" is not so suitable for business.
> Your use of the term "respect" instead of "popular" makes me believe
you DON'T
> just believe it's market share. You actually think Microsoft should
people
> should bow and scrape in M$'s presence.
No. Major vendors - Intel, MS, Seagate and such - are just much more
respectful then minor ones.
> Business takes the bottom line into account. There are no rules,
thanks to
> companies like Microsoft who blew the rest of corporate "ethics"
away in the '80s
> and '90s.
Do not go in for money-related cheating or illegal affairs. The other
is not immoral in business.
In one of these messages, I described Sun/JavaSoft behaviour. Much
more atrocious then MS's. This is a reality.
>Because of bastards like them, no small players who actually make a
> profit can survive very long without getting bought out
Not bad anyway. IBM bought Lotus. For whom is it bad? For
shareholders? They got their Lotus stock replaced with IBM one. For
Lotus Notes users? Again doubts.
When a large company buys a small one, this only means - the small
one, while making technically good products, is too weak in marketing
to survive.
> No...whether something WORKS determines compatibility. You're
really going nuts
> on this marketing angle, aren't you?
Windows works. It is not _this_ unstable for millions of people to use
it. People are _satisfied_ with Windows (and especially NT) stability
level.
Otherwise, Windows would die ago, and OSes like OS/2 or BeOS (much
better architected and designed then Win9x) replacing it.
> And it's also wrong. Marketing force means consumers get screwed,
because they
> get sold something that is usually inferior, both in compatbility
and quality.
As you can understand, this can occur only if there is nothing
superior :-)
Note: Linux is free! It is much cheaper then Windows, not to say NT!
Now note the percent of Linux on desktops. Not so large.
Max
Maxim S. Shatskih
they
> push first support calls to the PC system builders. If their crap
works
> they win. If it doesn't, they don't loose _that_ much.
Yes. Their _first_ question is - "is your PC on hardware compatibility
list"? If not - the talk is over.
The attitude of "Yes, we do not support our OS running on such
machines. If it runs by mere luck, then good, if not - then it is not
our fault".
I know people from MS Russia - they were _taught_ to respond to
customer problems this way.
BTW - I can tell you some most important points of MS Russia's
marketing activity. Know people there from some COM-related seminars
they organized for developers in Moscow.
a) Dealing with IT departments of country's largest structures with
the "you understand - the larger the vendor, the most trustworthy it
is. We are the largest vendor. Thus, we are most trustworthy"
attitude.
A good marketing, given the USSR traditions of seriosity, derived from
Stalin's paranoia. The IT director (or any other boss) of large
Russian structure usually has very strong attitudes of "serious" and
"unserious". If you will say him on Linux - he will respond with
something like "students? amateurs? are you sane? you really suggest
running the structure of THIS importance on amateur software???" -
like this attitude. "Amateurs cannot produce anything serious, only
Big Names can".
Even if IT director is smart enough to not be bought on this bull,
then his non-IT boss will buy :-). There was a rumour that Yeltzin
have heard the Hewlett-Packard name. Now you can understand what
desktop computers were used in all Russian companies considering
themselves "serious". :-)
On the other hand, this attitudes starts to work against MS. Some
Russian bosses consider MS OSes to be dangerous from this point of
view - "American company? Any guarantees that CIA did not force MS to
put backdoors to OSes?". So, they switch to FreeBSD. Linux is again
overboard as "amateur" software (well, comparing to FreeBSD it is
possibly 100% true in all cases).
I'm writing a PhD thesis now. My professor told me to include such
"information national security" attitudes there, since the other
professors (on whom my thesis is dependant) love such attitudes.
:-)))
b) Developer education. Not user education, but developer education.
You see - organizations use lots of software developed internally for
their own needs. The software is usually simple and uses VBA macros or
Visual Basic, but nevertheless is important for organization.
Now imagine - if the organization will have all its document
management based on MS products, they will never want to hear on
non-MS solutions.
And not only non-IT organizations. There are lots of small-to-mid
companies who develop solutions for such organizations. Their boss
knows that it is good to be friends with MS, since this means - a bit
re-use of MS's marketing machine for his business (and MS will really
support him, especially if all his products are based on MS software).
Their developers know (from personal experience and seminars) how easy
is to develop the solution (financial app, for instance) in things
like VB or ASP, and if they need something more complex - MSVC is
suitable for any PC programming tasks.
This result in the company producing solutions able to work on MS
platforms only. If you will ask the director about UNIX-based
solution - he will respond as "UUUNIX... any significant market for
it?".
Since producers (and not only demand) have large influence over the
market, the consumers are also start to have pro-MS bias as "the usual
server OS".
This leads to the majority of organizations having MS-based unportable
solutions for their internal software, which is essential for them.
MS pays huge attention to this developer education, I will not be so
wrong if I will tell that 50% of activity in MS Russia is such.
This is MS's business policy. Read MSDN papers and journals to see
another example of it.
The result. Largest stock exchange in Russia. Yes, puny compared to
American ones, but hey, the country is smaller economically. They
_moved from FreeBSD to IIS_ on their webservers. Really so. According
to what I know, the idea of such a move was _from programmers_ and not
from management. Their site - www.rts.ru - bears a logo of "Powered by
MSSQLServer and IIS". This is because ASP is convinient, WMI too, MSVC
too, COM too, ATL too, and there is an organization to maintain
seminars telling people on how convinient and usable these products
are! Moving away from them to lesser usable stuff, web scripting
without a GUI debugger, badly standartized object libraries, lack of
usable C++ IDE and worse documentation - they do not want this, and
will convince their bosses that "switching away from MS tools will
double the development cost".
Even CodeRed/Nimda (the most major bugs in MS's history) have no
significant effect over this, only temporary one. Everybody knows that
MS will fix these bugs.
Your (and Beth's) suggestion that I'm MS spokesperson is funny, and
only talks that you never talked to real MS's people.
BTW - Sun's marketing in Russia is nearly the same (though weaker) +
exploiting the existing anti-MS bias.
In fact, the only company who feels well in this is Oracle. Oracle
earned to be trustworthy very long ago in early 90ies, before MS had
any significant server software. So, Oracle if used very often, and
"Oracle database + all other tiers on MS technologies" solutions are
often. In fact, MS's technologies support Oracle very well.
Now let's look on small-to-mid businesses. They often have weak IT
stuff. Chances for Linux to get there are very low. Imagine a
secretary girl (or even a non-IT lawyer, accountant, HR department
psychologist or even top manager) who can handle the Windows PC.
He/she get accustomed to this PC. Will he/she want to study KDE or
Gnome? For what? They are not computer-related persons, and use
computer just for email and Word. For many of them, computers are just
not interesting.
In fact, the mere fact of _two UIs_ in Linux will be irritating for
them. The fact that they are deeply customizeable - too. They do not
want to teach redundant stuff, they want all computers to be the same.
For them - "I know Windows and Word" - means - "I know computer". You
can understand the amount of resistance to variable UIs among them.
They will ask - "why not still use standard Windows?". The mere idea
will be for them as - "let's replace a dashboard on your car!". They
do not interested in Linux community (or even do not know on them) and
supporting them.
> It's a win-win situation, except for Microsnoft's reputation that
> actually shows their true colour.
Business companies are not Mother Theresas. Neither MS nor Sun. Face
the reality.
Max
Maxim S. Shatskih
get the
> answers that you want. Whoever wrote the survey (probably Russ, I
imagine)
> favors the functionality of VBA macros, and wanted it to come out
"no".
No. This was around May 99. After a serie of VBA holes, Russ asked
NtBugTraq - "what is your wish - would MS remove all this
functionality from their products?".
About 70 responses followed, the majority (around 80%) was "no", some
responded "yes".
I cannot tell that Russ has pro-MS bias. He is unbiased.
Max
Maxim S. Shatskih
customize M$
> applications for some degree of security?
> 2. Is it acceptable that VBA macros have no restrictions on access
to the
> system and would prefer this be corrected even if it requires VBA to
be
> removed?
> 3. Another question even more pro security and minimizing the
positive
> effects of VBA.
My personal opinion (here I'm not trying to give the general picture
of things):
- VBA must be completely off by default, or even by installation
package choice.
- for those who rely on these macros, enable them explicitly.
Max