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

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

Quick question about the VB Installer

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

Contents

  Quick question about the VB Installer HarryC - 2013-03-07 11:40 -0500
    Re: Quick question about the VB Installer Deanna Earley <dee.earley@icode.co.uk> - 2013-03-07 16:48 +0000
    Re: Quick question about the VB Installer ralph <nt_consulting@yahoo.com> - 2013-03-07 11:21 -0600
      Re: Quick question about the VB Installer HarryC - 2013-03-07 12:46 -0500
        Re: Quick question about the VB Installer "Mayayana" <mayayana@invalid.nospam> - 2013-03-07 17:11 -0500
          Re: Quick question about the VB Installer HarryC - 2013-03-07 18:44 -0500
        Re: Quick question about the VB Installer ralph <nt_consulting@yahoo.com> - 2013-03-07 17:14 -0600
          Re: Quick question about the VB Installer HarryC - 2013-03-07 18:54 -0500
            Re: Quick question about the VB Installer ralph <nt_consulting@yahoo.com> - 2013-03-08 00:16 -0600
              Re: Quick question about the VB Installer R C Nesbit <spam@ukrm.net> - 2013-03-08 09:54 +0000
                Re: Quick question about the VB Installer HarryC - 2013-03-08 07:34 -0500
                Re: Quick question about the VB Installer Schmidt <ng@vbRichClient.com> - 2013-03-08 21:33 +0100
              Re: Quick question about the VB Installer R C Nesbit <spam@ukrm.net> - 2013-03-09 12:09 +0000

#1737 — Quick question about the VB Installer

Thanks Deanna,

You would think that Microsoft would have worded that message a little
less confusing than they did.

Harry

[toc] | [next] | [standalone]

#1738

On 07/03/2013 16:40, HarryC wrote:
> Thanks Deanna,
>
> You would think that Microsoft would have worded that message a little
> less confusing than they did.

You have the source code :)

Having said that, there are far better options than PDW, like Inno Setup.

(Oh, and please use the reply/follow up button when replying or 
following up to a UseNet post.
Creating a new thread just confuses things.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

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

#1739

On Thu, 07 Mar 2013 11:40:53 -0500, HarryC wrote:

>Thanks Deanna,
>
>You would think that Microsoft would have worded that message a little
>less confusing than they did.
>

In addition, this message refers to 'shareable' DLLs, and in most
cases you can totally eliminate these messages by NOT including extra*
files in your PWD package.

[* 'extra' defined as anything not an authored component of your
application nor required by Startup.]

PWD comes from a time when it was 'safer' to be safe than sorry, and
likely targets were far more varied with installed versions than
today. The Wizard reads a project's dependancies, consults the VBdep
file then, quite helpfully <g>, includes anything it comes up with.

Without going into a long list of items you can safely remove, just
post the list of components you are currently including and we'll show
you what you can remove.

[Note: If your target is Windows 2000 or greater, it is highly
unlikely a 'newer' non-authored component would ever be replaced even
you insisted. <g>]

-ralph

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

#1740

On Thu, 07 Mar 2013 11:21:17 -0600, ralph <nt_consulting@yahoo.com>
wrote:

Forgot about the reply button :)

Deanna, ralph - I just wanted to make sure I wasn't telling people to
do something that was harming their computer, but since the oldest
computer is an XP it sounds like I couldn't mess it up anyhow.
The machine in question is Windows 8 which when the app was installed
it worked perfectly then all of a sudden our app slowed down to a
crawl and some menu choices quit working.  I thought that maybe
I had over wrote some need files.  But all the other apps on the
computer still work fine.

Ever hear of this ? 

>On Thu, 07 Mar 2013 11:40:53 -0500, HarryC wrote:
>
>>Thanks Deanna,
>>
>>You would think that Microsoft would have worded that message a little
>>less confusing than they did.
>>
>
>In addition, this message refers to 'shareable' DLLs, and in most
>cases you can totally eliminate these messages by NOT including extra*
>files in your PWD package.
>
>[* 'extra' defined as anything not an authored component of your
>application nor required by Startup.]
>
>PWD comes from a time when it was 'safer' to be safe than sorry, and
>likely targets were far more varied with installed versions than
>today. The Wizard reads a project's dependancies, consults the VBdep
>file then, quite helpfully <g>, includes anything it comes up with.
>
>Without going into a long list of items you can safely remove, just
>post the list of components you are currently including and we'll show
>you what you can remove.
>
>[Note: If your target is Windows 2000 or greater, it is highly
>unlikely a 'newer' non-authored component would ever be replaced even
>you insisted. <g>]
>
>-ralph

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

#1742

| The machine in question is Windows 8 which when the app was installed
| it worked perfectly then all of a sudden our app slowed down to a
| crawl and some menu choices quit working.  I thought that maybe
| I had over wrote some need files.  But all the other apps on the
| computer still work fine.
|
| Ever hear of this ?
|

   That's a very general question.

   On the PDW, there's no reason to ship any system
files. You can't install them, anyway. If you're shipping
your own DLLs don't mark them as shared. (Assuming
they're not.) Shipping newer system files won't hurt, in
the sense that XP+ won't let you install them. But it
would put the PDW into a reboot loop. It arranges to
install the system files during reboot, then finds they
didn't install and starts all over again. (There was no
System File Protection in '98.)

  As Mike said, there is a slight bug in the code as well.
It's not critical. It's just that when the PDW compares
files it checks the versions, which works fine, but if it
can't find versions it will then check dates. The date code
is backward, so that the PDW would try to install the older
file in that case. But none of that should matter because
it shouldn't be trying to install anything -- and you shouldn't
be shipping anything -- that's a system file.

  As others have said, there are other free installers
available. On the other hand, the PDW source code is
available so that a PDW install is entirely customizable.
If you're curious I have two updated and cleaned up versions
here:

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

  One version is just a cleaned-up version of the PDW with
some updated functions added, like Desktop shortcut option,
App Data folder creation, etc. The second version is a further
rewrite that eliminates the need for setup.exe. Setup.exe
is a C++ EXE that was only needed because the VB6 runtime
was not always installed on target PCs. But the VB6 runtime
has been a system file since Windows 2000, and setup.exe
also did some ugly things -- like that weird gray borderless
window at startup that says something like, "Please wait...",
and some odd behavior that involved moving the install files
into \Windows\ before running the install.

   The updated versions linked above are more work, but there
are full instructions with them, and if you use your own rewrite
of setup1.exe you get the advatage that you can fully customize
the UI, add your own license clickthrough, and add just about
any other functionality you like. Since all PCs now have the
VB6 runtime there's no reason that an installer has to be other
than VB. 

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

#1744

On Thu, 7 Mar 2013 17:11:38 -0500, "Mayayana"
<mayayana@invalid.nospam> wrote:

Mayanyana - Thank you, I'm going out and look at your samples.


>| The machine in question is Windows 8 which when the app was installed
>| it worked perfectly then all of a sudden our app slowed down to a
>| crawl and some menu choices quit working.  I thought that maybe
>| I had over wrote some need files.  But all the other apps on the
>| computer still work fine.
>|
>| Ever hear of this ?
>|
>
>   That's a very general question.
>
>   On the PDW, there's no reason to ship any system
>files. You can't install them, anyway. If you're shipping
>your own DLLs don't mark them as shared. (Assuming
>they're not.) Shipping newer system files won't hurt, in
>the sense that XP+ won't let you install them. But it
>would put the PDW into a reboot loop. It arranges to
>install the system files during reboot, then finds they
>didn't install and starts all over again. (There was no
>System File Protection in '98.)
>
>  As Mike said, there is a slight bug in the code as well.
>It's not critical. It's just that when the PDW compares
>files it checks the versions, which works fine, but if it
>can't find versions it will then check dates. The date code
>is backward, so that the PDW would try to install the older
>file in that case. But none of that should matter because
>it shouldn't be trying to install anything -- and you shouldn't
>be shipping anything -- that's a system file.
>
>  As others have said, there are other free installers
>available. On the other hand, the PDW source code is
>available so that a PDW install is entirely customizable.
>If you're curious I have two updated and cleaned up versions
>here:
>
>http://www.jsware.net/jsware/vbcode.php5
>
>  One version is just a cleaned-up version of the PDW with
>some updated functions added, like Desktop shortcut option,
>App Data folder creation, etc. The second version is a further
>rewrite that eliminates the need for setup.exe. Setup.exe
>is a C++ EXE that was only needed because the VB6 runtime
>was not always installed on target PCs. But the VB6 runtime
>has been a system file since Windows 2000, and setup.exe
>also did some ugly things -- like that weird gray borderless
>window at startup that says something like, "Please wait...",
>and some odd behavior that involved moving the install files
>into \Windows\ before running the install.
>
>   The updated versions linked above are more work, but there
>are full instructions with them, and if you use your own rewrite
>of setup1.exe you get the advatage that you can fully customize
>the UI, add your own license clickthrough, and add just about
>any other functionality you like. Since all PCs now have the
>VB6 runtime there's no reason that an installer has to be other
>than VB. 
>

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

#1743

On Thu, 07 Mar 2013 12:46:09 -0500, HarryC wrote:

>On Thu, 07 Mar 2013 11:21:17 -0600, ralph <nt_consulting@yahoo.com>
>wrote:
>
>Forgot about the reply button :)
>
>Deanna, ralph - I just wanted to make sure I wasn't telling people to
>do something that was harming their computer, but since the oldest
>computer is an XP it sounds like I couldn't mess it up anyhow.
>The machine in question is Windows 8 which when the app was installed
>it worked perfectly then all of a sudden our app slowed down to a
>crawl and some menu choices quit working.  I thought that maybe
>I had over wrote some need files.  But all the other apps on the
>computer still work fine.
>
>Ever hear of this ? 
>

"slow down"
"menu choices not working"

This means that for whatever reason the App has gotten into an endless
loop, or otherwise wasting cycles unexpectedly.

If the App worked fined on one platform and shows problems only on
another, then the most likely culprit is a difference in data between
the two environments.

[1. A count in one environment that seldom exceeded a few hundred
during tests is suddenly seeded to very large value.
2. A check for a changed value misses the specific value.
3. Magic numbers valid in one environment are different in new
environment.
4. ...

You know your own app so can likely 'think-out' where these things
might be occuring.]

The problem is easily resolved IF you can either install VB6 or WinDbg
on the Windows 8 box. Run in the debugger and periodically peek to see
where the App is spending its time. Otherwise you may need to
instrument a 'debug' version of your App that logs its activity to a
file.

-ralph

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

#1745

On Thu, 07 Mar 2013 17:14:14 -0600, ralph <nt_consulting@yahoo.com>
wrote:

ralph

the program was created on an XP machine. It works fine on 98, XP,
Vista, & Windows 7. 
I bought a Samsung tablet with Windows 8 (full version) on it and
installed it on that one also.  It's working on it.

The program is more of a database (Access) heavy processing type.
could this be a problem ?


>On Thu, 07 Mar 2013 12:46:09 -0500, HarryC wrote:
>
>>On Thu, 07 Mar 2013 11:21:17 -0600, ralph <nt_consulting@yahoo.com>
>>wrote:
>>
>>Forgot about the reply button :)
>>
>>Deanna, ralph - I just wanted to make sure I wasn't telling people to
>>do something that was harming their computer, but since the oldest
>>computer is an XP it sounds like I couldn't mess it up anyhow.
>>The machine in question is Windows 8 which when the app was installed
>>it worked perfectly then all of a sudden our app slowed down to a
>>crawl and some menu choices quit working.  I thought that maybe
>>I had over wrote some need files.  But all the other apps on the
>>computer still work fine.
>>
>>Ever hear of this ? 
>>
>
>"slow down"
>"menu choices not working"
>
>This means that for whatever reason the App has gotten into an endless
>loop, or otherwise wasting cycles unexpectedly.
>
>If the App worked fined on one platform and shows problems only on
>another, then the most likely culprit is a difference in data between
>the two environments.
>
>[1. A count in one environment that seldom exceeded a few hundred
>during tests is suddenly seeded to very large value.
>2. A check for a changed value misses the specific value.
>3. Magic numbers valid in one environment are different in new
>environment.
>4. ...
>
>You know your own app so can likely 'think-out' where these things
>might be occuring.]
>
>The problem is easily resolved IF you can either install VB6 or WinDbg
>on the Windows 8 box. Run in the debugger and periodically peek to see
>where the App is spending its time. Otherwise you may need to
>instrument a 'debug' version of your App that logs its activity to a
>file.
>
>-ralph

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

#1746

On Thu, 07 Mar 2013 18:54:02 -0500, HarryC wrote:

>On Thu, 07 Mar 2013 17:14:14 -0600, ralph <nt_consulting@yahoo.com>
>wrote:
>
>ralph
>
>the program was created on an XP machine. It works fine on 98, XP,
>Vista, & Windows 7. 
>I bought a Samsung tablet with Windows 8 (full version) on it and
>installed it on that one also.  It's working on it.
>
>The program is more of a database (Access) heavy processing type.
>could this be a problem ?
>

Possiblily.

At this point only three things are known for sure ...

1) Once discovered the problem will be blatantly obvious.
2) It will be found entwined in code managing flow control that you
*know for a fact* is absolutely error and problem free.
3) Repairing the problem will be quick, simple, and totally out of
proportion to the length of time it will take to discover its
location.

-ralph
<g>

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

#1747

Ralph spoke:
> At this point only three things are known for sure ...
> 
> 1) Once discovered the problem will be blatantly obvious.
> 2) It will be found entwined in code managing flow control that you
> *know for a fact* is absolutely error and problem free.
> 3) Repairing the problem will be quick, simple, and totally out of
> proportion to the length of time it will take to discover its
> location.

<applause>

-- 
Rob Pearson

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

#1748

On Fri, 08 Mar 2013 09:54:02 -0000, R C Nesbit <spam@ukrm.net> wrote:

After that I can now tackle the problem with a smile.

>Ralph spoke:
>> At this point only three things are known for sure ...
>> 
>> 1) Once discovered the problem will be blatantly obvious.
>> 2) It will be found entwined in code managing flow control that you
>> *know for a fact* is absolutely error and problem free.
>> 3) Repairing the problem will be quick, simple, and totally out of
>> proportion to the length of time it will take to discover its
>> location.
>
><applause>

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

#1749

Am 08.03.2013 10:54, schrieb R C Nesbit:
> Ralph spoke:
>> At this point only three things are known for sure ...
>>
>> 1) Once discovered the problem will be blatantly obvious.
>> 2) It will be found entwined in code managing flow control that you
>> *know for a fact* is absolutely error and problem free.
>> 3) Repairing the problem will be quick, simple, and totally out of
>> proportion to the length of time it will take to discover its
>> location.
>
> <applause>
>

+1  ...yeah, nice one. :-)

Olaf

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

#1750

Ralph spoke:
> 1) Once discovered the problem will be blatantly obvious.
> 2) It will be found entwined in code managing flow control that you
> *know for a fact* is absolutely error and problem free.
> 3) Repairing the problem will be quick, simple, and totally out of
> proportion to the length of time it will take to discover its
> location.

4) If you are doing this for a customer and try to charge by the hour 
they will say *HOW MUCH*?

-- 
Rob Pearson

[toc] | [prev] | [standalone]

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

csiph-web