Thursday, 10 June 2010

Packaging interview questions HP

Packaging Interview questions HP

1. Disadvantages of lock permission table – find out
Regardless of the tool you're using, Windows Installer has a table called 'LockPermissions', which we expose in the Files and Folders and Registry views of the InstallShield Project file (*.ism).

However, there are some significant limitations associated with this such that Microsoft is rewriting this feature in a future release of Windows Installer. So, there may be some cases where you'll need to end up relying upon the custom action approach that you've used in the past.
Some scenarios that I'm aware of:
--Not natively localizing user groups based on well-known SIDs
--Appending to an existing ACL (it replaces the existing one)
--The following knowledgebase entry:
2. Disadvantages of repackaging legacy setups
3. Update host file using script
4. Diff bet immediate execute and deffered
5. How to identify the application is 16 bit or 32 bit application
Identify a 16-bit Program
To identify a 16-bit program:
1. Use Windows Explorer to open the folder that contains the program's executable (.exe) file.
2. Right-click the .exe file, and then click Properties.
3. A 16-bit program does not have a Version tab in this dialog box.
Back to the top
Identify 16-bit Programs that Are Running
To determine if any 16-bit programs are currently running, and identify any those are:
1. Start Task Manager. To do so, right-click a blank spot on the taskbar, and click Task Manager.
2. On the Processes tab, note the contents of the Image Name column.
3. If any 16-bit programs are running, you see an entry for Ntvdm.exe, which is the virtual DOS machine that is provided by Windows XP. You also see wowexec.exe (the Windows on Windows subsystem), and the executable name of each 16-bit program that is running in that WOW virtual machine. As a helpful visual aid, wowexec.exe and the 16-bit executable file names are indented.

6. Install moniter , adv and more abt
A traditional snapshot captures differences between two machine states - before installation, and after installation.

The smartmonitor tool captures changes as they occur. Here's a quote from Wise:

"SmartMonitor is the only capture technology that records changes as they are executed by the source installation. SmartMonitor captures the replacement of files, overwriting of existing registry keys and more."

If an existing registry key was overwritten with the same value during the installation of a product, a snapshot would not capture this because this would not result in a "change" between snapshots - Smartmonitor should. If you installed your "snapshot" package on a machine where the registry key did not exist, this key would still be missing after you installed your package.
7. VBS, update host file
8. Whether we can open non extension files (VBS)
9. Condition for calling CA during Uninstall
10. Condition for calling CA during only maintaince
11. Where is the options u will go for CA
Standard actions are sufficient to execute an installation in most cases. However, there are situations where the developer of an installation package finds it necessary to write a custom action. For example:
• You want to launch an executable during installation that is installed on the user's machine or that is being installed with the application.
• You want to call special functions during an installation that are defined in a dynamic-link library (DLL).
• You want to use functions written in the development languages Microsoft Visual Basic Scripting Edition or Microsoft JScript literal script text during an installation.
• You want to defer the execution of some actions until the time when the installation script is being executed.
• You want to add time and progress information to a ProgressBar control and a TimeRemaining Text control.

12. When will CA will be executed?
13. How will u debug if application go for self-heal every launch
14. What are the ways the CA can be called?
15. What is the complex application you have done in ue history, why u will call this as complex, what are steps taken to resolve the same
16. Diff between TRAGETDIR and INSTALLDIR
INSTALLDIR represents the main product installation directory for a regular Windows Installer–based (or InstallScript MSI) installation, such as the end user launching Setup.exe or your .msi database.
TARGETDIR represents the installation directory for an InstallScript installation, or for an administrative Windows Installer based installation (when the user runs Setup.exe or MsiExec.exe with the /a command-line switch).
The TARGETDIR property specifies the root destination directory for the installation. TARGETDIR must be the name of one root in the Directory table. There may be only a single root destination directory. During an administrative installation this property specifies the location to copy the installation package. During a non-administrative installation this property specifies the root destination directory.
17. Suppose if i change the TARGETDIR to D:\ but INSTALLDIR passing as c:\pf\VN\APPNAme, where the app will be installed?
18. What are the diff types of properties?
19. Why do u call Pubic property, what is the use of the same
19. What is install on demand and What is adv?
With traditional installation technology, it is necessary to exit an application and rerun setup to perform an installation task. This commonly occurred when a user wanted a feature or product not chosen during the first run of setup. This often made the process of product configuration inefficient because it required the user to anticipate the functionality required before they ever used the product.
Installation-on-demand makes it possible to offer functionality to users and applications in the absence of the files themselves. This notion is known as advertisement. The Windows Installer has the capability of advertising functionality and to make installation-on-demand of application features or entire products possible. When a user or application activates an advertised feature or product, the installer proceeds with installation of the needed components. This shortens the configuration process because additional functionality can be accessed without having to exit and rerun another setup procedure.
When a product uses the installer, a user can choose at setup time which features or applications to install and which to advertise. Then if while running an application the user requests an advertised feature that has not yet been installed, the application calls the installer to enact a just-in-time feature level installation of the necessary files. If the user activates an advertised product that has not yet been installed, the operating system calls the installer to enact a just-in-time product level installation.
Advertisement and installation-on-demand can also facilitate system management by enabling administrators to designate applications as required or optional for different groups of users. There are two types of advertising known as "assigning" and "publishing." If an administrator assigns an application to a group, then these users can install the application on-demand. If, however, the administrator publishes the application to the group, no entry points appear to these users and installation-on-demand is only activated if another application activates the published application.
The Windows Installer can advertise the availability of an application to users or other applications without actually installing the application. If an application is advertised, only the interfaces required for loading and launching the application are presented to the user or other applications. If a user or application activates an advertised interface the installer then proceeds to install the necessary components as described in Installation-On-Demand.
The two types of advertising are assigning and publishing. An application appears installed to a user when that application is assigned to the user. The Start menu contains the appropriate shortcuts, icons are displayed, files are associated with the application, and registry entries reflect the application's installation. When the user tries to open an assigned application it is installed upon demand.
The installer supports the advertisement of applications and features according to the operating system. The installer registers COM class information for assigned applications beginning with the Windows 2000 and Windows XP systems. This enables the installer to install the application upon the creation of an instance of an advertised class. For more information, see Platform Support of Advertisement.
You can publish an application from the server beginning with the Windows 2000 Server. The published application is then installed through its file association or Multipurpose Internet Mail Extension (MIME) type. Publishing does not populate the user interface with any of the application's icons. The client operating system can install a published application beginning with the Windows 2000 and Windows XP systems.

20. Append the log file
21. Steps failed if the app is not functioning
22. What are the diff types of Upgrade?
Patching and Upgrades
Because an installation package can contain the files that make up an application as well the information needed for their installation, Windows Installer can be used to update the application. The installer can update information in the following parts of the installation package:
• The .msi file.
• The files of the application.
• The Windows Installer registration information.
The type of update can be characterized by the changes the update makes to the application's product code, product version, and package code. The application's product version is stored in the ProductVersion property. The application's product code is stored in the ProductCode property. The application's package code is stored in the Revision Number Summary Property.
An update that changes the application into another product is required to change the ProductCode of the application. For more information about which updates require changing the ProductCode see Changing the Product Code. The update can change the ProductVersion and leave the ProductCode unchanged if future versions of the application will need to differentiate between the updated and nonupdated versions of the current product. The Package Code uniquely identifies the installation package and should always be changed whenever update or upgrade changes any information in the installation package.
When deciding whether to change the product version, you should consider If future versions of the application will need to differentiate between the updated and nonupdated versions of the current product. To ensure differentiation in the future, a minor upgrade should be used instead of a small update.
• If an update changes the .msi file and application files, but does not change the ProductCode property or ProductVersion property, it is termed a small update.
• If the update changes the ProductVersion, but does not change the ProductCode, it is termed a minor upgrade.
• If the update changes the installation into an entirely different product, the ProductCode must change and the update is termed a major upgrade.
Note To ensure differentiation of versions of the current product in the future, a minor upgrade should be used instead of a small update.
The following table summarizes the different types of updates.
Type of update Productcode ProductVersion Description
Small Update
No change No change An update to one or two files that is too small to warrant changing the ProductVersion. The package code in the Revision Number Summary Property does change. Can be shipped as a full installation package or as a patch package.

Minor Upgrade
No change Changed A small update making changes significant enough to warrant changing the ProductVersion property. Can be shipped as a full installation package or as a patch package.

Major Upgrades
Changed Changed A comprehensive update of the product warranting a change in the ProductCode property. Shipped as a patch package or as a full product installation package.

23. What is com and y do u do for registering, how u will register manually
In Windows, COM classes, interfaces and type libraries are listed by GUIDs in the registry, under HKEY_CLASSES_ROOT\CLSID for classes and HKEY_CLASSES_ROOT\Interface for interfaces. The COM libraries use the registry to locate either the correct local libraries for each COM object or the network location for a remote service.

What is a COM component?
A COM component is commonly referred to as a COM Object. We can visualize a COM component or Object as simply a "black box" that comprises a set of methods and associated data. Internally, these Objects contain reusable code (Methods), and provide ways for an application to call the object's Methods and read/write its associated data through its Interfaces. Notice that this is the same definition as an object internal to your program. The difference is that COM offers a way to perform this functionality on an object external to your program.
A COM Component is generally known as a COM SERVER, because it serves up information or actions requested by a COM CLIENT. A COM SERVER makes its Methods and Properties public, so that a COM CLIENT can call them as needed.
COM Components usually take the form of an EXE, or DLL/OCX file, but the actual file extension is largely irrelevant. However, DLL/OCX versions of a component are generally referred to as "in-process", since they are loaded into the address space of the calling application. EXE-versions are typically "out-of-process" because they will not share the address space of the calling application.
To summarize, a COM Object (COM Server) is a special form of code library (similar to a standard DLL) that conforms to the COM specification. It provides at least one public interface, and is identified by a globally unique PROGID and CLSID.
Every class is associated with a GUID (a 128-bit number or string) which uniquely identifies this particular class from all others, anywhere in the world. This identifier is called the Class ID, or CLSID. A friendlier version of the CLSID is a shorter text name, which also identifies the Class. This text name is known as the PROGID, though it's possible this PROGID may not be totally unique. As it's a simpler construct, it might be duplicated in another program. These identifiers are stored in the Windows Registry when the COM component is installed and registered. PowerBASIC programmers reference COM components by their PROGID string, and rarely by their CLSID. However, since these two items are stored in pairs, it is straightforward to retrieve the matching PROGID for a known CLSID, and vice versa.
As mentioned earlier, you don't need to know how a television works internally to use it and benefit from it. Likewise, you don't need to know how a COM Object works internally to use it and benefit from it. You only need to know the intended job of the object, and how to communicate with it from the outside. The internal workings are well "hidden", which is called encapsulation. Since we aren't able to "look inside" a COM Object, it's not possible to directly manipulate internal variables or memory. This provides a increased level of security for the internal code and data.
The PowerBASIC Console Compiler can only create internal objects, COM and ActiveX objects can be created with the PowerBASIC For Windows Compiler.

24. No shortcut, no active setup, how to get the keys for the first log-in
25. What does u mean by differed CA, how you will decide what CA to be kept in which mode say differed or execute immediate
The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed. This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in a call to MsiDoAction. A deferred execution custom action enables a package author to specify system operations at a particular point within the execution of the installation script.
The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead the installer writes the custom action into the installation script. The only mode parameter the installer sets in this case is MSIRUNMODE_SCHEDULED. See MsiGetMode for a description of the run mode parameters.
A deferred execution custom action must be scheduled in the execute sequence table within the section that performs script generation. Deferred execution custom actions must come after InstallInitialize and come before InstallFinalize in the action sequence.
Custom actions that set properties, feature states, component states, or target directories, or that schedule system operations by inserting rows into sequence tables, can in many cases use immediate execution safely. However, custom actions that change the system directly, or call another system service, must be deferred to the time when the installation script is executed. See Synchronous and Asynchronous Custom Actions for more information about potential clashes between their custom actions and the main installation thread.
Because the installation script can be executed outside of the installation session in which it was written, the session may no longer exist during execution of the installation script. This means that the original session handle and property data set during the installation sequence is not available to a deferred execution custom action. Deferred custom actions that call dynamic-link libraries (DLLs) pass a handle which can only be used to obtain a very limited amount of information, as described in Obtaining Context Information for Deferred Execution Custom Actions.
Note that deferred custom actions, including rollback custom actions and commit custom actions, are the only types of actions that can run outside the users security context.

26. Response file means, how to call response in command line
Creating the Response File
InstallShield 12
A normal (non-silent) installation receives the necessary input from end users in the form of responses to dialogs. However, a silent installation does not prompt the end user for input. A silent installation must get its end-user input from a different source. That source is the InstallShield Silent response file (.iss file).
A response file contains information similar to that which an end user would enter as responses to dialogs when running a normal installation. InstallShield Silent reads the necessary input from the response file at run time.
The format of response files resembles that of an .ini file, but response files have .iss extensions. A response file is a plain text file consisting of sections containing data entries.
There are two ways in which you can create an InstallShield Silent response file: you can run the installation and have InstallShield record and create the response file for you, or you can write the response file directly.
Recording a Response File
You have the option of letting InstallShield create the response file for you. Simply run your installation with the Setup.exe -r command-line parameter. InstallShield will record all your installation choices in Setup.iss and place the file in the Windows folder.
All InstallShield built-in and Sd dialog functions are designed to write values into the Setup.iss file when InstallShield runs in record mode (Setup -r). If you are creating custom dialogs, you will need to call SdMakeName and SilentWriteData to add sections and dialog data to the response file when the installation runs in record mode. Refer to the Sd dialogs' source code in the \Include folder for examples of using these functions to write to Setup.iss. Read the following section for more information about what data to add to Setup.iss when calling SdMakeName and SilentWriteData.
Manually Creating a Response File
You can also create the response file completely by hand. As mentioned, the Setup.iss file is similar to an .ini file. The sections of an InstallShield response file must be in the following order:
1. Silent Header Section
2. Application Header Section
3. Dialog Sequence Section
4. Dialog Data Sections (one per dialog)
Section names are contained in square brackets, as in [InstallShield Silent].
Data entries follow their section names and consist of pairs, as in the following example:

27. How will make single MST, when we give 5 MST in InstallShield
28. In IRP, whether u can apply std, what r the things can be done in IRP
29. Response iss file can be created for what type of setups


  1. Thank you for sharing this piece of information. Really awesome to know this kind of stuff.

  2. Hi

    I read this post 2 times. It is very useful.

    Pls try to keep posting.

    Let me show other source that may be good for community.

    Source: Advertising interview questions

    Best regards

  3. Gangadhar Annaluri2 February 2013 at 15:17

    Really spending my time to read this stuff is worthful.
    Thanks for giving clear Idea about the Packaging concepts.

    Gangadhar Annaluri