Why PalmSource May Be Right About Multitasking

[Alexander Turcic]

More on WM's memory management here:
http://msdn.microsoft.com/library/de...advmemmgmt.asp
http://msdn.microsoft.com/library/de.../threads30.asp
http://blogs.msdn.com/mikezintel/arc...08/278153.aspx
http://cs856.watsmore.net/windowsce_arcd.pdf (PDF)

You can assign more than 32MB of memory in one process by using memory mapped files:

When a Windows CE-based device starts up, the operating system creates a single, 4-GB virtual address space, which all of the processes share. Part of this address space is divided into 33 "slots" of 32 MB each, one for each process's resources. As each process starts, Windows CE assigns it one of the available 32-MB slots. Slot zero is reserved for the currently running process.

When a process starts, the OS stores all of the dynamic-link libraries (DLLs), the stack, the heap, and the data section in the slot that is assigned to the process. DLLs are loaded at the top of the slot, and they are followed by the stack, the heap, and the executable (.exe) file. The bottom 64 kilobytes (KB) are always left free. DLLs are controlled by the loader, which loads all of the DLLs at the same address for each process.

In addition to assigning a slot for each process, Windows CE creates a stack for the primary thread and a heap for the process. The maximum number of threads that a process can maintain is dependent upon the amount of available memory. You can allocate additional memory outside of the 32 MB that is assigned to each slot, by using memory-mapped files or by calling the VirtualAlloc function to reserve or commit a region in the calling process's virtual address space.

If that is a good thing, I don't know. Laurens was mentioning the limit not to point out a disadvantage, I think, but a safe-guard by Microsoft to prevent process from misbehaving (by allocating too much of the total available RAM).

[macrotor]

This really boils down to how the user will use the device. I think it's great that devices have become powerful enough that running multiple CURRENT apps is possible, but developers often max out a devices capability.

I prefer saved-state (with support of background threads) for the following reason:
A program will have nearly ALL resources available to it while it runs.

Until we develop a device that allows us to SEE multiple applications at once, there is little need to be running multiple entire programs at once. Even if you throttle down the CPU usage of a background app, it is still using a chunk of the heap RAM. I suppose you could try to move that RAM to a swap-space, but that means there will be a noticeable delay every time you switch.

However, as I said before, developers LOVE multi-tasking. It puts all the strain on the user instead. Now I have to deal with selecting what apps are active based on their use, CPU use, and memory use. How easy is the app to restart and get where I left off versus just letting it run in the background and suck down resources?

Developers do NOT like having to deal with multi-threading and save-states. It's a royal pain. But, as a user, I sure do like a program done right.

However, this is where I turn around and state that multi-tasking will be the future-wave anyways. Why? My Palm now has an obscene number of programs on it. It is naive to think that they are all programmed to play well with each other. My screen may be small, but 320x480 IS enough to start running "widgets" in the corners. Besides, some of today's programs are so large that re-starting takes more time than it would take to move swap-space back to the heap RAM. As for RAM, I remember a day when 2MB was considered plenty for both heap, databases, and programs. Now there is 245MB or RAM. There WILL be devices with sufficient RAM to do real multi-tasking.

In other words, we are now at the beginning where only games and video require ALL resources, so task-switching will become unnecessary. I prefer Palm's method...for now. I think PocketPCs were trying to be a laptop long before they had the power to do so, and their usability has suffered because of it. But I applaud Palm's switch to Linux and multi-tasking. The hardware has finally arrived (LifeDrive and T5), but now the software needs to catch up.

(How's that for seeing both sides?)
- Jim

[TadW]

Originally Posted by macrotor

I prefer saved-state (with support of background threads) for the following reason:
A program will have nearly ALL resources available to it while it runs.

I am not sure about HEAP allocation and such in Windows Mobile 2005, but unless you run out of memory, I have never had resource trouble when running multiple applications at once on a Pocket PC.

Until we develop a device that allows us to SEE multiple applications at once, there is little need to be running multiple entire programs at once.

Well, except for those who like to do multiple things at once, like Alex's example with the Internet applications. Btw, there is a tool called Seymour for PPC which allows you to SEE two running applications at once:
http://msmobiles.com/news.php/2294.html

How easy is the app to restart and get where I left off versus just letting it run in the background and suck down resources?

Like I said above, I don't see where resources are suck down when you run PPC applications in background.

In other words, we are now at the beginning where only games and video require ALL resources, so task-switching will become unnecessary. I prefer Palm's method...for now. I think PocketPCs were trying to be a laptop long before they had the power to do so, and their usability has suffered because of it. But I applaud Palm's switch to Linux and multi-tasking. The hardware has finally arrived (LifeDrive and T5), but now the software needs to catch up.

Totally agree with you here!

[surur]

As you said, PPC's started of with the expectation that hardware will catch up, which is has. Now it has much less retooling to do than POS. There is actually a number of small programs that take advantage of multi-tasking by displaying stuff in a window. That task manager in my example picture is one of them. There is also sidex, which is a program launcher etc which swoops in from the side of the screen ( http://www.mtux.com/info_sx.aspx ), floating calculators (http://www.pocketgear.com/software_detail.asp?id=3424 http://www.pocketgear.com/software_detail.asp?id=5150 ) floating sticky notes and even an app that will split the screen. The ability is built-in, and people can and do use it.

Surur

[surur]

I finally found the ultimate multi-tasking demonstrator.

Seymour allows you to work better with your Pocket PC by giving you the ability to view any two applications at once, including the Today screen. This lets you simplify how you work with your favorite applications and share data between them.

http://www.handango.com/ampp/store/P...&productType=2

If its running in the background you might as well show it also.

Surur

[Dianne Hackborn]

I am going to try to make some quick replies while I have a little time.

First, let's get this out of the way:

Originally Posted by Voice_of_Reason

Your buddy, Ms. Hackborn suddenly became silent (unusual for her ) when pressed for details on what Cobalt can really do IN PRACTICE rather than IN THEORY.

In an exchange along the lines of "does not", "does so", "does not", looking at who last spoke doesn't say anything about who is actually right.

I already replied to your question a long time ago, and the answer is still the same: Cobalt's multithreading and process support doesn't have any of the problems you keep alluding to. The only limitation is that applications running separately from the main application all share the same process, which I have been very upfront about. In practice, about the worst this means is that if you are, for example, using a web browser that makes use of the background process to remain running, if some other background thread crashes, the web browser will be killed as well and you will end up back in the Launcher. Note that the main application runs in its own process, so a crash in the current application won't disrupt other running applications.

Unless you are going to give actual information along with all of your claims about Cobalt's faults, there is nothing more I can contribute to this discussion. I have tried to be very clear about what is going on technically in order to explain how things work and what it means. From what I can see, you really know nothing about Cobalt, but are just making baseless accusations. If that's not the case, put up and post some actual detailed explanations of how you reach your conclusions.

Originally Posted by Voice_of_Reason

Hardware is slowly catching up to the intrinsic inefficiencies of PPC. On the other hand, hardware bypassed PalmOS way back in 2001. The writing has been on the wall for years, but only recently has Palm started planning for the future.

Well, we started Cobalt in 2001, with one of the key intents being to rearchitect the system to take advantage of the much more powerful hardware that was appearing on devices. I agree, though, that it was late -- Cobalt ideally should have been started a few years before that.

Anyway, on to better stuff...

Originally Posted by TadW

True, but that shouldn't be a problem anymore. The Palm V had 2MB Ram and Flash and didn't offer multitasking. The Tungsten T5 has a whopping 256 MB of total memory (which includes the user-accessible RAM and Flash), and still doesn't offer multitasking.

All I am saying is that as hardware develops and opens up to new possibilities, we shouldn't be arguing that software technology that dates back almost a decade is still preferable to newer technology.

When I joined PalmSource, even though I was trying to avoid being stuck in the desktop mentality, this is still something that caught me by surprise: the hardware in handheld devices does not evolve like it does on the desktop.

The difference is subtle, though, because it does evolve kind-of like the desktop, but only at the high end. The thing is, rather than the high end of today fairly rapidly becoming the mainstream of tomorrow, instead what happens is that the range of hardware capabilities spreads, and you can now take the older hardware and make cheaper/smaller devices.

Here's an example: when we started doing Cobalt, our reference board was a 200MHz Intel PXA250. We designed the system with that as our base target, with the assumption that if we could get by on the edge of reasonable performance on that board, we'd be in very good shape when we were done with development.

However, today we are working with a licensee whose hardware is slower than that PXA250 from four years ago. Huh?!? That was a surprise. It's not an insurmountable problem, but it does mean spending more time on more optimizations than we thought we'd need to do.

Here's something even better: I have talked with some device manufacturers who want to run a Cobalt or Linux class operating system on a 50 MHz ARM 7. The ARM 7 processor doesn't even have an MMU...

So though the T5 may have 256 MB of memory, we would like to still be able to run Cobalt on 16MB RAM + 16MB flash (our current minimum configuration), even when we move to Linux. For a lot of device manufacturers, especially when you are in the phone space, that is not very low-end. And now they want to have all kinds of 3G services and video conferencing and videos and mp3s and web browsers running on such a device. Fun!

Originally Posted by surur

BTW, I still have not see anybody address the disadvantages of Saved State vs multi-tasking yet. Isn't this what the whole thread is all about?

I think the key thing is that this isn't really an either/or question. For the kinds of things these devices are doing -- multimedia, all kinds of communications stuff, web browsing, etc -- multithreading and multiple running applications is required. That doesn't mean, however, that you should be forced to use it for things where it doesn't give any benefit, such as in your address book app.

From a user experience perspective, one thing that would be nice is if the applications the user interacts with could make use of one or the other approach in a way that matches what the user expects. That is, if an application wants to stay running, that is because it is actually doing something (such as playing an mp3), which the user knows about it doing, so they will naturally just think of it continuing to run while switching to other things. However, if it is something like an address book app, from a usability perspective it is a benefit to not have it stick around, because then you don't have to come up with some artificial way for the user to find out that it is still running and deal with it.

So to my mind what it gets down to is not a question of what basic functionality the operating system provides -- we know what that is, it's threads, and processes, and all the traditional OS stuff that has served us well for 30 years. The real challenge is how you take this standard functionality and present it to the user in a way that makes sense for a handheld device.

And I have to say, I feel pretty strongly that a good handheld user experience is not at all just a PC experience shrunk down, in the same way that the PC experience needed to be fundamentally different than minicomputers.

[macrotor]

@surur: I like the Seymour app you posted there. I can only think of a couple situations where I would use that...but I must admit that I really would like to have that WHEN I needed it. Mainly, it would be nice if I could have both my outliner and Word Doc available at once. Waiting for WordToGo to boot every time I switch gets a little old.

@Hackborn: Thank you for joining us! I must say your comments about your hardware constraints add a little light. Let me see if I can summarize properly (and correct me if I'm wrong):
You are unable to truly program for the high-end devices because Palm still wants the new OS to run on the economy devices. Hence, your comment about putting the Linux onto a 16RAM/16Flash device.

I really hope I got that wrong, because you are about to get rained with all kinds of comments about "holding back and crippling" the high-end devices for the sake of the economy devices. The fact that the Zire21/32 series actually uses POS5 is still a mystery to me. They have lo-rez screens, so compatibility is out the window, anyway. They should've been POS4 devices, so that POS5 could have been programmed for the big guns. You have a T5 and a Life-Drive. You should be programming to max out THOSE devices. Let the cheapies run on yesterday's OS for now. People who get the cheap stuff aren't looking for latest & greatest.

Whoa....way off topic. My apologies. Back on subject:
I do agree that some programs don't need to run in the background (addressbook, etc). Once again, does the load go to the developer or the user? A part of me would like to have something akin to the "nice" function in Linux: let me set the background priorities of apps. However, that feature itself would take a load.

Cooperative task-switching is great for squeezing the most performance out of a device, but it relies on all the programmers playing nice with each other. Multi-tasking has a high overhead cost. Remember how PPCs had a much more powerful processor, yet seem to run the same speed of POS4 devices? That's why.

Apple Computer use to do threaded task-switching, etc up to MacOS9. It made for a very fast system. However, many programs and extensions were starting to not play nice with each other. Stability was going down the tubes. Programmers were whining about how difficult it was to program for the Mac. Things had simply become too complex. Once the hardware became powerful enough, Apple switched to a robust, multi-tasking, protected memory system (OS X). Sure, it was a massive CPU-drain, but the new processors could take it, and now the user had stability and customized multi-tasking.

I love OS X on my G4, but it would have been silly to try to put that on my old PowerPC. When PocketPCs first came out, I saw it the same way: their design concept was stupid-silly.

But now we have the Hardware. I don't give a flying zip about your 16MB devices. Let the PowerPCs run MacOS9, and let the 16MB devices run POS5 or POS4. I want the LifeDrive running full-bodied, mutli-tasking Palm-Linux, not some diluted OS that was designed for a Zire31.

Okay, I'm done (for now). The PalmSource guys have done some great magic in the past, so I know they have some magic prepping for the future. I'm mostly fearful that PalmOne will mess up the hardware and force PalmSource to streamline and cripple their upcoming OS.

- Jim

[Bob Russell]

You know, I think this thread and others like it point out a great opportunity for PalmSource to put out some simple whitepapers to clarify a few topics. It would be something that could be referred to over and over to clarify discussions. Heck, they could even put page and paragraph numbers so you could quote passages from a particular version in the average discussion. Topics like...
* PalmOne vs PalmSource (which will probably always be somewhat confusing even after the name change or PalmSource)
* How multitasking/mulithreading works in Garnet, Cobalt, PalmOS for Linux, and how it compares to Win Mobile
* Benefits of PalmOS
* Laymans explanation for NVFS and palm databases vs MS file systems
... and whatever other topics just keep coming up over and over and never seem to be clear. As long as it's not just Marketing fluff!

I'll follow off-topic just briefly here, because it was an interesting point brought up, and then return on-topic.

Concerning the OS accomodating lower spec handhelds, I would have to say that I don't see it as a bad thing. Even so, I suspect that a lot of OS level adjustments can be made over time to grow with the hardware. But I think it is pretty nice to have a more powerful pda that really acts zippy. I feel the same way about desktops... it's horrible using them when things run slow, and sometimes you need the best desktops to get things zippy.

True, you only get benefit from faster CPU up to a point, but still I like hardware that can make up for sloppy apps that seem be so slow on the average handheld. Surely even third party developers have to consider some of the lower spec devices for the same reason -- to widen their market. I think it's good because the wider a market we see for the OS, the more PalmSource makes, and the more they can reinvest for the future. And, for good or bad, the biggest slice of the market is not in the top line spec devices, but the "average cell device" that is getting more and more powerful every year.

I second your thanks for Dianne's participation. Really cool stuff!

There will always be those of us frustrated with PalmOne and PalmSource, and there will certainly be many who just naturally prefer Pocket PC (which is okay because they have a great product also). But I am convinced that the more you learn about what PalmSource is really doing, and why, the more you respect their work and want to cheer for them to succeed. They more they succeed, the more great device choices we get to see in our hands! And even if you don't think they are making all the right choices, you have to at least get the feel that they are making some good choices and be excited about the great stuff that's coming. It's just hard to wait!

Okay, back on-topic...

With regard to multitasking in Cobalt, remember that

Originally Posted by Dianne Hackborn

Cobalt's multithreading and process support doesn't have any of the problems you keep alluding to. The only limitation is that applications running separately from the main application all share the same process, which I have been very upfront about. In practice, about the worst this means is that if you are, for example, using a web browser that makes use of the background process to remain running, if some other background thread crashes, the web browser will be killed as well and you will end up back in the Launcher. Note that the main application runs in its own process, so a crash in the current application won't disrupt other running applications.

So I think that with the exception of those shared threads not protecting as completely against inter-program interference, you can do pretty much the same basic things with Cobalt as Win Mobile multitasking. We may see it looking a lot better after some more UI changes which are coming after some of the core underlying and invisible work is done.

And I can't remember where, but I think I read somewhere that the way threads are handled can be changed as the hardware grows without major OS rewrites. (Not positive about that one.)

I think the UI is really the big deal here. With WinMobile you basically have a list of windows/apps that are running, and you don't have to worry about whether or not they are built to run in the background, or what state they will return in. You can even do some fancy things showing multiple applications at once on the screen, like we saw above. Pretty cool.

But don't forget that there are ways to do all that in Cobalt. Hopefully I don't have this all wrong. But the basic assumption seems to be one app on the screen being used at one time, which is pretty reasonable. (So you may not see those split screen apps for a long time, unfortunately.) But with such small handheld screens, especially in phones, you may not really want that too much. I think you can still have popup screens running in parallel with, say, a small overlay or popup or maybe cutout screen for something like the mp3 player while you are doing word processing. Or you can have various kinds of control bars to manage background processing for things like downloads. You could even have split screens for game interaction. But, yes, the applications are probably more responsible for managing how that works. That's another thing that will probably have to be improved in the OS.... support for developers to do that sort of thing more easily and gracefully.

Sounds like the state thing does matter, though, when you pull an app back up, and right now apps haven't really been able to do that well on PalmOS, so I suppose that is an indicator that the support structure isn't fully there yet. But all the other things that a user would (or should) care about seem to be relative to the UI design.

And I've seen enough to convince me personally that it's not just PalmSource blowing smoke, but that they have some pretty significant infrastructure work that's being done and UI work will move much faster very soon. Surely they are aware that their primary IP advantage in the Linux space is going to be UI and managing environments on mobile devices. That means that it's got to be a high priority on their UI work and they'll have to back it up with their internal resource allocation.

I don't think multitasking approaches are going to be significant enough to push many users to one camp or the other (unless people get caught up in the wake of the MS Marketing machine). Like I said, I haven't really heard any disadvantages to the PalmOS approach except some apps that don't handle state properly and some UI work that needs to be done to handle app switching on both WinMobile and PalmOS side anyway.

[Dianne Hackborn]

Originally Posted by macrotor

You are unable to truly program for the high-end devices because Palm still wants the new OS to run on the economy devices. Hence, your comment about putting the Linux onto a 16RAM/16Flash device.

One correction: in fact it is not nearly so much palmOne who wants Cobalt on lower-end devices, but rather other device manufacturers (in particular phone manufacturers) who have these lower-end requirements. Remember that PalmSource does the software; the hardware requirements come from the licensees we work with.

(And if you find it a little ironic that palmOne would be the one with the higher-end devices, while still not having a Cobalt device... well I do too!)

Btw, this is part of the explanation for why early on when Cobalt was introduced, Garnet was being positioned as the more phone-oriented product: the phone space tends to push down really hard into lower-end hardware, since it is so price and size competative, so from that perspective the lighter-weight Garnet seemed like a good choice for it. At it turns out, however, phones are also the devices that have the most need for some of the modern features in Cobalt, so it is really a much better platform for that market, as long as we don't go nuts with assumptions about how fast hardware capabilities are going to grow.

Personally, I think that we went from a system that was way under-powered for the hardware it was running on (Garnet), to one that is probably a little over-powered for the class of hardware we have right now. In the short-term, that means we ended up doing a little more work than expected to optimize parts of it, but we definitely have a good foundation on which to build for many years to come.

Originally Posted by macrotor

I really hope I got that wrong, because you are about to get rained with all kinds of comments about "holding back and crippling" the high-end devices for the sake of the economy devices.

Since we only do the software, I can't address the hardware in specific devices. However, in terms of the operating system, what this mainly means is that scalability is much more important in the software on these devices than it is on a desktop operating system.

This is something that we had in mind from day one when designing Cobalt, and that goal has gone into a lot of its architecture. In particular, as I recently discussed elsewhere, we think that one of the things needed to achieve better scalability is to have a lot more flexibility in how processes are used, instead of the traditional approach where an application is directly associated with its own process.

To achieve this, nearly all of the Cobalt system software is built on top of a standard component framework similar to COM or CORBA (it is called the Binder, if you've seen that mentioned elsewhere), but designed for system-level services as well. One of the main things a component system does is hide where a particular object lives -- you just make a call on an interface, and the object you are talking with can be in the same process as you or some other process. The caller doesn't care, and the component framework will implement this call as a direct function call or cross-process call as needed.

Because of this, we can basically decide, at runtime, how we are going to distribute the operating system and applications across processes, in any way we want. If we run everything in the same process, all the process and IPC overhead goes away, allowing you to run on much lower-end hardware. That doesn't mean you can't scale up to higher-end hardware, and in fact as time goes by we will be able to do some really nice stuff like run a web browser application in one process while a plug-in like RealPlayer that is embedded inside its web page can run in another process. That way, if the plug-in crashes, the browser itself is not disrupted at all, and there is no extra work required of the browser or plug-in to make this happen.

Truth in advertising: the current Cobalt kernel has a fairly embedded mindset (read "hard-coded") when it comes to processes, which limits how much we can use this aspect of the system. We do use this feature for things like running multiple applications in the background process, but today we can't go so far as to run everything in a single process. That should change when we move to Linux.

Originally Posted by macrotor

Cooperative task-switching is great for squeezing the most performance out of a device, but it relies on all the programmers playing nice with each other. Multi-tasking has a high overhead cost. Remember how PPCs had a much more powerful processor, yet seem to run the same speed of POS4 devices? That's why.

I am not sure about the terminology here -- no version of PalmOS has ever used cooperative task-switching, they have always been built on top of a pre-emptive multithreaded kernel. The limitation was that they only exposed one of those threads to applications, and all of the higher-level parts of the system (UI and other things) were single-threaded, so there was essentially no multithreading at all available to applications.

Originally Posted by macrotor

Apple Computer use to do threaded task-switching, etc up to MacOS9. It made for a very fast system. However, many programs and extensions were starting to not play nice with each other. Stability was going down the tubes. Programmers were whining about how difficult it was to program for the Mac. Things had simply become too complex. Once the hardware became powerful enough, Apple switched to a robust, multi-tasking, protected memory system (OS X). Sure, it was a massive CPU-drain, but the new processors could take it, and now the user had stability and customized multi-tasking.

I am not familiar enough with MacOS to say for sure, but I would suspect that development difficulties on it had little to do with "threaded task-switching." For example, the Amiga allowed multiple applications to run at the same time, with a full pre-emptive scheduler, but had no memory protection (processes) at all. Yet programming for it was really wonderful, especially compared to other personal computers at the time. And it was doing this on an 8MHz 68k CPU.

My impression is that MacOS was suffering from the same issues as Garnet (and Windows 9x) -- the entire architecture was originally designed as essentially a single-threaded system, with no memory protection. Trying to turn such a thing into a modern system with full processes and threads is really difficult, and in fact not the way to make that transition: MacOS X, Windows NT, and Cobalt all took the approach of designing a new modern system architecture underneath, and providing a new implementation of their existing APIs on top of it.

Generally multithreading doesn't introduce much overhead -- as I said, PalmOS has always been built on top of a multithreaded kernel. The big hit comes with memory protection, which is one of the basic reasons why Cobalt is significantly more heavy-weight than Garnet.

Originally Posted by BobR

You know, I think this thread and others like it point out a
great opportunity for PalmSource to put out some simple whitepapers to clarify a few topics.

That is a really good idea. I'll try to talk with Michael Mace about it.

Originally Posted by BobR

With regard to multitasking in Cobalt, remember that So I think that with the exception of those shared threads not protecting as completely against inter-program interference, you can do pretty much the same basic things with Cobalt as Win Mobile multitasking. We may see it looking a lot better after some more UI changes which are coming after some of the core underlying and invisible work is done.

Yep, they are functionally pretty similar. The most obvious thing missing from Cobalt is that we don't provide a standard user interface to manage multiple running applications. However, in a recent newsletter I wrote an article that described some APIs a developer could use to write their own application to do this. (Note that this isn't because we don't think this is an important issue, it is because we think it is important enough that we really want to do it right, and not just reproduce the desktop experience.)

(Btw, we don't have a per-process limit on the amount of RAM you can use. There is a limit on the total RAM all running applications can use, which can be arbitrarily configured for the device depending on how much RAM it has.)

Originally Posted by BobR

But don't forget that there are ways to do all that in Cobalt. Hopefully I don't have this all wrong. But the basic assumption seems to be one app on the screen being used at one time, which is pretty reasonable. (So you may not see those split screen apps for a long time, unfortunately.) But with such small handheld screens, especially in phones, you may not really want that too much. I think you can still have popup screens running in parallel with, say, a small overlay or popup or maybe cutout screen for something like the mp3 player while you are doing word processing.

That is pretty much correct. There is one self-contained process running at a time as the "main application", and switching between main applications involves stopping the current one and starting a new one. However, the main application in no way owns the screen -- another application running at the same time as a "non-main" application (in the background process) can display a window whenever it wants, and the system will correctly multiplex it with other things on the screen. The window doesn't need to be full-screen; it can be a small dialog that floats on top of the main application's UI.

In fact, we support very sophisticated window compositing in Cobalt, so these secondary applications can do things like display a semi-translucent window that floats on top of other application windows, and allows pen events to go through to whatever is underneath. You can also create windows that have varying alpha levels -- for example, the on-screen graffiti window has a slightly translucent gray background to show you where it is, while the frames (showing the different graffiti areas) and ink in it are nearly or completely opaque. You can basically do whatever you want.

During our recent developer's conference, the LifeBalance people used this feature to write a background application that created a full-screen transparent window, in which they animated falling snowflakes. The effect was that you could be doing anything else on the device, while those snowflakes were falling down your screen on top of everything else. They had this running on one of the Cobalt devices that were floating around the conference.

Originally Posted by BobR

Or you can have various kinds of control bars to manage background processing for things like downloads. You could even have split screens for game interaction. But, yes, the applications are probably more responsible for managing how that works. That's another thing that will probably have to be improved in the OS.... support for developers to do that sort of thing more easily and gracefully.

To be honest, right now we are not spending much time on adding ways to split the screen between multiple applications. Our big challenge is actually how to deal with smaller screens -- for example, a 2.2" diagonal screen is quite common. That kind of display is pretty darn small for just a single traditional PalmOS application, let alone trying to cram more than one on it.

[macrotor]

It appears my lingo may be inaccurate on how the POS divides up the processes in the background. From the sounds of it, the OS chooses what tasks can be combined and which need to run on a separate thread, hence optimizing the overhead. I confess that I'm more of a desktop programmer than a PDA developer, for it seems my analogy of POS to the old MacOS9 is not exactly correct either. My point was that the current architecture of POS5 seems similar to the old Mac days in that a poorly-programmed application can monopolize all processing and RAM, and then crash the entire device if it glitched. The device is at the mercy of proper programming. Also, any multi-tasking is limited to what the programmer implements.

However, I just looked at my Tungsten|C and remembered those 26 Desk Accessories I have installed under the Zlauncher QuickLaunch feature. For the most part, I can do enough multi-tasking for now.

Once again, thanks for stopping by!

- Jim

[Dianne Hackborn]

Originally Posted by macrotor

It appears my lingo may be inaccurate on how the POS divides up the processes in the background. From the sounds of it, the OS chooses what tasks can be combined and which need to run on a separate thread, hence optimizing the overhead.

I wish! The current Cobalt is not nearly that good. That is, however, the kind of thing we are moving towards... though the main intent is to divide and combine processes dynamically. What is inside of Cobalt today includes a lot of the technology that will enable this, we just aren't to the point of making full use of it.

Originally Posted by macrotor

My point was that the current architecture of POS5 seems similar to the old Mac days in that a poorly-programmed application can monopolize all processing and RAM, and then crash the entire device if it glitched. The device is at the mercy of proper programming. Also, any multi-tasking is limited to what the programmer implements.

Oh yeah, absolutely. For the most part, that is no longer an issue in Cobalt. Because of the underlying support for protected memory and multithreading, if an application crashes we can catch it and recover as on a PC, and likewise if the application has become unresponsive we put up a dialog saying so and giving the user a chance to kill it.

Originally Posted by macrotor

Once again, thanks for stopping by!

You're very welcome, I hope it is useful!

[Voice_of_Reason]

Please note that the text of this post has been deleted because it was simply badgering, and that does not live up to the standards of this community. We welcome dissenting views from TVoR here, as well as from all other sources, but, as stated before, we insist on a respectful approach to sharing opinions, and this post was clearly not helpful to the discussion, andin fact makes a true discussion of the topics impossible.

Please feel free to PM me with any concerns, but we insist on making it possible for all of us to actually talk about the issues. Everyone is entitled to their opinions here, but politely and respectfully without badgering or personal attacks.

[Voice_of_Reason]

This post has been removed because of personal attacks. It's a shame because there were some interesting questions or points contained also. But we insist on respectful and polite postings, not bullying. We want to have actual adult discussions, not a 3rd grade online verbal brawl. [BobR]

TVoR, I think you understand our rules. Please follow them.

[derekweb]

Quoting:

You're very welcome, I hope it is useful!
__________________
Dianne Hackborn
Manager, Application Frameworks, PalmSource Inc.
-----------------------------------------------

Even if it's not very useful for the, how do I be describe myself?, the dummies of the handheld community, it's awesome that you're willing to stop by and clarify points and discuss things. It's greatly appreciated. Thank you.

[Dick Tracy]

Originally Posted by derekweb

Quoting:

You're very welcome, I hope it is useful!
__________________
Dianne Hackborn
Manager, Application Frameworks, PalmSource Inc.
-----------------------------------------------

Even if it's not very useful for the, how do I be describe myself?, the dummies of the handheld community, it's awesome that you're willing to stop by and clarify points and discuss things. It's greatly appreciated. Thank you.

I would also like to extend my appreciation to Diane for your willingness to participate and help us understand more about this topic. I'm a long-time Palm user and am now excited about future developments and can be patient. I'd also like to extend my appreciation to the moderator(s) for their assistance in maintaining a civilized discussion. Thank you all.