Rebuttal to the Ford versus Chevy Article

[Jason Dunn]

<div class='os_post_top_link'><a href='http://www.cewindows.net/commentary/rebuttal-ford-chevy.htm' target='_blank'>http://www.cewindows.net/commentary...-ford-chevy.htm</a><br /><br /></div>"Jeff Kirvin's article entitled Ford vs Chevy just doesn't do justice to what Microsoft implemented in Windows CE (the core OS that the Pocket PC and Windows Mobile systems use). What he described is how physical ram is allocated between execution and storage. The critical thing he left out is how the OS virtually allocates memory and how it decides what to do. Also, his discussion does NOT explain how the Windows CE OS multitasks..."<br /><br />Chris De Herrera has written a rebuttal to <a href="http://www.writingonyourpalm.net/column040315.htm">Jeff Kirvin's Ford vs. Chevy article</a>, and it's worth a read.

[JonnoB]

I find it interesting the Jeff mentions that the Pocket PC cannot have more than window being viewed... as if this was a fundamental flaw of the OS. It was intentional to make the experience in the Pocket PC seamless, not a limitation of the core operating system. To simplify the user experience, the PPC shell limits one top-level application to be viewed at a time, and the others are still running - just at a lower z-order. In fact, an application can have pop-up windows (see the screenx apps from mtux) that do not interfere with other apps in the z-order. The applications themselves actually can share the z-order top-level window with tools like seymore as well. These apps expose the true multi-tasking of the core OS. The Conduits MP3 player adds a notfication icon to control the player in the back-ground. This is the full application running in the background, not some seperate ui-less thread.

I do think it is an interesting step that PalmSource has taken to allow multiple thread processes... and it shows that MS was on the correct path. It just doesn't go far enough. The Palm implementation reminds me very much of the old DOS-based TSR utilities - and that just doesn't cut it.

[c38b2]

I don't think it was a rebuttle - more like an in-depth look at exactly how Pocket PCs handle multitasking. Since he doesn't have a discussion forum I guess we'll have to discuss his comments here. :)
Palm's decisions to require applications to be rewritten shows how poorly they initially planned to support multitasking. Further their decisions are going to limit what applications are available for their customers.
Apps do not have to be rewritten to work under the new OS. The rewriting happens when developers want to take advantage of the multitasking of the new Palms OS (or when the developer chooses to write directly to the hardware and the hardware changes).
Just take any Pocket PC and setup Notes to record voice and let it run until there is no more ram left and you'll see why we have the ability to perform a hard reset.
Either I misunderstand this statement or PPC doesn't handle full RAM very well. :lol:

[Lucan]

It just doesn't go far enough. The Palm implementation reminds me very much of the old DOS-based TSR utilities - and that just doesn't cut it.


I keep reading on this forum how the Palm implementation of multitasking is not good enough, just doesn't cut it, etc. My question is why? Please give everyday examples of something a PPC device can do that a Cobalt device cannot do.

Lucan

[huangzhinong]

Palm's decisions to require applications to be rewritten shows how poorly they initially planned to support multitasking. Further their decisions are going to limit what applications are available for their customers.

Apps do not have to be rewritten to work under the new OS. The rewriting happens when developers want to take advantage of the multitasking of the new Palms OS (or when the developer chooses to write directly to the hardware and the hardware changes).\\

I don't understand your words. Chris told us application need to be rewritten if the application want to run background in "mulittasking" POS, you said the same thing, what's the difference?

Just take any Pocket PC and setup Notes to record voice and let it run until there is no more ram left and you'll see why we have the ability to perform a hard reset.
Either I misunderstand this statement or PPC doesn't handle full RAM very well. :lol:

Actually most of people didn't notice that file explorer can always be launched even the ram is full(without any bit left). I found this feature by chance. One month ago I tried to copy my maps to SD card but by mistake I copied to RAM, I filled up all RAM and the system closed all apps including file explorer. I run the file explorer again, popup windows told me if I need convert some SD card space as virtual memory, I click yes and the file exploere launched and I moved away all my maps.

Most of time you won't see this popup windows " Do you want to convert some storage card space as virtual memory? ".

[huangzhinong]

It just doesn't go far enough. The Palm implementation reminds me very much of the old DOS-based TSR utilities - and that just doesn't cut it.


I keep reading on this forum how the Palm implementation of multitasking is not good enough, just doesn't cut it, etc. My question is why? Please give everyday examples of something a PPC device can do that a Cobalt device cannot do.

Lucan

The simplest example is old apps for earlier version OS can always stay background in every PPC os version without rewriten, but in POS the old apps will be closed once you launch another application.

Simple?

[Ed Hansberry]

It just doesn't go far enough. The Palm implementation reminds me very much of the old DOS-based TSR utilities - and that just doesn't cut it.


I keep reading on this forum how the Palm implementation of multitasking is not good enough, just doesn't cut it, etc. My question is why? Please give everyday examples of something a PPC device can do that a Cobalt device cannot do.
On a PPC, open and email. Say it has contact info in the sig you want and you decide to copy it to contacts. Open Contacts and open a form. Switch to the email and copy one line. Switch to the contact form and paste in the appropriate line. Switch to the email and copy the next line. Keep doing this until you are done.

On OS6, the UI keeps closing the contact form since the UI thread is killed. I'm not sure if it keeps the email actually open and your cursor on the same line or not or if it keeps closign that window.

[JonnoB]

I keep reading on this forum how the Palm implementation of multitasking is not good enough, just doesn't cut it, etc. My question is why? Please give everyday examples of something a PPC device can do that a Cobalt device cannot do.


Using Seymour (http://www.jarosoft.com/seymour.html) I work on a word document in which the content is relative to research I am able to view browsing the web. I do this, while streaming audio via a shoutcast radio station. When needed, I talk to people on the Pocket PC phone without interuption to the downloading of multiple large files via WiFi, the remote administration (terminal server) at the office, and the multiple A. People who do not need true multi-tasking applications would not understand how important it is to others who really do need it. Kind of like those who said years ago that they could not understand why anyone would need a multi-tasking desktop and more than 640k of memory.

[Lucan]

[/quote]

The simplest example is old apps for earlier version OS can always stay background in every PPC os version without rewriten, but in POS the old apps will be closed once you launch another application.

Simple?[/quote]

True. But isn't it true that the majority of applications don't need or don't benefit from multitasking? Here is my list of applications that benefit for multitasking:

Web, email, IM, phone call, open form, music, GPS.

Did I miss anything?

Lucan

[Lucan]

It just doesn't go far enough. The Palm implementation reminds me very much of the old DOS-based TSR utilities - and that just doesn't cut it.


I keep reading on this forum how the Palm implementation of multitasking is not good enough, just doesn't cut it, etc. My question is why? Please give everyday examples of something a PPC device can do that a Cobalt device cannot do.
On a PPC, open and email. Say it has contact info in the sig you want and you decide to copy it to contacts. Open Contacts and open a form. Switch to the email and copy one line. Switch to the contact form and paste in the appropriate line. Switch to the email and copy the next line. Keep doing this until you are done.

On OS6, the UI keeps closing the contact form since the UI thread is killed. I'm not sure if it keeps the email actually open and your cursor on the same line or not or if it keeps closign that window.

That certainly is a basic need for multitasking. Are the experts saying that this cannot be done in Cobalt?

Lucan

[Lucan]

Using Seymour (http://www.jarosoft.com/seymour.html) I work on a word document in which the content is relative to research I am able to view browsing the web. I do this, while streaming audio via a shoutcast radio station. When needed, I talk to people on the Pocket PC phone without interuption to the downloading of multiple large files via WiFi, the remote administration (terminal server) at the office, and the multiple A. People who do not need true multi-tasking applications would not understand how important it is to others who really do need it. Kind of like those who said years ago that they could not understand why anyone would need a multi-tasking desktop and more than 640k of memory.

With the exception of Seymour, it was my impression that you could do all of this on a Cobalt device?

Lucan

[JonnoB]

That certainly is a basic need for multitasking. Are the experts saying that this cannot be done in Cobalt?

With Cobalt, you can only have one active application UI operating at the same time. As I see it, there isn't a way to make one program interact with the other in real-time so that the user interface in one application reflects non-stored information collected from another application. That is, unless you somehow make the two UIs share a communicating thread... but then when a UI is reactivated, it must update the state again and does not reflect real-time updates.

[huangzhinong]

Actually I don't really want to argue about POS and PPC. The main reason is I like POS a lot and I have serval POS devices. I have no problem with POS 6.0 multithreading at all, I think it's a good method to improve efficency.

The only thing I feel unconfortable is POS 6(only) shouldn't declare they implement industry standard multitasking while they only implement their own definition multitasking. If they call it multitasking, they are really stupid because they should say it much earlier-- their POS 3.0,4.0 and 5.0 are "multitasking" under the help of hackmaster and DA long time ago. Of course don't forget DOS 1.0 is also multitaskingable under POS definition.

[Deslock]

An interesting article, but it doesn't address the key weaknesses of CE's (and PPC's) mulitasking implementation: higher resource requirements, PPC's restrictive implementation, and Win32's tempermental nature. I expect Palm's approach to have its own problems and limitations, but hopefully it'll address some of the problems with the Win32 method (perhaps forcing Microsoft to fix problems with their mobile OSs, if that's possible).

Anyway, I also recommend that people read the book cited in the article, which details Microsoft's decision to base CE's design on NT:

Title: Inside Microsoft Windows CE
Author: John Murray
Publisher: Microsoft Press
Date: September 1998
ISBN: 1572318546

[JonnoB]

With the exception of Seymour, it was my impression that you could do all of this on a Cobalt device?


I don't see how it is possible. For example, if I have an application document with an application calcualtion result that is being constantly updated based on multiple data sources, and I need that result in real time in yet another application, I cannot get it. I have to switch the UI to allow the calculation to be made, copy it, then paste it into my new application UI. With a Pocket PC, the always executing application will always be current.

Here is another example. I can run a full-fledged application in the form of a CE-based SQL server and run multiple apps against it that are doing real work on that database updating that data based on calculations, etc that results are again put back into the database and reflected in UI in multiple windows in multiple applications. The application itself is running with as many threads as it needs and does not need to spawn off a background thread when its UI cannot run.

[omikron.sk]

It just doesn't go far enough. The Palm implementation reminds me very much of the old DOS-based TSR utilities - and that just doesn't cut it.


I keep reading on this forum how the Palm implementation of multitasking is not good enough, just doesn't cut it, etc. My question is why? Please give everyday examples of something a PPC device can do that a Cobalt device cannot do.

Lucan

Once I lended my PPC to my 2 friends when I had a lot of work and they did not. I found both of them using my PPC at the same moment! The first one was listening to the music thru the earphones and the other played Age of Empires (without sounds, but that really does not matter). And my PPC had no problems of handling this situation at all!

[omikron.sk]

Of course don't forget DOS 1.0 is also multitaskingable under POS definition.
You've hit the nail exactly on its head. :D

[omikron.sk]

An interesting article, but it doesn't address the key weaknesses of CE's (and PPC's) mulitasking implementation: higher resource requirements, PPC's restrictive implementation, and Win32's tempermental nature. I expect Palm's approach to have its own problems and limitations, but hopefully it'll address some of the problems with the Win32 method (perhaps forcing Microsoft to fix problems with their mobile OSs, if that's possible).

But don't forget that PPCs are more powerful and better equipped to this kind of "lifestyle", and also good PPC user will handle his/her apps to do not "eat" too much of system resources (if he/she wants to).

[c38b2]

I have found it curious that people keep referring to DOS as if it's some sort of bad thing! For the handheld platform perhaps DOSesque multitasking is more appropriate than the PPC version. Remember the Zen of Palm! 80/20! 80/20! :lol:

[Gerard]

c38b2 wrote:
I don't think it was a rebuttle - more like an in-depth look at exactly how Pocket PCs handle multitasking. Since he doesn't have a discussion forum I guess we'll have to discuss his comments here.
Who doesn't have a discussion forum? Jeff Kirvin has a dedicated discussion forum on pocketnow.com, which is the source for this thread on Thoughts. Chris De Herrera has a discussion forum, on CEWindows.net. I don't understand this statement, nor the connotation of the added smiley. Just wondering....

[c38b2]

Who doesn't have a discussion forum? Jeff Kirvin has a dedicated discussion forum on pocketnow.com, which is the source for this thread on Thoughts. Chris De Herrera has a discussion forum, on CEWindows.net. I don't understand this statement, nor the connotation of the added smiley. Just wondering....
I guess I thought Chris didn't - and looking at the page again.... where is it? :?

[Gerard]

His comments were addressed to readers in general, as well as to Jeff specifically. I don't see why any link to an exterior discussion site of his own is relevant. That's all I was questioning. It seemed an odd thing to point out. I mean, if I posted a comment here, in this thread, saying 'since c38b2 doesn't seem to have a discussion forum of his own, I guess we'll have to respond to him here', that would be strange, right? As it happens, Chris has a discussion forum here:

http://discuss.cewindows.net/cgi-bin/ubb/Ultimate.cgi?action=intro&BypassCookie=true

I moderate for him, as he's pretty busy with tablet PC stuff and work stuff of late. I meant no offence, was just curious about that comment, which seemed sort of 'out of nowhere.'

[c38b2]

I generally respond to comments on the author's site/discussion thread. This is how sites like Slashdot, PPCT, and Brighthand are run. I didn't see any link to a topic discussion so I commented that I would comment here in rebuttle to the rebuttle. That's all. :wink: Sorry if my redundant comment confused you.

[johncruise]

An interesting article, but it doesn't address the key weaknesses of CE's (and PPC's) mulitasking implementation: higher resource requirements, PPC's restrictive implementation, and Win32's tempermental nature. I expect Palm's approach to have its own problems and limitations, but hopefully it'll address some of the problems with the Win32 method (perhaps forcing Microsoft to fix problems with their mobile OSs, if that's possible).

Huh??? How then will POS address that limitation that CE has? If it cannot allocate a memory... where else will it get enough resources to run? If CE developers can see any other way to do this, you'll bet that they already did that rather than close other applications.

[Gerard]

By definition, a 'rebuttal' is a comment made in response to, and often in the same location as, the initial comments which inspired it. In this case, the thread is isn Jeff Kirvin's forum on pocketnow:

http://discuss.pocketnow.com/showthread.php?s=1acf84929a29e905222b3adf7bf98eef&threadid=15385

Are you unable to access this forum from your computer?

[felixdd]

If what Jeff is true, then the impliementation of POS's multithreading worries me. That's not true multitasking, as it seems that what threads will be killed, and what threads will be spared, is up to the developer. I don't know...but this might result in some unpleasant surprises wherein the reader would say, "I thought that function of the program was part of the 'stay alive' thread!"

And I'm reading the pocketnow thread -- as Jeff says, once a thread is finished it "should" be killed. Hope this is implemented well or Palm users will have to have a program that kills running threads, like we do with background programs!

My understanding of programming is rudimentary at best, so please correct me if this is a misconception.

[Will T Smith]

I find it interesting the Jeff mentions that the Pocket PC cannot have more than window being viewed... as if this was a fundamental flaw of the OS. It was intentional to make the experience in the Pocket PC seamless, not a limitation of the core operating system. To simplify the user experience, the PPC shell limits one top-level application to be viewed at a time, and the others are still running - just at a lower z-order. In fact, an application can have pop-up windows (see the screenx apps from mtux) that do not interfere with other apps in the z-order. The applications themselves actually can share the z-order top-level window with tools like seymore as well. These apps expose the true multi-tasking of the core OS. The Conduits MP3 player adds a notfication icon to control the player in the back-ground. This is the full application running in the background, not some seperate ui-less thread.

I do think it is an interesting step that PalmSource has taken to allow multiple thread processes... and it shows that MS was on the correct path. It just doesn't go far enough. The Palm implementation reminds me very much of the old DOS-based TSR utilities - and that just doesn't cut it.

People should be VERY careful when they talk about the core WinCE Operating System vs the PocketPC package.

In fact, WinCE CAN display multiple top level windows on the screen. There is at least one app on the market that enables this. And I suspect that we'll see even more that will allow putting two apps side by side once the trasition to VGA is underway (most apps will have to support both 320x240 & 640x480).

The portion of the OS that controls this is the window manager. On your desktop PC, this is represented by "explorer.exe". You can bring up the task manager and kill the "explorer.exe" process. Any applications that were open will work just fine. Save, you won't be able to move root level windows around after you've killed it. Indeed, alternative shells are available for Windows if you don't like the default Windows look and feel.


Back to the article, Ford vs Chevy. Yes, it's very clear that WinCE supports pre-emtive multi-tasking. Both Apple and Microsoft struggled for a LONG time with this transition to a modern OS infrastructure (like Unix). Palm chose to sidestep the issue and they are now dealing with the same struggle. Microsoft made the right decision to build the OS RIGHT in the first place.

The nature of Palm's new scheme isn't 100% clear yet. There seems to be a lot of confusion regarding how their "threads" will operate. If they aren't pre-emtive, then they aren't real threads. It's just co-operative multi-tasking no different than Windows 3.1 or classic Macintosh. When a "thread" can choose to hog the processor, it's NOT a "thread".

Palm users will balk and claim that there is no difference. In terms of the user experience, there may be no difference. However, the developer experience may be VERY different. Making a developers life more difficult means a longer time to market AND ultimately less applications due to a lower return on investment (and people giving up in frustration). It also results in buggier applications that are difficult to debug.

For most types of applications, it really won't matter. Most palm sized apps really don't need multi-tasking. However, the new connected variety of applications that are going to move cell-phone style devices absoluetly need multi-tasking capabilities.

In most cases, the types of code that's written to keep apps chatting was pioneered a 20 years ago with Unix internet applications. Enlightened OS vendors realize that there is no need to re-invent the wheel. Forcing applications to explicitely dealing with CPU changes forces them to re-invent wheels and write LOTS of unnecessary (and often buggy) code.

So look for all the cool IM apps (Odigo, ICQ, Blackberry, Jabber, IRQ, Trillian, etc...) to all come out for WinCE devices but lag behind on Palm). I also expect that Palm will be locked out of vertical markets for connected inventory, GIS and other data collection fleets.

Finally, if you've noticed the price difference between Palm and PocketPC has virtually evaporated. The only real advantage Palm had till this spring was higher resolutions (320x320, 480x320). That advantage will dissapear soon.

If Palm's future is the Treo style devices, they are woefully behind. Indeed, their talks with Symbian are very telling.

The other striking thing you'll notice is PalmSource's buyout of BeOS assets. For those of you unfamiliar with BeOS, it was the champion of multi-tasking. One would expect that some of the Be guys could be their methods into the Palm OS. Apparently, this effort has NOT bore fruit yet. I suggest they get pre-emptive multi-tasking into their OS ASAP.

[pacemkr]

This is more of a question than a comment...

Wouldnt the POS approaches be significantly slower?

Ed's example is probably good for this. Lets say you had to switch between two or more applications every few seconds. And lets suppose the applications are heavy (database software of some kind for ex). Wouldn't this just crawl on Cobalt? Because it would have to get the information from the background thread every time you switch to that app and rebuild the UI based on that info. And if you have ~1000 entries in a database. I know it takes several seconds to load this info for the first time on PPC, but then you can switch between applications as much as you want with absolutely no lag. In Cobalt this would mean loading that information every time you switch to the app. I suppose POS is very good with handling limited processing power, but isnt this just too much to handle? And if the devices had the same specs, wouldn't PPC still have a big advantage?

[gorkon280]

This guy has no freaking clue about the slider. The slider,in my opinion, is freakin useless. I have adjusted it in the past, closed that out and done other things and gone back and it's BACK in the middle. It's useless. The one thing that IS an option on PPC is soem day, they can turn on the specific bits that make it act, more or less, like NT. I see some day soon where the OS either continues to boot off rom or as an option, can boot off of the integrated Microdrive. When pluggied into a docking station, it will run as large of a screen as you can currently with XP and you will not just be able to run pocket word, but the whole thing. Honestly, people saying that Pocket PC's are constrained resource wise any more is getting a bit on the silly side. I mean we now have a 400 MHz processor, 128 MB of ram on some devices (with about 64 for execution...) the only thing missing is a true and hard separated limit for storage and memory. If they just changed things a hair, they could integrate the microdrive, make all memory for execution only and you literally have a pc in your palm. Remember, CE is a subset of NT. Microsoft can choose to add more of the API and you should be able to get it to do more desktop like things. Palm has no chance at this without a complete rewrite....more so then pocket pc ever will. Pocket PC will literally be a Pocket PC.

Also BTW, Pocket PC can multithread as well. Just thought I would add that too. Chris was just being nice as he could have slammed this Palm OS guy because the gu7y who wrote it has no clue about mondern os design.

[Deslock]

An interesting article, but it doesn't address the key weaknesses of CE's (and PPC's) mulitasking implementation: higher resource requirements, PPC's restrictive implementation, and Win32's tempermental nature. I expect Palm's approach to have its own problems and limitations, but hopefully it'll address some of the problems with the Win32 method (perhaps forcing Microsoft to fix problems with their mobile OSs, if that's possible).
Huh??? How then will POS address that limitation that CE has? If it cannot allocate a memory... where else will it get enough resources to run? If CE developers can see any other way to do this, you'll bet that they already did that rather than close other applications.
As I wrote, POS will probably have its own problems, but its approach to multithreading may have lower resource requirements and may be less tempermental than CE's implementation.

[foghead]

I keep bringing this up in different discussions.

The biggest problem with Cobalt is the fact that ALL background threads run in a single address space and are no user controllable.

This means that one rogue thread can kill ALL background threads and even the single tasks that is running them. There is a mechanism to attempt to restart background threads if this happens, but you will still lose any unsaved state, and if the crashy thread is restarted, you may have to reset to get rid of it.

Additionally, there is no mechanism provided to kill background threads if they don't terminate themselves. There is also no mechanism for a user application to enumerate background threads so that you could write a third-party thread killer.

At least PPC provides a mechanism to shut down tasks without having to reset the device.

[johncruise]

An interesting article, but it doesn't address the key weaknesses of CE's (and PPC's) mulitasking implementation: higher resource requirements, PPC's restrictive implementation, and Win32's tempermental nature. I expect Palm's approach to have its own problems and limitations, but hopefully it'll address some of the problems with the Win32 method (perhaps forcing Microsoft to fix problems with their mobile OSs, if that's possible).
Huh??? How then will POS address that limitation that CE has? If it cannot allocate a memory... where else will it get enough resources to run? If CE developers can see any other way to do this, you'll bet that they already did that rather than close other applications.
As I wrote, POS will probably have its own problems, but its approach to multithreading may have lower resource requirements and may be less tempermental than CE's implementation.

Sorry Des... I'm wearing my dev hat on this discussion this time (I'm guessing you too since you're in this thread). :-) Anyway, I just couldn't figure out how they would make the resource any lower :confused totally: . Whenever you thread an application, you have to retain that same memory that the program is using plus it's state (program counters, stacks, heaps, etc). I don't see any way this can be lowered as it is. Saving those to a temp file is not an option either.... RAM and flash memory space are theoretically the same unlike PC. It's either they keep the old program in memory or they let it go. File system or Database... however they implement it, when they go multithreading, they both will go to this route of saving previous state. :-(

[Gerard]

Gorkon280; I'm puzzled by your comments on the slider. Yes, it can be temperamental at times, especially if one initiates some massive CPU-draining action like resizing an XVGA JPEG or capturing 128kbps MP3 in NoteM. The 'Program Memory' portion will grab some of the 'Storage Memory' allotment, and not give it back after the process is finished. But to generalise that it just always jumps back after manual adjustment is nonsense. I've been using various models of Pocket PC since they first came out, and in every case I have seen great stability of this adjustment, provided I do not slide it too far one way or the other. While an absolute number is not really applicable, in general it is safe to say that leaving 15% of the total available RAM at one end or the other should be stable in most conditions. This has been very convenient for me, especially when trying to make best use of video capture with a CF camera, or stills for that matter. The older Casio line (I had the E-115 and then EG-800) would go from shooting 12 second videos to shooting 50 second videos if i just moved the slider to allow about 85% of RAM to function as Program Memory. In a sort of inversion of this, sliding it to allow more Storage Memory allows very long captures of audio using NoteM, or lots of pictures with my Dell Axim X5 using CECam software and the Pretec 1.3Mp CF camera. I regularly adjust for lots of program memory when doing image processing in PQV or Pocket Artist or Photogenics. After such uses, having closed the programs involved, I find the slider more or less where I last put it. If I've been multi-tasking in several very intensive applications, then of course the memory slider will have reset itself, but it is rare that one needs to do image work on a large scale while recording new media and browsing the web too.... I mean, multi-tasking works on the PPC, but 400MHz is still a bit limiting.

[Deslock]

Anyway, I just couldn't figure out how they would make the resource any lower :confused totally: . Whenever you thread an application, you have to retain that same memory that the program is using plus it's state (program counters, stacks, heaps, etc). I don't see any way this can be lowered as it is. Saving those to a temp file is not an option either.... RAM and flash memory space are theoretically the same unlike PC. It's either they keep the old program in memory or they let it go. File system or Database... however they implement it, when they go multithreading, they both will go to this route of saving previous state. :-(
With CE, the entire program needs to be copied from storage-RAM to system-RAM (unless it's in the unit's flash, right?) That's what I'm thinking may result in RAM-savings with the POS approach. Additionally, Win32 occasionally causes seemingly random system slowdowns... we don't know if POS will have those kinds of strange CPU-usage spikes.

My point is that before people dismiss the POS approach, give it a chance.

[johncruise]

With CE, the entire program needs to be copied from storage-RAM to system-RAM (unless it's in the unit's flash, right?)

Hmmmm... that very much is true. Does POS even have that option? (I mean, install the programs into a storage card and run it "from there"?)

[Will T Smith]

Anyway, I just couldn't figure out how they would make the resource any lower :confused totally: . Whenever you thread an application, you have to retain that same memory that the program is using plus it's state (program counters, stacks, heaps, etc). I don't see any way this can be lowered as it is. Saving those to a temp file is not an option either.... RAM and flash memory space are theoretically the same unlike PC. It's either they keep the old program in memory or they let it go. File system or Database... however they implement it, when they go multithreading, they both will go to this route of saving previous state. :-(
With CE, the entire program needs to be copied from storage-RAM to system-RAM (unless it's in the unit's flash, right?) That's what I'm thinking may result in RAM-savings with the POS approach. Additionally, Win32 occasionally causes seemingly random system slowdowns... we don't know if POS will have those kinds of strange CPU-usage spikes.

My point is that before people dismiss the POS approach, give it a chance.

Unlike a traditional computer, WinCE does NOT copy programs from secondary storage to main memory. Programs run in place where they are stored (this is why running from a CF card is a bad idea). The program stack and heap reside in program memory space.

[Will T Smith]

This is more of a question than a comment...

Wouldnt the POS approaches be significantly slower?

Ed's example is probably good for this. Lets say you had to switch between two or more applications every few seconds. And lets suppose the applications are heavy (database software of some kind for ex). Wouldn't this just crawl on Cobalt? Because it would have to get the information from the background thread every time you switch to that app and rebuild the UI based on that info. And if you have ~1000 entries in a database. I know it takes several seconds to load this info for the first time on PPC, but then you can switch between applications as much as you want with absolutely no lag. In Cobalt this would mean loading that information every time you switch to the app. I suppose POS is very good with handling limited processing power, but isnt this just too much to handle? And if the devices had the same specs, wouldn't PPC still have a big advantage?

I don't think this necessarily prejudices PalmOS. One could write a background "palm thread" (I'm not convinced these are real threads) that updated a data cache on an interval, or responded to update messages. When the App was brought to the foreground, it would be ready to populate it's UI without a network request.

[Gerard]

I keep seeing this crap about how CE copies programs to RAM to run them, seen it for years now. Evidence of this? None, not that anyone has ever shown me. Here's a pragmatic little excersize i just ran, to demonstrate the absurd wrongness of this statement.

Textmaker, by SoftMaker, is one of the bigger resource-hogs in the Pocket PC software arsenal. It's a serious word processor, with an installed presence in basic representation of about 7.6MB, which can climb a lot higher depending on user choices of added dictionaries for other languages. The EXE file, the central one needed to run it, is about 5.3MB. Now, I have several very reliable tools for measuring memory usage, including Sprite's PocketMon, Tapani Otala's FreeSpace plugin for Dashboard, Resco's Explorer contains a fine resourse monitor... and of course there's the native Memory applet in the device Settings. All concur in the instance of comparing pre- and post-launch memory conditions for Textmaker. The difference? Exactly 2.44MB, on both my old iPAQ 3835 and new Axim X5. That's less than one half of even just the executable element, never mind all the other assistant files the program has already loaded.

When I opened Microsoft's basic little calculator, which is in ROM on every PPC, I lost an additional 560KB of RAM, vastly out of proportion to the size of the executable at 75KB. Closing that calculator after running the subtraction of memory before and after numbers, I get back 100% of the resources the calculator grabbed. Apparently it's a memory hog for it's size, not nearly so efficiently made as Textmaker.

Shutting down Textmaker, I get back everthing but for about 90KB, so apparently there's a tiny leak or residue here. For reference; I have Textmaker installed to an MMC card on the iPAQ 3835, to an SD on the Axim. It loads ready for use in approximately 13 seconds on the iPAQ, 14 seconds on the Axim. when I've run it from a few differently formatted and speed-rated CF cards in the past, and from an Accurite external hard drive, I've had open times between about 7 seconds for the HDD and 25 seconds for the slowest, cheapest CF card. 12 seconds is average, making this the slowest program to load in my repertoire, including Tomb Raider which beats it by about 1 second if I fast-forward through the author credits with the D-pad.

Can we call this nonsense about loading entirely into RAM on launching settled now, please? It's a dead horse, and just ain't so. On the other hand.... don't Palms have to load card-base programs into main memory to run? Seems that's a hard and fast rule, from what I've heard. Or maybe that's untrue too? Please, Palm users, educate me. That is, if you can multi-task sufficiently well to get accurate memory readings before and during and after loading another program into memory.... which perhaps you can't?

[JonnoB]

Programs stored on ROM or in the internal RAM are executed with a technology called XIP (execute in place). It is possible for an application to allocate more memory space when running, but the memory footprint the program is stored in is the actual processes initial memory allocation. It does not have to take more memory necessarily.

[Fishie]

With regards to the windows, yes PPC and WinCE are able to show multiple windows, the handheld PCs are a nice example and with my Toshiba e800 I noticed that some windows running a program in quarter VGA can be moved around about the screen thus adding the ability to show multiple windows simultanously just like a desktop PC would.
Its not a technical limitation of the OS, its a design decision by MS.

[Blue Sky Miner]

So, being new to all this, if I understand this correctly, Windows CE (and therefore Pocket PC) has a hard limit of 32Mb per application. If a programs is stored on ROM or Storage Memory, then XIP will allow them to not use much more Program memory to achieve this?

I take it that programs need to be written specifically to take advantage of XIP? If you have a 10Mb application in Storage Memory which blows up to 20Mb in Program Memory, then by using XIP you would only be using the 10Mb of Storage Memory plus the extra 10Mb of Program memory, or is this too simplistic?

Does CE 4.2 have any speed/performance advantages over CE 3.0. Do CE 3.0 applications need to be re-written to run on CE 4.2, or are they backward compatible? If so, why did the move from Pocket PC 2002 to Pocket PC 2003 cause so many applications to break?

Very interesting discussion - I'm learing a lot by listening to you guys.
:D

[Ed Hansberry]

So, being new to all this, if I understand this correctly, Windows CE (and therefore Pocket PC) has a hard limit of 32Mb per application. If a programs is stored on ROM or Storage Memory, then XIP will allow them to not use much more Program memory to achieve this?
At this time, there are no apps that come even close to needing 32MB to run. I don't know if each process has a hard 32MB limit or not either.
I take it that programs need to be written specifically to take advantage of XIP? If you have a 10Mb application in Storage Memory which blows up to 20Mb in Program Memory, then by using XIP you would only be using the 10Mb of Storage Memory plus the extra 10Mb of Program memory, or is this too simplistic?
Only the portion of an app that needs to be in RAM is in RAM. Your storage memory is like a hard drive and the PPC will get what it needs when it needs it. It doesn't copy the entire .exe to RAM to process.
Does CE 4.2 have any speed/performance advantages over CE 3.0. Do CE 3.0 applications need to be re-written to run on CE 4.2, or are they backward compatible? If so, why did the move from Pocket PC 2002 to Pocket PC 2003 cause so many applications to break?
4.2 is much faster. The only apps that had a problem going from 2002 to 2003 were drivers, games with complex video and apps that relied heavily on the PIE engine. I am sure there were a few others that broke for one reason or the other, but it was likely they were using some undocuemnted feature of 2002 that got turned off or were incorrectly using a feature that got changed in 2003. I didn't notice any issues with the dozens of apps I use except those that fit into the categories above.

[Blue Sky Miner]

So, being new to all this, if I understand this correctly, Windows CE (and therefore Pocket PC) has a hard limit of 32Mb per application. If a programs is stored on ROM or Storage Memory, then XIP will allow them to not use much more Program memory to achieve this?
At this time, there are no apps that come even close to needing 32MB to run. I don't know if each process has a hard 32MB limit or not either.

So where do memory mapped files come in? If I read this correctly, it is possible to access more than 32Mb at once though these files: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcemain4/html/_wcesdk_memory_mapped_files.asp

Is that correct and is there a speed or other penalty for doing this?

I take it that programs need to be written specifically to take advantage of XIP? If you have a 10Mb application in Storage Memory which blows up to 20Mb in Program Memory, then by using XIP you would only be using the 10Mb of Storage Memory plus the extra 10Mb of Program memory, or is this too simplistic?
Only the portion of an app that needs to be in RAM is in RAM. Your storage memory is like a hard drive and the PPC will get what it needs when it needs it. It doesn't copy the entire .exe to RAM to process.


Sure, so do programmers need to code specially for this or is it automatic?

So if Textmaker runs at 7.6MB, are there any larger applications for CE or PPC?

Thanks.