Bah pour de l'assembleur multi-plateforme : on peut utiliser nasm ou fasm non?
Ca peut ainsi fonctionner sur toutes les machines x86... (et sous linux, netBSD, win32, peut être même MacOS)

QBasic 32 bits existe (enfin sauf si tu parles d'un truc microsoft), il s'appelle FreeBASIC ( http://www.freebasic.net ), il est vraiment pas mal, à ce que j'ai vu. Il utilise des bindings pour les librairies existantes et donc : allegro, sdl, opengl, etc. sont gérés. Bref, je me tais et j'en vais ^^

kod128, l'assembleur multiplateforme n'existe pas !
Nasm ou fasm s'exécute sur un grand nombre d'architecture, le code assembleur compilé ne le sera que pour une et une seule architecture !

Ce que tu propose nous limite aux architectures x86 de ce point de vue. D'un point de vue portabilité donc, ce n'est pas top :/

Poly Progr@ms, Freebasic est un projet existant, mais j'ai déjà essayé de compiler certaines sources qui marchait très bien sous QBasic avec FreeBasic : une HORREUR !! Des améliorations ont peut-etre été faites de ce coté là depuis l'époque ou j'avais essayé, mais bon. FlexProject, avant d'etre un projet QBasic 32 bits, est un projet pour apprendre.

Et non, ne t'en vas pas et ne te tais pas ! D'ailleurs, tu peux venir nous rejoindre, si tu en as envie....

Pour l'assembleur, je pense qu'on pourrait conserver cette possibilité, puisque de toute facon, soit le prog ne marche pas, soit il n'est pas protable... autant qu'il marche un peu que pas du tout.
En plus, l'adaptation de l'asm en QB, si je me souvient bien, passe par un ASM deja compilé, non? Donc pas besoin de recompiler, il suffit de traduire la ligne QB qui l'execute par une ligne en C...
Sinon, je pense que réécrire les libs sera indispensable, puisque tout programme utilisant le son (de manière évoluée, sous entendu, pas le ahut parkeur systeme ^^) en utilise.

Il faudra recompiler l'asm, puisque pour QB, c'est du 16 bits, alors que notre projet tend à faire du 32 voir 64 bits...

Les instruction 16 bits sont executables en 32, et je peut touours aller fouiner sur la toile pour voir si les differences des opcodes sont si flagrantes (il me semble que non)...
Ca me fait penser: on pourrait gérer les scripts, ce serai cool, non?

ce n'est pas tellement l'opcode des instructions, mais plutot la gestion de la mémoire.
Un pointeur sur une adresse est codé en 16 bits en 16bits et sur 32 bits en 32 bits !
d'où une instruction comme MOV [adresse mem], ax qui est codé sur 3 octets en 16bits s sera codé sur 5 octets en 32 bits...

Je sais, mais il me semble avoir lu jenesaisplusou que la différence des opcodes n'est pas énorme, donc adaptable avec un plug-in (pas un script, désolé, je me suis trompé plus haut)

honnetement, il serait super difficile (et encore, je ne sais pas si c'est possible), d'adapter le code 16 bits en code 32 bits.

- Pour la raison que j'ai cité plus haut d'abord.
- Ce décalage au niveau des octets se fait ressentir ensuite au niveau des instructions. Une instruction se trouvant à l'adresse 0xEAF0 peut ne plus être à cette meme adresse lorsqu'on passe en 32 bits. Et encore, je dit "peut ne plus etre" pour ne pas dire "ne sera plus".

Si au niveau de l'opcode il n'y a pas grande différence, la taille de codage va créer elle de réelle difficulté.

Si toutefois tu trouves une solution simple, je t'invite à la developper clairement pour qu'elle soit étudier ^^

sur les sauts, je sais... enfin, on peut gérer des plug-in et si on est motivés, après, on pourra toujours essayer (moi, ca me motivera paut etre, mais on verra quand on en sera vers la fin, au pire)