Contents:

• Installation program
• Language
• Eloquence IDE
• Eloquence CGI
• RUNSRV32.EXE
• eloqsd service

Installation program

The Eloquence installation program for the Windows platform now contains all software components in a single executable. This simplifies downloading the software and helps to eliminate problems during installation. It is still possible to select which components should be installed.

If you have configured additional eloqdb6 server instances they are now completely retained, including their Startup Type. After installation your additional eloqdb6 server instances are ready to use and can be started from the Service Control Panel.

Language

The Windows default printer may now be configured in the eloq.config configuration file.

In the example below, PRINTER 0 is assigned the Windows default printer:

 PRINTER 0 SYSTEM DEFAULT

The Windows default printer is dynamically queried. Therefore, if the Windows default printer is changed while an Eloquence program is running, the new default printer is used the next time the printer is opened with the PRINTER IS statement.

Eloquence IDE

The Variables toolwindow now orders the list of variables by name.

The editor windows now support mouse wheel scrolling. When holding the SHIFT key while using the mouse wheel, scolling is accelerated by factor 10.

Using Ctrl+Tab to switch between windows in the IDE workspace now works when a File Open window is open.

The integrated dialog editor of the Eloquence IDE now supports the new JDLG attributes .fgcolor and .bgcolor. The previous change to the .fgc and .bgc attributes has been reverted so that .fgc and .bgc again require an integer value (as in the original implementation). To provide string color values in JDLG .fgcolor and .bgcolor should be used.

In case this implementation causes problems with particular DLG files it is possible to fallback to the original implementation of the dialog editor as below:

1. Exit the Eloquence IDE
2. Open the Eloquence lib installation subdirectory in the Windows explorer (for example C:\Program Files\Eloquence\lib)
3. Rename the file ide-adlg.cfg to ide-adlg-gui.cfg
4. Rename the file ide-adlg-old.cfg to ide-adlg.cfg
5. Please report any problems to support@marxmeier.com. Thank you.

Eloquence CGI

The Eloquence eloqcgi web integration utility is now available for the Windows platform. It is installed in the Eloquence lbin subdirectory (for example: C:\Program Files\Eloquence\lbin\eloq.cgi).

The eloqcgi documentation has been updated accordingly.

RUNSRV32.EXE

The following changes apply to the RUNSRV32.EXE component on Windows:

• In the eloqcl.ini configuration file, the new [access] section allows to configure which IP addresses or networks are allowed to connect to the RUNSRV32.EXE.

  The syntax for an access entry is:

   {allow|deny} = {All | ip-address [/ [netmask | addrbits]]}
  

  ip-address is an IP v4 address, such as 127.0.0.1.
  netmask is an IP v4 network mask, such as 255.255.255.0.
  addrbits specifies the number of bits in the IP address, such as 24.
  If neither netmask nor addrbits is specified it defaults to a host address.

  Example 1:
  allow access to all addresses in the local network 192.168.33.0/24

   [access]
   allow = 192.168.33.0/255.255.255.0
  

  Example 2:
  same as above, but exclude the 192.168.33.44 address

   [access]
   allow = 192.168.33.0/24
   deny = 192.168.33.44
  

  For full backwards compatibility, access is not restricted by default (equivalent to allow=all).

  A new eloqcl.ini.sam configuration template file is installed in the Eloquence etc subdirectory (for example: C:\Program Files\Eloquence\etc\eloqcl.ini.sam) which includes a template for the new [access] section.

• The Eloquence installation program does no longer put a shortcut to RUNSRV32.EXE into the Windows autostart program group.

  If the RUNSRV32.EXE should be automatically started when the Windows PC is booted or a user logs in, a shortcut to RUNSRV32.EXE must be manually added to the Windows autostart program group.

eloqsd service

• Specifying how users are authenticated

  The eloqsd on Windows now allows to configure the method how users are authenticated. This is controlled with the [Config] AuthPolicy configuration item in the eloqsd.cfg configuration file:

  AuthPolicy=server

  The default AuthPolicy=server configuration performs a user logon for each eloqsd connection and runs the associated processes with the privileges of the user. This allows separate privileges for each session and is preferable in most cases for security reasons. However the maximum number of concurrent eloqsd connections is limited by the Windows desktop heap (see below).

  This authentication method has been used in previous eloqsd versions and is still recommended. It is therefore the default.

  AuthPolicy=user

  With the new AuthPolicy=user configuration, the connected user is validated using the configured user name and password in the userFile (eloqsd.user by default). However, after this validation, the user is not logged-on to Windows. Instead, all actions (for example launching an eloqcore process) are performed using the privileges of the eloqsd process. As this implies less overhead than a real user logon a higher number of concurrent connections is possible without having to adjust the size of the Windows desktop heap.

  AuthPolicy=user requires the eloqsd process to run as an account different from the default Windows SYSTEM account. The necessary configuration steps are:

  1. Open the Services applet from the Computer Management console in the Windows Control Panel.

  2. Select the eloqsd entry in the list. Open the Properties dialog either from the menu or using the context menu (right mouse button). Select the Log On tab on top of the Properties dialog.

  3. Configure an appropriate account to run the eloqsd. This account should have the necessary privileges to access all resources your application requires.

  Please note:

  • When using AuthPolicy=server, the maximum number of connections is limited by the Windows desktop heap, resulting in Windows error #1816 (ERROR_NOT_ENOUGH_QUOTA) when this limit is exceeded.

    To overcome this limit, the size of the Windows desktop heap for the non-interactive windowstation must be increased.

    This requires to change a Windows registry entry with the Windows regedit or regedit32 tool. Please note that this must be done with extreme care, as doing the wrong changes to a registry value can prevent Windows from operating correctly.

    The necessary procedure is documented in the Microsoft Knowledge Base document #184802.

    Summary:

    Locate the following value in the Windows registry (you must be administrator to edit this value):

     HKEY_LOCAL_MACHINE\System\CurrentControlSet\
     Control\Session Manager\SubSystems\Windows
    

    This is a string value consisting of multiple sections. Locate the section starting with SharedSection=, it should have 3 parameters which are comma-separated.

    Example: SharedSection=1024,3072,512

    The 3rd parameter (in this case 512) is the one which must be increased. If you find only 2 parameters you can add the 3rd parameter yourself.

    You can set the 3rd parameter as high as the 2nd (in this case 3072), but this is often too much. Increase it in steps of 256 until your problem is solved.

    Windows must be restarted afterwards to activate this change.

  • When using AuthPolicy=user the configured users must have a password assigned in the userFile (eloqsd.user by default) to successfully connect to the eloqsd.

• Configuring the Windows logon type

  The new [Config] LogonType configuration item in the eloqsd.cfg configuration file is used with AuthPolicy=server (see above) to specify how a user is logged-on to Windows:

  LogonType=interactive

  This mode grants access to all resources the same user would have when logging on interactively. It has the least side effects and therefore is now the default.

  Unless this is used on a Windows Domain Controller, this mode should not require to configure any additional user rights.

  However, on a Windows Domain Controller, interactive access is denied to non-administrative accounts by default. To overcome this, the "allow log on locally" user right must be granted (see below).

  LogonType=batch

  This mode was used in previous eloqsd versions. It uses the "batch" logon type which is meant for background processes and is supposed to be more economical than the "interactive" logon type. However, in recent Windows versions a "batch" process is restricted so that this mode may no longer be appropriate. It requires the "log on as a batch job" user right to be granted (see below).

  The new default is "interactive". To retain the previous behavior, it is required to manually configure LogonType=batch.

  To grant either the "allow log on locally" or "log on as a batch job" user right, the following configuration steps are required:

  1. [optional, recommended] Create a dedicated group for all eloqsd accounts (i.e. the accounts configured with UID in the userFile (eloqsd.user by default)). This will simplify the configuration. Also, it allows to grant access to common directories for all eloqsd accounts (e.g. a common program file directory).

  2. Open the Local Security Policy editor from the Computer Management console in the Windows Control Panel.

     Please note: On a Windows Domain Controller please open the Domain Controller Security Policy editor instead (not the similarly named Domain Security Policy editor!).

  3. In the Security Policy editor, navigate to Security Settings -> Local Policies -> User Rights Assignment.

  4. In the policy list, locate the desired user right and open the Properties dialog either from the menu or using the context menu (right mouse button). If you created a dedicated group as suggested above (1), add this group to the list. Otherwise, selectively add your eloqsd accounts to the list.

  The eloqsd.cfg.sam and eloqsd.user.sam configuration template files have been updated to reflect the new configuration options.