Executer un prog archivé - Page 1

Peut-être que je me plante, mais l'exemple dans la FAQ de la doc de tigcc expliquant comment faire son propre launcher pour des progs de + de 8ko ou 24ko ne marche pas bien : les progs archivés pour kernel font reseter la calc... C'est moi qui me suis planté ou le programme d'exemple est faux?

Y' pas besoin de launcher pour les prog pour kernel

oui, je sais bien...
J'avais juste besoin de ca pour executer un prog a partir d'un autre.

suffit de mettre le dossier le nom et () sur la pile et de lancer ?!

moi ca marche a chaque fois....

Oui, mais justement je ne veux pas faire ca car j'ai besoin de garder l'estack comme elle est.

Si tu le met a la main sur l'estack (sans passer par push_parse_text), ca devrait marcher ...

Oui, mais NG_execute détruit aussi parfois l'estack
[edit]Edité par ExtendeD le 20-07-2001 à 23:22:38[/edit]

et si tu recopies la chaine dans ton lanceur?
a + ")")

à savoir:char *a;
a = next_expression_index + 2;
NG_exectute("as92(" +

?

Oui, j'ai pensé à aussi, mais je sais pas pourquoi, apparement NG_execute crée un handle, et il ne faut pas qu'un handle soit créé. Peut-être que g mal vu, parce ue y'a aucune raison. En tout cas ca plantait quand g fait ca.

Oui, NGexecute de mande un handle.
Mais tu dois pouvoit t'en sortir en mettant ce qui faut sur la pile, et avec un RationalESI

J'ai trouvé le problème, je n'ai pas essayé mais ca devrait marcher maintenant. Ca provient d'un bug dans le code du launcher de la FAQ (et dans les sources des versions précédentes de ttstart dans tt et tigcc).

Dans tigcc_patch.zip :

If NOSTUB programs become too large they cannot be started directly on AMS 2.0x.
Therefore the TIGCCLIB FAQ suggests a launcher tool which performs the following
sequence:


SYM_ENTRY *symptr = DerefSym(SymFind($(filename)));

if (!symptr) fatal("Program not found")
plen = *(short*)(cptr = fptr = HLock(symptr->handle)) + 3;
//
// more code comes here, including the start of the program ...
//
HeapUnlock(symptr->handle);

What's wrong with this sequence? First of all it performs also an conditionally
Lock/Unlock sequence, but this shouldn't be a problem as long as the file cannot
be start twice (like its possible for an explorer).
The real problem is the using of symptr->handle in the HeapUnlock! Suppose your
program runs a while and heap compression is triggered. The file stays locked
so it ISN'T moved around, but the SYM_ENTRY structure may be moved arround!
When this structure is moved arround due to a heap compression your program
will probably crash again.

NOTE: This problem is NOT ONLY related to launchers, but to each code which
handles with SYM_ENTRY pointers. You have to be very carefully when you operate
with VAT access functions.

NOTE2: This problem again is NOT ONLY related to NOSTUB programs. I have examined
the sourcecode of the DoorsOS 0.98 and it contains this bug in various locations
(each of them is a possible crash source).

A stable launcher sequence will look like this:

SYM_ENTRY *symptr = DerefSym(SymFind($(filename)));
volatile HANDLE h;

if (!symptr) fatal("Program not found")

h = symptr->handle;
if (HeapGetLock(h)) {
//------------------------------------------------
// already locked before !! (set h to 0 as marker)
//------------------------------------------------
cptr = fptr = HeapDeref(h);
h = 0;
}
else {
cptr = fptr = HLock(h);
}

plen = *(short*)(cptr) + 3;
//
// more code comes here, including the start of the program ...
//
if (h) HeapUnlock(h);