Community
Participate
Working Groups
We should investigate what parts of the TCF Agent use Windows API that's not available on Windows CE (if any), to get a rough idea about porting effort.
To get the TCF agent out of Subversion, use an SVN client such as http://tortoisesvn.net/ or http://www.eclipse.org/subversive The anonymous svn repository access is at http://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent There are Microsoft Studio *.dsw and *.dsp files for building the agent. Any community help or hints would be appreciated to see how it goes.
The main problem to compile TCF for Windows CE is missing header files from the C Runtime Library which is stripped for Windows CE. You can find a reference to the Runtime Library for Windows CE here: http://msdn2.microsoft.com/en-us/library/ms859613.aspx The solution for this problem is to use Windows APIs where using the runtime library is not possible (process and file management from what I have seen). Here is a list of the header files which are missing for WinCE: #include <errno.h> #include <sys/types.h> #include <signal.h> #include <sys/stat.h> #include <sys/utime.h> #include <io.h> #include <fcntl.h> Regarding the Windows APIs which are used, keep in mind that not all of them are available for Windows CE. They are either not supported or have a different name (usually prefixed with "Ce"). Here is a short list of such APIs used in TCF: SignalObjectAndWait GetSystemTimeAsFileTime SHGetFolderPath GetFullPathName Do you have serious intentions about porting TCF for Windows CE? I find this agent interesting and I can help if you want.
We have ported a subset of the TCF agent and got it up and running on Windows CE 5.0. It is not the full TCF agent, only the parts we need to communicate with our target system running windows CE. If someone is interested in this, we could contribute that part (please tell us, how). What we have to offer is a local git repo with a branch based on 1.2-LUNA, containing customizings for CE5.
(In reply to Edwin Bruckner from comment #3) This sounds very interesting, thanks ! - I have 2 questions: 1. How big are the changes, could we get a preview ? (Perhaps exported as "git format-patch" and attached on Bugzilla). This would give us a first rough idea of what we are talking about. 2. Assume your changes are merged into TCF mainstream, could you also offer some maintenance in the sense of letting us know when something breaks ? Eg you run some test automation on your local servers against latest TCF and let us know when it breaks on Windows CE. The background here is that I wouldn't want the WinCE port to become stale when TCF evolves, nobody actively uses CE and we thus don't notice what breaks. Thanks! Martin
(Reply to Edwin Bruckner from comment #4) We have discussed this in our team, and decided to not contribute at the moment: We will wait until someone is really interested in a WinCE port. As long as we are the only ones who are using CE, it seems to make no sense for us. The changes are mainly some #ifdef __WINDOWS_CE__ within the following files: org.eclipse.tcf.agent/agent/Makefile.inc org.eclipse.tcf.agent.cvs_head/agent/Makefile.inc org.eclipse.tcf.agent/agent/tcf/framework/asyncreq.c org.eclipse.tcf.agent/agent/tcf/framework/errors.c org.eclipse.tcf.agent/agent/tcf/framework/mdep-fs.h org.eclipse.tcf.agent/agent/tcf/framework/mdep.c org.eclipse.tcf.agent/agent/tcf/framework/mdep.h org.eclipse.tcf.agent.cvs_head/agent/tcf/framework/asyncreq.c org.eclipse.tcf.agent.cvs_head/agent/tcf/framework/errors.c org.eclipse.tcf.agent.cvs_head/agent/tcf/framework/mdep.c org.eclipse.tcf.agent.cvs_head/agent/tcf/framework/mdep.h org.eclipse.tcf.agent/agent/system/Windows/tcf/pthreads-win32.c org.eclipse.tcf.agent.cvs_head/agent/system/Windows/tcf/pthreads-win32.c Another reason why it is not so easy to contribute is that we are using a POSIX threading library implementation, which is LGPLv2.
Hello Edwin, I think that independent of who else might be using Windows CE, there should be value in your contribution : because for any changes that live in the Open Source repository, you won't have to merge in your changes on your end as the code evolves. It's also kind of a chicken-and-egg problem ... somebody has to start making TCF officially be Windows CE aware in order to spark other adopters' interest. What about following proposal: 1. You contribute as many of your #ifdef __WINDOWS_CE__ snippets as you can - This means fewer files to merge on your end 2. You perform automated builds of TCF master against Windows CE (using Open Source PLUS any additional modifications that you cannot contribute) 3. You let us know (via bug / contribution) in case your build automation breaks. I suspect that this will reduce merge work on your end (much fewer files to keep private) and enable you to pick up tcf updates more often. We won't officially announce full Windows CE support as long as it's incomplete. Still I think there's a win-win situation even with only a partial contribution. The longer-term goal would be moving the WinCE build automation to Eclipse.org servers at some point. Does that make sense to you ? Regarding the posix threading library, I am wondering why you need that when we have pthreads-win32.c in Open Source under EDL ?
