Edit PDW for Vista

I have been selling roof estimating software for about the last 6 years written in vb6 and have always used PDW for installs. I have learned to always edit the setup1.lst as it seems almost always something is not right. I have been reading about Vista the last couple days and have ended up totally confused. Seems the discussions have a lot of different options on what should be done, even arguments. Checked into some installers like i did 6 years ago and they seem to all have problems and written with stuff i don't understand like("{}") i used to use that in lotus 123, don't have clue what it means now. Last night i decided to not sell to anyone using Vista, but then this morning my first email was from a customer who bought my program and has upgraded to Vista and nothing works.So here i am again looking for answers. With all the installers i read about i can figure out why someone does not write an upgrade for PDW. written in Vb just for VB and people like me could edit it and configure it. I sure would buy such a product. The more i think about the possible problems with my app and vista the more questions i have. I have a list and i hope i can get help with it.
How to install ocx's and dll's i have purchased and other ocx's flexigrid etc ?
I realize this cannot be hardcoded:
Does my exe go in Program Files or under C:\All Users\Myapp or C:\users\myapp ?
I realize that that all my App.Paths will no longer work
Do my ini, rtf and text files go under C:\All Users or C:\All Users\Myapp?
Then my program produces .bid files that are saved as binary like Customer Last name, customer address.bid where wuill these be saved?
These bid files are opened by using the customers commom dialog using Api
Will this still work?
I also have selection to save-as to allow customers to create folders and save to different folder again using the api to open the common dialog. Will this still work?
My app also does 1 write to the registary to HKEY_Current_User for regristration will this work?
Any help with any of this will help

Quote:

---

Originally Posted by isnoend07

I have been selling roof estimating software for about the last 6 years written in vb6 and have always used PDW for installs. I have learned to always edit the setup1.lst as it seems almost always something is not right. I have been reading about Vista the last couple days and have ended up totally confused. Seems the discussions have a lot of different options on what should be done, even arguments. Checked into some installers like i did 6 years ago and they seem to all have problems and written with stuff i don't understand like("{}") i used to use that in lotus 123, don't have clue what it means now. Last night i decided to not sell to anyone using Vista, but then this morning my first email was from a customer who bought my program and has upgraded to Vista and nothing works.So here i am again looking for answers. With all the installers i read about i can figure out why someone does not write an upgrade for PDW. written in Vb just for VB and people like me could edit it and configure it. I sure would buy such a product. The more i think about the possible problems with my app and vista the more questions i have. I have a list and i hope i can get help with it.
How to install ocx's and dll's i have purchased and other ocx's flexigrid etc ?
I realize this cannot be hardcoded:
Does my exe go in Program Files or under C:\All Users\Myapp or C:\users\myapp ?
I realize that that all my App.Paths will no longer work
Do my ini, rtf and text files go under C:\All Users or C:\All Users\Myapp?
Then my program produces .bid files that are saved as binary like Customer Last name, customer address.bid where wuill these be saved?
These bid files are opened by using the customers commom dialog using Api
Will this still work?
I also have selection to save-as to allow customers to create folders and save to different folder again using the api to open the common dialog. Will this still work?
My app also does 1 write to the registary to HKEY_Current_User for regristration will this work?
Any help with any of this will help

---

Hi,

Quite a story! :) I can answer most of your questions, to begin with the installer:

I use InnoSetup, it's freeware and fearly easy to use. If you combine it with ISTools, you can import PDW projects, which makes it much easier to work for you. Best of all, ISTool is also freeware.

I've written a sample module that will take care of the App.Path issue, and it will be resonably easy to change you code to use it. You most likely will have to make some changes, but the sample project basically does what you're mentioning, and also demonstrates the use of extra folders.

The problem we (programmers) now facing, is that Microsoft no longer allows saving data into the installation folder - typically "Program Files\AppName". We actually shouldn't have done so from W2K on, and the sample will work on Xp and W2K as well. Honesty permits me to say I didn't check W2K, I no longer have a W2K box.

Since I've stopped using the registry to store app information a long time ago, I can't tell what will work and what not, others will probably be able to tell you.

When you update your code to use the proper folders and save all your files in that new location, you customers won't notice the difference, whether they're using XP or Vista.

HTH

Quote:

---

Originally Posted by Jottum

Hi,

Quite a story! :) I can answer most of your questions, to begin with the installer:

I use InnoSetup, it's freeware and fearly easy to use. If you combine it with ISTools, you can import PDW projects, which makes it much easier to work for you. Best of all, ISTool is also freeware.

I've written a sample module that will take care of the App.Path issue, and it will be resonably easy to change you code to use it. You most likely will have to make some changes, but the sample project basically does what you're mentioning, and also demonstrates the use of extra folders.

The problem we (programmers) now facing, is that Microsoft no longer allows saving data into the installation folder - typically "Program Files\AppName". We actually shouldn't have done so from W2K on, and the sample will work on Xp and W2K as well. Honesty permits me to say I didn't check W2K, I no longer have a W2K box.

Since I've stopped using the registry to store app information a long time ago, I can't tell what will work and what not, others will probably be able to tell you.

When you update your code to use the proper folders and save all your files in that new location, you customers won't notice the difference, whether they're using XP or Vista.

HTH

---

Thanks for the information and the file and links i have tons of files to rewrite this will be an adventure
If you run accross anything about registering the ocx's and dll's please let me know. That info seems to be scarce

The PDW isn't the problem. As already described, the biggest issue is where you locate things like data files.

A secondary issue is the use of registry keys outside of HKCU.

As far as installers go PDW and many of the 3rd party packagers are in the same boat. Under Vista they're all second class citizens, though for now Vista will sniff them, wink slyly, and let them run as "legacy installers." You really want to create your packages as .MSI files now.

This isn't really that bad. Microsoft released Visual Studio Installer 1.1 a long time ago for VB6 developers (1999 or so?). It's still available for downloading and use and seems to work fine (within its own limitations, about like those of the PDW in scope though different in kind).


Another hazard is having your installed VB6 program detected as a "legacy program." This causes Vista to try to apply a set of "application compatability shims" to it, and sometimes these shims (especially the registry and filesystem virtualization shims) can lead to erratic behavior.

The way you bypass this is to include an application manifest that has a Vista Trust element in it. When Vista sees a program run with one of these it says to itself "ok, this program is telling me it knows the rules" and runs it without the default set of legacy shims applied. Of course if you break a rule then, Vista kills your program dead. Most of these rules include things like trying to access something outside HKCU or in a protected filesystem location.


The important rules are really pretty simple. Be careful where you put data files and registry entries and avoid anything that requires a user to have admin rights when your program is run. Use the Shell32 API calls or scriptable objects to locate the appropriate standard folders to put data into. VSI 1.1 can be coerced into installing your data files where you need them, but I think the PDW can do this too. Without patching the PDW Setup1 program only knows about a few special folders (for example, it doesn't know about COMMONAPPDATA).

Quote:

---

Originally Posted by dilettante

The PDW isn't the problem. As already described, the biggest issue is where you locate things like data files.

A secondary issue is the use of registry keys outside of HKCU.

As far as installers go PDW and many of the 3rd party packagers are in the same boat. Under Vista they're all second class citizens, though for now Vista will sniff them, wink slyly, and let them run as "legacy installers." You really want to create your packages as .MSI files now.

This isn't really that bad. Microsoft released Visual Studio Installer 1.1 a long time ago for VB6 developers (1999 or so?). It's still available for downloading and use and seems to work fine (within its own limitations, about like those of the PDW in scope though different in kind)


Another hazard is having your installed VB6 program detected as a "legacy program." This causes Vista to try to apply a set of "application compatability shims" to it, and sometimes these shims (especially the registry and filesystem virtualization shims) can lead to erratic behavior.

The way you bypass this is to include an application manifest that has a Vista Trust element in it. When Vista sees a program run with one of these it says to itself "ok, this program is telling me it knows the rules" and runs it without the default set of legacy shims applied. Of course if you break a rule then, Vista kills your program dead. Most of these rules include things like trying to access something outside HKCU or in a protected filesystem location.


The important rules are really pretty simple. Be careful where you put data files and registry entries and avoid anything that requires a user to have admin rights when your program is run. Use the Shell32 API calls or scriptable objects to locate the appropriate standard folders to put data into. VSI 1.1 can be coerced into installing your data files where you need them, but I think the PDW can do this too. Without patching the PDW Setup1 program only knows about a few special folders (for example, it doesn't know about COMMONAPPDATA).

---

Seems i checked out that msi installer a few yrs ago and something i didn't like about it, users had to have some file on their machine or something. Thanks for your input, if you think of anything else i'm all ears.

This is probably a stupid question, Has anyone tried to install their exe into
C:\All Users or C:\All Users\Myapp? That would make things too easy.

Quote:

---

Originally Posted by isnoend07

This is probably a stupid question, Has anyone tried to install their exe into
C:\All Users or C:\All Users\Myapp? That would make things too easy.

---

Hi,

I haven't tried this, but by doing so you are again not following OS rules, which are mandatory from Vista and up. It might work now, it might not. I would strongly advice against it anyway. You really better role up your sleeves, and do it the right way.

I don't know how you coded the App.Path in your application, but can't you use the Public variable pointing to the AppData folder and replace all App.Path instances in your code with it? You've probably coded it something like this:

vb Code:

MyFileToOpen = App.Path & "\DataDir\DataFile.ext"

If that's the case, all you have to do is a search and replace with the new variable and the result would be for example:

vb Code:

MyFileToOpen = m_AppDataFolder & "\DataDir\DataFile.ext"

About the Visual Installer: I've used it a couple of times, but have always found it very hard to configure. Inno Setup isn't - if you use it together with ISTools anyway - and it does know about the "new" folder locations, like AppData. {userappdata} and {commonappdata}.

HTH

Quote:

---

Originally Posted by isnoend07

This is probably a stupid question, Has anyone tried to install their exe into
C:\All Users or C:\All Users\Myapp? That would make things too easy.

---

I haven't seen this option suggested anywhere yet.

On the surface, it does fly in the face of what we've been told about why "Program Files" is protected in Vista. The idea is that if you put programs into a user-writeable folder it would be possible for malware with only user rights to replace legitimate EXE, DLL, OCX, etc. files with "infected" ones that the user would end up running... and things go downhill from there.

However I have seen Microsoft recommend per user installs into a directory under CSIDL_LOCAL_APPDATA in some cases. This was recommended as an option for game programs that require frequent updating. They do warn that this results in an installed copy for each user, wasting disk, and that it leaves your software unprotected against infection. Search for the Microsoft whitepaper: "Patching Methods in Windows XP and Windows Vista."

I suppose we might see anti-malware flag software installed in this manner as a "potential risk" in the future. That could be a negative in terms of the buzz your product gets in the user community down the road, especially if it ever does become an infection target.


The advantange of those "insecure" per-user installs is that it can provide a way for users who have no admin rights at all to install and use your application.

For all but the most trivial VB6 programs this means using Registration-Free COM. Almost every program ends up need a Common Dialog or a Grid control or something. Since Microsoft hasn't offered any tools for reg-free COM in VB6, all but the most knowledgeable developers would need to use one of the few 3rd party pre-packager tools out there. Make My Manifest is a free "beta" tool, and I've seen one commercial tool too. The resulting package only works on XP and later though since reg-free COM is a "new" feature (since what, 2001?).

VSI 1.1 can be used to create non-admin MSI packages. I'm not sure if something like the PDW or Inno Setup EXEs can be run without admin rights though.


Windows Installer has been shipped as part of Windows since at least Win2K. There is little excuse for creating EXE-based setups anymore, and as Microsoft says in "Windows Vista Application Development Requirements for User Account Control Compatibility":

Quote:

---

Use the Windows Installer 4.0 for your setup package. Many of the following requirements are already integrated into the Windows Installer engine. Using Windows Installer for your setup package will assist you with following Windows Vista installation requirements.

---

The easiest way to do that for VB6 programs is to use VSI 1.1, though some 3rd party setup toolkits can do this as well.

This thread is really in the wrong spot if we're primarily talking about installation issues. You might look for Application Deployment under General for existing threads on these issues.


Installation is getting to be a subject almost as intricate as programming itself now. Vista only raises the bar further. While I don't think we need to become experts, Vista is forcing us to be more aware of and a little more literate on the subject.

By the way:

While it is now late in the day for people to start learning how to develop and deploy on Vista, there are still a few of those Microsoft whitepapers and tools posted at Dev Readiness: Files.

Be sure to open the treeview at the left of this page to dig deeper into the list of available resources. Note that many of the links found there are dead now. This material was originally put out there 2 to 3 years ago.

Quote:

---

Originally Posted by dilettante

This thread is really in the wrong spot if we're primarily talking about installation issues. You might look for Application Deployment under General for existing threads on these issues.

---

Indeed - thread moved.

I appreciate all the input, Thank you people
I have 3 roof estimating programs ready to release and have decided to not make this release Vista compliant for users who have already have registered copies and are waiting. These users are not using Vista, but i still have to consider the fact they may upgrade. These programs are not small and contain everything a user could ask for; Context sensitive help, recent file list, ballon tooltips,spell checker
print preview, address book that emails rtf files etc. I have decided to give them a warning of the things they will need to do before upgrading to Vista. Off the top of my head "There's no files in my recent file list" etc
This program contains 37 forms,32 bas modules and 19 classes.
I am still working on making my app vista compliant, but need to slow down a little and take 1 step at a time and make sure i understand each step. Heres
the step i am not 100% sure on, does this look right?
I realize i have to use these files as not to hard code
SHGetSpecialFolderPath
SHGetFolderPath


If hardcoded xp path
C:\Program Files\MyExe.exe
For data
C:\Documents and Settings\Application Data\MyApp\myinifile.ini
C:\Documents and Settings\Application Data\MyApp\myDictionary.txt
C:\Documents and Settings\Application Data\MyApp\Myrtf.rtf
C:\Documents and Settings\Application Data\MyApp\GridData.dat
C:\Documents and Settings\Application Data\MyApp\RecentFileList.ini
C:\Documents and Settings\Application Data\MyApp\Apphelp.chm
C:\Documents and Settings\Application Data\MyApp\Joe Smith. 124 Oak ave.Bid

For Vista if hardcoded
C:\Program Files\MyExe.exe
For data
Users\Application Data\MyApp\myinifile.ini
Users\Application Data\MyApp\myDictionary.txt
Users\Application Data\MyApp\Myrtf.rtf
Users\Application Data\MyApp\GridData.dat
Users\Application Data\MyApp\RecentFileList.ini
Users\Application Data\MyApp\apphelp.chm
Users\Application Data\MyApp\Joe Smith. 124 Oak ave.Bid

You should never hard code 'system' paths like that - as it will be wrong for many users (especially if they are using a non-English version of Windows), as the special folders can be moved and/or renamed.

I haven't checked it yet, but I would assume that the code in this post uses SHGetSpecialFolderPath etc, and would expect it to do so correctly/safely (Jottum's previous code samples have been very well written).

Quote:

---

Originally Posted by si_the_geek

You should never hard code 'system' paths like that - as it will be wrong for many users (especially if they are using a non-English version of Windows), as the special folders can be moved and/or renamed.

I haven't checked it yet, but I would assume that the code in this post uses SHGetSpecialFolderPath etc, and would expect it to do so correctly/safely (Jottum's previous code samples have been very well written).

---

I realize i can not hard code, i changed that part to red and bold, just trying to be sure i understand what a typical path might look like. I am changing all my paths from App.Path

It doesn't matter what the paths look like - just detect the location of the relevant "Application Data" folder (user or common or roaming, depending on whether the data should be shared by all users of that computer, and whether it should follow the user around a network).

For XP, that might return something like this: "C:\Documents and Settings\All Users\Application Data\" (or perhaps "X:\Data\All Users\Application Data", etc).

By using the proper functions, you can be sure that it is correct - and can simply append your sub-folder and file name.

Assuming that you have stored the folder you detected to a variable called strAppData, the full path/name for your first file would be: strAppData & "MyApp\myinifile.ini" (or perhaps strAppData & "\MyApp\myinifile.ini" , depending on the function you use to detect the folder)

Quote:

---

Originally Posted by si_the_geek

It doesn't matter what the paths look like - just detect the location of the relevant "Application Data" folder (user or common or roaming, depending on whether the data should be shared by all users of that computer, and whether it should follow the user around a network).

For XP, that might return something like this: "C:\Documents and Settings\All Users\Application Data\" (or perhaps "X:\Data\All Users\Application Data", etc).

By using the proper functions, you can be sure that it is correct - and can simply append your sub-folder and file name.

Assuming that you have stored the folder you detected to a variable called strAppData, the full path/name for your first file would be: strAppData & "MyApp\myinifile.ini" (or perhaps strAppData & "\MyApp\myinifile.ini" , depending on the function you use to detect the folder)

---

I guess my question should be I do create a folder under Application Data and my files go into that folder right?

That is correct. Using my previous example, you would create the folder: strAppData & "MyApp" (or strAppData & "\MyApp").

If you sell multiple programs, you may even want to make a "MyCompany" folder, and put the "MyApp" folder inside it (but this may cause problems for users who upgrade from previous versions of your program).

Quote:

---

Originally Posted by si_the_geek

That is correct. Using my previous example, you would create the folder: strAppData & "MyApp" (or strAppData & "\MyApp").

If you sell multiple programs, you may even want to make a "MyCompany" folder, and put the "MyApp" folder inside it (but this may cause problems for users who upgrade from previous versions of your program).

---

I have been doing some testing with code i got,i think from here om my xp machine:
This does not work:

HTML Code:

---

Option Explicit

'SHGetFolderPath API: locates special windows folders
Private Declare Function SHGetFolderPath Lib "shfolder.dll" Alias "SHGetFolderPathA" (ByVal hwndOwner As Long, _
ByVal nFolder As Long, ByVal hToken As Long, ByVal dwFlags As Long, ByVal pszPath As String) As Long

Private Const CSIDL_FLAG_MASK = &HFF00
Private Const SHGFP_Type_CURRENT = &H0
Private Const MAX_PATH = 260 'max path length

 
'some usual constants. There are a lot more, just google a bit and you'll find them.
Private Const CSIDL_APPDATA As Long = &H1A 'the {current user}\Application Data folder
Private Const CSIDL_COMMON_APPDATA As Long = &H23 'the {all users}\Application Data folder. Use this if all users will access the same data.
Private Const CSIDL_COMMON_DOCUMENTS As Long = &H2E 'the {all users}\Documents folder (shared documents)


'this returns the path for the selected special folder
Function GetSpecialPath(CSIDL As Long) As String
Dim strPath As String
Dim iReturn As Long
strPath = String(MAX_PATH, 0)
iReturn = SHGetFolderPath(0, CSIDL, 0, SHGFP_Type_CURRENT, strPath)
GetSpecialPath = Left$(strPath, InStr(1, strPath, Chr(0)) - 1)
End Function

'now, an app.path replacement to save you some coding.

Public Function NewPath() As String
Dim strTemp As String

strTemp = Trim(GetSpecialPath(CSIDL_COMMON_APPDATA)) 'replace the constant with the one you need

'now, since app.path doesn't end with a "\", we'll strip it out just to keep the rest of your code unchanged

If Right$(strTemp, 1) = "\" Then strTemp = Left$(strTemp, Len(strTemp) - 1)

NewPath = strTemp

End Function

---

I'm calling it like this:
myfile = NewPath & "\myApp\quicker.dat"
it does not add the myapp folder
but this will add the qucker.dat
myfile = NewPath & "\quicker.dat", but not in a folder
do you know why ?

Quote:

---

Originally Posted by isnoend07

I have been doing some testing with code i got,i think from here om my xp machine:
This does not work:

HTML Code:

---

Option Explicit

'SHGetFolderPath API: locates special windows folders
Private Declare Function SHGetFolderPath Lib "shfolder.dll" Alias "SHGetFolderPathA" (ByVal hwndOwner As Long, _
ByVal nFolder As Long, ByVal hToken As Long, ByVal dwFlags As Long, ByVal pszPath As String) As Long

Private Const CSIDL_FLAG_MASK = &HFF00
Private Const SHGFP_Type_CURRENT = &H0
Private Const MAX_PATH = 260 'max path length

 
'some usual constants. There are a lot more, just google a bit and you'll find them.
Private Const CSIDL_APPDATA As Long = &H1A 'the {current user}\Application Data folder
Private Const CSIDL_COMMON_APPDATA As Long = &H23 'the {all users}\Application Data folder. Use this if all users will access the same data.
Private Const CSIDL_COMMON_DOCUMENTS As Long = &H2E 'the {all users}\Documents folder (shared documents)


'this returns the path for the selected special folder
Function GetSpecialPath(CSIDL As Long) As String
Dim strPath As String
Dim iReturn As Long
strPath = String(MAX_PATH, 0)
iReturn = SHGetFolderPath(0, CSIDL, 0, SHGFP_Type_CURRENT, strPath)
GetSpecialPath = Left$(strPath, InStr(1, strPath, Chr(0)) - 1)
End Function

'now, an app.path replacement to save you some coding.

Public Function NewPath() As String
Dim strTemp As String

strTemp = Trim(GetSpecialPath(CSIDL_COMMON_APPDATA)) 'replace the constant with the one you need

'now, since app.path doesn't end with a "\", we'll strip it out just to keep the rest of your code unchanged

If Right$(strTemp, 1) = "\" Then strTemp = Left$(strTemp, Len(strTemp) - 1)

NewPath = strTemp

End Function

---

I'm calling it like this:
myfile = NewPath & "\myApp\quicker.dat"
it does not add the myapp folder
but this will add the qucker.dat
myfile = NewPath & "\quicker.dat", but not in a folder
do you know why ?

---

this works
MkDir NewPath & "\MyApp"
then
myfile = NewPath & "\MyApp\quicker.dat"

There is also VB6 - AppEx Class, Assists Vista Programming which includes routines for OS version detection and such as well as supporting a longer list of special folder locations and handling "PathAndSubDir" lookups.

I have determined this so far:
The installer has to determine the OS
If Vista and not adminstrator
Stop installation with a messagebox "Right click and run as adminstrator to proceed" ( to allow to install ocx's dll's )
Don't install runtimes
Vista and xp, win2k etc
Find the correct path to your data files and make a folder for your program
Install the files your program needs on start to this folder (.ini files etc)
Install your exe to Program Files

looks like the installer will have to be able to be edited easily.
Next thing i need is a way to determine if adminstrator as started installation
Anybody know?

If you install via an MSI package Windows Installer will look at it (and any command line parameters) to decide whether you are doing a per-user or per-machine install. If the latter, it will automatically prompt for elevation.

If you use anything Vista decides is a "legacy installer" (which it does by looking at the EXE's name and extended properties, and making comparisons against a built-in list of keywords and such) it will always prompt for elevation. You might bypass this with an application manifest.

Otherwise your installation EXE will run as a user program, perhaps with appcompat shims applied. Then your "Run as Admin" prompt may come into play.

Detecting elevation is different from detecting whether a user is in a local or AD administrators group. I haven't seen any concise way of doing elevation detection aside from trying to do something prohibited and trapping the error.


If you try to install the runtimes or any other protected components, Vista will just ignore you (at least for PDW setups, I haven't tested others).


If you use VSI 1.1 or another MSI-producing packager, you can designate where to put things like INI files and data files, and even have it create the subfolders. I assume later versions of Inno Setup, etc. can do the same.

To use the PDW for this would require at least patching the Setup1 program (which is written in VB6 and you should have the source). That's because it only "knows about" some of the special folders:

Code:

---

Public Enum SpecialFolderIDs
    sfidDESKTOP = &H0
    sfidPROGRAMS = &H2
    sfidPERSONAL = &H5
    sfidFAVORITES = &H6
    sfidSTARTUP = &H7
    sfidRECENT = &H8
    sfidSENDTO = &H9
    sfidSTARTMENU = &HB
    sfidDESKTOPDIRECTORY = &H10
    sfidNETHOOD = &H13
    sfidFONTS = &H14
    sfidTEMPLATES = &H15
    sfidCOMMON_STARTMENU = &H16
    sfidCOMMON_PROGRAMS = &H17
    sfidCOMMON_STARTUP = &H18
    sfidCOMMON_DESKTOPDIRECTORY = &H19
    sfidAPPDATA = &H1A
    sfidPRINTHOOD = &H1B
    sfidProgramFiles = &H10000
    sfidCommonFiles = &H10001
End Enum

---

Quote:

---

Originally Posted by dilettante

If you install via an MSI package Windows Installer will look at it (and any command line parameters) to decide whether you are doing a per-user or per-machine install. If the latter, it will automatically prompt for elevation.

If you use anything Vista decides is a "legacy installer" (which it does by looking at the EXE's name and extended properties, and making comparisons against a built-in list of keywords and such) it will always prompt for elevation. You might bypass this with an application manifest.

Otherwise your installation EXE will run as a user program, perhaps with appcompat shims applied. Then your "Run as Admin" prompt may come into play.

Detecting elevation is different from detecting whether a user is in a local or AD administrators group. I haven't seen any concise way of doing elevation detection aside from trying to do something prohibited and trapping the error.


If you try to install the runtimes or any other protected components, Vista will just ignore you (at least for PDW setups, I haven't tested others).


If you use VSI 1.1 or another MSI-producing packager, you can designate where to put things like INI files and data files, and even have it create the subfolders. I assume later versions of Inno Setup, etc. can do the same.

To use the PDW for this would require at least patching the Setup1 program (which is written in VB6 and you should have the source). That's because it only "knows about" some of the special folders:

Code:

---

Public Enum SpecialFolderIDs
    sfidDESKTOP = &H0
    sfidPROGRAMS = &H2
    sfidPERSONAL = &H5
    sfidFAVORITES = &H6
    sfidSTARTUP = &H7
    sfidRECENT = &H8
    sfidSENDTO = &H9
    sfidSTARTMENU = &HB
    sfidDESKTOPDIRECTORY = &H10
    sfidNETHOOD = &H13
    sfidFONTS = &H14
    sfidTEMPLATES = &H15
    sfidCOMMON_STARTMENU = &H16
    sfidCOMMON_PROGRAMS = &H17
    sfidCOMMON_STARTUP = &H18
    sfidCOMMON_DESKTOPDIRECTORY = &H19
    sfidAPPDATA = &H1A
    sfidPRINTHOOD = &H1B
    sfidProgramFiles = &H10000
    sfidCommonFiles = &H10001
End Enum

---

---

Thanks for you input
Earlier today i had decide on Inno, but could not even create a messagebox
Tried to post to there group and oulook express, which i don't use wanted a name or something Now i have decided to edit the PDW at least i know how to write code in it. I think i may try your solutation of writing something that vista doesn't like and trap the error as i have not been able to find information
on If administrator. The MSI you mentioned, seems i checked into using it a few yrs ago and it seemed the users had to have some file on their PC or something. You mentioned that Vista will just ignore trying to install runtimes with PDW. You have tried this?

I stumbled accross this:
http://www.jsware.net/jsware/vbcode.php3

This is a further rebuild of Setup1, the executable used by the PDW for VB6 setup. This is the "noSE" version. (no Setup.Exe). The Setup.exe functions have been added into the Setup1.exe code, so the total size of your setup can be reduced by a further 135 KB (in addition to the reduction of approximately 120 KB resulting from the weeding and cleanup of the original Setup1 code). And there is no ugly gray box flashing by at the beginning of setup. (That was caused by Setup.exe.)

When the PDW was first created it was designed for use on Windows 95/98/NT4, where the VB6 runtime was not installed. Setup.exe was needed in that case to install the runtime and reboot. Today, virtually all PCs have the VB6 runtime installed, so setup.exe is unnecessary. At the same time, the PDW is showing its age in some respects. This rebuild of Setup1 provides the necessary updating and adds flexibility to easily create unique, professional installers with custom graphics - something that is difficult or impossible to do with most other installers.

This rebuild of Setup1 also adds more new functions to update VB setups. In addition to adding an EULA clickthrough, graphical options, and new settings for an Add/Remove icon, this version of Setup1 also adds an option to install files to a subfolder of Application Data. And it adds options for Desktop and Quick Launch icons to the GUI.

This Setup1 still uses the PDW. You just run the PDW and create a setup package as usual, then substitute your own custom version of Setup1.exe and make some minor changes to the package. The download includes the VB6 code project, a sample installation, and full directions.

The GUI of this setup can be easily redesigned to create a custom setup for each individual software product. (A background gradient in any color combination is one option that is pre-coded.) To get an idea, see this picture of a basic sample setup. The pictured sample uses the background gradient option, but customizing this setup's GUI is as easy as customizing a VB form. As long as you don't change any control names on the forms you won't need to make any code changes.

Quote:

---

Originally Posted by isnoend07

You mentioned that Vista will just ignore trying to install runtimes with PDW. You have tried this?

---

Yes, and I just re-verified it. No problems at all.

Quote:

---

Originally Posted by isnoend07

The MSI you mentioned, seems i checked into using it a few yrs ago and it seemed the users had to have some file on their PC or something.

---

Yes, users of unsupported OSs (prior to Win2K) would need to install Windows Installer before an MSI package will install properly. Of the old OSs it is possible that WinMe also included an early version of Windows Installer.

The latest version I see for Win95/98/Me is Windows Installer 2.0, which will handle VSI 1.1's MSI pacakages just fine. You could supply this to your users of old Windows versions if you had to. Windows Installer 2.0 Redistributable for Windows 95, 98, and Me. As noted there, Win XP Gold shipped with Installer 2.0 and Win2K can be updated to Installer 2.0 but you wouldn't need to.

Most Win2K, XP, and Win2003 users should be at Installer 3.1 v2 by now via the normal Windows Update process. Vista ships with Installer 4.0 and it is installed by default.

This should really only be an issue for people running Win95/98 who have done a clean OS install recently. Even installing a version of Office after Office 97 forces Windows Installer onto your system.

Quote:

---

Originally Posted by dilettante

Yes, and I just re-verified it. No problems at all.


Yes, users of unsupported OSs (prior to Win2K) would need to install Windows Installer before an MSI package will install properly. Of the old OSs it is possible that WinMe also included an early version of Windows Installer.

The latest version I see for Win95/98/Me is Windows Installer 2.0, which will handle VSI 1.1's MSI pacakages just fine. You could supply this to your users of old Windows versions if you had to. Windows Installer 2.0 Redistributable for Windows 95, 98, and Me. As noted there, Win XP Gold shipped with Installer 2.0 and Win2K can be updated to Installer 2.0 but you wouldn't need to.

Most Win2K, XP, and Win2003 users should be at Installer 3.1 v2 by now via the normal Windows Update process. Vista ships with Installer 4.0 and it is installed by default.

This should really only be an issue for people running Win95/98 who have done a clean OS install recently. Even installing a version of Office after Office 97 forces Windows Installer onto your system.

---

Thanks for your feed back, I have decided to edit the pdw, at least i can keep my custom setup screens and not try to configure something written
in outer space language. Can you make your own screens with MSI. looks like it would be safe use now. I just checked my logs for today, the results:
Win XP 396 75.86%
Win NT 65 12.45%
MacOS 27 5.17%
Win 2000 17 3.26%
Linux 9 1.72%
Win 98 3 0.57%
Win ME 1 0.19%
Unknown 4 0.77%
very few real old systems left