Linux? - Page 53

(hohohohoho ! hihihihi ! )

hahehihohuhy

hahahahahaha !

ha

(pour eviter qu'un modo passe par la avec raison, je pense que meme si c'est pour parler d'iphone & coil vaudrait mieux se remettre a en parler que faire des hahahahuhuhu & co)

hahahaha

Tu n'as pas comprit, ça rejoint le fait que je ne peux pas regarder GG sur l'iPhone car, n'ayant plus mon PC, je ne peux plus transférer sur l'iPhone ^^

Sinon, j'attend le N8 de Nokia, j'ai lu pas mal de trucs bien, même si je voulais un clavier, je suis bien tenté.

héhéhéhéhé
eh oui, c'était trop subtil, c'est tout

Ah mais merde, jme suis trompé de topic en plus ^^

kernel c'est bien, nostub aussi.

Et Linux aussi

(Mais pas Fedora )

Folco (./1558) :
Sauf que quand on programme efficacement, un saut vers une fonction de lib conditionnelle avec PreOS se résume à un jsr fonction.l si on accepte le smc, ou à un jsr x(an)/jmp (fonction) si on fait du pic.

Pas si on programme en C.

son dock 57,26 fois plus petit permet de suivre, en always-on-top, à la fois le débogueur et le source.

Bah, tu peux utiliser le mode multi-fenêtres style GIMP, comme ça tu peux cacher ce qui ne te sert pas et placer le reste de manière optimale.

Sauf que j'ai besoin au minimum du code, des registres, des flags et de la RAM. Et j'aime pas le multi-fenêtre, j'avais particulièrement insisté auprès de Romain pour avoir un dock unique, et il l'avait gentiment fait.
Le problème c'est qu'en GTK, ça prend une place folle. Les tailles de police auraient dû être fixées par défaut.

Kevin Kofler (./1570) :
Pas si on programme en C.

On peut parfaitement calculer les pointeurs de fonction et les appeler comme ça en C.

    const unsigned char PdtlibFuncs[] =
    {
        PDTLIB__INIT_CMDLINE,
        PDTLIB__MANAGE_ARGS,
        PDTLIB__GET_CURRENT_ARG_PTR,
        PDTLIB__SKIP_ARGS,
        PDTLIB__GET_FILE_PTR,
        PDTLIB__CHECK_FILE_TYPE,
        0,                             /* End of table */
        0
    };
    const unsigned short PdtLibOffsets[] =
    {
        (unsigned long)&Data.InitCmdline        - (unsigned long)&Data,
        (unsigned long)&Data.ManageArgs         - (unsigned long)&Data,
    (unsigned long)&Data.GetCurrentArgPtr   - (unsigned long)&Data,
        (unsigned long)&Data.SkipArgs           - (unsigned long)&Data,
        (unsigned long)&Data.GetFilePtr         - (unsigned long)&Data,
        (unsigned long)&Data.CheckFileType      - (unsigned long)&Data
    };

    RegisterFunctionsPtr(&Data, Data.pdtlib, PdtlibFuncs, PdtLibOffsets);
...
    if (Data.CheckFileType(CfgFilename, TEXT_TAG, NULL) == 0)
        Data.printf(STR_NO_CONFIG_FILE);
    else
    {
        ptr = Data.GetFilePtr(CfgFilename);
    }

void RegisterFunctionsPtr(SFRAME* Data, LibRef* Descriptor, const unsigned char* Func, const unsigned short* Offset)
{
    while ((*Func != 0) || (*(Func + 1) != 0))
    {
        *(void**)((unsigned long) Data + *Offset) = kernel_LibsPtr(Descriptor, (short) *Func);
        Offset ++;
        Func ++;
    }
}

Folco (./1571) :
Et j'aime pas le multi-fenêtre, j'avais particulièrement insisté auprès de Romain pour avoir un dock unique, et il l'avait gentiment fait.

Bah, j'ai toujours trouvé que le mode dock sux, je me demande d'ailleurs si je ne devrais pas mettre le multi-fenêtre par défaut dans Emu-TIGCC.

On peut parfaitement calculer les pointeurs de fonction et les appeler comme ça en C.

On peut faire ça aussi avec les "DLLs nostub".

Mais ça économise seulement une indirection. La DLL contient déjà une table comme ça, elle est relogée quand toute la DLL est relogée avec EX_patch, et un pointeur sur cette table est gardé dans une variable globale __DLL_interface_ptr dans le programme principal. (C'est ça la raison technique pour laquelle une seule DLL peut être chargée à la fois.)

Folco (./1571) :

    const unsigned short PdtLibOffsets[] =
    {
        (unsigned long)&Data.InitCmdline        - (unsigned long)&Data,
        (unsigned long)&Data.ManageArgs         - (unsigned long)&Data,
        (unsigned long)&Data.GetCurrentArgPtr   - (unsigned long)&Data,
        (unsigned long)&Data.SkipArgs           - (unsigned long)&Data,
        (unsigned long)&Data.GetFilePtr         - (unsigned long)&Data,
        (unsigned long)&Data.CheckFileType      - (unsigned long)&Data
    };

Ce code n'est pas du C valide. Tu ne peux pas utiliser des offsets comme ça en C, seulement des pointeurs relogés. (Le tableau des DLLs nostub est aussi un tableau relogé, pas un tableau d'offsets.)

Kevin Kofler (./1572) :
(C'est ça la raison technique pour laquelle une seule DLL peut être chargée à la fois.)

C'est dû au design délibérément merdique que tu as choisi cette limitation, c'est pas une fatalité. Tu vas pas me dire qu'un handle contenant ces pointeurs aurait été dur à implémenter...

Kevin Kofler (./1573) :
Ce code n'est pas du C valide.

Ah bon ? Une différence de pointeurs c'est interdit ? En tout cas "ça compile" ©, et le principe est là. D'ailleurs, c'est plus de l'asm transcrit qu'autre chose.

sur un pc une dll/so est TOUJOURS -fPIC donc pourquoi on fait pas ça sur ti?

Parce que les codeurs asm ont codé comme des procs ? J'ai souvent pensé à porter les libs existantes en pic, mais ce serait un boulot de test énorme pour pas grand chose. Dommage, car sous PedroM ça cartonnerait.

Kevin Kofler (./1572) :

Folco (./1571) :
Et j'aime pas le multi-fenêtre, j'avais particulièrement insisté auprès de Romain pour avoir un dock unique, et il l'avait gentiment fait.

Bah, j'ai toujours trouvé que le mode dock sux, je me demande d'ailleurs si je ne devrais pas mettre le multi-fenêtre par défaut dans Emu-TIGCC.

Il suffit de mettre une question avec deux shotscreens dans l'installeur pour que le premier concerné - l'utilisateur - ait le choix.

Il n'y a pas l'installeur sous GNU/Linux, et un RPM n'a pas le droit de poser des questions à l'installation.

Ben c'est une grave erreur…
Les .deb ont le droit, eux…

Folco (./1574) :
Ah bon ? Une différence de pointeurs c'est interdit ? En tout cas "ça compile" ©,

Ça compile où? À l'intérieur d'une fonction? (Parce qu'avec Lionel, on a essayé et GCC n'a pas accepté ça en global!) As-tu regardé le code que GCC te donne pour ça? (Indice: Ce tableau est construit en temps d'exécution sur la pile s'il est local étant donné qu'il n'y a pas de static, et GCC te calcule gentiment l'offset avec 2 relogements, un sub.l et un move.w reg-to-mem.)

GoldenCrystal (./1579) :
Ben c'est une grave erreur…Les deb ont le droit, eux…

<SARCASM>Super pratique</SARCASM> quand tu installes une distribution entière, tu dois être là sans arrêt pour répondre aux questions…
Debconf est une idée totalement pourrie, l'installation non-interactive est un principe indispensable.
J'adore le fait que Fedora ne me pose pas de questions à la con à chaque fois que j'installe un logiciel.

Kevin Kofler (./1581) :
Super pratique quand tu installes une distribution entière, tu dois être là sans arrêt pour répondre aux questions…

N'importe quoi, il n'y a pas de questions à l'install. Essaye avant de raconter n'importe quoi.

Kevin Kofler (./1581) :
Debconf est une idée totalement pourrie, l'installation non-interactive est un principe indispensable.

Pffff Le fait que ça puisse être interactif est une feature de merde ? Sous Debian et dérivés, au moins on peut faire ça, nous.

Kevin Kofler (./1580) :
Ça compile où? À l'intérieur d'une fonction?

Dans main.

vince (./1577) :
Il suffit de mettre une question avec deux shotscreens dans l'installeur pour que le premier concerné - l'utilisateur - ait le choix.

On parle du monde de Kevin, là ! Kevin est là pour décider pour lui

Han, j'aurais jamais dû regarde ce code bordel !!!
const char CfgFilename[] = "system\as";
=>

.LC0:
    .ascii "system\as\0"
    ...
    move.b .LC0,(%a4)
    move.b .LC0+1,83(%sp)
    move.b .LC0+2,84(%sp)
    move.b .LC0+3,85(%sp)
    move.b .LC0+4,86(%sp)
    move.b .LC0+5,87(%sp)
    move.b .LC0+6,88(%sp)
    move.b .LC0+7,89(%sp)
    move.b .LC0+8,90(%sp)
    move.b .LC0+9,91(%sp)

Mais que fait GCC ???


Et sinon :

    const unsigned short PdtLibOffsets[] =
    {
        (unsigned long)&Data.InitCmdline        - (unsigned long)&Data,
        (unsigned long)&Data.ManageArgs         - (unsigned long)&Data,
        (unsigned long)&Data.GetCurrentArgPtr   - (unsigned long)&Data,
        (unsigned long)&Data.SkipArgs           - (unsigned long)&Data,
        (unsigned long)&Data.GetFilePtr         - (unsigned long)&Data,
        (unsigned long)&Data.CheckFileType      - (unsigned long)&Data
    };

typedef struct SFRAME
{
    void (*InitCmdline) (CMDLINE* CmdLine, int argc, const char** argv);
    int (*ManageArgs) (CMDLINE* CmdLine, void* Data, const char* OptList, int (*Callback)(void* Data, int Status),
                       void (*SwitchFunc)(void* Data, char Sign), ...);
    const char* (*GetCurrentArgPtr) (CMDLINE* CmdLine);
    void (*SkipArgs) (CMDLINE* CmdLine, int NumArgs);
    FILE* stderr;
    void (*printf) (const char* format, ...);
    short (*fprintf) (FILE *stream, const char* format, ...);
    int (*CheckFileType) (const char* Filename, unsigned char Type, const char* CustomType);
    void* (*GetFilePtr) (const char* Filename);

    LibRef* syslib;
    LibRef* pdtlib;
    CMDLINE Cmdline;
    long GlobalFlags;
    long FileFlags;
    long* CurrentFlags;
} SFRAME;

=>

PdtLibOffsets.5157:
    .word    0
    .word    4
    .word    8
    .word    12
    .word    32
    .word    28

Ca marche.

Résumé -> Les libs conditionnelles sont parfaitement exploitables en asm et en C, de manière optimale.

Oserais-je ? Non, c'est trop gros. Rah pourtant... hmmm je me tâte... oué, pas trop longtemps... allez, déconnons sec \o/
Désolé de t'apprendre le C mon cher

pour le premier coup c'est un code d'initialisation, what else? (bon il est bien pourri quand même )

Ben what else qu'il est over pourri, lent et lourd (j'ai édité la partie asm de ce code)

move.l #'syst',x(sp)
move.l #'em\a',x+4(sp)
move.w #'s\0',x+8(sp)

Bon ok, une chaine constante, j'aurais dû la déclarer en global pour éviter la recopie sur la pile. Mais bordel, le const devrait lui faire savoir que c'est pas la peine de recopier...

et ça, ça génère quoi?

const char * = "system\as";

const char * const = "system\as";

(y'a toujours la vieille notion du pointeur constant, et du contenu pointé constant, moi j'ai jamais clairement pigé comment ça s'écrit.

const char* => la chaine est constante.
char* const => le pointeur de la chaine est constant.

static const char CfgFilename[] = "system\as";
à l'intérieur d'une fonction, est une des façons de déclarer de manière (semi-)globale cette string.

Folco (./1588) :
const char* => la chaine est constante.
char* const => le pointeur de la chaine est constant.

oué, en fait on devrait plus ou moins écrire :
char const* const
car le const s'applique à l'élément qui le précède.





char const
donne un char constant,

char const*
un pointeur sur un char constant

char* const
un pointeur constant sur un char

char const* const
un pointeur constant sur un char constant





Mais en général les gens préfèrent écrire
const char
que
char const...