cmd.exe and command.com in Windows

[MisterX]

Chris,

First, if the customer gets pissed off by this problem, note well
that it's his fault for limiting things whether needed or not... 
With Windows Policy you can today finegrain any access to any part
of the pc for any kind of user. Even without active directory which
goes even further down to the resource (in a matter of speaking).  

Then again, undocumented features and bugs (as Im suffering everyday
whether in RunRev or in Windows or in Colin Mac Rae (stupid farging 
program - don’t buy it!), it's up to the user to find a solution and not
always the programmer's fault because of client or user's limitations ;) 

I don’t blame anyone really ;) I just avoid them ;)

Workaround? Can the "user" read the registry? 

Otherwise, you can maybe do an install as an admin, have the stack
write down the results of the specialfolders to an ini file or in the
prefs stack (you choose) which can then be read innocently by the user.

It's a good compromise. Avoid hardcoding a path like that in your
app, regretable need for an update later when a simple "Prefs/options"
field  saved to a pref file would suffice. 

But every client's discomfort is worth a few more hours in the bill ;)
Ferenguee Development rule number 45 

Without looking up, I came to a close match ;))
http://encyclopedia.thefreedictionary.com/Rules%20of%20Acquisition

Take advantage of the situation that the client offers you!

Cheers
http://monsieurX.com

--




 

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> Chris Sheffield
> Sent: Monday, October 11, 2004 4:24 PM
> To: RevList
> Subject: cmd.exe and command.com in Windows
> 
> I have a customer who's using my company's application that 
> called our tech support with a problem where it would just 
> suddenly quit under Windows without an error or anything.  It 
> turns out they are running a security program (Visual CASEL) 
> on their Windows workstations.  When logged on as an 
> administrator, everything was working fine, but when logged 
> on with a student account, the program would suddenly die.  
> They discovered that it was because, by default, their 
> security was blocking access to "cmd.exe" and "command.com", 
> which I'm assuming the shell function uses to accomplish it's 
> tasks.  But the weird thing is, I'm not using shell anywhere. 
>  So I did a search for "shell" in the docs, and one function 
> that came up was specialFolderPath, but nowhere in the 
> documentation for that function does it actually mention the 
> shell function or cmd.exe or command.com.  But the user has 
> verified by watching the list of processes that "cmd.exe" 
> does indeed run at a couple different points when first 
> starting up our program.
> 
> So does specialFolderPath use "cmd.exe" and/or "command.com"? 
>  If so, why isn't this documented?  Our user was not happy at 
> all that they had to allow access to these executables 
> because they could potentially be used to format one's hard 
> drive or perform other damaging tasks.  And I suspect we'll 
> have others with the same problem.  I was also told that 
> Foolproof, another popular security system in schools, also 
> blocks access to these modules by default.  If anyone has any 
> kind of workaround, I would be most grateful to hear it.
> 
> Thank you,
> 
> Chris Sheffield
> Software Development
> Read Naturally
> 
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.775 / Virus Database: 522 - Release Date: 10/8/2004
>  
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>