From: mayayana on

>
> How do I figure out what 'versions' to ship? I write the programs on my XP
> Home system. When done and ready to package, I don't know what files Win98
> can or cannot run. What tells me that I wrote my program with a version
that
> is too high for other systems?
>

I think it's the responsibility of the programmer to
research that. You're asking people to trust your
installer. You should know what's in it and why.
Especially if you're writing on XP, since that means
many of your system files won't be compatible with
Win9x.

If you've installed VB/VS service packs, a lot of
what's in those is updates for files as a result of
problems that have occurred over time. The PDW will
take files from the folder Wizards\PDWizard\Redist, if
they're there, rather than from the XP system folder.
For instance, with the VC6 runtime, MSVCRT.DLL, the
version to ship is 6.00.8397.0. (Though as Steve Gerrard
said, very few people will need that file.) If you can cut out
whatever you're using in SCRRUN.DLL then the PDW
probably will also drop MSVCRT.DLL from the list.

In the case of SCRRUN.DLL, the current version
is 5.6, but I think that 5.1 is probably the one to ship.
V. 5.1 is almost the same as 5.6, but v. 5.6 ships differently
for Win9x vs. WinNT. ...That's the kind of thing I mean that
you should know - that MSVCRT.DLL is a dependency of
SCRRUN.DLL and that there might be problems shipping
v. 5.6 of SCRRUN.DLL. ...And also that you're using something
in that (FileSystemObject? Dictionary?) that, if you can eliminate
that need, should remove two of your dependencies.

> comdlg32.dll - I think that's wrong. If you're using a common
dialogue control you need comdlg32.ocx, but not the DLL.

> comdlg32.ocx
> fmtkit32.dll
> igtabs40.ocx
> igtoolbars50.ocx
> mscomctl.ocx

> msvbvm50.dll - Why this? You've already got the VB6
runtime listed. It's VB6 software? Maybe you've declared
something from MSVBVM50 that could have been declared
from MSVBVM60.DLL?

> msvcrt.dll
> scrrun.dll - Maybe you can dump these. See if you really
need to use the FileSystemObject.

> VB6 Runtime and OLE Automation.
>

> As for a packaging program, what do you find to be really, really good and
> easy to use?
>

That's up to you. A lot of people really like Inno. I like
to use the PDW. I've rewritten the code for my
own use and I can now make fully customized
installs with my own graphics, an EULA clickthrough,
desktop shortcuts, etc. I also shrank the size of it down
by quite a bit. (The Setup1.exe project comes with
VB. Setup1.exe is the PDW installer. So you can
write your own installer if you want to. See here for samples:
http://www.jsware.net/jsware/vbcode.php3 )

A lot of people complain about the PDW, but it works fine
as long as you're not shipping newer versions of
protected files. SCRRUN.DLL is a good example of
that. It's pre-installed on 2000/XP and probably on
WinME. Those systems won't let you overwrite it.
So you should ship the oldest version that you need to
do the job on Win98. That way the pre-installed versions
on 2000/XP will be newer and therefore your installer,
whatever you use, won't try to overwrite on those
systems. But you'll still have it there in case it's needed
on Win98.

Using the PDW offers potentially more control and
customization, but I've never heard anything bad about
Inno from anyone. (Their interface is very bland, but
so is IS and MSI.) The only thing I would never use,
personally, is MSI. It's a breathtaking mess.




From: BeastFish on
> The basic rule to avoid such issues is to build and test on the lowest
> level OS that you wish to support, in this case, Win98. Keep a minimal
> install Win98 box around for that, or have a dual boot system so you can
> use it for testing.

Drive drawers, baybee <g>

(AKA, disk caddies)


From: Jan Hyde on
"WebBiz" <justask(a)andyouwillget.com>'s wild thoughts were
released on Wed, 4 Oct 2006 16:25:30 -0500 bearing the
following fruit:

>Greetings!
>
>Recently someone with Win98 had a problem when installing and trying to run
>my VB6 program. Some files that needed to be on the machine were not, or
>were too old, or a variation of such. My XP customers have no problem
>installing my app.
>
>I've been using INNO_Setup to package my installation. Without really being
>up on how to determine what all files need to go with the program, it is
>pretty much hit-n-miss for me.

In that case use the VB6 P&DW to create a dependency list so
you know what you app needs.

Stick to Inno for doing the actual install though.

J

>I used to use the VB6 package program, but it makes VERY BIG downloadables.
>The INNO program makes them so much smaller.
>
>But with this recent Win98 issue, I had to do the fat VB6 deployment/package
>wizard. So rather than 3 meg download, it was 8 megs!
>
>My question is this:
>
>1. What do you recommend as a good deployment/packaging program? I'm I cool
>with Inno, or is there actually better/easier?
>
>2. Is there an easy way to determine which files I must install with my
>program? Inno requires I know upfront what they are.
>
>3. How do you know whether you should replace the file on the user's machine
>if it already exists? Is there Win98 vs. XP file issues?
>
>I want to make sure that all the proper files get loaded onto the machine if
>necessary, whether they are using Win98, XP, Win2K, NT, etc.
>
>Thanks in advance!
>
>Rick
>


Jan Hyde (VB MVP)

--
Meditation is not what you think.

From: mayayana on

> If you've installed VB/VS service packs, a lot of
> what's in those is updates for files as a result of
> problems that have occurred over time. The PDW will
> take files from the folder Wizards\PDWizard\Redist, if
> they're there, rather than from the XP system folder.
> For instance, with the VC6 runtime, MSVCRT.DLL, the
> version to ship is 6.00.8397.0. (Though as Steve Gerrard
> said, very few people will need that file.)
>
Rereading my post, I realized this parapgraph
was confusing. What I was trying to say was this:

Occasionally some kind of problem is found
with specific files. A given version might cause
problems on one system or another.
One of the functions of the service packs is to
deal with that.
The way they deal with it is to put a safe version of
the given file into the Redist folder. When the PDW
runs, it checks that folder. Any file in there will be
used in place of the system folder version.


From: WebBiz on

"Steve Gerrard" <mynamehere(a)comcast.net> wrote in message
news:Tu2dnfmlUO_X_7nYnZ2dnUVZ_o6dnZ2d(a)comcast.com...
>
> "WebBiz" <justask(a)andyouwillget.com> wrote in message
> news:7mXUg.20522$2g4.11454(a)dukeread09...
>> "mayayana" <mayaXXyana1a(a)mindXXspring.com> wrote in message
>> news:DyWUg.6929$o71.545(a)newsread3.news.pas.earthlink.net...
>>
>> Okay, I ran PDW and it gives me a list:
>>
>> comdlg32.dll
>> comdlg32.ocx
>> fmtkit32.dll
>> igtabs40.ocx
>> igtoolbars50.ocx
>> mscomctl.ocx
>> msvbvm50.dll
>> msvcrt.dll
>> scrrun.dll
>> VB6 Runtime and OLE Automation.
>>
>> So I should include all of the above EXCEPT the VB6 Runtime, correct?
>>
>
> According to your first post, when you had the Win98 user run the PDW
> setup, it worked, is that right?
> If so, the PDW would have made a "Support" folder, with the versions of
> each file it used in the setup. Those are the ones to use.
>
> Your list doesn't look like 8 Meg to me, and what is different in the Inno
> setup that it includes only 3 Meg?
>
> The general wisdom is not to include msvcrt.dll; doing so can cause "file
> in use" errors, and most users have several versions already and there is
> no need.
>

Hello Steve.

Wish I could answer the 3 to 8 meg deal. But I cannot. Just watched it as I
FTP'd it to my server.

Yes, a support folder was created and some other files outside of it.

You mentioned "msvcrt.dll". Now this is what I'm talking about. How does one
go about knowing 'what' should and should not be part of the package, to
avoid these install problems?

As for the PDW that worked on the Win98 system, how would I have known this
BEFORE sending out the install program? There are no Win98 machines in my
office. I had actually fix the problem on the customers machine directly.
Just couldn't figure out why, over email or phone, it would not install on
his machine. So when I got a hold of his computer (yes, had him send me the
laptop), I found my install did not work. So I loaded all the PDW files
(including support folder) onto the laptop and install it again. It worked
after that.

So that is what I'm trying to avoid for future installs.

Thanks.
Rick