Note: Descriptions are shown in the official language in which they were submitted.
CA 02440825 2003-09-19
sJ
10
15
20
25
Field of the Invention
The present invention relates generally to methods and apparatus for
30 displaying information on a terminal, and more particularly relates to
methods
and apparata for formatting and displaying, on a terminal, graphical user
interfaces such as the Microsofit Windows operating environment and
applications programs within such environments.
CA 02440825 2003-09-19
2 l 959f'
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
5 because of ease of use, uniformity of use. interface, high quality display,
as well
as other reasons.
However, such user environments were designed for use with
vvorkstations and microcomputers such as personal computers. Such
workstations and microcomputers, while flexible, present difficulties with
10 security, reliability, ease of administration, ~snd value. While data
terminals are
known to offer the advantages of improved security and ease of administration
relative to microcomputers, and 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
l 5 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, diskiess
PCS offer severs! deficiencies. !n most instances, diskless PCS operating in a
20 client server erjvironment display application program information by
downloading tine application from the server and executing the application
focally. This requires the diskless PC fio have t-vhatever processing power is
required for each application it attempts to exeo.ute. In today's environment,
this
can require eight or more megabytes of memory, a powerful processor, and so
25 on -- making a diskless PC expensive. !n addiiion, diskless PCS offer
limited
security and can require extensive administration.
The V'Jindows~' NT operating system provides a robust network
client/server environment, while at the same time offering compatibility at
the
applications program lave! with the popular'Nindows"~ environment. However,
30 the NT operating system was written for PC clients, and not terminals. As a
CA 02440825 2005-05-12
3
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
1
multiuser environment. The WinFrame operating system, recently offered by
Citrix Systems, lnc., modifies the Windows NT operating system by extending it
to operate in a multiuser environment, although the prior art application for
WinFrame has been PCS clients as opposed to terminals.
There has therefore been a need for a terminal which 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
According to a first aspect of the present invention there i~ provided a
method for configuring a terminal having a display for communication with a
host
system comprising: establishing at least one bit-mapped area within a portion
of
the display, establishing within the area at least one bit-mapped group
comprising
operating environment information of the terminal, and establishing at least
one
bit-mapped select within the group, each select having one or more choices
associated therewith.
According to a second aspect of the present invention there is provided
a method for configuring a terminal having a display for communication with a
host
system comprising: establishing at least one bit-mapped area within a portion
of
the display, establishing at least one bit-mapped group within the area,
establishing at least one bit-mapped select within the group, each select
having
one or more choices associated therewith, and communicating with a memory
information displayed in the bit-mapped portions of the display.
The present invention may be applied to 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 WinframeT"" operating system provided by Citrix
Systems, Inc. The WinframeT"" operating system incorporates the Windows NT
operating system plus extensions implementing a display protocol known as ICA-
3
as well as multi-user capabilities.
The terminal may include, in an exemplary embodiment, a hardware
architecture based on the Intel X86 processor line. In addition, the terminal
offers
CA 02440825 2005-05-12
3a
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 is distinctly different from the prior art X terminals or
diskless
PCS, or other PCS configured in a client/server
._
CA 02440825 2005-05-12
' ' 4
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 either monochrome (including grayscale) or
color, as well as input/output devices typical of the Windows environment such
1
as mouse, keyboard, touchscreen and other I/O services:
1
In additional, 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
1 5 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
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.
One feature of the terminal is the availability of client-
independent computing within a Windows environment. Thus, with a system
according to the present invention, a user defines his operating environment
and
that environment follows him or her throughout the system. A user could
therefore log onto one terminal, define an environment, and then log onto
another terminal. That second terminal would automatically display the
environment defined by that user at the first terminal.
CA 02440825 2005-05-12
The terminal may have a setup mode which permits the user to configure
a variety of operating aspects of the terminal.
The present invention may implement a graphical user interface for
configuration of a terminal and other locally managed tasks. In particular,
the
5 graphical interface employs a plurality of windows and each window permits
reconfiguration of one or more terminal characteristics or other local tasks.
Arranged in groups within each window are the selects which can be configured
within that window. These selects, or choices, from which the user may select
are
displayed, or displayable through a pull-down or similar menu. Various data
structures are associated with differing types of groups and selects.
To enable terminals to comply with commands sent.by servers such as
those running WinFrame, a special purpose terminal operating system has been
developed which either emulates or otherwise responds to the calls to a
conventional PC operating system. The terminal operating system includes a
boot
block to initialize and, start the system, followed by a kernel which loads
additional
drivers and command software, including loading modified WinFrame client code.
Execution of the modified WinFrame client includes making a connection to an
applications server.
CA 02440825 2005-05-12
6
The present invention may be better appreciated from the following
Detailed Description given by way of non-limitative example with reference to
the
accompanying Figures, in which:
Brief Description of the DrawinrJs
Figure 1 shows a generalised arrangement of an application server and
a terminal.
Figure 2 shows in functional block diagram form the architecture of the
logic of the terminal of Fig.1.
CA 02440825 2003-09-19
6a
and for emulating one of the second and fourth sets of instructions, to
provide to the
associated host system responses compatible uvith the communications protocol
associated with that host system, and switching means for identifying the host
system to
which the terminal is currently connected and selecting the appropriate one of
the first and
at least the second personalities for communications with the identified host
system.
In accordance with a third aspect of the present invention there is provided a
terminal for displaying, in the Microsoft Windows F~ operating environment,
application
pr ogram information provided by a host system running a Microsoft V1lindows~
operating
systems comprising: interface means for receiving from the application server
display
information for an application program operating on the application server,
processing
means, not fully compatible with personal computer hiOS or disk operating
systems and
incapable of executing the application program locally, responsive to the
interface means
for either emulating or processing instructions supplied by programs executing
on a
rernotely located application server to provide to the host system responses
compatible
with those expected by the host system, display means responsive to the
processing
means for displaying the windowing information.
The above objects and summary of the present invention may be better
appreciated
from the following Detailed Description of the Invention tarcen in combination
with the
accompanying Figures.
2 0 Brief Description of the Drawincts
Figure 7 shows a generalized arrangement of an application server and a
terminal in accordance with the present invention.
Figure 2 shows in functional block diagram form the architecture of the logic
of
the present invention.
CA 02440825 2005-05-12
7
Figure 3 shows in block diagram form the architecture of the control ASIC
of Figure 2.
Figure 4 shows an overview of the software architecture of the terminal.
Figure 5 shows in simplified block diagram form the setup interface
between the GUI Engine and the remainder of the system.
Figure 6 shows in flow chart form a top level view of the process by which
the terminal connects to an application server.
Figure 7A shows a setup screen from the configuration software which
implements the present invention.
Figures 7B1-7B3 show the data structures associated with the
configuration software.
Detailed Description of the Invention
Figure 1 shows a simplified system to ~ivhich the present invention
may be applied. In particular, a single application server 10
communicates bidirectionally with one or a plurality of terminals 12 over a
suitable network or other communications link 14. The network link may be an
RS232 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 a
exemplary
arrangement which has been determined to operate satisfactorily, the
application
server is running an operating systern such as Windows NT~ with appropriate
extensions, such as those offered by Citrix as the Winframe OS. Tl~e Citrix
remote windows protocol or extensions include the ICA 3.0 protocol as well as
enhancements which 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 ~48G prOCesJOr 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 uxan~plary
configuration, the server may have sixteen megabytes of RAM for Winframe'"
CA 02440825 2005-05-12
8
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 1 G, 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.
Referring next to Figure 2, the hardware architecture of a terminal
may be better appreciated. In particular, . _
a CPU 100, typically a microprocessor of the X86 family and in an exemplary
embodiment an 80386CXSA or '486SXLC microprocessor, receives clock and
reset signals from clock and reset logic 102. The CPU communicates with the
remaining logic via an address bus 105, a data bus 106 and a CTRL bus 108.
Importantly, the buses 105, 106 and 108 are typically not compatible with the
IBM PC/AT standard, nor any other personal computer standard, since the
present invention is intended to avoid many, if not all, of the pitfalls
associated
with personal computers operating in a networked environment.
In particular, the address bus 105 extends from the CPU 100 to a control
ASIC 110, as well as a flash memory array 112 and a VGA controller 1 14. The
data bus 106 likewise communicates with the control ASIC 110, the VGA
controller 1 14, and a memory array 116. The CTRL bus 108 similarly provides
control signals to the ASIC 110 and the VGA controller 1 14. Miscellaneous
logic
1 18 provides CONFIG, IDCS and DIAGCS to the ASIC 110.
The ASIC 110 communicates with the memory array 1 16 via a DMA bus
120, and also communicates with the flash memory 1 12 via a PD bus 122. Tire
PD bus 122 also provides communication between the ASIC 1 10 and the tlasl~
memory 112, a serial l/0 and parallel controller 124, a keyboard and mouse
controller 126, as well as a LAN controller 1 28. In addition, the ASIC
provides
an FCS signal to the flash memory 1 12, provides RAS, CAS and WE signals to
CA 02440825 2003-09-19
~' cy~~.~h
the memory array 116, and provides COM1, COM2, and PPCS signals to the SIO
controller 124. Further, the ASIC 110 provides a KSCS signal to the
keyboardlmouse controller 126, and provides an NETCS signal to the LAN
controller 128. Finally, the ASiC provides a speaker enable signal SPEN to a
5 speaker 130.
The CPU 100 also communicates with the S10 controller 124, the
keyboardl mouse controller 126, and the L.AN controller 128 via a portion of
the
bus 105. In addition, the ASIC i 10 provides hardware interrupts INTA, INTB
and INTP to the SIO controller, provides hardware interrupts KBINT and MSIN'f
10 to tine KBIMS controller 12n, and provides hardware interrupt NINT to the
LAN
controller 128.
The memory array 1 16 is typically comprised of DRAM memory, although
other types of memory may be acceptable in some embodiments. However,
unlike modern personal computers, the amount of DRAM in the array 116
1 5 required foe operation of the terminal typically will be within the range
of 512 KB
to four megabytes. In an exemplary embodiment, only 23 memory address lines
and a byte select line are used, which limits the memory space to 16 MB. In
other embodiments different sizes of memory space may be preferred.
The Control ASIC 1 10, in an exemplary embodiment, contains f unctional
20 blocks for bus control, DRAM control (typical fast page mode with
interleave),
a system timer and speaker timer, and an I/0 controller. The Control ASIC may
also be implemented as a gate array or oi;her highly integrated device, and is
described in greater detail in connection with Figure 3.
In an operating example, it has been shown sufficient to size the flash
25 memory 1 12 on the order of 512KB; ho~rrever, in other applications a size
of up
to five megabytes or more may be preferred. While in a preferred embodiment
the array 112 comprises flash memory, in some embodiments a substantial
functionality of the present invention would remain even if the array was of
EPROM and SRAM or other comparable memory devices.
30 The Si0 controller 124 communicates with COM1 , COM2 and printer (or
CA 02440825 2003-09-19
10 ;Jv9P
parallel) ports 132, l 34 and 136, r espectmeiy. T he Sl0/parallel controller
124
may be a 16552 device, such as that available from Startech. The
keyboard/mouse controller 126 similarly communicates with a keyboard 138 and
mouse 140, while the LAN controller, which need not be peovided in all
5 embodiments, communicates with a t~AI~ interface 142. In one exemplary
prototype, the keyboard/mouse controller 126 may be a standard keyboard
controller, while the keyboard and arouse will both comply with the PS/2
standard, although in at least some embodiments the keyboard controller wilt
be
modified to be compatible with the four-wise keyboard interface described in
U.S.
10 Patent No. 4,706,068. Pinaliy the LAN cor7troller may be any suitable
network
interface controller, and may comply with any accepted network standard,
including 10BaseT, 108ase2, and others. The network interface may have
512168 memory or more for additional code storage.
The video and graphics controller 1 ? 4 has operatively associated
1 5 therewith a second memory array 144 for storing video and graphics
information,
which is supplied to a monitor 146 via an MP S 148. The video controller 1 14
may be, for example, a Cirrus 5429 device with interns! RAMDAC, and may
have on the order of one megabyte of video merwory to provide high resolution
graphics displays compatible with, as an example, at least the Video Graphics
20 Array standard. It will be apparent to those skilled in the art that the
total
memory requirements are distinctly fens than for a personal computer having
similar capabilities to display Windows application programs. A sleep signal
150
may be provided from the A SIC 1 10. Various methods for implementing a sleep
signs! may be used. For example, in a monochrome version of the present
25 invention, a signs! is provided to the powor~ supply of the monitor, which
disables
the video signal and lowers the power required of the monitor power supply. In
a color version, the sync signals are mani>.7ulated in accordance with the
VESA
standard to cause the monitor to power down. !t will be apparent to those
skilled in the art that, in the future, numerous of these functions, including
the
30 CPU, may be incorporated into one or mare VLSI devices such as ASICs, gate
CA 02440825 2005-05-12
11
arrays, or other devices.
In a special feature of the hardware, the terminal
operating system stored in the flash memory 112 may be updated through a
variety of methods, including communication through a suitable interface such
as the parallel port 136, a serial port 132 or 134, or a network adapter
s~~clms
LAN interface 142. 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, such as by attaching a loopback plug, an appropriate
key sequence or other suitable means. In such an arrangement, downloading to
the terminal's memory system is enabled while still permitting communication
with the host. The host then provides, via the communications link, updated
operating characteristics either to the terminal's DRAM 1 16 or the flash
memory
1 12 directly. Thereafter, the updated operating system information is stored
in
the flash memory 112 if necessary, and the terminal is returned a normal
operating status in which downloading is disabled.
In normal conditions, the system of Figure 2 begins operation following a
reset by beginning execution of the boot code contained in the flash memory
array 112. The flash memory array 112 may be arranged in two banks, both of
which are accessed at a predetermined address of the CPU memory space, for
example C00000 - DFFFFF and E00000 - FFFFFF, while the remainder of the
memory space is allocated to provide many of the normal PC functions as shown
in Table 1, below. It will be apparent to those skilled in the art that, in an
exemplary embodiment, the videolgraphics memory addresses are shifted eight
megabytes beyond conventional PC memory addresses. In such an
embodiment, the VGA chip may be used in "compatible" mode (i.e., linear
addressing mode turned offl, so the VGA chip only responds to a frame buffer
at AOOOOh - AFFFFh (in graphics mode) or BOOOOh - B7FFFh (for MGA mode) or
B8000h - BBFFFh (for CGA mode), and that these addresses will be shifted to
8AOOOOh -8AFFFFh, and so on. The addresses have been shifted to permit
hank 0 DRAM to be contiguous, while at the same time (and as discussed
CA 02440825 2003-09-19
1 2 ~ c) r~ y E:a
heremafterl permitting functions sufficient
emulation of normal to permn
PC
display of Windows
application program
information.
FLASH BANK 0 FFFFFF
E00000
5 Boot Block Flash
FLASH BANK 1 DFFFFF
File System Flash C00000
Network . BFFFFF
Card 880000
10 ArJditional Flash B7FFFF
Memory 800000
Video/Craphics AFFFFF
Controller 800000
DRAM 7FFFFF
15 BANK 1 400000
DRAM
3FFFFF
BANK 0
000000
T~E3~.'B 'f
20 Bank 0 may be arranged into a 16K byte boot block at the upper address
range, for example FFC000H - FFFFFFH, following two eight Kbyte parameter
blocks, and further following a plurality of main blocks down to address
F80000H (for a 512KByte allocation) or down to F00000H (if a one megabyte
allocation is rnade~ or E00000H (if a two megabyte allocation is made!. The
25 main blocks of memory are typically organized as a file system. Bank 1 of
the
flash memory is typically allocated to a file system device, and may range
from
address DFFFFFH down to C00000H.
Referring next to Figure 3, the ASfC 1 10 r-r~ay be better appreciated. A
clock buffer 160 receives a CLK50 signal, and provides clock signals to RESET
30 SYNC logic l 62, DRAM control logic 16~., and timer control logic 1 6e. An
(INTO buffer 168 receives iNTi', lNTA, INTB, MS1NT, KBINT and NINT signals as
CA 02440825 2003-09-19
1 3 1 ~~~.9F'
set forth m I'abie 2. The RV T butfer provides a plurality of signals to
interrupt
Control logic 170, which receives a control signal from CPU Control input
buffer
172 and a timer control signal from timer control logic 1 66 and generates an
INTR output signal, which is provided to the CPU. The CPU Control input buffer
.
5 1 7 2 also supplies a control signal to Cycle control logic 174, which in
turn
provides a contr of signal to DRAM control 1 G4. The DRAM control 1 64 also
receives a refresh signal from timer control-logic 166; the timer control
logic 166
also generates the speaker enable signal SPEN.
in the exemplary embodiment, the interrupt control logic 170 is not 8259
10 compatible; likewise, the system timer, or timer control logic 1 66, is not
8254
compatible, and operates at a higher frequency than an 8254-compatible device.
The result is that some of the higher frequency interrupts sent by the timer
control logic are masked in the kernel, but others are passed through to
approximate, ors average, the normal time between interrupts. The higher
15 frequency thus permits emulation of standard PC functionality even though
the
time between lower istandard) 'frequency emulated interrupts may not be
uniform.
The ASIC 110 also includes a CPU Address input buffer 176, whick
.~ receives BEO, BE'l and A1-A23 signals as described in Table 2 and provides
an
20 output signal to a DRAM Memory Address Mux 178 as well as Mem/i0 Chip
Select Control logic 180. The Mem/10 Chip Select Control logic 1 8O promdes
a variety of output signals, including FLASHCSO (FCSO) and FLASHCS1 iFCS1 )
signals, and others as shown in Tab6e 2. Further, the ASIC 1 7 0 receives
signals
DO-15 from the data bus 108 and provides them to CPU Data input buffer 182.
25 The buffer 182 provides data to a Sdata Output Buffer & Latch 184, which
supplies output signals BDO-15. The buffer 182 also provides data to Power
control logic 186, which supplies SLEEP and PWRDWN signals.
T he signals BDO-1 5 can also provide data to 8data Input buffer 1 88,
which in turn suppfies that data to CPU Data output buffer 190. The interrupt
30 control logic 170 also provides signals to the buffer 190. A configuration
CA 02440825 2005-05-12
14
register 192 also provides a configuration signal (such as hardware
configuration, for example how much flash and/or DRAM, or from the monitor
power supply or from a plug-in card, for example, a network card) to the CPU
data output buffer, which can supply data on the bus 106 to the CPU.
Referring next to Figure 4, the key elements of the terminal operating
system may be better understood. It will be appreciated
from the foregoing that the hardware is not compatible
with a standard AT-bus design. Instead, the present invention relies on
firmware
to provide the requisite BIOS services to the upper software Payers. In an
exemplary embodiment, the firmware is designed to run i.n 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. Signals such as I/0 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.
Continuing with reference to Figure 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 fife. The AUTOEXEC.BAT file may include, for example,
keyboard and mouse drivers although both such drivers may not be used in evrry
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 o
CA 02440825 2005-05-12
communications port causes the self-test sequence to execute.
The EXEC.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
5 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 setup mode is
selected by the user, the EXEC.COM 325 branches to run the SETUP, or GUI
' 10 330. If the setup mode was not selected, the EXEC.COM 325 cooperates in
the
..
loading and unloading of network drivers at 335 and begins the running of
network connection code (again, ICA, thinwire, 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
15 version of which is available from Citrix Systems, Inc.
Now referring to Figure 5, the cooperation of the terminal operating
system and the hardware architecture may be better
appreciated. In particular, the lowest layer shown in Figure 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 1 12 and partly out of RAM 1 16.
Once the power on self tests are completed, the terminal continues with the
boot sequence described generally above in connection with Figure 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. Ttie AUTOEXEC in turn causes the EXEC.COM 325 to
CA 02440825 2003-09-19
Z ~'7 ~'~ ,' 1;7 ~ f a
load. As noted above, the EXEC.COM sequence 325 can branch either to ct~c
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
5 receives information from one or more setup data files 41 a and starts the
GU1
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
l 0 controller 430, which may for example be based on a Cirrus 5428 graphics
processor, to generate a video display during the setup sequence. The setup
sequence will be described in greater detail in connection with Figure 5.
The keyboard driver 422 in turn communicates with the keyboard
controller hardware 432, which may, for example, be a conventional PS12
15 keyboard Input/output system, a universe! 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
I. a mouse Input/output system 434. Throughout such operations, the terminal
20 operating system's flash file and memory services portions 426 wil!
typically be
executing out of flash and RAM.
As discussed in greater detail in connection with Figure 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,
25 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 414, and
return to the EXEC:COM. When allowed to continue, the EXEC.COM process
412 can be caused to branch to the netvdork connection module 416. The
30 network connection module 340 initiates by retrieving the data stored in
the
CA 02440825 2003-09-19
1 7 . ~34i;-~P
connection data riles 440 and the command line of the connection rnoduie.
thereby communicating to the application :server how to talk to the rest of
the
driver and hardware Payers of the terminal. In particular, the network
connection
module communicates with the keyboard driver 422, the mouse driver 424, the
5 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 we!! as, in some embodiments, a
hardware network interface 444. The network drivers 444 execute out of RAM
1 16 in one exemplary embodiment, but may execute out of flash memory 1 1 2.
10 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 Figure 6, the operation of the GUI engine 420 shown in
Figure 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
1 5 graphical user interface during the configuration operation.
As noted in connection with Figure 5, above, the operation of Figure 6
begins when the setup sequence is invoked during terminal boat up. The setup
sequence rnay be invoked from a sequence of keystrokes or any other
~. convenient and suitable means. The setup sequence starts by calling setup
20 code 502, which in turn puns information from setup data files 418. The
setup
data files 418 identify the options available in the configuration of the
term~al.
The setup code 502 communicates bidirectionally 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
25 communicates bidirectionally with the RAIV1 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.
30 The setup code permits the user to cycle through a plurality of
CA 02440825 2003-09-19
~ ~~J~)1~
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 Figure 7A is an illustration of a setup screen used in the
configuration
mode of the terminal. In a preferred emlJOdiment, the setup screens are
displayed
5 graphically. As the user cycles through the configuration screens. the
configuration data may be selectively updated by the user througfo use of
tloc:
keyboard and mouse. 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
10 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 EXCC.COM 325 for initiation of the neimork ccnnection module 340 shown
in Figure 5.
15 Continuing with reference to Figure 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 Figure 7A, the "Communication" group includes
the selects Serial Port, TCP/1P, SPX and IPX, each of which has associated
20 therewith a region 630 indicating that that select has been chosen, or
selected.
Referring next to Figures 7B1 - 7133, the data structures associated with
the configuration software are shown. In particular, a list of area painters
is
found in ARFA_LIST 700. The structures pointed to by the area list include
boundaries, size, title and groups attached for af4 areas as defined by the
SSTUP
25 process. As noted previously, each area appears as a window on the screen.
In addition, all areas which 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 ovGriapping is not necessarily required in all embodiments.
CA 02440825 2003-09-19
1 9 1 ~)5'3f~
At 704 is the data structure for GROUP_L1ST, which lists ail groups
defined by the SETUP process in ail areas found in the AREA_L(ST 700. As
previously noted, each area typically includes one or more groups. An optional
data structure 706 for a STRING LIST may also be provided, and a FfLE LIST
5 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 I,D 712, a painter to the next area 714, a painter to the
previous area 71 fi, and a structure pointer 718. The structure pointer 71 8
10 associated with each area !D 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 carnet 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
15 FLAGS entry 728 specifies whether a border extends around the area. A
TITLE POSITION entry 730 and TfTLE_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 en=ry 734 specifies the maximum number of characters which
~. may be used for the title.
20 In addition, the area structure 714 also includes an entry 736 far the
number of groups contained witt-iin the particular area. An AREA-MPTR entry
738 specifies tt-re mouse pointer hat spot within the area, while an entry
DEF BUTTON 740 specifies which button within the area wits 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 wil! 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 painter 744
points to an associated group structure block 746, discussed hereinafter. A
hot
key list may also be defined far the area.
30 The structure of the DISP AREA LIST, shown at 748, is essentially
CA 02440825 2003-09-19
2G 1 ~35~ih
identical to the structure of the AREA LIST 700, and includes blocks for area
ID,
next area, previous area, and structure pointer. As with the AREA_LiST 700,
the
DISP AREAyLIST 748 also points to the area structure 714. A similar structure
for the GROUP f_1ST 704 is shown at J50, 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 STR1NG_LIST 706 may also Ue
provided, and may include a string ID 760,. a next string pointer 7G2, a
previous
string pointer 7E~4; and a string structure pointer 766.
Referring again to the group structure pointer 758, it points to the group
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 tf~e 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 irrjportant element is
to
ensure that all features of an area m~iraain 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 th7e group, as wail a
GFI.AGS entry 792 for specifying the harder 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 structur e, entries for title position 798,
group label 800 and MAXySTR_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_ATTACFi is provided as
a back reference to the area iD 712. 'with which the particular group is
CA 02440825 2003-09-19
~ a,r~cjE:>
associated. . he AiD ATTACH entry 806 is not reqwred in ail cases, but assvsts
in improving performance in at least some instances. Lastly, a list of pointer
entries 808A through 808N each point to a select structure associated with the
particular group. As will be discussed hereinafter, a variety of select
structures
E may be associated with each group, but some elements are cowman among the
various types. Thus, the first pointer- 808A points to a SELECT_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.
10 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, aUICK,KEY_POS and
QUICK KEY CHR entries 824 and 826 for specifying the hot keystroke
15 combinations associated with the select, a M,AX-S'i'R 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
20 to Figure 7A. The different types of selects which 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 isee 650 in Fig. 7A); in others, one of several choices must be
25 selected, as indicated in the "Communication" and "Serial Port" groups 660
and
670 of Figure 7A. In stilt others, an image may be selected, while in others
specific text must be selected. In some, a fill-in entry is required f680 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
30 list is not exhaustive and other selects can be readily implemented given
the
CA 02440825 2003-09-19
- 22 ' 959i'
teachings herein.
For a "fill ira" 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 wet! 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
NUM 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
1 5 together with a child group pointer, which points to a group structure of
the type
shown in group structure block 746. 'T'he 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 titEe (or MAX OP_LEIV1 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 which includes an area 1D entry 900, a group
IDentry
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 r eference 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
specify upper left X and Y positions as yv~:ll as lower right X and Y
positions far
CA 02440825 2003-09-19
~ n~C3J.~
23
the mouse hat spat, together with an entry 914 for mouse fl,sgs which cause
tf~e
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
5 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 r,~any
10 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 of ten.
Additional entries 962 and 964 are provided for the number of pixels per
1 5 column and row, .respectively, as welt 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
I~ select types with keyboard focus. Still further, (FOCUS and JFOCUS entries
980
20 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.
25 The information specifying the currerat state of the selects is specified
in
an ACTIVE SELECT structure 1000. Each structure includes a button entry
1002, an S'I'FLAGS, or select common flags, entry 1004, and an ACTIVE entry,
which stores the current state of al! selects, from which that data may be r-
nade
available to the SETUP code.
30 In an exemplary embodiment, an event queue structure 1010 may also be
CA 02440825 2003-09-19
24 ~~ ':35''_)!~
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
d
terminal operating system of the present invention is not compatible with a
5 standard PCiAT B105 or DOS. However, the terminal operating system is
required to support certain of these functions to maintain tfe ability to
tlisploy
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 SlOS.SYS functions which are supported by the present
~ 0 invention; it will be apparent to those skidled in the art that the list
does not
include numerous standard 1310S and DOS functions. Other functions are
unsupported. 1n 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
t 5 a hard disk. Likewise, Function 33h [GetISet System Value] is supported in
terms of function and flag, but the "Control-Break" function is not supported.
Similarly, Function 2Ah through 2Dh [GetlSe~t DatelTime 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
20 used to measure the duration of events, without reflecting absolute timQ.
!n addition, the flash file system of the present invention is, in the
presently preferred arrangement:, partitioned into multiple single-directory
drives.
f--lowever, unlike conventional disk files, the flash file system includes no
clusters or sectors. Files within each drive or partition grow upwards from
the
25 bottom of the partition, white directory entries grow downward from the
top.
Files are stored contiguously, without fragmenting. Directory entries, which
are
sixteen bytes long in a preferred embodirr~ent, are generally similar to a DOS
directory entry; however, elements which would normally be reservf:d are
defined to permit the file to execute out of flash; rather 'than DRAM. These
30 include the starting address of the file. Within the flash, as wet! as the
remap
CA 02440825 2003-09-19
25 1 ')~.:~)!'
segment of the file within the t~OS address specs.
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
5 ESh. 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
10 least same embodiments.
The flash file system supports conventions) DIR, TYPE and DEL
commands, supports a new "DEBUGMSG" command for generating a DEBUG
message, and also supports program execution 'through batch fifes. The file
system also supports the AUTOEXEC.BAT file, as well as loading and executing
15 of .EXE and .COM files, and Int 21h and Int 27h. However, the file system
does
not support, in at feast some embodiments, the CONFIG.SYS file or .SYS device
drivers. Likewise, the file system does not support batch file commands
(except
program executian], I/0 redirection, pipes, or interrupts 20h (Program
Terminate], 22h (Terminate Address], 23h (Ctrl-Break Exit Address], 24.h
(Critical
20 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
25 standard BIOS and DOS functions are not supported. in addition, even those
BIOS and DOS functions which are supported are not executed by standard AT-
campatible 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.
30 The service functions supported by the boot block 305 include: GET
CA 02440825 2003-09-19
26 1 ')~~5f'
FLASH DRIVE SIZE, lrvhich interrogates the flash memory 438 for drive size;
READ FLASH DRIVE, far reading data from the flash memory 438; WRITE FLASH
DRIVE; GET FLASH DRIVE BLOCK SIZE, for interrogating the block size of the
memory 438; ERASE FLASH DRIVE BLOCK, for erasing data from the memory
5 433; 1NARM REBOOT, used by the manufacturing test to loop through the
power-on diagnostics repeatedly but not used in normal operation; GET.BOOT
BLOCK DATE; CLEAR KEYBOARD CONTROLLER I/O BIT, used to control
components connected to the keyboard controller; and SE-f KEYBOARD
CONTROLLER IIO BIT.
10 The operation of the kernel 305 is shown in greater detail. In particular,
the kernel includes three service functions. The first is an "ACTIVATE VIDEO
INT 10h" function, which enables the normal int lOh functions for video
services. The interrupt int lOh is initially intercepted by the kernel 305 to
suppress the display of text-mode messages from the various device drivers
15 while those drivers are loaded. After the drivers are loaded and the
terminal
enters graphics mode, the ACTIVATE VIDEO INT 10h function is called to
restore normal int lOh operation. In addition, the kernel 305 includes a
second
function, "SET POWER DOWN TIME," which can set various power saving
~. functions (such as Energy Star compliance) and the delay timer for
activating
20 such features. Finally, the kernel 305 includes a "PROCESS DOS INTERRUPTS"
function, which can be called from the boot block or other portions of the
kernel
305 anytime necessary to process pending DOS interrupts which require real
time processing in a DOS environment. The interrupts most often processed by
this function are mouse and keyboard interrupts, although they may include
25 timer, serial, parallel and network interrupts. The interception by this
function
prevents, for example, mouse and keyboard interrupts from being disabled for
an excessive period -- i.e.. long enough to be an annoyance to a user, for
example a delay of about one second betvveen a movement of 4he mouse and
a responsive movement of the cursor -- and to flush 'the keyboard controller's
30 output when it becomes necessary to . send a command to the keyboard
CA 02440825 2003-09-19
1, t~t~Cll)
controller.
Since the hardware of the present invention does not comply with the
PC; AT standard, and the fiirmware does not ccmply with either conventional
PC; AT BIOS or DOS, but the overall s~rstem is intended to permit the user to
5 view and interact with a conventional Windows display, some conventional
f~ardware interrupts and related calls must be managed by the present
invention.
in a preferred embodiment, such interrupts. and calls are handled in the
'terminal
firmware, either by emulating or modifying the appropriate response to t;oe
incoming signal. Such responses will be treated in greater detail in
connection
10 with the software kernel described hereinafter.
The kernel puts the processor in virtual $08fi mode and sets up various
tables as necessary to intercept I10 to various ports. After an access to a
selected port generates an exception, the instruction that generated the
exception is disassembled so that the kernel can process it correctly to
emulate
15 PC compatibility, thus simplifying the porting of various personalities.
Because
an entire subroutine is executed for each intercepted I/O instruction, the l/0
instruction will not execute as fast, so intercepted I/0 is limited to as few
ports
as possible. In some instances, all or only a portion of an I/0 port is
interrupted
as necessary to provide AT compatibility. !t will be appreciated that, while
the
20 primary embodiment described herein is intended to provide a Citrix
Winframe
personality, other personalities could also be implemented for use by the
terminal
of the present invention. In some instances, the terminal of the present
invention may include multiple personalities in r-nemory, with the terminal
connected to multiple hosts running different operating systems which expect
25 such differing personalities. The user or others may then be able to select
from
such personalities through a hot key or other sequence, with the kernel of the
present invention then executing the aplpropriate personality out of memory
and
permitting communication to the appropriate 1-rost. --
The i10 ports which are intercepted by the kernel to provide AT
30 compatibility are:
CA 02440825 2003-09-19
28 1 ,"~~:;i'
20h [The command port of an AT-compatible interrupt controlled -- iW 1y
the "end of interrupt" command is emulated, which is issued at the end of
every
interrupt handler to allow more interrupts of the same or lesser priority to
occur.
The kernel also emulates the normal operation of a PC-compatible interrupt
5 controller of blocking interrupts of equal or lesser priority until the "end
of
interrupt" command is received.
21h [The AT-compatible interrupt controller's mask register) -- Emulated.
40h-43h [Access to an AT-compatible 8254 system timer) -- The ports are
not emulated, but are intercepted because some AT-based drivers write to these
10 ports. Since the interrupt mask register of an exemplary embodiment of the
present invention is set at port 40h, unintercepted writes would interfere
with
the interrupt mask register of the present invention.
61h [A miscellaneous control port on an AT architecturel -- One speaker
control bit is emulated to permit the speaker to be turned on and off.
15 AOh [The command port of an AT-compatible computer's second interrupt
controller) -- As with port 20h, the "end of interrupt" command is emulated.
A1h [The mask register for the second interrupt controller isimiiar to port
21 h? I -- Emulated.
ZFBh through 2FFh [A standard address for an AT second serial part) --
20 The ports are remapped to 5F0h through SFEh, which are the port addresses
for
the second serial port of an exemplary embodiment of the present invention.
The new port range [5F0 - 5FE1 includes even addresses only. In an exemplary
embodiment, byte swapping has not been implemented, and thus only even
bytes of the eight bit SI~ device can be accessed. However, byte swapping
25 may be implemewted if desired.
378h through 37Fh [A standard address for an AT parallel portl --
Remapped to 6FOh through 6FEh, which are the port addresses for the parallel
port of an exemplary embodiment of the pr esent invention.
3F8h through 3FFh [A standard address for an AT first serial port) --
30 Remapped to 7FOh through 7FEh, which are the part addresses for the finest
serial
CA 02440825 2003-09-19
,, ~~,~~~1,
port of an exemplary e~nbociiment.
Having sully described a preferred embodiment of the invention and
various alternatives, those skilled in the art wiil recognize, given the
teachings
herein, that numerous alternatives and equivalents exist which do not depart
5 from the invention. It is therefore intended that the invention not be
limited by
the foregoing description, but only by the appended claims.
