Board index » delphi » existing user can not run program

2005-11-19 02:27:00 PM
delphi31
We have been selling shareware programs for several years. We have
received several reports within the last few weeks from existing users
who can no longer start our programs and new users with the same
problem. Nothing happens when they try to run the program.
If they create a new user with admin privileges, they can run the
programs as that new user. Some already have admin privileges but
still have to create a new user to run the program.
We are still using Delphi 3. Sort of selling our previous works and
not paying much attention to new operating system developments. We
use an old installer "eschalon" (they went out of business a few years
ago). Still, some of these programs seem to have installed and
running for a long time before this malady happened. All have been
using XP with service pack2.
Our programs read and write to the Windows folder on startup to check
registration status, and read and write to the program folder which is
installed in a subfolder of \Program Files by default.
I'm just casting about for answers, fearful that this will turn into
some kind of epidemic before we can figure out what is happening all
of a sudden.
Any input will be appreciated.
TIA
 

Any messages in the Windows event log?
Any anti-virus software running on these machines?
Does the app access the Internet or a network that could be blocked by
a firewall?
--
Bill Todd (TeamB)
 

I am not an expert on Windows XP SP2 and you need one. If you don't get
any better help here try the Microsoft newsgroups. I know that XP SP2
does not allow non-admin users access to some folders and does not
allow write access to others. The same is true of some sections of the
registry. For example, users have had to grant full writes to the BDE
section of the registry to get apps that use the BDE to work under XP
SP2 for non-admin users. My best guess is that you have a rights
problem of some kind. Wish I could be of more help.
--
Bill Todd (TeamB)
 

On 19 Nov 2005 06:42:20 -0700, "Bill Todd" <XXXX@XXXXX.COM>writes:
Bill,
Originally, this problem was limited to one of our products (a CAD
design app).
We have two new reports today. One is using a completely different
program of ours from the previous reports (it's a mailing porogram).
This guy has been using the app since Jan 2003. Yesterday, it refused
to start. Absolutely nothing happens when he double-clicks on the
exe in MyComputer.
In two previous cases, the user has been able to create a new User
with admin priveliges and run the app with that user.
Both apps used the same installer. Coult the insaller have installed
the program three years ago and done something that is causing Windows
to refuse the program now?
This is really starting to concern me.
 

Chuck Herndon writes:
these expired on the specific user?
I can testify that D3 and XPSP2 go along nicely - no side effects (apart
from poor programming, of course).
--
Ben
 

Chuck,
now starts and operates correctly? If so, the problem is obvious.
Their user account doesn't have permission to do something which
the application is doing.
This typically means either registry or file/directory access. Under
many corporate Windows/NT systems, security is managed from
central servers and thus, changes can be made without the user's
knowledge. i.e. some sys admin 500 miles away can decide that
no user should be accessing a certain registry key and push it out
to all his users. Many IT departments lock down the registry to
only keys known to supported applications.
You honestly need an list of all registry keys, files, and directories
you need to access on start-up. Ideally, you should test for each
on these on start-up and if you can not access them, display a nice
error message, and then exit.
run under Windows/XP or you need to buy, use, install, and test
your application under XP.
 

do you have a computer you can reproduce this on? if so,
you should use the "filemon" and "regmon" from www.sysinternals.com
that should tell you what your program is trying to access that gets
denied...
-john