Interviews

Listen to an MP3 of this article  

Five Steps to a Better Vista Installation - Transcript

Transcript of interview with Bob Corrigan, senior manager for global product marketing at Macrovision, and Robert Dickau, principal trainer

MIKE VIZARD: Hello, and welcome to the premium edition of the ACM Queuecast, sponsored by Macrovision, the leading provider of content protection, software licensing and installation, and digital rights management technologies. I'm your host, Mike Vizard, and joining me today is Bob Corrigan, Senior Manager for Global Product Marketing at Macrovision; and Robert Dickau, Principal Trainer for Macrovision. Today's topic is Vista, and the installation routines around Vista and the opportunities that bring developers.

Guys, welcome to the show. It's great to have you here.

BOB CORRIGAN: Hey, thanks for inviting us.

ROBERT DICKAU: Thank you.

MV: I guess a lot of things that are on most developers' minds these days is how they're going to deal with Vista. I mean, the noise level around Vista is just about now reaching a crescendo, and people are starting to wonder what the implications in terms of being a developer on Vista are, and in particular, what does Vista mean for their software installations? So can you guys enlighten some folks about what's going to happen with Vista around the whole installation process?

BC: That's a great question. Vista's been in the rear view mirror now for so long that developers have been thinking about it as much as they are now that it's right on top of us. And of all the things that Vista brings to the table, it brings a lot of new technologies that are going to have a very meaningful impact on the installation experience that end users will have when they install a program that they get from a software producer.

So the sort of things that we feel software producers and developers are going to want to be aware of are the things that are going to make that installation experience the best it can possibly be, and these are things that we've spent a lot of time on. The InstallShield team has been working to really optimize so that the installation experience for the end user can be as best as it can be, and the installation development experience can be as good as it can be. Robert, are there some thoughts you have on what you're seeing from the development community from the folks you've been doing training with?

RD: Well, exactly. The idea is just like the change from Windows 98 to the Windows NT-based systems and NT Fords 2000 and so forth. There are a lot of changes throughout the whole development and installation experience, and so we try to make it as easy as possible to address the new features that Vista's going to provide.

BC: So I've got five things that I think if we talk about them today we'll do a service to any developers who are listening in. The first thing is that inevitably a software developer is going to have old installations they've created for previous versions of Windows, and they're going to have a question, "Well, how is this going to perform on Vista?" The good news from Microsoft is they've done an awful lot of work to make sure that previous versions of MSI, or Microsoft Windows Installer, work well on Vista. The question is how well do those old versions of MSI play with some of the new capabilities of Vista?

So when it comes to knowing your gaps, as a developer it's helpful to have an ability to in an automated way scan your old installers to see how well they're going to perform on Vista and then call out some of those deficiencies before you move any further so that you can take a look at what you need to change.

So we've delivered with InstallShield 12, specifically in the premier edition, a almost think of it as a validation scanner that will take your MSIs either from older versions of InstallShield or ones you built yourself from scratch or ones you've built with InstallShield 12, and will sweep through and apply some tests that we've derived from the Vista quality program's requirements around installation. And it will step by step highlight those aspects of your install that don't -- that won't behave well on Vista, and it will give you some recommendations on how to go about fixing them.

One of those is, for example, how you can take advantage of the restart manager. The restart manager is something Microsoft has provided to make the installation experience I think a lot more palatable for the end user by working to eliminate many of those unnecessary restarts that would be seen as unnecessary by the end user, but are certainly necessary as seen by Windows. So we've given the ability to integrate some dialogues into an install to take advantage of the restart manager so that applications can be given an opportunity to elegantly shut down and then avoid the requirement for restart. Rob, is that something you've seen some end users talking about?

RD: One of the biggest complaints that end users had is that they don't want the installation program to sort of interrupt their work or their day or anything, and so with earlier versions of MSI, you may know, there was a dialogue box that would tell the user that they needed to shut programs down, but if they chose to ignore that it would just reboot at the end anyway. And so with the newer version of MSI with Vista, there's this new capability and new dialogue box that lets the installation program not only shut down applications that it needs to update, but then also start them back up when the installation is finished, and five minutes later they can forget that they had to install anything, instead of having to wait around.

BC: So that's an example of a simple, elegant solution to a really painful problem. But one that is I think a really meaningful pervasive issue that Microsoft has addressed with Vista is the question of user account control and how to help end users operate in a more secure way on a daily basis. Inevitably, when you go to install a program, many programs require elevated privileges in order to do some of the things that they do, whether that's write files, write to the registry, or whatever other magic the developer has built into it.

What we've done with InstallShield 12 is make it so that installation developers can create installs that are much more polite in that if you require multiple grants of administrative privilege throughout an install, rather than seeing that dialogue pop-up 12, 15, 20, however many times it's required, it's a pretty elegant solution. We will prompt and give you the ability to prompt for those permissions once and then it will apply them through the rest of the session.

Robert, I know when dealing with the user account control feature,that that's one of the areas that seems like it's going to have a real impact on the quality of the end user experience.

RD: Yeah. I mean, one of the themes for Vista is accountability for what's actually Installing on the user's machine, and so the user account prompts are something you get for free, whether you want it or not. And so while it's technically acceptable to prompt over and over to ask if the installer should be allowed to do certain things, we make it as easy as possible and ask as few questions as possible. So it makes the installation experience as smooth as it can be, as you said.

BC: You know, and related to that, the fourth thing of the list of topics that we think are really going to be in the mind of the developer looking at Vista, especially from an installation perspective, is that Microsoft has taken a much greater focus on making sure that developers sign their installations and get those signatures into the MSI. Robert, in the past, is this something that people did all that well?

RD: They did not do that all that well. I mean, it was partly difficult to integrate into the development process and the installation development process, and so we've made it a lot easier and the validations make it a lot clearer what parts of the installation need to be signed, whether it's the set-up.Exe itself or that actual executables they are installing, it's a lot easier to do now.

BC: Yeah. I think those two things that we just talked about go hand in hand, making sure that we handle the authorizations around user account control well and in a way that's easy on the end user and well-understood by the developer, but also make it easy to get those signatures into the MSI so that there is no doubt on the part of the end user that what they're receiving is something that is genuine and they can have a high level of trust in it.

The trust question is meaningful not just on a day-to-day basis operating Windows Vista, but it's especially a concern when somebody's bringing something new into their Vista environment and InstallShield 12 has a big role in making that trust something that the developer can help implement.

Now, the fifth thing that we wanted to chat about -- and frankly this is something that is not broadly implemented in the software development world -- is how people test. It's not uncommon to have developers build their code and test from the nightly build, but more and more when I'm out talking with some of our customers, I'm discovering that they're really interested in testing as deployed, so the challenge of building and building your code and then automatically building the install from that and then testing the product as it would be experienced by the end user is a best practice that I think around Windows Vista is going to have a tremendous yield in quality, especially for the first applications that go out. Robert, is that something that you would echo in some of your experiences?

RD: Oh, certainly. I mean, something that we've seen all along is that people think of installation as sort of an afterthought, and so by integrating the overall product development process with the installation development process, I think people will be a lot happier, especially with the new rules that come into play with Vista.

BC: We started looking at Vista quite a long time ago and working with our partners at Microsoft to get a better understanding of what the implications would be on the installation. And whether it was user account control, whether it was some innovations in the restart manager, whether it was their new focus on getting signatures and certificates into the install, whether it was their focus on a much more rigorous quality program that had touch points across the entire development continuum, including installation, it was clear to us that there were a number of important touch points that would allow developers to not just be compatible with Windows Vista, but to truly exploit and really take advantage of those new capabilities in a very meaningful way to improve user experience.

We only get this opportunity every few years. When the Microsoft Windows operating system shifts, the installation world shifts with it. And this time there are a number of changes that are very meaningful to installation. And for the application developer and the installation developer, the availability of InstallShield 12 to support and exploit those Windows Vista-specific capabilities I think is going to be a real advantage and help improve the overall rate of acceptance of Vista. Robert, would you agree or disagree?

RD: Oh, certainly I agree.

BC: So there you have it. Those are the top five things that we think are going to be important around the installation and things that you can do both with InstallShield 12 and from a process perspective to create better installs and create a better overall installation experience for the end users.

MV: Given that Vista is such a big deal, why would anybody think about writing their own install routine? What process leads them down that path given all the things they have to do as a developer; it just seems to me it's not something that they'd want to spend their time on.

BC: That's a fair question. One of the challenges that we face at Macrovision across all our product lines is that we're selling solutions to very very bright people who are used to building software solutions on their own. So when you think of what an installation is at its most basic of levels, it's nothing more complicated than unzipping a file into a directory and starting to play with it. But when you start looking at all the complexities associated with putting a program into a consistently usable state on an end user machine, it becomes clear that doing it on your own, while it may be useful for the first generation of a solution, rapidly becomes unacceptable as your application becomes more complex, as the number of your customers grows, and as you start thinking about what the challenges you're going to have in supporting all those customers is going to be. Robert, from your perspective, what is something that you think drives people from writing their own tools to looking at a tool like InstallShield?

RD: Well, I think a lot of it is just inertia. The way they've always done it is by hand. But I mean, it's sort of the difference between I can type all my letters on a typewriter, or I could use a word processor that has spelling checker and everything built into it. So I think it's just habit. But as there are more and more requirements, it's less and less feasible or less and less good use of people's time to do it by hand. And so we hope that by using InstallShield 12 with the built-in Vista rules, the spelling checker with all the newest words in it and so forth, they'll save themselves a lot of time.

MV: Just about every application that I see people using has an InstallShield wrapped around it for its installation process. And maybe that's not true of corporate applications pre se, but I was wondering is there a value proposition to the fact that as a developer I'm going to use the same install routines as other developers so that the user has a common experience when deploying multiple applications?

BC: I think that a very strong draw for the software development community as a whole, especially in the Windows world, is that the end user has a certain expectation of what the experience is going to be, and by virtue of how long InstallShield has been on the market and how consistent we've been in supporting new Microsoft technologies as they've come down the road, that the end user sees InstallShield, and there's a level of confidence they get knowing that, "Okay, well, I've got a professional install and un-install experience. I know that when I'm done with this I'm going to have my software in a state that I can use it in," and that the developers as they use InstallShield as they move from job to job bring those skills with them and bring their particular way of going about building installations with them.

And it becomes a benevolent cycle over time that the professional application and installation developer team wants consistency in how their products are delivered. The application development manager wants to speed up the time it takes to get through the final steps of the development cycle. The support manager wants consistency in how the product is installed so they don't have a lot of support calls. And ultimately the people who are running the organization are keenly interested in having the highest customer satisfaction possible.

When you boil all that down so much of it comes down not just to the quality of the solution that is delivered and sold, but the quality of the very first experience the end users have. And that first experience is the installation experience. So, yeah, I think there is a very strong value proposition behind it up and down the software producer organization.

MV: What is your take on the chicken and egg question about when the right time to start developing for Vista is? Because you'll hear a lot of developers say, "Well, I'll develop for Vista when there's a lot of platforms." And you'll hear the buyers say, "I'll buy Vista when there's a lot of applications." And, you know, if we let that go on forever, nothing will happen.

RD: Well, I mean, whenever it happens, it's not too early to start planning for it. You don't want to be caught by surprise when the sort of critical mass of it takes place.

BC: Well, I can give you some metrics that we've seen. We had InstallShield 12 available for sale earlier in 2006. And just from an objective perspective, if the market as a whole was just not interested in Vista, I don't think we would have seen the level of uptake that we've seen around InstallShield 12, where the key message in that product was "Get ready for Windows Vista." So like a lot of things, I think thoughtful application developers recognize that while it may not be here today, they need to have it on their horizon--their planning horizon is not a two-week horizon; it's a six-month, one-year horizon.

So from our perspective, our goal is to help people create installations that are optimized for today's technologies, so that when they need to deliver that very same application to Windows Vista that used to be delivered to XP they can have a user experience that's optimized for Vista, whether that is 2 percent of their target audience, whether it's 50 percent, or whether ultimately it becomes 100 percent.

MV: Do you have any insight as to whether or not people are bringing their XP application forward to Vista, or are they in the process of building new applications that really take advantage of the full features of Vista, or is it somewhere in between those two?

BC: I think it's somewhere in between those two. I think once again you've got armies of extraordinarily bright people at Microsoft working over a period of years to make sure that legacy applications are going to run well. One area where you can take something old and present it as something new is around the install. So something that was written for Windows XP, yet you want to create an install experience that is very much integrated with Vista, the first thing they're going to do is they're going to take it, they're going to run the InstallShield 12 validation checker. They'll see how far off they are, maybe implement a couple of the tricks that we talked about earlier for Vista, and then roll that out.

So from what we're seeing, we're seeing a lot of people who are repackaging their existing applications so that they're not just going to run on Vista, but they're going to be able to exploit some of the installation-specific capabilities of Windows Vista. So that first experience the end user has, whether they're just experimenting with Windows Vista or whether they're engaged in a more aggressive rollout, that first experience will be a good one, and they'll go back to the vendor and have happy things to say.

MV: Okay. Last question, guys. I think most people are probably familiar with InstallShield on some level, but what is it specifically in Version 12 that people should pay attention to?

BC: Well, I think we talked about it a few minutes earlier. There were a few things that we worked very hard on when we were working through the InstallShield 12 development process. One was to get out ahead of the marketplace in partnership with Microsoft to help people start to get ready for Windows Vista. So the fact that the product has been in the marketplace while Vista has been in beta, that we've been working closely with the development community to help them to understand the implications of Vista, we've really taken a leadership position in the installation marketplace around Windows Vista, and I think given that it's November, 2006, and magic things are going to start to happen over the next three months with Vista, I think that's the top of my concern.

The second element that we think end users of our product the software developer and the installation developer want to be mindful of is that InstallShield 12 also keeps pace with a lot of new Microsoft technologies that have come out in the last number of months. Robert, do you have a few off the top of your head that you'd want to mention?

RD: Oh, well, there are always new versions of MDAC and XML processors and that sort of thing, and so we do try to keep abreast of those changes.

BC: So the third area that was very meaningful for us is that we've been on a pretty fast march over the last two years with new version of InstallShield, going from 10 to 10.5, 11, 11.5, and 12 only since May of 2004. So come 2006 and InstallShield 12 comes out, we've put a very significant effort into working through the queue of issues that our customers had reported, enhancements around usability and robustness and some -- you know, all the inevitable market feedback that you get.

So the end user experience thus far in the first four or five months the product has been on the market has been enormously positive around InstallShield 12. So if people had an experience with an InstallShield version from years ago and they were wondering, "Well, what has the Macrovision team done to make InstallShield really sing in 2006?" we've put a lot of energy into it and any time spent in our communities will show an end user population that is very happy with this new version. We're especially proud of what we've done to support Windows Vista to work to keep pace with new technologies coming out of Microsoft and to provide the application developer with the highest quality installation development tool that we think we can prepare for them.

MV: Gentlemen, thanks for sharing your insights today, and we look forward to seeing the fruit of your work on a whole host of Vista applications in 2007.

BC: Thanks.

RD: Thanks, Michael.

MV: Macrovision is all about helping producers of digital content protect, enhance, and deliver their content. For more information, check out www.macrovision.com.

acmqueue

Originally published in Queue vol. 5, no. 1
Comment on this article in the ACM Digital Library





More related articles:

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx in Action
DevEx (developer experience) is garnering increased attention at many software organizations as leaders seek to optimize software delivery amid the backdrop of fiscal tightening and transformational technologies such as AI. Intuitively, there is acceptance among technical leaders that good developer experience enables more effective software delivery and developer happiness. Yet, at many organizations, proposed initiatives and investments to improve DevEx struggle to get buy-in as business stakeholders question the value proposition of improvements.


João Varajão, António Trigo, Miguel Almeida - Low-code Development Productivity
This article aims to provide new insights on the subject by presenting the results of laboratory experiments carried out with code-based, low-code, and extreme low-code technologies to study differences in productivity. Low-code technologies have clearly shown higher levels of productivity, providing strong arguments for low-code to dominate the software development mainstream in the short/medium term. The article reports the procedure and protocols, results, limitations, and opportunities for future research.


Ivar Jacobson, Alistair Cockburn - Use Cases are Essential
While the software industry is a fast-paced and exciting world in which new tools, technologies, and techniques are constantly being developed to serve business and society, it is also forgetful. In its haste for fast-forward motion, it is subject to the whims of fashion and can forget or ignore proven solutions to some of the eternal problems that it faces. Use cases, first introduced in 1986 and popularized later, are one of those proven solutions.


Jorge A. Navas, Ashish Gehani - OCCAM-v2: Combining Static and Dynamic Analysis for Effective and Efficient Whole-program Specialization
OCCAM-v2 leverages scalable pointer analysis, value analysis, and dynamic analysis to create an effective and efficient tool for specializing LLVM bitcode. The extent of the code-size reduction achieved depends on the specific deployment configuration. Each application that is to be specialized is accompanied by a manifest that specifies concrete arguments that are known a priori, as well as a count of residual arguments that will be provided at runtime. The best case for partial evaluation occurs when the arguments are completely concretely specified. OCCAM-v2 uses a pointer analysis to devirtualize calls, allowing it to eliminate the entire body of functions that are not reachable by any direct calls.





© ACM, Inc. All Rights Reserved.