Page 1 of 1

PostPosted: Tue Jan 23, 2001 5:02 am
by obeckers
Hey !

Is it possible to compile or pack all used libraries, incl. the pocketc runtime, in one prc-file for easier distibuting.

I use the PDE to develop.

PostPosted: Tue Jan 23, 2001 1:27 pm
by Vilmos
I'm not sure that is possible in the first place. You can pack a lot in the prc file but moving the runtime would cause problems I think. If you did manage to do it you run into problems when your user already bought the full development environment as your runtime would replace it.

Installing on the Palm is pretty easy anyway. Out of thousands of users I have had about 20 respond with problems installing the program and the vast majority the problem was that they didn't read any of the dosumentation to find out that they needed to use a newer version of PocketC.


PostPosted: Wed Jan 24, 2001 3:02 am
by stephane
Check out this URL:

It is for a utility called <b>par</b>, a .prc management tool, which among other things lets you merge program and library files.

I agree that it makes it easier if the libraries are merged with the program, but like Vilmos said though, merging the runtime is asking for trouble. Otoh, common libraries like mathlib would also cause problems.. [:\]


PostPosted: Wed Jan 24, 2001 3:31 am
by jstadolnik
As far as I know it is not possible to wedge an applet into the pocketC runtime. The main reason being is because both the runtime and the applet require thier own 'code0' and 'code1' resources.

Also, there can be at most one 'libr' resource in a .prc file, which means that at most one native library can be put into an applet .prc. You can actually put more than one 'libr' resource into a .prc, however the palm OS PLI can only access 'libr0'.


PostPosted: Wed Jan 24, 2001 4:15 am
by stephane
Thanks for the clarification, I hadn't used <b>par</b> yet... and I probably won't, now <img src=icon_smile.gif border=0 align=middle>

I guess the other approach to facilitate distribution would be a "one shot" deal, where the user would run one program to install, and not necessarily have to install PCrt, my prc, and 4 libs, etc.

At one point, I recall seeing an installation tool that seemed to do just that.
Was this my imagination, or can someone point us in the right direction?



PostPosted: Fri Jan 26, 2001 7:42 am
by obeckers
Hey again !

Thanks for reply, but ...
i develop a pocketc app on my windows. On my windows i compile it with my desktop edition. pocketc (the runtime or full version) will be edited and compiled on a system like linux or windows or something else. So, if I take the source code from pocketc an compile it, i get an prc-file. Now (this is my question!) could we compile our app on soucecode-base an include our libraries like pocketc-runtime or toolbox and the sourcecode of our programms ??

Best regards


PostPosted: Fri Jan 26, 2001 2:43 pm
by jstadolnik
PocketC is not true compiler. It generates "virtual code" which will not directly run on a palm device. Besides being a "compiler" per se, PocketC also serves as a "virtual machine", which can read the and execute this virtual code. The PocketC runtime is the "virtual machine" side of pocketC.

Being a virtual compiler/machine, pocketC is not as fast as natively compiled code (and why native shared libraries for pocketC can be so much faster). (On the positive side, pocketC handles a lot of the programming dirty work for you by providing a set of easy to use high level functions and automatic type conversion, etc.)

Since pocketC is not a native compiler it cannot compile or link non-PocketC code. Thus, applet, runtime, native library code cannot be compiled into one big "code" resource.

If someone were ambitous enough, they could write a "pocketC" palm library (not a shared native lib, but rather one which acually gets linked). This library would ideally contain all the normal pocketC funtions.

This would allow one to compile pocketC code with gcc or Codewarrior. (Though strings and type conversion would have to be handled differently). The resultant programs would be faster, smaller, and would not need a runtime. Such a library would be sweet, but it would require much effort to write.


Edited by - jstadolnik on 01/26/2001 08:46:49