From: mayayana on 4 Oct 2006 23:27 > > 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 5 Oct 2006 02:13 > 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 5 Oct 2006 04:04 "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 5 Oct 2006 08:31 > 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 5 Oct 2006 11:40
"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 |