DDK-то за XP ще е платено, защото доколкото разбрах ще включва C компилатор-а. To цялото XP явно е писано с този нов компилатор/линкер, защото форматът на PDB файловете от retail symbols е нов и ако се опиташ да apply в IDA Pro казва, че версията била по-висока (7.0).

засега за XP общо взето само Microsoft-ския debugger е използваем, въпреки грешките в него. SoftICE от Numega Driver Studio 2.5 RC1 е много нещастно :(( - не работят BPX-та и прочие. Ще чакаме оконачателната версия - предполагам една седмица след това ще се появи и по хакерските сайтове ;)
за XP Microsoft са направили няколко много ценни kernel debugger extensions - !heap -l например; общо взето това май е единствената причина за която мога да се сетя за да не се върна на Win2000. Но ако до края на годината Numega не пуснат свестен SoftICE ....

отплеснах се.. :)
не мога да кажа че познавам добре средствата, които предлагат www.krftech.com {jungo} (WinDriver) или www.bluewatersystem.com (WinRT) или пък DriverAgent-a на Numega, още по-малко пък съм работил с тях, но имам идея какво представляват. Това са драйвери които изпълняват заявки от user-mode приложения за достъп до хардуера - казваш му прочети ми еди кой си порт, и драйвера прочита порт-а ти връща резултата. Това наистина е удобно - позволява ни да задържим логиката в usermode приложението и по време на разбработката OS-a много по-рядко ще забива и то само ако наистина объркаме нещо много сериозно по логиката за достъп до хардуера. Недостатък е, че постоянно минаваме между user и kernel mode, а това съществено забавя скоростта (каквито и реклами да се правят един "чист" kernel mode driver при всички положения ще е по-бърз).

по-големият проблем според мен, който ми се струва че е валиден и за тази задача, е че в общия случай заявките към kernel mode драйверите се изпълняват в arbitrary thread context (тоест не в същия thread от който е дошла заявката). Предвид необходимостта от връщане резултата от заявката IRQL не трябва да се вдига до IRQL DISPATCH_LEVEL или по-високо, което значи че даваме възможност на другите приложения да живеят. (Допускам обаче че WinDriver и другите може би имат някакво много хитро решение на това). Така че идеята с последователно четене на сектори и времеизмерване не ми се струва особено подходяща.

използването на S.M.A.R.T. очевидно е "официалният" метод за failure prediction и Microsoft мъдро са добавили такава възможност във WMI.

http://www.microsoft.com/hwdev/manageability/SMARTdrv.htm

погледнах на tucows и не забелязах програми които да правят подобни прогнози за живота на твърдите дискове, (още повече, че не се иска кой знае какво), което лично мен ме учудва - явно това се оказва пазарна ниша, така че на който му се печелят пари и слава... :)