How to make a working XGE driver

Drivers are "linked on the run" to the main program.
Initially i planned to use sort of automatic linker
capable to link-in object code, but decided do not follow such method
(not enough time to devenlop a thing capable to work with every
 object code format, ad "program security" issues).

The current XGE DRIVERS RELEASE ZERO ( XVD0, XSD0 )
are simple binary images containing code "partially" self relocatable.
All code gets loaded in the same segment, i don't want to hear of
multiple segments no more (besides they slow down operations in prot mode).

Every driver must be a single 32bit segment and start with and ORG 0
directive (so we are sure code and data offsets are "counted from zero").
When you perform jumps, always use BRANCHES (relative jumps)
and when you access local data use EBP as an index
(when a driver function is called, usually it receives EBP
 loaded with the starting offset at wich the driver code has been loaded)

So if into the driver you declared:

Beer dd 0

    You can load 'Beer' into eax with:

        mov eax,[ebp+Beer]

    [The driver is compiled thinking that the driver starting offset is zero
     so using the ebp register we correct this]

Some driver functions do not receive EBP loaded as described
(ESPECIALLY the ones that are usually called from ISR routines
 where God only knows where is the stack segment)

But you can "Fix" this in an easy way.

        If you want to "relocate" the
        mov eax,<value of Beer>
        instruction using edi as a base register....

        At routine start put
        align byte
Hack:   mov edi,12345678h ; (load edi with a 32bit immediate value)
        .......
        mov eax,[edi+Beer]
        ......

        And in the driver initialization routine (surely it gets EBP
        set to base address) do this:
        mov esi, offset Hack
        mov [ebp+esi*1+1],ebp  ; replace 12345678h with EBP value

I know, this look not very clean, but don't you really need it in many places
just on 2..7 positions in the worst case.

N.B  USE BYTE ALIGNMENT WHERE YOU HAVE TO FIX THINGS
     (different alignments usually causes the insertion of NOP opcodes
      between an instruction and another so you don't know exactly
      where is the instruction you want to fix)

When you compile the driver, COMPILE IT TO BINARY FORMAT
[ compile it as an EXE file, the use the EXE2BIN utility to get the
  final binary image (same format as a *.COM file but program and data
 starts from offset ZERO) (COM files starts ar offset 100h )].

As an added bonus i decided to "freeze" the format of the data at the start
of the code32 segment, so using the head32.inc include file
you can reference directly the virtual registers and some other
useful variables/pointers declared into 386power.

See makefile and drivers' source files for more info.