Rumors? Time table for Windows 7 Beta

Current logo requirements state that beginning today, as soon as Windows
7 beta 1 is released, anything to be logo’d for Vista or
Longhorn must include logs for Windows 7 (pass or fail). (plus the 32
and 64 bit requirements)

First of all, to anyone that hasn’t read about this - heads up. Better
think about getting /another/ new machine…

Secondly, does anyone have any sort of time table for this? From my
reading of this, once the
Windows 7 beta goes live (which could be at ANY time) this policy will
be enforced. Finding extra hardware laying around
that could support Vista was problematic enough much less finding
hardware that will support a new beta OS built off of Vista…

Lastly, and most importantly, how should this new OS be abbreviated?
‘W7’ doesn’t sound to cool. ‘W7k’ would refer to the year
7000 but probably wouldn’t be released until the year 9000, and I doubt
Microsoft would go with ‘Wvf’ (windows vista fixed).

Matt

At 10:50 01/06/2008, Matt wrote:

First of all, to anyone that hasn’t read about this - heads up.
Better think about getting /another/ new machine…

Oh great, just what I wanted to make my life easier.

Secondly, does anyone have any sort of time table for this? From my
reading of this, once the

If I had to put money on it, I’d say look to the end of October and
in to November - if possible they do like to make something
significant available to WinHEC attendees.

Mark.

Mark S. Edwards wrote:

Oh great, just what I wanted to make my life easier.
Well, at least now you know about it… I found two articles about this
(one published on 5/29 and the other 5/31) before checking it out
myself. No mention on OSR’s main page… I’m
thinking a lot of people download the Vista and Longhorn logo
requirements prior to this update(3/31) and didn’t think they would
change in this ‘new’ way.

I assume a lot of people are going to have problems here (if they were
unaware of this); first having their boss approve a new system purchase,
then waiting on build and shipping,
then installing Vista or Longhorn only to sit threw a multi-hour
upgrade. Then wait on all the DTM test to run… All combined could set
a project back a few weeks, only learning
of this after their new driver was submitted and rejected because the
beta went live a few nights prior.

If I had to put money on it, I’d say look to the end of October and in
to November - if possible they do like to make something significant
available to WinHEC attendees.

That sounds like a really good guess, but for anyone working off a
deadline - knowing this can pop-up at any time must be nerve racking.
Microsoft really needs to
submit some sort of time frame…

Matt

The very idea of testing drivers on the newer system in order to certify it for the older one is interesting in itself - it looks like the MSFT has invented the brand new concept of “forward compatibility” (shit, even the very phrase itself sounds ridiculous). However, the fact that the newer system is just at Beta 1 stage while the older one is already RTM makes the whole thing orders of magnitude more interesting - in order to prove that the driver is good one has to test it on the system that is, probably, buggy itself. Well done, MSFT…

Anton Bassov

On Sun, Jun 1, 2008 at 6:40 PM, wrote:
> system that is, probably, buggy itself. Well done, MSFT…

As an end-user, I think it sounds brilliant.

The way I understand it, they don’t require your driver to work, they
just want to be told in case it fails. This helps them help you (and
this in turn helps end-users like myself who constantly struggle with
drivers built like minefields).

Additionally, this will force lazy-ass companies like nVidia to start
work sooner, rather than wait for several months after the darn thing
finally ships! Heck, this might even help Creative’s drivers, but I am
not holding my breath.

Allow me to repeat my statement: Brilliant!


Rune

> The way I understand it, they don’t require your driver to work, they just want to be told in case it fails.

…which implies that the problem lies not with your driver (because it works fine with Vista/ W2K8) but with their new OS…

This helps them help you

No, it just helps them to fix bugs in their new OS - it is of no help to driver writer whatsoever, because the problem lies with the OS, rather than with a driver. Basically, what they do is simply requesting driver writer’s assistance in testing their new OS, and present their request in the following form " If you don’t help us with testing our new OS we are not going to certify your driver for Vista/w2k8"…

To be honest, I hardly find the whole thing surprising. First the driver writer community embraced the PatchGuard; then it reluctantly swallowed the request of 64-bit driver signing and refusal of certifying 32-bit drivers that don’t provide their 64-bit counterpart - once MSFT sees that driver writers readily do whatever they are told, it keeps on coming with more and more ridiculous demands. I just wonder what is going to come next…

Anton Bassov

On Sun, Jun 1, 2008 at 8:59 PM, wrote:
> No, it just helps them to fix bugs in their new OS - it is of no help to driver writer whatsoever,

OK. So don’t do it. Wait until the thing gets released, and then
find out about the bug. Good luck getting the thing fixed at that
point.

I fail to see how this approach helps you in any way whatsoever?

> writers readily do whatever they are told, it keeps on coming with more and more ridiculous
> demands. I just wonder what is going to come next…

Given the amount of buggy drivers out there that never should’ve
reached my PC or anyone elses, I fail to muster much sympathy for your
particular plight in this particular case.


Rune

> OK. So don’t do it. Wait until the thing gets released, and then find out about the bug.

Good luck getting the thing fixed at that point.

I am afraid you logic is totally faulty. If it is the *OS* bug, then driver writer should not be thinking about fixing it, let alone applying any modifications to his properly-written source. The only thing he should be concerned about is fixing a bug in *his* code, and if his driver works fine with the existing OS, then it is not buggy - as long as the new OS provides backwards compatibility and does not have any bugs in it, objectively, you should be able to build the driver from the source written for the existing OS, and do it without applying a *single* modification to your source. If the new OS offers some new API features… well, then what on Earth does it have to do with drivers written for the OS versions that don’t provide these features???

Given the amount of buggy drivers out there that never should’ve reached my PC or anyone elses,
I fail to muster much sympathy for your particular plight in this particular case.

Well, luckily, the term “plight” does not really apply to my particular case - these days I am " Linux character", so that the only type of driver I would consider writing for Windows is disk-based FSD (which seems to be the only area in the Windows driver world that it still free from MSFT “recommendations”, “guidelines”, frameworks, etc). I do understand you - indeed, as a Windows user (which must be a tough experience) you must be pretty annoyed with the number of crappy drivers around. However, it has nothing to do with certification. If you don’t believe me, 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…

Anton Bassov

On Sun, Jun 1, 2008 at 10:38 PM, wrote:
> I am afraid you logic is totally faulty. If it is the OS bug, then driver writer should not be

Dude, do you actively try to misread other peoples’ statements?

My logic was this:
- Your driver crash beta 1
- You report to MS
- MS fix bug
- OS gets released without bug

Everybody happy.

The alternative:
- MS test the heck out of the OS, knows nothing about the issues you face
- They release the OS
- Your driver still triggers latent bug in freshly released OS

Sheesh.


Rune

> Dude, do you actively try to misread other peoples’ statements?

My logic was this:

  • Your driver crash beta 1
  • You report to MS
  • MS fix bug
  • OS gets released without bug

Well, apparently, I just got mislead by your statement about “buggy drivers out there that never should’ve reached my PC or anyone elses” - it does not really seem to fit into the above model, does it…

Everybody happy.

To be honest, I don’t see any reason why person X should be happy about being *forcefully* requested to detect bugs that got introduced by person Y, especially if they don’t work on the same product and have no access to each other’s code. Why should you be requested to do someone else’s job, in the first place??? It never occurred to you to think this way???

The alternative:

  • MS test the heck out of the OS, knows nothing about the issues you face
  • They release the OS
  • Your driver still triggers latent bug in freshly released OS

Yes, but what on Earth may OS bugs possibly have to do with driver writers???

Anton Bassov

On Mon, Jun 2, 2008 at 12:24 AM, wrote:
> Well, apparently, I just got mislead by your statement about “buggy drivers out there that never
> should’ve reached my PC or anyone elses” - it does not really seem to fit into the above model,

The crux of the argument is that testing of drivers seem to be a thing
of the past. When a new OS version ships, many OEMs look positively
bewildered. They spend months touting the “it’s a moving target”
mantra, which translates to “we can’t be bothered to do squat” and
when the thing finally ships, they change their tune to “the new OS is
buggy as h—!”. This is known as the “Creative Labs” approach to
driver development. It is not a good thing™.

Drivers are an essential part of the OS. I know this. You know this.
MS can’t test all devices out there. It makes sense that they unload
some of this burden to third party developers, rather than leave the
burden with the end-users like in the ‘good’ old days. And at this
juncture they don’t even expect you to work around their issues. They
just would like to get told about them. (beats the hell out of “MS
changed the APIs, so we can’t be blamed!” whining that nVidia and
Creative perpetrated post-Vista release)

> someone else’s job, in the first place??? It never occurred to you to think this way???

After the release it becomes a moot point, because then the bug can’t
be fixed and you’re left with a potential disaster. Your customers
can’t live without the OS, but they can (in most cases) live without
your device. My Creative Labs soundcard lives in a drawer, not inside
my computer.

The problem is that we’re all part of the same eco-system. A huge
eco-system. Like Forrest Gump said: --it happens.


Rune

> To be honest, I don’t see any reason why person X should be

happy about being *forcefully* requested to detect bugs that
got introduced by person Y, especially if they don’t work
on the same product and have no access to each other’s code.
Why should you be requested to do someone else’s job, in the
first place??? It never occurred to you to think this way???

Anton Bassov

Are you sure that you understand the philosophy of Linux and open
source?
It seems to me that if you are not ready to test other peoples code and
fix their bugs Linux is not the right operating system for you.

Or is it really the word *forcefully* that is your problem.

Tzachi

Tzachi, open source is never about *forcefully*, it’s about the free
will of the community.

The case we discuss here is totally different from Linux.

According to the updated WHQL policy, I *must* test my driver on
Windows 7 beta.

If the tests fail, I won’t be able to submit the driver for WHQL
signature, even if the driver works ok on RTM versions of Windows.

Does it really sound ok ???

I really hope it’s a misprint in the policy document and MSFT don’t
really mean to enforce it.

Tzachi Dar wrote:

cite="mid:xxxxx@mtlexch01.mtl.com"
type=“cite”>

To be honest, I don’t see any reason why person X should be
happy about being forcefully requested to detect bugs that
got introduced by person Y, especially if they don’t work
on the same product and have no access to each other’s code.
Why should you be requested to do someone else’s job, in the
first place??? It never occurred to you to think this way???

Anton Bassov

Are you sure that you understand the philosophy of Linux and open
source?
It seems to me that if you are not ready to test other peoples code and
fix their bugs Linux is not the right operating system for you.

Or is it really the word forcefully that is your problem.

Tzachi


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 athttp://www.osronline.com/page.cfm?name=ListServer

Sorry, I misread the policy, if tests fail on Windows 7 beta it’s still
ok to submit the driver for a signature.

So the situation is not so bad. The only problem is that we are going
to be forced to submit

Windows 7 logs - sort of a community effort, Linux style, only forced
:slight_smile: .

Tzachi Dar wrote:

cite="mid:xxxxx@mtlexch01.mtl.com"
type=“cite”>

To be honest, I don’t see any reason why person X should be
happy about being forcefully requested to detect bugs that
got introduced by person Y, especially if they don’t work
on the same product and have no access to each other’s code.
Why should you be requested to do someone else’s job, in the
first place??? It never occurred to you to think this way???

Anton Bassov

Are you sure that you understand the philosophy of Linux and open
source?
It seems to me that if you are not ready to test other peoples code and
fix their bugs Linux is not the right operating system for you.

Or is it really the word forcefully that is your problem.

Tzachi


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 athttp://www.osronline.com/page.cfm?name=ListServer

> Are you sure that you understand the philosophy of Linux and open source?

It seems to me that if you are not ready to test other peoples code and fix their bugs
Linux is not the right operating system for you.

I just wonder how on Earth Linux and open source may be possibly related to the whole thing…

Probably, I just misread something, but somehow I failed to notice any statements saying that MSFT asks people to review the *code* of Windows 7. I also failed to notice any statements saying that driver writers can submit their *source* for the review by MSFT, so that, in case their code gets accepted, their driver is going to be supported in all future OS releases. I also failed to notice any statements saying that people are allowed to modify MSFT’s code in any way they wish and launch their own Windows distros that, at the kernel level, can be made compatible with MSFT-released one, so that users can have a choice which particular kernel to boot for a given session. The only thing I noticed is that, for this or that reason, people are requested to test their drivers on Beta 1 if they want to get certified for Vista…

Therefore, I repeat my question - how on Earth are Linux and open source philosophy may be possibly related to the whole thing???

Anton Bassov

Anton is right, open source is never about *forcefully*, it’s about the
free will of the community.
I can test and report bugs found in Fedora Core X which will help RedHat
to fix things back in RHEL.
But there is no *must*.

The case we discuss here is totally different from Linux.
According to the updated WHQL policy, I *must* test my drivers on
Windows 7 beta.
Therefore, I *must* spend more lab hours and maybe, buy more hardware.

Though I personally like the idea to be able to improve Windows 7 the
community style - at free will.
This is in contrast to be forced - the MSFT style.

Alexey

xxxxx@hotmail.com wrote:

> Are you sure that you understand the philosophy of Linux and open source?
> It seems to me that if you are not ready to test other peoples code and fix their bugs
> Linux is not the right operating system for you.
>

I just wonder how on Earth Linux and open source may be possibly related to the whole thing…

Probably, I just misread something, but somehow I failed to notice any statements saying that MSFT asks people to review the *code* of Windows 7. I also failed to notice any statements saying that driver writers can submit their *source* for the review by MSFT, so that, in case their code gets accepted, their driver is going to be supported in all future OS releases. I also failed to notice any statements saying that people are allowed to modify MSFT’s code in any way they wish and launch their own Windows distros that, at the kernel level, can be made compatible with MSFT-released one, so that users can have a choice which particular kernel to boot for a given session. The only thing I noticed is that, for this or that reason, people are requested to test their drivers on Beta 1 if they want to get certified for Vista…

Therefore, I repeat my question - how on Earth are Linux and open source philosophy may be possibly related to the whole thing???

Anton Bassov


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

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.

If you are in the Linux world as well you don’t have to be part of the
kernel.
But if you want to sell on these markets, you should be on the kernel
and in the big distributions as well.
At this stages things are not being done at your free will. You want to
sell you are part
of that community and you obey it’s rules.

Theoretically, just theoretically, you write a perfect driver and it
doesn’t work because of bug in the OS.
Do you have any choice other than fixing the OS? Can the OS be fixed
without testing?
Do the Linux OS developers have all the HW in the world?
Practically speaking in order to have your driver work you have to test
it with the OS and with
pre-released version of the OS.

And one more thing, you don’t have to pass, you only have to test (" The
test logs generated
from the beta OS are not required to pass")

Tzachi


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexey Polonsky
Sent: Monday, June 02, 2008 10:24 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Rumors? Time table for Windows 7 Beta

Tzachi, open source is never about *forcefully*, it’s about the
free will of the community.

The case we discuss here is totally different from Linux.
According to the updated WHQL policy, I *must* test my driver on
Windows 7 beta.
If the tests fail, I won’t be able to submit the driver for WHQL
signature, even if the driver works ok on RTM versions of Windows.
Does it really sound ok ???

I really hope it’s a misprint in the policy document and MSFT
don’t really mean to enforce it.

Tzachi Dar wrote:

To be honest, I don’t see any reason why person
X should be
happy about being *forcefully* requested to
detect bugs that
got introduced by person Y, especially if they
don’t work
on the same product and have no access to each
other’s code.
Why should you be requested to do someone else’s
job, in the
first place??? It never occurred to you to think
this way???

Anton Bassov

Are you sure that you understand the philosophy of Linux
and open
source?
It seems to me that if you are not ready to test other
peoples code and
fix their bugs Linux is not the right operating system
for you.

Or is it really the word *forcefully* that is your
problem.

Tzachi


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


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

FFS !!!

It’s Monday morning and this thread like so many others has morphed
once again in to childish Linux/OSS vs Windows.

I work with both. I have 20+ years coding various operating
systems. I can make my own mind up without having the children
arguing conspiracies all around me.

The title of this mailing list is NTDEV. When I want to hear about
Linux, I’ll see you on LINUXDEV. Please keep within the terms of
reference, the signal to noise ratio in here is dropping off dramatically.

> Practically speaking in order to have your driver work you have to test it with the OS

and with pre-released version of the OS.

Sure, particularly if you rely upon the API that gets introduced by the new OS version and is not available
under the older one. However, if you write your driver for Vista, objectively, you just cannot be expected to use the API that turns up only under Windows 7. At this point the question arises - why should you test your *Vista* drivers against Windows 7 ??? Is it going to have exactly the same kernel that Vista does??? If so, what is the *technical* point of releasing it, in the first place??? From the marketing point of view it is perfectly understandable, but from the technical one it just does not seem to make sense, don’t you think…

Anton Bassov

Mark,

this thread like so many others has morphed once again in to childish Linux/OSS vs Windows.

I don’t believe it myself, but on this particular occasion it was not me who went into this direction - now I am trying my best to take Tim’s approach…

Anton Bassov