Tuesday, November 25, 2003
Windows CE 32 Process Limitation: The Ugly Truth
Posted by Jason Dunn in "ARTICLE" @ 01:11 PM
There's just no nice way to frame this: Windows CE 4.2 has a limitation of 32 simultaneous processes. Why is this a problem? Because of the increasing complexity of hardware in devices that now require more software to control them, and also because of developers not always choosing the most efficient route, Pocket PCs like the XDA II are especially vulnerable to this limitation. Arne Hess has write up an article that explains it all:
"Maybe you've also read the rants that the new i-Mate Phone Edition/xda II/MDA II isn't able to handle larger applications and closes other programs in the background if you open a new one. In fact this statement is wrong! The real problem is a different one and it is because the Windows CE platform isn't able to handle more then 32 processes simultaneously! This is - according to my sources (which I also already get confirmed from other sides) - a design limitation which already was introduced with Windows CE 1 and never were expended - even not with today's Windows CE 4 platform.
The result is if a user starts the 33rd process, any of the processes, running in the background is killed by the system. In "best case" it's an application you've launched only, in worst case it's a Windows CE task. Users never have seen it before because by default Pocket PCs were never running that much processes after a softreset. Unfortunately it's different with the HTC Himalaya platform because by default it's running the typical Pocket PC apps plus the Pocket PC Phone Edition applications plus some HTC and O2 customized stuff like Bluetooth, IA Caller ID, IA Camera and for the O2 version O2 Active UI. This means that on a xda II something around 26 tasks are already running in the background - right away after a softreset. Now imagine if you install Spb GPRS Monitor, Pocket Plus and Fullscreen Keyboard also! One task is left for a customer application. Now start ActiveSync which starts 3 tasks by itself and you are done! Your device will need a softreset!..."
The good news is that Spb Software House has come up with a way for developers to stack multiple processes under a single process (thread), so if the majority of developers use this process, it will go a long way toward alleviating this problem. Spb will be publishing an article about this in the next couple of weeks.
"Maybe you've also read the rants that the new i-Mate Phone Edition/xda II/MDA II isn't able to handle larger applications and closes other programs in the background if you open a new one. In fact this statement is wrong! The real problem is a different one and it is because the Windows CE platform isn't able to handle more then 32 processes simultaneously! This is - according to my sources (which I also already get confirmed from other sides) - a design limitation which already was introduced with Windows CE 1 and never were expended - even not with today's Windows CE 4 platform.
The result is if a user starts the 33rd process, any of the processes, running in the background is killed by the system. In "best case" it's an application you've launched only, in worst case it's a Windows CE task. Users never have seen it before because by default Pocket PCs were never running that much processes after a softreset. Unfortunately it's different with the HTC Himalaya platform because by default it's running the typical Pocket PC apps plus the Pocket PC Phone Edition applications plus some HTC and O2 customized stuff like Bluetooth, IA Caller ID, IA Camera and for the O2 version O2 Active UI. This means that on a xda II something around 26 tasks are already running in the background - right away after a softreset. Now imagine if you install Spb GPRS Monitor, Pocket Plus and Fullscreen Keyboard also! One task is left for a customer application. Now start ActiveSync which starts 3 tasks by itself and you are done! Your device will need a softreset!..."
The good news is that Spb Software House has come up with a way for developers to stack multiple processes under a single process (thread), so if the majority of developers use this process, it will go a long way toward alleviating this problem. Spb will be publishing an article about this in the next couple of weeks.
