VB6 Apps and Vista
Discussion of Installation of Vb6 Applications on Vista under the new default limited access standard user.
Original Author: Anthony Awx
Code
While this is not a 'code' article per say, I believe it is worth posting here, since most of us want our applications to work on Vista (right?). No votes necessary - just some food for thought to perhaps assist you in making your applications work on Vista, or, so you know what to expect. I hope you find it helpful.
I (like perhaps many of you) am trying to figure out how we can use our apps on Vista. The vb6 apps themselves will work on Vista. The largest 'snag' of it all is, in Vista, ALL applications get run as a standard (non-admin) user.
While some Win2000 and XP systems are set up like this, typically, they are in large corporate environments where workers UNDERSTAND they cannot install or run any software they want. On Vista, ALL USERS will be faced with this limitation, and I fear, will not understand how to get software installed (I am beginning to wonder if Vista will be successful at all).
So, over the past several weeks, I have been tinkering around, trying to resolve the following objectives:
1) Enable a standard (non-admin) user to INSTALL our software.
2) Enable a standard (non-admin) user to RUN our software.
I want do discuss each one, because I believe they are very important to understand, and, I am looking for any additional opinions and thoughts on these very essential topics:
===========
1) The first one (INSTALLING as non-admin) is perhaps a bit contraversial. The whole purpose (I presume) of a standard user is to NOT allow them to install software. However, our users right now pretty much ALL run on single-user (non-corporate) systems, which means, whether they realize it or not, they are operating with full admin priviledges, and can therfore install any software they choose.
Installers typically WRITE FILES to the c:program files folder, and make several registry entries (ocx and dll files). Both of these tasks are impossible as a standard user.
Therefore, a standard user under Vista (again, this is THE DEFAULT), in order to install most software, will need to run the installer as admin.
Will our users understand how to do that? Hmm.. I think they might just think its broke, or, doesn't work with Vista, and move on to another piece of software.
People don't read instructions -- they double click, and click OK OK OK. If the message says RUN THIS INSTALLER AS ADMIN etc etc, they are just going to click OK. Nothing will happen, and they will wonder what is going on. They will not understand what 'AS ADMIN' means, and my guess is, we will lose half of our prospects!
Our solution?
Well, still working it out, but here is what we KNOW WILL WORK:
1) Wrap the OCX and DLL files into the EXE.
There is a very nice software program called molebox that enables you to wrap your dll and ocx files into your vb6 exe. When your user runs the exe, the dll and ocx are extracted into MEMORY instead of getting registered with the registry. We are still testing it out, but so far, it has been a dream come true. Highly recommended!
2) Set the default install path to the Vista equivalent of c:documents and settingsall usersapplication dataappname (I believe it is c:userspublicapplication data).
I don't like doing this, but right now, I dont see any other way to enable Vista users to be able to install software without having to understand the admin rights system. The net result of installing here is what a user running Win98 or WinME or XP-with-admin-rights gets - just double-click the installer, click NEXT NEXT NEXT or OK OK OK, and it gets installed.
==========
2) Enabling a standard user to RUN the application is highly dependent on WHERE the application is installed.
Up until now, we have installed all applications and its data files together -- in other words, everything gets installed into c:program filesappname, and the .exe expects to be able to read and write files and folders within that directory.
Apparently since Windows 2000, the recommended methodology is to write the data files to c:documents and settingsall usersapplication data{companyname}{appname} or c:documents and settings{your_user_name}application data{companyname}{appname}.
YUK! No offense, but our users are not developers or very technical. Add the fact that the application data folder is HIDDEN by default, there was just no hope to using this.
Vista changes (or forces upon us) a revisit to this. You see, in Vista, EVEN IF YOU ARE THE ADMINISTRATOR running an application, the application itself DOES NOT RUN with admin rights. This means that the application CAN NOT WRITE to its own folder in the c:program files folder. In other words, if you application sits inside of c:program filesapp1, and tries to write a file named c:program filesapp1data.txt, it will fail in Vista! Note: You can FORCE the application to run using admin rights, but most users will not know how to do that, and, it takes several extra steps to do it.
The solution:
1) Recode our software to point all of its reading and writing to the ..application data folder mentioned above. I personally don't like this, but, perhaps in the long run, users will get used to it. I think the application, and its data, should be in one place - I may be in the minority on this though.
2) Install the application as well as the data files into the ..application data folder. I talked about this above. Not sure this is a good way to do it, but it is transparent to the user, and more importantly, easier for users to get INSTALLED since they wont need to be admin to install the files there.
===============
I hope this is helpful to some of you, and, I hope some of you will contribute to the thread. I am certainly not an expert at any of this, and am hopeful some of you guru's out there can contribute some godly logic to this.
Thanks -
--
Anthony Dunleavy
http://onenerd.blogspot.com/
Loading Comments ...
Comments
No comments have been added for this post.
You must be logged in to make a comment.