Re: Using COM OutProc server on WinCE
- From: "John Spaith [MS]" <jspaith@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 20 Oct 2006 11:58:27 -0700
I've been asked this enough I've tried to cleanup the answer to this and
related questions a bit --
http://blogs.msdn.com/cenet/archive/2006/10/20/windows-mobile-does-not-support-out-of-process-com.aspx
I don't dig as much into specifics as we go into on this thread, but my hope
is that should be enough to kick start a 'aguliani' and shave a few days off
the response times.
For getting your stuff signed for a real device, I think there is a bunch of
work here but for your development purposes as I wrote below I don't think
it'll be that bad to recompile, it's just figuring it out the 1st time
that's tricky.
--
John Spaith
Development Lead, Windows CE
Microsoft Corporation
Check out the CE Networking Team Blog at http://blogs.msdn.com/cenet/.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2006 Microsoft Corporation. All rights
reserved.
"aguliani" <aguliani@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A462F071-1164-4510-B3E2-6B7ABF3D1D93@xxxxxxxxxxxxxxxx
Thanks again for the comments. I am trying to get ore information on
signing because if signing procedure is like getting WHQL then I have to
stay
from it as I do expect my UI to change very often and we can't afford to
get
certification every time we make the change and I also asusme that using
COM
inproc server should be OK on WM5.0
"John Spaith [MS]" wrote:
1) In CE 5/WM5, it is very easy to move code back and forth between
device.exe & services.exe if you're not using any special device.exe
stuff
(like say talking right to hardware) or services.exe stuff. You can
absolutely popup UI from device.exe, so putting your myservice.dll as a
device driver would work and there would be no IPC needed. You're also
correct about the UI code needing to be part of your driver. So in the
short/med-term you'll be fine. Long term be aware that in CE 6.0 we've
rewritten the kernel, device.exe is going away and everything will run in
nk.exe (kernel process) and you can't popup UI from nk.exe in CE 6.0.
However, when you get CE 6.0 and it's the basis of a WM device (I can't
say
when that'll be, but won't be for a bit) there are mechanisms to have
kernel
components like your myservice do IPC to a UI Based "service" running in
user mode to get around the no UI in kernel limitation.
You have to have your DLL signed to run in either device or services,
they
key off the same signing logic as far as determining trust/untrust.
2) I'm embarrased to say I'm pretty far removed from ISV development of
services on WM, I don't know about how you get this signed for real.
However I believe there is an SDK Test certificate and you can install
this
somehow on your development WM device as something you trust, and then
sign
your app with this during your development so that you don't get bogged
down. I don't know anymore details on this I'm afraid.
If your service has to send notifications it's possible to do this with
your
app waiting on an event or other mechanisms, but at some point (it's not
an
exact scinece) your service becomes less like a service and more like
some
peer-to-peer type scenario.
3) i'd really like to steer you away from writing an exe, especially if
it's
long-running as it sounds yours is. CE 5.0x based kernels only support
32
processes, and on a lot of WM devices you're at like 20+ processes when
the
device boots, which is why we try to push so much stuff into services.exe
even if we just need services.exe to act as the "WinMain" equivalent in
starting up the service so it can startup worker threads & do its thing.
--
John Spaith
Development Lead, Windows CE
Microsoft Corporation
Check out the CE Networking Team Blog at http://blogs.msdn.com/cenet/.
This posting is provided "AS IS" with no warranties, and confers no
rights.
You assume all risk for your use. © 2006 Microsoft Corporation. All
rights
reserved.
"aguliani" <aguliani@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:460CA1CC-F3E9-4C2F-BFF9-EF7C335FC60F@xxxxxxxxxxxxxxxx
Thanks for the useful reply. My original XP application that I want
to
port on CE and WM5 is a wireless application (like MS Windows Zero
Config)
and I am having myUI.exe that loads myAPI.dll and a myserver.exe that
runs
authentication/association engine etc so I am not sure if I merge them
then I
would be able extend it in future.
Anyways I went to all the links mentioned by you and have few questions
1) On CE it seems that device.exe hosts both the wzcsvc.dll and
wzcsapi.dll
so I want to know if I can also host my myserver.dll and myapi.dll also
on
device.exe. If yes then I guess there won't be any interprocess
communication
issues. Is it correct? Also I am assuming that my UI code has to be
part
of
myapi.dll else I will see the same interprocess communication. Do my
dll
has
to be signed if it has to be hosted by device.exe?
2) If instead of device.exe I use services.exe mentioned by you then it
is
mentioned that my "service DLL has to be signed to be trusted and
loaded
by
services.exe" so does it mean that every time I change the version of
my
dllI
have to get signature files from Microsoft? Also services.exe works on
client-server model but my server(myserver.dll) has to issue
notifications
to the client so I guess in that scenario services.exe won't be
helpful.
Is
this correct?
3) So I might end up writing an myui.exe that will host my single dll
(myserver.dll+ myapi.dll) and I want to know if it is preferred option
in
CE
and WM5.
Thanks
aguliani
"John Spaith [MS]" wrote:
Windows CE 5.0 (general embedded) actually does have an out-of-proc
COM
Server (you'd need SYSGEN_DCOM, see
http://blogs.msdn.com/cenet/archive/2005/04/27/412600.aspx about
adding
components to a CE device). You're right though on WM5 you wouldn't
have
out of proc COM, so best not to mess with it.
I have a blog about different IPC mechanisms on CE -
http://blogs.msdn.com/cenet/archive/2005/07/13/438424.aspx. In this
case,
if you have a clear differentiation between a client & server piece to
this
(eg part A always calls part B), then you could potentially move the
server
part into services.exe where you can create a special fcn to receive
calls
like this, this is in fact how we on CE port RPC servers -> CE. White
paper
on services at
http://blogs.msdn.com/cenet/archive/2004/12/15/316007.aspx.
(My long-term goal is to be able to answer any newsgroup questions via
blog
links :)).
For your case, have you considered a bigger rearchitecture and putting
both
the executables into one giant executable so you can just use in-proc
COM?
This would be easiest, though don't know if architecture lends itself
to
that or no.
--
John Spaith
Development Lead, Windows CE
Microsoft Corporation
Check out the CE Networking Team Blog at http://blogs.msdn.com/cenet/.
This posting is provided "AS IS" with no warranties, and confers no
rights.
You assume all risk for your use. © 2006 Microsoft Corporation. All
rights
reserved.
"aguliani" <aguliani@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D67B002C-0452-4B25-A002-EB9044A99924@xxxxxxxxxxxxxxxx
I have an application that uses COM OutProc server and I have to port
it
to
WinCE 5.0 and WinMobile 5.0 and I found out that COM outproc server
is
not
supported on WinCE 5.0.
One option for me is to remove COM and implement my own RPC
server
and
client but this might take so is there any way to make existing code
work
on
winCE. I am also using Monikers in my code.
aguliani
.
- References:
- Re: Using COM OutProc server on WinCE
- From: John Spaith [MS]
- Re: Using COM OutProc server on WinCE
- From: aguliani
- Re: Using COM OutProc server on WinCE
- From: John Spaith [MS]
- Re: Using COM OutProc server on WinCE
- From: aguliani
- Re: Using COM OutProc server on WinCE
- Prev by Date: Re: Exception launcing processes
- Next by Date: Re: Exception launcing processes
- Previous by thread: Re: Using COM OutProc server on WinCE
- Next by thread: Re: Suggested Project Type for Building ISAPI Extensions for WinCE in
- Index(es):
Relevant Pages
|
