64 bit Windows install difficulty

[p***@blueyonder.co.uk]

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!

[ralph]

On Thu, 15 Mar 2012 16:25:38 -0700 (PDT),
***@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

Post by p***@blueyonder.co.uk
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.

Post by p***@blueyonder.co.uk
"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.)

Post by p***@blueyonder.co.uk
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.

Post by p***@blueyonder.co.uk
I am hampered at the moment by not having a 64bit system here to try things out on!

Always a bummer.

-ralph

[p***@blueyonder.co.uk]

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

Post by ralph
On Thu, 15 Mar 2012 16:25:38 -0700 (PDT),
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

Post by p***@blueyonder.co.uk
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.

Post by p***@blueyonder.co.uk
"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.)

Post by p***@blueyonder.co.uk
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.

Post by p***@blueyonder.co.uk
I am hampered at the moment by not having a 64bit system here to try things out on!

Always a bummer.
-ralph
On Thu, 15 Mar 2012 16:25:38 -0700 (PDT),
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

Post by p***@blueyonder.co.uk
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.

Post by p***@blueyonder.co.uk
"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.)

Post by p***@blueyonder.co.uk
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.

Post by p***@blueyonder.co.uk
I am hampered at the moment by not having a 64bit system here to try things out on!

Always a bummer.
-ralph

[ralph]

On Fri, 16 Mar 2012 08:49:37 -0700 (PDT),

Post by p***@blueyonder.co.uk
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

[H-Man]

Post by p***@blueyonder.co.uk
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.

[Farnsworth]

Post by p***@blueyonder.co.uk
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/library/windows/desktop/ms682586%28v=vs.85%29.aspx

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

Post by p***@blueyonder.co.uk
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.

Post by p***@blueyonder.co.uk
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

[p***@blueyonder.co.uk]

Thanks to all for their most interesting and informative comments, tips and references. All taken on board, so to speak. So if I don't mention it in this post that doesn't mean it is being ignored
Right..
Were I starting again, or if I have to start again, I would use the universally recommended Inno setup program.

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
'...........................................................
Run "start.cmd"

Sub Run(ByVal sFile)
Dim shell

Set shell = CreateObject("WScript.Shell")
shell.Run Chr(34) & sFile & Chr(34), 0, false
Set shell = Nothing
End Sub
'......................................................................

As you can see, this simply runs the file "start.cmd" in a minimised window.
File "start.cmd" code is
'........................................................................
copy msvbvm50.dll %WinDir%\syswow64 /y
start install.exe
exit
'.........................................................................

Quite surprisingly (to me at least) this doesn't seem to mess up the install on my 32 bit Vista system. "Install.exe" (the VB wrapper for the setup.exes) starts as normal, and a user would not be aware of any change from previous, where install.exe was set to start immediately on unzip.

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"?

Anyway, all is yet to be tested on a 64 bit system, so I must wait for my user to report back, and I will post any response here. He has reported the error message as "MSVBVM50.DLL is not available".

It may all be a storm in a teacup - it may be nothing to do with 64 bit.
But, the coincidence of a) 64 bit, b) the file being elsewhere from the syswow64 directory, and c) msvbvm50.dll being "unavailable", is interesting.

I have resisted the temptation to try "Virtual box" so far. One reason is I am a bit low on disk space. It's time for a hard disk upgrade here.

[Mike Williams]

Post by p***@blueyonder.co.uk
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

[p***@blueyonder.co.uk]

Post by p***@blueyonder.co.uk
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.

[ralph]

On Sun, 18 Mar 2012 11:07:17 -0700 (PDT),

Post by p***@blueyonder.co.uk

Post by Mike Williams
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

[Mike Williams]

On Sunday, 18 March 2012 15:51:35 UTC, Mike Williams

Post by Mike Williams
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

[p***@blueyonder.co.uk]

Post by Mike Williams
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.

Post by Mike Williams
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.

[Mike Williams]

Post by p***@blueyonder.co.uk
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

[GS]

On Sunday, 18 March 2012 15:51:35 UTC, Mike Williams

Post by Mike Williams
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.

[Mike Williams]

Post by GS

. . . 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'.

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.

Perhaps there are different versions? The version of Winzip Self extractor
that I mentioned (the freeware version I downloaded earlier today)
definitely does have and explicit elevation option. The 'zip file for
software installation' option you mentioned is on the second page of Winzip
SE and that option does not itself cause 'run as admin'. However, on the
sixth page of Winzip SE there are 'run as user' and 'run as administrator'
option buttons under the heading 'When run on Windows Vista:". This is on
the same page as a 'unzip automatically' checkbox and a couple of language
option buttons. Perhaps your own version is fifferent?

Mike

[GS]

Post by Mike Williams

Post by GS

. . . 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'.

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.

Perhaps there are different versions? The version of Winzip Self extractor
that I mentioned (the freeware version I downloaded earlier today) definitely
does have and explicit elevation option. The 'zip file for software
installation' option you mentioned is on the second page of Winzip SE and
that option does not itself cause 'run as admin'. However, on the sixth page
of Winzip SE there are 'run as user' and 'run as administrator' option
buttons under the heading 'When run on Windows Vista:". This is on the same
page as a 'unzip automatically' checkbox and a couple of language option
buttons. Perhaps your own version is fifferent?
Mike

Yeah, I use the 'registered' version but I may have been looking in the
wrong place because the freeware features are included in the licensed
version. Also, I may need to update to latest release but I've been
paying for maintenance since day 1 and so it should be current.<g>

[GS]

Just confirming I was running an erlier version that launches from my
MS Office toolbar rather than the start menu or explorer context menu.
I see this option in my current latest version, and so I'll be changing
that toolbar's icon to use the latest version from now on.<g>

[Farnsworth]

Post by p***@blueyonder.co.uk
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

[p***@blueyonder.co.uk]

Post by Farnsworth
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
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 there from previous installs and which would mess up the new install.
I suppose all that can be done in freebasic?

[Farnsworth]

Post by p***@blueyonder.co.uk

Post by Farnsworth
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
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 there from previous installs and which would
mess up the new install.
I suppose all that can be done in freebasic?

First, trust me on this. I would bet it's the anti-virus program because
some maleware writer included the VB dll in the same folder, and so the
anti-virus program considered it a "fishy" behavior and did the user a favor
by blocking the program. Like Mike William suggested, it's not the OS
bitness, but the anti-virus program is to blame. Either ask the user to turn
off the anti-virus program temporarily, or ask him or her what type of
anti-virus program he or she is using and what edition and version, so you
can duplicate the problem, but there is no guarantee that you can duplicate
it even with that information.

Second, it's somewhat difficult to make GUI apps with FreeBasic, but non-GUI
should be easy. There are examples included when you install it.

[ralph]

On Sun, 18 Mar 2012 11:47:08 -0700 (PDT),

Post by p***@blueyonder.co.uk

Post by Farnsworth
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
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.

Well, IMHO ... (Which means you can safely ignore everything that
follows. <g>)

The "more elegant and reliable" solution is to use an Installer. P&D
and Inno Setup are free. Both can modified to do quite interesting
things.

P&D has the obvious advantage of being written in VB with all the
source code available, ie, anything you can do in VBS/VBA/VB you can
do with your setup1.exe.

Inno uses a separate scrip, but could certainly be engineered to
fulfill your modest requirements.

Why re-invent the wheel?

-ralph

[p***@blueyonder.co.uk]

Post by ralph
Well, IMHO ... (Which means you can safely ignore everything that
follows. <g>)
The "more elegant and reliable" solution is to use an Installer. P&D
and Inno Setup are free. Both can modified to do quite interesting
things.

....(snip)

Post by ralph
-ralph

I do use the P&D. But I have two setup.exes made from the P&D wizard and I give the user a choice as to which one to run. I can't see how to do this using the P&D alone. Once setup.exe has run it closes down, for example.

Post by ralph
Why re-invent the wheel?

Exactly what I am trying to avoid!

I've downloaded "FreeBasic" but can't get past first base with it so far.

[Mike Williams]

Post by p***@blueyonder.co.uk
I do use the P&D. But I have two setup.exes made from the
P&D wizard and I give the user a choice as to which one to
run. I can't see how to do this using the P&D alone. Once
setup.exe has run it closes down, for example.

Ah, the plot thickens. I'm not sure exactly what your intention is there,
and I don't use PDW myself, but as far as I am aware Setup.exe is
essentially a non-VB wrapper around Setup1.exe. It probably does a few other
things but the main job of Setup.exe is to install the VB runtime
(msvbvm50.dll in your case) so that it can then run Setup1.exe, which is a
standard VB program and which is the main installer. The thing is,
Setup1.exe can be modified by you to do all sorts of things and so you
should be able to modify it to carry out your own specific task. In VB6 the
VB source files for Setup1 are usually in the folder Program Files /
Microsoft Visual Studio / VB98 / Wizards /PDWizard / Setup1, so I assume
that the equivalent VB5 source files will be somewhere in the Program Files
/ DevStudio / VB folder on your machine. If you open the Setup1.vbp project
then you can modify the source code to do pretty much whatever you want and
then recompile, so that you have a new modified Setup1.exe file. There is
usually a copy of setup1.exe in both the Setup1 folder and in the PDWizard
folder so make sure that they are both your new modified versions.

Mike

[p***@blueyonder.co.uk]

Post by Mike Williams

Post by p***@blueyonder.co.uk
I do use the P&D. But I have two setup.exes made from the
P&D wizard and I give the user a choice as to which one to
run. I can't see how to do this using the P&D alone. Once
setup.exe has run it closes down, for example.

Ah, the plot thickens. I'm not sure exactly what your intention is there,
and I don't use PDW myself, but as far as I am aware Setup.exe is
essentially a non-VB wrapper around Setup1.exe....

I have two install packages, for two separate VB5 application, both contained within the same, single zipped .exe.
Each has its own setup1.exe, tailored even down to individual establishment level.
The problem is that the choice between which application to install is made from a VB program ("install.exe").

As it happens, I've just this minute had a conversation with a different user about another matter, but remembered to quiz him re. the current subject of this discourse.

Me: "Have you any Windows 7, 64 bit computers?"
User (actually, the ICT technician): "We've got one."
Me: "Have you installed XXXX on it?" (XXXX is the name of the program)
User: "Ye..es"
Me: "Did you have any problems?"
User: "I do believe I did, now you ask. There were some files missing... a dll...I can't remember the name. But I downloaded it from the internet and put it on the computer. I can't remember the folder I put it in...it wasn't sysvol...but it worked OK after that."

[ralph]

On Mon, 19 Mar 2012 05:03:22 -0700 (PDT),

Post by p***@blueyonder.co.uk

Post by Mike Williams

Post by p***@blueyonder.co.uk
I do use the P&D. But I have two setup.exes made from the
P&D wizard and I give the user a choice as to which one to
run. I can't see how to do this using the P&D alone. Once
setup.exe has run it closes down, for example.

Ah, the plot thickens. I'm not sure exactly what your intention is there,
and I don't use PDW myself, but as far as I am aware Setup.exe is
essentially a non-VB wrapper around Setup1.exe....

I have two install packages, for two separate VB5 application,
both contained within the same, single zipped .exe.
Each has its own setup1.exe, tailored even down to individual
establishment level.

Simple solution - create ONE Setup1.

Post by p***@blueyonder.co.uk
The problem is that the choice between which application to
install is made from a VB program ("install.exe").

Provide this choice within your Setup1.

Post by p***@blueyonder.co.uk
As it happens, I've just this minute had a conversation with a
different user about another matter, but remembered to quiz
him re. the current subject of this discourse.
Me: "Have you any Windows 7, 64 bit computers?"
User (actually, the ICT technician): "We've got one."
Me: "Have you installed XXXX on it?" (XXXX is the name of the program)
User: "Ye..es"
Me: "Did you have any problems?"
User: "I do believe I did, now you ask. There were some files
missing... a dll...I can't remember the name.

I believe that issue is well understood. My advice - include the VB5
package MS provides for exactly this reason with your install.

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

-ralph

[Mike Williams]

Post by p***@blueyonder.co.uk
Me: "Have you any Windows 7, 64 bit computers?"
User (actually, the ICT technician): "We've got one."
Me: "Have you installed XXXX on it?" (name of the program)
User: "Ye..es"
Me: "Did you have any problems?"
User: "I do believe I did, now you ask. There were
some files missing... a dll...I can't remember the name.
But I downloaded it from the internet and put it on
the computer. I can't remember the folder I put it
in...it wasn't sysvol...but it worked OK after that."

Yeah, but we can all relate stories to show things behaving in different
ways under different circumstances. The devil is in the detail. Here's a
conversation I had myself recently:

Me: "Have you got a Windows 7, 64 bit machine?"
Wife: "Yep. That's what I use all the time."
Me: "Have you ever installed VB5 on it?"
Wife: "Nope . . . what's VB5 anyway?"
Me: "Did you check the Registry like I told you
to confirm my own check which showed
that there are no references whatsoever to
a file called msvbvm50.dll?"
Wife: "Sure did. You were right there. Nothing at all."
Me: "Did you get the folder off that memory stick
I threw at you?"
Wife: "Yes. It contained two files, one called
test.exe and another called msvbvm50.dll
. . . and stop throwing things like that!"
Me: "Did you run test.exe and did it run okay?"
Wife: "Yes, it ran fine."
Me: "What's for dinner this evening?"
Wife: "Your friend from The States is over here
on holiday with his wife. They are coming
for dinner. We're having a good old American
evening . . . pork belly and grits out by the
cement pond."
Me: "Mmmm. That'll be nice . . . I'd best nip up to
the loft and see if I can find that old bottle of
whisky with an 'e' in it . . . etc, etc"

Mike

[ralph]

On Mon, 19 Mar 2012 01:07:35 -0700 (PDT),

Post by p***@blueyonder.co.uk

Post by ralph
Well, IMHO ... (Which means you can safely ignore everything that
follows. <g>)
The "more elegant and reliable" solution is to use an Installer. P&D
and Inno Setup are free. Both can modified to do quite interesting
things.

....(snip)

Post by ralph
-ralph

I do use the P&D. But I have two setup.exes made from the P&D
wizard and I give the user a choice as to which one to run. I can't
see how to do this using the P&D alone. Once setup.exe has run
it closes down, for example.

In addition to Mike's Post.

Open the Setup1.vbp project, navigate to the Form_Load event in
setup1.frm, place your new code after ShowBeginForm is called.

For additional files, etc. edit the Setup.lst file.
http://msdn.microsoft.com/en-us/library/aa263457(v=vs.60).aspx

This idea of writing one's own "bootstrap installer" has came up
frequently over the years and I can appreciate the various reasons why
developers feel it is necessary - A desire to avoid extra screens,
files, or complexity. Sounds reasonable, but as Mike has pointed out
Setup.exe IS a "bootstrap installer", and one can modify Setup1's
presentation to one's heart content. As for 'complexity' - a simple
examination of Setup1 will demonstrate that it isn't doing anything
other than what one would need to do with their custom installer.

I will agree that Setup1 isn't the best example of VB code. (A super
understatement.) It is convoluted, contains multiple 'insertion
points' and lots of dead code. But that is partly by design, and
partly by circumstance. It was originally a thrown together "sample
utility" provided for developers (by a separate technical download) to
use as an example for writing their own. An official mapping of
exactly where all components should be installed didn't exist, thus
Setup1 was built to cover as many bases as possible. And equally
limited to what they thought was all that was needed at the time.

It became sort of 'codified' (is that a word? <g>) when it was
converted and shipped with VB4 (warts and all). At that time, you
might remember, MS was getting sued by the FTC for taking unfair
advantage of their 'special' Windows knowledge over other software
vendors and MS was actively courting these same vendors. Setup1 was
delivered as a "good enough" utility, but fully expected to be
replaced.

[Visual Studio also included an InstallShield - lite, which could be
used to install VB and VC applications, but for some reason VBers
avoided it like the plague.]

[You'll find many VB controls and utilities suffer from this
essentially marketing decision. They are provided as "good enough"
often "lite" versions from other vendors. Products the vendors
supplied hoping one would buy the full version.]

Mayayana has posted a stripped-down, improved version of Setup1. Can't
seem to find the link at the moment. (Perhaps he'll post it here.)

-ralph

[p***@blueyonder.co.uk]

Post by ralph
In addition to Mike's Post.
Open the Setup1.vbp project, navigate to the Form_Load event in
setup1.frm, place your new code after ShowBeginForm is called.
(snipped)
-ralph

AFIK, Setup.exe opens setup1.exe with all sorts of things already set - for example the list of files to install.
But I have two lists, different for each of the two programs.
I can't see how I could give the user a choice of which program to install after setup.exe has run.
The zipped install package puts the files for each of the programs in their own folder within the temp folder.

Peter

[Mayayana]

| AFIK, Setup.exe opens setup1.exe with all sorts of things already set -
for example the list of files to install.
| But I have two lists, different for each of the two programs.
| I can't see how I could give the user a choice of which program to install
after setup.exe has run.
| The zipped install package puts the files for each of the programs in
their own folder within the temp folder.
|

As Ralph said, why not just write it all into one Setup1?
If you're already customizing Setup1 then you can do
whatever you want. For that matter, you may not even
need to use Setup1 in the first place if the program is
fairly simple.

Here's a link to two versions of VB6 Setup1:

http://www.jsware.net\jsware\vbcode.php5

I use the VB6 PDW and first rewrote Setup1 to clean up
the code, add updated functionality, and customize the
GUI. Later I rewrote it again to skip setup.exe. That works
well with VB6 because the VB6 runtime is pre-installed on
virtually all current machines.

It's true that setup.exe does some preparation. It's
Setup1 that handles the list of files (setup.lst) but setup.exe
does other things that must be added to Setup1 if
setup.exe is to be dropped. Setup.exe also does some
quirky things. If I remember correctly, I think it actually
moves Setup1.exe and the CAB file into the Windows
folder before running Setup1.exe! If you can get rid of
setup.exe that simplifies things.

I wonder if you could do something like ship two versions
of the VB5 runtime, with one misnamed. Then run off the
normal one while installing the misnamed one. Then you'd
just need to add a bit of custom code at the end to rename
and register the one you've moved into the system folder.

[Mayayana]

Woops. That link has backslashes. It should be like so:

http://www.jsware.net/jsware/vbcode.php5

[p***@blueyonder.co.uk]

Post by Mayayana
As Ralph said, why not just write it all into one Setup1?
If you're already customizing Setup1 then you can do
whatever you want. For that matter, you may not even
need to use Setup1 in the first place if the program is
fairly simple.
http://www.jsware.net\jsware\vbcode.php5

Thanks, I've had a look.
The one not using setup.exe relies on the VB6 runtime being already installed.
But I'm using VB5.
How do you get the list of files into it, by the way? I thought setup.exe was respnsible for that.

The streamlined version still starts setup1.exe with a specific list of files to install, allowing no choice in this matter (correct me if I am wrong).

[ralph]

On Mon, 19 Mar 2012 06:00:40 -0700 (PDT),

Post by p***@blueyonder.co.uk

Post by ralph
In addition to Mike's Post.
Open the Setup1.vbp project, navigate to the Form_Load event in
setup1.frm, place your new code after ShowBeginForm is called.
(snipped)
-ralph

AFIK, Setup.exe opens setup1.exe with all sorts of things
already set - for example the list of files to install.
But I have two lists, different for each of the two programs.
I can't see how I could give the user a choice of which
program to install after setup.exe has run.
The zipped install package puts the files for each of the
programs in their own folder within the temp folder.

Yeah, thought of that later. I was thinking of options/choices for a
single application and that your separate Setup1s were expressions of
those options. But if two entirely different different applications
... then perhaps instead of one installer, you simply add another one.
A "main" or controller?

I usually do multiple installs (MS packages, My control packages,
etc.) by including the install packages within a single installer -
just as one might include the MS VB5 runtime or MDAC packages with an
application install.

Another scenario I've done is installing an application 'suite' -
several executables, various components, and multiple folders.

I'm positive your particular problem domain can be solved with either
P&D or any other 3rd party install. BUT before we go any farther it
would help if you supplied more information on particular problem. So
provide a better breakdown of the executables, options/choices,
folders, etc. for your applications.

You need not supply actual names - just a general outline. That way,
neither I nor others will have to do any guessing (or in my case make
an erroneous assumption). Once we have that, one of several bright
fellows around here will be along with an excellent suggestion very
shortly.

-ralph

[p***@blueyonder.co.uk]

Got it....

Bits and pieces from various posts have at last come together to make a solution.

All I have to do is to upgrade the start program, the one where the user chooses which setup to run, from VB5 to VB6.

VB6 will run, because its runtime is pre-installed as part of Windows. If I include MSVBVM60.dll in the install that'll cover any ancient computers without it.
Setup1 will install msvbvm 50.dll to syswow64 in readiness for the main, VB5 program to run.

[Mike Williams]

Got it.... Bits and pieces from various posts have at last
come together to make a solution. All I have to do is to
upgrade the start program, the one where the user chooses
which setup to run, from VB5 to VB6. VB6 will run,
because its runtime is pre-installed as part of Windows.

I think the reason nobody suggested that before is that the details of your
various posts led us to assume you did not have VB6, at least that's what I
assumed myself. I still don't know why Win7 64 bit caused your specific
hiccup with regards to the VB5 runtime though, because simply including it
in the same folder as a VB5 compiled exe works for me on my own (or rather
my wife's!) Win7 64 bit machine which does not have msvbvm50.dll anywhere on
the machine and which has no references to it in the Registry. Still, that's
Windoze for you ;-) The only time it failed is when I deliberately tried to
run the VB5 compiled exe from within the same batch file that copied the VB5
runtime to the system folder, to simulate what I think you were yourself
doing at one time. But it wasn't Windoze which caused that failure because
the copy succeeded and it was Norton's quite aggressive Sonar protection
that pulled the plug in that case.

Mike

[p***@blueyonder.co.uk]

wrote in message
I think the reason nobody suggested that before is that the details of your
various posts led us to assume you did not have VB6, at least that's what I
assumed myself. I still don't know why Win7 64 bit caused your specific
hiccup with regards to the VB5 runtime though, because simply including it
in the same folder as a VB5 compiled exe works for me on my own (or rather
my wife's!) Win7 64 bit machine which does not have msvbvm50.dll anywhere on
the machine and which has no references to it in the Registry. Still, that's
Windoze for you ;-)

I've got VB6, Mike, although I've never installed or used it. I just didn't realise it was relevant until mayana pointed out that the VB6 runtimes come with Windows.

I do have two users reporting install failure on 64 bit machines, and with the same error message, referring to msvbvm50.dll. Something's going on....

Your experiment on your wife's computer - where was the VB5 application residing? Was it in Program files (x86)?

Peter

[ralph]

On Mon, 19 Mar 2012 15:50:25 -0700 (PDT),

Post by p***@blueyonder.co.uk
I do have two users reporting install failure on 64 bit machines, and
with the same error message, referring to msvbvm50.dll. Something's going on....
Your experiment on your wife's computer - where was the VB5
application residing? Was it in Program files (x86)?

The search rules for the Windows Launcher to find a dependent shared
DLL (Win32 DLL, Regular DLL, ...) for a given executable are as
follows:

1) the file specified by a fullpathname
2) the folder the executable is launched from
3) the current directory
4) the current 'System' folder
(c:\windows\system32\ or \SysWoW64\)
5) the 'Windows' folder
(c:\Windows, ... c:\WinNT)
6) folders contained in the Path environmental variable
(in order, left to right)

It worked on Mike's wife's computer because of Rule 2 or 3.

The Launcher attempts to resolve all dependencies before any code
after the entry point in the executable is called. Therefore the DLL
must be in one of those search locations before the executable is
launched.

-ralph

[Mike Williams]

Post by ralph
The search rules for the Windows Launcher to find a
dependent shared DLL (Win32 DLL, Regular DLL, ...)
[rules snipped]
It worked on Mike's wife's computer because of Rule 2 or 3.

Yep. I was in fact already aware of the search rules myself, but I
specifically placed msvbvm50.dll in the same folder as the VB5 program in
order to get as close as possible to what the OP said he was doing in his
very first post.

Mike

[ralph]

On Tue, 20 Mar 2012 11:09:34 -0000, "Mike Williams"

Post by Mike Williams

Post by ralph
The search rules for the Windows Launcher to find a
dependent shared DLL (Win32 DLL, Regular DLL, ...)
[rules snipped]
It worked on Mike's wife's computer because of Rule 2 or 3.

Yep. I was in fact already aware of the search rules myself, but I
specifically placed msvbvm50.dll in the same folder as the VB5 program in
order to get as close as possible to what the OP said he was doing in his
very first post.

Meant that as a reply to the OP, not you. (I think we can safely trust
you know the search rules by now. <g>)

I was trying to be as boringly complete as possible. Perhaps I should
have been even more "complete".

OP:

First off, while the MSVBVM50.DLL is important, in this context it is
just another shared DLL. There is nothing particularly mysterious
associated with it being 'missing'.

The main reason why an executable will report a dependent DLL as
"missing" is because the DLL is not physically in one of the 'search'
folders. This is easy to troubleshoot - open up Explorer and look.

Another might be because while the named DLL can be found other DLL's
it is dependent on are 'missing'. Again easy to troubleshoot - run a
dependency checker then open Explorer and look for them. (It is
unlikely this is a problem in this case, but ?)

Another reason is because while the file might be physically/virtually
located in one of those folders, due to its current privileges the
application can't 'see' it when invoking the search rules. This can be
more difficult to troubleshoot as the multiple reasons are usually
less intuitive and obscure. Examples might be:

1) The executable might be located in one folder and the DLL located
in another. The location of the DLL might be in the PATH Environmental
Variable, but due to current user privileges the user is unable to
'see' that folder.

2) Both an executable and its shared DLL (eg, App1.exe, DLL1.dll) are
in the same folder (eg, c:\MyStuff) and that folder is not included in
the PATH variable.
A process with its current directory in say 'C:\Working' launches an
executable in that folder by providing the fullpathname (eg,
C:\MyStuff\App1.exe).
DLL1.dll will be reported as 'missing' since the search rules will
fail.

There are other likely scenarios, but this should give one a good idea
of where to start looking. The search rules are fundamental to
resoving the issue of 'missing' shared DLLs.

-ralph

[p***@blueyonder.co.uk]

......There are other likely scenarios, but this should give one a good idea
of where to start looking. The search rules are fundamental to
resoving the issue of 'missing' shared DLLs.
-ralph

Thanks for that comprehensive input, Ralph. As I said in my reply to Mike's post, I will check with the user (when and if I get the chance) whether the two files are ending up in the same folder (as they are supposed to, and always have up until now).
If the VB6 front end solves the problem, however, I doubt if I shall ever find the answer.

Peter

[Farnsworth]

Post by ralph
2) Both an executable and its shared DLL (eg, App1.exe, DLL1.dll) are
in the same folder (eg, c:\MyStuff) and that folder is not included in
the PATH variable.
A process with its current directory in say 'C:\Working' launches an
executable in that folder by providing the fullpathname (eg,
C:\MyStuff\App1.exe).
DLL1.dll will be reported as 'missing' since the search rules will
fail.

But the search rules always include the folder where the EXE is located
regardless of the current directory, so in order for this fail, I could
think of 4 things:

1 - Permissions issues like you mentioned.

2 - Missing dependency that the DLL depends on, like you mentioned.

3 - Anti-virus program interference.

4 - Somehow the search rules didn't include the folder where the EXE is
located despite MS saying so. I think in Windows 3.x, it wasn't included,
but I am not sure. Perhaps there is a bug that makes Windows not search that
folder in certain situations.

[ralph]

Post by Farnsworth

Post by ralph
2) Both an executable and its shared DLL (eg, App1.exe, DLL1.dll) are
in the same folder (eg, c:\MyStuff) and that folder is not included in
the PATH variable.
A process with its current directory in say 'C:\Working' launches an
executable in that folder by providing the fullpathname (eg,
C:\MyStuff\App1.exe).
DLL1.dll will be reported as 'missing' since the search rules will
fail.

But the search rules always include the folder where the EXE is located
regardless of the current directory, so in order for this fail, I could
1 - Permissions issues like you mentioned.
2 - Missing dependency that the DLL depends on, like you mentioned.
3 - Anti-virus program interference.
4 - Somehow the search rules didn't include the folder where the EXE is
located despite MS saying so. I think in Windows 3.x, it wasn't included,
but I am not sure. Perhaps there is a bug that makes Windows not search that
folder in certain situations.

Never where the executable is "located", but rather always the current
directory it is "launched from". It is entirely possible for a process
to launch an executable within a context of "current directory" wholly
divorced from the physical location of the executable.

-ralph

[Farnsworth]

Post by ralph

Post by Farnsworth

Post by ralph
2) Both an executable and its shared DLL (eg, App1.exe, DLL1.dll)
are in the same folder (eg, c:\MyStuff) and that folder is not
included in the PATH variable.
A process with its current directory in say 'C:\Working' launches an
executable in that folder by providing the fullpathname (eg,
C:\MyStuff\App1.exe).
DLL1.dll will be reported as 'missing' since the search rules will
fail.

But the search rules always include the folder where the EXE is
located regardless of the current directory, so in order for this
1 - Permissions issues like you mentioned.
2 - Missing dependency that the DLL depends on, like you mentioned.
3 - Anti-virus program interference.
4 - Somehow the search rules didn't include the folder where the EXE
is located despite MS saying so. I think in Windows 3.x, it wasn't
included, but I am not sure. Perhaps there is a bug that makes
Windows not search that folder in certain situations.

Never where the executable is "located", but rather always the current
directory it is "launched from". It is entirely possible for a process
to launch an executable within a context of "current directory" wholly
divorced from the physical location of the executable.

I didn't mean to say that the executable is "located" as in FindExecutable()
and such, but meant the folder where the EXE is loaded from. The current
directory can be anything. In Windows 95+, it doesn't matter what the
current directory is, the folder where the EXE was loaded from is searched
first. See item #1 in the search order here:

Dynamic-Link Library Search Order:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

It's easy to skip it while speed reading. I have missed it few times myself.
MS even added more exceptions in recent versions of Windows that I wasn't
aware of. To add to the confusion, when running in the IDE, and depending on
how one setup the IDE shortcut, loading libraries fail if it's in the
project folder unless the shortcut working directory was set to the project
folder, or the line "ChDir App.Path" is used, which sets VB6.EXE current
directory to the project folder, so it's in the search path. The EXE in this
case is VB6.EXE and the folder where the EXE was loaded from is the "VB98"
folder. This makes it seems that the project folder is not searched, which
is true unless one takes steps to make it the current folder.

[ralph]

Post by Farnsworth

Post by ralph

Post by Farnsworth

Post by ralph
2) Both an executable and its shared DLL (eg, App1.exe, DLL1.dll)
are in the same folder (eg, c:\MyStuff) and that folder is not
included in the PATH variable.
A process with its current directory in say 'C:\Working' launches an
executable in that folder by providing the fullpathname (eg,
C:\MyStuff\App1.exe).
DLL1.dll will be reported as 'missing' since the search rules will
fail.

But the search rules always include the folder where the EXE is
located regardless of the current directory, so in order for this
1 - Permissions issues like you mentioned.
2 - Missing dependency that the DLL depends on, like you mentioned.
3 - Anti-virus program interference.
4 - Somehow the search rules didn't include the folder where the EXE
is located despite MS saying so. I think in Windows 3.x, it wasn't
included, but I am not sure. Perhaps there is a bug that makes
Windows not search that folder in certain situations.

Never where the executable is "located", but rather always the current
directory it is "launched from". It is entirely possible for a process
to launch an executable within a context of "current directory" wholly
divorced from the physical location of the executable.

I didn't mean to say that the executable is "located" as in FindExecutable()
and such, but meant the folder where the EXE is loaded from. The current
directory can be anything. In Windows 95+, it doesn't matter what the
current directory is, the folder where the EXE was loaded from is searched
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
It's easy to skip it while speed reading. I have missed it few times myself.
MS even added more exceptions in recent versions of Windows that I wasn't
aware of. To add to the confusion, when running in the IDE, and depending on
how one setup the IDE shortcut, loading libraries fail if it's in the
project folder unless the shortcut working directory was set to the project
folder, or the line "ChDir App.Path" is used, which sets VB6.EXE current
directory to the project folder, so it's in the search path. The EXE in this
case is VB6.EXE and the folder where the EXE was loaded from is the "VB98"
folder. This makes it seems that the project folder is not searched, which
is true unless one takes steps to make it the current folder.

Substitute the phrase "loaded from" with "launched from" and you'll
see we are talking about the exact same thing.

-ralph

[Mike Williams]

Post by p***@blueyonder.co.uk
Your experiment on your wife's computer - where was the
VB5 application residing? Was it in Program files (x86)?

Initially it was in a folder on the desktop, just as a quick test, and it
worked fine there. I then placed it into a folder in Program Files (X86) and
it worked fine there as well. The important thing is that, wherever it was,
the msvbvm50.dll was in the same folder with it. These were manual tests
though, where I placed the folder with the VB5 application and the
msvbvm50.dll file manually onto the machine, and I did it that way simply to
prove (at least to myself on the machines I currently have access to) that a
VB5 application will happily run when the only copy of msvbvm50.dll is in
the same folder with it, whether that copy of msvbvm50.dll is registered or
not. The same is true for a VB6 application (on machines where msvbvm60.dll
is deliberately unregistered and all references to it removed from the
registry), except that in a recent thread here we established that for one
specific thing to work (VB6 PropertyBags) a registered copy of msvbvm60.dll
is required.

Post by p***@blueyonder.co.uk
I do have two users reporting install failure on 64 bit
machines, and with the same error message, referring
to msvbvm50.dll. Something's going on....

Yep, clearly something is going wrong there. It could be anti virus action,
as both I and others have suggested, although in my own experience the more
aggressive anti virus programs, such as the Sonar protection in Norton, tend
to pull the plug only when you do something they regard as suspicious, such
as running a compiled exe within a batch file. However, I think is what you
were doing at one stage? (I've lost track of the details now). On my wife's
Win7 64 bit machine Norton's Sonar was deleting the VB5 program under such
circumstances, but other things on other machines might delete the DLL it is
attempting to use. Clearly, using a batch file for such things is going to
lead to problems on some machines.

I think it would be best to stay away from batch files anyway for such
purposes because Windows itself can cause problems when you use a batch file
to run a compiled exe. For example, I have just turned off Norton's Sonar
for a while so it does not get in the way and I used the following simple
batch file to run a compiled exe (the exe in the same folder as the batch
file):

start mike.exe

It works fine when you run the batch file normally, and mike.exe runs.
However, if you run the batch file using Run as Administrator then it fails
and Windows pops up the error message "Windows cannot find mike.exe",
although of course mike.exe is clearly there and nothing either now or later
deletes it under these circumstances. This happens both on my wife's
Windows7 64 bit machine and on my own Vista 32 bit machine. At first I
thought it might be because Windows did not like piggy backing under such
circumstances but it still happens even if I embed an Admin Privileges
manifest into mike.exe. I haven't looked any further into it yet, and I
probably won't do, but I think in general that batch files should be avoided
for such things.

Post by p***@blueyonder.co.uk
I've got VB6, Mike, although I've never installed or used it.
I just didn't realise it was relevant until mayana pointed out
that the VB6 runtimes come with Windows.

That's good, and it makes all the above a bit academic now, but it was an
interesting exercise nonetheless ;-)

Mike

[p***@blueyonder.co.uk]

Post by Mike Williams

Post by p***@blueyonder.co.uk
Your experiment on your wife's computer - where was the
VB5 application residing? Was it in Program files (x86)?

Initially it was in a folder on the desktop, just as a quick test, and it
worked fine there. I then placed it into a folder in Program Files (X86) and
it worked fine there as well. The important thing is that, wherever it was,
the msvbvm50.dll was in the same folder with it....(snip)

OK.
msvbmvm50.dll and "install.exe" are aimed the same folder on unzip of the install package. I'll have to ask the user if in his case this is actually happening - if he can find them both in the "temp" folder.

Post by Mike Williams
I think it would be best to stay away from batch files anyway for such
purposes because Windows itself can cause problems when you use a batch file
to run a compiled exe...(snip)

I've taken that on board, Mike, and am hoping the VB6 version of install.exe will render the batch file solution unnecessary.
I was interested to see that opening the VB5 file in the VB6 IDE produced no message or obvious upgrade attempt. I just made the .exe as normal and have pasted it over the previous VB5 .exe in the install folder where I keep the files to be zipped into the install package.

Thanks for your support.

Peter

[ralph]

On Mon, 19 Mar 2012 18:48:42 -0000, "Mike Williams"

Post by Mike Williams

Got it.... Bits and pieces from various posts have at last
come together to make a solution. All I have to do is to
upgrade the start program, the one where the user chooses
which setup to run, from VB5 to VB6. VB6 will run,
because its runtime is pre-installed as part of Windows.

I think the reason nobody suggested that before is that the details of your
various posts led us to assume you did not have VB6, at least that's what I
assumed myself.

Don't you just love assumptions and posts written in the style of St.
John ... that is, a sequence of revelations.

-ralph
<g>

[p***@blueyonder.co.uk]

...Don't you just love assumptions and posts written in the style of St.
John ... that is, a sequence of revelations.
-ralph
<g>

Not done on purpose! The learning curve has been a step function.

Another revelation, perhaps...I notice that when I rename msvbvm.50.dll in my system32 directory and try to start a vb5 application I get the error message "The application has failed to start because msvbvm50.dll is not found...." and then another couple of messages follow.

The user, however has reported (rather vaguely) that the message was that msvbvm50.dll was unavailable.
Perhaps that suggests it was found but the application was not allowed to access it.

[Mike Williams]

Post by p***@blueyonder.co.uk
Another revelation, perhaps...I notice that when I rename
msvbvm.50.dll in my system32 directory and try to start a
vb5 application I get the error message "The application has
failed to start because msvbvm50.dll is not found...."
The user, however has reported (rather vaguely) that the
message was that msvbvm50.dll was unavailable. Perhaps
that suggests it was found but the application was not
allowed to access it.

I wouldn't read too much into that. For example on my Vista machine I get
the message ". . . was not found" whereas on the Win7 64 bit machine I get
the message ". . . is missing from your computer". Having said that, I do
have a vague suspicion that there might still be something else going on
here, perhaps somehting to do with permissions with respect to the copying
of files, that we have not yet pinned down. Wouldn't it be good if either
yourself or one of us could sit in front of your user's machine when he had
the specific problem . . . we'd have it pinned down in a jiffy! Presumably
your immediate problem will be solved by the simple expedient of using VB6
instead of VB5 for this specific task and so both yourself and others might
be disinclined to look into it any further, but I'm sure it will be reported
here if anything else does turn up.

Mike

[p***@blueyonder.co.uk]

wrote in message
....Wouldn't it be good if either
yourself or one of us could sit in front of your user's machine when he had
the specific problem . . . we'd have it pinned down in a jiffy!....
Mike

I could email you a cut-down install package ... or you could download same from web site.

I will understand a natural antipathy to virus threat, of course

[Mike Williams]

Post by p***@blueyonder.co.uk

wrote in message
....Wouldn't it be good if either yourself or one of us could
sit in front of your user's machine when he had the specific
problem . . . we'd have it pinned down in a jiffy!....

I could email you a cut-down install package ... or you could
download same from web site. I will understand a natural
antipathy to virus threat, of course

That's a good idea, Peter. I'm not bothered about viruses (at least not
computer viruses!) and in any case I'm sure your stuff is fine. It might be
best if I downloaded it from your web site rather than by email so as to
better simulate what your users are doing. Fire away . . .

Mike

[Mike Williams]

Post by p***@blueyonder.co.uk
... or you could download same from web site.

. . . further to my previous response, I'm not sure whether you want to post
the link here or email it so in case it is the latter here is an email
address which will reach me [remove the fizzy drink from it]:

***@yahoo.co.uk

Mike

[p***@blueyonder.co.uk]

Post by Mike Williams

Post by p***@blueyonder.co.uk
... or you could download same from web site.

. . . further to my previous response, I'm not sure whether you want to post
the link here or email it so in case it is the latter here is an email
Mike

Mike, I've sent you an email both to the above address and the whisky one. I've possibly not elided correctly.
If nothing has arrived at your end, perhaps you could email me.
Peter

[Mike Williams]

Post by Mike Williams

Post by p***@blueyonder.co.uk
... or you could download same from web site.

. . . further to my previous response, I'm not sure whether you want to
post the link here or email it so in case it is the latter here is an

For anyone interested, the OP sent me his test project and I checked it out
thoroughly on my own two machines but I could not get it to fail. It worked
fine. I then looked at the problem in more detail and what it was doing on
my own machines and I made a number of suggestions to Peter as to what might
be the cause on the couple of clients' machines on which he was having
problems. One of the things I suggested was that it just might be possible
to control the standard DLL Search Order by fiddling with the Registry
(although that was just a blind guess of course) and if such a thing was
possible then a SysAdmin might have done it. A bit later I had a look to see
if I could find anything out there that might indicate such a thing was
possible and I found this:

http://support.microsoft.com/kb/2264107

Very insteresting stuff.

Mike

[c***@gmail.com]

I don't know if your problem has been solved yet, ***@blueyonder.co.uk.
If it hasn't, you could try running VB P&D's setup.exe from the SFX Zip file, just change setup.lst to run your special install.exe.
That way setup.exe will first install msvbvm50, then run install.exe, which picks between the 2 available setup options.
Hope this helps
Micah

Post by Mike Williams

Post by Mike Williams

Post by p***@blueyonder.co.uk
... or you could download same from web site.

. . . further to my previous response, I'm not sure whether you want to
post the link here or email it so in case it is the latter here is an

For anyone interested, the OP sent me his test project and I checked it out
thoroughly on my own two machines but I could not get it to fail. It worked
fine. I then looked at the problem in more detail and what it was doing on
my own machines and I made a number of suggestions to Peter as to what might
be the cause on the couple of clients' machines on which he was having
problems. One of the things I suggested was that it just might be possible
to control the standard DLL Search Order by fiddling with the Registry
(although that was just a blind guess of course) and if such a thing was
possible then a SysAdmin might have done it. A bit later I had a look to see
if I could find anything out there that might indicate such a thing was
http://support.microsoft.com/kb/2264107
Very insteresting stuff.
Mike

Post by Mike Williams

Post by p***@blueyonder.co.uk
... or you could download same from web site.

. . . further to my previous response, I'm not sure whether you want to
post the link here or email it so in case it is the latter here is an

For anyone interested, the OP sent me his test project and I checked it out
thoroughly on my own two machines but I could not get it to fail. It worked
fine. I then looked at the problem in more detail and what it was doing on
my own machines and I made a number of suggestions to Peter as to what might
be the cause on the couple of clients' machines on which he was having
problems. One of the things I suggested was that it just might be possible
to control the standard DLL Search Order by fiddling with the Registry
(although that was just a blind guess of course) and if such a thing was
possible then a SysAdmin might have done it. A bit later I had a look to see
if I could find anything out there that might indicate such a thing was
http://support.microsoft.com/kb/2264107
Very insteresting stuff.
Mike

[Mayayana]

| Mayayana has posted a stripped-down, improved version of Setup1. Can't
| seem to find the link at the moment. (Perhaps he'll post it here.)
|
Indeed. I hadn't really been following this thread, but
when I saw there were 7 new posts this morning I
figured there must be hot debate going on about
something. :)