Prev: Sys x: format x:/u/s
Next: Hibernation not working
From: Unknown on 10 Apr 2010 12:03 You keep insinuating Microsoft is incompetent. You are completely blind to the real world. Doesn't it occur to you the third party program may be at fault? Can any programmer anticipate everything that will occur in the future when assembling a program? "Brian Gregory [UK]" <ng(a)bgdsv.co.uk> wrote in message news:IaydnSgh9cPQMiLWnZ2dnUVZ7vSdnZ2d(a)pipex.net... > > "ju.c" <bibidybubidyboop(a)mailinator.com> wrote in message > news:ed8%23yK8wKHA.6140(a)TK2MSFTNGP05.phx.gbl... >> How to delay loading of specific services >> http://support.microsoft.com/kb/193888/en-us > > They actually admit they bodged it: > > "In some computers, especially older systems and those with slower > peripherals, it may be necessary to delay the loading of a specific > Windows service for the computer to boot properly" > > This shows Windows is incorrectly written software by any professional > standard. > > If you know something could go wrong you are incompetent if you don't > write the software so that it's impossible for it to go wrong. > > -- > > Brian Gregory. (In the UK) > ng(a)bgdsv.co.uk > To email me remove the letter vee. >
From: Brian Gregory [UK] on 10 Apr 2010 18:36 "Shenan Stanley" <newshelper(a)gmail.com> wrote in message news:ehoqVxD2KHA.1624(a)TK2MSFTNGP06.phx.gbl... > Brian Gregory [UK] wrote: >> They actually admit they bodged it: >> >> "In some computers, especially older systems and those with slower >> peripherals, it may be necessary to delay the loading of a specific >> Windows service for the computer to boot properly" >> >> This shows Windows is incorrectly written software by any >> professional standard. >> >> If you know something could go wrong you are incompetent if you >> don't write the software so that it's impossible for it to go wrong. > > Not really. > > Since there are millions of combinations of computer hardware and computer > software possible (billions even, probably a number larger than that) - to > think any one piece of software (OS or otherwise) could handle all the > possible combinations or be compatible with all the past/present and > future possibilities as well is a ridiculous notion. > > In fact - the notion of doing anything so that it is *impossible for it to > go wrong* demonstrates an ignorance of reality. I'm not asking for Windows to never go wrong, only that one of the most basic things not be simply left to chance. > The key works in my door lock now... Think it will work always no matter > what happens? If you were programming a robot to unlock a door you would not write an insert the key in the lock process and a turn the key process and then test and say the key seems to reach the door in time. You would explicity make the turn the key process wait until the key was in the lock. With explicitly waiting the fact that on your particular state of the art robot the key seems to reach the lock in time would not be an excuse for not explicitly making the turn the key process check the key was actually in the lock before turning it. -- Brian Gregory. (In the UK) ng(a)bgdsv.co.uk To email me remove the letter vee.
From: Jose on 10 Apr 2010 18:38 On Apr 9, 6:50 pm, "Brian Gregory [UK]" <n...(a)bgdsv.co.uk> wrote: > "ju.c" <bibidybubidyb...(a)mailinator.com> wrote in message > > news:ed8%23yK8wKHA.6140(a)TK2MSFTNGP05.phx.gbl... > > > How to delay loading of specific services > >http://support.microsoft.com/kb/193888/en-us > > They actually admit they bodged it: > > "In some computers, especially older systems and those with slower > peripherals, it may be necessary to delay the loading of a specific Windows > service for the computer to boot properly" > > This shows Windows is incorrectly written software by any professional > standard. > > If you know something could go wrong you are incompetent if you don't write > the software so that it's impossible for it to go wrong. > > -- > > Brian Gregory. (In the UK) > n...(a)bgdsv.co.uk > To email me remove the letter vee. Working as designed and working as deired are sometimes not the same thing. Expectations also sometimes exceed reality. I don't fully understand your problem and there are many unknowns in the equation, but I read someplace that when users were just so anxious to get to work and their system was not quite settled down yet, automatic login was disabled so that may allow enough time tor things to settle down (your force them to login manually which takes a few seconds) and in another instance, a login batch file using the "sleep" command was created and pushed out to all the users to induce a 3 second pause in the login process. You can of course adjust the delay to whatever causes the least amount of complaining but still resolves the issue. The users do not even have to know about the batch file. They'll get used to it. If you use the login delay method, you may have to deal with the dreaded "whatever you did, my computer is now too slow" gripe - for a while... until everybody gets used to it and adjusted. Of course, you do not inform your users that you introduced a DELAY! in their login, only that you have successfully resolved their issue.
From: Shenan Stanley on 10 Apr 2010 21:20 Brian Gregory [UK] wrote: > If you were programming a robot to unlock a door you would not > write an insert the key in the lock process and a turn the key > process and then test and say the key seems to reach the door in > time. You would explicity make the turn the key process wait until > the key was in the lock. With explicitly waiting the fact that on > your particular state of the art robot the key seems to reach the > lock in time would not be an excuse for not explicitly making the > turn the key process check the key was actually in the lock before > turning it. How do you know the key is in the lock? How do you account for every key type and every lock type that may be used with that robot? Is it a luggage key? Plastic? Metal? Electronic components embedded? Wooden? What type of lock is it? How long is the key? How wide? Is it possible to have the key go too far in? Not far enough? How do you determin? How far do you have to turn it? Which way? Can it turn all the way around or is there a stop? What shape is the key/lock? What is the lock/key is corroded/rusty (old?) You see - you seem to imply that you know every possible situation with your examples - but - you cannot even come close. In an enclosed environment where all the variables are known - no problem. In the real world - where things like OSes reside - not so much. -- Shenan Stanley MS-MVP -- How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html
From: Brian Gregory [UK] on 11 Apr 2010 12:38
"Shenan Stanley" <newshelper(a)gmail.com> wrote in message news:enLMOVR2KHA.5820(a)TK2MSFTNGP06.phx.gbl... > Brian Gregory [UK] wrote: >> If you were programming a robot to unlock a door you would not >> write an insert the key in the lock process and a turn the key >> process and then test and say the key seems to reach the door in >> time. You would explicity make the turn the key process wait until >> the key was in the lock. With explicitly waiting the fact that on >> your particular state of the art robot the key seems to reach the >> lock in time would not be an excuse for not explicitly making the >> turn the key process check the key was actually in the lock before >> turning it. > > How do you know the key is in the lock? How do you account for every key > type and every lock type that may be used with that robot? Is it a > luggage key? Plastic? Metal? Electronic components embedded? Wooden? > What type of lock is it? How long is the key? How wide? Is it possible > to have the key go too far in? Not far enough? How do you determin? How > far do you have to turn it? Which way? Can it turn all the way around or > is there a stop? What shape is the key/lock? What is the lock/key is > corroded/rusty (old?) > > You see - you seem to imply that you know every possible situation with > your examples - but - you cannot even come close. In an enclosed > environment where all the variables are known - no problem. In the real > world - where things like OSes reside - not so much. In this case the key and the lock were both made my Microsoft. -- Brian Gregory. (In the UK) ng(a)bgdsv.co.uk To email me remove the letter vee. |