Discussion sur le langage Forth

[Xavier31]

En fait tu cherches une façon "portable" (i.e. indépendant de la machine) de faire une sauvegarde compatible avec le basic des dites machines (de sorte à pouvoir charger avec RUN ""). Je pense que c'est un besoin d'utilisateur d'informatique "récente", dont on ne peut reprocher aux concepteurs du langage de ne pas l'avoir introduit.

Non, pas du tout. Je ne cherche pas du tout quelque chose qui soit indépendant de la machine.
Ce n'est pas non plus un besoin d'utilisateur d'informatique récente, vu que j'utilise Turbo-Pascal 3.0 sous CP/M.

Quand on est programmeur, et qu'on a écrit un programme, (peu importe le micro-ordinateur)
on souhaite qu'un autre utilisateur puisse le lancer sur sa machine, SANS POSSEDER le langage avec lequel a été écrit le programme.
C'est aussi simple que ça. Ca ne date pas d'aujourd'hui.

SI tu écris un programme en langage FORTH, ton voisin ne pourra le lancer QUE s'il possède le langage FORTH.

Le génie de Turbo-Pascal 3.0 quand il est arrivé en 1983, c'est que les programmes crées ne généraient pas seulement
des .PAS (programme source Pascal qui ne s'exécute QUE dans Turbo-Pascal)

MAIS AUSSI de pouvoir générer un programme compilé en langage machine en .com
qui est exécutable tout seul, sous CP/M, SANS avoir besoin de posséder Turbo-Pascal! (et libre de droits!!)

A l'époque, Microsoft avait aussi sorti un langage Pascal, beaucoup plus cher, mais Microsoft demandait des royalties
si tu vendais ton propre programme écrit avec son Pascal !!!

Borland est arrivé avec son Turbo-Pascal à 50 dollars!! et a dit :
- Créez vos programmes en Turbo-Pascal, vendez-les si vous voulez, ils sont libres de droits (pas de royalties à nous verser)
- Vous pouvez générez un exécutable .com, donc PAS BESOIN pour vos utilisateurs de posséder une copie de Turbo-Pascal
pour lancer VOS programmes.

Résultat : Borland a écrasé le Pascal de Microsoft qui a pratiquement disparu.
(c'est TRES rare dans l'histoire de l'informatique qu'une petite société ait pu battre Microsoft sur le terrain des langages)

Voilà, je ne sais pas pourquoi ma question a généré autant de posts, alors que j'ai la réponse depuis bien longtemps :
FORTH ne sauvegarde que des programmes sources qui ne s'exécuteront QUE sous FORTH.

Résultat, si tu veux que ton voisin teste ton programme, il doit posséder le langage FORTH sur son ordinateur.
EN 1983, déjà, on s'affranchissait de ça. Ce n'est pas nouveau ni récent.

Je suis sûr et certain que c'est ce qui a fait disparaître le langage FORTH par rapport au langage C.

Tu imagines, si en C, on devait demander aux gens de posséder un compilateur C pour pouvoir exécuter NOS programmes ??

Il faudrait dire à ton voisin : "Je te passe un programme, mais tu dois posséder un compilateur C, le lancer,
puis charger mon programme et le compiler à la main. Ensuite seulement tu pourras l'utiliser."

C'est ce qui se passe avec FORTH. On peut lui trouver des excuses, genre "il est plus ancien que Turbo-Pascal, etc.",
mais je ne m'occupe pas de ça. Je dis juste : On ne peut faire tourner les progs que sous Forth, donc c'est très limité.

J'ai bien compris que vous voulez modifier le Forth du MO5 pour qu'il puisse sauvegarder de vrai excutable autonomes.

Mais ça ne m'intéresse pas, car si demain, je veux un exécutable sous Amstrad CPC, Commodore 64, ou sur mon PC Windows,
comment je fais ? Et si le jour d'après je veux faire ça sur un autre micro-ordinateur ? cette solution n'est pas viable.

Je pensais écrire des petits utilitaires écrits en FORTH sur mon PC sous Windows et les diffuser,
mais s'il n'existe pas de FORTH qui crée des programmes autonomes, ça ne sera pas possible.
Mais peut être qu'avec GFORTH ou Turbo-Forth ils y ont pensé, je n'ai pas encore testé.

C'est bien beau en 79 et en 83 d'avoir normalisé le FORTH, mais ils auraient du penser à faire comme Turbo-Pascal,
de façon à pouvoir faire en sorte que n'importe qui ne possédant pas FORTH puisse quand même lancer le programme.
Et sans avoir à le compiler à la main. (pour le grand public c'est rédhibitoire).

Voilà pourquoi FORTH n'a pas décollé en dehors des laboratoires, et des application métiers.
(un ingénieur n'a aucun problème à faire tourner son programme Forth et à la compiler à la main à chaque fois,
par contre, pour vendre des logiciels, les programmeurs choisiront Turbo-Pascal puis le langage C, c'est évident).

Voilà, même si vous arrivez à créer ce que Dominique appelle un ExeForth pour MO5, le problème reste entier
pour les autres ordinateurs. Et je ne compte pas m'amuser à bidouiller la RAM de chaque différent ordi!

Mais bon, je continue à apprendre à programmer en Forth, pour le côté intellectuel.
Mais quand je veux créer un programme que je veux diffuser, j'utilise un autre langage.

[Xavier31]

En fait, tous ces posts sont inutiles.

Quand j'ai posé la question, il suffisait de me répondre :
"Non, on ne peut pas le faire en FORTH, sans trafiquer le compilateur ou le programme en mémoire".

J'aurais compris. Lol

[__sam__]

En fait, tous ces posts sont inutiles.

Pas tant que cela. S'interroger sur le pourquoi du comment de l'absence d'un concept qui nous parait évident de nos jours permet de réfléchir à l'évolution des technologies. Ok c'est de la "discussion de salon" sans vrai but, mais ca permet de réfléchir, ce qui est déjà bien

MAIS AUSSI de pouvoir générer un programme compilé en langage machine en .com
qui est exécutable tout seul, sous CP/M, SANS avoir besoin de posséder Turbo-Pascal! (et libre de droits!!)
(..)
Résultat, si tu veux que ton voisin teste ton programme, il doit posséder le langage FORTH sur son ordinateur.
EN 1983, déjà, on s'affranchissait de ça. Ce n'est pas nouveau ni récent.

Oui oui je comprends bien ton point de vu, mais il me semble très orienté personnal-computeur et ne tient pas compte de la diversité des systèmes de micro-ordinateur au début de 1980. C'est quoi l'équivalent de CP/M sur TO7, Zx ou TI99-4a? A l'époque, les amateurs s'échangeait des programmes en basic . L'échange de source était le mode de diffusion privilégiés entre amateurs toutes machines confondues (cf le contenu des premiers numéros de hebdogiciels). Alors oui, on peut regretter que le FORTH n'ait pas prévu de génération de binaires en standard. Mais il faut moduler cela par le fait que la notion de "binaire standard" n'était pas évidente du tout à l'époque.

Cela dit, c'est du passé, et ce qui compte est ce qu'on peut faire à présent. Et je suis persuadé que Dominique va nous sortir un beau-programme autoporté pour son outil de paint.

Tu imagines, si en C, on devait demander aux gens de posséder un compilateur C pour pouvoir exécuter NOS programmes ??

C'est toujours en le cas pour une partie des programmes. Unzip.exe ms-dos ne marche pas sur mon amiga. Je suis obligé de récupérer les sources pour recompiler. Recompiler était très fréquent dans la mouvance unix d'origine. Si j'ai bon souvenir, durant mes études, il me semble qu'il y avaient des gros classeurs avec le code source des OS achetés à l'époque (je ne serais pas surpris s'ils aient du aussi le compiler pour l'installer). Je crois aussi que freeBSD doit toujours être distribué sous forme de code source qu'il faut compiler soi-même (Le fameux "make world" qui récupère par FTP le code source et recompile le noyau).

C'est d'ailleurs à mon sens ce qui a fait le succès du C le fait qu'il est allé de pair avec l'apparition et l'évolution des OS *nix au travers de différentes plateformes.

Le passage des architectures de 16 à 32bits a du aussi porter un coup au Forth. Le C a réussi sa migration 16->32 (à tel point que pour beaucoup de gens, sizeof(int) vaut toujours 4. mais c'est un autre sujet) alors que manipuler du 32bits en Forth me semble être resté difficile.

Bref tout n'est pas forcément du à l'absence de "binaire natif". La disparition (relative) du Forth est certainement mufti-factorielle. Ca serait trop simple sinon

[jfg]

Quand on est programmeur, et qu'on a écrit un programme, (peu importe le micro-ordinateur), on souhaite qu'un autre utilisateur puisse le lancer sur sa machine, SANS POSSEDER le langage avec lequel a été écrit le programme. C'est aussi simple que ça. Ca ne date pas d'aujourd'hui

...

Mais ça ne m'intéresse pas, car si demain, je veux un exécutable sous Amstrad CPC, Commodore 64, ou sur mon PC Windows, comment je fais ? Et si le jour d'après je veux faire ça sur un autre micro-ordinateur ? cette solution n'est pas viable.

Sauf, que ça n'existe pas! Je ne connais aucun moyen permettant d'exécuter un programme quel que soit le système d'exploitation. Pour la simple raison que les CPU diffèrent (Motorola, Intel, MIPS, Zilog, Sparc, PowerPC, ...) et que les façons d'accéder aux périphériques ne sont pas standardisées.
La façon actuelle d'écrire des logiciels assez portables est d'utiliser le langage Java (et surement pas le C ou le C++), qui normalise tout un ensemble très vaste d'accès aux routines système, mais cela nécessite une machine virtuelle pour chaque système d'exploitation / CPU.

Ce que tu demandes au Forth n'a jamais existé et n'existe nulle part. (De plus, je vois que vos programmes Forth sont truffés de langage machine, absolument pas portable...).

[Xavier31]

Salut Jfg,

Bien sûr que ça existe. Depuis longtemps. J'utilise ça tous les jours.
Par contre, je ne parle pas de faire tourner un programme sur TOUS les systèmes d'exploitation,
mais sur LE même modèle d'ordinateur. SANS posséder le langage qui a crée le programme. (ce qui facilite la diffusion).

- Prends CP/M. (un Amstrad CPC, un MSX 2, un Osborne 1, bref n'importe quel ordi faisant tourner CP/M)

- Lance le compilateur Turbo-Pascal et écris ton code source .PAS puis compile-le sur disque (tu obtiens un exécutable .com)

Voilà, tu peux envoyer ton programme binaire machin.com à n'importe quel utilisateur CP/M de la planète,
ton programme s'exécutera sur sa machine. (en respectant la programmation CP/M bien sûr, donc sans toucher au hardware).

PAS BESOIN pour les autres personnes d'ACHETER ni posséder le langage Turbo-Pascal.

C'était un des arguments de Philippe Kahn, et qui a contribué (entre autres) au succès de Turbo-Pascal.

Quand au FORTH, je ne demande pas EXACTEMENT la même chose, nuance! ^^

Je sais bien qu'un exécutable binaire qui aurait été crée sur un MO5 ne fonctionnerait sur un AMSTRAD.
Je ne suis pas débutant en informatique à ce point-là! Lol

Mais si le FORTH permettait d'enregistrer une fichier binaire compilé,
tous les utilisateurs DE CETTE MACHINE pourraient le lancer sans avoir à acheter le langage FORTH.

Les utilisateurs d'un autre modèle d'ordinateur, devraient eux, recompiler le code source on est d'accord.

Mais c'est une sacré avancée pour diffuser ses programmes sur le même modèle d'ordinateur non ?

[Xavier31]

De plus, je vois que vos programmes Forth sont truffés de langage machine, absolument pas portable...).

On ne veut pas faire de la portabilité multi-ordinateurs. On sait bien que c'est impossible, surtout avec du langage machine.

La discussion porte sur le fait que FORTH ne possède pas la faculté de sauvegarder un programme binaire compilé
qui puisse d'exécuter SANS LUI.

Sans avoir à charger FORTH à chaque fois, puis à compiler à chaque fois le prog source pour l'exécuter.

- Les personnes qui ne possèdent pas le langage FORTH sur la même machine que toi ne pourront pas exécuter ton programme.
- Si tu voulais diffuser un jeu écrit en FORTH sur MO5 en 1985, ça aurait été illégal puisque tu n'as pas le droit de mettre le FORTH de Loriciels sur la cassette que tu diffuses, alors que c'est indispensable...
- Même si la personne reçoit le langage FORTH, pas sûr qu'elle sache charger,compiler, et exécuter un code source FORTH.

Bref, tu vois la galère par rapport à Turbo-Pascal...

Ce n'est pas magique, ça ne fait pas des programmes compatible inter-machine (ça ça n'a jamais existé, nous sommes bien d'accord)
mais au moins, on pourrait distribuer ses programmes fait maison.

La solution de Dominique de trafiquer en mémoire le programme, voire le compilateur, n'est pas la bonne,
car si tu changes de modèle d'ordinateur, tout est à refaire.

[Xavier31]

Recompiler était très fréquent dans la mouvance unix d'origine. Si j'ai bon souvenir, durant mes études, il me semble qu'il y avaient des gros classeurs avec le code source des OS achetés à l'époque (je ne serais pas surpris s'ils aient du aussi le compiler pour l'installer).

Oui, mais la différence, c'est qu'en C tu ne recompiles que si tu es programmeur. Car tes programmes peuvent s'exécuter
sans avoir un compilateur C sur la machine. Et aucune compilation n'est à faire par l'utilisateur. C'est cool!

Ta voisine madame Michu ne recompile pas ses programmes en C. Ni monsieur Duchmol.
Les connaisseurs recompilent le source en C s'il est disponible, les autres se contentent de lancer ou d'installer des programmes.

Idem en Turbo-Pascal. Seuls les programmeurs recompilent les .PAS s'ils les ont, l'utilisateur lambda se contente
de lancer un programme .com ou .exe sans même savoir s'il a été écrit en langage machine ou en Turbo-Pascal.

Bref, on diffuse le programme compilé propriétaire ou le programme en open-source avec son code source, c'est au choix.

Sur FORTH, tu n'as le choix QUE de diffuser ton code source, et l'utilisateur doit en plus posséder une copie du langage FORTH
sur sa machine. PAS pratique du tout...

Ceci dit, j'aime beaucoup ce langage ésotérique pour ses autre aspects, ne nous méprenons pas...
Par exemple, quand il s'agit s'écrire ses propres instructions (mots-Forth) et de se fabriquer un langage sur mesure,
là il est fabuleux. (Ceux qui ont essayé de créer leur propres instructions en BASIC par le langage machine me comprendront).

[fneck]

- Prends CP/M. (un Amstrad CPC, un MSX 2, un Osborne 1, bref n'importe quel ordi faisant tourner CP/M)

J'ai quand même l'impression qu'il y a un quelques raccourcis dans ce que tu dis Xavier. L'exemple de CP/M est bon, car ce qui fait la portabilité d'une machine à une autre dans ce cas c'est bien CP/M. Un programme développé pour un Osborne ne tournera pas sur un Amstrad... sauf si tu as chargé préalablement CP/M, c'est lui le programme commun.

Turbo Pascal est portable sur tout PC sous Ms-DOS, le .COM généré placé dans un Amstrad ne fera jamais rien, sauf évidemment s'il s'agit d'un PC. Dans ces deux cas, reprend-moi si je me trompe, c'est l'OS qui assure la portabilité car au final ce n'est jamais qu'une même famille de machines pas si différentes.

[Dominique]

Sauf, que ça n'existe pas! Je ne connais aucun moyen permettant d'exécuter un programme quel que soit le système d'exploitation. Pour la simple raison que les CPU diffèrent (Motorola, Intel, MIPS, Zilog, Sparc, PowerPC, ...) et que les façons d'accéder aux périphériques ne sont pas standardisées.
.......
Ce que tu demandes au Forth n'a jamais existé et n'existe nulle part. (De plus, je vois que vos programmes Forth sont truffés de langage machine, absolument pas portable...).

Je pense qu'ici tout est dit .

[__sam__]

Sur FORTH, tu n'as le choix QUE de diffuser ton code source, et l'utilisateur doit en plus posséder une copie du langage FORTH
sur sa machine. PAS pratique du tout...

Oui oui tout à fait. Les langages dans lequel les programmes ne peuvent être fournis que sous forme de source sont nombreux: BASIC, LISP, PROLOG, PHP, PYTHON, PERL, TCL/TK, JAVASCRIPT, MATLAB etc.. Alors pratique ou pas, chacun voit midi à sa porte, mais il doit y avoir de bonnes raisons pour que ce mode de diffusion des programmes ait subsisté jusqu'aujourd'hui.

Sinon, si on veut faire du C sur thomson, il n'y a pas de solutions native. Cependant le Forth peut nous venir en aide. En effet quelqu'un a débuté l'écriture d'un compilo de mini-C en forth. Je rêve qu'en prenant la même approche on puisse porter le Tiny C Compiler.

/!\ Dans Tiny C Compiler, le tiny c'est le compilo, pas le C. Tcc accepte tout le standard ANSI (et même plus), est compatible GCC et compile à la vitesse de la lumière.

Ah sinon il existe des compilateur commerciaux de C vers Forth : http://www.mpeforth.com/arena/C2ForthKit.120.zip. Décidément ils sont fou ces forçats du Forth.

[yo_fr]

Il existe des Forth "Stand-alone" qui permettent de se passer du langage pour être lancés. Bien évidement ils sont liés à la machine sur laquelle ils sont prévus... ForthOS est un exemple. Il y a quelque temps j'avais regardé un Forth IM-4 ou un truc comme cela, mais je ne le retrouve plus. Il permettait soit de passer par MS Dos soit carrément de s'en passer.
Par contre je ne pense pas que "l’exécutable" Forth ai un intérêt : de base c'est un langage de calcul pour scientifique (en remplacement du Fortran). La micro "grand public" des années 70 (fin) en a fait un langage de programmation à part entière, mais ce n'est pas sa vocation, il me semble.

PS : Il n'est pas obligatoire de transférer aux utilisateurs finaux le source Forth : une sauvegarde des mots compilés au sommet de la pile de mot Forth (après le dernier mot du langage Forth), et hop ! (c'est comme cela que sur l'Hector HRX / MX des programmes écris en Forth ont été distribués)
[EDIT] ça va mieux en le disant : il faut aussi sauvegarder et restituer les pointeurs de dico...

[Xavier31]

J'ai quand même l'impression qu'il y a un quelques raccourcis dans ce que tu dis Xavier. L'exemple de CP/M est bon, car ce qui fait la portabilité d'une machine à une autre dans ce cas c'est bien CP/M. Un programme développé pour un Osborne ne tournera pas sur un Amstrad... sauf si tu as chargé préalablement CP/M, c'est lui le programme commun.

C'est bien ça, c'est l'OS CP/M qui permet la portabilité. Un programme Osborne tournera effectivement sur un Amstrad CPC lorsque CP/M est chargé sur la machine (le CPC possédant 2 systèmes d'exploitation).

Mais le point que je soulignais, ce n'était pas tant la portabilité (elle vient de CP/M effectivement) mais le fait
qu'une fois que tu as crée ton programme .com en Turbo-Pascal, il tourne sur toutes les machines CP/M
sans qu'il y ait besoin de mettre le compilateur Turbo-Pascal sur aucune de ces machines.

C'est effectivement un mauvais exemple que j'ai donné car du coup on s'y perd un peu...

Turbo Pascal est portable sur tout PC sous Ms-DOS, le .COM généré placé dans un Amstrad ne fera jamais rien

Oui, tout à fait. Comme je l'ai dit précedemment, Il faut rester sur le même système d'exploitation.
Je parlais de CP/M dans mon exemple. Mais si tu veux qu'un programme Turbo-Pascal écrit sur un Amstrad CP/M tourne sur un PC avec MS-DOS, tu recompile le code source Pascal avec le Turbo-Pascal sous MS-DOS, et ça fonctionne.
(si on ne touche pas au hardware bien sûr).
Mais tu as raison, le .com compilé sur Amstrad lui ne fonctionnera pas sur un PC.

Dans ces deux cas, reprend-moi si je me trompe, c'est l'OS qui assure la portabilité car au final ce n'est jamais qu'une même famille de machine pas si différentes.

Une fois que les programmes sont écrit en binaire (compilés ou assemblés) effectivement, ce n'est plus portable d'un OS à l'autre.
Donc oui, c'est bien l'OS au final qui assure la portabilité.

Mais si on prend un code source FORTH sur un ordinateur est qu'on le recompile sur un autre (différent),
le programme fonctionnera. (à condition d'employer des mots-clés compatibles, cela va de soi)

Le problème de FORTH est qu'il ne sait PAS générer ce genre de fichier binaire. Avec lui, tu n'as qu'un code source
à recompiler chaque fois que tu veux charger et lancer ton programme.

Donc, moi qui voulait m'amuser à remettre FORTH au goût du jour en diffusant des applications que j'aurai crée sur PC,
je me retrouve limité. FORTH est un superbe langage. J'ai l'impression que cette fonctionnalité a été oubliée par son créateur.
Pourquoi diable n'y a t-il pas pensé ?

Car ne vous y trompez pas, les ordinateurs ne comprennent AUCUN langage de programmation!!!
à part le leur, le langage machine. Tout langage finira donc par traduire son code en opérations pour le microprocesseur.

Donc monsieur Chuck Moore, je pousse ma gueulante :
votre langage est super, il est rapide, il est concis et extensible. Il permet même la meta-compilation!
(un truc de fou qui permet au langage d'écrire son propre éditeur-compilateur... en FORTH!!)

Mais vous n'avez pas mis l'option de sauvegarder l'exécutable final binaire. Pas gentil ça!!!

[Xavier31]

Pour faire simple Fneck :

- Si je t'envoie un programme compilé en Turbo-Pascal (sur une machine avec le même OS) tu pourras l'exécuter.
même si tu ne possèdes pas Turbo-Pascal.

- Si nous avons toi et moi le même ordinateur et que je veux que tu testes mon programme écrit en FORTH :

si tu n'as pas le langage FORTH sur ta machine, tu ne pourras pas lancer mon programme.

Et en plus tu devras charger FORTH en mémoire, il faudra que je t'explique comment compiler, etc.

Donc c'est lourd, et pas pratique du tout. C'est dommage car FORTH est vraiment génial sur bien des points.

[__sam__]

Ce que cette discussion m'inspire (et que j'avais essayé de faire passer le long de ce fil, mais je suis peut-être allé trop vite) est qu'un exécutable 100% autonome n'existe pas. Il s'appuie toujours sur un environnement d'exécution. L'exemple du turbo pascal utilise implicitement le fait que l'environnement d'exécution est CP/M. Sur une même machine sans le CP/M de démarré, l’exécutable ne marche pas. Il n'est d'ailleurs pas vu comme quelque chose d'executable.

L'environnement d'exécution permet de lancer plusieurs taches, plusieurs programmes, avec différents arguments. Il gère l'allocation des ressources nécessaires à leur bonne exécution. Dit avec nos mots d'aujourd'hui (anglais), l'environnement d’exécution est un OS. CP/M est l'OS qui définit ce qu'est un programme ".EXE", comment il se charge, comment il se lance, comment il termine, comment il doit lire le clavier, ou accéder aux fichiers.

Pour revenir sur thomson, un TO7 par exemple: Qu'est ce qui défini la notion de tache/truc exécutable, qui sait l'exécuter, l'arrêter pour pouvoir lancer une autre tache? Qu'est ce que l'environnement d'execution du TO/7? qu'est ce qui joue le role du CP/M sur cette machine? Par défaut RIEN. Mais dans ce fil nous connaissons bien quelque chose qui définit ce qu'est un programme, qui est capable de le lancer et obtenir un résultat, puis en relancer un autre, bref qui s'apparente à ce que fait un OS. L'outil FORTH de loriciel? OUI L'outil de loriciel n'est rien d'autre que système capable d'exploiter les programmes FORTH.

Lidée que j'essaye de faire apparaitre est qu'outre le fait d'être un langage, FORTH est aussi un système d'exploitation. Il tient le rôle du CP/M faisant tourner les programmes compilés pour lui.

Bref, si on voit plus loin que le langage (sa syntaxe, sa sémantique) et qu'on se fait à l'idée que FORTH est un système d'exploitation (il gère la mémoire, défini la notion de taches, peut en exécuter à la file avec un nombre variable d'argument), alors il n'y a plus de problème avec la notion d’exécutable natif manquant en FORTH. L’exécutable natif est soit un source FORTH soit sa version compilé en mémoire. Cela explique probablement pourquoi le concepteur n'a pas eu besoin de créer une fonction d'export vers un autre système. FORTH se suffit à lui même.

En fait, FORTH est même un OS génial. Il occupe très peu de mémoire. Il tourne sur pleins de machine. Il fut même multitâche avant que bien d'autre OS essaye de l'être, et cela sur des CPU non conçus pour ca. Bref, c'est bluffant d'avoir atteint un tel degré de maturité dans un OS dès 1970 alors que d'autres, plus connus des médias (Billou?), n'attendront que l'approche de l'an 2000 (25 ans après) pour remplacer leur (MS-D)OS limité par un OS nouvelle techno capable, enfin, de faire du multitâche multi-utilisateurs a peu près correctement.

A+

sam (oula, ce sujet me rend vraiment très bavard. Désolé si je radote. C'est l'âge )

[fneck]

Une question qui me vient à l'esprit pour alimenter le débat. Est-ce qu'une machine comme le Jupiter ACE, qui ne dispose par défaut que du Forth comme OS, pourrait exécuter directement un programme écrit sur une autre machine (à la condition bien sûr qu'on arrive à lui faire lire le dit programme, évidemment) ?