I can share your experience in one way: I once (and only once) had a setup.exe run on Win7, in which the setup seemed to be stuck.
As I know in general there is no problem, I waited. It took several minutes before the usual elevation dialog (asking to allow or log in with admin credentials) appeared(!)
This should not happen, as you are used to an elevation dialog appearing promptly after starting a setup. If this is your first experience with a setup, I can understand you're unsatisfied with Installshield.
As clipper said, you could also update Installshield, the version coming with VFP9 is from 2006 of course, Vista came 2007, Win7 2009, so from that outset a newer version wouldn't hurt.
One major change in Vista was how to acquire special folders, there's a big difference you can see here:
It's a reason people are going over to Inno setup, it's free, in continous development and you can do all the usual stuff in it, if you're willing to learn a bit of scripting (or find the Inno scripts for VFP apps).
You need to dive into the setup process a bit anyway, need to understand COM or ActiveX needs registration, what runtimes are for CHM help support, what is needed for XML functions, but also where data should go at a pc, if your install is for a single user, all users o a pc, terminal services, lan installation, client or server setup. Things that also depend on your application design.
But it's like it's always: Only if knowing what you really want and what you can do, you can find the best solution.
Some admins of customers prefer an MSI setup instead of EXE, as Software Management System can only deploy MSI files to clients.
So you see there are lots of things to consider and still people think this is something they can do in 15 minutes after spending a month programming the application.
I could still continue with knowledge you need about licensing ActiveX, copy protection, 30-day-trial mode, Creating an update installer and making the first setup in a way a update-installation is possible via the same kind of setup. The different forms of setups, setup dialogs, accessing registry, updating your config with the user choices made during installation, ClickOnce installations, Deinstallation (and not removing too much, eg DLLs shared) ... it never ends.
And if you do one customer a favor and hand out a non limited installer, it may already be too late to add protection to further setups. It is too late to shut the barn door after the fox has bolted.
Creating a setup is one of the most underestimated things a developer does. I'd bet it's not seldom a developer doesn't plan time for it, at least not more than a day, if even that much.
Most people don't even know their EXE needs support dlls called runtime, though this is the case for any EXE in any language. It's just some runtimes are preinstalled anyway and you could live without that knowledge with C++ or VB or nowadays even with .NET, as the .NET Framework is widley spread and widely available. So it is quite usual the exe you create is all that you need, even on a customer PC.
Each language not having a linker component does not links DLLS or their LIBs into the EXE, so you depend on DLLs, if only OS Dlls.
To round this up, I know Jochen Kirstaetter has already used NSIS as installer, which compares to Inno in the way you need to write scripts.
I'd always prefer installers supporting Merge Modules (MSM files), as that also handles deinstallation so much better in knowing what things were merged into the system at installation, keeping that info for uninstallation to see what needs to remain. Something you also should take care of - or ideally the setup creation software you use.
I bet you have cursed about some software keeping remains making the installation of the next version or some other software impossible. Do you want to be the one, over which others curse for that same reason?
All this is one motivation for the cloud or classic web applications, moving the responsibility towards a single server, keeping users at the newest version with just the update of that one server. With all the advantages and disadvantages...
Bye, Olaf.