I’m sure a lot of people don’t care about the platform, a lot of other people are interested in seeing our components running on WinCE targets.
A reason why I believe making our GMAE products work on WinCE is interesting, is because of the existing market: mom, pop, bro and sis are not going to flash their expensive devices into a for themselves nearly unusable state. Maybe if you’d pay the shop that distributes the devices to flash it, you might convert a single percentage of the users to your absolute freedom Utopia. Most of them, will not really care and go with the flow.
That doesn’t mean that I don’t like initiatives like what Openmoko and Maemo are doing. Those are great, for the developers. The actual users, usually don’t care that much about the freedom aspect of it. (sure, comment that you disagree and that users do care. Please also post the actual numbers that prove it). The availability of applications that comes with opening a mobile, however, is what its users care about indeed. If this is in an integrated way (with a nice website where they can find the point-and-click installable applications).
We can, however, make software for people who made the decision to buy a WinCE based device. We just have to finish the WinCE port of pthread-win32, get iconv compiling and then build a glib for it. With the relatively new project cegcc it’s easy to set up an environment for cross compiling to a WinCE target. It works a lot like Mingw32. They even have a compiler that is compatible with it (and which seems to be working with autotools nicely).
My first experiments gave me the typical results for iconv and pthread-win32: WinCE has no errno.h, and when faking it you get unresolved symbols about _errno. Such problems are relatively easy to fix. The pthread-win32 library tried to link with wsock32, which I had to replace with winsock. There are some platform dependent parts in the pthread_cancel implementation of pthread-win32. I don’t think glib uses pthread_cancel so you can perhaps initially just ignore this and make it compile with an empty implementation.
The latest version of iconv seemed to be in an even better state. I think the only problem that I had while trying to compile it was the unresolved symbol _errno. Although I think WinCE has its own typical iconv related things.
Making Gtk+ work on WinCE might also be worthwhile. Although my opinion is that D-BUS and glib (including gobject, gmainloop and gthread) are initially more important. Tor did some work on porting Gdk/Gtk+ to Win32, perhaps is a bunch of that stuff reusable?
Once finished, we could run GMAE applications and components on WinCE phones, PocketPCs with native O.S. and a lot of tablet computers. I’m for example very interested in the many ruggedized embedded and mobile devices. For example the Psion Teklogix ones. A lot of companies let their employees use such ruggadized devices in the field. This might be an interesting market to explore with GMAE? And why not? Those companies usually see no reason whatsoever to flash their device with Linux, if their custom Compact Framework .NET application already just works for them. Although Mono might be very interesting for the company who developed that software?