"You can tell whether a man is clever by his answers.  You can tell whether a man is wise by his questions."

- Naguib Mahfouz

General Questions

1. Is Waba an implementation of Java?
2. Is Waba free?
3. How stable is the Waba Virtual Machine?
4. Who came up with the idea for Waba?
5. Is there a Waba newsgroup somewhere?

1. Can I access PalmPilot databases from Waba?

   Yes. You can use the Catalog class to access PalmPilot databases from a Waba program.

2. Do Waba programs use the storage heap for memory?

   Yes, starting with the Beta 7, the class heap of Waba programs is kept in storage memory. The object heap, native stack and VM stack of a Waba program are kept in dynamic memory.

3. If I use sockets and try to open one when my program starts, it fails under the PalmPilot. What's going on?

   PalmOS doesn't allow you to open a socket until the "main loop" of your application has started. If you open a socket before events start getting processed, PalmOS may reset the device. The WabaVM prevents a Waba program from opening a socket at the wrong time and won't let a program open a socket until it is safe to do so.

   Waba programs are constructed before the PalmOS event loop starts. That is, a MainWindow constructor will be called before the "main loop" starts. So, opening a socket in a MainWindow constructor will fail under PalmOS.

   Under PalmOS, you can open a socket once event processing starts. For example, after a pen event occurs, after a key event occurs or when the screen is painted. You should only see this problem if you open a socket in your program's constructor.

4. Does Waba support grayscale drawing on the PalmPilot?

   You may have seen or used PalmPilot programs that draw in 4 color grayscale (2 bits per pixel) instead of just black and white.

   The PalmPilot doesn't actually support grayscale drawing through the PalmOS API. To get it to draw in gray you need to do quite a bit of poking around in memory.

   3Com has a very nice article on their web site about this. The WabaVM sticks to the supported features of PalmOS, doesn't write directly to screen memory and doesn't set undocumented system registers. So, it only supports 1 bit color drawing on the PalmPilot.

   Due to popular demand, however, this is subject to change.

5. I can't switch applications when I run a Waba application or the application doesn't seem to close normally. What's going on?

   This occurred under the Waba Beta 4 release when Waba programs were run under the Palm Personal.

   The problem occurs when a PalmOS program doesn't leave enough room in the dynamic heap for the PalmOS launcher to work properly. The default amount of memory allocated to a Waba program using the WabaSDK Beta 4 and earlier was 12K.

   Under the Palm Personal, this was enough to launch the program but not enough to let the PalmOS launcher program switch programs.

   The WabaVM Beta 6 and later tries to prevent this problem by ensuring there is some dynamic memory (~2K) left for PalmOS after a Waba progam starts up.

   For reference, a Palm Personal has around 12K of dynamic heap. The dynamic heap is where a Waba program puts its object heap, native stack and VM stack. A Palm Professional has 44K when sockets aren't used and 12K when they are used (when the TCP/IP stack is active). A Palm III or IIIx device has 68K when sockets aren't used and 36K when they are used.

6. Is there a bug drawing clipped lines under PalmOS?

   Yes, PalmOS has an interesting bug that can show up when you draw clipped lines.

   If you have a clipping rectangle and you draw a line from somewhere in the clipping rectangle to an area directly below the clipping rectangle and it is not a vertical line, its right-left orientation may flip.

   For example, if this what you want:

     

   This is what you might get:

     

   This only occurs when the line is not vertical and when the line ends directly below the clipping rectangle.

7. Is there a bug drawing using the DRAW_AND operation under PalmOS?

   Yes, there is a bug in the PalmOS WinCopyRectangle() function which causes the DRAW_AND operation to produce incorrect results under some circumstances.

   The following images demonstrate the problem. This is the result the AND operation should produce when copying a source to a destination:

     

   and this is the actual result PalmOS gives when the scrAND operation is used with the PalmOS function WinCopyRectangle():

     

8. Is there a bug in DRAW_XOR mode copyRect() on PalmOS?

   PalmOS has a bug that shows up when you perform an overlapping copy on a surface in XOR mode.

   This will show up in Waba if you set the graphics drawing mode to XOR and perform a copyRect() where:

   • the source and destination surfaces are the same
   • the source and destination regions overlap
   • the destination is to the right of and lower than the source

   Here is some C code that shows the problem under PalmOS:

     RectangleType rect;
     WinHandle winHandle;
   
     winHandle = WinGetDrawWindow();
     // draw a black rectangle in the center
     rect.topLeft.x = 70;
     rect.topLeft.y = 70;
     rect.extent.x = 20;
     rect.extent.y = 20;
     WinDrawRectangle(&rect, 0);
     // XOR the rectangle a little lower and to
     // the right (overlapping)
     WinCopyRectangle(winHandle, winHandle, &rect,
       71, 71, scrXOR);
   

   If you encounter this problem (you'll see strange lines drawn on the screen), you can work around it by first copying the area into an image buffer and then copying it back to the surface using XOR.

9. When I run Gremlins against a Waba program in the emulator, it gives me a Form error. Is this a bug?

   This appears to be caused by a bug in Gremlins/PalmOS. The problem does not appear if you run Gremlins in "Entire PalmOS device" mode, it only appears if you run Gremlins against a specific Waba program.

   Waba programs on the PalmPilot are composed of a launcher (.prc file) and classes (.pdb file). The launcher program starts up the WabaVM and tells it where to find the classes and how much memory to use.

   When Gremlins runs a Waba program, it runs the launch program and the launch program runs the WabaVM. After switching to the WabaVM, the original program is no longer active.

   But Gremlins only knows about the launch program and it starts feeding events to the inactive launch program. When it feeds an event to popup the keyboard dialog (character 0x109), PalmOS appears to become confused because the program that is supposed to pop up the keyboard dialog is no longer active. This causes a Form error.

   When run under "Entire PalmOS device" mode, this doesn't happen because Gremlins doesn't feed events directly to the event queue of the inactive program.