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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#984

On Sun, 18 Mar 2012 11:47:08 -0700 (PDT),
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. 
>

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

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

#985

On Monday, 19 March 2012 03:11:37 UTC, ralph  wrote:
> 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)

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

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

#986

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

> 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

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

#987

On Monday, 19 March 2012 10:14:55 UTC, Mike Williams  wrote:
> wrote in message 
> news:18433174.4307.1332144455764.JavaMail.geo-discussion-forums@ynlt15...
> 
> > 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."


 

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

#989

On Mon, 19 Mar 2012 05:03:22 -0700 (PDT),
peter.lawton@blueyonder.co.uk wrote:

>On Monday, 19 March 2012 10:14:55 UTC, Mike Williams  wrote:
>> wrote in message 
>> news:18433174.4307.1332144455764.JavaMail.geo-discussion-forums@ynlt15...
>> 
>> > 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.

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

>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

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

#995

<peter.lawton@blueyonder.co.uk> wrote in message 
news:6559785.1227.1332158602968.JavaMail.geo-discussion-forums@vbux23...
>
> 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

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

#988

On Mon, 19 Mar 2012 01:07:35 -0700 (PDT),
peter.lawton@blueyonder.co.uk wrote:

>On Monday, 19 March 2012 03:11:37 UTC, ralph  wrote:
>> 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)
>
>> 
>> -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

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

#990

On Monday, 19 March 2012 12:05:02 UTC, ralph  wrote:
> 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

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

#991

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

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

#993

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

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

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

#996

On Monday, 19 March 2012 14:31:26 UTC, Mayayana  wrote:

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

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

#994

On Mon, 19 Mar 2012 06:00:40 -0700 (PDT),
peter.lawton@blueyonder.co.uk wrote:

>On Monday, 19 March 2012 12:05:02 UTC, ralph  wrote:
>> 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

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

#997

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.

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

#999

<peter.lawton@blueyonder.co.uk> wrote in message 
news:14127446.381.1332176755304.JavaMail.geo-discussion-forums@vbbp15...
> 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

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

#1000

On Monday, 19 March 2012 18:48:42 UTC, Mike Williams  wrote:
> 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

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

#1002

On Mon, 19 Mar 2012 15:50:25 -0700 (PDT),
peter.lawton@blueyonder.co.uk wrote:


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

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

#1004

"ralph" <nt_consulting64@yahoo.net> wrote in message 
news:scmfm7teeusc2ec7f72e1krdo8j87qa8n4@4ax.com...

> The search rules for the Windows Launcher to find a
> dependent shared DLL (Win32 DLL, Regular DLL, ...)
> for a given executable are as follows:
> [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

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

#1005

On Tue, 20 Mar 2012 11:09:34 -0000, "Mike Williams"
<Mike@WhiskyAndCoke.com> wrote:

>"ralph" <nt_consulting64@yahoo.net> wrote in message 
>news:scmfm7teeusc2ec7f72e1krdo8j87qa8n4@4ax.com...
>
>> The search rules for the Windows Launcher to find a
>> dependent shared DLL (Win32 DLL, Regular DLL, ...)
>> for a given executable are as follows:
>> [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

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

#1006

On Tuesday, 20 March 2012 13:32:24 UTC, ralph  wrote:

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

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

#1008

ralph wrote:
> 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.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web