Dmitry Grinberg vient de rendre disponible une version béta de UDMH (Unlimited Dynamic Memory Hack).

Le site web de l'auteur : http://dmitrygr.titaniumhosting.com
Et le PRC: http://dmitrygr.titaniumhosting.com/file/UDMH.prc


Ce hack (à activer avec YAHM - Yet Another Hack Manager) est censé fournir davantage de mémoire dynamique aux logiciels qui en ont besoin (en en récupérant dans la mémoire de stockage).

Apparemment risqué, mais le seul moyen d'utiliser CasSTaway, Guinea Pig, Warring Nations:Medieval Heroes etc... sur des machines genre Tungsten T (qui disposent grand maximum de 0,8 Mega seulement de mémoire dynamique).

Je n'est pas réussi personnellement à l'installer sur un Zire 71, mais apparemment ça marche sur Z72 & TT...

FAITES QUAND UN MEME UN BACKUP DE VOTRE MACHINE SI VOUS L'INSTALLEZ - ON NE SAIT JAMAIS...

Pour ceux qui essayent, ce serait sympa de nos faire part de votre expérience

quelques précisions en français
- cette beta est échue le 28 janvier
- pour désinstallez, rebootez votre palm en mode sans échec (rest + bouton "haut") et supprimez le fichier avec un gestionaire de fichier (Filez, etc...).
- un petit reset et c'est tout bon !
si vous ne comprenez pas de quoi je parle ... attendez un peu avant de tester

La version béta est-elle limité dans le temps? payante?
Si non est-ce que vous l'auriez encore? sa m'intéresserais!

Tu peux toujours le télécharger en cliquant ici et les infos (en anglais) sont toujours à cette adresse.

ui mais sa dure une semaine si j'ai bien compris sinon faut l'acheter..enfin si je le supprime et le réinstall sa va me refaire une semaine? Parce que moi il me sers juste pour mon émulateur super nes

Que ce soit possible ou pas n'est pas la question : le principe du shareware est de te donner le temps de tester le logiciel avant de l'acheter. Au-delà, l'utiliser sans l'avoir acheté est illégal.

UDMH vient de passer version 3

J'ai entendu parler à plein d'endroit de ce UDMH et j'ai enfin trouvé LE sujet qui ne traite que de ça.

Quel est le résultat final de l'emploi de cette appli ? Je veux dire, est-ce que c'est utile de l'installer sur mon T5 par exemple ? Et j'y gagne quoi exactement ?

En passant, pouquoi est-ce qu'il ne figure par dans la sélection logiciels ?

Salut,

J'ai UDMH 3.0 installé sur mon Treo 650 depuis un peu plus d'un mois, et il ne me pose aucun problème particulier.

Certains programmes qui ne fonctionnaient pas avant fonctionnent avec UDMH (en particulier les simulateurs ZdoomZ, PalmMame...etc). Les autres programmes sont en majorité plus stables et plus rapides, mais c'est très subjectif, et je n'ai pas fait d'essai comparatif réel. Enfin je préfère que TomTom m'indique qu'il a 16.5Mo de RAM pour travailler plutot que 1.5 Mo

J'ai noté une incompatibilité avec Blazer. Il suffit d'aller dans la config UDMH, de choisir Blazer et de cocher la case "Désactiver UDMH pour ce programme".

@+
stipus

je n'ai pas très bien compris le principe, mémoire dynamique c'est la RAM non?

si je dis une conn.... reprenez-moi... ... c'est un peu le principe de fonctionnement de MemoryJack ??? ou alors c'est complètement différent et cela pourrait être complémentaire

si on m'explique suffisamment clairement et si c'est compatible avec mon Zire 31, je veux bien tester!! Tout ce qui peut améliorer mon ti palm je suis preneur...

Rien à voir avec Memory Jack. UDMH n'ajoute pas de mémoire.

UDMH permet simplement de rompre le partitionnement fixe de la pile (dynamic memory) dans la mémoire.

La pile est utilisée par les programmes, dès que tu déclares une variable locale, que tu fais un appel de procédure ... etc.

Par défaut sa taille est fixe, et j'imagine que tu as droit à un soft reset, dès que le programme dépasse l'allocation maximum...

Merci aux spécialistes de la programmation Palm de me corriger si nécessaire. Je ne suis pas un mauvais programmeur en général, mais pas expérimenté sur Palm.

@@+

stipus

UDMH ne fait pas augmenter la taille de la pile, mais du tas ("dynamic heap"). La pile est fixe, et sa petite taille n'a me semble-t-il jamais été un problème pour les programmeurs.

Rapidement :

Sur les Palm anciens, jusqu'au T3, la RAM est divisée en "storage heap" dans laquelle sont stockés les programmes et les données, et auquel on accède à l'aide de fonctions orientés "Enregistrement" (lire ou écrire un enregistrement de la base) - c'est l'OS qui se charge de faire l'écriture ; et en "dynamic heap", espace de travail des programmes dans lequel le programmeur peut allouer comme bon lui semble. La distinction entre les deux permet d'éviter qu'un programme avec un bug de type "pointeur fou" ne corrompe les données t programmes - au pire, il ne fera que mettre le boxon dans la "dynamic heap" ; et toute écriture de données directement dans la "storage heap" est prohibé.

La séparation entre les deux est purement logique : toute tentative d'écrire dans la storage heap est interdite par le système ; mais il existe une fonction (MemSemaphoreReserve/MemSemaphoreRelease) pour désactiver la protection. C'est comme ça que marche l'option "Load Samples in Storage Heap" de Bhajis Loops.

UDMH désactive définitivement ce verrou, et patche toute les fonctions d'allocation mémoire pour en conséquence. Au passage, cela fait tomber le garde-fou que représente la séparation entre les deux espaces : un programme buggué peut maintenant corrompre des bases de données et programmes.

Sur les Palm modernes (T5, TE2, LifeDrive), les programmes et bases ne sont pas stockés en RAM. Ils y sont temporairement transférés (mécanisme de cache). Cela a pour effet :
- De limiter la RAM totale disponible une fois UDMH activé (parce qu'il y a effectivement moins de RAM sur ces nouvelles machines).
- De rendre un peu moins dangereux l'utilisation d'un programme foireux avec UDMH (au pire, on corromp le cache, pas les données originales).

Oulà, ça devient vachement technique l'explication... j'ai du m'y reprendre à plusieurs fois et je crois que j'ai saisi l'idée... en tout cas le fond principal mais pour le reste...

Par rapport à ta dernière remarque poolpy, sur les palm modernes, je n'arrive pas à saisir si ça apporte qqch de l'utiliser ou non?! Et sur ces mêmes machines, pour lire des vidéos avec TCPMP par exmple, on remarque une différence ? Ou au niveau de la rapidité des applications les plus courantes ?

Merci pour ces précisions, et désolé pour cette confusion entre le tas et la pile.

stipus

merci Poolpy et Stipus, je ne suis pas certain d'avoir tout compris donc je ne ferai pas mumuze avec.

ce serait bien quand même un test

Très intéressant Poolpy, je ne me doutais pas de ce risque !!

Mais cela m'amène à deux remarques :
- Garder UDMH en fonctionnement en permanence n'est pas très sécuritaire (fonctionnement pourtant par défaut proposé). Je vais donc le désactiver et l'activer uniquement lorsque j'en ai besoin (pour l'instant, une seule appli en a besoin : Duke3D... )
- J'aurais aimé avoir une configuration de UDMH du genre Disable par défaut pour toutes les applications sauf une liste définie par l'utilisateur (actuellement, c'est l'inverse qui est proposé !?! )...

Merci pour l'info !!

Bon j'ai ressorti mes vieux cours de C++ tous jaunis d'il y a 10 ans.

D'après mon professeur de l'époque, l'utilisation de la pile ou du tas est liée à la notion de variable automatique (pile) ou dynamique (tas).

void MaProcedure()
{
int i=10; // <-- automatique sur la pile
int t[10]; // <-- tableau automatique sur la pile
int *p = new int[i]; // <-- pointeur p alloué sur la pile, mais contenu alloué sur le tas.

// les variables i, t, p sont automatiques donc désallouées automatiquement
// dès qu'on sort du scope

// par contre le contenu dynamique de p n'est pas désalloué automatiquement
// donc ne pas oublier:
if( p != null ) delete [] p; // [EDIT]
}

Donc un programme correctement écrit ne devrait pas planter si le tas est trop petit, vu que logiquement après le new, on vérifie toujours si le pointeur retourné n'est pas nul, et on agit en conséquence....

gné ... c'est très logique tout ça !!!

stipus

Si mes souvenirs sont bon, je crois que c'est même plutôt :
if( p != null ) delete [] p;
sinon, tu ne libères que le premier élément du tableau.

Oui, dans un monde idéal, en effet...

Merci de la précision Fred, cette erreur semble connue sous le nom de "mixer des allocations mémoires scalaires et vectorielles"

Gotcha #60: Failure to Distinguish Scalar and Array Allocation

Il semble que certains vieux compilateurs acceptaient cette forme, mais tu as raison la forme correcte est d'utiliser l'opérateur correspondant systématiquement.

malloc --> free
new --> delete
new [] --> delete []

De tout ça, on comprend quand même l'intérêt des languages modernes tels que le C#, qui libèrent automatiquement la mémoire non utilisée, à partir du moment où il n'existe plus aucun pointeur vers l'objet alloué...

@@+
stipus

J'ai pas tout compris voir même rien du tout

je crois qu'on s'est gouré de thread, la langue utilisée est le

J'sais même plus qu'elle était la question ...

Larvation :

Je ne crois pas qu'UDMH apporte beaucoup sur les Palm modernes. Je pense que la part de la RAM utilisée pour le cache des bases de données est presque toujours plein, donc qu'il n'y a rien à gagner en plus de la dynamic heap réservée. Au cas où le cache n'est pas plein, la part à gagner est modérée... Cela reste donc à vérifier...

Stipus :



Non, il ne plante pas, il affiche un message "Out of Memory" en cas d'échec de l'allocation mémoire ou assimilé, et retour au launcher. C'est ce qui se passe avec des jeux ou des émulateurs gourmand en mémoire...

Le vrai risque avec UDMH est le suivant :

Imaginons un programme (caricatural, mais bon) avec un bug de type "buffer overflow" :



Ici, on alloue un bloc de 4096 octets, mais on écrit 5096 octets de 0 dedans. Les 1000 octets qui suivent, en mémoire seront eux aussi remis à 0. Problème : ils ne nous appartiennent pas!

Si le bloc gnarkouze a été alloué en dynamic heap, on corrompt l'espace de travail de notre propre programme ou d'un autre programme ayant alloué des données. Dans le meilleur des cas, ou modifie de l'espace non alloué. Au pire on remet à zéro une variable stratégique qui conduit a un plantage. Un soft reset, et c'est oublié.

Si le bloc gnarkouze a été alloué en "storage heap" (parce que UDMH a été installé), il se peut très bien que les 1000 octets qui suivent appartiennent à un programme, à une base de données, à une bibliothèque système, et là, y beaucoup plus de risques de casse, qu'un soft-reset ne réparera pas.

("Coin de la culture" : Dans tous les systèmes d'exploitation moderne, ce problème ne se pose pas - un programme qui tente d'écrire dans une zone mémoire qui ne lui a pas été allouée est arrêté par le système. C'est le "segmentation fault" des unix ou le "Programme a tenté d'écrire à l'adresse ..." de windows).

Conclusion : UDMH+programme instable ou mal écrit = Plus de risques de plantages sévères qu'un soft-reset ne réparera pas.

Dés le début du sujet je savais que j'aurais du mal à comprendre.C'est vérifié mais c'est encore pire que ça,Je n'ose même plus toucher à mon PDA.

Merci à poolpy pour les explications... même si je n'ai pas tout compris, c'est expliqué clairement (enfin heureusement que j'ai quelques vagues souvenirs de programmation).

J'en conclu donc que UDMH n'est pas à utiliser à toutes les sauces pour faire n'importe quoi et surtout qu'il faut bien connaître son utilité et les risques. Avec tout ça, je crois bien que je ne vais pas l'installer.

Si un de tes jeux ou émulateurs préférés (et en version finale, bien propre) ne se lance sur ta machine pas faute de mémoire, UDMH est quand même la seule solution !

Comment tu as deviné que c'était mon idée ???
Mais bon, vu les risques, je crois que je vais laisser tomber ces jeux... j'en trouverai bien d'autres.

Les risques ne sont pas non plus si insoutenables que ça.... depuis plus d'un mois qu'il est actif en permanence sur mon Treo, il ne me semble pas y avoir eu de reset bizarre ni de base corrompue ni quoi que ce soit sauf VersaMail, mais il me semble que c'est une autre histoire...).

Tu peux aussi activer UDMH à la demande. juste avant de lancer ton émulateur.

Et puis si risque il y a, le plus simple est de couvrir le risque, en installant un bon soft de backup et en effetuant des hotsync régulières. Backupman me garde par exemple automatiquement les 3 derniers jours de backup sur la SD.

@@@+
stipus