Subject: Re: You have to start somewhere....
From: Dean Beeler <canadacow@softhome.net>
Date: Tue, 08 Jun 1999 19:38:44 -0500

The secret to all that information was from a program I found called dumplx.exe
from http://www.tbcnet.com/~clive  .  I'm using this output as verification for
my VxD loader.  I forgot to mention it in post last night.

Oh yeah... I think by now we all know about the VxDMon utility by System
Internals.  It was the program that inspired me to take this course of action.

Dean

Sachin Khadilkar wrote:

> Good Job Dean,
>
> You atleast made a head start.
>
> Well here is my contribution :
>
> There is a utility provided by Vireo software called VxDView to see what all
> VxD's on a Windows95/98 box.
> It is a utility provided by them as a compliment to their software which
> lets one write VxD's in C/C++.
> There is also a couple of other utilities there, like Monitor etc. Maybe we
> can use the VxDview sometime in future to see if our VxD is loaded properly.
>
> FYI, i got VxDView to actually work in Linux using Wine.
> here is the url :
> http://www.vireo.com/drivercentral/utilfiles/util.shtml
>
> Also there is a VxDMon utilitility at http://www.sysinternals.com.
>
> Now i have some questions :
>
> 1) How did u print the info in the file unimodem.txt ? i mean just running
> ur winsand with my own VxD does not produce so much info.
>
> 2) Also the VxDmon utility at sysinternals uses the CreateFile API to
> actually load the VxD it uses to monitor other VxD's, i still dont know how.
>
> 3) on my linux box, i dont get a VendorId for my LU 56k PCI modem using cat
> /proc/pci  how do people do that?
>
> Regards
> - Sachin
>
> ----- Original Message -----
> From: Dean Beeler <canadacow@softhome.net>
> To: <discuss@linmodems.org>
> Sent: Monday, June 07, 1999 10:32 PM
> Subject: You have to start somewhere....
>
> >     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.
> >
> > Dean
> >
> >