• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 422
  • Last Modified:

Need advice on Batch files

I have multiple software/driver packages that I need to install before I install my main application. Right now I have to do each one of these individually (10+). I am looking for a way to have them all kick off through the execution of one file. Is it possible to create a batch file that will execute multiple .EXE files? I have used in the past for similar operations but I'm stumped on this one.

Would batch file be the best way to handle this? If so, example?
Is there any free/cheap custom install package software that can achieve this?

Thanks
0
vecbmcdonald
Asked:
vecbmcdonald
  • 4
  • 3
  • 2
  • +3
1 Solution
 
pony10usCommented:
Here is a brief outline for a batch file with no error checking built in.  Is this something like what you are after?
@echo off
rem install preliminarys
echo Installing first program
  call <install1>
echo First program installed - installing second program
  call <install2>
.
.
.
echo all preliminary programs installed - now installing main program
   call <main>
echo all complete
pause

Open in new window

0
 
vnicolaeCommented:
I would use start.exe instead of call
0
 
pony10usCommented:
vnicolae:

I considered that but my concern was I know that call branches out and runs the other application and then returns upon completion to get the next command in the batch. If memory serves, using start will execute the other program and continue the batch file while the other program is running. This would pose an issue based on the author's comment that the preliminary programs have to be done before the main program installs.

Of course using the call will end up making the program take much longer but will ensure each preliminary program will be installed before moving on to another.

I suppose you could use start.exe and then include some type of check to make sure all the prelimanary programs complete before executing the final (main) install which would speed up the process as long as there are no other dependencies.
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
vecbmcdonaldAuthor Commented:
I had examined using Start but not Call will look into both
Pony - that is what I was looking for but my concern is its ability to work with actual SETUP.EXE files not .MSI installers.  I don't believe I can get an .EXE file to run silently without prompt? Has anyone had explicit experience with using setup.exe or executable files in batches?

Thoughts?

Thanks for the outline.
0
 
pony10usCommented:
That is a tough one.  If the Setup program does call for input then it need to get that information from somewhere. I would consider one of the many freeware/shareware/professional products available to create MSI's.

As long as the programs don't stop and ask for input or wait for a keypress then the basic outline I provided would work as would using the start.exe instead of call with the

Another advantace to using a an MSI is that you can actually work all of that into the MSI and would have no real need for the batch file.
0
 
QlemoBatchelor and DeveloperCommented:
I suppose pony10us forgot the switch to use with start to make it work:
   start "Title" /wait "Executable"
That will wait for the exe to terminate in any case before continueing with processing.
0
 
BillDLCommented:
vecbmcdonald

Do you know for certain whether any of the driver packages or software require a system reboot?

Although the Setup packages are EXE files, that doesn't necessarily mean that there are no command line options available.  Have you tried running the /? -? -h -help /help etc commands on them to see whether you get a command line usage dialog or usage syntax in the cmd window?

Do any of the setup.exe files unpack using WinZip, WinRAR, or 7-Zip?

Often you can extract a package to get the *.msi file, but usually the reason it is packaged like this is because there are "transform" files (eg. *.MST) for different languages that the user may choose as the setup dialog loads.

From the EXE file's Properties you can often determine the packaging software that was used to build the setup file, and from that you may find that there are command line switches including one like   setup.exe /extract C:\whatever

Some self-extracting EXE files can be unpacked using the /X switch like this:
setup.exe /x:C:\DeployFolder
or add /q for quiet:
setup.exe /q /x:C:\DeployFolder

Don't confuse that /X switch with the Windows Installer "uninstall" switch used on MSI files, ie:
msiexec.exe /x packagename.msi

A classic giveaway of a self-extracting archive (that usually unpacks the files for the setup routine to the user %temp% folder) is an extra "Archive" tab in the file's Properties dialog.

The setup.exe files created using the older Windows "IExpress" packager support the following switches to extract or install the contents:
/? = Help
/Q = Quiet modes for package
/T:<full path> = Temporary working folder
/C = Extract files only to the folder when used also with /T
/C:<Cmd> = Override Install Command defined by author
The actual instructions for these files is contained in the setup.exe file and not in a setup instruction file, to be extracted with the files, unless the creator wrote something like an INF, VBS, or other file and packaged it with instructions to use it during setup.

Where a setup.exe file contains an *.msi file and you know the name of the MSI file, then the Windows Installer command line options allow you to run the package like this:

setup.exe /q /c:"msiexec /qb
/a filename.msi USING_EXUIH=1 REBOOT=ReallySuppress /l*
c:\logs\filename.log TARGETDIR=c:\whatever"

If a setup file won't extract by standard means, then there are other ways to unpack and inspect the contents.

Empty your %TEMP% folder and run setup.exe to the last dialog before the full installation begins.  Open your %Temp% folder, refresh using F5, and copy out any new folders and files created to a neutral non-system folder. Cancel the setup and the Temp files should be removed.  Examine the files and see if they can be used as they are or repackaged into a new setup package using something like WinRAR self extractor options that allow you to specify post-unpacking commands to run.  If they use INI or INF files, then you might be able to modify them to suit your needs if you know what all the settings do.

I use a free program named "Universal Extractor" to unpack various types of setup files and examine the contents before I test out new freeware programs.  It creates new Right-Click options for supported file types, but be aware that it may associate itself with some file types that don't normally have file associations by default.
http://legroom.net/software/uniextract

There are so many different types of setup.exe packages around that it is hard to provide specific advice, so have a nosey around them and see what you can find out.  You may be able to chain them together and run them sequentially.

You may be able to find specific information about named software, such as unpublished setup switches, from here
http://www.appdeploy.com/

This is also an excellent site:
http://www.installsite.org/pages/en/msi/tips.htm
and I like the "Windows Installer Command Line Builder" program (WICLB.exe).

I hope this helps.

Bill
0
 
BillDLCommented:
Maybe Qlemo's suggestion of START /wait  will be all that you need ;-)
start /? for full usage.
0
 
Here2HelpCommented:
Hey.

This tool could be useful for you.

DriverForge

cheers.
0
 
vecbmcdonaldAuthor Commented:
Thanks for the help. I took Pony's suggestions and ran with them. Managed to create a batch file to handle everything I needed, and even request user input. There were only 2 programs that absolutely require user inputs (and none require restart).
0
 
pony10usCommented:
vecbmcdonald: Thank you for the points. Glad you got it working.

Qlemo: TY - I started to talk about the Start /wait but as you can see I got sidetracked mid sentence. ADHD is a wonderful thing.  I won't know when Alzheimers strikes.   :)

BillDL:  Good explanation. You managed to cover the one important thing that I didn't and that was reboots. If any of the sub programs required one it would have  been an issue.

0
 
BillDLCommented:
That's great news vecbmcdonald.  A stroke of good luck or a well crafted batch file, or a combination of both, and it certainly saved you a lot of messing around there.
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 4
  • 3
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now