Marty,
Thanks.
Being able to specify a startup ini file for dBase can be implemented during the deployment process. I have tested it and it works fine with a short pathname.
While you are adding support for embedded spaces and long path and file names check the maximum length of the command line dBase can take. I found a limit somewhere around 150 characters.
So, two of the three dBase vista security model issues are solved:
1 - controlling placement of BDE temporary objects.
2 - controlling placement of the dBase startup ini file.
The third one, separation of code requiring a full admin access token from code that can run with a standard access token or a filtered admin access token, is still to be solved.
However, I have managed to figure a way to manage PLUSrun's manifest requestedExecutionLevel.
The current issue is PLUSrun has a default requestedExecutionLevel = requireAdministrator and this requires the application to be run with a full admin access token or the user to know the credentials for an account with administrative privilege. It also means the application is blocked if run on a user login requiring extra steps to unblock it. The current deployment of PLUSrun needs to overwritten with a new PLUSrun.exe.manifest with a requestedExecutionLevel = asInvoker to workaround this issue. This has risk.
Personally I would suggest the default deployment of PLUSrun be with an AsInvoker manifest. However, for those executables that require write access to locations needing a full admin access token this will cause problems. As M$ states, the two code types need to be separated. This for PLUSrun is mutually exclusive and for the developer a conundrum.
I wrote an ApplicationStart utility, using the ShellExecute API that can start any dBase executable, taking the application being started PLUSrun properties from an ini file and successfully had it working BEFORE you pointed out the ability to run an executable directly specifying PLUSrun's startup ini file. The last remaining piece I had to code was the ability to run PLUSrun.exe with a specific manifest. I have not done that yet. I sort of ran out of steam and needed to do some other stuff.
My strategy was to create two new PLUSrun executables and accompanying manifest files:
1 - PLUSrun.asInvoker.exe and PLUSrun.asInvoker.exe.manifest
2 - PLUSrun.administrator.exe and PLUSrun.administrator.exe.manifest
Using my ApplicationStart utility and an ini file entry of requestedExecutionLevel=<level> I would be able to start any executable with the needed manifest.
Placement of these extra PLUSrun executables and manifests can be:
1 - copying and renaming PLUSrun.exe from wherever it is installed to the current startup folder during deployment
2 - placing the PLUSrun.asInvoker.exe.manifest and PLUSrun.administrator.exe.manifest files during deployment
This option is static and has risk. Any new PLUSrun deployment after an application deployment would need the PLUSrun.asInvoker.exe and PLUSrun.administrator.exe files to be updated. Not easy to manage.
An alternative option can be copying and renaming PLUSrun.exe from wherever it is installed to the current startup folder and creating the accompanying manifests at runtime in the ApplicationStart front-end. Not an elegant and simple solution either but PLUSrun.exe would be the latest release.
My personal recommendation would be to have the standard PLUSrun deployed with it all in place and provide the ability to start any dBase executable with a specific manifest. This approach will provide the developer with the ability to spawn dBase executables fit for access purpose and comply with the Vista security model. dBase server applications could be built to perform specific privileged tasks.
The only remaining issue would be a new one as a result of the ability to spawn dBase service executables fit for access purpose. How can information be exchanged between them?
I was looking at FUNCKy's interprocess communication capability as a possibility as the amount of information needing exchange would not be large. A dBase table could be used or an ini file. Synchronization would need to be done with semaphores, something FUNCKy can provide as I have had problems being able to fully interface to the M$ CreateMutex/CreateSemaphore API set.
Right now I do not have any code that requires a full admin access token so it is not urgent for me to solve this last Vista security model issue.
However I feel it is imperative dBI provide a Vista security model fully compliant dBase release. Multi-user applications are critically dependent on it, particularly applications deployed into terminal services environments.
Thank you for the help and listening to my needs.
regards, andrew
Post by Marty KayAndrew,
I don't recall seeing this documented anywhere, but I just verified that
the -C command line switch
myApp -CC:\AltIniPath
where myApp.exe is a dBASE Plus application file.
Also - we are now testing changes to support using double quotes around
the -C path to support
embedded spaces and long folder names.
- Marty -
Martin Kay
dataBased Intelligence, Inc.