Execution of a windows program from a classic page

Description

Launching a process from the browser on a local Windows workstation can be a response to a particular need in some cases; but this might create a security flaw. A dedicated feature allows you to call Windows executables as long as they are in the registry.

This new functionality allows you to launch an application (i.e., process) on the local workstation from a classic page session using 4GL Callui statement, relayed by Asynchronous Pluggable Protocols stack (APP in the following). Unlike System 4GL statement, this implementation does not support I/O flow control on a called process. It is just a "Launch & forget" mode, in an asynchronous way.

To use this new functionality, Windows registry on a local workstation must be updated to register the application to launch, based on APP specification (see https://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx).

Every application that can be launched is identified by a unique name (the APP protocol name). For example, if you want to launch "notepad.exe", you call this component "SageX3ProtocolTest". The APP protocol must be registered for "SageX3ProtocolTest" by adding this Windows registry branch :
[HKEY_CLASSES_ROOT\SageX3ProtocolTest]
@="URL:SageX3ProtocolTest"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\SageX3ProtocolTest\shell]
[HKEY_CLASSES_ROOT\SageX3ProtocolTest\shell\open]
[HKEY_CLASSES_ROOT\SageX3ProtocolTest\shell\open\command]
@="notepad.exe"
The corresponding 4GL script is :
Local Char RETOUR(250)
Callui RETOUR="" With     "UIAction="+chr$(1)+"OpenFile",
&                         "UILocalDir="+ chr$(1) +"APP",
&                         "UIWindowTimeOut="+ chr$(1) +"10000",
&                         "UIWindowName="+ chr$(1) +"My window App  ID",
&                         "UIWindowFeatures="+ chr$(1) +"width=300,height=300",
&                         "UILocalFile="+ chr$(1) +"SageX3ProtocolTest:

Warning

If the process to call requires command line arguments, you have to be aware that, at the end, the command line propagated to the called process contains the APP protocol name (SageX3ProtocolTest: in our sample). So, the called process must be able to correctly parse this command line to skip or ignore the protocol name.
Otherwise, if the called process cannot handle this constraint, it is possible to use a workaround by calling the process via a DOS script, as described below. In this case, both 4GL script and Windows registry data must be adapted accordingly.
Below are presented: the Windows registry data, the 4GL script, and the DOS script, based on the same sample (i.e. launch notepad.exe and edit a text file) :

Registry

[HKEY_CLASSES_ROOT\SageX3ProtocolTest]
@="URL:SageX3ProtocolTest"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\SageX3ProtocolTest\shell]
[HKEY_CLASSES_ROOT\SageX3ProtocolTest\shell\open]
[HKEY_CLASSES_ROOT\SageX3ProtocolTest\shell\open\command]
@="c:\\temp\\test_app_notepad.bat \"%1\""

The corresponding 4GL script is

Local Char RETOUR(250)
Callui RETOUR="" With     "UIAction="+chr$(1)+"OpenFile",
&                         "UILocalDir="+ chr$(1) +"APP",
&                         "UIWindowTimeOut="+ chr$(1) +"10000",
&                         "UIWindowFeatures="+ chr$(1) +"width=300,height=300",
&                         "UILocalFile="+ chr$(1) +"SageX3ProtocolTest:~C:\Tem",
&                         "UILocalFile="+ chr$(2) +"p\test_app.txt"

The DOS script

The script is called test_app_notepad.bat, according to our example.

Command line relayed by APP is split (see ~ character) to retrieve the right part, meaning the end application startup arguments.

@echo off
for /f "delims=~ tokens=1,2" %%a in (%1) do set param=%%b
start notepad %param%