Abstract:
A method, system and process for installing an application under a first operating system and translating the installation parameters into a set of similar parameters to assure proper execution under a second operating system. The invention prompts a user for selection of preferences for an initial operating system and stores the initial selections representing a user&#39;s requirements under the initial operating system. Then, the hardware is examined to ascertain a list of all bootable devices and the operating systems associated therewith. The list of bootable devices is presented to the user for selection of which operating systems the application should be enabled under. Finally, the application is enabled in accordance with the information stored in the initial selections on each of the selected bootable devices and the operating systems associated with the bootable device.

Description:
FIELD OF THE INVENTION 
     This invention generally relates to improvements in installing applications under a plurality of operating systems. 
     BACKGROUND OF THE INVENTION 
     Application management has become the subject of significant recent interest, not only because of the popularity of low cost communication links for personal computers but also because of the ready made access via a LAN to many application programs. Today, computer systems often have a plurality of bootable operating systems. Until this invention, a user could not install an application under a first bootable operating system and automatically enable the other bootable operating systems that were on the computer or bootable devices associated with the computer to employ the application. Rather, individual installations were required for each of the other operating systems. 
     An example of an US Patent for executing programs in a multi-mode microprocessor is U.S. Pat. No. 4,825,358 to Microsoft. This patent discloses a method and system for executing programs in two modes on a specific hardware platform. However, a single operating system is always operable and only one bootable device is discussed. 
     Remote processor initialization is also well known in the prior art. Remote processor initialization refers to the capability of downloading an Initial Program Load (IPL) sequence to a computer via a communication link. This process allows a remote computer to boot another computer in a predetermined manner. However, a single operating system is always operable and only one bootable device is discussed. 
     SUMMARY OF THE INVENTION 
     Accordingly, it is a primary object of the present invention to provide a technique for installing an application under a first operating system and then automatically enabling the same application under multiple other operating systems. 
     These and other objects of the present invention are accomplished by the operation of a process in the memory of a processor. The processor, under the control of the process, installs an application under a first operating system and translates the installation parameters into a set of similar parameters to assure proper execution under a second operating system. The invention prompts a user for selection of preferences for an initial operating system and stores the initial selections representing a user&#39;s requirements under the initial operating system. Then, the hardware is examined to ascertain a list of all bootable devices and the operating systems associated therewith. The list of bootable devices is presented to the user for selection of which operating systems the application should be enabled under. Finally, the application is enabled in accordance with the information stored in the initial selections on each of the selected bootable devices and the operating systems associated with the bootable devices. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a host computer in accordance with the subject invention; 
     FIG. 2 is a flowchart in accordance with the subject invention; 
     FIG. 3 illustrates a display of an application installation in accordance with the subject invention; and 
     FIG. 4 is a display of an application update in accordance with the subject invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     PREFERRED EMBODIMENT 
     A representative hardware environment is depicted in FIG. 1, which illustrates a typical hardware configuration of a workstation in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units interconnected via a system bus 12. The workstation shown in FIG. 1 includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk units 20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a touch screen device (not shown) to the bus, a communication adapter 34 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus to a display device 38. 
     The preferred embodiment of the subject invention is an IBM Personal System/2 with the IBM OS/2 operating system installed. Detailed descriptions of the hardware and software environment are provided in PS/2 Hardware Interface Technical Reference, S10G-6457, IBM Corporation (1991), and OS/2 Presentation Manager Programming, SC28-2700, IBM Corporation (1992). While the invention will be described in terms of this hardware and software, one skilled in the art will recognize that other operating systems and hardware can be supported without undue experimentation. 
     A flowchart of the subject invention is presented in FIG. 2. Processing commences at terminal 200 and immediately flows to function block 210 for the installation and configuration of an application under a first operating system. Thereafter, a list of local OS/2 bootable devices is created in function block 220. A bootable device is any device having a file thereon that can be used to Initial Program Load (IPL) the computer system. Thus, any hard disk or diskette drive can be a bootable device. Also, a communication link attaching the computer system to a remote system can be a bootable device. Then, in function block 230, a window is displayed to allow a user to select drives and the corresponding bootable operating system thereon for enablement of the application. Finally, in function block 240, the installation file created in function block 210 is used to update the system files of the operating systems selected in function block 230 and processing is terminated in terminal 250. The details of the functions will be discussed below with reference to the figures. 
     INSTALLING AND CONFIGURING AN APPLICATION 
     FIG. 3 is an illustration of an application installation display in accordance with the subject invention. The Install pushbutton 300 is the default pushbutton if no application has currently been installed on the system. This button is selected when a user desires to install an application. The Configure pushbutton 302 is the default if an application is already installed on a first operating system. Selection of this button initiates the configure operation. The Remove pushbutton 304 is selected when a user desires to remove an application from the system. The Exit pushbutton 306 is selected to exit the program. If a configuration has already been commenced, then the user will be prompted with the next configuration step to avoid discontinuity. Finally, the Help pushbutton 308 produces a help dialog that provides specific information for each of the other buttons. 
     To install an application, the following steps are executed. 
     1) Insert the application diskette into drive &#34;A:&#34;. From &#34;A:&#34; type &#34;LAPS&#34; to begin the installation/configuration program. 
     2) Select the INSTALL pushbutton 300 on the main window and enter the letter of the drive on which you want the application installed on &#34;Target Drive&#34; window. 
     3) After installation is complete and you are returned to the main LAPS window, select the CONFIGURE pushbutton 302, then select the &#34;Configure LAPS&#34; pushbutton and create the desired configuration on the &#34;Configure Workstation&#34; window. 
     4) You will be returned to the LAPS main window where you should press the EXIT pushbutton 306 to exit LAPS. At this point the machine is searched for local bootable drives and the user is presented the &#34;Update CONFIG.SYS&#34; window. 
     DISPLAY 
     This file contains the source for the window which allows the user to select the bootable devices on which the CONFIG.SYS files will be updated with the PROTOCOL.INI information. FIG. 4 illustrates the display the user interacts with to select the bootable devices to enable. 
     The following C-source code is a dialog which processes a multi-select list box of bootable devices. 
     
         ______________________________________/********************************************************//*** FUNCTION NAME: LAPSCFGSYSMsgProc**** FUNCTION:       This routine sets up and displays the**          IDLG.sub.-- LAPSCFGSYS dialog**** CALLED FROM: Module: XIATND.C** EXIT NORMAL: 0.** Function is exception handled (see EXCEPT.C).*//********************************************************/MRESULT EXPENTRY LAPSCFGSYSMsgProc(hWndD1g,message, mp1, mp2)HWND hWndD1g;USHORT message;MPARAM mp1;MPARAM mp2;MRESULT fpRC = (MRESULT) FALSE;SHORT mymp1;USHORT i;CHAR insertstring[2];SHORT SelectedItem;BOOL anyselected;CHAR Temp[] = &#34;a:&#34;;WITH.sub.-- HANDLINGswitch(message){case WM.sub.-- INITDLG:for (i=0;i&lt;BootableDriveCount;i++) {insertstring[0] = Bootable.sub.-- Drive.sub.-- List[i];insertstring[1] = NULLCHAR;WinSendD1gItemMsg(hWndD1g,CFGSYS.sub.-- LB.sub.-- DRIVES, LM.sub.-- INSERTITEM,MPFROM2SHORT (LIT.sub.-- SORTASCENDING, 0),MPFROMP(insertstring));} /* endfor */anyselected = FALSE;for (i=0;i&lt;BootableDriveCount;i++) {Temp[0] = Bootable.sub.-- Drive.sub.-- List[i];if (Check.sub.-- Configsys.sub.-- For.sub.-- Ibmcomdrive(Temp)) {WinSendD1gItemMsg(hWndD1g,CFGSYS.sub.-- LB.sub.-- DRIVES, LM.sub.-- SELECTITEM,MPFROMSHORT(i), MPFROMSHORT(TRUE));anyselected = TRUE;}} /* endfor */if (!anyselected) {WinSendD1gItemMsg(hWndD1g,CFGSYS.sub.-- LB.sub.-- DRIVES, LM.sub.-- SELECTITEM,MPFROMSHORT(0), MPFROMSHORT(TRUE));} /* endif */WinSendD1gItemMsg( hWndD1g,CFGSYS.sub.-- LB.sub.-- DRIVES, LM.sub.-- SELECTITEM,MPFROMSHORT(0), MPFROMSHORT(TRUE));WinSetFocus(HWND.sub.-- DESKTOP,WinWindowFromID(hWndD1g,CFGSYS.sub.-- LB.sub.-- DRIVES));fpRC = (MRESULT)TRUE;CenterD1gBox(hWndD1g, hWndClient);break; // End of WM.sub.-- INITDLGcase WM.sub.-- CONTROL:break; // End of WM.sub.-- CONTROLcase WM.sub.-- COMMAND:switch(SHORT1FROMMP(mp1)){case CFGSYS.sub.-- PB.sub.-- CONTINUE:  //Continuei = 0;SelectedItem = LIT.sub.-- FIRST;// loop through selected list and retrieve valuesselecteddo {SelectedItem = (SHORT) WinSendD1gItemMsg(hWndD1g, CFGSYS.sub.-- LB.sub.-- DRIVES,LM.sub.-- QUERYSELECTION,MPFROMSHORT( SelectedItem), 0L);if (Selectedltem != LIT.sub.-- NONE) {WinSendD1gItemMsg(hWndD1g,CFGSYS.sub.-- LB.sub.-- DRIVES,LM.sub.-- QUERYITEMTEXT, MPFROM2SHORT(SelectedItem, sizeof     insertstring),    MPFROMP(insertstring));SelectedDxives[i] = insertstring[0];i++;} else { //at end of listSelectedDrives[i] NULLCHAR;} /* endif */} while (SelectedItem != LIT.sub.-- NONE);if (i==0) {DisplayMessageBox( hWndD1g,DLGS.sub.-- CFGSYS.sub.-- MUSTSELECT.sub.-- TITLE,DLGS.sub.-- CFGSYS.sub.-- MUSTSELECT.sub.-- MSG,ACTION.sub.-- MSG, OK.sub.-- BUTTON,(USHORT)CFGSELE.sub.-- EXTHELP25720,(PSZ)NULL); //} else {WinDismissDlg(hWndD1g, FALSE);} /* endif */ break;case CFGSYS.sub.-- PB.sub.-- EXIT:  // ExitWinDismissD1g(hWndD1g, FALSE);SelectedDrives[0] = NULLCHAR;break;}break; // End of WM.sub.-- COMMANDcase WM.sub.-- CLOSE:WinDismissD1g(hWndD1g, FALSE);break; // End of WM.sub.-- CLOSEdefault:fpRC = WinDefDlgProc(hWndD1g, message, mp1,      mp2);break;}ON.sub.-- EXCEPTIONReportError(theException, PM | LOG, hWndD1g, 0);WinDismissD1g(hWndD1g, FALSE);mymp1 = (SHORT)theException;WinPostMsg(hWnd, LAPSWM.sub.-- EXCEPT,MPFROMSHORT(mymp1), 0L);END.sub.-- HANDLING;/*** Retum value*/  return fpRC;} /* End of LAPSCFGSYSMsgProc */______________________________________ 
    
     UPDATE 
     An intermediate file, PROTOCOL.INI, is created during the install process. This file is used as input for updating the other operating system environments for execution of the application. 
     The following is an example of a PROTOCOL.INI file created by a user using LAPS to do configuration: 
     
         ______________________________________[PROT.sub.-- MAN]   DRIVERNAME = PROTMAN$[IBMLXCFG]   IBMTOK.sub.-- nif = IBMTOK.nif   LANDD.sub.-- nif = LANDD.nif[LANDD.sub.-- nif]   DriverName = LANDD$   Bindings = IBMTOK.sub.-- nif   ETHERAND.sub.-- TYPE = &#34;I&#34;   SYSTEM.sub.-- KEY = 0×0   OPEN.sub.-- OPTIONS = 0×2000   TRACE = 0×0   LINKS = 8   MAX.sub.-- SAPS = 3   MAX.sub.-- G.sub.-- SAPS = 0   USERS = 3   TI.sub.-- TICK.sub.-- G1 = 255   T1.sub.-- TICK.sub.-- G1 = 15   T2.sub.-- TICK.sub.-- G1 = 3   TI.sub.-- TICK.sub.-- G2 = 255   T1.sub.-- TICK.sub.-- G2 = 25   T2.sub.-- TICK.sub.-- G2 = 10   IPACKETS = 250   UIPACKETS = 100   MAXTRANSMITS = 6   MINTRANSMITS = 2   TCBS = 64   GDTS = 30   ELEMENTS = 800[IBMTOK.sub.-- nif]   DriverName = IBMTOK$   ADAPTER = &#34;PRIMARY&#34;   MAXTRANSMITS = 6   RECVBUFS = 2   RECVBUFSIZE = 256   XMITBUFS = 1______________________________________ 
    
     To see how the CONFIG.SYS file is updated based on the PROTOCOL.INI file, look at the following sections from the PROTOCOL.INI file. LAPS locates the *.NIF file containing information pertinent to the driver that is being configured. 
     
         ______________________________________[IBMLXCFG]IBMTOK.sub.-- nif = IBMTOK.nif..[IBMTOK.sub.-- nif]DriverName = IBMTOK$...______________________________________ 
    
     Note that the file name is retrieved from a common section (IBMLXCFG) for the particular driver of interest. Then, the *.NIF file is read to extract the information necessary to build the appropriate `DEVICE=` statements in the CONFIG.SYS file: 
     
         ______________________________________[IBMTOK]Type = NDISTitle = &#34;IBM Token-Ring Network Adapters&#34;Version = 1.0DriverName = IBMTOK$Xports = NETBEUI LANDDCopyfile = LT2.MSG, LT2H.MSG[FILE]Name = IBMTOK.OS2Path = IBMCOM MACS______________________________________ 
    
     In this example, the following statement would be built in the CONFIG.SYS file: ##EQU1## This same scenario is repeated for each drive selected on the window display illustrated in FIG. 4. 
     ENABLING OTHER BOOTABLE SYSTEMS 
     In order to discern which bootable devices are available on a given computer system, the following logic is performed. First, to locate bootable devices, a loop is executed for possible drives A to Z to determine if the particular device is a fixed disk drive. If the drive is a fixed drive, then if it is a local drive, it is added to a temporary list of local drives and a test is performed to determine if the physical drive has been configured by examination of the SYSLEVEL.OS2 file and CONFIG.SYS file of OS/2. If the physical drive has been configured, then it is added to the list of drives. 
     To determine if the drive is bootable, the device must first be opened employing a DOSOPEN call. If the device is a local device, then the device parameters must be retrieved from the Control file, DOSDEVIOCTL. If the device is a tape drive, then it is noted. Otherwise, a test is performed to determine if the device is fixed or removable by further examination of DOSDEVIOCTL. If the device is a fixed drive device then the fact is noted. However, if the device is removable, then the floppy drive device is returned. Otherwise, an unknown media type is returned. If the device is a non-local device, that fact is also noted, and finally, the device is closed. A final check is performed to verify that the proper system files reside on the bootable device. The source code corresponding to this processing appears below. 
     
         ______________________________________SOURCE CODE FOR CREATING LIST______________________________________/********************************************************//*** FUNCTION NAME: Find.sub.-- Local.sub.-- Bootable.sub.-- Drives**** FUNCTION: which drives are local**   and bootable.** CALLED FROM: Module: XIATND.C**** INPUT:**** OUTPUT:**** EXIT NORMAL: 0. Exception handled.*//********************************************************/VOID Find.sub.-- Local.sub.-- Bootable.sub.-- Drives(PSZ BootDrives)USHORT count;USHORT i;CHAR dname;    /* ASCII drive name */CHAR temp1ist[26];CHAR syslevelfile[MAXPATHLEN]= &#34;a:&#34;;CHAR configfile[MAXPATHLEN]=&#34;a:&#34;;DosError(DISABLE.sub.-- ERRORPOPUPS);/* Disable error */count = 0;for (i=0;i&lt;26;i++) {   Do drives A thru Z */dname = (CHAR)`A` + (CHAR)i; /* Setup drive */if (check.sub.-- media.sub.-- type(&amp;dname) == FIXED.sub.-- DRIVE) { //if      it&#39;s localtemplist[count] = dname; //add it to our arraycount++;}} //end for//Now determine which of these are bootableBootableDriveCount = 0;strcat(syslevelfile,SYSLEVEL);strcat(configfile,CONFIG.sub.-- SYS);for (i=0;i&lt;count;++ ) {syslevelfile[0] = templist[i];if (Exist(syslevelfile)) {configfile[0] = templist[i];if (Exist(configfile)) {BootDrives[BootableDriveCount] = temp1ist[i];BootableDriveCount++;} /* endif */} /* endif *} /* endfor */DosError(ENABLE.sub.-- ERRORPOPUPS); /* Disable error      popups */}______________________________________SOURCE CODE THAT DETERMINES THEMEDIA TYPE FOR EACH DEVICE SCANNED INFIND.sub.-- LOCAL.sub.-- BOOTABLE.sub.-- DRIVES______________________________________/********************************************************//*** FUNCTION NAME: check.sub.-- media.sub.-- type**** FUNCTION:**  This routine will check the type of the media - and**   determine if it**  is a tape drive, floppy, remote drive, or fixed or**   CD-ROM.****  The routine expects as input the drive letter for**   the media.**** CALLED FROM: Module: check.sub.-- disk.sub.-- space**** INPUT**** OUTPUT:**** EXIT NORMAL: . . . Function is exception handled.*//********************************************************/USHORT check.sub.-- media.sub.-- type(driveletter)CHAR * driveletter;USHORT rc;CHAR DriveString[3];Type.sub.-- Drive DevInfo;USHORT DevHandle;USHORT action;ULONG size = 0;BYTE ParmList = 0×00;BYTE Fixed;//Determine if drive is floppy or non-localDriveString[0] = *driveletter;DriveString[1] = COLONCHAR;DriveString[2] = NULLCHAR;//Open the deviceif (!(DosOpen(DriveString, &amp;DevHandle, &amp;action, size,NORM, READ.sub.-- ONLY, OPENMODE, 0L))){// Get device parametersif (!(DosDevIOCtl(&amp;DevInfo, &amp;ParmList, 0×0063,0×008, DevHandle))) {if (DevInfo.DevType == 6) { //it&#39;s a tape driverc = TAPE.sub.-- DRIVE;} else {//Determine if media is removableif (!(DosDevIOCtl(&amp;Fixed, &amp;ParmList, 0×0020,      0×0008,DevHandle))) {if (Fixed) {  rc = FIXED.sub.-- DRIVE; //it&#39;s not              removable} else {  rc = FLOPPY.sub.-- DRIVE; //it&#39;s a              removable floppy} /* endif */} else {rc = UNKNOWN.sub.-- MEDIA;} /* endif */} endif */} else {rc = UNKNOWN.sub.-- MEDIA;} /* endif */DosClose(DevHandle);} else {rc = REMOTE.sub.-- DRIVE;} /* endif */return(rc);}/********************************************************//*** FUNCTION NAME: Exist**** FUNCTION: checks to see if IBMLVL.INI exists**** CALLED FROM: Function: Check.sub.-- IBMLVL (this module)**** INPUT:**** OUTPUT: returns TRUE if file exists or FALSE if it** doesn&#39;t**** EXIT NORMAL: 0.*//********************************************************/BOOL Exist (PSZ pszFileName){HDIR         = HDIR .sub.-- CREATE;USHORT       usSearchCount = 1;FILEFINDBUF  findbuf;if (DosFindFirst(pszFileName,&amp;hdir,FILE.sub.-- DIRECTORY,&amp;findbuf,sizeof(findbuf),&amp;usSearchCount,0L))return FALSE ;elsereturn TRUE ;} /* Exist ( ) */______________________________________ 
    
     While the invention has been described in terms of a preferred embodiment in a specific system environment, those skilled in the art recognize that the invention can be practiced, with modification, in other and different hardware and software environments within the spirit and scope of the appended claims.