Slashdot Mirror

Macrovision is behind many foul evils of our time... besides the video corruption schemes bearing their namesake. They're also behind SafeDisc, a data CD corruption technique almost universally used by game publishers. They've recently introduced a DVD corruption scheme as well.

Installshield has always been slow, ugly, buggy, bloatware, but I didn't know until now that Macrovision is behind that. I also didn't know that Macrovision has added product activation to InstallShield 11.

This is not exactly new technology, it's just that Macrovision is trying to monetize it. Of course, who's going to protest the patent?

But then again, it is Macrovision, and Macrovision has a long and sordid history of injecting 'security' technologies that do much more harm than good, and at the end of the day are bypassable except by the painfully incompetent. Even the painfully incompetent were able to find the filter for the original Macrovision videotape "protection" -- and this before the internet had been commercialized. At the end of the day, it just annoyed more than hurt folks who were pursuing "novel" uses of content.

Look at this way: Adobe uses Macrovision's SafeCast to protect Photoshop CS and now CS2. It does not take too much looking around to find 1) the applications and 2) numerous ways to get around it.

At the end of the day, Macrovision is a slow, old cat, and the mice they chase are not only faster, they are smarter too.

If I were trying to create software for a major financial gain or for something I wanted the WHOLE WORLD to use, I'd prefer my own hand coded installer.

Reinventing the wheel is seldom a profitable activity. Let's say that a senior programmer's time costs you $125/hr. A copy of Installshield Premier is $2,499. That equates to 20 hours of your programmer's time. Do you really believe that ANYONE can produce a complete, fully-tested installer in less than 20 hours? Good luck selling *that* idea to your investors.

As a software customer, if I installed a windows program and it saw that DIDN'T use installshield or one of the other major installers, I'd be HIGHLY suspicious about the company and the product.

InstallShield X actually is Mac OS X native.

However, it is incredibly unclear as to if this is what they are referring to, or if they are talking about installer.app.

All in all, I won't be giving them $50 if they can't even be clear and concise about what I get for my $50...

A couple of counter points, I think.

Debian can't be supported as long as it bucks the RPM trend

Let's face it. Most of the most popular distros are RPM-based. Many of this distros have collapsed, but as far as installed-base out there, if a company such as IBM is going to support a native installer (like installp on AIX, pkgadd on SystemV such as Sun or SCO, swinstall on HP-UX, etc.), which one are they going to pick? Each native installer is another CD in the box and another fixpak to generate. So, to keep costs down while still being able to claim Linux support, RPM it is.

There are other solutions here, of course. InstallShield MultiPlatform (ISMP), now called InstallShield X, or the new InstallShield for IBM Solution Installer would work - with their own problems of not being integrated with how the rest of the system is being installed. Using "rpm -qa" no longer tells you what is going on with that vendor's products. Solves one set of problems at the expense of creating others.

Stability is a hype word

I mean, come on. We're all predicting that the Longhorn delays will give Linux a chance to wedge in because the churn that industry pretends to hate isn't frequent enough. Industry, and the economy, is addicted to regular updates and regular fees to keep the money moving. If Ford doesn't buy a new OS, that OS vendor's employees don't get paid, and put off the purchase of their brand new Ford, which causes Ford to make less money. It's all funny-money anyway (and I'm a capitalist!).

In this industry, 3 years is a bit too long to delay. Companies are trying to get a bigger return on their buck, and want the features (and security fixes) available in the 2.4 or even 2.6 kernels. Sticking with the 2.2 kernel can be great for some people, but without some of those boosts, DB2 v8.2.x won't be able to get all the performance it can out of the machine.

What they want isn't a lack of options that Debian Stable offers. They want the option to stick with a 3-year-old product and still get support, or to update to the latest-and-greatest product and get more bang for their computer buck.

Have RH and SuSE/Novell managed to find the happy medium between the extremes of 3-month cycles and 3-year-cycles? Only time will tell. I would bet they've come close enough.

A couple of counter points, I think.

Debian can't be supported as long as it bucks the RPM trend

Let's face it. Most of the most popular distros are RPM-based. Many of this distros have collapsed, but as far as installed-base out there, if a company such as IBM is going to support a native installer (like installp on AIX, pkgadd on SystemV such as Sun or SCO, swinstall on HP-UX, etc.), which one are they going to pick? Each native installer is another CD in the box and another fixpak to generate. So, to keep costs down while still being able to claim Linux support, RPM it is.

There are other solutions here, of course. InstallShield MultiPlatform (ISMP), now called InstallShield X, or the new InstallShield for IBM Solution Installer would work - with their own problems of not being integrated with how the rest of the system is being installed. Using "rpm -qa" no longer tells you what is going on with that vendor's products. Solves one set of problems at the expense of creating others.

Stability is a hype word

I mean, come on. We're all predicting that the Longhorn delays will give Linux a chance to wedge in because the churn that industry pretends to hate isn't frequent enough. Industry, and the economy, is addicted to regular updates and regular fees to keep the money moving. If Ford doesn't buy a new OS, that OS vendor's employees don't get paid, and put off the purchase of their brand new Ford, which causes Ford to make less money. It's all funny-money anyway (and I'm a capitalist!).

In this industry, 3 years is a bit too long to delay. Companies are trying to get a bigger return on their buck, and want the features (and security fixes) available in the 2.4 or even 2.6 kernels. Sticking with the 2.2 kernel can be great for some people, but without some of those boosts, DB2 v8.2.x won't be able to get all the performance it can out of the machine.

What they want isn't a lack of options that Debian Stable offers. They want the option to stick with a 3-year-old product and still get support, or to update to the latest-and-greatest product and get more bang for their computer buck.

Have RH and SuSE/Novell managed to find the happy medium between the extremes of 3-month cycles and 3-year-cycles? Only time will tell. I would bet they've come close enough.

Funny you mention that. InstallShield is available for vendors to use if they want to create an installer for Linux.

Why the heck vendors are sticking with their own crappy command-line-only installs is really beyond me. Only one I know of that uses IS for Linux is if you download the Java NetBeans Cobundle.

Actually, UnrealTournament 2004 may also use ISX. I remember some nifty Java installer....

Definitely something useful for small developers who can't afford an installshield license.

I agree that InstallShield is a pretty good solution, but keep in mind that you've got to author your initial MSI properly or upgrades and patching will be very difficult. I've had to upgrade MSIs that weren't build properly initially (lots of "AllOtherFiles###" components, dynamically linked components, missing upgrade table, etc.), and if you don't build that first MSI properly then you're piling hacks on top of hacks. Spend a few bucks on a consultant or ask an expert for some free advice if you need to, but do it right the first time.

InstallShield offers an update service that helps automate the patch distribution, you might want to check out InstallShield Update Service for more information on the update service. It seems like a great option if you can't use BITS (and may be a good option even if you can).

(Hopefully links above don't violate terms of service, I did a quick scan and they don't seem to, but if they are in any way offensive I sincerly apologize. The point is to do it right the first time and get expert advice if you need it. InstallShield offers consulting too, and some of their team is pretty good.)

I think once you spent hours disassembling and debugging these "simple" installer programs to make them run on Wine you'd have a different view on the matter ;)

Let's do a quick review of how things are done on Windows:

• InstallShield/NSIS type installer programs. These embed all the data needed inside themselves, or in the case of InstallShield the actual installer is wrapped by the equivalent of a WinZip self extractor. Ever wondered why InstallShields take so long to start? Well, the first thing it does is extract a bunch of files (setup.exe, data.cab, some dlls etc) that comprise the installer, then it runs setup.exe which in turn extracts the InstallShield Engine to your local hard disk, possibly upgrading it in the process. Then it runs it and makes RPCs to it using DCOM, which starts the actual installation - done by iKernel.exe.

  This is sort of how autopackage works, except we do it in a much simpler way and don't rely on CORBA (the nearest equivalent of DCOM on Linux). These installers have no dependency management beyond "is this file the right version? No? replace it then" which has caused some truly horrific hacks like Windows File Protection.

• MSI packages. These are the closest Windows has to traditional RPMs/DEBs. You need to install the runtime support separately for MSIs to work. They are based on a bizarre kind of database, with its own dialect of SQL. MSIs are mostly data but are extendable via COM, iirc. They even deal with dependencies, via MSMs (merge modules).

  Yes, Windows apps have dependencies too. Check out this list to see..

  MSIs "deal" with dependencies by including the least common ones inside themselves, causing huge and bloated downloads, and leaving the user to figure out random breakage for ones that don't exist (how many times have you found that an app assumes the presence of some VB/VC++ runtime lib that just wasn't there?).

  They can get away with this because Windows is a platform and a whole pile of technology is guaranteed to be present. For instance, you know without needing to check that graphics support is available, because it's a part of the kernel and cannot be removed. On the server that's an achilles heel, on the client it's an advantage (in terms of packaging).

• MSI/InstallShield hybrids. [shudder]. Let's not go there. These things take evil to a new level.

• Zip files. All MS Windows binaries are relocatable. In contrast, virtually no Linux binaries are. That's partly because it's not at all obvious how to make them so - there is no glibc API available to figure out your absolute path, rather stupidly (and I'm too scared of Uli Drepper to submit one ;). We wrote a simple dropin C file to help C/C++ programs do this - making a program relocatable makes many users lives a lot easier, so do it today.

Because there is no standard Linux platform (the LSB never caught on), and the user can basically arbitrarily add, remove or upgrade individual components as they see fit (from the kernel to the theme in use) package managers are used to manage and maintain it all. Unfortunately, because there is no standard platform, the distro becomes the platform - of which there are many.

The freedesktop.org platform effort and the LSB are both worthy steps forward in this area and I hope they pick up steam. In the meantime, approaches like autopackage, being dependency-smart and having communities of packagers are the way forward.

Can anyone offer some input on how a programmer can redistrubute updated code to the users.

Can anyone offer some input on how a programmer can redistrubute updated code to the users.

InstallShield and Wise are perhaps the best-known products for deployment management. Use the professional products, they might add a little to the bottom line of the products, but will save hours of support time from angry users calling and asking where they can get the missing library.

Or switch to Java/.NET, lots of issues related to DLL Hell have been solved there.

basically because of a honeytoken like entity

someone at installshield had an entry in some internal company data source using her maiden name (and had used her maiden name nowhere else). she recieved solicitations from wise and got suspicious.

now installshield is sueing the hell out of wise, see this article, and this news release

And there's not an installer since they signed a bad contract with InstallSheild, who doesn't have a Linux version.

Incorrect, InstallShield has InstallShield Multiplatform which handles "[...] Mac OS X, OS/400, Windows, Linux, Solaris, AIX, HP-UX, and all other OS platforms you target." It creates a Java Swing GUI (commandline available by using the -console switch) which I'm using at work to create installers for our apps. Our target archs are AIX, Solaris and Linux, you layout your app, then it creates the installers for whichever archs you choose. It's really pretty nice, if you don't mind waiting for the Java GUI to load. ;)

CB

I wish there was a unix equilivant to installshield for windows.

InstallShield offers a Linux version now...has for awhile. Too bad the Linux companies won't use it. It is Java based, and it is pretty damned cool. And, of course, you can view files and thier install paths with the setup list. Would probably help in cases like this...

http://www.installshield.com/iemp/specs/default.as p/a?