MSFT HCK, crock of shit
-
TheGreatAndPowerfulOz wrote:
Why is this in the soapbox?
His signature is offensive. :-\
There are only 10 types of people in the world, those who understand binary and those who don't.
RyanDev wrote:
His signature is offensive
This again, you are too sensitive and munchies is a troll. Stop feeding him!
Never underestimate the power of human stupidity RAH
-
So as a driver writer I have to run my drivers through the Microsoft HCK to get a signature. Why does one test, CHAOS, fail in one of the Microsoft system drivers on some platforms? (even without using my driver). Why does this test fail with different kinds of hardware used as a test device? Why does this test pass 50% of the time with some hardware combinations (test PC and test device)? Why does this test pass all the time with Windows 8 on the test PC? Now in all of this, I have written a driver, a driver that doesn't vary, and which I want testing. I don't want to test the OS, the OS drivers, the PC hardware, the USB host controller, or the hardware the driver is written for. All I want to test is the driver, that little tiny bit that sits between the host and the IO manager. And yet I cant. So I have to spend days and days farting around trying to get a pass. (And this one test takes hours to run, in total, its a day of testing). And this has to be done on Win7, 8, 8.1, 32 and 64 bit. HCK is a joke. An utter waste of time written by morons who have no idea whats gong on in the real world. Oh, and I once wrote a filter driver for the ppm CPU driver. Both intelppm.sys and amdppm.sys BSOD if HCK is run on them demonstrating that Microsoft don't run their own drivers through HCK.
Munchies_Matt wrote:
I don't want to test the OS, the OS drivers, the PC hardware, the USB host controller, or the hardware the driver is written for. All I want to test is the driver, that little tiny bit that sits between the host and the IO manager.
Well, I'm not sorry for you. That seems the way some manufacturers do and we end up with brilliant drivers that work all the time except the real hardware is connected :)
-
RyanDev wrote:
His signature is offensive
This again, you are too sensitive and munchies is a troll. Stop feeding him!
Never underestimate the power of human stupidity RAH
Oh yeah, sure, I am just a big bad troll, expressing my utter frustration with Microsoft's tool chain just like all other trolls do. Why don't you try to come up with a rational counter poi9nt instead of a pathetic insult? We might give yo more credibility if you do.
-
Munchies_Matt wrote:
I don't want to test the OS, the OS drivers, the PC hardware, the USB host controller, or the hardware the driver is written for. All I want to test is the driver, that little tiny bit that sits between the host and the IO manager.
Well, I'm not sorry for you. That seems the way some manufacturers do and we end up with brilliant drivers that work all the time except the real hardware is connected :)
Have you ever heard of the words 'modularisation' and 'un coupling' in reference to software design? if not look them up and then come back and tell me why the driver has any connection at al with the hardware. Unless of course you just don't know anything about the windows kernel and therefore assume that in some way the two are linked. (They aren't, they are completely separate, and the only connection between them is by a handful of standard windows functions exposed by the Microsoft supplied bus drivers.)
-
Have you ever heard of the words 'modularisation' and 'un coupling' in reference to software design? if not look them up and then come back and tell me why the driver has any connection at al with the hardware. Unless of course you just don't know anything about the windows kernel and therefore assume that in some way the two are linked. (They aren't, they are completely separate, and the only connection between them is by a handful of standard windows functions exposed by the Microsoft supplied bus drivers.)
Calm down, this is soapbox. Why so serious? But if you insist... ;) Yes, I've heard of all these terms and yes I know the idea behind microkernels (but had no real life experience with Windows drivers, I admit). As a customer I would appreciate if the certification "yes this hardware driver works with this OS and this HW" was backed by a test with this OS and this HW. I'm not interested in certificate that just say "this driver works as piece of software". I would compare this to doing just unit tests on "modularised" and "un coupled" pieces of software without doing an UAT (I really hope you don't need to look this term up...). Do you understand my point now?
-
Calm down, this is soapbox. Why so serious? But if you insist... ;) Yes, I've heard of all these terms and yes I know the idea behind microkernels (but had no real life experience with Windows drivers, I admit). As a customer I would appreciate if the certification "yes this hardware driver works with this OS and this HW" was backed by a test with this OS and this HW. I'm not interested in certificate that just say "this driver works as piece of software". I would compare this to doing just unit tests on "modularised" and "un coupled" pieces of software without doing an UAT (I really hope you don't need to look this term up...). Do you understand my point now?
You still don't get it. Both the hardware and the driver agree to support an interface. If they do, they both pass, regardless of each other. If the hardware doesn't, it wont work with ANY driver so the driver can, and should, be tested in isolation and independent of the hardware. And as for the windows system causing tests to fail, that's just plain stupid.
-
RyanDev wrote:
His signature is offensive
This again, you are too sensitive and munchies is a troll. Stop feeding him!
Never underestimate the power of human stupidity RAH
-
You still don't get it. Both the hardware and the driver agree to support an interface. If they do, they both pass, regardless of each other. If the hardware doesn't, it wont work with ANY driver so the driver can, and should, be tested in isolation and independent of the hardware. And as for the windows system causing tests to fail, that's just plain stupid.
Ok. I get it. This is unit testing. But the certificate is for the whole chain working: HW<->OS interface<->Driver<->OS interface<->Application I don't say you should not test driver and HW separately. I repeat: certification is thing after unit testing. It is to certify that pieces tested and approved separately before DO WORK TOGETHER!
Munchies_Matt wrote:
And as for the windows system causing tests to fail, that's just plain stupid.
And here we are: Driver is working? Yes. HW is working? Yes. Whole solution is working? NO. Still no need to test the whole thing? Ok, arguments aside, something constructive now: Are you 200% sure that neither HW nor driver makes the interface unstable? Ok, after unit tests you have the right to be. Most common cases? Flaw in interface, wrong driver or HW reaction to nonconforming signal on the bus or interference with other (faulty?) drivers/HW ... As far as I remember CHAOS is the test that is doing exactly this kind of tests. If it fails without your driver you should suspect there is something unstable already in your system. All patches installed? All drivers for all hardware updated? Known problems checked? Look, if you are the only one who is suffering this type of problems - it probably means there is something wrong with your setup. If there are many others like you - leave the Soapbox and join them on MS forums - MS should hear you and fix the problem :)
-
Ok. I get it. This is unit testing. But the certificate is for the whole chain working: HW<->OS interface<->Driver<->OS interface<->Application I don't say you should not test driver and HW separately. I repeat: certification is thing after unit testing. It is to certify that pieces tested and approved separately before DO WORK TOGETHER!
Munchies_Matt wrote:
And as for the windows system causing tests to fail, that's just plain stupid.
And here we are: Driver is working? Yes. HW is working? Yes. Whole solution is working? NO. Still no need to test the whole thing? Ok, arguments aside, something constructive now: Are you 200% sure that neither HW nor driver makes the interface unstable? Ok, after unit tests you have the right to be. Most common cases? Flaw in interface, wrong driver or HW reaction to nonconforming signal on the bus or interference with other (faulty?) drivers/HW ... As far as I remember CHAOS is the test that is doing exactly this kind of tests. If it fails without your driver you should suspect there is something unstable already in your system. All patches installed? All drivers for all hardware updated? Known problems checked? Look, if you are the only one who is suffering this type of problems - it probably means there is something wrong with your setup. If there are many others like you - leave the Soapbox and join them on MS forums - MS should hear you and fix the problem :)
Jarek Kruza wrote:
And here we are: Driver is working? Yes. HW is working? Yes. Whole solution is working? NO. Still no need to test the whole thing?
Because the failure occurs inside Microsoft components ONLY when the HCK test is running. A component over which you have NO control and yet one that is standing in your way. Take the xhci test on windows 8. Why does THEIR driver crash just enumerating the device, and that's before the driver under test even gets loaded? Its because its unstable.
Jarek Kruza wrote:
Are you 200% sure that neither HW nor driver makes the interface unstable
Yes. Its a very very old interface, goes back 15 years its that old. This hardware is ancient, the driver is too, just a few tweaks here and there, and has been running since the days of windows 2K.
Jarek Kruza wrote:
All patches installed? All drivers for all hardware updated? Known problems checked?
Yes, ran WU, didn't help.
Jarek Kruza wrote:
join them on MS forums
I have posted countless times and you don't get a response. By the way I have been working with the windows kernel since 1997, the days of NT4 writing serial and network drivers so even someone with vast experience like me, who knows windows inside out, and who has used the previous tool, WHQL, extensively, for many many years, has issues with HCK. I just don't understand MSFTS philosophy here, surely it is the DRIVER that is being signed, it is the DRIVER that should be tested, and not the OS, the hardware device, and the hardware of the OS!
-
So as a driver writer I have to run my drivers through the Microsoft HCK to get a signature. Why does one test, CHAOS, fail in one of the Microsoft system drivers on some platforms? (even without using my driver). Why does this test fail with different kinds of hardware used as a test device? Why does this test pass 50% of the time with some hardware combinations (test PC and test device)? Why does this test pass all the time with Windows 8 on the test PC? Now in all of this, I have written a driver, a driver that doesn't vary, and which I want testing. I don't want to test the OS, the OS drivers, the PC hardware, the USB host controller, or the hardware the driver is written for. All I want to test is the driver, that little tiny bit that sits between the host and the IO manager. And yet I cant. So I have to spend days and days farting around trying to get a pass. (And this one test takes hours to run, in total, its a day of testing). And this has to be done on Win7, 8, 8.1, 32 and 64 bit. HCK is a joke. An utter waste of time written by morons who have no idea whats gong on in the real world. Oh, and I once wrote a filter driver for the ppm CPU driver. Both intelppm.sys and amdppm.sys BSOD if HCK is run on them demonstrating that Microsoft don't run their own drivers through HCK.
The Microsoft driver group are a bunch of vicious morons. They are number three on my list of development-teams-put-against-the-wall-when-the-revolution-comes (just behind the Lotus Notes and InstallShield/whatever-their-name-is teams). I've never written a Windows driver myself, but I did have to write installers for a couple. There are three ways to install a Windows driver: 1. The method documented in the DDK/WDK 2. The method used in the DDK/WDK samples 3. The method used in pathetic Google search results while sobbing quietly 4. The method you finally arrive at after weeks of pounding the keyboard randomly
Software Zen:
delete this; -
The Microsoft driver group are a bunch of vicious morons. They are number three on my list of development-teams-put-against-the-wall-when-the-revolution-comes (just behind the Lotus Notes and InstallShield/whatever-their-name-is teams). I've never written a Windows driver myself, but I did have to write installers for a couple. There are three ways to install a Windows driver: 1. The method documented in the DDK/WDK 2. The method used in the DDK/WDK samples 3. The method used in pathetic Google search results while sobbing quietly 4. The method you finally arrive at after weeks of pounding the keyboard randomly
Software Zen:
delete this;You have my sympathy, in fact, if you had written code, you would also find out, painfully, slowly, and on your own, that the code in the samples is also wrong. Yep, THE most complex bit of coding you can do, and you get fuck all guidance. However, let me say, if you think writing inf files is bad for 2k on, you should have seen NT4. It was a completely undocumented script language, as arcane and impenetrable as the best secrets of the Vatican. :) For example, my HCKX package wouldn't upload the other day, so I asked MSFT. They said "rename it .zip. Unzip it. Rezip it. Rename it .hckx" and guess what, it uploaded. I see, so the zip mechanism they put in their tool isn't compatible with their website, but 7zip is compatible with both? Are they fucking mad? :wtf: :confused: :omg: :omg: :omg: