MEDC2006 - WinXPembedded and others
Topic: Technology
Was busy after the MEDC2006 i.e to office after 3 days so didn't get time to update earlier

On 2nd day attended the WinXP embedded track to see what it was all about. As it turns out WinXPEmbedded is nothing but componentized WinXP which is normally used in ones PC. Currently only binary modules are provided by MS and that too only for the x86 architecture. As far as drivers are concerned standard PC drivers can be used in WinXPe. Even thou MS seems to have WinXPe for other architectures (powerpc for sure, well almost, why? because Xbox360) internally they aren't giving it to others.

As of now because of lack of support (atleast outside MS) for NonX86 architectures, Relatively large size of resultant WinXPe images (unless MS allows one to build up the GUI and other standard functionalities at the higher level as one likes) and lack of source code support would make it a difficult candidate to use in the embedded world.

One thing I liked about the MEDC2006 india was that it allowed the people who attended the conference to interact with the key speakers and also arranged hands-on tracks inturn handled by these key speakers.

Day One at MEDC2006 - J2ME vs .NETCF, WinCE memory architecture, Arm Emulator and NMD Feature pack
Mood:  down
Topic: Technology
Today I attended the MEDC2006 conference being held at Bangalore. Overall it was ok. Came to know some of the inner working of WinCE, hadn't found time before to look into this :-).

Started with attending a talk comparing WinMobile and Symbian mainly from their virtual execution env (i.e J2ME vs .NETCF). Even thou it was good in some ways, it was too marketing pitch based as far as talking about J2ME was concerned, trying to tell that it is a bunch of headache to develop anything 4 J2ME. Only forgetting that MIDP1 is pretty old (well for that matter even MIDP2) and was targeted to run on realy really resource constrained phones which where available long long time back. And .NETCF would be pretty difficult to run in such a h/w with all its features. So telling that there is MIDP1 and MIDP2 for people to worry about is wrong, for sometime now most of the phones out there support MIDP2. Similarly telling that MIDP2 doesn't need to support Float if you look at the suggestions in the standard, when in reality most of the MIDP2 phones out there would be supporting CLDC1.1 which supports it. And many such ...

Then I attend many of the WinCE internals talks. Which was interesting. Starting with their threading and schedular logic which is some what similar to the realtime threading mechanism in linux(well almost except that almost everything is a thread in wince, which is good in some sense AND chances are even linux will have a slightly better and flexible concept of some threads with priority above some int't handler threads (or any mix and match) by default (currenlty requires to be manually patched at int't subsystem level AND or some other hacks)).

However wrt their Memory management and architecture, I found it strange that the developers didn't try to add support for making the applications position independent by supporting address fixup support at application startup time, well you ask why should they have, then continue reading. It seems WinCE maintains 31 slots (each 32MB in size) in the lower part of the processor virtual memory space for applications thus only 31 (well seems like 29-30) applications can be running in the system at any time. And inturn it always maps the current application to run in a 64MB window (i.e 2 slots) at the bottom, of which the lower slot (i.e 0) holding the application (code, data, heap and stack) space along with Non rom dlls AND the slot 1 holding the core and ROM based dlls. Thus when ever any thread in the system has to run the lower vaddr entries in the system pagetable are patched such that application slot (to which that thread belongs) is also mapped into the 0th slot. Even thou the page table updation required at context switch might be minimal the TLB will require to be flushed of any slot0 related virtual address mappings as they will be remapped to the memory maps for the switched into application. _By_ _letting_ the DLLs remain at a fixed slot(s) in memory across all processes (as is done even now) _AND_ by letting the application remain in its alloted slot (i.e 2-31) (and if required don't map any dll to this space, but to slot 1 and if required slot 0) and not mapping it into slot 0 the need for these TLB flushes and subsequent TLB updation (well almost, depends on dynamics of the system) can be avoided AND also the pagetable fixup required will/should also be relatively minimal.
Hope they either follow some scheme like what I mentioned above (or similar, where the number of lower slots alloted to DLLs is dynamically adjusted based on the need in the system in addition to what I mentioned above or ...) OR move fully away from the slot based management system in their new/coming versions of WinCE (well may be not really this drastic).

Also found that now they have a ARM based wince device emulator, freely downloadable have to check this out.
Today they have announced the availability of NetworkMediaDevice (NMD) Feature pack 4 wince, but the sad part from my perspective atleast is that they have not used their existing RTC framework to add this functionality but have implemented it over a new framework involving uPNP, WebServices, HTTP streaming and their DRM for streaming.