Spb Publishes Article, Tools To Circumvent 32 Process Limitation

[Janak Parekh]

<div class='os_post_top_link'><a href='http://www.spbsoftwarehouse.com/about/pressreleases/2004/feb26.html?en' target='_blank'>http://www.spbsoftwarehouse.com/abo...4/feb26.html?en</a><br /><br /></div>"Spb Software House is pleased to announce the release of a free solution for developers to the Windows Mobile 32 process limitation problem. The most common methodology used by Pocket PC developers for implementing background tasks is to create executable files which are stored in the Windows/Startup folder in order to ensure that the program is automatically started following a reset, and continues to run in the background. The problem comes in that the Windows CE operating system limits the number of processes running to 32. For example, in XDA II Pocket PC devices, 28 processes automatically start running immediately after a soft-reset, thus leaving you with only four possibilities for new processes, which limits the number of programs you can run. The Spb Software House solution counteracts this limitation, and developers can implement this solution free of charge within their applications."<br /><br />The fundamental aspect of this approach is to lump all of the background startup tasks under one process called SERVICES.EXE. This functionality is built into WM2003, but not under Pocket PC 2000 or 2002, so they've also built a solution for those two platforms. If you're a developer on any of the three, and writing some of these applications, you might want to give this article a serious look.

[mashtim]

I was just wondering about this limitation recently with all the WiFi/BT/GPRS devices that are being announced lately.
I know that it affected the XDA2 and that is primarily what kept me from getting one. Well, that and the fact that AT&T gouges their customers for data, but that's another issue for another place.
I wonder, though, if this issue will affect the iPaq 6000 series.

[JonnoB]

I will be sure to bring this up at the MDC next month when I am there.

[Jason Dunn]

I will be sure to bring this up at the MDC next month when I am there.

Indeed - the more developers know about this, the sooner this problem will get fixed.

[dlangton]

Is there any way that the tools could be modified so that end users could add a service via some sort of dialog? Obviously, this would require using an exe rather than a dll file as the object, but I'd think that shouldn't be a problem.

[Jason Dunn]

Is there any way that the tools could be modified so that end users could add a service via some sort of dialog? Obviously, this would require using an exe rather than a dll file as the object, but I'd think that shouldn't be a problem.

No, I don't believe so - this is really something developers need to take on and incorporate into their code. The best thing you can do is point every developer of every application you have towards the press release that has the links and info they need.

[sponge]

I don't understand, if it lumps everything into services.exe, why does it need to be implemented dev side?

[Janak Parekh]

Because (read the article ;)) the dev must implement their task as a DLL that's associated with SERVICES.EXE.

--janak

[Sedwo]

hmmm.... So does the application program still show up in the Memory Process Viewer when it is under Services.exe? And if it crashes, can you kill it seperately, or you simply have to kill the entire Services.exe tree? Can you even kill the Services tree?

This looks very "cludgy" and am opting to leave the resolution up to Microsoft in raising the 32 Process limit. The OEM developers with specific drivers for their device should be the first to make this Services change. ISV's developing full blown applications should then be the last (if at all). Life is easier for developer and user if they're working with an .EXE rather then .DLL's.

[Jason Dunn]

This looks very "cludgy" and am opting to leave the resolution up to Microsoft in raising the 32 Process limit. The OEM developers with specific drivers for their device should be the first to make this Services change. ISV's developing full blown applications should then be the last (if at all). Life is easier for developer and user if they're working with an .EXE rather then .DLL's.

Have you read the article? Yes, it's a "cludge" with the EXE solution, but that's only for Pocket PC 2000 and 2002 devices - with Pocket PC 2003, Microsoft has support for services, and developers only need to change their code to take advantage of what's already there in the OS. I seriously doubt you'll see Microsoft up the process limitation anytime soon, because the long-term solution is for developers to write the tightest code possible, using the services solution already available in Windows Mobile 2003. And they certainly won't issue a retroactive patch for Pocket PC 2000 and 2002 systems, so this EXE is the only solution for those operating systems.

Sincerely,

Jason Dunn
VP Marketing
Spb Software House