LES
DOSSIERS DU GAULOIS
|
|
(26/02/2k) Les formats des bases de données par Pierre Brothier:
NOTE LIMINAIRE
Ce qui suit est un travail de compilation, il n'a été relu par personne et ce que j'ai pu écrire n'engage que ceux qui y croient. Toutefois, si certains s'en sentent le courage, il faudrait faire progresser cette première approche et enrichir (et surtout corriger) cette mini base de données. J'ai rassemblé des renseignements, ici et là, pour en tirer une synthèse. J'espère qu'elle pourra vous être utile et que certains plus doués que moi - et surtout plus au courant, car je ne fais pas de programmation pour le Pilot- permettront de la mettre à jour et de la réviser.
Ne venez pas me chercher pour trouver des renseignements plus avant ou si vous avez rendu vos fichiers illisibles...
Si vous avez des éléments nouveaux ou des corrections à apporter, vous pouvez me contacter à pbrothier@lemel.fr . Notre cher Webmaster se fera certainement un plaisir de publier les mises à jour à venir.
Il est bien évident que les noms, marques, logos et autres signes extérieurs de richesses et d'intelligence, sont les propriétés de leurs éventuels possesseurs.
LES PREMISSES
Il y a quelques temps, j'ai griffonné dans les colonnes de ce site, un essai de HandBase. Estimant les fonctionnalités de ce programmes supérieures à celles de Jfile, dont j'étais un fervent supporter, j'en ai acquis la licence et j'ai converti toutes mes données de Jfile en HandBase.
En Homme soucieux de préserver mes arrières, j'avais réalisé des sauvegardes. Lorsque j'ai comparé les longueurs des tables (les fichiers PDB), je me suis aperçu que celles de HandBase étaient 2 à 3 fois plus importantes que celles de JFile. Ceci m'a amené à me pencher sur les formats de ces tables, et par la même, sur les formats des fichiers de données du Pilot.
Ces quelques mots ne s'adresse pas au programmeur à qui je n'apprendrai rien, mais plutôt à l'honnête homme, non angliciste, qui désire peut-être, récupérer en Pascal - ou en un autre langage presque aussi évolué, comme le C (++?), le Logo ou le Cobol, des données de ce qui traîne dans sa machine de bureau. L'autre but est de donner une information "d'homme du monde " à ceux qui s'en sentent le courage. Les applicatifs éventuels viendront peut-être par la suite si j'arrive à me mettre au C (j'en suis resté à TP7/DELPHI et - un peu - à VB... mais ce n'est plus à la mode) ou si certains s'en sentent, quoiqu'il en existe déjà sur le Ouaibe.
Après avoir présenté mon approche, je parlerai de généralités sur les processeurs et le Web, je rebondirai sur le coeur du sujet, c'est-à-dire les formats d'en tête , puis ce qu'on appelle la liste des enregistrements des fichiers " *.pdb " et " *.prc " dont le format est si proche et dont l'assemblage est particulier. Une prochaine fois, je surferai sur mes toutes nouvelles connaissances pour comparer les tables de Jfile et HandBase et j'en profiterai enfin par une rituelle conclusion qui me permettra de me présenter. Enfin, je donnerai dans une annexe, les adresses Internet de quelques programmes bien utiles et de sites essentiels pour qui veut approfondir ce sujet .
Comme j'ai une grande flemme, et que je ne passe plus ma vie sur le Web ou devant ma machine, la totalité de l'article n'est pas là... Le reste devrait suivre dans un avenir plus ou moins lointain. Cela concerne le format des fichiers JFile et HandBase, dans lequel je commence à voir clair, et les adresses utiles que je n'ai pas encore mis en forme.
DE L'IMPORTANCE DES MACHINES ET DE LA MENTALITE
Hors donc, au début, il y eut un essai de 'dump' brutal de mes fichiers de données - exactement semblables - pour deux programmes différents, afin de les comparer. Je reconnu bien mes données 'texte' et même 'numérique' dans les listings, mais contrairement à une table Dbase, il y avait beaucoup d'autres choses incompréhensibles, que ce soit dans les données au format Jfile ou celles au format HandBase..
Je me mis donc à fureter sur le Web pour trouver une réponse à mes questions. Je m'aperçu vite qu'il n'y avait pas de ressources en français - et c'est la cause de cette dissertation - et qu'il y en avait peu en anglais.
J'en ai tiré plusieurs enseignements :
Les structures des fichiers .pdb et .prc sont globalement équivalentes. Elles renferment du code, des données et des ressources qui permettent :
aux programmes de retrouver leurs données et au Pilot de retrouver ses programmes (il n'y a ni répertoires, ni suffixes différents dans la mémoire du Pilot, des bases ou des programmes différents peuvent avoir un même nom, la même base peut être utilisée par différents programmes et avoir été développées sur des machines avec des OS différents... etc. Il faut donc que la machine puisse s'y retrouver),
de synchroniser les données entre le Desktop et le Pilot en fonction de la date de modification ou de divers indicateurs contenus dans l'entête du programme ou de la base, et sur lesquels nous reviendrons,
au aux porogrammes, et donc au Pilot, d'accéder aux données (ressources, enregistrements ...etc.).
Palm Computing( ou 3 Com) semble rechigner à donner des renseignements, et la lecture du SDK (Software Development Kit) laisse sur sa faim : il n'y a pas grand chose sur les structures. Pour Palm, il semble qu'il suffit de faire appel aux fonctions pré-programmées pour créer ou récupérer lesdites structures sans avoir à s'inquiéter du pourquoi ou du comment... D'un certain coté, c'est tout à fait normal, ils ne veulent pas être vérouillés par un format qui pourrait évoluer dans l'avenir, sur de futures machines. J'ai donc déchargé les 9 Mo dudit SDK pour pas grand chose (hormis le fichier DataMgr.h). A la lecture de nombreuses pages traitant du sujet, on remarque combien les programmeurs se posent de questions sur certains bits, bytes et voire même, blocs de données.
Si vous possédez un PC ... c'est pas de chance ! Le processeur du Pilot est de la famille des 68000 (MOTOROLA), et ça pose des problèmes, entre autre, pour les dates, qui sont comptées en interne en secondes depuis le 01/01/1904 (comme sur le MAC), et la représentation des données numériques, dont par exemple le MSB (Most Significant Byte), d'un entier soit 2 bytes, vient en premier, et non pas en dernier comme sur un X86.
les Anglo-Saxons partagent plus facilement leurs connaissances que nous (à moins que nous ne soyons bien moins forts qu'eux).
DE LA STRUCTURE DES * .PDB (ET *.PRC)
Comme je l'ai dit supra, un fichier PDB ( ou PRC ) présente une structure constante, quel que soit le programme qui l'a généré. Je limiterai mes propos dans ce chapitre à une brève description des différentes parties de ces fichiers, mon but étant, je le répète, de donner une information sur leur format de manière à pouvoir récupérer des données sur un desktop à partir des fichiers créés par un Pilot, et non pas d'en générer un.
Un fichier PDB ( ou un PRC) comprend donc 3 parties
L'en-tête (header), qui renferme toutes les données générales du programme, le bit de backup, de modification, les heures de créations ou de modification, numéro de version ou identifiant de création ... etc.
La liste des enregistrements, qui énumère les 'enregistrements', ce n'est pas forcement le terme le plus approprié, de la base ainsi que leurs attributs.
La zone des données qui en plus des données ou ressources (les enregistrements pour ce qui est des bases de données), contient deux zones : le zone des informations de tri et la zone d'informations de l'application qui sont des éléments optionnels.
Le problème majeur vient du fait que le vulgus programmeur, qui n'a pas de copain chez Palm Computig (certains programmeurs indépendants sont soupçonnés de ... ! ! !), n'a pas accès à une doc complète et officielle. Tous ces braves gens ont donc décrypté, désossé et dépouillé quelques bases et programmes, pour savoir de quoi il en retourne. Comme les différents compilateurs compilent comme ils peuvent (ou savent), comme le format n'est pas verrouillé à 100%, et que les différents programmes sauvegardent ce qui leur plaît, on trouve des résultats différents pour de nombreuses bases ou programmes similaires.
Les conventions pour les tableaux qui suivent :
Entre parenthèses, les nom anglais les plus communément employés, et pas forcemment ceux utilisés dans le SDK.
Les longueurs sont données en octets (byte en anglais) avec les commentaires et types appropriés qui sont ceux du Pascal.
Pour les novices,
voici quelques renseignements : les masques de bits dans les bytes (un byte
vaut 8 bits ou 2 nibbles (quartets en français)) sont donnés
en valeur hexadécimal " Pascal " c-a-d $02, ce qui donne 0x02 en "
C ", pour une opération logique de type AND, OR ou XOR
| Numéro du bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| Valeur Hexa | $80 | $40 | $20 | $10 | $8 | $4 | $2 | $1 | |
| Valeur Décimale | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 | |
Je m'explique
: mettons qu'un byte vaille 147 décimal, soit en binaire :
| 1 | 0 | 0 | 1 | 0 | 0 | 1 | 1 |
Si je veux vérifier que le bit numéro 3 vaut 1, je fais : B AND $8, ce qui me donne FALSE.
Si je veux vérifier que le bit numéro 4 vaut 1, je fais : B AND $10, ce qui me donne TRUE.
Les commentaires sont donnés pour des valeurs par défaut des bits à 1. Ceux en italique renvoient aux fichiers *.PRC si besoin est.
Les bytes sont lus dans l'ordre dans lequel ils apparaissent sur le listing du dump ou dans la mémoire (le sens du 68000), toutefois, les bits dans les bytes sont lus de droite à gauche.
Remarque
: Il y a 15/20 ans, à l'époque des TRS 80, des Apple 2, des
ZX80 et autres CBM-PET, les 2 ou 3 mensuels informatiques faisaient les 2/3
de leur papier en dégueulant du source que nous passions des nuits
à recopier et à essayer de comprendre. C'était formateur
!
L'en-tête
Le HEADER contient
donc les données générales concernant le fichier :
| CHAMP | LONG | TYPE | OBSERVATIONS |
|---|---|---|---|
| Nom | 32 | Chaîne " C " de 31 caractères terminant par 0 (null terminated string) | Cette valeur est indépendante du nom
de fichier apparaissant sur le Desktop . Il s'agit du nom affiché
par le Pilot (pour les programmes PRC) ou les applications (pour les PDB)
dans les programmes.
Le 0 terminal ne semble pas obligatoire, les programmes compilés par PILA met 'PILA' dans les 4 derniers bytes ... |
| Attributs du fichier | 2 | WORD |
Le Word vaut $0001 pour un exécutable |
| Numéro de version | 2 | WORD | Créé et vérifié
par l'application mère. Pour certains, on a cela :
Le premier quartet (celui de gauche en 68000) lu correspond au numéro de version majeur, le second quartet, au numéro de version mineur. Le premier quartet de byte suivant correspond au stade de développement :
enfin le dernier quartet, au numéro de 'bugfix' pour les versions alpha et bêta. Voici quelques exemples pour faire clair :
Le word vaut $0001 pour une application. |
| Date de création | 4 | INTEGER | Comme précisé plus haut, elle est comptée comme sur le MAC en secondes depuis le 01/01/1904. Ce qui veut dire que le Pilot peut emmagasiner 2^32 secondes (4 fois 8 bit)... Donc, dans le courant du premier trimestre 2040, votre machine va se remettre à 0 et connaître le bug de l'an 2000 ! Il semblerait que la hotsync soit impossible si ce champ est à 0 |
| Date de la dernière modification | 4 | INTEGER | Voir supra pour le champ à 0 |
| Date de la dernière sauvegarde | 4 | INTEGER | Semble pouvoir être mis à 0 |
| Numéro de modification | 4 | INTEGER | Ce champ est modifié chaque fois qu'un enregistrement
est modifié, ajouté ou détruit. Cela permet aux bases
partagées de faire connaître leur état à tout
programme appelant.
Toujours à 0 |
| Adresse de la zone des informations de l'application (AppInfoArea) | 4 | INTEGER | Nombre de bytes, comptés depuis 0, à laquelle
est situé cette zone à partir du début du fichier. Toutes
les application n'en comporte pas. Si c'est le cas, ce champ est à
0. (voir plus bas pour les commentaires)
Toujours à 0 |
| Adresse de la zone des informations de tri
(SortInfoArea) |
4 | INTEGER | Nombre de bytes, comptés depuis 0, à laquelle
est situé cette zone à partir du début du fichier. L'adresse
doit pointer immédiatement après la 'AppInfoArea' si elle existe.
Comme si dessus, le champ est à 0 si cette zone n'existe pas.
Toujours à 0 |
| Type de la base de données
(Database Type) |
4 | Chaîne de caractères | C'est grâce à ce champ que le Pilot rattache
une base de données à une application (et que par là
même, il la détruit lorsque l'on efface cette application).
Cet identificateur est indépendant du nom qui apparaît sur le
Pilot et aussi du nom du programme appelant. Voir commentaires ci-dessous.
Souvent ce champ est le même que le suivant.
Toujours 'Appl' pour un PRC |
| Identificateur unique de programme
(Creator ID) |
4 | Chaîne de caractères | C'est grâce à ce champ que le Pilot retrouve
les applications en mémoire. Ce nom est indépendant de celui
qui apparaît sur le Pilot ou de celui sous lequel a été
développé l'application. PALM COMPUTING maintient à
jour une liste des identificateur ; il est de la responsabilité des
programmeurs de s'y inscrire. Cela se fait à
http://www.palm.com/devzone/crid/cridsub.html
Dans le cas d'un PRC, si par malheur vous donnez à ce champ la même valeur que celle d'une application existante, cette dernière sera effacée à la HotSync suivante. |
| Générateur d'identification des
enregistrements
(UniqueID Seed) |
4 | INTEGER | ? ? ? comme certains autres champs, les " pros " du Pilot
ne semblent pas trop savoir à quoi cela peut servir (certains disent
même que c'est du 'garbage' : des trucs à mettre à la
poubelle !). Il semble utilisé pour générer l'identificateur
unique de chaque enregistrement de la base. En tout état de cause,
il semble pouvoir rester à 0 (ou pointer vers une extension de
l'en-tête pour d'autres !)
Toujours à 0 |
| Identificateur de la liste d'enregistrements suivante
(NextRecordListID) |
4 | INTEGER | Même remarque que ci-dessus, à laisser à
0. Semble n'être utilisé que par le Pilot lors des process
internes.
Toujours à 0 |
| Nombre d'enregistrements
(NumRecords) |
2 | WORD | Sans commentaires ! |
Voilà, c'en est fini pour l'entête des PDB et peut-être des PRC. Si je compte bien, cela nous fait donc 78 bytes inamovibles.
Je reviendrais plus loin sur AppInfoArea et SortInfoArea.
Les commentaires
du tableau sont un peu la synthèse des éléments que
j'ai pu réunir ici et là. Ils ne sont ni les plus complets
ni forcement les plus pertinents : j'ai énuméré ce qui
me semblait important, de ce que j'ai récupéré et surtout
compris ! D'aucun ne font pas de différence majeure entre les PDB
et les PRC, considérant les deux comme des ressources pour le Pilot,
ce qui en fin de compte est vrai . Cela occasionne de petits problèmes
d'interprétation comme nous allons le voir plus loin !
La liste des enregistrements
En fait, il
s'agit des ressources pour un programmes ou des données pour un fichier
PDB. Cette structure se compose de N enregistrements tels que décrits
ci dessous.
Les fichiers PDB
Si le bit $01
du champ 'attributs du fichier' du HEADER est 'off', c'est à dire
à 0, c'est un fichier PDB :
| CHAMP | LONG | TYPE | OBSERVATIONS |
|---|---|---|---|
| Adresse de l'enregistrement
(Record Data Offset) |
4 | INTEGER | Comme les adresses ci-dessus, comptée depuis 0 à partir du début du fichier. Comme tout est compté à partir de 0, on ne peut pas parler de décalage (offset en anglais).Dans le cas d'une base lue sur le Desktop, l'offset vaut donc l'adresse... |
| Attributs de l'enregistrement | 1 | BYTE |
|
| Identificateur unique | 3 | Numérique (faute de mieux ...) | ...Ce champ semble changer à chaque HotSync... Voir le remarque du même genre dans la rubrique 'en-tête' |
On a donc une longueur de 8 bytes.
Remarque en
passant : lorsque vous détruisez un enregistrement sur le Pilot, il
n'est réèllement éffacé de la mémoire
que lors de la Hotsync suivante, (ce qui permet à certains programmes
de réaliser une copie de sauvegarde de ces enregistrements).
Les fichiers PRC
Si le bit bas
du champ 'attributs du fichier' du HEADER est 'on', c'est à dire à
1, on a un fichier PRC :
| CHAMP | LONG | TYPE | OBSERVATIONS |
|---|---|---|---|
| Type | 4 | INTEGER | En fait, le nom de la ressource |
| Identité de la ressource
(Id Number of the resource) |
2 | WORD | |
| Adresse des ressources (Offset) | 4 | INTEGER | Cf. la remarque dans le tableau ci-dessus |
On a donc une longueur de 10 bytes.
La zone des données
Je ne ferai pas de tableau, car là..... vous mettez ce que vous voulez et vous récupérez ce que vous pouvez !
Elle obéit, elle aussi à des structures précises dans sa première partie car elle renferme en effet les deux blocs que j'ai cité plus haut, la 'AppInfoArea' et la 'SortInfoArea' comme on le voit plus bas.
L'assemblage des données
Là aussi,
le Pilot réserve des surprises... Il faut, bien sûr, mettre
toutes les informations décrites ci-dessus dans le bon ordre et rajouter
une pincée de poudre de perlimpimpim.
| ZONE | LONG (en octets) | OBSERVATIONS |
|---|---|---|
| EN-TETE | 78 | |
| LISTE DES ENREGISTREMENTS | doit contenir au moins un enregistrement | |
| TAMPON
(Filler en anglais, mais j'ai pas trouvé mieux !) |
2 | 2 octets à 0. Ils ne sont pas nécessaires lors de le création de la base sur le desktop, mais le Pilot les rajoute à la Hotsync suivante si le bit de saugarde est placé ! |
| ZONE DES DONNEES | On y trouve dans l'ordre :
|
La zone des données commence donc à 78+2+N*(10) pour les PRC ou 78+2+N*8 pour les PDB.
C'en est fini de cette description. La prochaine fois, je parlerai plus en détail des formats propres des fichiers de données de JFile et HandBase. Cela permettra d'expliquer leur grande différence de taille pour un même ensemble de données.
EGO ME ABSOLVO
Marié avec des enfants, je bidouille de temps en temps au gré des humeurs de ma femme et de l'état d'excitation des dits enfants. Je suis militaire, et au hasard de mes affectations, et j'ai développé quelques applicatifs sous TP, DELPHI, et même sous VB sur une base Oracle. Maintenant, ma machine me sert essentiellement pour jouer, ce qui me contraint à changer de carte mère et de processeur tous les 3 ans !
J'ai acheté ma pemière machine (un TRS 80 avec 16 k de mémoire et un magnifique lecteur de cassettes en 1980/81), et depuis, je n'ai pas quitté - ou essayé de quitter - l'esprit que j'avais à l'époque ou l'on achetait pas encore des package 'machine+applicatifs' dans les rayons des super / hyper / peta marchés !
Mon Palm, un modèle Pro upgradé avec un module de III, ne me quitte jamais. S'il mangeait moins de piles ce serait mieux !
ANNEXE : EN MATIERE DE SITES ET DE PROGRAMMES
Les références citées ci après ne concernent que des programmes ou des sites internet. Je n'en ai aucune quant à la documentation 'papier', mais je pense qu'il doit bien exister des ouvrages qui traitent du sujet (comme les manuels de compilateurs).
Lorsque l'on se ballade sur le Net, on retombe vite sur les mêmes sites. J'ai fait ma recherche avec divers moteurs et en cherchant quelques mots clefs sur les sites de developpeurs du genre : dump, database, decypher, flush, listing ...etc. Il n'y a pas une foultitude de sites... malgrés le nombre de développeurs. Dommage ! Sauf erreur de ma part, je n'en ai pas trouvé en français. La liste suivante n'est pas exhaustive, je n'ai d'ailleurs pas mis tous les sites que j'ai trouvés en liaison avec le sujet qui nous intéresse.
Malheureusement pour les 'non native english speakers' ou ceux qui n'ont pas suivi en classe, toutes ces pages sont en anglais et je ne les traduirais pas !
Les références sur les formats
Nom et site Observations Wade's Pilot Programming FAQ Ce n'est pas à proprement parler une page sur les formats des fichiers. Elle renvoie toutefois à un tas de pages très intéressantes pour qui veut se lancer dans la programmation sous différents SDK, programmes en fonction de sa plate-forme; ou tout simplement pour qui veut en connaitre plus sur le(s) soft(s) du Pilot en général.
Nico´s Homepage Page très riche sur les formats des applications internes du Pilot dont je n'ai pas parlé plus haut. Pour qui cherche les formats des données de l'agenda, du mémo, du carnet d'adresse ... etc., ne cherchez pas plus loin, vous venez de trouver La Bible des fichiers *.dat. Je vous rappelle que ces fichiers sont sauvegardés par des processus particuliers dans des répertoires spécifiques.
The Pilot record database format Une des meilleures pages concernant le format *.pdb. Elle a été à la base de la loghorrée dont je vous ai abreuvé.
The PRC format Excellente page, trés trés (vraiment trés) technique pour le format *. PRC. Elle concerne les purs et durs de la programmation. Il faut être branché 68000 et C.
Voilà pour les pages donnant des renseignements sur les formats, il y a aussi le WinSDK de chez 3COm (voir remarques plus haut). Il pèse 9 Mo, pour presque 29 Mo décompressé... pour ceux qui sont fanas. Toutefois, on en tire des enseignements limités quant au format des fichiers .
Les programmes analysant les données sur le desktop
La liste de programmes qui suit donne un aperçu des applications qui prennent les données des fichiers PDB ou PRC sur votre desktop et les transforment, soit à l'écran soit encore sous fichier TXT en données compréhensibles (ou inversement). Pour ceux que j'ai pu tester, ils donnent des informations générales sur le Header et tout le reste. Si vous relevez l'offset du byte qui vous intéresse, vous pouvez ensuite le modifier avec un programme dans le genre de HexEdit ou tout autre éditeur Héxa. C'est bien pratique pour modifier les indicateurs des jeux (comme Mulg), lorsque l'on arrive pas à passer un tableau ou pour faire croire à vos petits copains que vous avez pulvérisé les scores à Pyramid ou à HMaki !
Je ne suis pas un pro de Java, et je n'ai fait tourner aucun programme écrit dans ce langage. Pourtant, ils sont les plus nombreux. Si certains s'en sentent, ils peuvent le faire et apporter des corrections à ce tableau.
Nom et site |
Observations |
|---|---|
| PDBCompiler | Compilateur qui permet de transformer un fichier TXT en fichier PDB. Il faut au moins java 1.0.2 pour le faire tourner. Comme je n'ai pas envie d'aller faire un tour chez SUN, je n'ai pas Java et je ne l'ai donc pas essayé. Les sources et surtout leurs commentaires sont intéressants. (j'ai JView, mais j'ai la flemme:-)). Bien sûr, il y a une syntaxe à respecter pour que le compilateur y retrouve ses petits. |
| PilotView | Un mamouth. Difficile à trouver car il a été remplacé par PDViewer qui est décrit au § suivant. Il n'est plus supporté, mais il existe encore sur quelques serveurs (à priori les auteurs on demandé à ce qu'il soit enlevé, mais ce n'a pas été toujours suivi, les liens renvoient souvent vers leur home page). Je ne l'ai pas essayé car j'utilise PDViewerPro des mêmes auteurs qui est bien plus puissant. Il existe par exemple sur PalmCentral, mais plus sur PilotGear. |
| Ptools | Cette fois-ci, c'est un décompilateur. Au vu des sources, il semble très performant, mais il tourne aussi sous Java et je ne l'ai pas essayé. Les sources sont très "propres" et même si elles ne sont pas commentées, elles renferment des renseignements précieux. Il permet selon l'auteur de visualiser les ressources des fichiers PRC et même d'afficher les images. |
| Pilot-File | AAAHHHHHH ! voilà un programme intéressant. C'est un EXE qui fonctionne en ligne de commande, mais il ne faut pas 377 arguments comme dans JAVA pour le lancer. Il "dump" les fichier PDB ou PRC avec pleins d'options dans un fichier TXT (Header seul, tous les enregistrement ou certains, la HeapInfo ou la SortInfoArea ... etc.). Les sources sont livrées avec et renferment plein de bonnes choses. Accessible à tous. |
Les programmes analysant les données sur le Pilot
C'est marrant, lorsque vous utilisez un programme ( comme ceux qui suivent) qui fait directement appel aux données sans passer par les 'built-in functions' du SDK, le Copilot officiel de 3COM couine en vous assurant que vous allez avoir des problèmes, que les logiciels vont évoluer et que la modification des bases aura pour effet de planter votre Pilot et qu'enfin il vous faut préparer votre boite de trombonnes pour les reset à venir... On se saurait être plus clair. 3com se garde bien de légaliser le bidouillage en direct... J'aimerai bien savoir si les compilateurs (libres ou commerciaux) utilisent tous les fontion pré-programmées du SDK !
Nom et site
Observations
C'est le grand frère de PilotView. J'utilise personnellement la version Pro (enregistré). La version free ne permet pas les transfert du Pilot vers le Desktop et vice-versa. J'ai hésité à mettre là ce programme, car il réside sur le desktop, mais lit les données sur le Pilot lors de la HotSync (comme BackUpBuddy). Il permet d'éditer en mode hexa ou en mode texte toutes les ressources du Pilot (PDB ou PRC), donne les renseignements sur le header et les autres zones, permet de modifier les indicateurs généraux (dates, indicateurs de sauvegarde, CreatorID... etc) et même les champs des enregistrements ou des ressources que vous désirez.. Il permet la sauvegarde d'un fichier particulier ou son envoi vers le Pilot. Seul problème, la consommation de piles durant la manip de la HotSync. La version free et la version pro sont accessibles sur le site de Sonoma Software qui ne supporte plus PilotView (et ne le distribue plus). J'ai eu un petit problème lors de l'utilisation, ils m'ont répondu en 12h00 avec la solution. La version Pro coute $15.00, ce qui est donné.
C'est un peu minimaliste, mais vous pouvez récupérer les sources qui sont commentées. Il ne permet que la consultation, mais vous permet de visualiser le header et les enregistrements.
Semble faire à peu près tout ce que fait PDWiever, mais directement sur le Pilot. Je n'ai essayé que la version démo qui est bridée : on ne peut pas accéder aux enregistrements. Le programme semble toutefois très complet. Il permet en plus l'edition et la modification de nombreuses données concernant le Pilot en général qui sont normalement accessibles par le programme 'Préférences' et même plus (reboot à froid ou chaud ... etc.). Il coute $15.00.
Comme au dessus, mais ne permet d'accéder qu'aux données du header et de les modifier.
Un truc qui marche bien (bases *.pdb sur le PC), semble être PdBingo, à récupérer chez http://xprsg.cjb.net/ Ce programe permet de modifier les bases sur le PC (à l'inverse de PdWiever) mais au moins il est gratuit.
Voilà,
j'ai fait le tour de ce qui me semblait utile. Je n'ai pas mentionné
les dessassembleurs, mais il y en a qui fonctionnent directement sous PalmOS.
Ajout (Pascal)
Le format des fichiers
Palm (agenda, adresse, memo, todo) : http://www.geocities.com/Heartland/Acres/3216/palmrecs.htm
La conversion des bases du Palm en HTML : http://home.vr-web.de/jSwi/
|
|
|||
|
|
|||
