Subject: You have to start somewhere....
From: Dean Beeler <>
Date: Tue, 08 Jun 1999 00:32:49 -0500
Tue, 08 Jun 1999 00:32:49 -0500
    Sorry about posting a binary to the discussion group, but
considering the response, I figured everyone would want to see the
starting point for my LinModem project.  Right now no actual execution
of the VxD happens.  I am trying to make sure everything is in place
before I attempt anything like that.
    Right now it will list the exports and objects present in the VxD
for debugging information.  I have included unimodem.vxd for an example
but if you have other VxDs you want to toy with just specify them on the
command line.  I wouldn't be too surprised if this current version
compiled with even a DOS C compiler (no VxDs > 640K, of course).
Presently there is more commenting and stubs than real source code.
    Someone said something to the effect that VxDs run in Ring 0 which
is why they won't work in Linux.  This may be true, and we will
certainly find out how much freedom is needed once we start trying to
initialize the VxDs using kernel level threads.  Kernel level threads
are also what Wine uses to run its Windows executables as well.  But
I've been thinking... ok... how hard is it to control these DSPs in
hardware anyway?   Besides sheer CPU power, all you are doing is simply
IRQ requests, I/O accesses and Co-processor use.  The free reign of
memory featured by Ring 0 wouldn't be a concern... I don't think.  Mind
you, I've never taken on an emulation project either so I'm sure I'm in
for some surprises anyway.
    Finally, if someone could tell me about the driver configuration for
these seemingly popular Lucent WinModems so I could get some idea how
uniform the whole VxD/WinModem is between developers.
    Feel free to modify the code and give me the changes.  Next on the
agenda is to bring up the DDB points including the API entry point.
Once there, I'll make sure the VxD is in memory correctly and try
threading to it.


["application/x-gzip" not shown]