I'm afraid that I don't have any experience with InstallShield.
I use my own version of the PDW. I haven't had any troubles
but I'm working on Win98 and don't ship the runtime files like
OLEAUT.DLL. (I figure that so few people need them these days
that it's realistic to just provide a link and explanation for those
people. That also saves me 1MB  of traffic in each download.
The only people who won't have adequate runtime files are those
using Win95/98/NT4 who have never installed VB6 software
before.)

     I wonder if I.S. might have an option to package older files
and NEVER overwrite a file with same or later version, similar
to the PDW Redist folder? That seems like a better
approach to me because you can still ship, say, OLEAUT32.DLL
in case a Win95 or NT4 system needs it, shipping only the
latest version necessary, and without worrying about problems
delivering it to Win2000/XP since it won't get installed there anyway.

--
--
Bob Kochem  wrote in message
news:xvivc.13896$bD4.10911{at}nwrdny02.gnilink.net...
> Thank you for the detailed reply.
>
> I am using the Installshield installer. Would it be acceptable or wise to
> use one of it's options "Never write over existing files" ?
>
> I'm pretty confideent that would not harm the target system, but I'm not
> sure what effect it would have on my application.
>
> Bob
>
> "mayayana"  wrote in message
> news:lTbvc.7867$Yd3.2443{at}newsread3.news.atl.earthlink.net...
> >    There was a post about this last week. Someone
> > had trouble on just a few Win98 machines. The trick is
> > to be careful about not shipping XP versions to older
> > machines. You can do that by putting appropriate file
> > versions in the Wizards\PDWizard\Redist folder so that
> > the PDW will use those instead of the system versions.
> > VB service packs have done that for some files
> > with known problems.
> >   I'm using VB6 with SP3. The service packs have put
> > the following versions in my Redist folder:
> >
> >  C02C4EN.DLL -  4.6.1.106
> >  COMCAT.DLL - 4.71
> >  MFC40.DLL - 4.1.6140
> > MSVCRT.DLL - 6.00.8397.0
> > MSVCRT20.DLL - 2.11.000
> > MSVCRT40.DLL - 4.22.0000
> > RICHED32.DLL - 4.00.993.4
> > MDAC_TYP.EXE - last modified 3/18/99
> >
> >  Maybe it also makes sense to add the
> > SP5 runtime file versions to the Redist folder
> > if you're distributing those, since you had
> > trouble with OLEAUT32.DLL. The publicly available
> > runtime installer should have appropriate file versions
> > for all machines.
> >
> >
> > > Are VB programs distributed from an XP development platform more
likely
> to
> > > encounter DLL problems on a range of target user's systems?
> > >
> > >
> > >
> > > I have been distributing applications developed in VB5 and VB6 for a
> > couple
> > > years now.  Recently I switched my development from a Win'ME  platform
> to
> > a
> > > Win'XP-Home  platform
> > >
> > >
> > >
> > > I am now occasionally seeing a user install the program and report
that
> > > their computer is in some way messed up.  In one case the target
system
> > was
> > > Win'98 and the problem was corrected by reverting one of the DLL's
> > > (OLEAUT32.DLL) to it's original state.
> > >
> > >
> > >
> > > The OLEAUT32.DLL problem on Win'98 is well known and documented in
many
> > > places on the net.
> > >
> > >
> > >
> > > My questions are -
> > >
> > >
> > >
> > > 1.) Are problems like this more common if developing on an XP system?
> I.E
> > > are XP DLL's and the like worse in terms of backwards compatability? I
> > never
> > > had this happen when distributing from an ME machine.
> > >
> > >
> > >
> > > 2.) When distributing the application, would it be wiser to invoke an
> > option
> > > in my installer to not automatically upgrade DLL's, or would that
cause
> > more
> > > problems?
> > >
> > >
> > >
> > > 3.) Would this be any better/worse if I moved all my applications to
> VB6?
> > >
> > >
> > >
> > > I am assuming in the above that the DLLs are 'native' to XP and are
not
> > > installed on my development system as part of the VB 5/6
installations.
> > >
> > >
> > >
> > > I have the option of going back and doing distribution on an ME
systems,
> > so
> > > that only DLL's from the ME system are distributed, but I'd like to
> avoid
> > > that if possible.
> > >
> > >
> > >
> > > Any suggestions are comments on all this?
> > >
> > >
> > >
> > > Thanks a lot,
> > >
> > >
> > >
> > > Bob Kochem
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
---
þ RIMEGate(tm)/RGXPost V1.14 at BBSWORLD * Info{at}bbsworld.com

---
 * RIMEGate(tm)V10.2áÿ* RelayNet(tm) NNTP Gateway * MoonDog BBS
 * RgateImp.MoonDog.BBS at 6/2/04 10:28:30 AM