PDA

View Full Version : *** I WANT YOUR SERVICE initiative ***


NLS
22nd February 2009, 04:25 PM
http://www.library.ohiou.edu/govdocs/images/UncleSam.jpg

So you have a nice application that has to run all the time (because it detects a sensor, it reacts on something, whatever)... People love it and want to use it.

Then you have stupid WM limits. You can have only 32 processes mister (and 32MB for them)... Yeap that's all for you, even today and WM 6.5 (expected to change with WM7 but WM7 if it ever comes, is at least 18 months away)...

Then you have modern devices that from the factory come loaded with things you want to use and these 32 processes are already half "eaten"...

Then us geeky users, try to add more things and before you know it: "Cannot execute whatever.exe" (inc. even your sync subsystem... no discriminations here)... Then some of those nice programs those nice people in XDA devs made... have to go.

Microsoft HAS an workaround though. A workaround that is used in your desktop windows much more, even though desktop windows don't have this stupid limit: SERVICES.

It's even a philosophy thing: Something that has to run all the time, should be service! Something that you don't want the system to kill it for you, should be service! Something that runs in the background "invisible" SHOULD be service!

Here are some nice links for you:
http://bansky.net/blog/2008/04/services-for-windows-mobile-in-managed-code/
http://msdn.microsoft.com/en-us/library/ms838599.aspx
http://www.pocketpcdn.com/articles/services.html
http://www.eggheadcafe.com/software/aspnet/30999963/service-vs-process-why-n.aspx
http://www.geekzone.co.nz/content.asp?contentid=2407
http://blogs.msdn.com/windowsmobile/archive/2005/08/01/446240.aspx#448385

Yes a service is a bit more complex thing to build and handle (for example you cannot just "quit" a service), but the results are there; and after all this is what some apps SHOULD be.

...So I am making this thread to have a nice AND ESP. FRUITFUL discussion about shifting your great creations to services (i.e. to whatever app this applies). The issue is there. The solution is there. Don't turn a blind eye to it.

Fire away...

(ps. I'd love if someone makes this sticky eventually)

danielherrero
22nd February 2009, 05:14 PM
Yes, we can!
:p

NLS
23rd February 2009, 01:41 AM
Ok we have one recruit. ;)

Let's hope for more.

(I esp. wait for mr. TouchLockPro guy - ...TLP as CMP ***SHOULD*** be service)

Keland44
23rd February 2009, 03:23 AM
i have to say after reading this thread it does make really good sense especially if your like me who keeps a messanger running all the time be it beejive or im+ and also call firewall so getting those programs to run as a actual service that would be good so i know that there running all the time

nothin
23rd February 2009, 04:44 AM
cooker point of view, with 64 mb mem device(max 33-34 mb mem free) - just thinking aloud..

Something that has to run all the time, should be service!
..it may be just module cooked into rom, too, you know..no ram usage, still process though..
but - how many processes do you need at once, people...

btw,
and 32MB for them
so we can load i.e. 50 mb of services maintaining 32 mb mem space for processes then?
just asking..

"Cannot execute whatever.exe"
lol, but not beacuse of "32 processes at once" reason.
are there really users, that have 32 processes launched on their ppc's at once?

cannot just "quit" a service
well, modules again..no mem footprint.

Then you have modern devices that from the factory come loaded with things you want to use
lol, things i do not want to use - we are cookers because of that.
people are using custom roms because of that.

and these 32 processes are already half "eaten"...
so 1/2 still left..

btw one more thing:
what about battery life time vs many services(lets say not especially good written ones)?

NLS
23rd February 2009, 07:30 PM
All my devices hit the 32 process limit pretty soon.

I definitely welcome a cook's point of view, but this cannot apply to everybody.
Something that must run all the time, must run all the time. Be it a service or a process or a cooked module. In fact you can have a service as a cooked module. That's not the point.

The point is overcoming an issue that Windows Mobile has.
A real actual problem that all "more than basic" users face sooner all later.

We have devices with great potential (my TP certainly has) that are limited by stupid 10-15 years old limits.

Let's not take the side of young Bill "640Kb should be enough for everyone" Gates, or people that said some years ago that "IRQ is not a problem"... well history taught both of them otherwise.

Personally I strongly suggest devs that want to make something that must run all the time, to take a hard look on services.

ZuinigeRijder
23rd February 2009, 07:52 PM
This is a very interesting topic, which I did not know of.

Why are the builtin programs of a phone not packaged as a service by the manifacturer?

Then the remainder programs can use the other 32 processes :rolleyes:
If TouchLockPro is only packaged as a service, this will be only 1 process less.

I see also a lot of cons for services. Debugging/developing is much more difficult.

And I am also not sure, if there is a UI related to the service, if that is still a separate process (not background task). As I read the articles, the UI related applications use the service events for doing their job. So for TouchLockPro this would be a no-win, it still needs a separate process. So no gain from that perspective.

NLS
23rd February 2009, 08:05 PM
Services, esp. for WM which are always dll, interact with their environment using various calls.

Having a front end, as long as it is used to set various bits and pieces (like in your TLP) that are then stored for the dll to use, is no problem. Your config front end will be a process of course, but not one that you keep in the background, will run only when needed.

If you talk about your popup window with the six buttons, I am sure you can do that too.

On purpose, one of the links I included above talks about SPB that has already moved all their "backbone" apps to services - and as you know SPB apps use everything... config screens, today items, pop-ups, you name it. Indeed everybody that has SPB software installed, will see in the proper task manager (http://www.dotfred.net/TaskMgr.htm), just a few SPB services installed and no process, as many SPB products as you have. In fact I bet this has allowed them (or at least helped them) to have their famous integration between their products.

danielherrero
24th February 2009, 09:00 AM
Hi.
Just a tip. Debug isnt complicated. Just attach the debugger(Visual Studio) to services.exe and you will be able to debug. Its a similar procedure to debug a today plugin (attaching to shell32.exe).....
Dani

Soul_Est
28th February 2009, 02:06 AM
All my devices hit the 32 process limit pretty soon.

I definitely welcome a cook's point of view, but this cannot apply to everybody.
Something that must run all the time, must run all the time. Be it a service or a process or a cooked module. In fact you can have a service as a cooked module. That's not the point.

The point is overcoming an issue that Windows Mobile has.
A real actual problem that all "more than basic" users face sooner all later.

We have devices with great potential (my TP certainly has) that are limited by stupid 10-15 years old limits.

Let's not take the side of young Bill "640Kb should be enough for everyone" Gates, or people that said some years ago that "IRQ is not a problem"... well history taught both of them otherwise.

Personally I strongly suggest devs that want to make something that must run all the time, to take a hard look on services.

I have only done some ROM cooking (1 Pass/9 Fail) but I can say that this is a great topic especially once you deal with UI replacing or enhancing today plugins which consume memory like nothing else such as PointUI's Home 2 and HTC's Manila 2D. Software As A Service is the future!

danielherrero
28th February 2009, 08:03 AM
Hi
After two days I managed to configure commmgrpro to run in dual mode, as a service or as a process. I thought It was going to much more difficult. If someone needs help please let me know.....
Dani

NLS
28th February 2009, 11:06 AM
Well since I am beta testing the thing and works really well, I can only say "why didn't everybody do it like that already!" (i.e. for apps that it fits - read: programs that run all the time).

You even did it in record time and that option that switches it back to being a process... fantastic!

So people ask Danny for help, you can all do it!
(erm... I hope this didn't sound bad for Danny's programming skils hehehehe)

joubertvasc
28th February 2009, 11:50 AM
Hi
After two days I managed to configure commmgrpro to run in dual mode, as a service or as a process. I thought It was going to much more difficult. If someone needs help please let me know.....
Dani

Hi, congratulations!

Could you add some short tutorial explaining how to transform an app to service?

Regards,
Joubert

Soul_Est
28th February 2009, 09:57 PM
Hi, congratulations!

Could you add some short tutorial explaining how to transform an app to service?

Regards,
Joubert
I second that. Once I get better at C++ this would be quite good to know.

danielherrero
28th February 2009, 10:17 PM
Sure
On monday I will give detailed explications. Basically
1) Your program lives attached to services.exe
2) You cant configure it to run on startup because it wont be signed (except if you ve certificate) so windows will refuse to load it with all the signed drivers and sservices. You ve to run a small program on startup (\windows\startup) that will load your service (ActivateService api)
3) Create some registry keys under HKLM\services defining your service(where is you dll, your pefix, description, order, etc).
4) You ve to create a DLL implementing 3 functions (init, uninit and iocontrol)
5) The key is the xxx_init method. You should create and launch a thread because that function should return quickly or services.exe will unload your service because you re a slow boy :P.
6) that thread should do what your WinMain function does. Generally will initialize your program and tipically loop to process windows messages (getMessager, TranslateMessage, DispatchMessage).
7) The uninit method should finish your program. Be careful to free all the memory allocated. In a normal program if you do memory leak on exit program windows will recover it. Here not. If you start/stop your services many times and you dont clean and destroy all your objects/heaps then services.exe will grow and grow.

Seach the function activateservice in msdn help. Its the door to a clear documentation about services. And of course, ask me what you need
Greetings
Dani

NLS
2nd March 2009, 09:57 AM
...we'll be waiting... :)

danielherrero
2nd March 2009, 10:21 AM
http://msdn.microsoft.com/en-us/library/ms938094.aspx
:)

thx1200
27th March 2009, 07:46 AM
ReRemind: http://forum.xda-developers.com/showthread.php?p=3532553

Notifies you by playing WAV periodically if you have missed calls, voicemails, or reminders awaiting your attention.

Implemented fully as a service.

Designed to replace apps like Best Reminder.

Oh, it's free too! :-) Very early alpha. Probably buggy. :-)

addicus
28th March 2009, 09:14 AM
So as a user do we just use a cab file to implement the programs?

NLS
30th March 2009, 12:52 PM
Thanks THX!

Addicus I don't understand you.

NLS
17th December 2009, 03:36 PM
Since this thread led to a few programs that actually successfully turned to services, I bump this a bit (after 9 months), so that newcomer devs see this or older XDA devs remember. ;)

Noonski
17th December 2009, 04:17 PM
I was just thinking about you, so good Bump, you helped me find your thread again.

NLS
17th December 2009, 04:29 PM
:D :D :D

should I play a Lotto or something?
(or should you)

TrashKalmar
17th December 2009, 10:16 PM
Hi. I'd like to share with you about my experiences with services.
Now I'm developing anti-theft system (if interesting, it is here (http://forum.xda-developers.com/showthread.php?t=594608)). Before I've started the development, I made some investigation. First, anti-theft system must have the following properties:
Invisibility. Stolen device will be most likely inspected by the theft, and all the suspicious software will be removed. It means that every anti-theft application that is implemented as exe and placed to \windows\startup folder will be most likely found and then killed. (I say about enough clever theft :) ).
Invincibility. WinCE platform does not implement the security management as WinNT does. Thats why every process may be killed (even gwes.exe and filesys.exe). Killing services.exe most likely will lead to device halt, so the service can not be terminated so easy.
Protection against unauthorized access. Independed UI (which may be removed when not needed) should exploite IO control codes as the gate to your service. And do not leave the back door. If your system is really valuable and interesting, one can reverse the protocol and create the killer for your service. Fantastic, but keep it in mind.

Service already has this properties, you need not implement it.
Second, your system's core and user interface must be separated. I think, it is obvious.
Third, the debugging of such a program is extremely hard. Yes, you can attach to services.exe and debug your service. But when you touch RIL and some other stuff, you have only one attempt to attach. The second one will fail with "Unable to attach" message. I don't know why, but I've seen this.
Workaround of that is to build debug version of your service as a simple dll, which is loaded by some loader. It simplifies the debugging but your service lose service's behaviour and you will often have a trouble: why the service fails, but as simple dll it works? :confused: I develop my system for 10 (!) months and for now it still is not completed.

I can jabber for a long time, so finishing. My conclusion is: you should implement your app as service only if it requires that. Forget about 32 proc limit, 10 user processes already hauls down the PDA. This is not worth the trouble.

This is my IMHO, thank you for attention :) And sorry for curly english.

NLS
17th December 2009, 10:25 PM
Very interesting read. Thanks.

Noonski
18th December 2009, 12:58 AM
Even for me, a non programmer it was indeed interesting reading, whish there where more interesting posts like these in Windows Mobile Software development.

ajhvdb
18th December 2009, 01:46 AM
Hi. I'd like to share with you about my experiences with services.
Now I'm developing anti-theft system (if interesting, it is here (http://forum.xda-developers.com/showthread.php?t=594608)). Before I've started the development, I made some investigation. First, anti-theft system must have the following properties:
Invisibility. Stolen device will be most likely inspected by the theft, and all the suspicious software will be removed. It means that every anti-theft application that is implemented as exe and placed to \windows\startup folder will be most likely found and then killed. (I say about enough clever theft :) ).
Invincibility. WinCE platform does not implement the security management as WinNT does. Thats why every process may be killed (even gwes.exe and filesys.exe). Killing services.exe most likely will lead to device halt, so the service can not be terminated so easy.
Protection against unauthorized access. Independed UI (which may be removed when not needed) should exploite IO control codes as the gate to your service. And do not leave the back door. If your system is really valuable and interesting, one can reverse the protocol and create the killer for your service. Fantastic, but keep it in mind.

Service already has this properties, you need not implement it.
Second, your system's core and user interface must be separated. I think, it is obvious.
Third, the debugging of such a program is extremely hard. Yes, you can attach to services.exe and debug your service. But when you touch RIL and some other stuff, you have only one attempt to attach. The second one will fail with "Unable to attach" message. I don't know why, but I've seen this.
Workaround of that is to build debug version of your service as a simple dll, which is loaded by some loader. It simplifies the debugging but your service lose service's behaviour and you will often have a trouble: why the service fails, but as simple dll it works? :confused: I develop my system for 10 (!) months and for now it still is not completed.

I can jabber for a long time, so finishing. My conclusion is: you should implement your app as service only if it requires that. Forget about 32 proc limit, 10 user processes already hauls down the PDA. This is not worth the trouble.

This is my IMHO, thank you for attention :) And sorry for curly english.

Did you write this from scrath or did you use some code as a base which you could extend. I'm very much interested in this so I would like to PM you about this. I'm a beginner and have seen a lot of code the last week, also examples from microsoft and all of them seem to fail depending on hardware and bugs in the OS.

Native code seems like the best solution but is very hard to understand.

thx1200
18th December 2009, 03:11 AM
Since this thread led to a few programs that actually successfully turned to services, I bump this a bit (after 9 months), so that newcomer devs see this or older XDA devs remember. ;)

This is a really good bump.

It also reminded me to finish up my blog post for creating a Service project in Visual Studio 2008. The instructions on MSDN are for like Embedded Visual C++ 4.0 or whatever -- painfully out of date!

hecksk
18th December 2009, 05:27 AM
I have started v0.3 with WM6.5.3 (28014) and it says "Keyboard Hook Failed".
Is it possible to fix?

TrashKalmar
18th December 2009, 06:40 AM
The whole project is written in native C++ from scratch. Even front-end of service is in pure winapi (no mfc/atl/.net/qt...). Of course I've used MSDN as primary source of information about services. But again, it somewhere lies, and samples really do not working :(

danielherrero
18th December 2009, 09:18 AM
Hi. I'd like to share with you about my experiences with services.
Now I'm developing anti-theft system (if interesting, it is here (http://forum.xda-developers.com/showthread.php?t=594608)). Before I've started the development, I made some investigation. First, anti-theft system must have the following properties:
Invisibility. Stolen device will be most likely inspected by the theft, and all the suspicious software will be removed. It means that every anti-theft application that is implemented as exe and placed to \windows\startup folder will be most likely found and then killed. (I say about enough clever theft :) ).
Invincibility. WinCE platform does not implement the security management as WinNT does. Thats why every process may be killed (even gwes.exe and filesys.exe). Killing services.exe most likely will lead to device halt, so the service can not be terminated so easy.
Protection against unauthorized access. Independed UI (which may be removed when not needed) should exploite IO control codes as the gate to your service. And do not leave the back door. If your system is really valuable and interesting, one can reverse the protocol and create the killer for your service. Fantastic, but keep it in mind.

Service already has this properties, you need not implement it.
Second, your system's core and user interface must be separated. I think, it is obvious.
Third, the debugging of such a program is extremely hard. Yes, you can attach to services.exe and debug your service. But when you touch RIL and some other stuff, you have only one attempt to attach. The second one will fail with "Unable to attach" message. I don't know why, but I've seen this.
Workaround of that is to build debug version of your service as a simple dll, which is loaded by some loader. It simplifies the debugging but your service lose service's behaviour and you will often have a trouble: why the service fails, but as simple dll it works? :confused: I develop my system for 10 (!) months and for now it still is not completed.

I can jabber for a long time, so finishing. My conclusion is: you should implement your app as service only if it requires that. Forget about 32 proc limit, 10 user processes already hauls down the PDA. This is not worth the trouble.

This is my IMHO, thank you for attention :) And sorry for curly english.

Hi
I agree in most of your conclusions. Currently I am developing a new program, the new version of CommMgrPro. AS before the core can run as service or as a process. It isnt very complicated to to this and It allows you to run as a process when you want to debug and run as a service in rest of cases. I developed CommMgrPro frontend using Win32 API directly but this time I will use .NET. In this way I can use any of the free touch library outthere, including Manila SDK and other features as SQL Server CE, etc. To comunicate .NET frontEnd with Win32 service I am using MS Peer to Peer messages queues. This native feature is a beatiful system to comunicate process in async way.....
Dani

NLS
18th December 2009, 10:19 AM
(maybe this thread should be sticky?)

thx1200
19th December 2009, 12:06 AM
(maybe this thread should be sticky?)

I agree!! How does one go about getting a thread stickied here?

TehPenguin
19th December 2009, 03:43 AM
I agree!! How does one go about getting a thread stickied here?

The Development and Hacking section has too many stickies, so now there is a Wiki page with the stickied links: http://wiki.xda-developers.com/index.php?pagename=XDA%20D%26H%20Wiki%20Page (And, since its a wiki page, anyone can edit it)

khaytsus
19th December 2009, 08:25 PM
The Development and Hacking section has too many stickies, so now there is a Wiki page with the stickied links: http://wiki.xda-developers.com/index.php?pagename=XDA%20D%26H%20Wiki%20Page (And, since its a wiki page, anyone can edit it)

Yeah, this limitation blows, I'm constantly having programs "disappear" because of this limitation, although I can't be 100% sure that's the reason. I usually idle around 25 processes with my normal load of stuff on my Tilt 2, wish I knew what other crap I could get rid of in the startup. What bugs me most is that Flexmail is constantly exiting if I'm running multiple other things, like if I'm geocaching and have GCzII and Google Maps running, I'll see flexmail exit (red line at the bottom of the screen.. When FM is syncing, it's a blue line, when cleaning up/exiting, red line).. It doesn't just crash, it exits cleanly.

Ah well.

thx1200
20th December 2009, 03:21 AM
Yeah, this limitation blows, I'm constantly having programs "disappear" because of this limitation, although I can't be 100% sure that's the reason. I usually idle around 25 processes with my normal load of stuff on my Tilt 2, wish I knew what other crap I could get rid of in the startup. What bugs me most is that Flexmail is constantly exiting if I'm running multiple other things, like if I'm geocaching and have GCzII and Google Maps running, I'll see flexmail exit (red line at the bottom of the screen.. When FM is syncing, it's a blue line, when cleaning up/exiting, red line).. It doesn't just crash, it exits cleanly.

Ah well.

If an application's primary window is hidden, WM will not close it during clean-up.

That said -- holy crap! 25 processes on boot? Even my TP's stock ROM only had 21 on boot. Since switching to Mighty, I have, I think, 18 on boot now, and that's with several processes launched at start, like MS3 and PocketShield.

WM starts to clean up processes once you pass 29, if I remember correctly (somebody correct me if I'm wrong). So if you hit 30, it will look for what it thinks is the "most stale" process and kills it. It doesn't wait until 32, that much I know.

Hopefully Windows Phone 7 will be based on CE6 (or newer) so we can get rid of this limit once and for all.

Noonski
20th December 2009, 04:59 AM
Yeah i'm always amazed at the processes Some Junior Cooks leave in startup.

It's like they went from owning the phone straight to cooking with al these to easy made kitchens, without ever toying and tweaking their own device first..

Come on who needs btwake start as an .exe if this process gets started by Bluetooth Explorer anyway?.

There's only a small percentage of people that actually need and use SAP BT Contacts Syncing. At least i never heard anyone complain that it was disabled by default.

And now a days you even see HTC add a /Silent /Hidden parameter for the Comm manager which is redundant.

I cook, but i also flash some other roms. And i don't see this disabled by anyone. But i rarely dare to say anything about it as most will see it as some sort of atack when you try to give some advice.

There's plenty of Programs to kill by default so there would be enough slots to start other apps.

Even when WM7 comes out, there will still be plenty of devices that will have to live with these max process limitations.

Raising some awareness amongst some cooks could help. But having more apps that could just as easily be a service, would help.

khaytsus
20th December 2009, 06:59 AM
If an application's primary window is hidden, WM will not close it during clean-up.

That said -- holy crap! 25 processes on boot? Even my TP's stock ROM only had 21 on boot. Since switching to Mighty, I have, I think, 18 on boot now, and that's with several processes launched at start, like MS3 and PocketShield.

WM starts to clean up processes once you pass 29, if I remember correctly (somebody correct me if I'm wrong). So if you hit 30, it will look for what it thinks is the "most stale" process and kills it. It doesn't wait until 32, that much I know.

Hopefully Windows Phone 7 will be based on CE6 (or newer) so we can get rid of this limit once and for all.

Stock ROM + S2U2, Aerial Battery, few other things.. I think a hard-reset stock on the ATT rom is like 20. This isn't quite the thread, but since you guys seem to know this sort, any of these from \windows\startup I can get rid of?

BTTrayCE, DelWMPTempFolder, HTCStartUp, MessageCSPTool, PKG, VPortBoot.

I don't know of those which actually create processes which run, but any of them that can be gotten rid of safely?

Noonski
20th December 2009, 02:07 PM
HTCStartUp & PKG can go without issues.

An maybe also DelWMPTempFolder.

The others are kind of new to me.

NLS
20th December 2009, 05:09 PM
added in wiki - hope I put it in the proper section (I'd prefer Misc since it would be alone ;))...

...and edited my sig appropriately ;) this needs exposure

Arktronic
19th January 2010, 06:56 AM
Noonski pointed me to this thread, suggesting that I make ArkSwitch a service. After researching it, I concluded that it is pointless for managed apps. My reasoning is summarized in this post (http://forum.xda-developers.com/showpost.php?p=5398121&postcount=73). Just some food for thought :)

NLS
19th January 2010, 09:28 AM
You reasoning is sound.
Indeed managed code and apps that still need an always on front-end (as opposed to a front-end just for configuration for an app that needs to run all the time) are not the best candidates as services.

I wish my whole thread becomes a fossil in a year or so - and not because WM is dead :D but because WM7 will lift the limitations posed by WinCE 5.X. Of course pre-WM7 devices will still need to be considered (for a few years).

danielherrero
19th January 2010, 09:39 AM
In my opinion the best idea is to join the benefits of both worlds.
1) C/C++ Wint32 core as service. Fast, small, powerful
2) C#/VB .NET CF front end (GUI). Can use .NET touch frienly libraries
3) Both parts talk using MS Queue (or IOControl for synchronous calls. In this way the system is decoupled and you cant replace the GUI easily and allowing skins developed quickly

Dani

NLS
19th January 2010, 11:55 AM
As Daniel said (after researching the subject much). ;)

(btw Danny you mean "can" not "cant")

danielherrero
19th January 2010, 12:03 PM
As Daniel said (after researching the subject much). ;)

(btw Danny you mean "can" not "cant")

hehehe, yes, yes, CANT :P

Arktronic
19th January 2010, 04:02 PM
In my opinion the best idea is to join the benefits of both worlds.
1) C/C++ Wint32 core as service. Fast, small, powerful
2) C#/VB .NET CF front end (GUI). Can use .NET touch frienly libraries
3) Both parts talk using MS Queue (or IOControl for synchronous calls. In this way the system is decoupled and you cant replace the GUI easily and allowing skins developed quickly

Dani

On the desktop, such a split would certainly be ideal, as would some categories of mobile apps. However, for an app that runs in the background most of the time, but needs to display fast once activated, using such an approach doesn't work, because .NET CF apps start up really slowly.

kholk
25th February 2010, 01:42 PM
I'm with you.

On our devices there are some programs that can be converted to services.
The only IMPORTANT thing is that we need to set even the order of the services that are being executed.
HTC Sense for example in custom ROMs can be set as service: it uses a large amount of RAM and I think that it would be even faster if executed as a service, but remember that it is a Today plugin.

What we need isn't to modify the source code of programs to being executed as a service because we don't have every source of every program: an useful thing would be to make a program that executes another program in service mode!
...And this is possible.


When you want to start the development, PM me. And I think that it's best to talk on IRC while developing.


The Eugenia Project Developer
-kholk

thx1200
26th February 2010, 04:51 PM
HTC Sense for example in custom ROMs can be set as service: it uses a large amount of RAM and I think that it would be even faster if executed as a service, but remember that it is a Today plugin.
-kholk

It's not actually a today plugin. The today plugin is a "boot strapper" that launches an external Sense EXE.

But, wow, I'm not sure I'd want to put Sense in as a service. When it crashes, it would bring down all the other services in services.exe (which is a risk!). Also, being a memory hog, it won't leave much memory left for other services. Remember, services.exe is a process and is subject to the 32MB memory limit that each process has and all services must share. I personally think that services.exe is best left to non-interactive non-UI repeating/timed/event-driven applications...

But hey if somebody pulls it off and it's stable, awesome! :-)

thx1200
1st March 2010, 04:31 AM
Here is a service that gives you a battery indicator as a line across the top of the title bar. This has been done many times before, but never as a service.

Enjoy!

http://www.xda-developers.com/forum/showthread.php?p=5756511

NLS
1st March 2010, 11:23 AM
Good job. :)

Noonski
7th March 2010, 11:08 AM
Here is a service that gives you a battery indicator as a line across the top of the title bar. This has been done many times before, but never as a service.

Enjoy!

http://www.xda-developers.com/forum/showthread.php?p=5756511
Such i good job i took it to the FrontPage ;)

Shasho
8th March 2010, 05:48 PM
anybody tried makin the service ACR – Auto Call Recorder – Version 1.2.3 a service instead an application. the call stops recording as soon as the light on the phone goes off. any help here?:confused:

thx1200
12th March 2010, 05:48 AM
Another service by me. This one is writtenly specifically for, and will only work on, the HTC Touch Pro 2. It's called ZoomBarPlus and it makes your TP2's ZoomBar more useful.

http://forum.xda-developers.com/showthread.php?p=5859672

NLS
12th March 2010, 01:39 PM
great job man

I always hated the zoom bar (waste of front space - why not a cursor pad?), so any attempt to make it more useful is great.

frmariam
17th March 2010, 06:32 PM
I'd actually love a wkTask (http://soft.photoracer.net/docs/wktask_en.html) like task manager (with all the wkTask goodies :) ). Don't like the new big C# task managers (too heavy, slow to load and short featured.. also it takes more steps to change and manage tasks).

This is my favorite task manager because it's in native code (no C# BS) and has gestures (horizontal and vertical "X" button swipe), app/file launchers, taskbar icon display, battery display, big volume and brightness controls, minimize/close/terminate app options (the terminate command is extremely useful). Fast, lite and useful. A hell of a lot better than HTC X button imho.

This sort of app seems like the perfect candidate to become a service... Unfortunately the dev seems to have dropped it (doesn't even answer to mails...).

michyprima
28th March 2010, 08:14 PM
Some days ago I took a look at this thread.
I just asked myself "Why make a service as described in the first link of first post, if it still uses a process slot instead of avoiding this?"
So I just decided to make a new way to make managed services for WM.
Of course they don't suffer of WM_CLOSE messages etc, but more they lives attached to a single main process (as unmanaged services do), as separate thread: that makes them to be managed in a more easy way and do basical operations easy (stop start suspend resume...) and to monitor and debug.
If someone is interested I can release full documentantion with examples and - maybe - source code.

NLS
29th March 2010, 12:39 PM
Yes that would be interesting.

thx1200
29th March 2010, 03:18 PM
Some days ago I took a look at this thread.
I just asked myself "Why make a service as described in the first link of first post, if it still uses a process slot instead of avoiding this?"
So I just decided to make a new way to make managed services for WM.
Of course they don't suffer of WM_CLOSE messages etc, but more they lives attached to a single main process (as unmanaged services do), as separate thread: that makes them to be managed in a more easy way and do basical operations easy (stop start suspend resume...) and to monitor and debug.
If someone is interested I can release full documentantion with examples and - maybe - source code.

I think it would be awesome if you could get a true managed service process standardized. The problem is adoption. Without everybody buying into it and without the service executible being burned into a bunch of ROMs or many people willing to download the EXE, it won't take off.

I thought about this a while back and came up with a solution, maybe you can integrate it.

My solution was to have a standard interface DLL that anybody wanting to participate in the managed service would reference. They would have their main form implement this interface. They would still compile to an EXE, however.

What would happen is that if the user has the managed service host running, the service host would dynamically load the EXE like a DLL (yes, this is possible in .Net) and call the implemented "OnServiceStart" method (or whatever) and it would run. However, if the user did NOT have the service host installed, the EXE would run like a normal background process.

I think developers would jump on that because it doesn't make their app depend on the service host to run, but they gain the opportunity to not waste process slots if the user does have the service host.

Additional logic would be required to make sure that if the service host is running, the background process from the EXE won't spin up (basically just start, then quit). Also, you would want to make sure that each service hosted by the host is encapsulated in its own try..catch on the new thread so any one service doesn't bring down the entire host. And finally, it would be a good idea to have an unmanaged service running that can spin the managed service host back up automatically, if the service host crashes.

Also, I would highly recommend you make this an open source project so others can contribute and make it better. A good managed service host should be something somebody else can pick up on, should you move onto other projects. Too many good projects die prematurely in the WM world and the source just gets lost!

michyprima
29th March 2010, 06:09 PM
What would happen is that if the user has the managed service host running, the service host would dynamically load the EXE like a DLL (yes, this is possible in .Net) and call the implemented "OnServiceStart" method (or whatever) and it would run. However, if the user did NOT have the service host installed, the EXE would run like a normal background process.
I know this is possible, and is exactly what I did. Of course, you can compile your service as exe or as dll, the main thing is that it should contain a class implementing my interface. Of corse (x2) if you want to follow the dll way, you will have to distribute the host too.
There will be 2 host versions: debug and release.
Attaching VS or any other debugger to the debug version, will bring you a fully documented debug log. ;)

I think developers would jump on that because it doesn't make their app depend on the service host to run, but they gain the opportunity to not waste process slots if the user does have the service host.

Additional logic would be required to make sure that if the service host is running, the background process from the EXE won't spin up (basically just start, then quit). Also, you would want to make sure that each service hosted by the host is encapsulated in its own try..catch on the new thread so any one service doesn't bring down the entire host. And finally, it would be a good idea to have an unmanaged service running that can spin the managed service host back up automatically, if the service host crashes.

Also, I would highly recommend you make this an open source project so others can contribute and make it better. A good managed service host should be something somebody else can pick up on, should you move onto other projects. Too many good projects die prematurely in the WM world and the source just gets lost!
I will consider that ideas before releasing.
Already my host has fully support for "remote" controlling etc, so basically it's nicely working.

mwalt2
29th March 2010, 06:30 PM
What do you need to turn a small exe into a service? Is the exe itself fine or do you need source? Thanks.

thx1200
30th March 2010, 03:07 PM
I know this is possible, and is exactly what I did. Of course, you can compile your service as exe or as dll, the main thing is that it should contain a class implementing my interface. Of corse (x2) if you want to follow the dll way, you will have to distribute the host too.
There will be 2 host versions: debug and release.
Attaching VS or any other debugger to the debug version, will bring you a fully documented debug log. ;)


I will consider that ideas before releasing.
Already my host has fully support for "remote" controlling etc, so basically it's nicely working.

Very awesome. I can really see people buying into this. if I had a managed "service" I know I would. I converted all my service ideas to unmanaged code, though, so I have nothing to test. Please update this thread with your progress. I really think the hybrid EXE-that-can-be-loaded-like-a-DLL approach is a winner. :-) I like the debug log idea too!

thx1200
30th March 2010, 03:09 PM
What do you need to turn a small exe into a service? Is the exe itself fine or do you need source? Thanks.

If you mean an unmanaged (true) service, an EXE cannot be a service. It has to be a DLL. OTOH, we were just talking about a managed service host. Sounds like a good one is in the works thanks to michyprima. :-) That would require less conversion work and would host .Net EXEs.

BHS Interceptor
11th November 2010, 07:12 PM
Even for me, a non programmer it was indeed interesting reading, whish there where more interesting posts like these in Windows Mobile Software development.

I can only agree to that - and I am just a "simple" user, but what I find most interesting and at the same time disturbing, is the fact that this thread, even though itīs been here for quite a while, has so few posts :confused:

Is it because "users" are not aware of the possible benefits? Or even worse, is it because developers donīt really care about these benefits?

Thank you all anyway, even if I only understand part of what you wrote, at least I did learn some things and enjoyed reading ;)

NLS
11th November 2010, 08:43 PM
Thanks people.

thx1200
12th November 2010, 03:11 PM
I can only agree to that - and I am just a "simple" user, but what I find most interesting and at the same time disturbing, is the fact that this thread, even though itīs been here for quite a while, has so few posts :confused:

Is it because "users" are not aware of the possible benefits? Or even worse, is it because developers donīt really care about these benefits?

Thank you all anyway, even if I only understand part of what you wrote, at least I did learn some things and enjoyed reading ;)

Quite a few services have appeared here and there since this thread, and that was/is a good thing for classic Windows Mobile.

The reason you probably don't see much activity anymore is that Windows Phone 7 does not support services, background processes, or any form of third party multitasking at all -- at this point anyway. If it ever does, WP7 is based on CE 7, which does not have a 32-process limit (I think it's 32767), so "services" on WP7 will likely be implemented just as simple background processes. However, if MS does create a "service" API for WP7, it will also most likely be completely different from the information in this post, as WP7 apps are all managed code / Silverlight and the WM6.5 and below service model requires unmanaged C++ code and the special host process "services.exe."