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.
"Paul G. Tobey [eMVP]" wrote:
> 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.
>
> "Davis Gentry" <(E-Mail Removed)> wrote in message
> news:C1681866-8E52-4D86-9342-(E-Mail Removed)...
> > 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
> >
> > "Paul G. Tobey [eMVP]" wrote:
> >
> >> 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.
> >>
> >> "Davis Gentry" <(E-Mail Removed)> wrote in message
> >> news:BD1F059F-1C1B-4B1C-AAD0-(E-Mail Removed)...
> >> > 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
> >>
> >>
> >>
>
>
>
|
Similar Threads
