System/Binaries
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 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
jpcre.dll -- Perl Compatible regular expression (in tools folder)
jconsole.exe -> 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
jpcre.so -- Perl Compatible regular expression (in tools folder)
jconsole -> libj.so
... -> libj.so -> libjpcre.so
... -> libj.so -> Unix API and other shared libraries
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 several different versions of j.dll on your hard drive and it is critical to 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 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:\windows\system32)
4. windows directory (usually c:\windows)
5. path environment directories
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 quietly be given version 6 instead, but that that the 2 or 3 are minor versions (bug fixes) and you would want the latest.