migrate VXD driver to W2000/NT/XP

In the existing code a *.vxd driver is loaded up (with a CreateFile command) and then is talked to with DeviceIOControl commands.  I believe its also the case that a WDM driver might be handled the same way?  That is, and application using the driver would use a CreateFile command on the driver, and then "talk to it" with DeviceIOControl commands -- is that correct?

I don't want to write the WDM driver -- it must exist -- I want to talk to it, somehow similar to how the applciation talked to the *.vxd driver.

Is there any chance that the nature of communication with a modern WDM driver would take the same shape as the with the old *.vxd driver?

DeviceIoControl() is the typical way in which an application talks to a driver.  

So it seems possible that you could implement a NEW driver for your new version of Windows that would behave essentially like your old VxD and could minimize the changes required in your application.

I'm confused by your statement:

"I don't want to write the WDM driver -- it must exist -- I want to talk to it, somehow similar to how
the applciation talked to the *.vxd driver."

Why MUST it exist?  Who has written such a thing?  And if they have, why don't you get from THEM the information on how to talk to it?  If this is a 3rd party driver there is NO guarantee that backward compatibility was among their priorities and so you could well be out of luck.

BTW, generally CF cards do not need to be talked to as generic devices.  Usually the vendor supplied driver implements them as a removable disk I/O device.  And since that interface is relatively standardized you may be in good shape here.  What I don't understand is what this VxD you're talking about does.  I understood from the question that this VxD was your (or your company's) doing.  But it seems that this is not the case.

Why don't you contact the manufacturer and get information on how to interface with their driver?  

Thanks jhance for the time you've already spent on this...

The eixsting driver talks to a CF card, so I think perhaps some company like sandsik wrote it (but not sure - sorry I "inherited" this code a project without much data -- I'm trying to get in contact with a former developer -- my company bought the assets of a former company and this landed on my desk).  

Now I just bought a sandisk card reader (USB) and plugged it into my XP system.  How can I find out about the driver that must have just been installed with that device?  I guess it must be WDM.  Will sandisk tell me how to talk to it?  Then I could adapt the application to talk to this driver.  Looking on sandisk's website didn't get me too far.  Perhaps I'll send them an e-mail in hopes of finding some tech help...  What do you think?

The SanDisk USB card interfact unit is most certainly a WDM driver.  The issue is whether or not the card you HAVE will work with the way the SanDisk is expecting it to work.

This is a bit like putting a MacOS floppy in a Windows box.  Yes, the disks themselves are identical but the filesystem is radically different and Windows does NOT understand the MacOS floppy format without a 3rd party driver that does understand it.

You might be lucky but I'm afraid that the "standards" for storing data on CompactFlash and similar devices are somewhat loose.

Here's a clue.  I have a CF card which the old applciation will read just fine (if its in an adaptor and stuck in a PCMCIA slot on a W95/W98 laptop).  I take that CF card and plug it into my sandisk CF card reader and read off the file.  It is some big *.PIB file -- some proprietary format it seems.  Windows says the CF is formated as FAT, but who knows if it is, or if Windows just assumes this, or is confused.  But in any case, I seem to be able to move the fileoff of it and onto my sytem.

Now I copy that file onto another CF card.  Now I put that card into the adaptor and into the PCMCIA slot and plug into the W98 machine.  Now the app can't read it.

What does this tell us?  I guess it tells us that the data on the CF gets garbled when windows copies it around, treating it as a windows FAT style file?  And that is also why my other experiments to read thru this file looking for 'eVS' (which is supposed to be on there) fail.

So, now my guess is that the data on the card is in some truly bizzare format, and a custom driver is needed to extract the data.

As far as you are not driver writer, then only way to solve your problem is:

- find the driver writer
- provide your VxD source code

In this case (I'm sure) the driver write can write the WDM driver which will allow to keep your application (almost) unchanged.