On revient vraiment au dev ici ? - Page 2

Concernant la VDI, n'oublie pas le mode de dessin (vswr_mode()) et la méthode de remplissage (vsf_style(), le DEFFILL du GFA). Je crois que sous XaAES (enfin, plutôt fVDI), les valeurs par défaut ne sont pas celles du TOS ou MagiC. Si ça se trouve, le remplissage est en mode transparent ou non rempli.

Je suppute le non-rempli, car on voit un cadre blanc dans ta fenêtre, qui correspond à ton v_bar().

Merci rajah ! Quel boulet je fait quand même !

Effectivement ça va beaucoup mieux maintenant sous mint !

En tout cas t'as de bons yeux, j'avais même pas remarqué le cadre blanc sur la fenêtre !

Il sera écrit Merci à Pierre Tonthat dans le panneau A propos du programme ! Quand il sortira fini, donc vers les 2025 !

Allez Hop Rajah Vs Gem : Rajah l'emporte de nouveau !!

Et voila un problème reparti chez lui. Cooper je continue la routine aujourd'hui, car j'avais pas tilté mais Azrael est en Alsace, donc hier soir nous sommes sortis.



GT Sortit

Alors d'autres pbs de dev ?


GT

Oui, une question spécial pour toi

Y a t-il moyen de connaitre la taille de la pile d'un programme compilé avec Gcc ?

Question suivante ? S'il vous plait

Il y a pas de spécialiste de Gcc ici ? Patrice mandin, ou Orion peut etre ? Ou d'autre spécialiste de ce langage.



GT Pour l'ASM !!


P.S. En Asm je sais et choisis la taille de ma pile

Nalfus (./35) :
Oui, une question spécial pour toi

Y a t-il moyen de connaitre la taille de la pile d'un programme compilé avec Gcc ?

Quand tu compiles un prog avec gcc, le fichier crt0.o contient la variable _stksize qui contient la taille par défaut de la pile au lancement du prog (par défaut toute la mémoire dispo je crois)

L'outil stack permet de changer cette valeur par défaut après compilation.

Les valeurs utilisées:
http://sparemint.org/cgi-bin/cvsweb/mintlib/mintlib/crtinit.c?rev=1.10&content-type=text/x-cvsweb-markup

Non, je connais pas, désolé.

Ce n'est pas la peine, Patrice Mandin a donné la réponse juste avant

Donc pb suivant ?


GT

C'est vraiment le bordel les piles en C, quand on voit la taille Après on s'étonne que des gens arrivent a faire tourner du code en douce en bricolant les piles. La mienne fait maxi 512 octets, donc good luck


GT Plutot petite

pmandin (./38) :

Nalfus (./35) :
Y a t-il moyen de connaitre la taille de la pile d'un programme compilé avec Gcc ?

Quand tu compiles un prog avec gcc, le fichier crt0.o contient la variable _stksize qui contient la taille par défaut de la pile au lancement du prog (par défaut toute la mémoire dispo je crois)

J'ai bien un fichier crt0.o avec les LIB.
J'ai _stksize 0 dans mes programmes

pmandin (./38) :
L'outil stack permet de changer cette valeur par défaut après compilation.

Les valeurs utilisées:
http://sparemint.org/cgi-bin/cvsweb/mintlib/mintlib/crtinit.c?rev=1.10&content-type=text/x-cvsweb-markup

Comment modifier la valeur par défaut de _stksize à la compilation ? Editer le crt0.o ?

Petit H.S. :

J'ai confondu buffer et stack overflow, mais petite info rigolote provenant du wiki francais a buffer overflow, concernant les moyens de ce proteger :

Protections logicielles

Modifier le compilateur pour qu’il insère des instructions NOP de façon aléatoire dans le code du noyau et des applications (opérations de routine en Linux). Cela ralentit peu les programmes et complique énormément la tâche de l'attaquant qui ne sait plus quelles adresses il doit viser.


GT Au ralenti

H.S. Off

Nalfus (./43) :
Comment modifier la valeur par défaut de _stksize à la compilation ? Editer le crt0.o ?

A la compilation, on ne peut pas. Faut utiliser stack:
stack -S 131072 monprog.tos
pour avoir une pile de 128Ko par exemple

Ok. Merci pour ton aide Patrice

Question suivante s'il vous plait

Vous avez un problème ? Non a (surement) une solution

GT

Bon alors ??? Elles sont où les questions ?

Bh moi j'en ai bien une, mais je devrais trouver, car c'est un problème de l'interface qui se trouve derrière le clavier !

Donc je cherche...

Change d'interface


GT Sur le mauvais clavier

Rajha, si tu passes dans le coin...

Serais-tu exposer vite fait (ou longuement), la technique du vro_cpyfm en GFABasic, car j'ai beau tourner et retourner tes codes, et c'est vraiment pas si simple...

C'est pour remplacer un GET(x,y,w,h,img$) et PUT(x,y,img$), qui est très simple à comprendre dans mon code, mais qui ne fonctionne pas sous Mint !


Merci d'avance...

GET et PUT sont à proscrire sur autre chose qu'un ST(E). Et fortement déconseillé avec NVDI. Sous MiNT, je suppose que tu est avec Aranym : c'est fVDI l'écran est tout à fait différent des résolutions ST.

Faut penser en C et (encore) aller potasser les doc-dev de http://toshyp.atari.org/en/00700b.html
Si tu veux un exemple en GFA simple, va chercher dans les VDI_FX : le B/POINK.PRG, et quand tu seras plus habitué, le SOTB.PRG

Bon, c'est quand même plus clair, en effet !

le MFBD, correspond en gros au img$ du GET/PUT... Si j'ai bien compris... Le reste est assez limpide...

Merci !

Bien ! vro_cpyfm digéré et intégré ! Celà n'a pas été évident, mais tout fonctionne comme sur des roulettes !

Merci rajah et poink.gfa ! Mes menus en fenêtres sont maintenant rapide et je n'ai plus de problème d'affichage quand un menu dépassait un peu de la fenêtre !


Maintenant je bloque sur complètement autre chose... Aurais tu l'amabilité de m'expliquer ta façon de faire (qui je suppose est la bonne technique), comment appeler un logiciel tiers via mon programme en lui passant uune ligne de commande (exemple appeler ZVIEW et lui passer une image)

J'ai bien vu, les coups de APPL_FIND et SHL_WRITE, mais pourquoi donc ferme tu toutes les fenêtres et les détruit ??? C'est sensé être du multitache non ?

Bien entendu, j'ai bien éssayé de gruger en ne fermant rien : ZVIEW m'affiche bien l'image, mais ce con il reste bloqué ! Obligé de tuer le processus pour reprendre la main sur mon programme !

Merci d'avance rajah !

P.S : après j'attaque les icones couleur !

Relis le code, je les ferme et réouvre uniquement en monotâche.

Faut avant détecter si c'est multitâche ou pas dans le début de ton programme.
- présence MiNT : on assume que c'est oui.
- présence MagiC : si l'application_id = 0, c'est le mode monoTOS, sinon c'est mutitâche.
- autre : on assume que c'est monoTOS.

Regarde la valeur de ton ap_id&

Playmobil (./53) :
Bien ! vro_cpyfm digéré et intégré ! Celà n'a pas été évident, mais tout fonctionne comme sur des roulettes !

Merci rajah et poink.gfa ! Mes menus en fenêtres sont maintenant rapide et je n'ai plus de problème d'affichage quand un menu dépassait un peu de la fenêtre !


Maintenant je bloque sur complètement autre chose... Aurais tu l'amabilité de m'expliquer ta façon de faire (qui je suppose est la bonne technique), comment appeler un logiciel tiers via mon programme en lui passant uune ligne de commande (exemple appeler ZVIEW et lui passer une image)

J'ai bien vu, les coups de APPL_FIND et SHL_WRITE, mais pourquoi donc ferme tu toutes les fenêtres et les détruit ??? C'est sensé être du multitache non ?

Bien entendu, j'ai bien éssayé de gruger en ne fermant rien : ZVIEW m'affiche bien l'image, mais ce con il reste bloqué ! Obligé de tuer le processus pour reprendre la main sur mon programme !

Merci d'avance rajah !

P.S : après j'attaque les icones couleur !

Comme l'a déjà dit Rajah on ferme les fenêtres si on se retrouve sous monotos, sinon pas besoin.
Pour savoir si on est en monotache il y a une façon très simple qui ne demande pas d'aller voir les cookies, après appl_init() suffit de regarder dans le tableau global à la position 1 (_AESnumapps) si la valeur est 1 (singletos) ou autre (normalement -1) pour système multitache.

OL