On Mon, Jun 2, 2008 at 9:43 AM, Tzachi Dar wrote:
> WHQL itself is not forced by MS or by anyone else. On the other hand, if you
> want to be
> in the windows market you should have it. No one calls it “free will” that
> is true.
I would just like to add, again as an end-user, that if a product
flashes the “designed for Windows” logo on its box, I expect it to
work for at least a couple of Windows versions. I even expected many
products to work with XP-64, which was seemingly just plain silly of
me.
For some odd reason, many end-users blame MS when their devices stop
working after upgrading the OS. I, for one, find that quite a bit
unfair.
WHQL should mean something. It should imply that a device doesn’t crap
out when faced with more than 4GB memory under Windows 2003 (hello
again nVidia). It should also imply that the manufacturer has a
comitment towards keeping the device reasonably functional with
upcoming versions of Windows. (within a reasonable timeframe – I no
longer expect any support for ISA devices at this point…) E.g.
Hauppauge finally released 64-bit drivers for the TV tuner I have,
except it turns out there are two revisions of that product, and mine
is the slightly older one… They do not deserve any Windows logos at
all.
Currently, WHQL is in danger of being washed out. The bar is set much too low.
The new policy, at the very least, forces some of the idiots out there
to remove their “if osversion > 6.0 raiseHell();” statements in their
install scripts. That alone will be helpful to many users.
I hope they also enforce this policy for some of their other
logos/certifications.
–
Rune
> For some odd reason, many end-users blame MS when their devices stop working after
upgrading the OS. I, for one, find that quite a bit unfair.
Sorry, but who has changed the API implementation in such way that even *MSFT-certified* drivers (which implies they are written the way required by MSFT and don’t rely upon hooking, undocumented API calls, internal kernel structures, etc) stopped working on the newer OS version??? Although I would accept your argument if you were speaking about “unsupported” drivers, I just cannot accept the same logic when applied to MSFT-certified ones…
It should also imply that the manufacturer has a comitment towards keeping
the device reasonably functional with upcoming versions of Windows.
…or, probably, it should work the other way around, so that MSFT has a commitment of not breaking drivers
that are written “properly” and don’t rely upon anything “unsupported” ??? Are you sure you understand what you are talking about???
Anton Bassov
“Rune Moberg” wrote in message news:xxxxx@ntdev…
> I would just like to add, again as an end-user, that if a product
> flashes the “designed for Windows” logo on its box, I expect it to
> work for at least a couple of Windows versions. I even expected many
> products to work with XP-64, which was seemingly just plain silly of
> me.
>
So far so good, that is a silly assumption.
> For some odd reason, many end-users blame MS when their devices stop
> working after upgrading the OS. I, for one, find that quite a bit unfair.
Here I am not understanding anything about what you saying. Is this not
contradictory ? Who else are they to possibly to blame if the developer went
through the pain of even having its product certified ? I am also getting
the idea you do not
understand much of what you are talking about.
//Daniel
On Mon, Jun 2, 2008 at 11:00 AM, wrote:
> Sorry, but who has changed the API implementation in such way that even MSFT-certified drivers (which implies they are
The cert requirements are set too low IMO.
E.g. 32-bit XP drivers are not required to support PAE. The result is
that ForceWare versions newer than 79.11 do not work well with 32-bit
Windows 2003 on machines with 4GB memory or more. Early versions of
8x.xx would BSOD and newer versions won’t let you launch apps that
employ Direct-X.
I’m sure there are other similar issues.
> …or, probably, it should work the other way around, so that MSFT has a commitment of not breaking drivers
> that are written “properly” and don’t rely upon anything “unsupported” ???
…which in turns means MS will be barred from introducing new features
in new versions of the OS. It seems both the audio and graphics driver
models changed significantly with Vista? (or why else are Creative
Labs and nVidia bitching?)
For now though, it seems MS simply want to know which WHQL certified
drivers will break with the next version of Windows. Nothing really
sinister about that. And various OEMs, like my hateful two, will be
forced to at least install Windows7 at an early juncture. Which I
really, really appreciate.
–
Rune
“Rune Moberg” wrote in message news:xxxxx@ntdev…
> The cert requirements are set too low IMO.
Which according to you is the fault of the developer ?
>> …or, probably, it should work the other way around, so that MSFT has a
>> commitment of not breaking drivers
>> that are written “properly” and don’t rely upon anything “unsupported”
>> ???
>
> …which in turns means MS will be barred from introducing new features
> in new versions of the OS. It seems both the audio and graphics driver
> models changed significantly with Vista? (or why else are Creative
> Labs and nVidia bitching?)
>
No that’s not about introducing new technologies, it’s about deprecating
existing ones.
//Daniel
On Mon, Jun 2, 2008 at 11:21 AM, wrote:
> “Rune Moberg” wrote in message news:xxxxx@ntdev…
>> For some odd reason, many end-users blame MS when their devices stop
>> working after upgrading the OS. I, for one, find that quite a bit unfair.
>
> Here I am not understanding anything about what you saying. Is this not
> contradictory ? Who else are they to possibly to blame if the developer went
> through the pain of even having its product certified ? I am also getting
Certified for XP did not mean that the thing would work under the next
Windows version (Vista). It didn’t even imply compatibility with
Windows 2003, which AFAICT is pretty darn identical to XP. (yet many
installers are version dependant and freak out for no good reason)
Often the reason is just sloppiness on the software vendor’s part. For
hardware the reason is often that the hardware OEM isn’t much bothered
supporting a two year old hardware device (or even a three month old
one if they’ve since moved to a new generation).
So yes, the developer went through the “pain” of having their product
certified for the then-current version of Windows. This doesn’t
translate to the developer making a comitment of supporting said
device two or three years into the future. So when Vista arrived…
Lots of angry users out and about waving old dead hardware around.
–
Rune
On Mon, Jun 2, 2008 at 11:35 AM, wrote:
> “Rune Moberg” wrote in message news:xxxxx@ntdev…
>>
>> The cert requirements are set too low IMO.
>
> Which according to you is the fault of the developer ?
That one is MS’ responsibility. But if you want to put a spin on it, I
guess a case could be made that developers are to be blamed since they
probably lobbied for low reqs to start with.
>> …which in turns means MS will be barred from introducing new features
>> in new versions of the OS. It seems both the audio and graphics driver
>> models changed significantly with Vista? (or why else are Creative
>> Labs and nVidia bitching?)
>>
>
> No that’s not about introducing new technologies, it’s about deprecating
> existing ones.
I.e. you are advocating the view that Vista should’ve kept the old
audio driver framework around, and add even more confusion into an
already confusing situation? (who is going to educate the end-users on
the differences?) To what gain? To make sure Creative Labs could
continue to churn out third-level device drivers?
–
Rune
As the OP, thanks for all the info about linux vs windows. Loved reading
it… (really did, for real)
The thread was intended to give a ‘heads up’ to anyone that was looking
to get a
WQHL sig while seeking a time frame for when this new policy was to be
fully implemented.
Thanks for the suggestion Mark, as noted in a previous post.
For most of the comments here, I don’t think anyone of a sane mind
objects to
failing a few test on a beta, it’s not a big deal. I’m just wanting to
know when the lack of a failed
test will become an issue. That is all I wanted to know (when will the
beta be released), estimates.
Matt
> So yes, the developer went through the “pain” of having their product certified for the
then-current version of Windows. This doesn’t translate to the developer making
a comitment of supporting said device two or three years into the future
Developer of certified driver is not meant to have any additional commitment - he has already expressed his commitment by meeting certification requirements… Basically, certification is just a contract between developer and MSFT, saying that, as long as driver uses only documented features and “supported” techniques, MSFT guarantees not to break a given driver in the future OS releases. This is the primary reason why driver writers want their drivers to get certified, in the first place - otherwise, they may have to provide updates to their drivers almost on daily basis the way vendors of AV and other “unsupported” software do.
Therefore, if certified driver breaks in the next OS release it means that MSFT just violated the contract.
However, for the reasons better known to yourself, you blame it on developers…
Anton Bassov
A bucketful of thanks and a hearty bravo to Mr. Edwards for helping keep the forum on track!!
I hereby grant you 10 additional karma points.
Mr. Moberg appears to be confusing WHQL Certfication with a quality-assurance test, which WHQL certification is most certainly NOT. WHQL Certification is about program compliance. It has very little, and in many cases absolutely nothing, to do with driver quality.
There are no statistics that I have ever seen that indicate that drivers that can pass the WHQL tests crass less frequently than those that don’t pass the WHQL tests.
To some previous assertions: The major compatibility issues in Vista, ASIDE from changes in driver models and similar major revisions, haven’t been with the kernel-mode drivers AT ALL. They’ve been with associated services and control panel applets.
Peter
OSR
There is a subthread in here that is actually relevant to NTDEV NT
developers.
The problem, in my opinion, with this apparent change in policy:
specifically a (rumoured?) change adding a requirement to test beta OS
releases in order to obtain logo’s for current OS releases, is that for some
of us out here, supporting new OS releases *AT ALL* is a major scheduled
work item. From MSFT’s perspective, and from those who are not in the
platform business, it is no big deal to run a crappy beta on some compatible
enough hardware to actually get test logs. For others, this is a near
crippling new activity that I can assure you has not been and will not be
easy to work into existing schedules.
On Mon, Jun 2, 2008 at 10:20 AM, wrote:
>
>
> A bucketful of thanks and a hearty bravo to Mr. Edwards for helping keep
> the forum on track!!
>
> I hereby grant you 10 additional karma points.
>
>
>
> Mr. Moberg appears to be confusing WHQL Certfication with a
> quality-assurance test, which WHQL certification is most certainly NOT.
> WHQL Certification is about program compliance. It has very little, and in
> many cases absolutely nothing, to do with driver quality.
>
> There are no statistics that I have ever seen that indicate that drivers
> that can pass the WHQL tests crass less frequently than those that don’t
> pass the WHQL tests.
>
> To some previous assertions: The major compatibility issues in Vista, ASIDE
> from changes in driver models and similar major revisions, haven’t been with
> the kernel-mode drivers AT ALL. They’ve been with associated services and
> control panel applets.
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
Mark Roddy wrote:
There is a subthread in here that is actually relevant to NTDEV NT
developers.The problem, in my opinion, with this apparent change in policy:
specifically a (rumoured?) change adding a requirement to test beta OS
releases in order to obtain logo’s for current OS releases, is that
for some of us out here, supporting new OS releases *AT ALL* is a
major scheduled work item. From MSFT’s perspective, and from those who
are not in the platform business, it is no big deal to run a crappy
beta on some compatible enough hardware to actually get test logs. For
others, this is a near crippling new activity that I can assure you
has not been and will not be easy to work into existing schedules.
Mr. Roddy, there is nothing rumored about it. Go to this MS link (PDF)
and view page 36.
Do remember, all test on the beta platform can fail, it doesn’t
matter… You just have to submit the failed logs.
Matt
Thanks for the confirmation. I understand fully that ‘all tests can
fail’. The problem for those of us where just booting a new OS on our
platform is a significant scheduled work item is just that: it is a
significant scheduled work item.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matt
Sent: Monday, June 02, 2008 11:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Rumors? Time table for Windows 7 Beta
Mark Roddy wrote:
There is a subthread in here that is actually relevant to NTDEV NT
developers.The problem, in my opinion, with this apparent change in policy:
specifically a (rumoured?) change adding a requirement to test beta OS
releases in order to obtain logo’s for current OS releases, is that
for some of us out here, supporting new OS releases *AT ALL* is a
major scheduled work item. From MSFT’s perspective, and from those who
are not in the platform business, it is no big deal to run a crappy
beta on some compatible enough hardware to actually get test logs. For
others, this is a near crippling new activity that I can assure you
has not been and will not be easy to work into existing schedules.
Mr. Roddy, there is nothing rumored about it. Go to this MS link (PDF)
and view page 36.
http://download.microsoft.com/download/d/e/1/de1e0c8f-a222-47bc-b78b-165
6d4cf3cf7/WLP-Policies_03-21-08.pdf
Do remember, all test on the beta platform can fail, it doesn’t
matter… You just have to submit the failed logs.
Matt
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Well my reading of that is for desktop systems, and perhaps devices, but
fortunately not server OS’es. With the number of custom server’s out there
this would become an unacceptable pain for many firms if Microsoft was to do
this.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Matt” wrote in message news:xxxxx@ntdev…
> Mark Roddy wrote:
>> There is a subthread in here that is actually relevant to NTDEV NT
>> developers.
>> The problem, in my opinion, with this apparent change in policy:
>> specifically a (rumoured?) change adding a requirement to test beta OS
>> releases in order to obtain logo’s for current OS releases, is that for
>> some of us out here, supporting new OS releases AT ALL is a major
>> scheduled work item. From MSFT’s perspective, and from those who are not
>> in the platform business, it is no big deal to run a crappy beta on some
>> compatible enough hardware to actually get test logs. For others, this is
>> a near crippling new activity that I can assure you has not been and will
>> not be easy to work into existing schedules.
>>
> Mr. Roddy, there is nothing rumored about it. Go to this MS link (PDF) and
> view page 36.
>
> http://download.microsoft.com/download/d/e/1/de1e0c8f-a222-47bc-b78b-1656d4cf3cf7/WLP-Policies_03-21-08.pdf
>
> Do remember, all test on the beta platform can fail, it doesn’t matter…
> You just have to submit the failed logs.
>
> Matt
>
Beginning with the release of the first beta of the next operating system,
all Windows Vista client and Windows Server 2008 submissions must include a
complete CPK with test logs for the new beta OS. The test logs generated
from the beta OS are not required to pass. Issues with hardware, system BIOS
or drivers must be investigated and resolved by partners prior to the launch
of the logo program for the new OS.
Maybe it is just me, but that seems to include W2K8.
On Mon, Jun 2, 2008 at 11:09 AM, Don Burn wrote:
> Well my reading of that is for desktop systems, and perhaps devices, but
> fortunately not server OS’es. With the number of custom server’s out there
> this would become an unacceptable pain for many firms if Microsoft was to
> do
> this.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
>
> “Matt” wrote in message news:xxxxx@ntdev…
> > Mark Roddy wrote:
> >> There is a subthread in here that is actually relevant to NTDEV NT
> >> developers.
> >> The problem, in my opinion, with this apparent change in policy:
> >> specifically a (rumoured?) change adding a requirement to test beta OS
> >> releases in order to obtain logo’s for current OS releases, is that for
> >> some of us out here, supporting new OS releases AT ALL is a major
> >> scheduled work item. From MSFT’s perspective, and from those who are not
> >> in the platform business, it is no big deal to run a crappy beta on some
> >> compatible enough hardware to actually get test logs. For others, this
> is
> >> a near crippling new activity that I can assure you has not been and
> will
> >> not be easy to work into existing schedules.
> >>
> > Mr. Roddy, there is nothing rumored about it. Go to this MS link (PDF)
> and
> > view page 36.
> >
> >
> http://download.microsoft.com/download/d/e/1/de1e0c8f-a222-47bc-b78b-1656d4cf3cf7/WLP-Policies_03-21-08.pdf
> >
> > Do remember, all test on the beta platform can fail, it doesn’t matter…
> > You just have to submit the failed logs.
> >
> > Matt
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
Don Burn wrote:
Not sure I follow you… This policy is alive and ACTIVE for Server '08
as well as Vista.
Server '08 is NOT excluded here…
Matt
Well my reading of that is for desktop systems, and perhaps devices, but
fortunately not server OS’es. With the number of custom server’s out there
this would become an unacceptable pain for many firms if Microsoft was to do
this.
You are right, well that makes thing real fun since I know of multiplle
system vendors who cannot run the desktop OS period on their hardware. I
guess this does show how stupid WHQL can be.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Mark Roddy” wrote in message news:xxxxx@ntdev…
> Beginning with the release of the first beta of the next operating system,
> all Windows Vista client and Windows Server 2008 submissions must include
> a
> complete CPK with test logs for the new beta OS. The test logs generated
> from the beta OS are not required to pass. Issues with hardware, system
> BIOS
> or drivers must be investigated and resolved by partners prior to the
> launch
> of the logo program for the new OS.
>
>
> Maybe it is just me, but that seems to include W2K8.
>
> On Mon, Jun 2, 2008 at 11:09 AM, Don Burn wrote:
>
>> Well my reading of that is for desktop systems, and perhaps devices, but
>> fortunately not server OS’es. With the number of custom server’s out
>> there
>> this would become an unacceptable pain for many firms if Microsoft was to
>> do
>> this.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>>
>>
>>
>> “Matt” wrote in message news:xxxxx@ntdev…
>> > Mark Roddy wrote:
>> >> There is a subthread in here that is actually relevant to NTDEV NT
>> >> developers.
>> >> The problem, in my opinion, with this apparent change in policy:
>> >> specifically a (rumoured?) change adding a requirement to test beta OS
>> >> releases in order to obtain logo’s for current OS releases, is that
>> >> for
>> >> some of us out here, supporting new OS releases AT ALL is a major
>> >> scheduled work item. From MSFT’s perspective, and from those who are
>> >> not
>> >> in the platform business, it is no big deal to run a crappy beta on
>> >> some
>> >> compatible enough hardware to actually get test logs. For others, this
>> is
>> >> a near crippling new activity that I can assure you has not been and
>> will
>> >> not be easy to work into existing schedules.
>> >>
>> > Mr. Roddy, there is nothing rumored about it. Go to this MS link (PDF)
>> and
>> > view page 36.
>> >
>> >
>> http://download.microsoft.com/download/d/e/1/de1e0c8f-a222-47bc-b78b-1656d4cf3cf7/WLP-Policies_03-21-08.pdf
>> >
>> > Do remember, all test on the beta platform can fail, it doesn’t
>> > matter…
>> > You just have to submit the failed logs.
>> >
>> > Matt
>> >
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> Mark Roddy
>
>please search the achieves for StarForce, so that you will have a chance to
see
how *MSFT-certified* driver may hang the system for any period of time it
wishes,
and still be able to display MSFT logo…
This is because Sony is a loud name, and MS will relax the logo requirements
for loud names.
So was the Intel Application Accelerator IDE stack which had the WHQL logo on
it in year 2002 and crashed the kernel on “Scan for hardware changes” in Device
Manager.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Rune Moberg wrote:
…which in turns means MS will be barred from introducing new features
in new versions of the OS. It seems both the audio and graphics driver
models changed significantly with Vista? (or why else are Creative
Labs and nVidia bitching?)
OK, it is quite clear by now that you have a serious grudge against
Creative and nVidia. We get it, message received. However, you seem to
be entirely ignorant of the fact that there are other people in the
world who are producing drivers.
For now though, it seems MS simply want to know which WHQL certified
drivers will break with the next version of Windows. Nothing really
sinister about that. And various OEMs, like my hateful two, will be
forced to at least install Windows7 at an early juncture. Which I
really, really appreciate.
Again, you seem to believe that every driver writer in the world works
for a multinational conglomerate that can afford to dedicate hundreds of
non-billable man hours enhancing their test laboratory, installing a
schlocky beta operating system that cannot be used for production work,
installing and maintaining another DTM configuration, and generating
test logs that serve no purpose other than helping Microsoft chase down
their own bugs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> This is because Sony is a loud name, and MS will relax the logo requirements for loud names.
No, this is just because technically they don’t violate MSFT requirements - instead of spending 3 secs in DPC routine (which would violate the certification requirement of not spending more than 100 microseconds in a DPC routine), they re-queue a DPC right from the DPC routine, and do it for 3 secs. The net result is exactly the same (from the user’s perspective, the machine just hangs for 3 secs), but once they technically don’t violate MSFT requirements they are still certified…
Anton Bassov