# WindX™ Thin-Client

Thin-Client Environment |

From a systems perspective, WindX appears like an intelligent graphical terminal that responds to a wide variety of command sequences. The command sequences are generated automatically by the system in response to your application logic and directives.

#### Note:
If the WindX workstation is an earlier version than what is installed on the server, you will not be allowed to process any NOMADS panels due to potential compatibility issues.

While running on a WindX workstation, you will not be allowed to launch server-side programs. Any attempt to do so will display a message. This includes launching a Client Server workstation, a Simple Client Server, an NTHost Server or configuring the Application Server. (This functionality was added in PxPlus 2017.)

## Mnemonic Processing

WindX responds directly to the internal form of all mnemonics. Therefore, unlike conventional terminals, no translation table is required. Mnemonics, such as 'CS', are transmitted as $1B$ + "CS" and screen position commands, such as @(1,2), are sent as $1B$ + "@2" + CHR(1) + CHR(2). Long-form mnemonics, such as 'WINDOW' and 'DROP', are sent in their native form as well.

WindX is a highly optimized intelligent terminal emulator designed primarily for use with PxPlus. Much of the functionality normally done by the host when dealing with 'Dumb' terminals is done by WindX locally. This means that less data needs to be sent to a workstation to handle functions such as window manipulation. On a normal terminal, when a window is created, the characters that make up the window border are transmitted from the Host to the terminal. Additionally, when a Window is removed, then all of the data that was hidden behind the window must be redrawn.

These two functions are processed locally by WindX, which reduces network traffic and improves system performance.

This product also provides enhanced graphical terminal emulation that allows graphical applications to run remotely. All graphical mnemonics such as drawing fonted text, rectangles, circles, etc. are supported.

#### Note:
Because the 'PICTURE' mnemonic needs to access image files for the purposes of rendering, special consideration needs to be given to this mnemonic.

On WindX

If using the 'PICTURE' mnemonic with early versions of PxPlus, the file name specified must exist (or at least be accessible) from the WindX PC. Make sure that the pathname of the bitmap is correct for the PC.

When using the 'PICTURE' mnemonic with PxPlus version 7.00 or later, you can enable the auto-download capabilities, which will send images from the host to the workstation automatically. See Auto-Download Capability.

## Location of Pictures When Printing Using WindX

The pathname used in a 'PICTURE' mnemonic when printing under WindX will depend on your host/server and OPEN statement.

If you are running on a Windows host/server and you open with just "*WINPRT*", you are opening a channel to the server's Windows print server; thus, the pathname should be relative to the host application and where it is running.

If you are running on a non-Windows host/server and you open with just "*WINPRT*", or if you open with "[WDX]*WINPRT*" regardless of the type of server you are using, then the pathname in the 'PICTURE' mnemonic needs to be relative to the WindX session.

Example:

If you issue OPEN (1) "[WDX]*WINPRT*" and issue a PRINT (nn) 'PICTURE'(...,"xxx"), the pathname "xxx" will be forwarded and resolved based on the current directory of the WindX workstation.

## Input Handling

All input entered on the workstation keyboard is sent directly to the host. Function keys and CTL events generated by graphical controls are included in the data stream as well.

## Command Line Shell Requests

On WindX

If you want to run command line shell requests on a UNIX/Linux or Windows server rather than on the workstation, you can use either the INVOKE directive or create a command such as 'sh' in the *cmd directory.

Example:

You could create the following program and place it in *cmd/sh:

> 0010 ENTER x$,ERR=*NEXT
> 0020 OPEN (HFN,ISZ=-1)"|"+x$+" 2>&1"
> 0030 WHILE 1
> 0040 READ RECORD (LFO,SIZ=1,TIM=.1,END=*BREAK,ERR=*NEXT)c$; PRINT c$,; CONTINUE
> 0050 OBTAIN (0,SIZ=1,TIM=.1,ERR=*CONTINUE)c$; WRITE RECORD (LFO)c$
> 0060 WEND
> 0070 CLOSE (LFO)

> Then, if you wanted to run a command such as PWD (or any other command), you would type the following:

> shpwd

Using this method allows more interactive commands to work as well.

## Graphical Directives

The host PxPlus tokenizes all graphical directives and references and then forwards them to WindX for processing.

WindX processes these tokenized commands locally. Access to the new control properties (e.g. BackColour$, Height, Enabled) are also tokenized and forwarded to the client for processing.

## Special File Command Tags for WindX

Two Special File Command Tags are available for use with PxPlus programs that relate to the Thin Client environment:

[WDX] | The [WDX] tag instructs the program to execute the directive or function on the local workstation. Example: OPEN lock (1) "[wdx]c:\Payroll.dat"
[LCL] | The [LCL] tag first determines whether a Thin Client environment is being used. If in use, it then instructs the program to execute the directive or function locally. If a Thin Client environment is not being used, it ignores the tag, which will eliminate the Error 12 that would otherwise be caused by a [WDX] tag. An [LCL] tag can be used anywhere where a [WDX] tag might otherwise be used.

## Remote File Access

WindX provides the additional functionality of allowing files to be opened and accessed remotely. Whenever a file open is executed on the host with a pathname prefix of "[WDX]" (or "[LCL]" for PxPlus), the file open request is forwarded to the workstation for processing locally. The host will then tokenize and forward all subsequent requests against that file to the workstation to be processed locally.

This feature allows host application to read and write files on the workstation with a minimum of effort. The following File IO directives and functions are supported for remote files:

Directives:

| CLOSE | INDEXED | OPEN | READ | SERIAL
| ERASE | KEYED | PROGRAM | REFILE | UNLOCK
| EXTRACT | LOCK | PURGE | REMOVE | WRITE

Functions:

| FIB | KEC | KEP
| FID | KEF | KEY
| FIN | KEL | RNO
| IND |  |

Example:

> OPEN lock (1) "[wdx]a:\Payroll.dat"
> READ record (1,end=end_data) r$
> …
> end_data: close (1)

In the above example, the remote file access facility is being used to allow the host application to read a file from a disk (a:\Payroll.dat) on the client workstation.

See [LCL] Access to Users Local Machine and [WDX] Direct Action to Client Machine.

At present, the DIR= option is not supported on remote files by WindX.

On PxPlus, simply include a "[LCL]" prefix that indicates the file is on the local workstation and will be ignored if non-Thin Client and considered the same as "[WDX]" if using a Thin Client.

## Remote Command Processing

WindX also supports the ability to remote process the INVOKE and EXECUTE directives on the WindX PC. If the string parameter passed to either of these directives starts with the sequence "[WDX]" (or "[LCL]" in PxPlus), the rest of the command is passed to WindX to be executed locally.

Examples:

> INVOKE "[wdx]notepad.exe c:\autoexec.bat"
> EXECUTE "[lcl]set_param 'cd' "

The most common uses for issuing remote EXECUTE directives include changing local directory, changing system parameters and changing the prefix.

#### Note:
Be aware that when using the EXECUTE directive remotely, it is possible that the local PC could be running a PxPlus with a different set of syntax tables, resulting in the directives not being correct.

## Remote Procedure Call

One of the more powerful features of WindX is its ability to execute subprograms remotely. Since WindX itself is a PxPlus program, it is capable of calling and passing parameters to a local sub-program.

Like the OPEN directive, the file name passed to a CALL directive can be prefixed with [WDX] or [LCL]. This indicates that the specified sub-program is to be run on the local PC, not the host system. The sub-program must exist on, or be accessible from, the client PC.

Any arguments specified in the CALL are sent to the WindX PC and any changes are passed back as per normal CALL processing.

#### Note:
There is a limit of 20 arguments that can be specified in a remote CALL.

PxPlus provides a built-in mechanism for downloading called programs to the workstation. See Auto-Download Capability.

#### Note:
Remember that the called program is actually running on the client workstation, not on the host system that initiated the CALL. Only the variables that have been passed specifically on the CALL argument list are accessible. Global variables and files are not accessible to called programs.

## Workstation Requirements

Most character-based or graphical applications can run without modification with WindX; however, there are a few things to consider.

File Requirements on the Local PC

Many commands are tokenized and sent to the local PC for processing. Some of these, such as the 'PICTURE'( ) mnemonic and MULTI_MEDIA commands, may include file name references. Since these commands will be executed locally on the workstation, all files referenced by them must exist or be accessible by the local WindX PC. In the case of the 'PICTURE' mnemonic, when using PxPlus, the Auto-Download Capability can be used to send a copy of the image to the workstation.

DLLs, OCXs, COM modules and VBXs must be resident/installed on the client PC.

Open requests to ODBC, DDE, *WINPRT*, or *WINDEV* files should be routed to the WindX PC by prefixing the pathname with "[WDX]" or "[LCL]".

Fonts used in 'FONT'( ) commands must exist on the client PC.

If using the Windows print drivers for Graphical printing, then a UNIX spooler queue could be used if set up as a Shared Printer and connected to print server software, such as VisionFS or SAMBA.

## WindX Advantages

Apart from the obvious advantages of being able to run graphical applications remote, using WindX has the following additional advantages over standard terminal emulators or running the application locally:

Remote Processing

The Remote Processing capability of WindX enables you to take full advantage of the potentials of both the host and client operating systems.

Faster Screen I/O

Simple screen transmissions and updates are often faster with WindX since it can process all system mnemonics locally and eliminate screen redisplays. The reduced transmission requirements provide for faster communications since screen redrawing is done without retransmission of the data from the host.

Data Reliability

Using WindX to connect to a Windows-based network to run your application eliminates the movement of application data and programs to the PC during processing. This minimizes the risk of corruption of the data or program logic. It provides your application with the data security and system integrity of UNIX while providing the look and feel of Windows.

Application Editor Utilities

As of PxPlus 2020, each name in the Recent File list in the *IT Program Editor, NOMADS Panel Designer and Report Writer will be maintained by workstation name, thereby only showing those related files/libraries applicable to the server to which you are connected.