MS explicitly designed and marketed and sold XP for a variety of user
setups, one of which was as a single-user OS (esp. XP Home), and knows
well from its help lines and from other sources how XP is being used.
Are you saying that MS knowingly misrepresented its product?
Your monikor Vanguard and length of posts suggests someone who once
learned the Leninist notion of propaganda as being the conveying of
many ideas to (relatively) few people, but has yet to figure out that
doing so doesn't necessarily require the use of many words. First,
however, I'd suggest your time would be well spent on a notion Lenin was
big on, namely learning how to think (one of its useful byproducts is
being able to judge better when to go long or short).
-G
On Sat, 26 Sep 2009 23:17:26 -0500
VanguardLH wrote:
gene wrote:
The length of your reply seems in direct proportion to the absurdity
of providing, or not greying out, a task scheduler that doesn't work
with single-user accounts
And therein lies the crux of your hypothesis. NT-based versions of
Windows are *not* single-user operating systems. That you use it that
way doesn't mean that's is how it was designed. You can use a
screwdriver as a hammer. You're using a rather large OS for your
personal needs; i.e., you limit the functionality of a large OS to
your specific needs. You might buy a SwissChamp Swiss Army knife (see
http://tinyurl.com/2b5bgx) but never actually use more than a third of
this "blades", and yet it might not have exactly the tool set that you
would design just for personal use.
and doesn't give an error message until after users have spent time
trying to set up a task.
It won't until it tries. As far as I know, the TS wizard only queries
the SAM database regarding login credentials when you attempt to enter
them during the wizard (you get prompted after creating the job for
the login credentials). It never verifies that the job will actually
run under that account specified within the job. It doesn't know that
until runtime.
For example, you can create jobs for existing accounts but which won't
run now but you aren't done completing your setup so that job, when it
does run, will run okay then.
Let's add that MS's tech paper on LUAs is addressed to "business
decision makers" and "IT Professionals," hardly your typical single
user set up or a very practical way to use a home computer.
While Microsoft did come up with "home" editions of their Windows
product (which crippled some features), it was a derivative of a
product that was primarily geared toward corporate use and
management. The single-user schema died with the DOS/9X versions of
Windows.
If you actually have a suggestion to offer, perhaps a workaround,
I'm all ears. But do limit yourself to a sentence or two or three
(and I'll go back to bottom posting).
You already found the answer: you must provide *complete* login
credentials for the account under which you want to run the scheduled
tasks (with the exception of the SYSTEM account but you cannot use the
Task Scheduler wizard for that).
Btw, the two instances of Google Task Update User (each followed by
a alphanumeric and either Core or UA at the end) are situated in the
Task Scheduler. If they aren't scheduled tasks, what are they doing
there?
You first mentioned "Google Updater" and that runs as an NT service
(so it gets rolled under one of the svchost process instances that
you see in Task Manager's Processes tab). Now you're mentioning
other tasks (which, I believe, are what I saw when Google Earth was
installed). Saying "Google Updater" didn't provide a clue as to which
of Google product's that you installed as that utility is included in
several of them.
The scheduled tasks you now mention are probably from you installing
Google Earth (but that is not conclusive since I didn't install all of
Google's software programs and you didn't mention which one you
installed). They are scheduled tasks but have you *looked* under
which account they are executed? If the SYSTEM account then the
installer used the 'at' command or similar to create the .job file
for that scheduled task (and no login credentials are required for
SYSTEM but then you had to be logged under an admin-level account
when you ran that installer). If not the SYSTEM account, the
installer can use the crypto API to get your login credentials to add
them to the .job file that it created (while you were logged on as an
admin-level user).
If you're interested in learning more about Windows security from
participants in newsgroups, visit the:
microsoft.public.windowsxp.security_admin group
I've seen users there that are far more intimate with the inner
workings of Windows and its security mechanism than I. Since you got
the answer (which you didn't want but is still the answer), I don't
see the point of further trying to explain why someone else's code
that is geared towards a mass community of users doesn't do exactly
what you want it to do.