Binaries – Shared Libraries – Directories

Binaries – Shared Libraries – Directories

Windows binaries that start applications have a suffix of exe and in Unix they have no suffix. Windows shared library binaries are called DLLs (dynamic load libraries) and have a suffix of dll. Unix shared libraries have a prefix of lib and a suffix of so in Linux and dylib in Mac. The Linux form is used in these examples. Each binary has an equivalent on all platforms except for j.exe, which is Windows only.



The J Engine is a shared library and the different front ends can each be compiled into small binaries that use the same J Engine shared library.



In addition to the system use of shared libraries, the J user can use other shared libraries, such as the host api and the J provided Perl Compatible Regular Expressions, with the cd facility

Windows binaries

j.dll — J Engine

jconsole.exe — front end with console support

j.exe — front end with wd (GUI) support (blue launch icon)

j.jar — Java based front end with wd (GUI support) (red launch icon)

jnative.dll — C wrapper that glues j.jar to j.dll

jee.exe — console front end that connects to j.exe or j.jar with sockets

jpcre.dll — Perl Compatible regular expression (in tools folder)


Windows use of shared libraries

jconsole.exe -> j.dll

j.exe -> j.dll

javaw.exe -> j.jar -> jnative.dll -> j.dll

jee.exe -> j.exe -> j.dll

jee.exe -> javaw -> j.jar -> j.dll

… -> j.dll -> jpcre.dll

… -> j.dll -> Windows API and other DLLs


Unix binaries

libj.so — J Engine

jconsole — front end with console support

j.jar — Java based front end with wd – identical on all platforms

libjnative.so — C wrapper that glues j.jar to libj.so

jee — console front end that connects to j.jar with sockets

jpcre.so — Perl Compatible regular expression (in tools folder)


Unix use of shared libraries

jconsole -> libj.so

java -> j.jar -> libjnative.so -> libj.so

jee -> javaw -> j.jar -> libjnative.so -> libj.so

… -> libj.so -> libjpcre.so

… -> libj.so -> Unix API and other shared libraries


Finding shared libaries

A problem with shared libraries is where to find them when they are needed. For example, in Windows when you run jconsole.exe it needs to load j.dll into memory. The question is where should it load from. There could be serveral different versions of j.dll on your hard drive and it is critical that get the right one. The problem is the same on Windows and Unix, but the rules for finding the shared library are a bit different.


JFE’s assume the correct JE is in the same J folder that contains the JFE. The JFE determines the path to this J folder and loads exactly that JE with a fullpath.

Windows Shared Library Search Rules

Windows searches and uses the first one it finds:


0. the exact file if a fullpath is specified

1. the directory that contained the exe binary that started the process

2. current directory

3. system directory (usually c:windowssystem32)

4. windows directory (usually c:windows)

5. path environment directories

Unix Shared Library Search Rules

Here is a simplified summary of where Unix searches for the shared library (it uses the first one it finds):



0. the exact file if a fullpath is specified

1. /usr/lib

2. /lib


There are three complications

1. links (files that link to other files) are often used with shared libraries

2. different versions of a shared library can be indicated by suffixes: so.5.1 and so.5.2

3. search rules are different when linking and when running



A typical shared library might have the following three files in /usr/lib

libfubar.so       link to     libfubar.so.5 
libfubar.so.5     link to     libfubar.so.5.2
libfubar.so.5.2   binary file for fubar version 5.2
libfubar.so.5.1   binary file for fubar version 5.1

When a binary is built for distribution the link is done with just the name fubar. The linker finds libfubar.so then libfubar.so.5 and then libfubar.so.5.2 and resolves everything based on the code there. But it puts the name libfubar.so.5 (not the starting name libfubar.so and not the name of the file actually used) in the resulting binary. When the binary is run it starts at libfubar.so.5. Generally this is good because it means that libfubar.so.5 could link to a new binary libfubar.so.5.3 with nice fixes. But it could be bad because you’re not getting exactly what you were built to expect. The theory is that the 5 is a major change and you wouldn’t want to quitely be given version 6 instead, but that that the 2 or 3 are minor versions (bug fixes) and you would want the latest.