>> > My application is developed in Satellite Forms v5.2, but I would like >> > to try to get the "Palm Powered" logo certification. According to the >> > certification requirements, all debug options must be turned ON during >> > emulator/simulator testing of our app. However, Satellite Forms >> > requires that all debug options be turned OFF in order to run in the >> > emulator (because of OS calls, I guess) without crashing. >> > >> > So... can a Satellite Forms-developed app be certified under this >> > program?? Has anyone done this? Do you need a special exemption?? >> > >> > >> >> I would hope that you can't get an exemption. If Satellite Forms is not >> stable enough to be run with all the debug options, then it and >> anything created with it, should not qualify for the certification. The >> certification has been designed, as far as I understand it, to say that >> the applications run reasonably well and don't suffer from crashing >> issues. >> >> I'd recommend trying to get Satellite Forms to fix their application so >> that it can pass certification or write your application from scratch >> so that you don't rely on someone's unstable application. >> >> (I've never used Satellite Forms, but I'd be very afraid of any >> application that can't run in the emulator with all debug flags turned >> on.) > >It is not that simple. > >The philosophy of RAD tools is to keep the programmer away from low level >details, such as memory allocation, or packing strings into database >records, or dealing with subtle differences between OS versions, and so on. >This is usually done through a runtime library, which behaves as a "layer" >that translates what the programmer wants into low level Palm OS calls, >and/or that provides helper functions. > >The problem is that it is almost impossible to write an efficient runtime >library for Palm OS without either calling system use only functions (such >as MemChunkNew) or either poking internal OS structures on 68k devices >(fortunately, OS 5 provides enough functions to make this unecessary on ARM >devices). Both triggers warnings when running with all options on. > >Another problem is that the emulator/simulator tends to be very suspicious. >For example, a RAD tool may provide some sort of exception mechanism. To >implement this, you have to write assembler code that crawls the stack up >until it finds a handler for the exception. Unfortunately, reading and >writing values from a stack frame which is not the "officially active" stack >frame sometimes triggers an "illegal memory access" if all options are >turned on. > >And there are many other examples. > >IMHO, the palm powered logo should take the development tool into account, >or it will dramatically restrict the number of applications that can pass >this certification... As far as I know, *all* RAD tools raise errors on >POSE, and I don't think such tools are that bad... > >Pascal
I can't agree. Originally, NS Basic had the same problem. We worked at it a bit and cleaned it up. In most cases it was simply sloppy programming. An NS Basic program should now be able to pass certification. A side benefit is that we can now use these messages as a debugging tool during our own development. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
