
 1. About JLoad and JLMs

  JLoad is an extension for Jemm (both Jemm386 and JemmEx) which allows to
 load 32bit flat protected-mode modules ( called "Jemm Loadable Module",
 JLM ) into Jemm's address space.
 
 JLMs can be used for various tasks, for example:

 - implement a protected-mode version of a DOS device driver.
 - implement a protected-mode version of a DOS TSR.
 - provide services for other JLMs (kind of a ring 0 dll).
 - run as a ring 0 protected-mode application which will
   be unloaded automatically after it has its job done.
 - emulate hardware by trapping I/O port access.

  A JLM is supposed to be loaded by JLoad, either as a device driver in
 CONFIG.SYS, or from the command line. The syntax is:

 [DEVICE=]JLOAD.EXE [ options ] name_of_JLM [arguments for JLM]

 The name of a JLM is always required as parameter. Options are:

   -q:  quiet mode.
   -u:  unload a JLM.

  To be able to unload a JLM, several conditions must be true. First, the
 JLM must export a so-called DDB. Second, the DDB must contain a valid
 "Device Id". And third, the JLM must not refuse to be unloaded.

  Note: currently  the versions of Jemm and JLoad always must match, else
 JLoad will refuse to do anything.

  A few JLMs (XDMA32, XCDROM32 and AHCICD) are included in the Jemm binary
 package. For more details see XDMA32.TXT, XCDROM32.TXT and AHCICD.TXT.


 2. Creating the Binaries

  JLoad.exe is a 16-bit binary. It contains a flat, zero-based 32-bit part
 that is included as a binary object during assembly time. While the 32-bit
 part (JLoad32.bin) is generated, the linker may emit warning "stack segment
 not found", which can safely be ignored. For details about the tools needed
 for creating the binaries see file Makefile.


 3. Technical Details about JLMs

  JLMs must be non-segmented and linked as Win32 PE binaries. But despite the
 similiarities, JLMs should not be confused with such binaries. Some of the
 differences are:

 - JLMs always run in ring 0 protected-mode.
 - there is no Win32 API (and also no DOS/DPMI API) available.
 - JLMs cannot be linked with Win32 import libraries.

  Because of the fundamental differences, JLMs should be linked with subsystem
 "native". Thus they aren't recognised anymore as Win32 binaries.

  The only API JLMs can use directly is the one installed by JLoad, which more
 or less is a small subset of the Windows 3x/9x VMM API. This API usually is
 invoked by an INT 20h opcode, followed by two words which determine the
 module and function to be called. The API also allows "nested execution",
 that is, a JLM can indirectly call BIOS or other software interrupts outside
 of the client's context. For details about what functions are implemented
 see files JLM.INC or JLM.H.

  There is a strong similiarity between JLMs and Windows 3x/9x VxDs, but there
 are also some major differences:

 - Jemm does not support Virtual Machines (VMs) currently.
 - Jemm has no integrated DPMI host. Therefore the client will always be in
   V86-mode. DPMI applications can run only outside of Jemm's context with
   the help of an external DPMI host that runs as VCPI client.
 - JLMs run with interrupts disabled. If they do a lengthy operation or have
   to wait, they must "yield" to allow interrupts to be serviced.

  Note that the first invokation of JLoad will actually make JLoad resident
 in Jemm's address space. Further invokations will call the resident part.
 This is relevant if multiple versions of JLoad are used, for example both
 a release and a debug version.

  A detailed documentation about the Win3x/9x APIs that are partly implemented
 by JLoad can be found in:

 - Win95 DDK, file VMM.HLP
 - Win98 DDK, file OTHER.CHM
 - Win2k DDK, file OTHER.CHM


 4. Debugging JLMs
 
 a) JemmDbg

  This is the easiest method to debug JLMs. This debugger has a simple line-
 oriented interface. Once loaded, a breakpoint in protected-mode will activate
 the debugger. It cannot debug applications running in v86-mode, though.

 b) 386SWAT

  Jemm is compatible with the 386SWAT ring 0 debugger. This debugger may also
 be used to find bugs in JLMs. However, to catch the most common type of errors
 in protected-mode - GPFs - with 386SWAT, one has to tell 386SWAT which GPFs
 are "expected" and which are not. The following line in 386SWAT.PRO should do
 the trick:

 GPSKIP=HLT,INI,IND,INS,OUTI,OUTD,OUTS,CRn


 Japheth

