Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 295
  • Last Modified:

migrate VXD driver to W2000/NT/XP

I have inherited some code which uses CreateFile on
a *.vxd file and then does a bunch of DeviceIOControl calls.  This is to read a compact flash card that is in an adaptor in a PCMCIA slot.  Works on W98.

Since *.vxd is not supported on W2000/NT/XP I need to find a way to get this going.  How, in general, do people migrate from *.vxd technology to the modern OS's?
I guess now one needs a 'kernel mode driver'?  

I'm not a driver writer, so am I looking at a nightmare?

  • 3
  • 3
1 Solution
VxDs are specifically a Windows 95/98/ME thing and they are NOT portable to NT/2000/XP in any way, shape, or form.

You must start over and build a WDM (Windows Driver Model) for your W2K and XP systems and a NT4 (.sys) driver if you plan on supporting NT4.  Yes, this is a real pain but that's Microsoft for you.

Indeed, this entire subject is literally a nightmare.  There is absolutely no way to get by with fewer than 3 different drivers if you need to support the entire spectrum of WIN32 platforms.

My advice would be to scrap NT4 support and focus on 2000 and XP.  The WDM model supports these (as well as Win98/ME in a slightly modified form) so in theory you can probably write one source file and two builds (2000/XP and 98/ME) for your WDM driver and cover the range of currently supported (by MS) Windows versions.  To get Win95 you actually should still be able to use your VxD and that leaves NT4 as the "odd man".  It has it's own driver model and doesn't support WDM or VxDs.

You may want to consider Walter Oney's fine book, Programming the Windows Driver Model.  Even if you don't plan on doing this work yourself, it will give you a good background on what you need to know to farm it out.

Good luck.  This is a nasty problem.
tullheadAuthor Commented:
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?  
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

tullheadAuthor Commented:
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.
tullheadAuthor Commented:
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now