Has anybody found a solution for this limitation yet that has always been in mobile windows editions - you cannot have more than 32 processes running at a time.
Or alternative - is there a way to run a normal process as a system service?
My device has lots of ram. Only I cannot use it because all of the windows's apps are made as compact as possible and I run into the 32 process limit
BUMP
Sorry to be an overpoweruser
The 32 processes is a limit of the underlying CE 5.0 operating system. Microsoft say this will be addressed in CE 6.0
WM 6.x is still based on CE 5.0. Until WM runs on CE 6.0, it is everybody's problem.
A service still requires a process which runs to provide the service. You would not gain anything there.
Thanks for a solid reply
This thread can be closed now
stephj said:
The 32 processes is a limit of the underlying CE 5.0 operating system. Microsoft say this will be addressed in CE 6.0
WM 6.x is still based on CE 5.0. Until WM runs on CE 6.0, it is everybody's problem.
A service still requires a process which runs to provide the service. You would not gain anything there.
Click to expand...
Click to collapse
Windows Mobile has support for multiple services running as threads in "services.exe". I think they have to be written in C++ though. By utilizing that process (which is almost certainly already running due to another service), you don't increase the process count.
Related
My question is really simple for many of you.
What exactly is AKU? I've seen that word gets thrown alot on this forum, and i figureed it's like a operating system or soemthing. so what's the difference between say AKU2.3 and the default Dopod 818 Pro WWE rom? is AKU2.3 more recent than the dopod rom?
Also, when i download those ROMs, there are alway sthree numbers, what are those numbers? ie. 2.13.xxxx 2.09.2222 2.07.1111, something like that? are those IPL, SPL, and Radio firmware versions respectively? I'm uberly confused.
thanks
What Is An AKU
Microsoft creates updated builds of the Windows Mobile operation system called Adaptation Kit Updates (AKU). These releases are rarely intended directly for consumers, and are usually a result of some extra features or fixes required by a particular Windows Mobile device. For example, if an OEM (Original Equipment Manufacturer) decides to add a new kind of external keyboard to a Windows Mobile Pocket PC, then some extra driver code will be required - in that case, Microsoft creates an AKU to drive the hardware.
Developer impact
It is rarely the case that developers need to know which device is running which AKU. The goal is that every device running Windows Mobile 5 runs every application. When a developer takes into account different screen sizes and orientations, either by design or programmatically, then the application should run on all Windows Mobile hardware.
End user impact
The end user of a device doesn't need to know anything about AKU builds. Perhaps a particular model of device will be updated to have new features (for example, push email) but that depends on whether the OEM and the operators decide to implement those features.
Source:
Channel9
This question prompted me to add a thread to the encyclopedia section, but then I noticed that those nifty auto links no longer work.
Now far be it for me to argue with Channel9 but:
These releases are rarely intended directly for consumers
Click to expand...
Click to collapse
So far there have been no AKU releases intended directly for the consumers nor can there be given the current format which requires flashing the whole image.
I also disagree with their assessment of the end user impact.
Not all but most people care if the brand new device they bought can do push mail, is secure or has the newest messenger version.
I'm with you Levenum
mccune said:
What Is An AKU
Microsoft creates updated builds of the Windows Mobile operation system called Adaptation Kit Updates (AKU). These releases are rarely intended directly for consumers, and are usually a result of some extra features or fixes required by a particular Windows Mobile device. For example, if an OEM (Original Equipment Manufacturer) decides to add a new kind of external keyboard to a Windows Mobile Pocket PC, then some extra driver code will be required - in that case, Microsoft creates an AKU to drive the hardware.
Developer impact
It is rarely the case that developers need to know which device is running which AKU. The goal is that every device running Windows Mobile 5 runs every application. When a developer takes into account different screen sizes and orientations, either by design or programmatically, then the application should run on all Windows Mobile hardware.
End user impact
The end user of a device doesn't need to know anything about AKU builds. Perhaps a particular model of device will be updated to have new features (for example, push email) but that depends on whether the OEM and the operators decide to implement those features.
Source:
Channel9
Click to expand...
Click to collapse
This sucks bigtime.
Hi all,
I have read that Microsoft plans to make an OS called Windows embedded/compact 7 for devices like smartphones or pcs who haven't the needed minimum hardware requirements to run windows 7/windows phone 7
So other phones still have the chance to get wp7?
The issue will still be with drivers.
WP7 is built on WCE7, much like WM6.X is built on WCE5.2.
The driver model relies on BSPs (board support packages) that are built for a version of Windows CE and a piece of hardware. I don't think the CE5.2 BSPs will work with WCE7, and as far as I know, very few have access to BSPs, and most of those work for HTC/MS/Qualcomm.
not sure about win7 embedded but
xp embedded is still xp as in only run on a x86 cpu not an arm based
OK, so is there any means to dual boot android/android? iphone can do it, why not android? I would like to chose between cyanogen/htc stock on the fly for emulation purposes. is this possible without having to set up all my nonsense?
unlikely =\
windows mobile and the iphone can not technically dualboot android, they use a program to clear all of the memory in order to boot android ontop of windows mobile/Iphone OS (haret), therefore the original operating system is no longer running and resources are devoted to the new virtual one running
android doesn't currently have a function similar to haret I far as I know (I'm rather new to android)
Its not impossible but as far as I can tell, it hasn't been done yet...
Hello, is there any emulator wich will alaud me to use windows xp app (like games) on mobile phones, or chance windows xp or vista or 7 to bi installed on mobile phone like htc for example?
helion222 said:
Hello, is there any emulator wich will alaud me to use windows xp app (like games) on mobile phones, or chance windows xp or vista or 7 to bi installed on mobile phone like htc for example?
Click to expand...
Click to collapse
i dont think so, windows xp needs a big ammount of ram and above 2ghz cpu dual core to even run properly these days, it takes alot of HDD space too.
Its very hard to make windows xp run natively on a phone, but emulating it is out of the question.
Emulating an entire operating system will result in major slowdown, you have xbox360 with windowsxp and its running horrible, it has a 3.2ghz tricore cpu too so imagine the speed of emulating it on a 1.0ghz dual core cpu and thats the top of the line phone these days.
So, windows will be very slow and when i mean slow i mean things like taking an entire minute to send a file to recycle bin and games would be out of the question as they are in majority D3D dependant and android cellphones use OpenGL.
As the above post says, no. It is possible to emulate a Winmo device from 2003 through 6.5.3 on your PC, but not the other way round. A phone, even the powerful ones do not have enough grunt, to do the job. WinMo emulators on the PC can now run native ARM code executables directly. No mean feat, even on a 3GHz PC
If the PC program was written in native x86 code, a phone cannot run it, but if it was written in .NET and used the core basic methods and properties of the same or a previous version of the .NET CF framework, there is a very slim outside chance that it may work, but the requisites are very restrictive.
Watch for the upcoming version of Windows 8. Microsoft is determined to get onto the latest ARM powered pad devices, having already lost important ground to the iPad and 'pad' versions of Android. This should see a much closer integration of the platforms, but next year may already be too late.
stephj said:
As the above post says, no. It is possible to emulate a Winmo device from 2003 through 6.5.3 on your PC, but not the other way round. A phone does not have enough grunt in it to do the job.
If the PC program was written in native x86 code, a phone cannot run it, but if it was written in .NET and used the core basic methods and properties of the same or previous version of the .NET CF framework, there is a very slim outside chance that it may work, but the requisites are very restrictive.
Watch the upcoming version of Windows 8, that Microsoft is determined to get onto the latest ARM powered pad devices, having already lost important ground to versions of Android. This should see a much closer integration of the platforms, but next year may already be too late.
Click to expand...
Click to collapse
This!
Buy a wm phone
Hi Guys,
I would like to create simple app with NATIVE code which run in emulator.
It is not possible to use solution in http://forum.xda-developers.com/showthread.php?t=1299134&highlight=developer+guide because it's use some ARM code.
Do you have any idea how make things work?
Thank you,
Ch.
You actually could (msotly) use that guide, but you would need to recompile the ARM portion for x86. My guess as to the best way to do this would be to use the "Platform Builder" for CE6 or CE7, instead of using the WinMo 6.5 platform as your target. WinMo only shipped on ARM devices, so far as I know, but the underlying OS, Windows CE, is very portable and the tools for it support building on a wide variety of architectures. WP7 is built on a version of CE somewhere between CE6 and CE7.
Otherwise, the stuff about using ATL, making a COM library, using ComBridge from the WP7 app, etc. all still applies.
That all said... why would you want to do this? Do you not have an actual phone to test on? Porting between ARM and x86 isn't *that* hard, but you shouldn't just assume that it'll work in all cases, so it makes a lot more sense, if you're building native code, to build and test for the same architecture you're planning to release on.
Additionally, the emulator may be missing some of the libraries that are present on the phone.
Thanks a lot. I will try it.
This is very beginning of my school project. I want only demonstrate that is possible to run some native code on WP7. Next phase of project will be on real device which I don't have right now..
Well, good luck, but I'd tend to say you're setting yourself up for a risk of failure. I don't know what it will take to use the CE Platform Builder for something like this; I have it installed but have never tried using it.
There may also be a way to compile for x86 using the WinMo build tools; I think some of the old "emulators" for WinMo were also x86 virtual machines (much like the WP7 emulator is). I never tried, though.
Risk of failure? I don't see how. The hardest part of this is finding a way to get his .exe on the emulator device and unlocking it. If he isn't using ARM ASM in his project, "porting" to x86 (or any other processor WinCE supports) should be trivial as long as a sufficiently complete SDK is available. The main issue with x86 on newer Pocket PC-like targets is that there are no Pocket PC SDKs targeting it newer than the Pocket PC 2003 one. If you want to use newer WM5 only features like GPSAPI, you'd probably need to use a CE 6.0 SDK instead.
If he doesn't want to do real time debugging, any of the Windows CE development tools or even 3rd party tools like Bloodshed DevC++, CE gcc/MinGW or FreePascal should all suffice. Windows CE is a very backward compatible OS so even an application targeting the CE 2.11 platform/SDK should still run on WP7 when you are careful to use supported APIs.
If you don't want to install Platform Builder and generate your own custom OS to base an SDK on, there are plenty of SDKs to choose from. Of course, some are worse than others. If you are using the CE 4.2 or 5.0 STANDARD_SDKs, you might become a bit frustrated when you realize they are missing many basic things like the Windows CE SIP APIs. (something that has been available for CE since 1.01 in 1997). But if you don't care about using the latest native CE kernel features and still want to use a newer IDE like VS2005/VS2008, the CE 5.0 STANDARD_SDK should be enough if you are careful. Though, I usually install things like eMbedded Visual C++ 3.0 and 4.0 along with all the Pocket PC and Handheld PC SDKs just in case I need a header or lib file that one or the other is missing.
The following MS SDKs can target x86:
-eVC3
Pocket PC 2002
Smartphone 2002
Handheld PC 2000
-eVC4
Pocket PC 2003
Smartphone 2003
STANDARDSDK_400
STANDARDSDK_401
STANDARDSDK_420
STANDARDSDK_500
-VS2005/2008
STANDARDSDK_500
Another useful x86 SDK I've found is the one for the Allegro CE/DOS Field PC:
http://www.junipersys.com/Juniper-Systems/support/Developers/Allegro-Field-PC/Allegro-CX
Here are some download links to many of the CE SDKs and compilers that were released over the years:
Here are some links to download some of the tools I've mentioned:
http://www.hpcfactor.com/developer/
http://www.microsoft.com/download/en/search.aspx?q=embedded visual tools
You will need SP4 for eMbedded Visual C++ 4.0 if you wish to use newer SDKs with it.
http://www.microsoft.com/download/en/search.aspx?q=pocket pc sdk
Ummm... maybe you missed the part where this is WP7 forum, and the OP is trying to run native code on the WP7 emulator... I can tell from your post that you're not terribly familiar with WP7 development, so here's a few salient points:
Compiling to a .exe is a waste of time. WP7 won't run foreign EXEs, at all, unless you make some pretty low-level changes that aren't possible on the emulator (see "full-unlock" custom ROMs). You have to write a managed app (which compiles to a DLL hosted inside a low-privilege EXE that's built into the system) and a COM library and use the InteropServices ComBridge API. So far we haven't even gotten P/Invoke to work.
WP7, especially Mango, uses a limited set of native APIs and the APIs have changed somewhat in the last decade or so. They aren't supposed to be available to third-party devs at all, so any backward compatibility is basically a convenient accident. Targeting Smartphone 2003 *might* work, but then, it might not. Even a number of WinMo 6.5 APIs aren't available or don't work.
Since it appears that the OP is just going for a demo project, he or she probably is a lot less interested in getting the most powerful APIs, and is probably hoping for something closer to invoking a MessageBox from native code.
All that said, however, it's true that there are WinCE SDKs which can build native x86 code. I'd tend to suggest using the CE6 or CE7 Platform Builders, since they're the most recent (WP7 is somewhere between the two), but there are other options. You probably want to follow the guide as much as possible, including things like using ATL, as it makes writing a COM library a lot easier and that's the best way we currently know for executing native code in WP7.