The work I had started towards the ePod - Girder app that is mentioned in the thread above hasn't progressed very far. My approach was for a full embedded Visual C++ MFC app with configurable button layout, multiple screens, Girder application extensions, etc. My test app used static buttons with static control strings and the plain vanilla Girder TCP/IP plugin. I can send my source code to anyone who would like to play with it, although you need to download the embedded Visual C++ compiler from Microsoft. It was available free for private use a couple months ago, and I believe that it still is. It's a TWO CD download, so it helps to have a broadband connection.
In terms of coding for the ePods. I found it easier to develop the code using Visual C++ 6.0 on my Win2000 machine to test and debug. If it worked under 6.0 it should work with a few mods under embedded C++. So the easiest thing for me was to copy the project (.dsp, .rc, .etc files) and source code over to embedded Visual C++. This required some updates to the includes, some mucking with the MFC class names and control interfaces, and finally updating the project settings to use MIPS code generation, Windows CE 2.12 target platform, ActiveSync mechanism, etc. I'm making it sound harder than it is, but it does take a while to figure it all out. It also helps to be familiar with MFC before trying to port Visual C++ 6.0 MFC code over to embedded C++ MFC.
Others were working with Visual Basic and seemed to have progressed farther along.
As a concept I think Girder control using a wireless (wireless Ethernet, IR, bluetooth, etc) TCP/IP connection has lots of potential. Two way communication is a feature that cost $$$$ in high end systems, but with the right software it could be implemented for a few bucks on a HTPC. There are some interesting problems that need to be solved with regards to application status reporting. Namely, a standard way of getting application status information. Intercepting windows messages could work, but the individual messages need to be decoded and that requires understanding the proprietary data in each message. Girder already can do something like this.
however, there is no hard requirement that an application send a windows message to change the state of control or reports the state of a control. It's how MFC works, but if you program your application using other software tools and techniques there are ways to avoid the windows message queue. This would make the message capture technique useless.
IMHO, In the media player world it would be very cool to have a COM/ActiveX like interface that Girder could query for application control and status interfaces. Interface statndards would need to be specified. (Microsoft is really good at this type of stadardization, but they tend to leave application programmers alone and let them do whatever comes to mind) Perhaps, manufactures would release Girder configuration files that specifies how Girder can access these interfaces. One can dream...
