Discussion :

[Lau-frenssss]

Bonjour,

Dans le cadre d'un projet, il m'est demander de porter une application codée sous Windows avec utilisation de fonction bien propre à cet OS vers un système Debian-Xenomai.

Pour le moment m'a seule idée est d'encadrer ces fonctions Windows par des directives de précompilation afin de pouvoir les remplacer par d'autre fonctions propre au système Unix. Le but étant de pouvoir compiler un exécutable Windows et une version Linux à partir du même code source.

Seulement, je n'aime pas n'avoir qu'une solution en tête, et encore moins l'idée de devoir compiler 2 versions différentes. J'aurais donc bien voulu savoir si d'autre alternative que la précompilation s'offrait à moi.

Merci,
L-F

Edit: L'application est portée vers un système temps réel, donc la perte de performance sera un gros point négatif quant à la solution apportée.

[LittleWhite]

Bonjour,

Pour le moment m'a seule idée est d'encadrer ces fonctions Windows par des directives de précompilation afin de pouvoir les remplacer par d'autre fonctions propre au système Unix. Le but étant de pouvoir compiler un exécutable Windows et une version Linux à partir du même code source.

En terme de performance, c'est ce qu'il y a de mieux, mais à la condition que les fonctions de la bibliothèque Linux soient identiques ou proche (que ce soit le comportement mais aussi les appels) aux fonctions Windows. Permettez moi de douter.

De plus, l'utilisation des directives de précompilation est une solution à court terme. En effet, il y a un risque que cela rende le code illisible et que si on vise une troisième plateforme il faudra tout refaire.

La solution est un refactoring, afin de mettre tous les appels systèmes dans des modules (en C -> des fichiers spécifiques) que l'on incluera/compilera selon la plateforme. Ainsi, pour une troisième plateforme, il suffit de rajouter un troisième fichier qui possède sa propre implémentation. Le code moteur (dans le sens, le reste du code) ne bougera pas d'un poil alors que vous changez autant que vous le souhaitez de plateforme.

Par contre, lorsque cela est mal fait, cela peut être un peu une catastrophe. Donc il faut bien regarder les fonctions Windows, voir les équivalences/possibilités sous Linux et après, seulement après cette étude, mettre en place la nouvelle architecture. Le must, c'est aussi de mettre en place des tests pour savoir si on casse ou pas quelque chose .

[gangsoleil]

Bonjour,

L'application est portée vers un système temps réel, donc la perte de performance sera un gros point négatif quant à la solution apportée.

Ayant cette contrainte, tu ne peux pas faire autre chose que du code natif pour toutes tes cibles : toute emulation (Wine par exemple) te fera forcement perdre en performance.

[Lau-frenssss]

Bonjour,

Tout d'abord je vous remercie pour l'aide apportée. Et je retiens la solution sur les modules correspondant au système d'exploitation. En effet l'idée de ne pas devoir toucher au code source pour ajouter un 3e OS compatible serait assez plaisante...

La solution est un refactoring, afin de mettre tous les appels systèmes dans des modules (en C -> des fichiers spécifiques) que l'on incluera/compilera selon la plateforme. Ainsi, pour une troisième plateforme, il suffit de rajouter un troisième fichier qui possède sa propre implémentation. Le code moteur (dans le sens, le reste du code) ne bougera pas d'un poil alors que vous changez autant que vous le souhaitez de plateforme.

Après quelques recherches sur google, j'ai toujours beaucoup de mal à me représenter la mise en place et le fonctionnement de ces modules. Si tu pouvais me rediriger sur de la doc, ou même encore me faire une brève explication plus précise, ça m'aiderai beaucoup.

Bonjour,
Ayant cette contrainte, tu ne peux pas faire autre chose que du code natif pour toutes tes cibles : toute emulation (Wine par exemple) te fera forcement perdre en performance.

Bien sur, l'idée est bien de modifier le code et non d'émuler car comme tu le dis, la perte de performance sera inévitable. Et de plus je ne pourrais plus garantir un temps de réaction maximale par rapport aux évènements du fait que Wine n'est certainement pas temps réel.

Bien à vous,
L-F

[gangsoleil]

Après quelques recherches sur google, j'ai toujours beaucoup de mal à me représenter la mise en place et le fonctionnement de ces modules. Si tu pouvais me rediriger sur de la doc, ou même encore me faire une brève explication plus précise, ça m'aiderai beaucoup.

Un exemple :

Cas tout melange :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
int ma_fonction (int param1, int param2)
{
/* bla bla bal */
#ifdef win32
  Win_fonction (param1, local_param3);
#else
  Linux_fonction (param1, local_param3);
#endif
/* blabla */
}

Cas separe :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
int ma_fonction (int param1, int param2)
{
/* bla bla bal */
  sous_fonction (param1, local_param3);
/* blabla */
}

Et dans deux autres fichiers :
win_fichier.c

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
ma_fonction (int param1, int local_param3)
{
...
}

linux_fichier.c

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
ma_fonction (int param1, int local_param3)
{
...
}

Et tu modifies ton Makefile (ou equivalent) pour compiler l'un ou l'autre des fichiers selon la cible

[Lau-frenssss]

Si je comprends bien,

Au lieu d'utiliser les directives de compilation, je devrais constituer une sorte d'API portable dans laquelle seraient appelées les différentes fonction spécifiques aux SE.

Mais dans ce cas, si on réfléchis, chaque appel de fonction serait doublé -> Utilisation inutile du processeurs, de la pile etc -> perte de performance.

L-F