I'm working on making a vb6 application compatible with vista. I'm here to ask about what can cause permission problems. I don't have my own copy of Vista to test on yet, so I need a general idea what I can and can't do. I've done a quite a bit of searching, but all the stuff I can find just sortof misses the points I really want to know.
Currently the app writes to program files. I am going to be moving all the application data to the UserAppData folder, but what am I allowed to do in that folder? Am I allowed to create a subdirectory in UserAppData? Can I delete folders and files there? Do I get a special folder for my program or something?
The app also writes some 'save' files to program files, and those will be moved to a folder in my documents. Once again, do I need permissions to create folders and files there, and can I delete files/folders?
The application also includes an updater, which downloads files from a server then shuts down and starts a local updater program [the program might update the local updater before running it] which uses regsvr32.exe to register any new DLLs and EXEs. This requires writing to program files, so I need to know how to elevate permission when updates are going to be installed. I also need to know if regsvr32.exe is going to be causing problems.
Don't pay attention to this signature, it's contradictory.
For AppData/MyDocuments, you are allowed to perform the usual file/folder operations (with the rights of the user, who should have full permissions for them), and for AppData at least you should create a folder for your program (to keep it tidy, and make other programs less likely to fiddle with your files).
Note that there are two per-user AppData folders, AppData_Local which stays on that PC, and AppData which will be available on other PCs (on the same network) that the user logs in to.
As to the updater, that will take a bit more effort.. but I'm afraid I don't know what. All I can say for sure is that using regsvr32.exe requires admin permissions.
I have to say, google is being brutal. Lots of articles about vb.net, or about COM, or about UAC, but nothing about actually using UAC in vb6. It's incredibly frustrating.
Chances are this post will end up being the top entry.
Last edited by alkatran; Feb 18th, 2009 at 02:00 PM.
Don't pay attention to this signature, it's contradictory.
I am facing the same problem trying to update my app to Vista. I have files thru-out my program that write to App.path and also have a program updater. I have just got more confused by reading all the articles i have read, seems some say one thing and the other says something different. i have finally decided to use CSIDL_COMMON_APPDATA to store my apps files so all users can find them.
had a hard time determining if to use CSIDL_COMMON_DOCUMENTS or CSIDL_COMMON_APPDATA. could not determine for sure by asking, so i decided
CSIDL_COMMON_APPDATA was best because on my xp thats where Google, kodak and everyone else puts their data. I have more questions as my program produces roofing estimates and allows the user to create folders to save bids in like Bids January, bids February etc. Also it has a file backup to a usb flash drive and a restore to App.path. Also emails rtf documents. Am also going to have to consider existing customers who have a lot of files in App.path. I have attached a zip i got from i think vbWire that shows the paths to all the folders.
I wish there was something written that was not so technical and step by step.
I will keep you posted with new info. just bought a new pc for Vista, but have not purchased vista yet. Microsoft should have never allowed App.Path
if it can't be used.
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
i have finally decided to use CSIDL_COMMON_APPDATA to store my apps files so all users can find them.
had a hard time determining if to use CSIDL_COMMON_DOCUMENTS or CSIDL_COMMON_APPDATA. could not determine for sure by asking, so i decided
CSIDL_COMMON_APPDATA was best because on my xp thats where Google, kodak and everyone else puts their data.
The difference between _AppData and _Documents is that the user will easily find the files in _Documents (as they will be shown in "My Documents" or "Shared Documents", the ones in _AppData are hard for them to find (but not impossible).
The _Documents folders make sense if you have set your program up to be associated with the files (ie: double-clicking on the file opens it in your program), otherwise _AppData would be the better choice.
Microsoft should have never allowed App.Path if it can't be used.
It can be used, but not for every file-based purpose.
Vista developer documentation was posted by Microsoft about three years ago, when the betas were first provided to developers. Since so much time has passed some of it can be harder to find now because a lot of new things have happened.
While many of the MSDN articles, White Papers, webcasts, etc. are still around, their links have been pushed off the home pages of MSDN, the Vista Developer Center, Channel9, and DevReadiness.org. It's a lot like looking for info on VB6 or classic ASP anymore: you snooze, you lose.
We also have to face the fact that lots of developers have left VB6 for greener pastures since well before Vista came out. Some went to .Net, others to Delphi or C++ or got disgusted with Microsoft and now tinker with Linux or PHP out of frsutration. That means there is a lot less being published to the Web about VB6 and Vista than there was for VB6 and XP - though even that was mostly how to get dumb Win9x programs running under XP in AppCompat mode. Most people don't even know how to write a proper XP program in VB6 today.
And that's where the problem began.
When Win2K and then WinXP came out, the typical VB6 guy's solution was to always run as admin. They just haven't made the leap from DOS/9x to NT OSs even today. Those protected directories were meant to be protected under Win2K and WinXP as well, and programmers were supposed to start respecting the rules.
They didn't.
The result was that Windows suffered attacks of being "insecure" to the point where Microsoft was forced to accept that Joe User was never going to "get it." The solution was UAC.
If you locate and dig through the Vista developer docs you'll find answers to all of the questions raised in this thread. There is a whole MSDN article on program updating alone, as well as numerous resources that give the advice about self-updating: "Don't do it."
Since Microsoft quickly came to realize .Net is a failure for shrink-wrapped software, ClickOnce just wasn't going to be the answer to self-updating that they had expected. That seems to be the motivation for the article Teach Your Apps To Play Nicely With Windows Vista User Account Control.
Other problems come from using deprecated installer technologies like InnoSetup or the PDW. These work, but they are second-class citizens in Windows and only work via special application compatibility shims. Things get even messier with undisciplined techniques like shelling runs of regsvr32. The recommended approach is to create a proper MSI installer package, often in concert with registration-free COM which goes a long way to eliminate the DLL Hell that resulted from Win9x installation approaches.
Anyway, I have attached a small demo that shows one way that a program can perform some elevated functions by starting a secondary "child" process.
Compile both programs. Then run ChildProcess.exe and you'll see that it is not elevated. Then run MainProg.exe, where you will see a button for starting ChildProcess.exe elevated. Note that per Vista guidelines this button displays the UAC Shield.
Everything in the demo has been covered here at this site many times, and is also described in numerous MSDN articles and White Papers. None of it is secret.
So all I need to do is just run the updater if the user is currently an admin, and if they aren't then I only need to specify "runas"?
Thank you.
What purpose does "MainProg.exe.manifest" serve? I've seen it mentioned for com-free stuff, but we aren't compiling a DLL here. From what I understand it's simply a local version of the information usually stored in the registry, so multiple versions don't conflict with each other.
What is the purpose of InitCommonControls? It seems unrelated to everything else.
Last edited by alkatran; Feb 19th, 2009 at 11:05 AM.
Don't pay attention to this signature, it's contradictory.
A manifest file is for the benefit of Windows, and tells it how to treat your program - it can include various things, such as whether Admin rights are required, which version of Common Controls you want to use, etc.
InitCommonControls is to enable a different version of Common Controls to the one that VB tries to use by default - which means your program uses themes (eg: buttons with rounded edges and nicer colours), rather than the usual 'old fashioned' style of controls you get with VB programs.
Side note about the updated common controls: I inserted the code, and copied only the "use shiny controls" part of the manifest to the program I was working on. Buttons set to 'graphical' style aren't changed, and the option buttons are showing as black on black. I think I'll stick to the old style controls for now.
Don't pay attention to this signature, it's contradictory.
Side note about the updated common controls: I inserted the code, and copied only the "use shiny controls" part of the manifest to the program I was working on. Buttons set to 'graphical' style aren't changed, and the option buttons are showing as black on black. I think I'll stick to the old style controls for now.
If you do include a manifest be sure to test it after compiling. I included one a couple of years ago and it worked fine in the ide, but after compiling my program
would open briefly and crash. I was probably doing something wrong, but its something to keep in mind
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
i am starting to put together a checklist.
Sub Main
determine if user has converted sample files to usable files
if yes then user is not running Vista, so do not extract files from resource file
If no then Create Folders CSIDL_COMMON_APPDATA\companyName\AppName\AppFolder
Extract resource data to AppFolder
End Sub
Determine if cdo will email files as attachments
Determine if my email error reporting works that emails silently thru my online JMail will work.
Determine if File Save as works to allow folders to be created and bids to be saved to these folders.
Determine if my program updater will work that replaces a exe in use
Determine if my File backup and restore to USB flash drive works correctly
Determine if PrintWindow.api that writes a temp file to app.path works in the new path correctly
Determine if context sensitive help works correctly in new path.
Change all Sendkeys
Make a manifest file
Be sure all purchased ocx's get registered and work correctly
Determine if recent file list works correctly in new path.
I am thinking that to start I only need to change the path to start with, then get out my rabbits foot and fire up vista. I am buying Vista tonight so i should have some answers to problem areas soon
Add to this list anybody ?
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
Probably first check the third party ocx's are Vista compatible before buying.
Thanks but too late they have been bought for a couple years.
One vendor is out of business and his ocx cannot be used on another computer without the license. this is a nice menu control, but i may have to replace or make the setup on my xp. Do you know any menu controls similar (Included)
The other ocx's are vista compliant
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
You can make a standard VB6 menu into that by doing OwnerDrawing on the menu. Or you could do it in VB.NET and make it a COM exposed dll as VB.NET makes that kind of menu real easy.
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum.
One lucky thing for me is that we are currently at the end of an upgrade cycle. We're sending out new CDs to customers, not pushing out updates. I won't need to check if files are in the correct location, I will simply have an importer for last year's stuff. I assume I can at least READ from program files.. right?
Actually, we would like to push it out as an update but our update system collapsed on itself. We were using an FTP site, and one of the last windows updates nuked the site (Really, really, well.). The irony is that I had put out a better updater about a month before, but not enough customers had updated for it to matter. [The old updater used the inet control, which was a nightmare].
Last edited by alkatran; Feb 19th, 2009 at 03:27 PM.
Don't pay attention to this signature, it's contradictory.
Common Controls 6.0 are required in order to display the UAC Shield on buttons, etc. that will result in an elevation prompt. Not displaying the Shield doesn't hurt anything but it violates the UI guidelines and would keep your software from ever getting Vista certified.
The trustInfo part of the manifest is used to tell Vista two things:
That your program is Vista-aware.
What level of privilege your program requries.
There are new, explicit entries for "Vista aware" and "Windows 7 aware" now as well. Without them the presence of a trustInfo entry indicates "Vista" level of awareness, which turns off AppCompat shims for registry and filesystem virtualization and a few other small things.
A manifest can cause your program to fail in at least ways:
Bad (syntax) manifest.
Embedded manifest not a multiple of 4 bytes in length (which results in bad syntax due to NUL padding).
Failure to call InitCommonControls, or call it early enough in the program.
When you create folders under CommonAppDataFolder you need to set permissions on them. By default you end up with a folder where files can only be updated and removed by the "owner" (the user who created them), even though everyone can read them.
Common Controls 6.0 are required in order to display the UAC Shield on buttons, etc. that will result in an elevation prompt. Not displaying the Shield doesn't hurt anything but it violates the UI guidelines and would keep your software from ever getting Vista certified.
The trustInfo part of the manifest is used to tell Vista two things:
That your program is Vista-aware.
What level of privilege your program requries.
There are new, explicit entries for "Vista aware" and "Windows 7 aware" now as well. Without them the presence of a trustInfo entry indicates "Vista" level of awareness, which turns off AppCompat shims for registry and filesystem virtualization and a few other small things.
A manifest can cause your program to fail in at least ways:
Bad (syntax) manifest.
Embedded manifest not a multiple of 4 bytes in length (which results in bad syntax due to NUL padding).
Failure to call InitCommonControls, or call it early enough in the program.
When you create folders under CommonAppDataFolder you need to set permissions on them. By default you end up with a folder where files can only be updated and removed by the "owner" (the user who created them), even though everyone can read them.
Certification is not an issue for our software, and neither is other users being able to read the files.
Question: Since the update program is running as admin, will file system virtualization not be used?
Don't pay attention to this signature, it's contradictory.
Common Controls 6.0 are required in order to display the UAC Shield on buttons, etc. that will result in an elevation prompt. Not displaying the Shield doesn't hurt anything but it violates the UI guidelines and would keep your software from ever getting Vista certified.
The trustInfo part of the manifest is used to tell Vista two things:
That your program is Vista-aware.
What level of privilege your program requries.
There are new, explicit entries for "Vista aware" and "Windows 7 aware" now as well. Without them the presence of a trustInfo entry indicates "Vista" level of awareness, which turns off AppCompat shims for registry and filesystem virtualization and a few other small things.
A manifest can cause your program to fail in at least ways:
Bad (syntax) manifest.
Embedded manifest not a multiple of 4 bytes in length (which results in bad syntax due to NUL padding).
Failure to call InitCommonControls, or call it early enough in the program.
When you create folders under CommonAppDataFolder you need to set permissions on them. By default you end up with a folder where files can only be updated and removed by the "owner" (the user who created them), even though everyone can read them.
What does Vista Certified mean ?
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
There are number of Windows Logo Program type things for independent software vendors. It involves submitting your software to Microsoft for testing after it has passed local tests using downloadable testing harnesses.
You can't "logo" your software (whether in a box or as a download) without passing at a certain level.
It is meant as a marketing tool, to let you say your software works on Windows w/o screwing up peoples' machines and adheres to user interface guidelines, etc. Even if you do not plan to market your software the tools and documentation can be useful though.
Once source of such materials is at DevReadiness.org, where you can find lots of Vista and Win7 materials too.
I installed vista ultimate and installed my software thru a setup program. I installed as Administrator not everything works as it should. Program updater and sending mail thru cdo do not work. After i get things smoothed out I will address them one by one. My main concern now is: I setup a standard user account and my desktop and start menu shortcuts are not there. How can i make these shortcuts available to a standard user ?
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
Running a program while logged on as a user in the Administrators group doesn't not give the process admin privileges in itself.
Windows 6.x OSs apply "legacy installer detection" heuristics as part of process initiation to detect things like a PDW or other old-style installation EXE. This results in a request for elevation prompt before the process gets started.
If your setup fails those detection tests it will run with standard user rights. If it doesn't have an application manifest declaring "Vista awareness" various AppCompat shims will be applied by default as well, including registry and filesystem virtualization.
The end result is that a non-detected installer may not register components system-wide, shortcuts may be placed in per-user locations, etc.
But there is always the more basic question: Where (in what folder) did your install process try to put the Start Menu shortcuts?
It aggravates me a little that no major VB-oriented forum site was willing to establish a "Vista Issues" forum back when it might have done some good.
By now we'd have FAQs in a central location, along with a good history of "coping with Vista" threads in one place for people to search and browse.
Live and learn (I hope) but the horse is long out of the barn now.
Sadly, a UseNet group for VB6 & Vista was set up - though it was quickly overrun by appliance operators (end users, net admins) asking off topic questions. It is now largely abandoned.
Running a program while logged on as a user in the Administrators group doesn't not give the process admin privileges in itself.
Windows 6.x OSs apply "legacy installer detection" heuristics as part of process initiation to detect things like a PDW or other old-style installation EXE. This results in a request for elevation prompt before the process gets started.
If your setup fails those detection tests it will run with standard user rights. If it doesn't have an application manifest declaring "Vista awareness" various AppCompat shims will be applied by default as well, including registry and filesystem virtualization.
The end result is that a non-detected installer may not register components system-wide, shortcuts may be placed in per-user locations, etc.
But there is always the more basic question: Where (in what folder) did your install process try to put the Start Menu shortcuts?
Good question That I will have to find out. My installer http://www.gdgsoft.com/info/contact.aspx adds the shortcuts. I will have to find out. Finding anything in vista is a journey. Some things are put somewhere and then next time I look they are somewhere else. I can see vista is not for people that manage files
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
It aggravates me a little that no major VB-oriented forum site was willing to establish a "Vista Issues" forum back when it might have done some good.
We wanted something like that to happen here, but issues like available time and higher priorities meant that it hasn't really happened.
We've got a Classic VB FAQ article on Vista, but that is obviously lacking quite a bit of info compared to what could be done (it just covers the common issues, and not in much detail).
There has been intent from people to create more Vista+ related articles (and not just specific to VB6), but unfortunately as is often the case it hasn't happened yet (and depending on time/priorities, it may not).
The next FAQ article I'm intending to write is for special folders (including code for the CSIDL and Vista+ versions), which will improve things somewhat, but still leaves several issues to be covered.
Of course you are more than welcome to create FAQ articles yourself, and they will be added to the relevant FAQ index(es), and if apt linked from relevant existing articles.
We wanted something like that to happen here, but issues like available time and higher priorities meant that it hasn't really happened.
We've got a Classic VB FAQ article on Vista, but that is obviously lacking quite a bit of info compared to what could be done (it just covers the common issues, and not in much detail).
There has been intent from people to create more Vista+ related articles (and not just specific to VB6), but unfortunately as is often the case it hasn't happened yet (and depending on time/priorities, it may not).
The next FAQ article I'm intending to write is for special folders (including code for the CSIDL and Vista+ versions), which will improve things somewhat, but still leaves several issues to be covered.
Of course you are more than welcome to create FAQ articles yourself, and they will be added to the relevant FAQ index(es), and if apt linked from relevant existing articles.
That would be great, I have been all over the internet reading the last couple days. I thought by installing vista a lot of question would be answered, instead I have more eg a folder showed up called VirtualStore with a copy of my app. I think a Faq with different situtations would be great. My app is made for 1 person, the pc owner to run my app and thats all. xp makes me fell in control in Vista I'm sitting in the back seat
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
We wanted something like that to happen here, but issues like available time and higher priorities meant that it hasn't really happened.
I sure wasn't pointing fingers, and I appreciate what was done in terms of FAQs.
The aggravation is on my end. Mostly it comes because people are now asking a lot of Vista questions that I have worked out on my own, seen answers for that others have worked out, etc., but...
I can't find the old links easily now on the one hand and I often can't recall what I did when I worked out issues myself. So much is now built into components and processes I now use w/o thinking that I have to go on a voyage of rediscovery to work out what I had done so I can share it.
So few brain cells left, so many questions arising now.
At least Windows 7 didn't alter the landscape much, and most Vista rules, tips, and tweaks still apply.
I'll add that Vista was double trouble for VB6 users.
The issues are almost entirely identical with C++, VB.Net, or C#, but with Microsoft dropping classic VB they have little motivation to provide documentation in terms Joe VB'er can grok and apply.
I agree with this thread being very usefull. Still trying to get my app to play nice with vista. I have added a manifest to my exe and it puts a shield on my desktop shortcut, but i do see what benefit it gives. The app does not seem to act or do anything different. Right now i am struggling with this:
Install as administrator and it adds a desktop shortcut and startmenu shortcut. These cannot be seen by a standard user and my installer has a list of install variables, but not for vista. So the way i see it I will have to write a bat file to install shortcuts to these locations CSIDL_COMMON_
STARTMENU and CSIDL_COMMON_DESKTOPDIRECTORY or have a seperate exe
write it, or have the main exe start atomically when installed and write them when started.
After I overcome this obstacle will my exe have the rights needed for standard users to use ?
I have also noticed that windows, google and others store a lot of data in ProgramData eg: log files , dlls, shortcuts it seems to be a place to put stuff that will not be moved.
I am going to make a new thread on how to write my shrtcuts needed
Waiting for a full featured smart phone with out marrying a provider
Go Android
Go raiders
And thus as I try to warn people about, not using Windows Installer takes you deeper and deeper down the rabbit hole. This is why Microsoft documentation on Vista development urges the same advice, going back to the docs released with the earliest betas 3 years ago.
I see you are trying the Common Start Menu location for your shortcuts now. This should solve your frustration but Vista is no different from WinXP on this. I'll bet you were installing on XP and then not trying another user, hmm?
I wouldn't create Desktop shortcuts. Most users consider that crude and rude and Microsoft urges that you refrain from it. Your call of course.
In Vista the folder ProgramData is where CSIDL_COMMON_APPDATA points.
This is the folder you create an application folder under to hold any per-machine files your program uses that the user does not need to directly operate on (say, via Explorer). INI files, MDBs, etc. can go here.
Note that subfolders created here (and files created in them) can be read by all but only updated and deleted by the Owner (creating user). Your installer is expected to change the security on any such subfolders, sub-subfolders, and files to produce the desired result. For example you'd probably want an MDB file to have all but delete rights for Everyone, however the LDB lockfile Jet creates and destroys means you want its folder permissions set to grant full access for Everyone for files created in that folder.
You can stuff DLLs and such here, but that defeats most of what UAC is trying to do to protect the machine from malware. It is a lazy way out used by some software vendors that want to auto-update but don't want to do it properly. Of course "properly" can be a chore too.
... will my exe have the rights needed for standard users to use ?
It also applies to WinXP, because if WinXP is used properly (i.e. users never run as admin, security on system folders is not tampered with) about 90% of the "Vista issues" are also seen on XP. UAC is merely an attempt to make things more secure even if stubborn users insist on running as admin.
In general though your question can only be answered depending on whether your program declares itself "Vista aware" or not. This is done by including the trustInfo section in the application manifest. By the way: Windows 7 introduces a new application manifest item to declare "Win6.0 aware" and "Win6.1 aware" but most programs will be able to ignore this (yes Virginia, Windows 7 has things that Vista doesn't - so there are new AppCompat issues).
If your program is "Vista ignorant" it will be subject to several automatically applied AppCompat shims. Registry and filesystem virtualization are the main ones. These let your program "break the rules" and store into off-limits registry and filesystem locations, jollied along by Vista (which redirects these into "virtual store" areas).
Your program might work right, or it might not. The usual problem comes from a program storing into HKLM or System32, etc. and thinking the info will be visible to all users - which it will not. Each user gets a private, virtualized copy of the data.
Relying on COM self-registration (whether by the VB6 runtime linking to the library or by running regsvr32) can also result in a virtualized, per-user component registation. Always have your installer register everything, or else use "reg-free COM" SxS isolation (which is also a WinXP feature).
If your program declares itself Vista aware, trying to write to a protected location raises an exception.
Reply With Quote
Originally Posted by isnoend07
