EDX/UNX User Interface for Java

by Stuart D. GathmanLast updated Mar 08, 2001

EDX/UNX and Java

EDX is a virtual machine operating system that has been in operation since
the early 1970s. Applications written for EDX are binary portable to any
hardware and OS combination with an EDX virtual machine (provided no native
code was linked). It was originally
developed for System-7, then ported to the IBM Series/1. H&A developed a
port to C/Unix called EDX/MAX - since renamed to EDX/UNX.

Binary portability allows users to "drop in" a new computer - even one with
a completely new processor with no disruption of applications or recompiling.
This feature is so valuable, that many EDX users were slow to jump on the C/C++
bandwagon. C/C++ portability requries recompilation of all application code.
Furthermore, variations in system headers (C interface descriptions) across
unix variants make recompilation more troublesome than it should be.

Nevertheless, EDL - the primary programming language for EDX - is a fairly
primitive language best described as "structured assembler". Would there
ever be a language with modern object oriented features and widely implemented
binary portability? Java can answer in the affirmative. Now EDX
programmers can join the OO age without giving up the portability of EDX.

The bmsi.edx Java package from
BMS
lets you mix Java and EDL code easily and efficiently. Based on the
freeware posix package
from BMS, EDXJava gives
your java code the same IPC access to the EDX/UNX virtual machine as
external C programs.

How does it work?

EDX/UNX provides an IPC based interface to external processes that communicate
with the EDX virtual machine. Using this interface, Java code can set and
inspect EDX memory,
cancel programs, post events, and other things. The
EDX class represents an EDX virtual machine
and exposes these operations.

EDX/UNX also provides a way to load and invoke an external process from EDL
code. A process invoked in this manner must recognize certain command
arguments and respond to messages in a UI queue. The
Edxuser class implements this
framework in an easily extendable form.

To easily call Java methods from EDL, the Edxjava Java application
implements a "generic" user process that gives EDL code access to
Java classes that implement the
EDXServlet interface. The Edxjava JVM is loaded only once for each
EDX VM. It is loaded automatically by the EDL interface stub - and subsequent
EDL calls to Java methods are very efficient.

Q. When I try to run Java code that
calls EDXServletRequest.getBtasdir() or use JBOOT, it hangs.
What is wrong? I can run the EASTER and TEST demo programs just fine.

A. The JAVA,MSLIB EDL stub is still trying to print JAVA VM LOADED on
$SYSLOG. For some reason, the EDX nucleus was compiled with $SYSLOG as
a 4978 terminal. Change $SYSLOG to a 4974, and you'll be ok. The latest
JAVA,MSLIB stub will skip printing JAVA VM LOADED when its terminal
emulator is not loaded.