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.
Reply With Quote