Re: f0dder's Fabulous Wait States.
- From: Donkey <donkey@xxxxxxxxxxxx>
- Date: Wed, 31 Aug 2005 03:16:16 GMT
hutch-- wrote:
Donkey,
I am pleased that you see the method as so effective.
1. Write something trivial that works well. 2. Listen to years of invective and bullsh*t about why its wrong. 3. Deliver the proof that it works well. 4. Loop back to 2 on repetition. 5. Develop a "Who gives a PHUK" attitude to the invective and bullsh*t. 6. Loop back to 2 on repetition. 7. Dump the trash in ALA due to 5. 8. Loop back to 2 on repetition. 9. Share the nuisance value aroung in ALA. 10. Loop back to 2 on repetition. 11. Start testing the source of invective and bullsh*t over some years. 12. Loop back to 2 on repetition. 13. Spare the decent assembler venues from the invective and bullsh*t. 14. Loop back to 2 on repetition.
If all else fails, WaitForf0dderDotLibNoTimeout().
Steve,
As far as I am concerned the point has never been whether it works or not, though your Shell function definitely does not work under all possible circumstances. The point of this whole long argument is "is this the right way to achieve this goal". I for one, and most others here do not believe it is, it is sloppy and a hack and though it may work to your satisfaction, it may not do so in the future. And before you say that Microsoft would not make such fundamental changes to the way Windows works, just look at XPSP2, with PAE mode making around 20% of my commercially acquired apps useless until I disabled it. A good example is Connectix Virtual PC, which cost me a fair bit of coin and is incompatible with PAE mode (though it works fine once PAE is disabled). Granted, PAE mode and it's consequences have little to do with the subject at hand but it does demonstrate what happens when you stray too far from Microsoft's recommended way of doing things. The moral of the story is simply that Microsoft feels no compunction in breaking software that does not comply with their specifications in future versions of the OS and it is simply conform or die in a BSOD.
At some point you should consider what has been offered as valid criticism and fix the function, I would think any good programmer would welcome advice that would improve his code and make it more stable across all versions of Windows. Perhaps not everyone has offered it in this manner but many have and they (ie Randall Hyde) should not be attacked for pointing out deficiencies and possible solutions to something they believe to be a problem in the MASM32 library. Randall has, as far as I know, never maliciously attacked you or attempted to deride you in public but you seem to see fit to do so to him, attacking his argument is fine but you are attacking him personally and that I find both unnecessary and unwarranted. Attack me if you choose, I have no reputation to uphold and have little regard for such things anyway.
The more I read you recent posts, the more I see the road that perhaps Betov took to get where he is. Defend a small peice of code against the swell of opinion just as a matter of principle, then stubbornly refuse to change it even when it is demonstrably flawed. At some point the argument becomes personal and vindictive then you find yourself on the slippery slope to "Outer Betovia", the land of the ignored and ridiculed. One simple way out is ofcourse to end the argument with the old standby "Let's agree to disagree", one of my favourites by the way.
Donkey .
- Follow-Ups:
- Re: f0dder's Fabulous Wait States.
- From: hutch--
- Re: f0dder's Fabulous Wait States.
- References:
- f0dder's Fabulous Wait States.
- From: hutch--
- Re: f0dder's Fabulous Wait States.
- From: Donkey
- Re: f0dder's Fabulous Wait States.
- From: hutch--
- f0dder's Fabulous Wait States.
- Prev by Date: Re: Polling loop good here???
- Next by Date: Why i dont attack any assemblers (or any of you clowns)
- Previous by thread: Re: f0dder's Fabulous Wait States.
- Next by thread: Re: f0dder's Fabulous Wait States.
- Index(es):
Relevant Pages
|