64 bit Windows install difficulty

Hi.
I distribute my programs via the internet from my web site. The file which users download is a self extracting zip file, with the .exe extension.
When it is run it extracts all the files within it to a temp directory and runs automatically one of these files (install.exe) which is a little vb program I have written which presents the user with a pretty picture screen and the choice of running the various "setup.exe" files now in the temp directory (there are several different "setup.exe"s to choose from).
OK, this has worked fine for years.
But, I today got a call from a Win7 64 bit user telling me that "install.exe" won't run and instead reports it can't find msvbm50.dll (I use vb5).

Now, msvbm50.dll is contained in the install package, and up 'til now, its presence in the temp folder has been sufficient for "install.exe" to run - it seems it doesn't need to be in the Sys32 folder for VB5 to run.

"Install.exe" eventually ran OK once the user had manually pasted msvbm50.dll into the SysWow64 folder.

So, I'm guessing that on a 64bit system, msvbm50.dll has to be in the SysWoW64 folder for vb5 to run.
My question is, how do I programmatically put it in this folder? I can't use VB because it has to be there before VB can run.
I was thinking of writing a .bat file which would automatically run when the install package is unzipped, and would copy msvbm50.dll to the Syswow64 folder, and then start install.exe.

Trouble is, would that mess up install on 32 bit systems - would it crash if the SysWow64 directory did not exist?

I am hampered at the moment by not having a 64bit system here to try thingsout on!

On Thu, 15 Mar 2012 16:25:38 -0700 (PDT),
peter.lawton@blueyonder.co.uk wrote:

There is little you can, or should do, to modify a 32-bit install for
a 64-bit environment. The O/S will pickup the version and will
generally do what is right.

/Note: had to edit because of long lines in OP

>I distribute my programs via the internet from my web site.
>The file which users download is a self extracting zip file, with the .exe extension.

A small thing, but change the name of this file to something that
includes the words "install" or "setup" in the name.

>
>"Install.exe" eventually ran OK once the user had manually pasted msvbm50.dll into the SysWow64 folder.
>
>My question is, how do I programmatically put it in this folder?

You could do that through a .bat file as you suggested, or as part of
the installer. Again put the words "install" or "word" into the name
and treat it like an 'install'. But not necessary if you use the MS
VB5 install package.

"FILE: Msvbvm50.exe Installs Visual Basic 5.0 Run-Time Files"
http://support.microsoft.com/kb/180071

(Note, for completeness, I presume, MS includes OLE 'system' files. In
most cases these files will NOT be installed.)

>
>Trouble is, would that mess up install on 32 bit systems - would it crash if the SysWow64 directory did not exist?
>

Probably unless you put in a condition to check. That is the
advantages of the MS VB5 install package, if not needed nothing is
installed, if it is everything goes to the right place.

>I am hampered at the moment by not having a 64bit system here to try things out on!

Always a bummer.

-ralph

Thanks for that, Ralph.
I'll keep Msvbvm50.exe in reserve and go for the .cmd file automatic run on unzip option. Or perhaps try .vbs.

I've just got to gen up on the syntax.

The instructions will be(I guess)
1) copy msvbm50.dll from current directory to syswow64 directory
2) catch any error
3) wait - to allow the copying to finish
4) check the copying has been successful
4) start install.exe

All easy enough in VB but in dos or vbscript??

Peter


On Friday, 16 March 2012 01:34:16 UTC, ralph wrote:
> On Thu, 15 Mar 2012 16:25:38 -0700 (PDT),
> peterlawton wrote:
>
> There is little you can, or should do, to modify a 32-bit install for
> a 64-bit environment. The O/S will pickup the version and will
> generally do what is right.
>
> /Note: had to edit because of long lines in OP
>
> >I distribute my programs via the internet from my web site.
> >The file which users download is a self extracting zip file, with the .exe extension.
>
> A small thing, but change the name of this file to something that
> includes the words "install" or "setup" in the name.
>
> >
> >"Install.exe" eventually ran OK once the user had manually pasted msvbm50.dll into the SysWow64 folder.
> >
> >My question is, how do I programmatically put it in this folder?
>
> You could do that through a .bat file as you suggested, or as part of
> the installer. Again put the words "install" or "word" into the name
> and treat it like an 'install'. But not necessary if you use the MS
> VB5 install package.
>
> "FILE: Msvbvm50.exe Installs Visual Basic 5.0 Run-Time Files"
> http://support.microsoft.com/kb/180071
>
> (Note, for completeness, I presume, MS includes OLE 'system' files. In
> most cases these files will NOT be installed.)
>
> >
> >Trouble is, would that mess up install on 32 bit systems - would it crash if the SysWow64 directory did not exist?
> >
>
> Probably unless you put in a condition to check. That is the
> advantages of the MS VB5 install package, if not needed nothing is
> installed, if it is everything goes to the right place.
>
> >I am hampered at the moment by not having a 64bit system here to try things out on!
>
> Always a bummer.
>
> -ralph



On Friday, 16 March 2012 01:34:16 UTC, ralph wrote:
> On Thu, 15 Mar 2012 16:25:38 -0700 (PDT),
> peterlawton wrote:
>
> There is little you can, or should do, to modify a 32-bit install for
> a 64-bit environment. The O/S will pickup the version and will
> generally do what is right.
>
> /Note: had to edit because of long lines in OP
>
> >I distribute my programs via the internet from my web site.
> >The file which users download is a self extracting zip file, with the .exe extension.
>
> A small thing, but change the name of this file to something that
> includes the words "install" or "setup" in the name.
>
> >
> >"Install.exe" eventually ran OK once the user had manually pasted msvbm50.dll into the SysWow64 folder.
> >
> >My question is, how do I programmatically put it in this folder?
>
> You could do that through a .bat file as you suggested, or as part of
> the installer. Again put the words "install" or "word" into the name
> and treat it like an 'install'. But not necessary if you use the MS
> VB5 install package.
>
> "FILE: Msvbvm50.exe Installs Visual Basic 5.0 Run-Time Files"
> http://support.microsoft.com/kb/180071
>
> (Note, for completeness, I presume, MS includes OLE 'system' files. In
> most cases these files will NOT be installed.)
>
> >
> >Trouble is, would that mess up install on 32 bit systems - would it crash if the SysWow64 directory did not exist?
> >
>
> Probably unless you put in a condition to check. That is the
> advantages of the MS VB5 install package, if not needed nothing is
> installed, if it is everything goes to the right place.
>
> >I am hampered at the moment by not having a 64bit system here to try things out on!
>
> Always a bummer.
>
> -ralph

On Fri, 16 Mar 2012 08:49:37 -0700 (PDT),
peter.lawton@blueyonder.co.uk wrote:

>Thanks for that, Ralph.
>I'll keep Msvbvm50.exe in reserve and go for the .cmd file automatic run on unzip option. Or perhaps try .vbs.
>
>I've just got to gen up on the syntax.
>
>The instructions will be(I guess)
>1) copy msvbm50.dll from current directory to syswow64 directory
>2) catch any error
>3) wait - to allow the copying to finish
>4) check the copying has been successful
>4) start install.exe
>
>All easy enough in VB but in dos or vbscript??
>

Should be. One of the things ALL Shells do reasonably well is manage
files.

Not sure I'd worry about the "3) Wait". Probably won't be necessary.
If it is just google for "Shell and Wait" schemes for the tool of your
choice.

Also not sure if you are using an Installer or if this is all home
grown, but most installers provide a mechanism to add additional
install packages. For example, with P&D you would merely place
msvbm50.exe in the \Redist folder and modify the VB6install.ini to add
it to the project.

If nothing else include it with your setup files. Then if you get
phone calls - suggest they manually run it. I believe most users now
days are used to having to install prerequisite software - DirectX,
data providers, .Net patches, etc.

Besides it is best to stay out of the 'System' install business
whenever you can. <g>

-ralph

On Thu, 15 Mar 2012 16:25:38 -0700 (PDT), peter.lawton@blueyonder.co.uk
wrote:

> Hi.
> I distribute my programs via the internet from my web site. The file which users download is a self extracting zip file, with the .exe extension.
> When it is run it extracts all the files within it to a temp directory and runs automatically one of these files (install.exe) which is a little vb program I have written which presents the user with a pretty picture screen and the choice of running the various "setup.exe" files now in the temp directory (there are several different "setup.exe"s to choose from).
> OK, this has worked fine for years.
> But, I today got a call from a Win7 64 bit user telling me that "install.exe" won't run and instead reports it can't find msvbm50.dll (I use vb5).
>
> Now, msvbm50.dll is contained in the install package, and up 'til now, its presence in the temp folder has been sufficient for "install.exe" to run - it seems it doesn't need to be in the Sys32 folder for VB5 to run.
>
> "Install.exe" eventually ran OK once the user had manually pasted msvbm50.dll into the SysWow64 folder.
>
> So, I'm guessing that on a 64bit system, msvbm50.dll has to be in the SysWoW64 folder for vb5 to run.
> My question is, how do I programmatically put it in this folder? I can't use VB because it has to be there before VB can run.
> I was thinking of writing a .bat file which would automatically run when the install package is unzipped, and would copy msvbm50.dll to the Syswow64 folder, and then start install.exe.
>
> Trouble is, would that mess up install on 32 bit systems - would it crash if the SysWow64 directory did not exist?
>
> I am hampered at the moment by not having a 64bit system here to try things out on!

Try a pre-install using something like Inno Setup. It's sciptable and you
could make sure VB5RT is installed before you present the user with more
options.

--
HK

peter.lawton@blueyonder.co.uk wrote:
> Hi.
> I distribute my programs via the internet from my web site. The file
> which users download is a self extracting zip file, with the .exe
> extension.
> When it is run it extracts all the files within it to a temp
> directory and runs automatically one of these files (install.exe)
> which is a little vb program I have written which presents the user
> with a pretty picture screen and the choice of running the various
> "setup.exe" files now in the temp directory (there are several
> different "setup.exe"s to choose from).
> OK, this has worked fine for years.
> But, I today got a call from a Win7 64 bit user telling me that
> "install.exe" won't run and instead reports it can't find msvbm50.dll
> (I use vb5).
>
> Now, msvbm50.dll is contained in the install package, and up 'til
> now, its presence in the temp folder has been sufficient for
> "install.exe" to run - it seems it doesn't need to be in the Sys32
> folder for VB5 to run.
>
> "Install.exe" eventually ran OK once the user had manually pasted
> msvbm50.dll into the SysWow64 folder.

Your problem is most likely that you have a user who didn't turn off their
Anti-Virus program before installing the software, and it was blocking the
loading of that DLL. Windows searches for the DLL first at where the EXE was
ran from unless it was already loaded or if the DLL is listed in a
"KnownDLLs" registry key. See this article for more details:

Dynamic-Link Library Search Order:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Ignore the section "Search Order for Metro style Apps" because it's for the
upcoming Windows "8" OS.

> So, I'm guessing that on a 64bit system, msvbm50.dll has to be in the
> SysWoW64 folder for vb5 to run.
> My question is, how do I programmatically put it in this folder?

Beware that writing to that folder is restricted unless the user runs your
app as admin. Windows sometimes asks for elevation when there is the word
"setup" or "install" in the EXE file name or version information. What I
recommend is that you use Inno Setup. Here are the instructions on how to
use it with VB6:

http://www.jrsoftware.org/iskb.php?vb

There are 6 runtime files, and they are the same for VB5 and VB6, except
msvbvm60.dll. Just change the "6" to "5". The other 5 runtime files have
become part of the OS for a long time, so you don't need to install them.
Also, you need to remove "OnlyBelowVersion: 0,6" for MSVBVM50.dll because
Inno author found out that Windows Vista+ protects the registry entries for
the runtime files(not sure if it's for MSVBVM60.dll specifically), so this
flag says to only install or update the files on pre-Vista
OS(2000/XP/2003Server). So, instead of 6 files, just install the one file
like this:

; begin VB system files
; (Note: Scroll to the right to see the full lines!)
Source: "vbfiles\msvbvm50.dll"; DestDir: "{sys}"; Flags: restartreplace
uninsneveruninstall sharedfile regserver
; end VB system files

The only change I made is removing "OnlyBelowVersion: 0,6". You can add an
extra flag called "onlyifdoesntexist". This would only install the DLL if it
doesn't exist, but if the user had an old version of the DLL, then the DLL
won't be updated to the version that you are including, so I recommend that
you don't use that flag. The default with the line above is that Inno would
check the file version and only update the file if it's newer. Here is a
link to Inno Setup home page:

http://www.jrsoftware.org/isinfo.php

The help file is provided online. See a link called "Documentation" on the
left menu.

Here is a quick way to create an installer using Inno Setup:

1 - Download Inno Setup. There are two versions: ANSI and Unicode. The ANSI
version would create installers for Windows 95+(Including the latest OS'es,
like Windows 7), and the Unicode version would create installers for Windows
2000+SP4+. There is no difference as far as VB is concerned except that it's
easier to support multiple languages if you use the Unicode version. Some
Inno users write complex scripts and it's easier for them to call the
Unicode version of the Win32 API functions.

2 - Go to File-->New to run the Wizard. For starters, just click Next till
the end to see what you get, then start it again and fill the required
information.
3 - The default installer file name is "setup.exe". You can change that by
specifying "OutputBaseFilename" parameter so you don't have to rename the
file each time you create the installer.
4 - The image shown in the installer can be changed by using
"WizardImageFile". See the help for [Setup] section to see what other
cosmetic parameters that you can change.
5 - If you like to make the installer cover the whole screen, see
WindowVisible/WindowShowCaption/WindowStartMaximized parameters. You can
make it cover the Task Bar or not, however, many users nowadays find it
annoying if the installer covers the Task Bar.

> I can't use VB because it has to be there before VB can run.
> I was thinking of writing a .bat file which would automatically run
> when the install package is unzipped, and would copy msvbm50.dll to
> the Syswow64 folder, and then start install.exe.
>
> Trouble is, would that mess up install on 32 bit systems - would it
> crash if the SysWow64 directory did not exist?
>
> I am hampered at the moment by not having a 64bit system here to try
> things out on!

You can if you have a 64-Bit CPU and enough RAM(more than 512 MB), and hard
disk space. It doesn't matter if you are currently using a 32-Bit OS or not.
You can download this free software and install a 64-Bit trial version of
the OS on it. There is no need for a second PC. You don't need to
repartition your hard drive. The new OS would be installed to a file in your
hard drive that you can back up and restore as much as you want to. For
example, after you install the OS, make a backup(snapshot) and call it
"Clean Install". After you screwup the OS with your experimental installer,
you can return the OS to the clean install state just by restoring the
snapshot, which would take a minute or two, rather than redoing the clean
install which could take like 30 minutes, so it's a time saver:

http://en.wikipedia.org/wiki/VirtualBox

<peter.lawton@blueyonder.co.uk> wrote in message
news:158540.17.1332077036726.JavaMail.geo-discussion-forums@vbhv6...
>
> File "start.cmd" code is
> copy msvbvm50.dll %WinDir%\syswow64 /y
> start install.exe
> exit
> '................................................. .....................
> A mystery is that making the dos window visible for
> "start.cmd" reveals that it reports "1 file copied".....
> I thought syswow64 existed only on 64 bit systems?
> Why don't I get "directory not found"?

Because the DOS Copy command /did/ find a suitable directory . . . it's just
not the directory you were hoping it would find. The DOS Copy command is
capable of renaming files as it moves them, and the fact that it could not
find the directory %WinDir%\SysWOW64 on your own 32 bit system caused DOS
Copy to assume that you wanted it to copy the msvbvm50.dll file into the
%WinDir% directory and to rename the file from msvbvm50.dll to syswow64 as
it copied it, and so that's what it did. If you have a look in your Windows
directory then you'll find it now contains a file called syswow64, and that
file will actually be a renamed copy of the file vbvm50.dll. To stop it
doing that you should specify the source filename again in the target path,
for example:

copy msvbvm50.dll %WinDir%\syswow64\msvbvm50.dll /y

Having said that, I'm not sure whether I would be doing it that way if I
were you and I would probably be following the advice that others have
posted. Is your install stuff running as Admin by the way?

Mike

peter.lawton@blueyonder.co.uk wrote:
> However, I am sure you will understand my desire for a quick fix for
> the setup process rather than a total rebuild.
>
> Today's attempt at a "fix" is that on unzip of the install package, I
> have set a vbs file to run automatically (the zipped install package
> allows you to run a start-up file). the code for this file is

Many admins disable the scripting host, so your VBS may not run. Better to
do it in some other way. Try writing a small app using FreeBasic, which
doesn't require dependencies:

http://en.wikipedia.org/wiki/FreeBASIC

On Sunday, 18 March 2012 15:51:35 UTC, Mike Williams wrote:
> wrote in message
> news:158540.17.1332077036726.JavaMail.geo-discussion-forums@vbhv6...
> >
> > File "start.cmd" code is
> > copy msvbvm50.dll %WinDir%\syswow64 /y
> > start install.exe
> > exit
> > '................................................. .....................
> > A mystery is that making the dos window visible for
> > "start.cmd" reveals that it reports "1 file copied".....
> > I thought syswow64 existed only on 64 bit systems?
> > Why don't I get "directory not found"?

> ....copy msvbvm50.dll %WinDir%\syswow64\msvbvm50.dll /y....
>
Thanks Mike. Got your point.
When I put in the corrected line you supplied, as above, the dos window says "system can't find the specified directory" (or words to that effect), as expected.
Fortunately, it continues to the next line and starts the VB "wrapper" program, "install.exe".

> Is your install stuff running as Admin by the way?

Mmm. I don't think the self extracting .exe makes any request for administrator status, now I come to look at it.

On Sun, 18 Mar 2012 11:07:17 -0700 (PDT),
peter.lawton@blueyonder.co.uk wrote:

>
>> Is your install stuff running as Admin by the way?
>
>Mmm. I don't think the self extracting .exe makes
>any request for administrator status, now I come to look at it.

Putting the words "setup" or "Install" within the file name is a hack
to enforce that behavior, albeit a tad unreliable. <g>

-ralph

On Sunday, 18 March 2012 16:54:22 UTC, Farnsworth wrote:

> Many admins disable the scripting host, so your VBS may not run. Better to
> do it in some other way. Try writing a small app using FreeBasic, which
> doesn't require dependencies:
>
> http://en.wikipedia.org/wiki/FreeBASIC

That sounds interesting. If I could re-write the "wrapper" program (install..exe) in freebasic instead of VB5 then the problem should be solved more elegantly and reliably.

"install.exe" shows the user a bitmap and two comand buttons on a full screen form . The buttons start the two "setup.exe" programs. The only other workings inside the code are to delete a few files which may be already therefrom previous installs and which would mess up the new install.
I suppose all that can be done in freebasic?

<peter.lawton@blueyonder.co.uk> wrote in message
news:17953706.1221.1332094037167.JavaMail.geo-discussion-forums@vbbfy7...
> On Sunday, 18 March 2012 15:51:35 UTC, Mike Williams
>> wrote in message:
>> news:158540.17.1332077036726.JavaMail.geo-discussion-forums@vbhv6...
>> Is your install stuff running as Admin by the way?
>
> Mmm. I don't think the self extracting .exe makes any
> request for administrator status, now I come to look at it.

Well you'll need to have your self extracting zip file Run as Admin
otherwise your attempt to use a contained script or batch file to copy a
file into a protected system folder will fail. Putting the word 'Setup' or
'Install' into the filename is supposed to make Windows detect it as
requiring Admin Privileges but, as Ralph has already said, that method is
not entirely reliable. The package you used to create your self extracting
zip file should have such a facility though. I don't use self extracting zip
files much myself but I've just downloaded the freeware version of WinZip
Self extractor and that certainly has the option to set the package to
automatically 'Run as Admin'.

One thing that puzzles me about what you are doing is your use of a VBS
script file which uses the Scripting Object to run a DOS batch file, with
the DOS batch file in turn copying the msvbvm50.dll file into the System
directory and then starting up your VB6 program. This just introduces an
additional level of complexity and will in any case fail if the scripting
host has been disabled. Why are you doing that? Why don't you get rid of the
VBS script file altogether and instead set the DOS batch file as the Autorun
file in the zip?

Having said that, whether your self extracting zip file uses both a script
and a batch file or just a batch file on its own to run a contained exe file
you will probably have problems on some machines with some anti virus
programs which might block such attempts. On tests I've just carried out,
the Sonar protection in Norton Internet Security is sometimes very
aggressive in such circumstances. In fact, as I think Farnsworth pointed
out, it was probably an anti virus program that caused your original problem
on one specific machine and the fact that it happened to be a machine
running a 64 bit version of Windows 7 was probably just a coincidence.

Mike

On Sunday, 18 March 2012 20:41:40 UTC, Mike Williams wrote:
> One thing that puzzles me about what you are doing is your use of a VBS
> script file which uses the Scripting Object to run a DOS batch file, with
> the DOS batch file in turn copying the msvbvm50.dll file into the System
> directory and then starting up your VB6 program. This just introduces an
> additional level of complexity and will in any case fail if the scripting
> host has been disabled. Why are you doing that? Why don't you get rid of the
> VBS script file altogether and instead set the DOS batch file as the Autorun
> file in the zip?
The .vbs file is solely to make the .cmd file run in a minimised window, so that users don't see it, not even the brief flash of it. I don't want that. Users are easily disconcerted.

>Having said that, whether your self extracting zip file uses both a script
>and a batch file or just a batch file on its own to run a contained exe file
>you will probably have problems on some machines with some anti virus
>programs which might block such attempts.

I assume the problem of getting past AV is not limited to running the .cmd file?
AV will block the whole install process?
If so, I've lost nothing since it is just a case of the installation failing at an earlier point than it would have done previously.

<peter.lawton@blueyonder.co.uk> wrote in message
news:8417621.579.1332104763805.JavaMail.geo-discussion-forums@vbmf37...

> I assume the problem of getting past AV is not limited to
> running the .cmd file? AV will block the whole install
> process? If so, I've lost nothing since it is just a case of
> the installation failing at an earlier point than it would
> have done previously.

It depends on which anti virus program is installed on the target machine.
From my own experience, Norton Internet Security's Sonar protection allows
the batch file to run and it allows the batch file to copy a file into the
Windows\System folder (providing the batch file is set to run as admin so
that Windows itself does not block the copy), but it usually prevents the
batch file from starting a compiled exe file.

Mike

Mike Williams brought next idea :
> <peter.lawton@blueyonder.co.uk> wrote in message
> news:17953706.1221.1332094037167.JavaMail.geo-discussion-forums@vbbfy7...
>> On Sunday, 18 March 2012 15:51:35 UTC, Mike Williams
>>> wrote in message:
>>> news:158540.17.1332077036726.JavaMail.geo-discussion-forums@vbhv6...
>>> Is your install stuff running as Admin by the way?
>>
>> Mmm. I don't think the self extracting .exe makes any
>> request for administrator status, now I come to look at it.
>
> Well you'll need to have your self extracting zip file Run as Admin otherwise
> your attempt to use a contained script or batch file to copy a file into a
> protected system folder will fail. Putting the word 'Setup' or 'Install' into
> the filename is supposed to make Windows detect it as requiring Admin
> Privileges but, as Ralph has already said, that method is not entirely
> reliable. The package you used to create your self extracting zip file should
> have such a facility though. I don't use self extracting zip files much
> myself but I've just downloaded the freeware version of WinZip Self
> extractor and that certainly has the option to set the package to
> automatically 'Run as Admin'.
>
> One thing that puzzles me about what you are doing is your use of a VBS
> script file which uses the Scripting Object to run a DOS batch file, with the
> DOS batch file in turn copying the msvbvm50.dll file into the System
> directory and then starting up your VB6 program. This just introduces an
> additional level of complexity and will in any case fail if the scripting
> host has been disabled. Why are you doing that? Why don't you get rid of the
> VBS script file altogether and instead set the DOS batch file as the Autorun
> file in the zip?
>
> Having said that, whether your self extracting zip file uses both a script
> and a batch file or just a batch file on its own to run a contained exe file
> you will probably have problems on some machines with some anti virus
> programs which might block such attempts. On tests I've just carried out, the
> Sonar protection in Norton Internet Security is sometimes very aggressive in
> such circumstances. In fact, as I think Farnsworth pointed out, it was
> probably an anti virus program that caused your original problem on one
> specific machine and the fact that it happened to be a machine running a 64
> bit version of Windows 7 was probably just a coincidence.
>
> Mike

I have WinZip SelfExtractor, which I use for distributing updates
instead of the full Install.EXE. I think you're referring to the
runtime behavior associated with the 'Type of self extracting zip
file', where it's explicitly optional for software installation. This
might elevate it to 'Run as admin' status but I don't see an explicit
option that states what elevation to run at.

If the OP is using IExpress, I don't see where there's an option for
setting the runtime UAC level.

I use Wise mostly, and I display a notification that it must be 'Run as
administrator' in case the "Install" portion of its name is ignored by
the OS. This is required because I also use jsware's NTFS permissions
code for setting up my target folder and it subfolders. I plan on
exploring Inno to consider a switch, hoping the permissions settings
are a built-in feature.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion