XPe headless user application

[John Keenan]

I have an existing application with a MFC user interface on one thread and
some continuously running calculations on another thread. I am toying with
the idea of splitting this application so the continuously running
calculations run as a headless user application on a headless XPe system.
The embedded user application would need to support a remote user interface
that would connect to it for monitoring and configuration purposes. I am
trying to determine what options are available for a headless XPe user
application to support a remote user interface (what has worked well; what
looked good but added too much overhead to the embedded system; etc.).

I believe the quickest time-to-market solution would be to place a COM
interface between the existing MFC user interface and the continuously
running calculations. The user interface would become a standalone
application that would use COM to remotely connect to the embedded user
application.

An alternative would be for the embedded user application to support a web
server allowing a web browser to be the user interface. Of course this would
entail new development to support the web interfaces.

I would appreciate any references/comments/suggestions of these options and
alternative options and their pros and cons.

John

 

[Slobodan Brcin \(eMVP\)]

Hi John,

Why do you need MFC user interface if you are going to run calculations only on headless device?
White application with one thread only and at the beginning of the loop read data from sockets or some other simple mechanism for
remote transfer of data.
Your user application should be on remote site not on XPe device, right?

Why do you need web server? This task sound basically very simple, but it might be due to lack of info what this application should
do.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do have an opinion on the effectiveness of Microsoft Windows Mobile and Embedded newsgroups? Let us know!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

John,

Is your target device going to be headless?
Then have you considered RDP option? I mean without changes to in your app you can just RDP to the target box and see the app UI and
current state.

Or did I miss anything from your requirements?

Btw, DCOM approach may not be a bad choice if you properly designed your app at first place.

Also, if the communication between the UI and calculation threads are simply data transfers, you can think of two apps network
separated. The communication channel between the apps could be implemented with a network named pipe, a TCP/IP connection, a shared
mapped file, a database, DCOM, etc.

 

[John Keenan]

Slobodan,

Why do you need MFC user interface...

Normally the application will run without the user interface and without
user intervention of any kind. Input and output is handled separately. But
the remote user interface is required to monitor and configure the
application dynamically.

Your user application should be on remote site not on XPe device, right?

The application will be on a remote, headless, XPe device.

Why do you need web server?

I need some means to dynamically attached a user interface to the
application running on the remote, headless, XPe device. The web server idea
is simply one idea on how to accomplish this.

I am curious how others have chosen to dynamically attach a user interface
to a headless application running on a remote, headless, XPe device.

John

Hi John,

Why do you need MFC user interface if you are going to run calculations only on headless device?
White application with one thread only and at the beginning of the loop

read data from sockets or some other simple mechanism for

remote transfer of data.
Your user application should be on remote site not on XPe device, right?

Why do you need web server? This task sound basically very simple, but it

might be due to lack of info what this application should

do.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do have an opinion on the effectiveness of Microsoft Windows Mobile and

Embedded newsgroups? Let us know!

 

[John Keenan]

KM,

Is your target device going to be headless?
Yes.

Then have you considered RDP option?

I am not completely familiar with the capabilities of RDP. I will have to
read up on it and experiment with it to determine if it will satisfy my
immediate needs. However, the application must eventually become a Windows
service so I am still interested in how to dynamically attached a user
interface to a headless application running on a remote, headless, XPe
device.

Btw, DCOM approach may not be a bad choice if you properly designed...

The application is well architected objects.

Also, if the communication between the UI and calculation threads are

simply data transfers...

The communication is not really simple data transfers. It is well
architected objects talking to each other. I can see how to write interface
objects to transform the communication to simple data transfers. I am
curious if others have found this approach beneficial to DCOM.

John

John,

Is your target device going to be headless?
Then have you considered RDP option? I mean without changes to in your app

you can just RDP to the target box and see the app UI and

current state.

Or did I miss anything from your requirements?

Btw, DCOM approach may not be a bad choice if you properly designed your app at first place.

Also, if the communication between the UI and calculation threads are

simply data transfers, you can think of two apps network

separated. The communication channel between the apps could be implemented

with a network named pipe, a TCP/IP connection, a shared

 

[Sean Gahan]

John,
I don't know if you plan on including the .net framework (don't laugh), but
if you do then you might look at this web server; it is a modified version
of the cassini project from asp.net, you can find it at xpefiles.com:
http://www.xpefiles.com/srOut.cfm?sortid=date&fileid=mss&selectid=109&commentRB=&fileRB=&bothRB=true
with this solution you could have a web interface or use web services. Also
have you looked at Remoting, MSMQ, or COM+. MS recently had a webcast that
covered some of the following topics:
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032256981&Culture=en-US

Regards,

Sean Gahan

 

[Slobodan Brcin \(eMVP\)]

Hi John,

You mentioned in another place that you want to create this application as service at the end.

I personally would make this application to use directly TCP trough sockets. In this way you can make small XPe image, simple
communication between your application on XPe device and User shell application on other device with monitor.

Since you are writing application I don't see a need for creating user interface for application that will run on XPe device and
then try to control it remotely as if user was there. (This approach would not work with services anyway.)

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do have an opinion on the effectiveness of Microsoft Windows Mobile and Embedded newsgroups? Let us know!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KM]

John,

To make it easy, RDP simply reflecting display activities on a remote side.

Not sure what kind of recommendations you are lookng for.

I have done some distributed system but not in embedded space. For instance,
one of my projects was a distributed system including MS IIS (ASP), SQL
Servers, some good powered machines to do serious calculations (online Risk
Management if it tells you anything). However, that was more Desktop OS
based system (some servers, some workstations). In that application, DCOM
helped me much for many reasons. However, that time .Net wasn't there
otherwise I would move to that as it simplifies development of distributed
systems very much.

I don't know how easy this applies to your case. My personal opinion that
DCOM is heavy (if not too heavy) stuff for an embedded device unless you
have already gotten an app written with COM. It depends, of course, much on
the target hardware and device specifications you get.

If you, for instance, stick with some easy way of communications - named
pipes, TCP/IP, sockets, etc. - the XPe image would be much smaller and
optimized.

If you still think about DCOM, look at the Sean's reply. Net may be a good
choice for you unless, again, you have to do a major rewrites of your app.

Regards,
KM

 

[John Keenan]

(This approach would not work with services anyway.)

I was aware that a service (by design) could not directly display a user
interface. But I was *not* aware of further limitations. It was my
understanding that a service could support a DCOM connection or a web server
(which are glorified socket connections under the hood). Could you please
explain why you think these approaches would not work.

John

Hi John,

You mentioned in another place that you want to create this application as service at the end.

I personally would make this application to use directly TCP trough

sockets. In this way you can make small XPe image, simple

communication between your application on XPe device and User shell

application on other device with monitor.

Since you are writing application I don't see a need for creating user

interface for application that will run on XPe device and

then try to control it remotely as if user was there. (This approach would

not work with services anyway.)

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do have an opinion on the effectiveness of Microsoft Windows Mobile and

Embedded newsgroups? Let us know!

 

[John Keenan]

To make it easy, RDP simply reflecting display activities on a remote
side.

Is RDP the same as "Terminal Server Client"? My last experience with
Terminal Server Client (about 3 years ago on Windows NT4SP6) was a bit
disappointing. You could easily unknowingly log off the remote desktop
causing all remote desktop applications to terminate. Does RDP provide
protection against this?

Not sure what kind of recommendations you are looking for.

Just looking for personal opinions on what has worked well; what looked good
but added too much overhead to the embedded system; etc.

My personal opinion [is] that DCOM is heavy (if not too heavy) stuff for

an embedded device

Wouldn't this same opinion apply to .net? Or is .net significantly lighter
weight than DCOM?

John

 

[KM]

John,

Is RDP the same as "Terminal Server Client"?

Not the same but from the same opera. RDP is the protocol used by the TSC.
You can read it more here:
http://www.microsoft.com/windowsserver2003/techinfo/overview/termserv.mspx
Again, the suggestion to use RDP was only to not touch your apps (easiest
solution).

My last experience with Terminal Server Client (about 3 years ago on Windows NT4SP6) was a bit
disappointing. You could easily unknowingly log off the remote desktop
causing all remote desktop applications to terminate. Does RDP provide

protection against this?

Your experience is way too old with this (not to offend but just fact).
You should try RDP to your XP Pro machine to see how it works now.
Also, there is a latest update from MS for RDP (5.2) available (customized)
for XPe:
http://www.microsoft.com/downloads/...7f-c439-4e7c-8d4e-9c4f65c09dc4&DisplayLang=en

My personal opinion [is] that DCOM is heavy (if not too heavy) stuff for

an embedded device

Wouldn't this same opinion apply to .net? Or is .net significantly lighter

weight than DCOM?

No .Net is even heavier. But the Sean's point was, I believe and I agree
with that, that since you were looking at DCOM as an option, .Net may be a
better option for you. The image would be still pretty big but you gain much
more functionality (e.g., Web Services) that is really easy to use, much
stable, very perspective (meaning that MS will definitely support ado about
the .Net for a few year at least. Using .Net may turn in pretty rapid
development for you, especially if you know what your apps have to do.

Regards,
KM

 

[John Keenan]

I don't know if you plan on including the .net framework (don't laugh),

Without any real evidence I had concluded .net would be too heavy to
support.

Also have you looked at Remoting, MSMQ, or COM+

Have not but will. By remoting I presume you are referring to remote
desktop?

John

 

[KM]

John,

Sean might have referred to .Net Remoting...
http://msdn.microsoft.com/library/d...-us/cpguide/html/cpconnetremotingoverview.asp

That makes more sense in the context.

KM

 

[Slobodan Brcin \(eMVP\)]

Hi John,

Yes service could do that. You can even make it interactive with user. Probably you could even write it (god forbid) in .net, but
this choice will actually depend on your device requirements and your programming knowledge. If you know DCOM and do not know to use
sockets or pipes and little heavier XPe image is not a problem then you can use them.

My preferred way of doing thing is to keep high level Windows support usage as low as possible. (Preferably to do everything that
can be done at driver or basic API level).

I do not try to persuade you in anything, choice is always yours (you know the best what you want to do), I merely try to give you
one of possible paths how to do things.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do have an opinion on the effectiveness of Microsoft Windows Mobile and Embedded newsgroups? Let us know!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[John Keenan]

Slobodan, Sean, KM,

I thank you very much for your ideas, suggestions, and links. I now need to
research and evaluate the various options.

Thanks again,

John

 

[Sean Gahan]

John,

Without any real evidence I had concluded .net would be too heavy to

support.

Sorry, but I had given you the wrong link to the webcast. You will have to
look for "Dave's Tour of Middle-Tier Options" which will be available next
week on the webcast page
http://www.microsoft.com/seminar/events/webcasts/ondemand.mspx . I have
the ppt from this webcast and if you want a copy let me know and I can
upload it to my server and provide you a link or if you prefer I can email
it to you (it's 2.2 megs zipped). The unfortunate reality is that .Net
has a lot to offer but it comes at a very hefty price; as of yet the .net
framework is not componentized and so therefore you must install the entire
framework. The framework has lots of dependencies, for example there is a
dependency on winlogon. With winlogon you are going to get the explorer
shell and that too will have dependencies. Basically, the .net framework
will add a lot of depth to your application base but there is a steep price.


< Also have you looked at Remoting, MSMQ, or COM+

Have not but will. By remoting I presume you are referring to remote

desktop?


Remoting is for Inner Process Communication (IPC), this is the fastest form
of IPC. It uses either tcp or http channels for communication
http://msdn.microsoft.com/library/d...-us/cpguide/html/cpconnetremotingoverview.asp



MSMQ is Message Queuing; it's also for IPC and is kind of like email for
applications. The message sits in a queue until removed; this is good when
you have to make sure that some other application gets updated.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetasync2.asp


COM+ is really broad and has a lot of flexibility. It allows you to control
the lifetime of apps, or how much resources the app can use cross database
connections, or even if the app needs to be exposed as a web service. One
of the key things about COM+ is security; it is secure right out of the box,
and that is not the case with the other technologies. Some articles on
COM+:
http://msdn.microsoft.com/msdnmag/issues/01/08/ComXP/default.aspx

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomser/html/complus.asp

http://msdn.microsoft.com/library/d...y/en-us/dndotnet/html/xpandnetintegration.asp



By the way, if you are interested in any of this technology then you really
need to see the "Dave's Tour of Middle-Tier Options" web cast. I can't say
enough of what a great job the presenter did with the technology.


Regards,



Sean Gahan

 

[Dave August]

I'll toss my 2-cents in here...

I've recently developed an aplication that speaks to other instances of
itself over the net... It's an MFC app and passes LOTS of MFC objects back
and forth... I derived a fairly straightforward (clever but straightforward)
class from the CSocket class and pass both the origonal windows messages and
MFC data over it... if you are not aware the CSocket class support Archives
so sending/receiveing an MFC class (derived from CObject and DECLARE_SERIAL)
is no harder than >> or <<, you can also use runtime class info on the
receiveing side to generate the objects 'on the fly' without knowing what
they are... FWIW the real 'magic' here is that the app is just responding
to normal Windows messages.. it has NO idea that they are comming over the
net...

This scheme would certianly work for communicating with your thread...

Dave August

 

[John Keenan]

Dave,

the real 'magic' here is that the app is just responding
to normal Windows messages

Where do you plug into the message pump?

John

 

[Dave August]

The CSocket has an OnReceive function.. (It actually creates a hidden window
to trip off this function).. That gets called when data is available.
My derived class takes a CWnd* and OnReceive just passes the "messages" on
to that window... You obviously set this when you create the socket and
"listen".

If you derive the CSocket correctly it can do all the work, be both the
"local"(server) and "remote"(client) including listen and do a
RUNTIMECLASS->ObjectCreate() to launch a copy of it's (derived) self to
connect to the Accept... and if it's done right you can derive from it and
not touch any of the listen/accept code.. (the magic of RUNTIMECLASS)

I have a simple bool that tells the app if it's a "remote" version or *THE*
local version...
All my message handlers check the bool and either handle the message localy
(do what they would normaly) or pass the message over the net...

If you are REALLY clever you can create a "message" class that you pass over
the socket... and do RUNTIMECLASS at the far end to figure out if there are
just wParma and lParm as arguments or MFC objects and if so instanciate
them, read them, and pass them as arguments to the windows message...
I use SendMessage so any instanciated objects can be destroyed by the caller
(OnReceive) but you sure could use PostMessage if you knew you had to delete
them yourself...

It a pretty simple model and damed if it dosen't work!
Dave August