Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #962 > unrolled thread

64 bit Windows install difficulty

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-15 16:25 -0700
    Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-15 20:34 -0500
      Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-16 08:49 -0700
        Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-16 12:33 -0500
    Re: 64 bit Windows install difficulty H-Man <Spam@bites.fs> - 2012-03-16 13:53 -0600
    Re: 64 bit Windows install difficulty "Farnsworth" <nospam@nospam.com> - 2012-03-16 21:56 -0500
      Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-18 06:23 -0700
        Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-18 15:51 +0000
          Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-18 11:07 -0700
            Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-18 13:38 -0500
            Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-18 20:41 +0000
              Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-18 14:06 -0700
                Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-18 22:43 +0000
              Re: 64 bit Windows install difficulty GS <gs@somewhere.net> - 2012-03-18 18:49 -0400
                Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-18 23:09 +0000
                  Re: 64 bit Windows install difficulty GS <gs@somewhere.net> - 2012-03-18 19:15 -0400
                    Re: 64 bit Windows install difficulty GS <gs@somewhere.net> - 2012-03-18 19:26 -0400
        Re: 64 bit Windows install difficulty "Farnsworth" <nospam@nospam.com> - 2012-03-18 11:54 -0500
          Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-18 11:47 -0700
            Re: 64 bit Windows install difficulty "Farnsworth" <nospam@nospam.com> - 2012-03-18 19:09 -0500
            Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-18 22:11 -0500
              Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-19 01:07 -0700
                Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-19 10:14 +0000
                  Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-19 05:03 -0700
                    Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-19 07:20 -0500
                    Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-19 14:55 +0000
                Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-19 07:05 -0500
                  Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-19 06:00 -0700
                    Re: 64 bit Windows install difficulty "Mayayana" <mayayana@invalid.nospam> - 2012-03-19 09:31 -0500
                      Re: 64 bit Windows install difficulty "Mayayana" <mayayana@invalid.nospam> - 2012-03-19 10:15 -0500
                      Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-19 08:18 -0700
                    Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-19 09:36 -0500
                    Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-19 10:05 -0700
                      Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-19 18:48 +0000
                        Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-19 15:50 -0700
                          Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-19 20:42 -0500
                            Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-20 11:09 +0000
                              Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-20 08:32 -0500
                                Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-20 08:52 -0700
                                Re: 64 bit Windows install difficulty "Farnsworth" <nospam@nospam.com> - 2012-03-20 15:34 -0500
                                  Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-20 16:07 -0500
                                    Re: 64 bit Windows install difficulty "Farnsworth" <nospam@nospam.com> - 2012-03-21 14:00 -0500
                                      Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-21 14:20 -0500
                          Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-20 10:29 +0000
                            Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-20 08:46 -0700
                        Re: 64 bit Windows install difficulty ralph <nt_consulting64@yahoo.net> - 2012-03-19 20:12 -0500
                          Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-21 01:29 -0700
                            Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-21 09:57 +0000
                              Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-21 04:57 -0700
                                Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-21 13:14 +0000
                                Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-21 15:29 +0000
                                  Re: 64 bit Windows install difficulty peter.lawton@blueyonder.co.uk - 2012-03-21 09:47 -0700
                                  Re: 64 bit Windows install difficulty "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-03-22 11:11 +0000
                                    Re: 64 bit Windows install difficulty chinamicah@gmail.com - 2012-04-15 16:12 -0700
                  Re: 64 bit Windows install difficulty "Mayayana" <mayayana@invalid.nospam> - 2012-03-19 09:32 -0500

Page 1 of 3  [1] 2 3  Next page →

#962 — 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 things out on!

[toc] | [next] | [standalone]

#963

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

[toc] | [prev] | [next] | [standalone]

#965

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

[toc] | [prev] | [next] | [standalone]

#966

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

[toc] | [prev] | [next] | [standalone]

#967

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

[toc] | [prev] | [next] | [standalone]

#968

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

> 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

[toc] | [prev] | [next] | [standalone]

#969

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.

[toc] | [prev] | [next] | [standalone]

#970

<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

[toc] | [prev] | [next] | [standalone]

#973

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.

[toc] | [prev] | [next] | [standalone]

#974

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

[toc] | [prev] | [next] | [standalone]

#976

<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

[toc] | [prev] | [next] | [standalone]

#977

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.

[toc] | [prev] | [next] | [standalone]

#978

<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

[toc] | [prev] | [next] | [standalone]

#979

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

[toc] | [prev] | [next] | [standalone]

#980

"GS" <gs@somewhere.net> wrote in message news:jk5oov$cda$1@dont-email.me...
> Mike Williams brought next idea :
>> . . . 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

[toc] | [prev] | [next] | [standalone]

#981

Mike Williams formulated the question :
> "GS" <gs@somewhere.net> wrote in message news:jk5oov$cda$1@dont-email.me...
>> Mike Williams brought next idea :
>>> . . . 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>

-- 
Garry

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

[toc] | [prev] | [next] | [standalone]

#982

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>

-- 
Garry

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

[toc] | [prev] | [next] | [standalone]

#972

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

[toc] | [prev] | [next] | [standalone]

#975

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

[toc] | [prev] | [next] | [standalone]

#983

peter.lawton@blueyonder.co.uk wrote:
> 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 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web