> > Either MS wanted confusion, or they just bugged the software > to not know what is what when determining if the software > would work. Hey, if MS does not certify the software, then > it may not or will not run according to MS. If you do not > pay me, we will not say it works.
Windows Logo (or more lately Works-With-Windows) or the predecessor program WHQL were all efforts to ensure that a given hardware (and its drivers), and more recently a given software had been verified to work with a given version of Windows. No big deal. It's a selling point. It's like insurance. You probably don't really need it (Mr. Corporate Purchaser), but a relentless marketing campaign has ensured that you'll be given grief if something _does_ go wrong and it turns out you didn't buy the insurance. "What?!? Our gimmelfripps servers are down and you _didn't_ buy certified software?? You're fired!" :-) Our company often pursues Windows Logo (as we did with the previous WHQL), because some big corporate and institutional customers demanded it. (By the way, Windows users are only a portion of our customer base.) However, the testing and the cost (not just money, but the time of engineers and others) ensures that we don't bother to seek the certification for every release. We just tell our Windows-using customers "Installing this release of Product-X will result in a warning message 'blah-blah-blah' from Windows. That is not a fault. Just click [Continue] to complete the installation. If your organization requires that you install only Windows Logo certified hardware and software, then you should remain with version yyy of Product-X until our next Windows-Logo-Certified release." Because we are a security-and-crypto products company (my division makes HSMs) we have the same arrangement with respect to FIPS 140-2 validation and with Common Criteria EAL, both of which require time and expense (FIPS, most of a year, and CC-EAL more than a year-and-a-half) just to work through the bureaucratic and testing hoops. So we often let two or three minor releases of a product go past before we submit a newer version for validation/certification. This means that many customers are using versions that we designed 4 years ago, developed 3+ years ago, released two-and-a-half years ago, and received validation certificate(s) a year ago. In that case, choosing to use only validated products means those customers are always living in the past. :-) One place where this can be a problem, in the security world, is if the industry discovers a vulnerability in a widely used component and that component must be updated or eliminated from products. The customers who _don't_ demand FIPS or CC-EAL validated products are able to update immediately and feel secure again, while those who are tied to the most recent validated version are stuck until the next time one of our releases emerges from the lengthy validation process. The same occasionally happens with WHQL or Windows Logo'd stuff. "You can have the version with the vulnerability fixed, today, or you can wait several months while we jump through hoops to have the updated version certified." That's life. Hell, some people deliberately look for computers that say "Intel Inside". Go figure. The "answer", I think, is for open source / free software like OOo to anticipate the problem and have the installer explain to the customer that they are about to see a marketing-related message from Windows, and they can safely ignore it. In their place, I'd even write up a big explanatory web page and include a link within the installer so that customers can read some reassurance if they feel the need. - Kevin Cheers, The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
