WO2000017729A2 - Improved method and apparatus for display of windowing application programs on a terminal - Google Patents

Abstract

A video display terminal (12) capable of operating with a graphical user interface. The terminal is not fully compatible with personal computer (20) BIOS or disk operating systems and incapable of executing windowing application locally, adapted to receiving windowing information supplied by programs executing on a remotely located application server (26). The invention provides FOP (24) and SNAP capabilities along with a number of user interface enhancements, DHCP and SNMP enhancements. File information is transferred to and from the terminal using a communications protocol (16). One or more image upgrades are transferred to the terminal from the remotely located application server (26).

Description

IMPROVED METHOD AND APPARATUS FOR DISPLAY OF WINDOWING APPLICATION PROGRAMS ON A TERMINAL

Related Application The present invention is a Continuation-in-Part Application of U.S. Patent No.

5,918,039 issued June 29, 1999 and U.S. Patent Application Serial No. 09/342,311 filed June 29,1999, and also claims the benefit of provisional application 60/101,319 filed September 21, 1998 which is incorporated herein and made a part hereof.

Field of the Invention

The present invention relates generally to methods and apparatus for displaying information on a terminal, and more particularly relates to methods and apparatus for formatting and displaying, on a terminal, graphical user interfaces such as the Microsoft Windows® operating environment and applications programs within such environments.

Background Of The Invention

Graphical user interfaces such as the Microsoft Windows' operating environment comprise the most popular operating environment for the world's best selling applications software. Such environments are typically preferred because of ease of use, uniformity of user interface, high quality display, as well as other reasons. However, such user environments were designed for use with workstations and microcomputers such as personal computers. Such workstations and microcomputers, while flexible, present difficulties with security, reliability, ease of administration, and value. While data terminals are known to offer the advantages of improved security and ease of administration relative to microcomputers, usually at lower cost, terminals have generally been unable to provide compatibility with the most popular graphical user interfaces. Terminals operating in the X environment can provide some graphical interface capabilities operating under UNIX, but typically are expensive, require extensive memory, and offer little compatibility with the most popular Windows environments. Another option known in the prior art is diskless PCs. However, diskless PCs offer several deficiencies. In most instances, diskless PCs operating in a client server environment display application program information by downloading the application from the server and executing the application locally. This requires the diskless PC to have whatever processing power is required for each application it attempts to execute. In today's environment, this can require eight or more megabytes of memory, per application, a powerful processor, and so on making a diskless PC expensive. In addition, diskless PCs offer limited security and can require extensive administration. The Windows NT operating system provides a robust network client/server environment, while at the same time offering compatibility at the applications program level with the popular Windows environment. However, the NT operating system was written for PC clients, and not terminals. As a result, NT clients are generally required to be robust and, as a result, expensive. In addition, Windows NT was written for the client/server environment, and not the multi-user environment. The Multi-User NT operating system offered by Citrix Systems, Inc., modifies the Windows NT operating system by extending it to operate in a multiuser environment, although the prior art application for Multi-User NT has been PCs clients as opposed to terminals.

There has therefore been a need for a terminal that is relatively inexpensive, reliable, easy to administer, secure and capable of displaying application program information within a multiuser Windows operating environment.

Summary of the Invention

The present invention provides an elegant solution to the shortcomings of the prior art, in that it provides an inexpensive terminal capable of displaying applications software compatible with a windowing environment.

In particular, the present invention provides a display terminal capable of communicating with an applications server running a multiuser operating system. This provides secure access to Windows applications at the desktop. In an exemplary configuration, an application server is provided in the form of any suitable computer running the Multi-User NT operating system provided by Citrix Systems, Inc. The Multi-User NT operating system incorporates the Windows NT operating system plus extensions implementing a display protocol known as ICA3 as well as multi-user capabilities.

The terminal includes, in an exemplary embodiment, a hardware architecture based on the Intel X86 processor line. In addition, the terminal offers only limited main memory, and is generally incapable of local execution of modern application programs such as word processing, graphics, database, or other popular programs, or even the Windows or DOS operating system itself. In this way the terminal of the present invention is distinctly different from prior art X terminals or diskless PCs, or other PCs configured in a client/server environment.

Importantly, the hardware architecture does not implement the conventional IBM PC/AT bus, and the firmware within the terminal implements neither standard PC/AT BIOS nor a standard PC-compatible disk operating system. The terminal firmware implements network access extensions compatible with the application server, again, for example, the ICA- 3 extensions available from Citrix Systems. A high-resolution graphical display is provided both for ease of use and may be monochrome (including grayscale) or color, as well as input/output devices typical of the Windows environment such as mouse, keyboard, touch screen and other I/O services.

In addition, the terminal includes a network interface capable of communicating with the application server across conventional RS232 lines, Ethernet connections, wireless, ISDN, fiber optic, AC power-line modems, cable or other connections. When connected to the application server, the terminal displays the Windows NT or Windows 95 operating environment, including any application programs executing on the server and accessed by the user of the terminal. In the exemplary arrangement, the terminal appears to the user essentially the same as a much more expensive, less secure, harder to manage personal computer. As a result, during operation the terminal of the present invention offers numerous features normally associated with a multiuser system, while at the same time offering many of the desirable features typical of a client/server environment.

The terminal includes transferring file information to and from the terminal and for automatically downloading images via file transferring protocol to the terminal over a network link from any network server between the processing means and the display means after the terminal has obtained information by the Dynamic Host Configuration Protocol. The terminal also includes using communications protocols for an interactive or automated download of a new image via a network. Enhancements to the Simple Network Management Protocol and user interface are provided along with means for downloading binaries to a terminal.

The present invention provides a terminal or a utility for executing on a terminal, server or both. The terminal displays application program information in a windowing environment including processing means, not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally, adapted to receive windowing information supplied by programs executing on a remotely located application server and a display for the windowing information supplied by programs executing on the remotely located application server. File information is transferred to and from the terminal using a communications protocol. One or more image upgrades can be transferred to the terminal from the remotely located application server. Configuration data for the terminal can also be transferred to the terminal from the remotely located application server.

The terminal can further include automated downloading for one or more images to the terminal through a network link between the processor and the display after the terminal has been assigned an Internet Protocol address such as by a Dynamic Host Configuration Protocol. The terminal can include: providing configuration settings for the terminal using simple network management protocol; providing an interactive or automated downloading of an image through a network using simple network management protocol; creating or modifying binaries in the remotely located server with customized configurations from a tool kit; downloading the binaries to the display means via parallel, serial, flash card paths or an automated or interactive transfer using a communications protocol; merging automated configuration file and workspace images; administrating the configuration settings of the terminal from the remotely located server using a communications protocol; providing configuration settings for the terminal using a Management Information Base located on the remotely located server.

The present invention also provides a method for displaying application program information in a windowing environment. The steps of the method include: sending windowing information supplied by programs executing on a remotely located application server to a terminal not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally; displaying the windowing information supplied by programs executing on the remotely located application server; and transferring file information to and from the terminal using a communications protocol. The present invention further provides a terminal or a utility for executing on a terminal, server or both. The terminal displays application program information in a windowing environment including processing means, not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally, adapted to receive windowing information supplied by programs executing on a remotely located application server, and display means for displaying the windowing information supplied by programs executing on the remotely located application server. More than one connection between the terminal and server is simultaneously maintained. The multiple connections include establishing more than one virtual machine on the terminal. Each virtual machine runs an open session. The writing of a screen stops and redisplays when a session is moved to the background without saving the screen in memory. Each virtual machine has a text buffer so when the virtual machine is in the background it has a virtual buffer that it can write to and it continue to run in the background. Each virtual machine sends a signal to a graphics application should a graphic need to be displayed. The application sends a signal out to the server to command it to stop sending display when the application is switched to the background so that traffic relating to the graphics application between the terminal and server is stopped. The server is commanded to redisplay the screen when the application is switched back to the foreground. Each virtual machine stops sending and receiving data to and from the server when an application resides in the background session. Each virtual machine commands the server to refresh the data for the application when the application is switched to the foreground.

The present invention provides a method for displaying application program information in a windowing environment that includes the steps of: sending windowing information supplied by programs executing on a remotely located application server to a terminal not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally; displaying the windowing information supplied by programs executing on the remotely located application server; and simultaneously maintaining more than one connection between the terminal and server.

Description of the Drawings

The drawings that form a part of the disclosure herein:

FIG. 1 shows a generalized arrangement of an application server and a terminal in accordance with the present invention. FIG. 2 shows in functional block diagram form the architecture of the 30 logic of the present invention.

FIG. 3 shows in block diagram form the architecture of the control ASIC of Figure 2.

FIG. 4 shows an overview of the software architecture of a terminal in accordance with the present invention. FIG. 5 shows in simplified block diagram form the setup interface between the GUI

Engine and the remainder of the system.

FIG. 6 shows in flow chart form a top level view of the process by which the terminal of the present invention connects to an application server. FIG. 7A shows a setup screen from the configuration software of the' 10 present invention.

FIG. 7B1-7B3 show the data structures associated with the configuration software of the present invention.

FIG. 8 is a table showing a memory address configuration.

FIG. 9 is a table showing an I/O address map configuration.

FIG. 10 is a table showing interrupt assignment configuration.

FIG. 11 is a table showing a DMA channel assignment configuration.

FIG. 12 is a table showing a chip select configuration.

Detailed Description of the Invention

I. HARDWARE DESCRIPTION

Referring now to FIG. 1, a simplified system is shown in accordance with the present invention. In particular, a single application server 10 communicates bidirecfionally with one or a plurality of terminals 12 over a suitable network or other communications link 14. The network link may be an R5232 line, an AC power line modem, or an Ethernet connection such as twisted pair or coaxial cable, or other suitable link such as fiber optics. In an exemplary arrangement, which has been determined to operate satisfactorily, the application server is running an operating system such as Windows NT with appropriate extensions, such as those offered by Citrix as the Winframe OS. The Citrix remote Windows protocol or extensions include the ICA 3.0 protocol as well as enhancements that provide true multiuser capability within the Windows NT environment. For such a configuration, the application server may be, for example, a personal computer based on an Intel Pentium or '486 processor or other similar processors such as a DEC Alpha or a MIPS processor, or multiple processors, together with a suitable amount of RAM. In an exemplary configuration, the server may have sixteen megabytes of RAM for Winframe OS, plus 1-8 megabytes of RAM per concurrent user, depending on the particular application being run by the user.

In appropriate configurations, the application server 10 may also communicate with other servers, including a NetWare file server 16, a Unix host 18, other personal computers 20, or an Internet gateway 22. Also, through other connections such as a router or other communications server 24, the application server 10 may also communicate with remote terminals 26, or by other means to remote dial-up users 28. FIG. 2 illustrates an Elan SC400 system controller 100 for the Winterm BASE-2A Windows system terminal. The Winterm BASE-2A (Windows) system is the Windows terminal for the Winterm product line. The Windows system uses an off-the-shelf embedded controller that integrates most of the logic found in the original Winterm BASE-1 design into a single chip to achieve the lower cost and higher performance. This system is an improvement to the BASE-1 Winterm design in hardware and in software. The controller 100 includes a 486DX-66 embedded controller with a DRAM controller, an Interrupt Controller, a DMA controller, a Timer/Tone generator, a PCMCIA expansion interface, a built-in Serial Port interface (used as COM2), a built-in Enhanced Parallel Port interface, a Built-in XT Keyboard interface, a Local peripheral interface bus with chip selects, a VL Bus Interface, a Flash memory interface, and an ISA/Local peripheral bus with chip selects.

FIG. 3 shows in block diagram form the controller of FIG.2 and the main system components for a terminal in accordance with the present invention. A Super VGA 110 with built-in RAMDAC supports up to 86 MHz dot clock (on VLB). Four banks of DRAM 120 (32 bit wide, up to 32 MB in total) are provided. Three banks of FLASH memory 132, 135 (8 or 16 bit wide) are provided. One UART 140 (used as COM1) provides an EIA-232D interface, an Ethernet Controller (on ISA) 150 is provided, and a Keyboard and Mouse Controller 160 is provided. An audio Codec 165 is provided. The system includes a VL Bus 170 and an ISA/Local peripheral bus 180. The system incorporates the AMD SC400 Embedded Processor 100 that integrates most of the core logic and a 486 SLE CPU on chip. The system supports a VL Bus 170, an ISA Bus 180, and PCMCIA interface 190.

Four banks of DRAM 120 (32 bit wide, up to 36 MB in total) are arranged in four DRAM banks as two on-board banks while the other two are in a double sided 72 pin DIMM. The bank 0 and 2 are assigned to be on board and are 4 Mbytes each. The bank 1 and 3 are arranged as a double sized DIMM that supports 1, 2, 4, 8, 16 and 32 Mbytes standard 32/36 wide DIMMs. A combination of software detection and hardware settings can concatenate all active DRAM banks to form one contiguous DRAM memory map.

The system has four flash devices 130, 132 designed to be on board but is only able to support up to three FLASH memory banks at the same time. The first device is a BOOT/FILE FLASH. The second device is a FILE SYSTEM FLASH and the third is a NAND FLASH. The fourth device is an 8-bit ROM/FLASH on a socket. The devices are routed through a set of jumpers and a couple of zero ohm resisters. The first and second banks of the FLASH are controlled by SC400 directly. The third bank is controlled by ROM2CE from SC400 through a 16V8 PLD, but can be routed to the FILE SYSTEM FLASH directly. The BOOT/FILE FLASH supports either of 4 Mbit and 8 Mbit BOOT FLASH devices in 256Kxl6 or 512Kxl6 forms, or a 16 Mbit FILE SYSTEM FLASH in lMxlό form. The second FLASH device supports 16 Mbit (with one chip select) and 32 Mbit (with two chip selects) FILE SYSTEM FLASH devices. The third FLASH supports the Toshiba NAND FLASH interface.

A BOOT ROM/FLASH socket is provided for system boot, housekeeping and testing. The BOOT ROM can be located at either the first or the second FLASH bank by a set of jumpers. The BOOT ROM uses an 8 bit interface and is installed in a 32 pin PLCC socket. The ready/busy status can be read from SC400 GPIO16 for FLASH ROM device 1 and 2. This status indicates the FLASH memory chip is in an erase or programming operation. The system is bootable from BOOT ROM, BOOT/FILE FLASH and FILE SYSTEM FLASH, but not NAND FLASH. A set of jumpers (JP1) is used to route the chip selects to FLASH ROMs. Another jumper (JP2) controls the bus width for the boot device. The system uses an external keyboard controller 160, which is a VT82C42 with

74LS05 buffer for keyboard and mouse.

The Winterm system requires two RS232 serial interface ports, including an external UART chip 140. A serial port clock is provided by an external crystal (1.8432 MHz).

The SC400 provides an EPP compatible parallel port with external buffering. A set of data buffers is needed to provide bi-directional and output latch. The control signals are directly connected to the port.

The system supports one PCMCIA slot 190. This PCMCIA interface is shared with the ISA interface without extra buffering.

The system uses the CS8900 network chip 150, which directly interfaces with the ISA bus.

The system design supports the CS4231 Audio CODEC chip that buffers the stereo input and output to/from the chip.

For a video graphics interface, the system uses a Cirrus Logic CL-GD5440 VGA chip on the 32 bit VL bus 170. The frame buffer of the VGA chip supports 512 Kbytes (256Kxl6xl) and 1 Mbytes (256Kxl6x2). The VGA graphics interface resolution is 1024x768x8 at 75 Hz.

The system provides four different buses: DRAM bus, VL bus, ISA bus, and local bus. The DRAM bus connects to the DRAM devices, including on board DRAM and, if present, the DIMM. The data bus (D[0:31] comes from the SC400 and is shared with other devices. The address bus (MA[0:12]) is dedicated to DRAM access only.

For the VL-Bus, the data bus (BD[0:311]) is a buffered version of the SC400 bus. The high side of the bus (BD[16.31]) provides service to the ISA and local bus. The address bus for VLB comes from the SC400. The control signals for VLB are connected to the SC400 directly. The only other device on VLB is the GD-5440 SVGA chip.

The data bus for ISA is shared with other peripheral buses (BD[ 16:31]). The SC400 routes the word or byte on the ISA bus to the correct rail internally or by swapping. The address bus (SA [0:25]) also connects to the SC400 address bus directly. The control signals

The SC400 provides a high-speed local bus with internal chip selects. There are six chip selects from the SC400, two for I/O devices, two for memory devices, one for FLASH ROM, and one for the external keyboard controller. The bus is as fast as 33.3 MHz or as slow as the ISA bus. The data bus (BD[16:31]) is the same buffered bus as VLB and the address bus (SA[0:25]) is connected to the SC400.

A simple RC circuit generates the system-reset signal with a DS1233A reset generator chip as a backup. The VL bus has its own reset that is provided by the SC400 under program control. The keyboard controller reset input also is connected to VLB reset due to timing requirements. The IDS bus provides another reset signal (RSTDRV) to all the peripherals that require positive reset signal.

The graphic controller chip 110 is fully programmable to various video timing standards, as required. The buses are typically not compatible with the IBM PC/AT standard, nor any other personal computer standard. In a special feature of the hardware of the present invention, the terminal operating system stored in the flash memory 112 may be updated through a variety of methods, including communication through a suitable interface. In an exemplary embodiment, the flash memory may be updated through communication with a host system when the terminal is placed in a predetermined state. In such an arrangement, downloading to the terminal's memory system is suitable such as by using three boot block download methods that occur at power up of the terminal and occur over the serial or parallel port into a PC card. At terminal power up a download is checked automatically. After power up a download is checked by the SNMP or DHCP, which are "enabled" any time the network is up. Configuration information is generally included with the firmware image, so there is usually only one download. It is possible to download just the configuration information. Downloaded information is always received into DRAM first and then written to flash memory. Serial, parallel, or flash card download will occur automatically at boot time if there is an appropriate agent available to receive the download from. DHCP-initiated downloads occur when the network driver loads, if DHCP updates are enabled in the user configuration, and if a new firmware image is available. SNMP-initiated downloads can occur any time after the network driver loads if SNMP download are enabled in the user configuration. SNMP updates are initiated by external SNMP requests to the terminal.

II. TERMINAL OPERATING SYSTEM

Referring next to FIG. 4, the key elements of one embodiment of the terminal operating system of the current invention may be better understood. The hardware of the present invention is compatible with a standard AT-bus design and is preferably configured for a National 5440 graphics processor.

However, the present invention can also be configured for non-standard AT-bus designs. In such an example, the present invention relies on firmware to provide the requisite BIOS services to the upper software layers. The firmware is designed to run in virtual 8086 mode, with AT-compatible hardware components such as the interrupt controllers and timers being emulated in software as closely as possible. In addition, while a standard keyboard controller is used in an exemplary embodiment, in the event a non-standard controller is used the interface to such a device would also be emulated.

In the preferred embodiment, the AT-bus compatible hardware does not require emulation of all of the components. However, the creation of multiple virtual machines by the present invention requires emulation of a number of these components. The kernel listed in Appendix A runs in the CPU's virtual mode for an 8086 processor. Signals such as I/O from and to the ports of such hardware components are intercepted to facilitate the emulation. Also, under the control of an emulated A20 gate, the memory management features of the processor could be enabled to simulate the wraparound, which occurs in normal hardware at one megabyte. The emulation also provides for mapping memory pages or accessing a particular piece of hardware so that multiple applications do not attempt to access one piece of hardware without serialization or control. For example, the interrupt codes listed in Appendix A must be mapped to match a piece of hardware such as a mouse to the appropriate session containing the mouse because there is only one copy of the mouse driver loaded. The session containing the mouse may or may not be the foreground session.

Continuing with reference to FIG. 4, the terminal operating system begins execution with a boot block 300, followed by loading of a kernel 305. The kernel 305 provides many of the intercepting and remapping functions of the present invention, as more particularly explained hereinafter. Upon completion of the kernel 305, the IO.SYS code 310 is loaded. Next the COMMAND.COM code 315 is loaded followed by executing commands provided by an AUTOEXEC.BAT file. The AUTOEXEC.BAT file may include, for example, keyboard and mouse drivers although both such drivers may not be used in every instance, as well as a VGA XMS driver. It may also include other optional code, including starting a self-test sequence, which executes if appropriate conditions exist. In an exemplary embodiment, a loopback plug installed in a communications port causes the self-test sequence to execute.

The GUI.COM code 325 is then loaded. At this point, depending on the implementation, either the system will enter setup mode, or user commands may cause either an entry of the setup mode or the loading of network connection code. In a presently implemented embodiment, the system enters the setup mode to obtain current configuration data, and then continues with loading of the network connection code.

If the implementation permits the user to select, and if the user selects the setup mode, the GUI.COM 325 branches to run the SETUP, or GUI 330. If the setup mode was not selected, the GUI.COM 325 cooperates in the loading and unloading of network drivers at 335 and begins the running of network connection code (again, ICA, thin wire, com, or other network) at 340. In a presently preferred embodiment, the network connection code includes a substantially modified version of the Winframe for DOS client, the standard version of which is available from Citrix Systems, Inc. Now referring to FIG. 5, the cooperation of the terminal operating system and the hardware architecture of the present invention may be better appreciated. In particular, the lowest layer shown in FIG. 5 is the Input/output system and hardware layer 400. The next higher layer is the Driver layer 402, while the top layer is the Application layer 404.

At power-on, the power-up and Init tests 406 in the hardware layer are performed as part of the boot block 300. The power-up and Init tests 406 execute partly out of the flash memory system 112 and partly out of RAM 116. Once the power on self tests are completed, the terminal continues with the boot sequence described generally above in connection with FIG. 4, including the remainder of the boot block 300, an AUTOEXEC sequence 408, and the COMMAND.COM sequence indicated at 315. Both the AUTOEXEC and COMMAND.COM files are maintained in the flash memory.

After the terminal's COMMAND.COM sequence executes, it causes the AUTOEXEC file to load. The AUTOEXEC in turn causes the GUI.COM 325 to load. As noted above, the GUI.COM sequence 325 can branch either to the Setup Module 330 or the Network

Connection module 340. At initial installation or any time thereafter that operating parameters of the terminal require verification or changing, the Setup Module 330 is run. The Setup Module 330 receives information from one or more setup data files 418 and starts the GUI engine 420. The GUI engine 420 in turn communicates with a keyboard driver 422, mouse driver 424, and the files and memory services driver 426 of the terminal operating system. In addition, the GUI engine 420 also communicates with the video Input/output system 428, which in turn provides data to the video controller 430, which may for example be based on a Cirrus 5429 graphics processor, to generate a video display during the setup sequence. The setup sequence will be described in greater detail in connection with FIG. 5. The keyboard driver 422 in turn communicates with the keyboard controller hardware

432, which may, for example, be a conventional PS/2 keyboard Input/output system, a universal serial bus (USB) interface, and in at least some embodiments may also include a four wire keyboard interface such as that described in the aforementioned U.S. Patent No. 4,706,068. Likewise, the mouse driver 424 is typically also communicating at appropriate times with a mouse input/output system 434. Throughout such operations, the terminal operating system's flash file and memory services portions 426 will typically be executing out offlash and RAM.

As discussed in greater detail in connection with FIG. 5, the setup process permits the user to specify the configuration information of the terminal, including such parameters as network interface and related configuration details, language, colors, and other parameters. Once these parameters are specified, the data is stored in the connection data files 440.

At this point the user is ready to exit the terminal setup module 41 4, and return to the GUI.COM. When allowed to continue, the GUI.COM process 412 can be caused to branch to the network connection module 416. The network connection module 340 initiates by retrieving the data stored in the connection data files 440 and the command line of the connection module, thereby communicating to the application server how to talk to the rest of the driver and hardware layers of the terminal. In particular, the network connection module communicates with the keyboard driver 422, the mouse driver 424, the video input/output system 428, and the file and memory services portion 426 of the terminal operating system. In addition, the network connection module also connects a hardware serial interface 442 as well as, in some embodiments, a hardware network interface 444. The network drivers 444 execute out of RAM 116 in one exemplary embodiment, but may execute out of flash memory 112. The serial interface 442 may be a conventional RS232 interface, but may also be another form of serial connection, such as the Universal Serial Bus, or USB.

Referring next to FIG. 6, the operation of the GUI engine 420 shown in FIG. 5 during setup module of the terminal 12 may be better appreciated. The GUI engine operates only during the setup mode, and provides a rudimentary graphical user interface during the configuration operation.

As noted in connection with FIG. 5, above, the operation of FIG. 6 begins when the setup sequence is invoked during terminal boot up. The setup sequence may be invoked from a sequence of keystrokes or any other convenient and suitable means. The setup sequence starts by calling setup code 502, which in turn pulls information from setup data files 418. The setup data files 418 identify the options available in the configuration of the terminal. The setup code 502 communicates bidirecfionally with a RAM structure 504, and also causes existing connection information from the connection data files 440 to be written into the RAM structure 504. The GUI engine 420 also communicates bidirecfionally with the RAM structure to set up and display current information in an arrangement described hereinafter as areas, groups and selects. In addition, a hardware interface 506 provides video information to video controller 430 while responding to information received from the user via the mouse 260 and keyboard 250.

The setup code permits the user to cycle through a plurality of configuration menus for the operating characteristics of the terminal, such as the language displayed on the terminal, the network connection method, and so on. Shown in FIG. 7A is an illustration of a setup screen used in the configuration mode of the terminal. In a preferred embodiment, the setup screens are displayed graphically. As the user cycles through the configuration screens, the user through use of the keyboard and mouse may selectively update the configuration data. The updated data is maintained in the RAM structure 504 before being written to the connection data files 436. However, in a presently preferred embodiment, certain of the data may be updated dynamically, while other data is not updated until the setup sequence is completed. Upon completion of the setup sequence, including writing any remaining configuration data to the connection data files 436, the setup sequence exits and returns to the GUIC.COM 325 for initiation of the network connection module 340 shown in FIG. 5.

Continuing with reference to FIG. 7A, the overall window in which the data appears will be referred to herein as an area 600. Within each area 600 are one or more groups 610, and each group 610 comprises one or more selects 620. Thus, in the example of FIG. 7A, the "Communication" group includes the selects Serial Port, TCP/IP, SPX and IPX, each of which has associated therewith a region 630 indicating that select has been chosen, or selected.

III. CONFIGURATION DATA STRUCTURES Referring next to FIGS. 7B1 - 7B3, the data structures associated with the configuration software are shown. In particular, a list of area pointers is found in AREA_LIST 700. The structures pointed to by the area list include boundaries, size, title and groups attached for all areas as defined by the SETUP process. As noted previously, each area appears as a window on the screen. In addition, all areas that are currently being displayed are listed in DISP_AREA_LIST 702. In an exemplary embodiment, the first area listed is displayed as the bottom area, and the last area listed is the top area displayed. In the exemplary embodiment, overlapping of windows is permitted although 30 overlapping is not necessarily required in all embodiments.

At 704 is the data structure for GROUP_LIST, which lists all groups defined by the SETUP process in all areas found in the AREA_LIST 700. As previously noted, each area typically includes one or more groups. An optional data structure 706 for a STRTNG_LIST may also be provided, and a FILE_LIST 708 is provided as a directory to bitmap images which may be used in multiple instances within the various areas, groups and selects.

The structure of the AREA_LIST 700 can be seen at 710 to include a block for an area ID 712, a pointer to the next area 714, a pointer to the previous area 716, and a structure pointer 718. The structure pointer 718 associated with each area ID 712 points to an area structure 715 which includes the area ID 712 together with an ABS_X entry 720 and an ABS_Y entry 722 to give the location of that area relative to (in an exemplary embodiment) the top left corner of the display. The area structure 714 also includes a ROWS entry 724 and a COLUMNS entry 726 that together specify the size of the area. A FLAGS entry 728 specifies whether a border extends around the area. A TITLE_POSITION entry 730 and TITLE_BAR entry 732 specifies the text of the title and its location within the title bar of the particular area, while a MAX_STR_LEN entry 734 specifies the maximum number of characters which may be used for the title.

In addition, the area structure 714 also includes an entry 736 for the number of groups contained within the particular area. An AREA_MPTR entry 738 specifies the mouse pointer hot spot within the area, while an entry DEF BUTTON 740 specifies which button within the area will be the default. The default button will be activated when the "enter" key is pressed. A 25 CAN BUTTON entry 742 specifies the cancel button, which will be activated when the "ESC" key is pressed. Finally, a list of pointers, one for each group associated with the area, is specified at 744A-744N. Each group pointer 744 points to an associated group structure block 746, discussed hereinafter. A hot key list may also be defined for the area.

The structure of the DISP_AREA_LIST, shown at 748, is essentially identical to the structure of the AREA LIST 748, and includes blocks for area ID, next area, previous area, and structure pointer. As with the AREA LIST 700, the DISP_AREA_LIST 748 also points to the area structure 714. A similar structure for the GROUP_LIST 704 is shown at 750, and includes a group ID 752, a next group pointer 754, a previous group pointer 756 and a group structure pointer 758. A similar structure for the optional STRING_LIST 706 may also be provided, and may include a string ID 760, a next string pointer 762, a previous string pointer 764, and a string structure pointer 766.

Referring again to the group structure pointer 758, it points to the group 10 structure block 746 and includes the group ID 752, a PARENT_SELECT_ID entry 780, to identify the select which, when activated, will automatically pop up this group, a HOTSPOT_COUNT entry 782 to identify the number of mouse hot spots within the group, and GSTART_X and GSTART Y entries 784 and 786, respectively, to specify the relative location of the group within the area. In an exemplary embodiment, both the group and the select locations are specified relative to the top left corner of the area containing them; but other relationships may be defined that are also acceptable, such as specifying the location of a select relative to the location of its group. The most important element is to ensure that all features of an area maintain their position within the area if the area is moved.

The group structure block 746 also includes ROWS and COLUMNS entries 788 and 790, respectively, for specifying the size of the group, as well a GFLAGS entry 792 for specifying the border of the group. In addition, a QUICK_KEY_POSITION entry 794 and a QUICK_KEY_STROKES entry 796 may also be specified for "hot" keystroke combinations associated with the group. Further, and similar to the area structure, entries for title position 798, group label 800 and MAX_STR_LEN 802 may be provided. In addition, a NUM_OF_SELECTS entry 804 is provided to identify the number of selects contained within a group. Next, an entry 806 for AID_ATTACH is provided as a back reference to the area ID 712 with which the particular group is associated. The AID_ATTACH entry 806 is not required in all cases, but assists in improving performance in at least some instances. Lastly, a list of pointer entries 808 A through 808N each point to a select structure associated with the particular group. As will be discussed hereinafter, a variety of select structures may be associated with each group, but some elements are common among the various types. Thus, the first pointer 808A points to a ELECT_COMMON structure block 810. Referring again to the area structure block 714, the default button entry 740 and cancel button entry 742 also point to the select common structure block 810.

The SELECT_COMMON structure block 810 includes a select ID entry 812, an entry 814 giving back reference to the group ID, REL_X and REL_Y entries 816 and 818 together with ROWS and COLS entries 820 and 822 for specifying the location and size of the select, QUICK_KEY_POS and QUICK_KEY_CHR entries 824 and 826 for specifying the hot keystroke combinations associated with the select, a MAX_STR_LEN 828 and select string 830 for specifying the maximum size and title for the select, and an SFLAGS entry 832 for specifying the characteristics of the select. In addition, a SELECT_TYPE entry 834 is also provided. As noted previously, different types of selects are available, and reference is again made to FIG. 7A. The different types of selects that may be provided within a group depend on the type of data required at that step for configuring the terminal. In some instances, the choices involve only the pressing of a button (see buttons 640); in others, a select involves enabling or disabling a feature, as a check box (see 650 in FIG. 7A); in others, one of several choices must be selected, as indicated in the "Communication" and "Serial Port" groups 660 and 670 of FIG. 7A. In still others, an image may be selected, while in others specific text must be selected. In some, a fill-in entry is required (680 in FIG. 7A), while in others one of many fields must be filled in. Although these are the types of selects which have been implemented in an exemplary embodiment, the list is not exhaustive and other selects can be readily implemented given the teachings herein. For a "fill in" select, cursor start and cursor end entries 836 and 838 are provided, together with a "first displayed" entry 840 for identifying from which character on the string should be displayed. In addition, a LABEL_REL_X entry 842 is provided as well as a LABEL REL Y entry 844 and a LABEL_STR entry 846.

For a "one of many" select type, entries for NUM_OF_SEL_ROWS and SUM_OF_SEL_COLS 848 and 850, respectively, are provided. Entries are also provided for the number of options 852 and default option 854, as well as a quick key pointer 856 and a flag pointer 858 to identify the number of option which are active. Finally, a select size 860 is also provided.

For an "image" type of select, only an entry for the file ID 708 and an image pointer 862 must be specified. For a "fields" type of select, a "child group" ID entry 864 is provided together with a child group pointer, which points to a group structure of the type shown in group structure block 746. The child group will be popped up automatically when the parent select is activated, and one of a group of fields is selected.

For a "list of strings" select, entries are provided for number of options 868, the maximum length of the option title (or MAX_OP_LEN) 870, a horizontal display offset entry 872 and a vertical display offset entry 874, together with an X label position 878 and Y label position 880. Finally a label string 882 and a select string size entry 884 are provided.

Referring again to the AREA MPTR entry 738, the mouse pointer hot spot is specified by a structure that includes an area ID entry 900, a group ID entry 902, and a select ID 904. In addition, an option select type 906 is provided to specify the type of select with which a particular hot spot is associated. Further, back reference entries 908 and 910 are provided for the group ID within the area, and the select ID within the group. Still further, four entries 912A-D 30 specify upper left X and Y positions as well as lower right X and Y positions for the mouse hot spot, together with an entry 914 for mouse flags which cause the mouse hot spot to be activated when the proper menu is displayed. In addition to the hot spots described in the foregoing, additional hot spots are provided at the top and bottom of a list display, to allow scrolling, and in the title bar portion of an area, to permit the area window to be moved.

In addition to the foregoing structures, a data structure is also provided for maintaining the currently selected entries from among the various choices. The current data structure block is shown at 950, and includes an entry 952 for the number of areas currently defined by

SETUP; an entry 954 for how many image files are defined; entries 956 and 958, respectively, for how many groups and selects have been defined, an entry 960 for allocating a predetermined maximum number of selects. In an exemplary embodiment, the maximum number of selects is allocated in blocks often.

Additional entries 962 and 964 are provided for the number of pixels per column and row, respectively, as well as a font entry 966, an area focus entry 968, a group focus entry 970, and a string focus entry 972. Also, a mouse focus entry 974 is provided for specifying the hot spot. Further, OFOCUS and TFOCUS entries 976 and 978 may be provided for specifying select options and select types with keyboard focus. Still further, IFOCUS and JFOCUS entries 980 and 982 are provided for the hotspot entries 908 and 910 from the mouse structure block described above. Finally, a menu entry 986 is specified for identifying the current menu focus, together with entries 988 and 990 for defining area borders and group borders, together with an OFLAGS entry for specifying mouse modes.

The information specifying the current state of the selects is specified in an ACTIVE SELECT structure 1000. Each structure includes a button entry 1002, an STFLAGS, or select common flags, entry 1004, and an ACTIVE entry, which stores the current state of all selects, from which that data may be made available to the SETUP code.

In an exemplary embodiment, an event queue structure 1010 may also be supplied, for recording keyboard strokes and mouse movements in an event queue.

As noted previously, a key feature of the present invention is that the terminal operating system of the present invention is not compatible with a standard PC/AT BIOS or DOS. However, the terminal operating system is required to support certain of these functions to maintain the ability to display application data in a multiuser environment, such as by interfacing to a Citrix client or other supported emulations. Attached as Tables 3A-3C is a list of the standard IO.SYS and BIOS. SYS functions which are supported by the present invention; it will be apparent to those skilled in the art that the list does not include numerous standard BIOS and DOS functions. Other functions are unsupported. In addition, some of the features which are listed are only partly supported in a presently preferred embodiment. Thus, Function 36h [Get Disk Free Space] is only partly supported due to the use of flash memory instead of a hard disk. Likewise, Function 33h [Get/Set System Value] is supported in terms of function and flag, but the "Control-Break" function is not supported. Similarly, Function 2Ah through 2Dh [Get/Set Date/Time functions] is only partially supported because no real time hardware is provided in the terminal of the present invention. The "Get Time" function is supported so that it may be used to measure the duration of events, without reflecting absolute time. In addition, the flash file system of the present invention is, in the presently preferred arrangement, partitioned into multiple single-directory drives. However, unlike conventional disk files, the flash file system includes no clusters or sectors. Files within each drive or partition grow upwards from the bottom of the partition, while directory entries grow downward from the top. Files are stored contiguously, without fragmenting. Directory entries, which are sixteen bytes long in a preferred embodiment, are generally similar to a DOS directory entry; however, elements that would normally be reserved are defined to permit the file to execute out of flash, rather than DRAM. These include the starting address of the file within the flash, as well as the remap segment of the file within the DOS address space. File deletion, while also similar to deletion of conventional DOS files, also differs in some important details. When a file is deleted in the present invention, the first byte of the directory entry is changed to 0, as opposed to setting it to E5h. This step is performed without erasing a flash block. Subsequent files will then be written to the next available space. However, if there is not enough available space for the subsequent files, the flash block for the deleted file is erased and undeleted files are rewritten to the flash block where the deleted file had been maintained. As noted before, file fragmentation is not permitted in at least some embodiments.

The flash file system supports conventional DIR, TYPE and DEL commands, supports a new "DEBUGMSG" command for generating a DEBUG message, and also supports program execution through batch files. The file system also supports the AUTOEXEC.BAT file, as well as loading and executing of .EXE and .COM files, and Int 21h and Int 27h. However, the file system does not support, in at least some embodiments, the CONFIG.SYS file or .SYS device drivers. Likewise, the file system does not support batch file commands (except program execution), I/O redirection, pipes, or interrupts 20h [Program Terminate], 22h [Terminate Address], 23h [Ctrl-Break Exit Address], 24h [Critical Error Handler Vector], 25h [Absolute Disk Read], 26h [Absolute Disk Write], and 2Fh [Multiplex Interrupt].

From the foregoing, it will be apparent that, while a selected group of the standard BIOS and DOS functions are emulated or otherwise supported by the terminal operating system of the present invention, a very significant number of standard BIOS and DOS functions are not supported. In addition, even those BIOS and DOS functions that are supported are not executed by standard AT-compatible hardware. Instead, the portion of the terminal operating system referred to in Figure 4 as the "boot block" 300 and the "kernel" 305 establishes the ability to emulate these functions. IV. MULTISESSIONS

The present invention includes a multisession capability for graphic applications that provides multiple full screen DOS sessions so that an user can switch between emulations such as to provide one window in a Citrix connection and a telnet connection in another window. Generally, the environment is as DOS compatible as possible to simplify porting. The problem with graphic applications is that it requires a large amount of memory to hold the graphic screens that the graphic screens would have to be stored when switching to another screen. The present invention overcomes this problem by sending a signal from the operating system to the application to stop drawing and then redraw the screen, which they switch out of, and switch into the foreground. This is a departure from making the environment completely DOS compatible because it requires some modification of the DOS application. For the ICA emulation, the kernel sends a signal to the Citrix application to redraw the graphics screen. By contrast, the text mode applications under the present invention run without modification because they do not require as much memory and are left unaffected by the signaling. The Citrix software is an application program that has a DOS version and a WINDOWS version to run on the client. The WINDOWS version requiring more hardware resources such as memory to run properly on the client. The Citrix client software runs on the RAM of the terminal. Typically, the client Software connects to an NT or Citrix server where another application is running that the user wants to connect. For example, a spreadsheet program running on the server is display output comes to the terminal. The emulations run on the RAM of the terminal with various device drivers and diagnostic programs and the kernel and a connection manager of the present invention.

The prior art mechanism for redrawing a screen involves Citrix client software sending a "stop" command to the server to stop sending output and then sends a redisplay command to send data to redraw the screen. Specifically, the Citrix software uses a connection manager invokes the stop request to send the open session to the background when you open the connection manager. The Citrix software does not allow establishing multiple connections. Only one session can be open at a time. Furthermore, only one of an open session or the connection manager can be open in the foreground at a time.

The present invention allows opening multiple sessions with each session having its own virtual machine that it runs in. The stop request and redisplay commands are taken advantage so that when a session is moved to the background, it will not be trying to draw it on the screen. The screen is not saved in memory.

The present invention gives each virtual machine its own text mode buffer, so when it is in the backgroμnd it has a virtual buffer that it can write to and it continues to run in the background. For instance, if the screen is being drawn to in the text mode (writing characters to the screen) when the screen is switched to the background, the mapping of the data will continue to the virtual buffer rather than to the actual physical hardware while the screen is in the background. The kernel handles the mapping transparently to the application.

For graphics applications, the present invention sends a signal to the application. The application sends a signal out to the host to command it to stop sending display. When the application screen is switched back to the foreground, the host is commanded to redisplay the screen. The amount of network traffic caused by the application being in the background is drastically reduced compared to the prior art. By contrast, the Citrix software continues to receive data to an application in the background session. The data, however, is not displayed. The sending and receiving of data from the server to the background application results in continuous network traffic and a drain on other system resources like memory and CPU utilization.

The present invention is particularly suitable to a DOS environment where the hardware resources are limited and cannot support a complete WINDOWS operating system on the terminal. The present invention provides a terminal that can run multiple connections with multiple graphic sessions of WINDOWS applications. Preferably, the multiple graphic sessions are run in a DOS environment.

V. SYSTEM KERNEL AND SYSTEM CONFIGURATION

Appendix "A" lists various services provided by the Windows system kernel, where these services are accessed through various interrupts.

FIGS. 8-12 illustrate various configuration parameters for a terminal according to the invention.

FIG. 8 shows a memory address map for the terminal system including address ranges, memory sizes, bus widths, and descriptions for the DRAM, the base memory, the VGA display memory, the boot block shadow, the VGA linear address, the peripherals, the network memory space, ROMCS2 (Flash Bank 2), ROM/FLASH Bank 1, ROM/FLASH Bank 0, and Boot ROM/FLASH. FIG. 9 shows an I/O address amp, which includes address ranges, sizes, and descriptions for various I/O items.

FIG. 10 shows interrupt assignments for various hardware and SC400 internal interrupts. FIG. 11 shows various DMA channel assignments.

FIG. 12 shows chip select for various devices along with address ranges.

VI. SOFTWARE DESCRIPTION The present invention expands the functionality of the previous Multi User NT to provide enhanced remote administration functions using industry standard protocols. These enhanced remote administration functions perform software image upgrades, modify terminal user-interface selections, and improve terminal status reporting.

Network Driver Loading

This version of software will attempt to load Ethernet drivers at bootup as the default network drivers. Normally, the network drivers load with very few messages in a single message box. If there is an error, the error message appears briefly, then goes away, and the terminal automatically continues. The network driver cannot continue to load if there was an error, but the connection manager can come up. If a verbose method is enabled more detailed messages are scrolled in the network box while the network is loading, and any errors that cause the network driver to fail loading will require the user to press a key acknowledging the error, before the terminal continues with its boot process.

FTP Enhancement

This version of inventive software supports the File Transfer Protocol (FTP), which is used exclusively for firmware images upgrades and remote terminal configurations. Use of TFTP is also suitable.

DHCP Automated Software Image Upgrades

The present invention uses the Dynamic Host Configuration Protocol DHCP and FTP to provide automated downloading of a new image via the network. For this process to work, the inventive software uses DHCP instead of a static IP address and having the DHCP Update field enabled.

The new update process functions such that on boot, the inventive software downloads new custom DHCP Options as follows: a) Tag 161 (IP octet or IP string up to twenty characters) indicates the FTP server on which the image software and control files

(PARAMS.INI AND PARAM#.ΓNI) are found, b) Tag 162 (String up to eighty characters) indicates the FTP server's root directory path on the server which image software and control file (params.ini and param#.ini) are found, c) Tag 163 (IP Array, maximum of four entries) contains a list of IP numbers for SNMP Trap Servers where the local IP Trap Server entries in the inventive software's user interface override though it is configured through DHCP. Tag 163 contains a list of IP numbers for the SNMP Trap Servers. If the corresponding SNMP Trap server entries in the local user interface are filed in, the local entries will override the values obtained through DHCP Tag 163. d) Tag 164 (String up to sixty characters) indicates the SNMP Set Community where the local Set Community entry in the inventive software's user interface overrides though it is configured through DHCP.

After a DHCP command has been performed, the inventive software uses information in the local copy of the PARAMS.INI (for base software) and PARAM#.LNI (for option software packages) files to determine the path from the FTP base directory where the terminal specific files (including control, base image files and option image files) are retained. The configuration file entries are listed in Table 2.

A matrix of how this path is structured is as follows: «<Entire FTP TREE>» WServer from DHCP Tag 161

\root directory from DHCP Tag 162 (root$ terminates tree creation. See note \Option from Option= entry in PARAMS .INI or P RAM#.INI

W-OemName from OemName= entry in PARAMS.INI or PARAM#.LNI \Os from Os= entry in PARAMS. INI or PARAM#.INI W-Platform from Platform= entry in PARAMS.INI or PARAM#.ιNI W-Refresh from Refresh= entry in PARAMS.INI or PARAM#.lNI \UserPath from UserPath= entry in PARAMS.INI or PARAM#.INI

-PARAMS.INI or PARAM#.INI file -Base or Option Image file Note that if a string sent with Tag 162 or DHCP OPT ADM FILEROOTPATH ends with a "$", this is considered the complete path to the PARAMS.INI, PARAM#.INI and image files. This indicator bypasses the imposed Wyse FTP Tree structure illustrated above.

Note that blank levels are skipped. For example, if this is standard Wyse base software (from defaults), the Option subdirectory, the OemName subdirectory and the UserPath subdirectory portions of the tree will not exist in the path. The remaining structure would be \\Server\root directory\os\platform\refresh\file.

1. After the correct path has been determined, the inventive software will connect via FTP to the specified \\server\path and download all PARAMS.INI and PARAM#.INI files. The inventive software will then compare the build number information and modification data information (BuildVer=, OemBuildVer=, and ModDate= information strings) of the PARAMS.INI and or PARAM#.INI FTP server files with the local files on the server to determine if an upgrade is required. If all strings match, the terminal will complete the boot into the user interface and function normally. If any string does not match, the inventive software will continue the upgrade process as follows:

2. The inventive software will download the appropriate bundled Winterm base or option image indicated by the server PARAMS.INI or PARAM#.LNI into RAM. During the network transfer of an image, if the network download is interrupted due to a loss of the network connection or power to the unit, the inventive software will not be adversely affected. Note that the maximum image size that can be transferred must be less than the amount of

RAM available at the start of the transfer. If there is insufficient RAM available at the transfer start, then the image is unbundled on the fly and saves to the FLASH to upgrade the image.

3. After the entire image is downloaded to RAM, the inventive software will unbundle the image and update the Boot Block and NAND Flash. This is similar to the update performed when downloading an image to the inventive software through a Parallel, Serial, or Flash Card update. The boot block will be checked first, and if the boot block code has changed a new boot block will be downloaded. The main image then will be written to the NAND flash. If power is interrupted during the file transfer to the boot block (this period is extremely small since the component is only 256K bytes in size), the boot block may be corrupted requiring a new pre-programmed component to be installed. If power is interrupted during a file transfer to the NAND flash (this time period too is small and takes only a few seconds to complete the upgrade), the NAND flash main image code may be corrupted requiring a serial, parallel, or flash card update. 4. Once the image update has been completed, the inventive software will automatically reboot. Note: During the DHCP update process, the inventive software sends SNMP Traps to reflect the current status of the terminal download process. DHCP related Traps are described below.

SNMP Enhancements

In the inventive software, the Simple Network Management Protocol SNMP enhancements listed in TABLE 1 are incorporated. Appendix B is hereby incorporated by reference and lists the portion of the Management Information Base for the network connections, user definitions and traps described herein.

1) Wyse Enterprise Specific Management Information Base MIB database - Memory Configuration Reporting for RAM and ROM Configuration Reporting

2) PCMCIA Device Reporting for Reporting on Inserted PCMCIA Devices

3) IO Device Reporting 4) Display Reporting reports the current and maximum values for display characteristics.

5) DHCP Information Reporting reports the values received from the DHCP server for the custom option values.

6) ROM Image Information Reporting reports the values associated with the ROM images actually loaded on the Winterm and those for the images loaded on the FTP server designated in wbt3FileServer.

7) Custom field content reporting. The contents of the three custom fields that can be configured through the Winterm UI on the SNMP/Network Administration property sheet.

8) The MIB also provides remote administration related functions. The fields within this group are writable so that an upload or download process can be initiated by setting proper values in these fields for File Uploading and Downloading. Note that upload and download requests generated by the SNMP manager prior the Winterm generating the sbt2TrapSNMPAccptLd trap will be ignored. Destination hosts, which will receive these traps, can be defined in the inventive software user interface. 9) SNMP Traps - The following SNMP traps are supported: a) Warmstart b)Coldstart c) Linkup d) Authentication Failure e) Equipment Specific TRAPS for Automated and Interactive Image Updates. SNMP Interactive and Automated Software Image Upgrade

In this version of the inventive software, support is added through SNMP and FTP to cause an interactive or automated downloading of a new image via the network. This update process generally functions as follows: SNMP updates must be enabled and "SNMP updates enabled" are the default settings on this version of software.

1. The Winterm powers up and sends the wbt3 Trap SNMP AccptLd Trap when the terminal is ready to receive a file upload or download request through SNMP.

2. For automated downloading, through OpenView or other SNMP management programs the administration program will be able to detect the wbt3TrapSNMP AccptLd Trap and through scripting identify the current revision of software and initiate file uploads or downloads to the inventive software.

3. Through SNMP, the current Winterm configuration can be obtained via a FTP/TFTP connection by requesting the setting .REG file. These files can then be modified and then downloaded to the inventive software terminal. Similarly, an entire binary image can be downloaded to the inventive software terminal.

If the inventive software has a connected session, an image upgrade process will display a message and prompt acceptance. After a file download is completed, the terminal will automatically reboot. The process of uploading files from the terminal transparently occurs in the background.

4. Bundled image updates will be handled identically as in DHCP image updates with the exceptions that: the FPT/TFTP server, path and filenames to be downloaded are specified via setting appropriate objects in the wbt3UpDnLoad group and download is not conditional on the contents of a PARAM#.INI file. Any download requested through the SNMP interface will be attempted unconditionally.

5. Once the image update has been completed, the inventive software will automatically reboot.

The present invention uses SNMP to remotely configure the terminal on a thin-client network. Typical configuration settings that can be remotely administered include, but are not limited to, the network interface, display, keyboard, any peripheral, any terminal emulation characteristics, security features, user account information, etc. This configuration data differs from information data which includes information about the RAM and FLASH memory, other hardware information, PC card slots, what PC card is plugged in, what peripherals are attached, the maximum resolution supported for display, what frequency is supported for the display, what information DHCP obtained, etc.

The MIB of the present invention is used to remotely configure a thin-client terminal even though the MIB resides on the server for the network. Other protocols can be used. The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.

APPENDIX A

Multi User NT KERNEL

1 OVERVIEW

The Multi User NT kernel sets up the operating environment in which the Winterm application programs execute

2 KERNEL API

The kernel provides a vaπety of services to application and control programs The services can be accessed through various interrupts:

Int FAh Switch Between Virtual Mode and Protected Mode

Int FDh Signal Session Switch

Int FEh / 0 Install Video

Int FEh / 1 Set Power-Down Time

Int FEh / 2 Get Video Selector

Int FEh / 3 Get Code Selector

Int FEh / 4 Get Data Selector

Int FEh / 5 Free Selector

Int FEh / 6

Int FEh / 7 Set Collection Number

Int FEh / 8 Disable Display Access

Int FEh / 9 Create Session

Int FEh / 10 Get Session Info

Int FEh / 11 Set Focus Session

Int FEh / 12 Destroy Session

Int FEh / 13 Mouse Event Handler

Int FEh / 14 New Graphics Mode

Int FEh / 15 Enable/Disable Session Switching

Int FEh / 16 Get Current Graphics Mode

Int FEh / 17 Prepare for Admin

Int FEh / 18 Acquire Resources

Int FEh / 19 Free Resources

Int FEh / 20 Post Thread Message

Int Feh / 21 Get Message

Int FFh / Boot Block Services

2.1 Int FAh: Switch Between Virtual Mode and Protected Mode

Interrupt FAh can be used to switch from virtual mode to protected mode, and then to return to virtual mode at a later time. After a transition, EIP will contain the offset of the next instruction after the mt FAh instruction. Flags (except for the virtual mode bit) will be preserved across the transition.

Hardware interrupts are allowed while in protected mode.

Virtual mode service interrupts (i.e., DOS, BIOS, etc. (i.e., t lOh, int I4h, int 15h, mt I6h, int 17h, int 21h, etc.)) should not be attempted while m protected mode.

When switching to protected mode:

CS is set to the code selector which was created duπng the last invocation of mt FEH, function 3. Normally this code selector is created to alias the current code segment.

Int FAh was defined to provide protected mode support for the Winterm/Citπx graphics dπver, and is intended to be used with only a single code segment Although it can be used with multiple code segments, the fact that there is currently no way to return to a previously created selector after a new selector is created, except by recreating the old selector, could be a limitation

SS ESP will be set to the kernel's stack Operations that use the stack while in protected mode should assume a 32-bit stack For example, ENTER, LEAVE, and other stack frame references should use EBP instead of BP

All other segment registers will be set to arbitrary values, and should be initialized pπor to use

When switching to virtual mode

A corresponding int FAh must have been executed previously to switch to protected mode

All segment registers are restored to the values they had before enteπng protected mode ESP is restored, as well

2.2 Int FDh: Signal Session Switch

Switching between sessions is intended to be as transparent as possible to the applications running m the sessions that are being switched in and out of the foreground To achieve this, the kernel maintains a virtual frame buffer for sessions when their applications are running in text mode When text mode applications lose focus (I e , they are switched out of the foreground), the contents of the physical text frame buffer is copied to the virtual buffer for that session If the application continues to output text while it is m the background, the virtual buffer will be updated, and the application will have no knowledge that it is not wntmg directly to the screen When that session is switched back to the foreground, the contents of the virtual buffer are copied back to the physical buffer

Unfortunately, maintaining virtual screen buffers for graphics applications would require much larger amounts of memory, up to 768KB for a 1024x768 256-color mode In order to maximize memory available for applications, the current architecture does not save virtual graphics screens Instead, graphics-mode applications are required to save their own screen, if necessary, and to restore it when they are returned to the foreground A propπetary interrupt is defined to signal graphics applications when the ga ing or losing focus (This is similar to the Win 32 paradigm, m which a REPAINT message is sent to an application to redraw part of all of its window )

Interrupt FDh is issued by the kernel to a session that is running a graphics application that has focus when the kernel wants that session to give up its focus The graphics application must issue its own interrupt FDh to acknowledge the kernel's request, and to signal that it is ready to give up the session

Interrupt FDh is also issued by the kernel to a session running a graphics application when that session is about to receive focus The graphics application should redraw the screen when it receives this signal

2.3 Int FEh 10: Install Video

Inputs : AX = 0

Output : None

2.4 Int FEh 11: Set Power-Down Time

2.5 Int FEh 12: Get Video Selector

Input : AX = 2

Output : AX = selector

The returned selector provides access to the graphics frame in protected mode The graphics chip is assumed to be in linear addressing mode

2.6 Int FEh / 3: Get Code Selector

Inputs: AX = 3

BX = code segment to alias Output: AX = code selector

This function creates and returns a selector that is an alias for a given code segment The segment will have read and execute pπvilege when accessed through the new selector.

The selector should be returned with t FEh, function 5, when it is no longer needed

2.7 Int FEh 14: Get Data Selector

Inputs: AX = 4

BX = data segment to alias Output: AX = data selector

This function creates and returns a selector that is an alias for a given data segment. The segment will have read and write privilege when accessed through the new selector.

The selector should be returned with mt FEh, function 5, when it is no longer needed

2.8 Int FEh 15: Free Selector

Inputs: AX = 5

BX = selector to return Output : None

This function returns a previously initialized selector to the kernel The selector must have been initialized with int FEh function 3 or int FEh function 4.

2.9 Int FEh 16

2.10 Int FEh / 7: Set Collection Number

Inputs: AX = 7

BX = collection number

EDX = MS-DOS encoded file date and time Output: AX = previous collection number

2.11 Int FEh / 8: Disable Display Access

Inputs: AX = 8

Output : None 2.12 Int FEh 19: Create Session

Inputs: AX = 9

EBX = session ID (0 if a new session is to be created) ECX = pointer to structure:

Offset 0 = size of structure in bytes (DWORD) Offset 4 = requested size of base memory in bytes (DWORD) Offset 8 = requested size of XMS memory in bytes (DWORD) Offset 12 = pointer to a string describing the session ( DWORD)

EDX = flags

Bit 0 = 1 iff the session is allowed to have focus (i.e., iff it is allowed to run as the foreground task) ; Bit 1 = 1 iff the session is to be given CPU time to execute non-mterrupt code; Bit 2 = 0 if there is to be no change in the session's current focus status; = 1 if the session is to be given focus immediately; ESI = pointer to command to execute (zero-terminated string containing command name), or zero if no command is to be executed at the moment. EDI = pointer to command tail, or zero if no command is to be executed at the moment . Outputs: AL = return code of the last DOS program that exited from the specified session; EBX = session ID (EBX is unchanged from the input value unless a new session is created) ; EDX = flags;

Bit 8 = 1 iff the session has the focus;

Bit 9 = 1 iff the session is executing a DOS program.

If EBX is set to zero, a new session will be created (if there is enough memory) If EBX refers to an existing session, this function can be used to change that session's flags and descπption stπng, and/or to begin execution of a DOS application in that session Currently, only the keyboard dπver (KEYBD.COM) is executed automatically for each newly created session (If the descπption stπng is not to be changed, either the pointer to the stπng or the pointer in ECX must be zero.)

COMMAND COM is executed automatically when the first session is created at boot time, however, it is not executed automatically when this function is called subsequently to create additional sessions. COMMAND COM can be executed by specifying it m a command line pointed to by the ESI register as descπbed above, but this is normally done only for testing, because vaπous application programs can be executed directly without invoking COMMAND.COM, and COMMAND.COM automatically executes AUTOEXEC.BAT, which should normally be executed only once, for the first session.

2.13 Int FEh 110: Get Session Info

Inputs : AX = 10

Output : EBX = session ID of the current session;

ECX = focused task;

EDX = flags;

Bit 0 = 1 iff the session is allowed to have focus ( i . e . , iff it is allowed to run as the foreground task) ;

Bit 1 = 1 iff the session is to be given CPU time to execute non-mterrupt code;

Bit 8 = 1 iff the session has the focus;

Bit 9 = 1 iff the session is executing a DOS program;

Bit 10 = 1 iff a previously executed call to " Set Focus

Session" Is still n progress.

Flag bit 9 can be polled to determine whether a program is still executing in the session, or whether it has exited After an executing program terminates, bit 9 will be zero Note that the session still exists, and will continue to exist until destroyed by int FEh function 12, however, no program is executing in the session It is possible to begin execution of a new program by passing the name of the program through int FEh function 9

2.14 Int FEh / 11: Set Focus Session

Inputs: AX = 11

EBX = new task to which to give focus Output : None

This function specifies which application session will have focus A session can only receive keyboard and mouse information if it has focus If a session is running a text-based application, output from the application will go to the physical screen frame buffer only if the session has focus, otherwise, the output will go to a virtual buffer that is restored to the physical buffer when the session regains focus

This function begins the session switching procedure and might return before the session switch completes Function 10 can be used to veπfy that a session switch has completed

Note that if a foreground graphics application uses this function to switch to the background, and then polls function 10 to see when the switch completes, the application must insure that interrupt FDh can be processed and acknowledged while the polling takes place

The session that is losing focus must be allowed CPU time m order to execute the procedure to save the current graphics state I e , flag bit 1 (see int FEh function 9) must be set The the CPU's time slice is disabled for that session, the "Set Focus Session" call will never complete

2.15 Int FEh 112: Destroy Session

Inputs: AX = 12

EBX = task that is to be destroyed Output : None

This function cannot be used to destroy the foreground (focused) session

2.16 Int FEh I ' 13: Mouse Event Handler

Inputs : AX = 13

Output : None

2.17 Int FEh 114: New Graphics Mode

Inputs : AX = 14

Output : None

2.18 Int FEh 115: Enable/Disable Session Switching

Inputs: AX = 15

EBX = 0 to enable session switching

EBX = 1 to disable session switching Output : None This function controls whether or not the user has the ability to switch sessions by pressing the session switch hot key

Disabling session switching with this function does not prevent a program from switching sessions with int FEh function 1 1

2.19 Int FEh I ' 16: Get Current Graphics Mode

Inputs: AX = 16

Output: AL = current graphics mode of the foreground session

BL = Dit field

Bit 0 = 1 iff there is a keyboard present

This function returns the current graphics mode of the foreground session (This is included in SNMP information )

2.20 Int FEh 117: Prepare for Admin

Inputs : AX = 17

Output : None .

Sessions are closed and XMS memory is returned to the free pool in preparation for a firmware upgrade requiπng all system memory to hold the new firmware image

2.21 Int FEh 118: Acquire Resources

Inputs: AX = 18

EBX = resource

0 - serial port 0

1 - serial port 1

2 - parallel port

3 - audio

4 - PC card 0

5 - PC card 1

6 - exclusion lock to perform terminal administration

7 - mass storage (flash memory or diskette drive)

ECX = time-out interval in system timer ticks (18.2Hz) (zero if there is no time-out) EDX = option bits

Bit 0 - set iff the kernel should display a dialog box to confirm the transfer of ownership after the time-out period expires Bit 1 - set iff the interrupts generated by the specified device should terminate power saving mode (for serial ports that are used for pointing devices) Bits 2-15 - unused; set to zero SI = 0 (DS:SI might be defined later to point to a string identifying the new owner of the resource, if the request succeeds) DI = 0 (ES:DI might be defined later to point to a buffer that will be filled with a string identifying the session that currently owns the requested resource (if any) (81 chars max, including zero terminator) EBP = acquisition handle (zero for new requests) Output: Carry = set iff the resource could not be acquired EBX = id of the session owning the requested resource, if it could not be acquired EBP = acquisition handle (zero if the request failed; unchanged for requests to extend the timeout for resources that have already been acquired; unique for successful new requests)

This function allocates resources for exclusive use by the calling process This will prevent improper operation caused by other processes trying to access the same device at the same time All processes that need to use any of the devices covered by this function must call this function pπor to using them (Access to the devices will not be disabled by the kernel, but processes will not be guaranteed exclusive access unless all processes follow this protocol )

Normally, resources that are acquired with this function must be returned when they are no longer needed, so that another process may use them Function 19 is used to return acquired resources If a session is destroyed, any resources that are owned by processes m that session will be automatically freed

A time-out can be specified m the CX register If an acquired resource's timeout expires and bit zero of DX is zero, that resource will be automatically freed If an acquired resource's timeout expires and bit zero of DX is one, then that resource will still be owned by the process that acquired it, but it will be transferable if another process requests it If another process attempts to acquire it, the kernel will display a message requesting confirmation that the resource should be transferred to the new process If the user approves, the acquisition will be granted, otherwise, it will fail, and there will be no change in the resource's status If an owning process frees a resource whose timeout has expired, the kernel will allocate that resource to the next requesting process without any user message

In the initial implementation, the kernel will have no capability of displaying messages If bit zero of DX is set, then a specified resource will be allocated with an infinite timeout

If a process acquires a resource with a timeout, then the acquisition function must be called again, repeatedly, in order to extend the timeout peπod if the resource is actively used For example, a process that is dπvmg a pπnter might acquire the parallel port resource with a timeout peπod of five minutes, so that the parallel port can be reallocated to another process if it is idle for more than five minutes However, if the oπginal process continues to use the pπnter, it must continue to call the acquisition function (with a five minute timeout) (with EBP set to the acquistion handle that was returned duπng the oπgmal resource request) to reset the timeout peπod back to five minutes The calling process should not call the acquisition function too frequently for performance reasons The pπntmg process, for example, would probably not want to call the acquisition function for every character

Resources that are known by GUI EXE to be required by an application for the entire duration of the application session's existence (e g , for the application's main communication channel) should be allocated by GUI EXE, rather than the application

Resource six, "exclusion lock to perform terminal administration", should be acquired by any program performing local or remote administration (configuration or firmware updates) for the duration of the operation

2.22 Int FEh 119: Free Resources

Inputs : AX = ^■■ 19

EBX = resource to free

0 - serial port 0

1 - serial port 1

2 - parallel port

3 - audio

4 - PC card 0

5 - PC card 1

6 - exclusion lock to perform terminal administration

EBP = acquisition handle that was returned by function IE when the resource was acquired Output: None. This function frees resources allocated by function 18. Specified resources that are not allocated, or that have already been freed, or that are allocated to a different process will not be affected

2.23 Int FEh 120: Post Thread Message

Inputs : AX 20

EBX = session that is to receive the message

(zero for broadcast to all sessions) ECX = message ID

0-3FFh system-defined messages 400h-7FFFh private window classes 8000h-BFFFh private messages COOOh-FFFFh messages registered by

RegisterWmdowMessage EDX first message parameter ESI = second message parameter

Output : None .

This function transmits a message to another session using the Win32 PostThreadMessage function

** following message ids are used by Wιnterm2000 currently *" message id meaning 1 message parameter 2" message parameter ABCOh A permanent DHCP lease is obtained form Network interface id N/A

DHCP server; new network configurations (0=NI_TOKENRING, are stored in option.ini file 1=NI_ETHERNET)

ABClh Request to shutdown the terminal bitO set if show warning N/A message for user bitl set if reboot πght after shutdown

ABC2h Initialize the COM port 0=COM1 N/A l=COM2

ABC3h Request to destroy all application sessions N/A N/A

(I e., all sessions except for the GUI session and the network session) in preparation for remote administration (sent by NETADMIN.EXE to GUI.EXE)

ABC4h Notify GUI that an application session using Session Id of the Error code , specifying

TCP protocol has lost contact with the peer application session what type of network host due to network eπor (sent by error TCPIP.EXE to GUI.EXE)

ABDOh Acknowledgment for ABC3h (sent by N/A N/A

GUI.EXE to NETADMIN.EXE after the request has been processed)

ABD 1 h Acknowledgment for ABC4h (sent by Session Id of the N/A

GUI.EXE to TCPIP.EXE after the request application session being has been processed, i.e an application closed session was closed due to the error reported by message ABC4h)

2.24 Int FEh 121: Get Message

Inputs : AX = 21 Output : Carry = set iff there is no message to retrieve

ECX = message ID

EDX = first message parameter ESI = second message parameter

This function checks the message queue, and, if there are any messages, retrieves the next message m the queue If there are no messages, the function returns with the carry flag set

2.25 Int FEh I 22: Get System Info

Inputs : AX = 22

Output : AL = currently selected keyboard language .

2.24 Int FFh: Boot Block Services

Interrupt FFh functions are passed on to the boot block's service handler A function number is passed in the AX register Functions are documented m the boot block documentation

3 INTERRUPTS

Because the kernel runs in protected mode, all interrupts are received by the kernel. Depending on which interrupt is received, an interrupt will either be processed by the kernel or converted to a DOS interrupt that is issued in a virtual mode session that has a handler for a session.

It is possible to configure a session so that it will not receive a time slice from the CPU by cleaπng bit one of the session's creation flags. However, this will not affect interrupt processing within such a session. The session will still receive CPU time to process interrupts.

3.1 System Timer

The system timer interrupt occurs 18 2 times every second When it occurs, the kernel issues a timer interrupt (interrupt 8) in every session.

Each session will have its own BIOS timer interrupt handler that will increment the tick count m the BIOS data area (virtual mode address 40h.6Ch). DOS applications are free to redirect the timer interrupt by wπtmg to the virtual mode interrupt table, just as they normally would.

Because the interrupt controller is currently not virtua zed (i.e , we do not intercept a virtual mode session's port access to the interrupt controller and emulate a separate virtual interrupt controller for each session), the BIOS timer interrupt handler in each session does not issue an end-of-interrupt command to the interrupt. The kernel issues the end-of-interrupt, so there will be only one end-of-interrupt per physical hardware interrupt.

3.2 Network Interrupt

The ethernet controller generates a hardware interrupt on IRQ 10, or interrupt 72h. This interrupt is redirected to the DOS session hosting the network dπver.

3.3 Stack Interrupt

Applications issue interrupt 61h to request network stack operations Interrupt 61 h is redirected to the DOS session hosting the network stack.

Parameters to interrupt 61 h functions are passed in the registers Many of the functions require pointers to memory spaces within the calling application's memory address space For example, when calling a function to read network information, an application will include a pointer to a buffer where the data will be wπtten This buffer must be accessible to both the calling program and the network stack, which might be m different DOS sessions To facilitate this, the kernel maps the region of the calling program's memory address space containing the buffer into the network stack's address space in the DOOOOh-DFFFFh address range

Although the network stack supports multiple simultaneous network connections the network stack is not reentrant The kernel guarantees that the stack's reentrancy requirement will not be violated

3.4 Mouse Interrupt

The mouse requires one of the kernel's most complicated interrupt schemes IRQ 12h (interrupt 74h) is the hardware interrupt which the kernel picks up and sends to the virtual mode PS/2 BIOS handler in the 10 SYS that is in the session that holds the mouse dπver 10 SYS calls the event handler m the mouse dπver The mouse dπver calls the event handler in the kernel (Because the standard mouse dπver cannot "CALL" the kernel directly, it calls a vector 10 SYS, and IO SYS invokes the kernel's int FEh function 13 ) The kernel's mouse event handler takes care of moving the mouse on the screen (The virtual mode mouse dπver is instructed to make its mouse "invisible" ) Then the kernel invokes the event handler of the application running in the session that currently has focus (which might be different from the one containing the virtual mode mouse dπver, and different from the one that was executing when the interrupt occurred)

(There are additional mechanisms to set up all of these vectors, in the πght order )

Although some of the PS/2 BIOS code will be duplicated, this scheme will make it possible to have only one mouse dπver in memory, and the one dπver will service all sessions Furthermore, that one dπver can be a standard mouse dπver (i e , the PS/2 mouse dπver that we developed, the Microtouch dπver, the Elo touch dπver, or the light pen dπver)

4 DEVICE VIRTUALIZATION

APPENDIX B **************************************************************************

— the wbt3Connections group

The wyse enterprise (1.3.6.4.1.714)

Product Group (1.3.6.4.1.714.1)

ThinClient Group (1.3.6.4.1.714.1.2) wbt3 Group (1.3.6.4.1.714.1.2.3) wbt3Connections Group (1.3.6.4.1.714.1.2.3.13)

wbt3ConnectionsNum OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION

"The number of entries/connections in the connection table." : :={wbt3Connections 1} wbt3ConnectionsTable OBJECT-TYPE

SYNTAX SEQUENCE OF wbt3ConnectionsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A table of connections, number of entries is given by the value of wbt3ConnectionsNum. " : :={wbt3Connections 2} wbt3ConnectionsEntry OBJECT-TYPE

SYNTAX wbt3ConnectionsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A Unique name per table entry." INDEX {Index} : :={wbt3ConnectionsTable 1} wbt3ConnectionsEntry : : = SEQUENCE { wbt3ConnectionsIndex

INTEGER, wbt3ConnectionsName

DisplayString, wbt3ConnectionsType

INTEGER, wbt3ConnectionsEntryStatus INTEGER } wbt3ConnectionsIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION

"A unique value for the request entry. Its value ranges between 1 and the value of wbt3ConnectionsIndex. "

: :={wbt3ConnectionsEntry 1} wbt3ConnectιonsName OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Name of the connection." : :={wbt3ConnectionsEntry 2} wbt3ConnectionsType OBJECT-TYPE SYNTAX INTEGER {

RDP(O) ICA(l)

TEC (2) DialUp(3)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Type of the connection." : :=(wbt3ConnectionsEntry 3} wbt3ConnectionsEntryStatus OBJECT-TYPE SYNTAX INTEGER { active (1) notlnService (2 ) notReady (3) createAndGo (4) destroy ( 6) } ACCESS read-write STATUS mandatory DESCRIPTION

"active = edit this connection, destroy = delete this connection, createAndGo = Add a new connection, notReady = no connection define."

: :=(wbt3ConnectionsEntry 10}

wbt3RDPConnections OBJECT IDENTIFIER ::= {wbt3Connections 3}

— the wbt3RDPConnections Group

The wyse enterprise (1.3.6.4.1.714)

Product Group (1.3.6.4.1.714.1)

ThinClient Group (1.3.6.4.1.714.1.2) wbt3 Group (1.3.6.4.1.714.1.2.3) wbt3RDPConnections Group (1.3.6.4.1.714.1.2.3.13.3) ******+**+*+****+**********++****+*+*********+****++*+*+******************** wbt3RDPConnTable OBJECT-TYPE

SYNTAX SEQUENCE OF wbt3RDPConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table of connections, number of entries is the number of entries in wbt3ConnectionTable which has wbt3ConnectionType=RDP . " : :={wbt3RDPConnections 1} wbt3RDPConnEntry OBJECT-TYPE

SYNTAX wbt3RDPConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A Unique RDP connection configuration entry." : :=(wbt3RDPConnTable 1} wbt3RDPConnEntry : := SEQUENCE ^• { wbt3RDPConnName

DisplayString, wbt3RDPConnServer

DisplayString, wbt3RDPConnLowSpeed

INTEGER, wbt3RDPConnAutoLogon

INTEGER, wbt3RDPConnUsername DisplayString, wbt3RDPConnDomain

DisplayString, wbt3RDPConnStartApplication

INTEGER, wbt3RDPConnFilename DisplayString, wbt3RDPConnWorkingDir DisplayString } wbt3RDPConnName OBJECT-TYPE

SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION

"A unique name for the RDP configuration entry." : :={wbt3RDPConnEntry 1} wbt3RDPConnServer OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Host server name or IP address the RDP Client connects to.¹ : :={wbt3RDPConnEntry 2} wbt3RDPConnLowSpeed OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l)

} ACCESS read-write STATUS mandatory DESCRIPTION "Using low speed connection." : :={wbt3RDPConnEntry 3} wbt3RDPConnAutoLogon OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Enable RDP automatic logon." : :={wbt3RDPConnEntry 4} wbt3RDPConnUsername OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Specify the user name to atomatically logon to host." : :={wbt3RDPConnEntry 5} wbt3RDPConnDomain OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Domain name of host server." : :={wbt3RDPConnEntry 7} wbt3RDPConnStartApplication OBJECT-TYPE SYNTAX INTEGER {

Desktop (0) Filename (2)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Select application starts up at connection.

0 = Desktop, 2 = select File name radio button." : :={wbt3RDPConnEntry 8} wbt3RDPConnFilename OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Name of the application to start." : :={wbt3RDPConnEntry 9} wbt3RDPConnWorkingDir OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Application working directory." : :={wbt3RDPConnEntry 10} wbt3ICAConnections OBJECT IDENTIFIER ::= { wbt3Connections 4}

— the wbt3ICAConnections Group

The wyse enterprise (1.3.6.4.1.714)

Product Group (1.3.6.4.1.714.1)

ThinClient Group (1.3.6.4.1.714.1.2) wbt3 Group (1.3.6.4.1.714.1.2.3) wbt3ICAConnections Group (1.3.6.4.1.714.1.2.3.13.4) *****************+***+***+*++***********+*+**+**+***+*+*+******+************ wbt3ICAConnTable OBJECT-TYPE

SYNTAX SEQUENCE OF wbt3ICAConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A table of connections, number of entries is the number of entries in wbt3ConnectionTable which has wbt3ConnectionType=ICA. " : :={wbt3ICAConnections 1} wbt3ICAConnEntry OBJECT-TYPE

SYNTAX wbt3ICAConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A Unique ICA connection configuration entry." : :={wbt3ICAConnTable 1} wbt3ICAConnEntry ::= SEQUENCE { wbt31CAConnNa e

DisplayString, wbt3ICAConnCommType

INTEGER, wbt3ICAConnServer

DisplayString, wbt3ICAConnCommandLine DisplayString, wbt3ICAConnWorkingDir

DisplayString, wbt3ICAConnUsername

DisplayString, wbt3ICAConnDomain DisplayString, wbt3ICAConnColors INTEGER, wbt3ICAConnDataCompress

INTEGER, wbt3ICAConnSoundQuality

INTEGER } wbt3ICAConnName OBJECT-TYPE

SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION

"A unique name for the ICA configuration entry." : :={wbt3ICAConnEntry 1} wbt3ICAConnCommType OBJECT-TYPE SYNTAX INTEGER {

Network(O)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Communication port this connection uses." : :={wbt3ICAConnEntry 2} wbt3ICAConnServer OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"IP address or name of ICA server connect to." : :={wbt3ICAConnEntry 3} wbt3ICAConnCommandLine OBJECT-TYPE

SYNTAX DisplayString

ACCESS read-write

STATUS mandatory

DESCRIPTION

"Command line to be launched once this ICA connection is brought up"

: :={wbt3ICAConnEntry 4} wbt3ICAConnWorkingDir OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Working Directory to be used for this ICA" : :={wbt3ICAConnEntry 5} wbt3ICAConnUsername OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"User name to be used to log on to ICA server" : :={wbt3ICAConnEntry 6} wbt3ICAConnDomain OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Domain name to be used to log on to ICA server" : :={wbt3ICAConnEntry 8} wbt3ICAConnColors OBJECT-TYPE SYNTAX INTEGER {

16(0) 256(1) } ACCESS read-write STATUS mandatory DESCRIPTION ,

"Specify 16/256 window colors." : :={wbt3ICAConnEntry 9} wbt3ICAConnDataCompress OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Enable/Disable Data compression for this ICA session" : :={wbt3ICAConnEntry 10} wbt3ICAConnSoundQuality OBJECT-TYPE SYNTAX INTEGER {

None(0)

Low(l)

Medium (2)

Hig (3)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Set sound quality for this ICA session, None to disable sound" : :={wbt3ICAConnEntry 11}

wbt3TermConnections OBJECT IDENTIFIER ::= {wbt3Connections 5}

— the wbt3TermConnections Group

The wyse enterprise (1.3.6.4.1.714)

Product Group (1.3.6.4.1.714.1)

ThinClient Group (1.3.6.4.1.714.1.2) wbt3 Group (1.3.6.4.1.714.1.2.3) wbt3TermConnections Group (1.3.6.4.1.714.1.2.3.13.5) *********************************************+*+*******+******^ wbt3TermConnTable OBJECT-TYPE

SYNTAX SEQUENCE OF wbt3TermConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A table of connections, number of entries is the number of entries in wbt3ConnectionTable which has wbt3ConnectionType=TEC. " : :={wbt3TermConnections 1} wbt3TermConnEntry OBJECT-TYPE

SYNTAX wbt3TermConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

"A Unique terminal emulation connection configuration entry." : :={wbt3TermConnTable 1} wbt3TermConnEntry ::= SEQUENCE { wbt3TermConnName

DisplayString, wbt3TermConnCommType

INTEGER, wbt3TermConnServer DisplayString, wbt3TermConnEmuType

INTEGER, wbt3TermVTEmuModel

INTEGER, wbt3TermIBM3270EmuModel

INTEGER, wbt3TermIBM5250EmuModel

INTEGER, wbt3TermConnPortNumber DisplayString, wbt3TermConnTelnetName

DisplayString, wbt3TermConnPrinterPort

INTEGER, wbt3TermConnFormFeed

INTEGER, wbt3TermConnAutoLmeFeed

INTEGER

} wbt3TermConnName OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION

"A unique name for the Terminal Emulation configuration entry." : :={wbt3TermConnEntry 1} wbt3TermConnCommType OBJECT-TYPE SYNTAX INTEGER {

Network (0) } ACCESS read-write STATUS mandatory DESCRIPTION

"Communication port this connection uses." : :={wbt3TermConnEntry 2} wbt3TermConnServer OBJECT-TYPE

SYNTAX DisplayString

ACCESS read-write

STATUS mandatory

DESCRIPTION

"IP address or host name of terminal server connect to (valid only if wbt3ConnCommType '= Serial)."

: :={wbt3TermConnEntry 3} wbt3TermConnEmuType OBJECT-TYPE SYNTAX INTEGER {

VT52 ( 0 ) VTl OO ( l )

VT220 ( 2 )

VT400-7-Bit ( 3 )

VT400-8-Bit ( 4 )

Ansi-BBS ( 5 )

Sco-Console ( 6 )

IBM3270(7)

IBM315K8)

IBM5250(9)

WY50(10)

WY50+(11)

TVI910(12)

TVI920(13)

TVI925(14)

ADDS-A2(15)

HZ1500(16)

WY60(17)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Emulation mode for this connection. : :={wbt3TermConnEntry 4} wbt3TermConnVTEmuModel OBJECT-TYPE SYNTAX INTEGER (

VT100(0)

VTlOl(l)

VT102(2)

VT125(3)

VT220(4)

VT240(5)

VT320(6)

VT340(7)

VT420 (8)

VT13K9)

VT132(10)

Not-Applicable (256)

}

ACCESS read-write STATUS mandatory DESCRIPTION

"Terminal model uses for this connection. This field represents the VT Terminal ID. : :={wbt3TermConnEntry 5} wbt3TermConnIBM3270EmuModel OBJECT-TYPE

SYNTAX INTEGER {

IBM3278-2(0)

IBM3278-3(1)

IBM3278-4 (2)

IBM3278-5(3)

IBM3278-2-E(4)

IBM3278-3-E(5)

IBM3278-4-E(6)

IBM3278-5-E(7) IBM3279-2(8)

IBM3279-3(9)

IBM3279-4 (10)

IBM3279-5(11)

IBM3287-K12)

Not-Applicable (256)

} ACCESS read-write STATUS mandatory DESCRIPTION

"IBM 3270 terminal emulation models.

This object only valid for wbt3TermConnEmuType

IBM3270"

={wbt3TermConnEntry 6} wbt3TermConnIBM5250EmuModel OBJECT-TYPE SYNTAX INTEGER {

IBM5291-K0)

IBM5292-2(1)

IBM5251-1K2)

IBM3179-2 (3)

IBM3196-AK4)

IBM3180-2(5)

IBM3477-FC(6)

IBM3477-FG(7)

IBM3486-BA(8)

IBM3487-HAO)

IBM3487-HC(10)

Not-Applicable (256)

} ACCESS read-write STATUS mandatory DESCRIPTION

"IBM 5250 terminal emulation models.

This object only valid for wbt3TermConnEmuType

IBM5250"

:={wbt3TermConnEntry 7} wbt3TermConnPortNumber OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-write STATUS mandatory DESCRIPTION

"Telnet port number for this connection." : :={wbt3TermConnEntry 10} wbt3TermConnTelnetName OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Name of this telnet session." : :={wbt3TermConnEntry 11} wbt3TermConnPrinterPort OBJECT-TYPE SYNTAX INTEGER {

LPTl(O) } ACCESS read-write STATUS mandatory DESCRIPTION

"Printer port for this connection." : :=(wbt3TermConnEntry 12} wbt3TermConnFormFeed OBJECT-TYPE SYNTAX INTEGER (

No(0)

Yes(l)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Use Form Feed terminator for printing." : :={wbt3TermConnEntry 13} wbt3TermConnAutoLineFeed OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Use Auto line Feed for printing." : :={wbt3TermConnEntry 14} wbt3TermConnScript OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Srcipt for this terminal emulation. Script syntax: Use back slash (\) to separate between 2 script commands , each script command has 2 entries (Act on and Send) , Use semi column ( ; ) to separate 2 entries. Samples: Login; <CR> or

Login; <CRXD>\Username, <U> Send entry syntax: C. return = <CR> Delay (2s) = <D>

Line Feed = <LF>

Password = <PW> Pause (0.255) = <P> UserName = <UN>" : :={wbt3TermConnEntry 15}

******_**_***_***********_*********************_**_********_*****_**_**

— the wbt3Users Group

The wyse enterprise (1.3.6.4.1.714)

Product Group (1.3.6.4.1.714.1)

ThinClient Group (1.3.6.4.1.714.1.2) wbt3 Group (1.3.6.4.1.714.1.2.3) wbt3Administration Group (1.3.6.4.1.714.1.2.3.8) wbt3Users Group (1.3.6.4.1.714.1.2.3.8.14)

— Implementation of the wbt3UpDnLoad Group is mandatory for all ThinClient2

— products with SNMP agents which supports the wyse MIB ***_********_*****************_**************_***********_**********_************* wbt3UsersNum OBJECT-TYPE

SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION

"The number of entries in the Users table' : :={wbt3Users 1 } wbt3UsersTable OBJECT-TYPE

SYNTAX SEQUENCE OF wbt3UsersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

: :={wbt3Users 2} wbt3UsersEntry OBJECT-TYPE

SYNTAX wbt3UsersEntry ACCESS not-accessible STATUS mandatory DESCRIPTION

INDEX {wbt3UsersIndex} : :={wbt3UsersTable 1} wbt3UsersEntry : := SEQUENCE ( wbt3UsersIndex INTEGER, wbt3UsersStatus

INTEGER, wbt3userName DisplayString, wbt3privilege INTEGER, wbt3password DisplayString, wbt3AutoConnect

INTEGER, wbt3Connectionl DisplayString, wbt3Connection2 DisplayString, wbt3Connection3 DisplayString, wbt3Connection4 DisplayString, wbt3Connection5 DisplayString, wbt3Connection6 DisplayString, wbt3Connection7 DisplayString, wbt3Connection8 DisplayString } wbt3UsersIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION

: :={wbt3UsersEntry 1} wbt3UsersStatus OBJECT-TYPE SYNTAX INTEGER ( active (1) notlnService (2 ) notReady (3) createAndGo (4) destroy ( 6) }

ACCESS read-write STATUS mandatory DESCRIPTION "The status of this user account: active: this user account is ready and can be changed, destroy: to delete this user account. createAndGo: to create a new user account. notReady: this user account is not defined." :={wbt3UsersEntry 2} wbt3userName OBJECT-TYPE

SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"Name of this user." : :={wbt3UsersEntry 3} wbt3password OBJECT-TYPE

SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The password defined by the user" : :={wbt3UsersEntry 4} wbt3privilege OBJECT-TYPE SYNTAX INTEGER {

Admin ( 0 ) User(l) Guest (2)

} ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates whether the user has extended, normal, or restricted rights on this terminal." : :={wbt3UsersEntry 5} wbt3AutoStart OBJECT-TYPE

SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Indicates this user has at least one connection with autostart enabled. "

: :={wbt3UsersEntry 6} wbt3Connectιonl OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name." : :={wbt3UsersEntry 7} wbt3Connectιon2 OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name." : :={wbt3UsersEntry 8} wbt3Connectιon3 OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name." : :={wbt3UsersEntry 9} wbt3Connectιon4 OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name." : :={wbt3UsersEntry 10} wbt3Connectιon5 OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name." : :={wbt3UsersEntry 11} wbt3Connectιon6 OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name." : :={wbt3UsersEntry 12} wbt3Connectιon7 OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name." : :={wbt3UsersEntry 13} wbt3Connection8 OBJECT-TYPE SYNTAX DisplayString ACCESS read-write STATUS mandatory DESCRIPTION

"The connection associates with the user name. : :={wbt3UsersEntry 14} wbt3AutoStartl OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connectionl . "

: :={wbt3UsersEntry 15} wbt3AutoStart2 OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connection2. "

: :={wbt3UsersEntry 16} wbt3AutoStart3 OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connection3. "

: :={wbt3UsersEntry 17} wbt3AutoStart4 OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connection4. "

: :={wbt3UsersEntry 18} wbt3AutoStart5 OBJECT-TYPE SYNTAX INTEGER { No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connection5. "

: :={wbt3UsersEntry 19} wbt3AutoStartδ OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connection6. "

: :={wbt3UsersEntry 20} wbt3AutoStart7 OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connection7. "

: :={wbt3UsersEntry 21} wbt3AutoStart8 OBJECT-TYPE SYNTAX INTEGER {

No(0) Yes(l) } ACCESS read-write STATUS mandatory DESCRIPTION

"Indicates this user has autostart enabled with the wbt3Connection8. "

: :={wbt3UsersEntry 22} ****************_***********_****************_***_*****_************************* _{*** TRA S ***} ************************_****_***********_************************************* wbt3TrapDHCPBuildMismatch TRAP-TYPE ENTERPRISE wbt3

VARIABLES { wbt3CurBuildNum, wbt3CurOEMBuildNum, wbt3CurModBuildDate, wbt3DUpBuildNum, wbt3DUpOEMBuildNum, wbt3DUpOEMBuildDate} DESCRIPTION

"Firmware build number mismatch according to information supplied by DHCP server." : : = 1 wbt3TrapDHCPUpdDone TRAP-TYPE ENTERPRISE wbt3

VARIABLES { wbt3CurBuildNum, wbt3CurOEMBuildNum, wbt3CurModBuildDate, wbt3DUpBuildNum, wbt3DUpOEMBuildNum, wbt3DUpOEMBuildDate } DESCRIPTION

"Firmware upgrade initiated due to build number mismatch according to DHCP information is done." : := 2 wbt3TrapDHCPUpdNotComplete TRAP-TYPE ENTERPRISE wbt3

VARIABLES { wbt3CurBuildNum, wbt3CurOEMBuildNum, wbt3CurModBuildDate, wbt3DUpBuildNum, wbt3DUpOEMBuildNum, wbt3DUpOEMBuildDate, wbt3TrapStatus} DESCRIPTION

"Firmware upgrade initiated due to build number mismatch according to DHCP information is not completed for some reason." : := 3 wbt3TrapSNMPAccptLd TRAP-TYPE ENTERPRISE wbt3

VARIABLES { wbt3SubmitLoadJob } DESCRIPTION

"Ready to accept up/download request initiated by SNMP manager." : := 4 wbt3TrapSNMPLdDone TRAP-TYPE ENTERPRISE wbt3 VARIABLES { wbt3TrapReqId } DESCRIPTION

"SNMP initiated up/download request is done." : := 5 wbt3TrapSNMPLdNotComplete TRAP-TYPE ENTERPRISE wbt3

VARIABLES { wbt3TrapReqId, wbt3TrapStatus } DESCRIPTION

"SNMP initiated up/download request is not completed for some reason. : := 6 wbt3TrapRebootNotComplete TRAP-TYPE ENTERPRISE wbt3 VARIABLES { wbt3TrapStatus } DESCRIPTION

"SNMP initiated reboot request is not completed for some reason." : := 7

END

Claims

We claim:

1. A terminal for displaying application program information in a windowing environment comprising: processing means, not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally, adapted to receive windowing information supplied by programs executing on a remotely located application server, display means for displaying the windowing information supplied by programs executing on the remotely located application server; file transfer means for transferring file information to and from the terminal using a communications protocol.

2. The terminal of Claim 1 wherein the file transfers means transfers one or more image upgrades to the terminal from the remotely located application server.

3. The terminal of Claim 1 wherein the file transfer means transfers configuration data to the terminal from the remotely located application server.

4. The terminal of Claim 1 wherein the terminal further includes download means for automated downloading one or more images to the terminal through a network link between the processing means and the display means after the terminal has been assigned an Internet Protocol address.

5. The terminal of Claim 4 wherein a Dynamic Host Configuration Protocol assigns the

Internet Protocol address.

6. The terminal of Claim 4 wherein the download means includes: means for determining the path from a base directory of the remotely located server to the terminal, the server retaining the control, base-image files, and option image files are retained; means for downloading appropriate files to the terminal; means for updating a boot block file and non-volatile memory in the terminal; and means for automatically rebooting the terminal after updating.

7. The_. terminal of Claim 1 wherein the terminal further includes: means for providing configuration settings for the terminal using simple network management protocol.

8. The terminal of Claim 1 wherein the terminal further includes: means for providing an interactive or automated downloading of an image through a network using simple network management protocol.

9. The terminal of Claim 1 wherein the terminal further includes: means for creating or modifying binaries in the remotely located server with customized configurations from a tool kit; and means for downloading the binaries to the display means via parallel, serial, flash card paths or an automated or interactive transfer using a communications protocol.

10. The terminal of Claim 1 wherein the terminal further includes: means for merging automated configuration file and workspace images.

11. The terminal of Claim 1 wherein the terminal further includes: administrating the configuration settings of the terminal from the remotely located server using a communications protocol.

12. The terminal of Claim 1 wherein the communications protocol includes protocols selected from the group consisting of: file transfer protocol (FTP), dynamic host configuration protocol (DHCP), and small network management protocol (SNMP).

13. The terminal of Claim 1 wherein the terminal further includes means for supporting SNMP traps.

14. The terminal of Claim 1 wherein the terminal further includes: means for providing configuration settings for the terminal using a Management Information Base located on the remotely located server.

15. A utility for displaying application program information in a windowing environment on a terminal having a processor, not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally, and a remotely located application server executing programs which supply the windowing information, the terminal having a display configured for displaying the windowing information, the utility comprising; file transfer means for transferring file information to and from the terminal using a communications protocol.

16. The utility of Claim 15 wherein the file transfers means transfers one or more image upgrades to the terminal from the remotely located application server.

17. The utility of Claim 15 wherein the file transfer means transfers configuration data to the terminal from the remotely located application server.

18. The utility of Claim 15 wherein the terminal further includes download means for automated downloading one or more images to the terminal through a network link between the processing means and the display means after the terminal has been assigned an Internet Protocol address.

19. The utility of Claim 15 wherein the terminal further includes: means for providing configuration settings for the terminal using simple network management protocol.

20. The utility of Claim 15 wherein the terminal further includes: means for creating or modifying binaries in the remotely located server with customized configurations from a tool kit; and means for downloading the binaries to the display means via parallel, serial, flash card paths or an automated or interactive transfer using a communications protocol.

21. The utility of Claim 15 wherein the terminal further includes: means for providing configuration settings for the terminal using a Management Information Base located on the remotely located server.

22. A method for displaying application program information in a windowing environment, the steps of the method comprising: sending windowing information supplied by programs executing on a remotely located application server to a terminal not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally; displaying the windowing information supplied by programs executing on the remotely located application server; and transferring file information to and from the terminal using a communications protocol.

23. The method of Claim 22 wherein the transferring step includes transferring one or more image upgrades to the terminal from the remotely located application server.

24. The method of Claim 22 wherein the transferring step includes transferring configuration data to the terminal from the remotely located application server.

25. The method of Claim 22 wherein the method includes the steps of: assigning the terminal an Internet Protocol address; and subsequently automatically downloading one or more images to the terminal through a network link between terminal and the display means.

26. The method of Claim 22 wherein the transferring step includes: providing configuration settings for the terminal using simple network management protocol.

27. The method of Claim 22 wherein the method includes the steps of: creating or modifying binaries in the remotely located server with customized configurations from a tool kit; and downloading the binaries to the display means via parallel, serial, flash card paths or an automated or interactive transfer using a communications protocol.

28. The method of Claim 22 wherein the method includes the step of: providing configuration settings for the terminal using a Management Information Base located on the remotely located server.

29. A terminal for displaying application program information in a windowing environment comprising: processing means, not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally, adapted to receive windowing information supplied by programs executing on a remotely located application server, display means for displaying the windowing information supplied by programs executing on the remotely located application server; means for simultaneously maintaining more than one connection between the terminal and server.

30. The terminal of Claim 29 wherein the multiple connection means includes: means for establishing more than one virtual machine on the terminal, each virtual machine running an open session.

31. The terminal of Claim 29 wherein the terminal having a foreground and background area and the multiple connection means includes: means for stopping and redisplaying the writing of a screen when a session is moved to the background without saving the screen in memory.

32. The terminal of Claim 30 wherein the multiple connection means further includes: each virtual machine has a text buffer so when the virtual machine is in the background it has a virtual buffer that it can write to and it continues to run in the background; each virtual machine sends a signal to a graphics application, the application sends a signal out to the server to command it to stop sending display when the application is switched to the background so that traffic relating to the graphics application between the terminal and server is stopped, the server is commanded to redisplay the screen when the application is switched back to the foreground.

33. The terminal of Claim 30 the multiple connection means further includes: each virtual machine stops sending and receiving data to and from the server when an application resides in the background session, each virtual machine commanding the server to refresh the data for the application when the application is switched to the foreground.

34. A utility for displaying application program information in a windowing environment on a terminal having a processor, not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally, and a remotely located application server executing programs which supply the windowing information, the terminal having a display configured for displaying the windowing information, the utility comprising: means for simultaneously maintaining more than one connection between the terminal and server.

35. The utility of Claim 29 wherein the multiple connections means includes: means for establishing more than one virtual machine on the terminal, each virtual machine running an open session.

36. The utility of Claim 29 wherein the terminal having a foreground and background area and the multiple connections means includes: means for stopping and redisplaying the writing of a screen when a session is moved to the background without saving the screen in memory.

37. The utility of Claim 30 wherein the multiple connections means further includes: each virtual machine has a text buffer so when the virtual machine is in the background it has a virtual buffer that it can write to and it continues to run in the background; each virtual machine sends a signal to a graphics application, the application sends a signal out to the server to command it to stop sending display when the application is switched to the background so traffic relating to the graphics application between the terminal and server is stopped, the server is commanded to redisplay the screen when the application is switched back to the foreground.

38. The utility of Claim 30 the multiple connection means further includes: each virtual machine stops sending and receiving data to and from the server when an application resides in the background session, each virtual machine commanding the server to refresh the data for the application when the application is switched to the foreground.

39. A method for displaying application program information in a windowing environment comprising the steps of: sending windowing information supplied by programs executing on a remotely located application server to a terminal not fully compatible with personal computer BIOS or disk operating systems and incapable of executing windowing applications locally; displaying the windowing information supplied by programs executing on the remotely located application server; simultaneously maintaining more than one connection between the terminal and server.

40. The method of Claim 39 wherein the multiple connecting step includes: establishing more than one virtual machine on the terminal, each virtual machine running an open session.

41. The method of Claim 39 wherein the terminal having a foreground and background area and the multiple connecting step includes: stopping and redisplaying the writing of a screen when a session is moved to the background without saving the screen in memory.

42. The method of Claim 40 wherein the multiple connecting step further includes: providing each virtual machine a text buffer so when the virtual machine is in the background it has a virtual buffer that it can write to and it continues to run in the background; sending a signal from each virtual machine to a graphics application; sending a signal from the application out to the server to command it to stop sending display when the application is switched to the background so traffic relating to the graphics application between the terminal and server is stopped; commanding the server to redisplay the screen when the application is switched back to the foreground.

43. The method of Claim 40 wherein the multiple connecting step further includes: sending and receiving data from each virtual machine to and from the server when an application resides in the background session; commanding the server from each virtual machine to refresh the data for the application when the application is switched to the foreground.