I have an old legacy application around for which I only have the installer. it doesn't do anything more than uncompress and register itself and his library's.
As i don't have the source-code it gives me a lot of headaches in maintenance problems. In some particular computers (Acer Aspire One with Windows) just do not run.
I would like to extract the files and re-create this installer with NSIS. Is this possible or I'm nuts?
The original installer has been created with Ghost Installer Studio.
One option is to find a machine that it does run on, and then install some "install guard" software (often called things like Acme Uninstaller). Use this to track what actually gets installed and then copy the relevant files and write your own.
It looks like a lot of hassle to me, and you may be on thin ice with regards to the licence.
You could try using a program that monitors new files being installed and then get the files that were installed from their respective paths.
For instance, I found this in about 10 seconds with Google, there are more programs like it, but I am inexperienced with those available for Windows.
If it uses a MSI file, you can use Orca or SuperOrca to get at the stuff packed inside.
This is typically the job of Repackaging Software. There are a few ways such tools work but typically it is by taking a look at a system before and after you install it on a clean system and building a custom installer from the detected changes. This is normally done to generate a customized installation and/or one that can be automated in its deployment. I'm not aware of one that generates an NSIS package, the standard format today is MSI (Windows Installer).
If you have the original installer any repackager will do, but even without the original setup program you can do as some of the others here suggest and monitor the use of the application for its requirements. The two most popular repackaging tools are InstallShield AdminStudio and Wise Package Studio. The feature may also be part of a setup authoring solution, so check with your in-house developers if you can.
A full list of repackaging tools can be found here at AppDeploy.com
One free repackaging tool available for creating Windows Installer setups from another [legacy] setup tool (with which I must divulge I'm involved) is the AppDeploy Repackager. Another free repackager is WinINSTALL LE.
Related
This question may seem really dumb, my apologies for having very minimal programming experience. We just need to make an inventory system exe given to us run and "work" on some computers.
The exe file itself is an inventory system made using Visual Basic 6. It runs fine on computers that have visual basic 6 installed.
However, on computers without VB6, we encounter crashes. The exe's themselves run fine but as soon as we perform something (logging in/clicking buttons/etc.), we get runtime errors 339. On one machine it says, "Component 'MSCOMCT2.OCX' or one of its dependencies not correctly registered: a file is missing or invalid. on another machine, we have a similar error but points to MSFLXGRD.OCX
I figured these problems may be caused by missing system files/dependencies and we need to first install those. How do I make an installer wizard (similar to those Windows app installers that installs system files alongside the actual app) for installing these missing dependencies?
You could do a lot worse than the free Inno Setup. I've used it for many VB6 projects and it's never failed me. There's a learning curve but it's a very flexible package.
I used to use (and contributed to) the WiX toolkit for this purpose.
This will build a standard .msi installer for you. Start with the heat program which will inspect your software and generate much of the WiX project for you, be sure to use the -svb6 option.
You will need to source the appropriate merge modules for VB6 as well, which will provide the components you are missing.
I have a freeware software, which i want to install on a network share. The reason is, if the software is installed on a network share, all users which has access to this network share folder should be able to use the program.
Now, I run the setup.exe on my machine and choose on the step "destination installation" my network share \sharename\TestFolder.
The software was installaing on this sharefolder and after the installation it was possible to run the program on my computer without any errors and use it..
After that I try to start the program on other client but there is always an error message, that it starts with a false operator.
Now my question is, is there a software, which can observe on which files the program want to access when I make double click on the (program.EXE).
Thank you, I hope you can help me.
Yes, there are several tools that can monitor or observe system changes performed by a setup.exe.
Many of these tools are quite old and may not operate correctly in new versions of Windows. The most recent one I found that looks acceptable was EMCO MSI Package Builder. I never tested the monitor feature, but it is at least an updated capture product.
In my experience these monitor tools capture way too much low-level system stuff, and you will need to spend quite a bit of time to sort out what is really needed for the software to operate. If you have experience with software development you may get just as much information from using a System Internals tool such as RegMon, FileMon or ProcMon. See Microsoft site: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx . These tools are exceptionally useful and known for their small size and great feature set. You can run a ProcMon on the launch of the application executable.
It is also possible that the setup.exe is a wrapper for an MSI file. These files can be viewed with free tools such as Orca and EMCO MSI Package Builder and you can basically see what registration settings are needed for the application to operate. Try opening a command prompt and write setup.exe /a and see if it offers to create an "administrative installation point" - or similar.
If I were to guess I'd say that the software needs to have COM servers registered locally, registry keys added to each local computer and possibly you need to install a couple of runtimes on each system - for example Microsoft C runtime of a particular version. This is just a wild guess. What is the name of the software? If it is a .NET application you may need assemblies installed to the Global Assembly Cache GAC.
I know on windows there are a bunch of installer tools you can use to create an installer, but on Mac OS I've seen two ways to install apps:
A DMG file which you download, double-click, then run an application inside - the application typically has you drag an icon to another icon (representing the Applications folder) to install the app
Another type of file which launches an apparently standard installer, which sometimes brings up a warning like "This installer may run a program to determine if you can go ahead with the install"
What's the "standard" way of packaging an app for install on Mac OS? Is one of the above the Apple-recommended way?
Thanks.
Apple is very clearly making the "standard" to be downloading a program from the App Store. This has the benefit of making application installation transparent to the normal user. And, believe it or not, normal people have a lot of trouble with the concept of installing a program. Of course that benefit comes with some costs, but this isn't the place for that debate–there are plenty of other places for that.
Assuming you don't want to or can't go the App Store route, both PKG and DMG are common ways to distribute a program. Use a PKG if you need to install files aside from your application bundle (which should not be a common use case). In all other cases use a DMG that prompts the user to copy the application into the Applications folder. But a lot of your users will not understand that they need to do that (unless your target audience is solely knowledgeable computer users). They will run your application from the disk image. Ideally in this case, your program will detect that it is running from a disk image and offer to copy itself into the Applications folder.
Packages works well. If your deployment process must be kept simple, it is great.
The Quick build consists of dragging your .app onto Package and it is done.
For advanced packaging, you can also provide a certificate.
http://s.sudre.free.fr/Software/Packages/about.html
We're discussing two things:
first and most importantly, the standard method by which the bits of an executable get laid on the disk in a way that's accessible and properly registered by the system
second, the mechanism for preparing the .app, as recommended by Apple
An older marketing page on Apple's site says it's recommended to create packages (so the Installer application can move the bits in place) with the PackageMaker application.
Its usage is described here: mactech.com/articles/mactech/Vol.25/25.03/2503MacEnterprise-PackagingforSystemAdministrators/index.html.
But as others have mentioned, the elephant in the room is the MacAppStore(MAS for short). Until it's debut, what was standard for large companies was their own custom scripts rolled into an older-style 'bundle' package or using an executable like the VISE installer. Smaller developers usually tried to make their app installable via drag-drop, distributed in zip archives or disk images(for simplicity's sake).
The MAS is different: as of 10.7 it uses a package format (which debuted in 10.5) referred to as a flat package (really a xar archive, explanation here)
which is transferred over http to a hidden folder, installs directly to Applications(after which the temporary folder it is downloaded to is deleted). It drops its receipt and a bill or materials file into /private/var/db, and is therefore audit-able by the built-in command line pkgutil tool, described here: mactech.com/articles/mactech/Vol.25/25.12/2512MacEnterprise-PackagesReceiptsandSnow/index.html
A benefit of using the flat package format is you can pull things over the network more safely and efficiently, but it isn't as easy to work with as bundle packages if you are testing and modifying the package regularly, or iterating to ensure scripts that perform actions or checks work well. Even when flat, putting the pkg in a archive or disk image is recommended for flexibility. More distribution tools expect DMG's than zip's, so there's that as well.
Besides what Apple recommends and what is standard, common practice, there's this article: https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/ which discusses the why's and hows (although mainly for system administrators) of packaging for wider distribution. It is greatly recommended to get more of a feel of how and why things go wrong, and what to avoid.
Try Iceberg!
Another one package creator.
In OS X, many applications are just created as a Relocatable
application bundles that the user just need to copy to the
/Application folder (or any other location). In other cases, when you
need to perform some operations over the machine (such as adding users
or changing permissions) you can use a PKG installer (for example built using PackageMaker), which allows
executing some pre and post install scripts and support some basic
installation configuration, like selecting the installation drive.
Sometimes, as with complex server software, you need more flexibility, for example to show custom pages to
the end user requesting information required to install your
application, like the MySQL port and password or proxy information to
download requirements on the fly (or simply to make it look fancier
:)). For this cases there are other installer solutions like our BitRock
InstallBuilder (disclaimer, I'm one of the developers).
InstallBuilder also has the advantage of generating multiplatform
installers using the same project with very little customization per
platform.
I'm looking for a solution to run multiple setup files (.exe and .msi) in sequence without any user input. The idea is to have everyone in my workgroup to have the same development tools (eclipse, python, cygwin, etc) by running one installer. Besides creating a batch script, is there a software out there that could create such a wrapper of installers?
Thanks!
From my knowledge there aren't any tools which create this type of wrappers, or if there are they are not MSI-based. This is because Windows Installer is very restrictive when it comes to running multiple installers simultaneously.
You can try using a setup authoring tool which supports package prerequisites. This way you can create a dummy package which installs nothing, but still handles all the applications you want installed.
If you want some suggestions don't hesitate to contact me.
I have a service installation that in order to get it to work on Win2k, I had to include instsrv.exe in the installer, since Win2k doesn't include sc.exe (which I use for XP and up) and instsrv.exe is not always installed...so I cannot count on it being there. (instsrv and sc are both used to create/install the service on the system).
I have not been able to find the license terms or distribution rights for instsrv however. Is there going to be a legal issue with me including this Microsoft exe in my own installer and therefore distributing it to the customers of the product? If you can point me to an actual license document for this exe it would be greatly appreciated.
The instsrv.exe program appears to come from the Windows 2003 Resource Kit, which you can download freely from Microsoft. The referenced page indicates that when you install it, you'll encounter the EULA (End User License Agreement), which would be where you'd read about the license terms regarding things like redistribution.
You should read that agreement yourself. The way I read it, you can't bundle the Kit with your installer, though you could certainly arrange to have it downloaded automatically and have its own installer invoked by yours, with your end user having to click to accept the Microsoft EULA at that time.
What about using a different approach? I believe for a simple service installation there are probably only a few registry keys or something to tweak. Maybe a simple script (Python or such?) could do the job as well.
I'm no legal expert, but is the issue the use of instsrv.exe or that it's lying on the PC until you uninstall your product?
Would it be redistribution if you craft your installer in such a way that you merely package instsrv.exe, unpackage during the install process, run it via a custom action, then let the installer cleanup process delete it from the temporary location?
As a big sidestep, you could change installers to WiX v3. They have standard custom actions to install services. You get the added Msi easily active directory integrated bonus. You could go with something else entirely but I assume this is a very last resort.
In the end, services are nothing more than registry entries in a specific format so you are not entirely limited to using those programs. You just get the bonus of blaming Microsoft if either instsrv or sc happen to blow up the registry.