Uploaded to ftp.devoresoftware.com/downloads is an updated emm386.zip,
the full FreeDOS file set of HIMEM and EMM386 files.

EMM386 has several enhancements.  It adds support for the most-used
API subset of VDS with the VDS option, allowing network drivers to be
loaded high in UMBs.  All moves to and from control and debug
registers via standard registers (e.g. MOV DR3,ESI) are now supported
in V86 mode, i.e. when EMM386 is present.  EMM386 source was updated
to support the 'M' and 'G' suffixes made by Aitor SantamarC-a Merino
for HIMEM, where those suffixes can be used.  All command line options
are listed in the EMM386 feedback.  And, to quell past minor outrage,
the ALTBOOT option was renamed NOALTBOOT.

Specifically...

If you previously used the ALTBOOT option -- which probably means you
are a BreadBox/GEOS Ensemble user since that's the only currently
known application which requires the option -- you should change your
CONFIG.SYS EMM386 line to read NOALTBOOT rather than ALTBOOT.  Users
can specify ALTBOOT, too, but it simply operates as the default EMM386
condition of hooking the INT 9 vector for reboot processing and really
does nothing.  This solution was the best of those suggested to
maintain MS-compatibility with the meaning of ALTBOOT while not
changing the way EMM386 has worked for the past many years.

EMM386 now supports all opcodes of the form 0F0h 020h xx - 0f0h 023h
xx, which is any move to and from a debug register (DRx) or control
register (CRx) via a standard register (EAX, EDI, etc.)  EMM386 does
this by means of self-modifying code which sticks the actual opcode to
be executed in the code segment via our friend the alias selector.
Currently EMM386 attempts to reset the cache after the self-modifying
code by the old standby of JMPing to the next instruction.  I'm hoping
this feeble cache flush/update method still works with all the newest
CPU pre-fetch doodads.  It did work on my Athlon XP 3000+ so maybe
it's okay.  If not, we'll probably have to implement code to a detect
486+ level chip and stuff in a leading WBINVD instruction if >386 or
JMP if not, which is a dorky hack and I don't want to do it if we
don't have to.

EMM386, via the VDS option supports the main locking functions 8103h
and 8105h and their corresponding unlock options 8104h and 8106h.
Actually, 8104h and 8106h do nothing and always report success since
memory isn't really locked; it's never changed by EMM386 from its
original mapping reported by 8103h and 8105h.  Other VDS functions are
not supported and will report to that effect.  If you see one of those
messages, let me know the numbers it reports and I'll add support if
feasible.

Users of the VDS option to load network drivers or other DMA-based
drivers in UMB's should be aware the VDS is a bit more shaky than
things like EMS, XMS, and VCPI and was never as universally embraced
and stabilized.  Be aware that if EMS with EMM386 is voodoo, VDS is
double-voodoo.  Lots of complicated things going on with remapping
memory, rebuffering of DMA on the fly, blah blah blah.  The network
drivers may work, they may not.

As always, should you have any problems let me know.  Should you have
a problem using VDS, unfortunately there is a good chance I may not be
able to duplicate the problem since those are typically tied to a
particular model network card or environment, and thus not be able to
fix it.  Que sera, sera.