driver development

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We have an existing driver/control (in .ocx and also the base .dll) for use
in talking to our controllers across ISA, VME, PCI, USB, Ethernet, and RS232.
It is programmed in VC++ and recently recompiled under VS.Net. I have a
request to use the control to program an interface which will run under WinCE
and which will talk across ISA (well, PC/104 to be technical). Do we need to:

a) Do nothing - use the control through VC# .Net to develop an interface
using the compact framework and all is beautiful?

b) Recompile our control/driver under the compact framework?

c) Totally rewrite our driver to run under WinCE?

My suspicion is that the answer is c .

Thanks,

Davis Gentry
 
a) Well, no you can't just copy your desktop executable to the device and
have it work (it won't access memory/I/O the same way, either, on CE).

The actual questions that we have to ask fall outside what you've told us:

1. How many applications and what type will be accessing this interface? If
you're going to have C/C++ clients, you can't use managed code for this. If
you will have multiple application programs trying to access the hardware at
the same time, I think you should use a regular CE driver to serialize those
accesses.

2. What type of device is this? Is it something for which there is a
standard interface in Windows CE? Serial? Network? Display? If so,
you're much better off writing the correct kind of driver (in C/C++, of
course, since you can't use managed code for that). The right group for
questions about driver issues is microsoft.public.windowsce.platbuilder.

Paul T.
 
Thanks for the answer. We provide our driver for use by our clients in
talking to our products. We support only Win2k and up, and development using
our driver under Visual Sudio or Delphi.

Our driver is programmed as an MFC app. I was hoping (though not really
expecting) that as we are using only MS standard calls we could port the code
directly to WinCE with no changes.

Davis Gentry
 
Oh - to finish answering the rest of your questions - typically the client
only has one app running which accesses our drivers. The driver uses the MS
standard devices for accessing the hardware ports (serial, bus, etc).

Davis
 
Wait a minute... your driver is an *application*? You're either mixing your
terms incorrectly all over the place or something very much odder than that
is afoot.

Are you saying that the interface to your hardware is *not* a driver, but an
ActiveX control? If so, you *may* be able to recompile for Windows CE, but
certainly *not* with VS.NET. Use eMbedded Visual C++ for this. Note,
however, that not all of MFC from the desktop is there. Furthermore, not
all Windows CE devices support out-of-process COM, so you'll have to check
your target devices for compatibility. If no-OOP COM is there, you'll have
to rebuild your control as an in-process object, although you may still be
able to use MFC. Again, eVC must be used.

I'd estimate the chance of 'no changes' at 0%, since you are presumably
talking to the hardware and mapping the memory space of the hardware (if
it's memory-mapped), is going to be different than Win2000. If it's I/O
mapped, maybe 5-10%...

Paul T.
 
Bus access is *not* standardized. Serial I/O is performed the same in
Windows CE as on the desktop with the exception that overlapped I/O is not
supported.

Paul T.
 
Ok - thanks - that pretty much answers my questions. We have an ActiveX
control (.ocx) which talks to our hardware through our driver (.dll). And
yes, we do map memory for the ISA and VME cards, though we are using memory
assigned by Windows when it sees the PnP device for PCI, USB, and Ethernet.

All of which pretty much says that, as you state, we'll have to start from
scratch using eVC to make everything work the way it should.

Thanks much.
 
Back
Top