I've been reading on a MS hosted forum lately about Windows for 64-bit. (In anticipation of the new workstation). It came up that install shield is a
32-bit app that still has some 16-bit stubs. Whatever stubs are. The reason this came up is that it has problems on Windows for 64-bit.
Could this be the reason we're supposedly going to be glad for WI? So that SW will install cleanly in a 64-bit environment? I imagine development has halted on install shield, so that the 16-bit stuff will never be updated. In that case, it does make sense to move to WI, however grudgingly.
The stubs alow a program to pop up a warning alongs the lines of 'This application requires Win32' and not crash in a heap when run on 3.1 machines. Not really very relivant thesdays. When the 16 bit stub sees thats it's on the right OS it launches it spawns the real installer, which is 32bit and these that will then hand off to msi to do the work.
Install shield is very much alive and kicking, it is basicllay a layer over MSI now. Same really goes for WISE as well.
You might ask: "Why can't I just run my standard programs on this new server and automatically gain all of the additional capacity that 64-bit systems deliver?" The 64-bit machine architecture is more, however, than just a standard PC with additional address lines. It has an entirely new instruction set: it is a different machine architecture. Native 64-bit components have to be ported and re-compiled to run on a 64-bit machine. While there is an emulation subsystem (called WOW) in Windows 2003 that allows 32-bit applications to be run on the 64-bit platform, it is a subset of Windows and not all facilities are available. Also since it is an emulation of a different instruction set, it is considerably slower than a native 64-bit program.
There is another option though and that is to use an AMD 64bit CPU as it's instruction set is an extension of IA32 that allows it to run both 64bit and
32bit code and 16bit code.
Back to the point in hand, Why would you not want SW to move to MSI? the technology is far superior to anything that came before it?
Doesn't make sense. SW does not seem to be much interested in going 64bit. My guess is MicroSoft influenced them more than anything. There is no other reason I can think of that they would do something so detrimental to so many customers.
Well that's rather screwed up. I have several applications that use the MSI patch technology, most relevant probably is Autodesk Inventor and that takes a couple of minutes at most to patch it's self for a service pack release.
Just about every new installer is based on MSI these days, if the SolidWorks patch takes that long to apply it says more about SolidWorks to me than MSI.
I can't say that's unreasonable. The reason MSI was questioned had to do with timing. The first experience most SW users had with it in connection with SW was sp2.1. The update experience was horrible, so we users looked for what changed. The installer was the only thing most of us could see that had changed, and several users already didn't like it because of other admin issues. Call it a scapegoat. Eventually, the blame did fall to SW implementation of the installer, but the question remained of why the change was made to the new installer, when everyone was happy with the old.
A good question, and the answer is to the end user not a lot.
Now if you ask the same question from the developers or network administrators point of view that's a different matter. For the developer Install is going to be obsolete over the next few years and quite frankly isn't very nice to use for big projects, especially those that are made from many components that have cross dependences or ship as different versions (Student, Developer, Pro etc) and the need to be translated (i.e. Resource management). Also you gain other features such as Install/uninstall applications with component-level management (in installScript you pretty much have to roll your own uninstaller), automatically repair key product files that have been corrupted, Roll back to a computer's original state during a interrupted installation, and the fact the installer runs in the local machine context means you do not have to be an administrator to install things like device drivers (this can be disabled via group policy).
As an Administrator you can use MSI via Active directory to advertise applications (in add/remove programs click on add new programs to see the list of available programs on the network) this list can be managed on a per user basis via GPO. GPO can cause a MSI to be installed when a machine is installed or added to an OU and removed when the machine is removed from the OU all without any user intervention. The automated install can be done via other methods but GPO and MSI is the cleanest method there is. Also MSI supports the idea of transforms that can be applied to installs to control what options get installed which again can be set on an OU basis.
Probably because we complained that we couldn't roll back SPs when the new one causes more problems than the old one. We had to do a full uninstall and reinstall and then apply SPs to the point we were comfortable with. I do agree though that the 2.1 install took me way longer than expected. Before I had actually done it I thought everyone was just blowing steam and finding something to complain about, now I realize that it was all warranted.
Maybe SW just hasn't figured out the best setup for the installer. Not that that is acceptable.
Some suggestions for SW
Find ways to refine installation. When you have to apply a 166Mb SP atleast call it a new major release. If you still want to apply a 166Mb SP please add some prompts
Please go get a cup of coffee. This may take a while. or Please leave office/home for 30min to 2hrs. This MAY be done when you get back.
or you could just add some fun game like Tetris or Bejeweled or Breakout something to keep our minds off of how long it really takes to apply a SP.
and for goodness sake pleas add a disclaimer to turn of the Virus protection. I always remember when it is too darn late.