Re: exe not working in non admin privilege winxp user account
On May 27, 5:42 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
See below...
On Thu, 26 May 2011 20:56:16 -0700 (PDT), satheesh <satheesh.businessonli=
....@gmail.com>
wrote:
On May 26, 10:32 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:
I'm not sure historically what VS6 required, since it has now been man=
y years since I last
used it. I know VS2003 required admin privileges to run, and errone=
ously launched
programs with the same priviileges as the developer (this is the one w=
here I had to have
the program re-launch itself so I could test it!) A real pain.
Note that another common mistake is trying to write files to the "exec=
utable directory",
which is a deep and fundamental mistake that has no excuse. Of cour=
se, without any
knowledge of what isn't working, it is hard to give advice on how to f=
ix it...
joe
On Thu, 26 May 2011 17:36:24 +0100, "David Webber" <d...@musical-dot-d=
emon-dot-co.uk>
wrote:
"C Programmer , MFC" wrote in message
news:c2ca4b81-a4b9-4d4a-abe2-834b778c87fc@z13g2000prk.googlegroups.co=
m...
Release mode : Using winxp admin/user(admin privilege) account it i=
s
working properly, but it is not working in other user account(not
admin privilege).i am using vc 6.0 only and winxp. how can i run my
application in all accounts in xp(both admin and non-admin privilege
account).<
You need to find out why. Usual reasons are trying to write to th=
e
HKEY_LOCAL_MACHINE area of the registry or to a protected area of the=
file
system.
The solution is almost always to stop doing that; not for the program=
to
demand admin permissions. With very few exceptions (chief among t=
hem
installers) programs should not need admin permissions.
With regard to Joe's comments, I have a question (as my memory is get=
ting
vague): I agree completely about developing without admin permissi=
on (and I
keep my Windows 7 UAC firmly switched on), but didn't VC6.0 itself re=
quire
admin permission?
Dave
-- David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
Hi,
The program is working perfectly in admin mode and admin-privile=
ge
user accounts. Except all other codes in my application (including
registry or calling some API ) In this case creating a file is a big
problem.
For eg: In an application for create a file and write "Hi" to that
file(notepad). Except admin privilege user account it is not possible
from the application.
CStdioFile cfile;
cfile.Open("c:\\log.txt",CFile::modeCreate|CFile::modeReadWrite)=
;
****
Already, this code is suspect! You should NEVER, EVER assume any parti=
cular directory is
accessible. The presumption that the C: drive exists is insane, the pr=
esumption that it
has enough space to hold the log is insane, and the presumption that the =
user wants you
writing in the root directory of the C drive is insane. In fact, it is=
so insane that
Microsoft typically protects the C:\ directory from non-privileged file c=
reation, so this
code is highly erroneous! The place to do this is to put it in the UserDa=
ta area, or
possibly in My Documents, but NEVER, EVER in the C:\ drive!
This code is crap. Rewrite it! It represents a degree of sloppy thi=
nking that is
unacceptable in modern programming practice. Failing to check the retu=
rn code to see if
the file was opened shows a complete failure in thinking about programmin=
g. NEVER assume
any file open will work! Using a hardwired filename is the first indic=
ation that there is
something deeply wrong with the code. It goes downhill from there. =
The choice of the C
drive is wrong. The choice of the ROOT directory in the C drive is wro=
ng. The use of an
8-bit character literal name (instead of _T("c:\\log.txt") [which is stil=
l going to be
wrong, because it assumes the C drive exists, that the root directory is =
writable, etc.]
is a programming error. This is not the PDP-11 in 1975 running Unix; i=
t is a Windows
machine in 2011. You have to program like 2011. The above code woul=
d have been sloppy in
1975; it is unacceptable today.
From my SHGetFolderPath Explorer:
//----------------
// in stdafx.h
#define _WIN32_IE 0x500
#include <shlobj.h>
//-----------------
CString path;
LPTSTR p = path.GetBuffer(MAX_PATH);
HRESULT hr = ::SHGetFolderPath(CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT=
, p);
if(SUCCEEDED(hr))
{ /* succeeded */
path.ReleaseBuffer();
...your code here
} /* succeeded */
else
{ /* failed */
path.ReleaseBuffer();
...failure code here
} /* failed */
CSIDL_PERSONAL is "My Documents". Or you could use CSIDL_APPDATA. B=
ut only the most
naive newbie would think that c:\ could ever make sense! You have no r=
eason whatsover to
assume you have the right to create files in ANY directory, let alone the=
root directory.
****
cfile.WriteString("Okay from mfc \n");
cfile.Close();
=
OR
FILE* logfile;
logfile = fopen("myLog.txt","w");
fprintf(logfile,"Okay from c \n");
fclose(logfile);
****
This code is even more amateurish than the last example. It creates th=
e file in the
current working directory, which means it creates it somewhere. Or not. =
Since there is no
error checking, this code is complete crap as it stands. But obviously th=
e programmer
cannot possibly tell WHERE that somewhere might be, or even guarantee tha=
t the somewhere
is the SAME somewhere between any two executions of the program!. Anot=
her example of code
that should never, ever exist, for any reason whatsoever. Sloppy progr=
amming, probably
learned by reading K&R First Edition, one of the single worst books on ho=
w to program ever
written (I used it to learn C back in 1975, and I thought it sucked then,=
and nothing I
have seen in the intervening 36 years has convinced me that it is not a t=
errible book,
badly written, badly presented, and which teaches poor programming style)=
..
This suffers from the naive assumption that a file open will always work.=
There is only
one way to deal with file opens: Assume that any file open will fail at a=
ny time for any
reason whatsoever, and be prepared for that!
****
for this any code i created in an application and it is failing in non-
admin privilege user account, is there any step of code to be placed
in my application to work. I had placed manifest also, its not given
me desired output in non-admin privilege account.may be the manifest
code correct or not. But i know it is possible. I know some pieces of
code can activate the application to work as admin privileged exe.
Please share your valuable knowledge to me.
****
(a) never use the current working directory
(b) never use the root directory
(c) never use the executable directory
(d) never use any directory in the Windows hierarchy
Having said these rules, there are two others:
Rule 1: There are no exceptions to the above rules
Rule 2: If you think you have an exception, consult Rule 1
Then there are a few more key rules to proper file management:
(e) always provide a COMPLETE path in the API to any file being created
(e.1) this path should be settable by the end user
(f) If you have to default to some path, use My Documents or AppData for =
things like log
files, or, as a last resort, the TEMP folder
(f.1) if you do not provide an interface by which the user can select the=
path, you have
probably made a serious design error
(g) any file open will fail at any time for any reason
Note that you should have detected these problems during development, whi=
ch means
(h) never, ever do development under an admin account or with admin privi=
leges enabled
(h.1) if you do development with admin privileges enabled, make sure you =
test it on a
nonprivileged account before releasing it.
(h.2) Do not be surprised if you have problems.
(h.3) If you have problems, your code is wrong, fix it.
Had you given the detailed information when you first posted your questio=
n (which was so
vague as to be totally useless), you would have been given correct advice=
for doing things
like handling files, which leads to
(i) "does not work" should never be used as a description of a problem; i=
nstead, you will
describe the PRECISE problem IN DETAIL (which you finally did, above, at =
which point the
fundamental errors were screamingly obvious)
Note that "in detail" means that if a file open fails, you will NOT say "=
the file open
failed", you will say "the file open failed with error 'access denied'" o=
r some other
intelligible explanation. There is nothing more amateurish than someon=
e who reports
merely "File open failed". If you notify the end user, the message wou=
ld say
File open failed
File: "c:\log.txt"
Error: Access denied
If you cannot report all of the above, don't even bother issuing an error=
message. This
would be the MINIMUM required for any error message. Note that
Error: 5
is NOT an acceptable substitute. Learn to use FormatMessage.
joe
****>Regards,
Satheesh
Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm
Hi,
I am using vc++ 6.0 , from your help i got the proper answer , this
code working perfectly and in vc6.0 there is some older things i have
done to get the path,
HMODULE hModule = LoadLibrary("SHFOLDER.DLL");
char szPath[MAX_PATH];
if (hModule != NULL)
{
SHGETFOLDERPATH fnShGetFolderPath =
(SHGETFOLDERPATH)GetProcAddress(hModule, "SHGetFolderPathA");
if (fnShGetFolderPath != NULL)
{
fnShGetFolderPath( NULL,
CSIDL_APPDATA /*CSIDL_PERSONAL CSIDL_PROGRAM_FILES*/,
NULL,
0,
szPath);
AfxMessageBox(szPath); // test display the path
}
FreeLibrary(hModule);
} ,
after a small research i found that in xp non-admin privilege account
i created a file within a folder. but if a file is created from admin
privilege account and it can't be modify or delete by a non-admin
user. so instead for that i've created a new file and placed the
contents to that file.my problem has been solved now. thanks for your
help, if i could't get your help definitely it won't compass the right
corner.
Regards,
Satheesh