# RealBasic, ca compile???



## SuperCed (11 Septembre 2001)

RealBasic, ca genere du code compile ou interprete???


----------



## simon (11 Septembre 2001)

Avec RealBasic tu peux créer des applications directement pour OS 9.x, OS X et Windows. Cela génére un executable...si je ne fais pas d'erreur mais cela fait un ptit bout de temps que je n'ai pas utilisé la chose...


----------



## SuperCed (12 Septembre 2001)

Je sais que ca genere un executable, mais il peut tres bien y avoir un runtime dedant... Donc ca ne m'aide pas a savoir si RealBasic compile ou pas.


----------



## Hurrican (13 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*Je sais que ca genere un executable, mais il peut tres bien y avoir un runtime dedant... Donc ca ne m'aide pas a savoir si RealBasic compile ou pas.*<HR></BLOCKQUOTE>

Si c'est un éxécutable (et RB en génére ...), c'est que le code est compilé. Le runtime n'a rien à voir avec çà.
Ta question est donc plutôt, RealBasic génére t'il un code libre, ou est t-il lié à une licence... 
La réponse est simple, il n'existe quasiment plus de langages imposant l'achat d'une licence pour l'éxécution du code. RB n'échappe pas à la règle.
En revanche, et comme la plupart des autres Basic, C, Java ..., il est nécessaire de joindre à l'éxécutable, les bibliothèques de fonctions qui permettent l'éxécution correcte du code, surtout si tu désires que le code tourne également sur plate-forme Windows. 
Résumé : Les programmes écrits en RealBasic sont libres de droits, et leur distribution est donc libre. Seul l'auteur a des droits sur ce code généré.


----------



## SuperCed (13 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
*

Si c'est un éxécutable (et RB en génére ...), c'est que le code est compilé. Le runtime n'a rien à voir avec çà.
Ta question est donc plutôt, RealBasic génére t'il un code libre, ou est t-il lié à une licence...
La réponse est simple, il n'existe quasiment plus de langages imposant l'achat d'une licence pour l'éxécution du code. RB n'échappe pas à la règle.
En revanche, et comme la plupart des autres Basic, C, Java ..., il est nécessaire de joindre à l'éxécutable, les bibliothèques de fonctions qui permettent l'éxécution correcte du code, surtout si tu désires que le code tourne également sur plate-forme Windows.
Résumé : Les programmes écrits en RealBasic sont libres de droits, et leur distribution est donc libre. Seul l'auteur a des droits sur ce code généré.*<HR></BLOCKQUOTE>


Non, un executable ne veut pas forcement dire que le code est compilé. Je te donne un exemple, Director cree des executable, mais pourtant, le code n'est pas compile, il est interprete. Ce qui le rend plus lent.
Le code compile, s'est de l'assembleur. Director ne genere pas de l'assembleur mais un fichier binaire que le runtime interprete comme il veut. C'est comme si c'etait du Java, sauf que la machine virtuelle est inclue dans l'executable.
Tu vois la difference?


----------



## jduffas (13 Septembre 2001)

et qu'en est il de Java sous os X ?

est il compilé ou interpreté, ...ou bien un peu des deux ?

et si java est toujours interprete, 
son integration dans les couches basses du systeme, permet elle une rapidité equivalente entre un programme ecrit en objective C et un programme ecrit en java ?


----------



## Hurrican (13 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*Non, un executable ne veut pas forcement dire que le code est compilé. Je te donne un exemple, Director cree des executable, mais pourtant, le code n'est pas compile, il est interprete. *<HR></BLOCKQUOTE>

Tu ne connais pas la définition d'un exécutable ... Il s'agit forcément d'un programme compilé (C, Basic, Java, Cobol, ...) ou assemblé (assembleur ...). A ne pas confondre avec un 'script éxécutable' (Director ...) par exemple. Quand le mot 'éxécutable' est indiqué seul, il veut dire 'programme objet'.


----------



## SuperCed (13 Septembre 2001)

ok, j'avais alors une mauvaise definition du mot executable. Je vais verifier ce que tu me dis quand meme... on sait jamais...
Je pensais qu'un executable etait seulement un programme qui se lancait quand on double cliquait dessus.


----------



## SuperCed (13 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par jduffas:
*et qu'en est il de Java sous os X ?

est il compilé ou interpreté, ...ou bien un peu des deux ?

et si java est toujours interprete,
son integration dans les couches basses du systeme, permet elle une rapidité equivalente entre un programme ecrit en objective C et un programme ecrit en java ?*<HR></BLOCKQUOTE>

Java, c'est toujours du code interprete, a part sur quelques prototypes de Sun... Je ne sais pas si objective C est compile ou interprete, mais je pense qu'il est compile. C'est a verifie. Si je suis dans le vrai, il y a des fortes chances pour que le code Java soit plus lent que le code ObjectiveC, a moins que le compilateur Objective C soit tres mauvais...


----------



## Hurrican (13 Septembre 2001)

Pour l'éxécutable tu peux me faire confiance, je suis ingénieur/chef de projet, et je développe depuis 1985 ...
Tu as tort également de croire que Java est toujours interprêté. Java se compile également. Il existe plusieurs types de compilateurs d'ailleurs. Les JIT (Just In Time) compilent à la volée, au moment de l'éxécution. Mais il existe aussi des compilateurs, qui crée des éxécutables au sens propre du terme. Il ne reste plus alors qu'à livrer l'objet, ses classes, ses beans, ... pour pouvoir l'éxécuter.
En revanche tu as raison sur la vitesse. Java n'est pas un foudre de guerre, même s'il a fait des progrès notables. En mode interprêté ou en JIT, il n'a vraiment aucune chance de toute façon ...


----------



## SuperCed (13 Septembre 2001)

Interprete


----------



## SuperCed (14 Septembre 2001)

Oui, c'est vrai, Java peut etre compile a la vole, j'avais oublie cela. Par contre, je savais pas qu'il pouvait etre compile totalement, comme du C.


----------



## jduffas (14 Septembre 2001)

et justement, qu'en est il dans OS X ?


----------



## Cocoa (14 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*Oui, c'est vrai, Java peut etre compile a la vole, j'avais oublie cela. Par contre, je savais pas qu'il pouvait etre compile totalement, comme du C.*<HR></BLOCKQUOTE>

Faux. Java n'est pas et ne sera pas compilé totalement comme du C. Cela voudrait dire que l'executable qui résulterait de la compilation serait du code machine donc directement comprehensible par le processeur. Ce n'est pas le cas puisque Java necessite une JVM. 

Pour ce qui est de RealBasic. Je suis quasiment certain que l'executable qui resulte de la compilation de ton projet est en fait un "run-time" qui compile ton code à son execution. 90 % certain.


----------



## SuperCed (14 Septembre 2001)

Pour Java, si, il existe justement des compilo qui transforme ton code Java en assembleur, et la, pas besoin de VM.
Pour RealBasic, tu crois vraiment qu'il s'agit d'un compilateur a la vole??? Moi j'aurais pas pense a ca, j'aurais pense que soit, c'etait compile, soit le runtime interpretait les commandes du script RealBasic. Ca me semble bizare qu'ils aient fait un compilateur a la vole vu la difficulte de realisation de ce genre de programme. Pourquoi se seraient-ils embetes a faire ca?


----------



## Cocoa (14 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*Pour Java, si, il existe justement des compilo qui transforme ton code Java en assembleur, et la, pas besoin de VM.*<HR></BLOCKQUOTE>

Désolé, mais j'ai du louper un épisode là ! 
La seule façon de faire de que tu dis, constituerait à implanter une "puce" java dans la machine (ce qui a été envisagé par Sun, mais jamais mis en oeuvre). 

Sinon point de salut. La particularité INTRINSEQUE de Java est d'etre un langage interprété, c'est donc necessairement la JVM qui se charge de ça....Si tu doutes, tu as le site de sun 

 <BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Pour RealBasic, tu crois vraiment qu'il s'agit d'un compilateur a la vole??? Moi j'aurais pas pense a ca, j'aurais pense que soit, c'etait compile, soit le runtime interpretait les commandes du script RealBasic. Ca me semble bizare qu'ils aient fait un compilateur a la vole vu la difficulte de realisation de ce genre de programme. Pourquoi se seraient-ils embetes a faire ca?[/QB]<HR></BLOCKQUOTE>

C'est un runtime, c'est certain. Sinon le langage utilisé n'est pas du basic.


----------



## SuperCed (14 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Cocoa:
*

Alors si cela existe vraiment du java non-interpreté, cela retire d'une part sa capacité de portabilité, et d'autre part, ce n'est surement pas Sun qui supporte ça. Pour ce qui est de la puce, elle est effectivement operationnelle, mais n'est absolument pas distribuée sur des stations grand-public...Pour des raisons évidentes de stratégies de la part de Microsoft par exemple.....

Un runtime est fait pour compiler du code à la volée lors de son execution. En clair, la partie executable de ton application "realbasic" est en fait simplement composée du runtime (et eventuellement des composants compilés de l'interface, mais je n'en suis pas certain). Le code Basic lui sera inévitablement compilé seulement et imperativement lors de l'execution du run-time.*<HR></BLOCKQUOTE>


En effet, ca retire une part des capacites de portabilite. Il n'y a pas trop d'interet.
D'autre part, un runtime ne fait pas de compilation a la volee, il ne fait qu'interpreter. Renseigne toi la dessus, et reviens me voir sur le forum.
Certaines machines virtuelles Java interpretent le code, d'autres font une compilation a la volee ce qui les rendent plus rapide.
C'est comme un emulateur, il y en a 3 types :
ceux qui compilent directement, ceux qui interpretent, et ceux qui font une compilation a la volee. Ces derniers sont souvent les plus rapides, mais par contre, c'est beaucoup plus chaud a programmer.
Renseigne toi un peu la dessus, et fais moi un rapport detaille a ton retour. ;-)


----------



## Cocoa (14 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Cocoa:
*

Un runtime est fait pour compiler du code à la volée lors de son execution. En clair, la partie executable de ton application "realbasic" est en fait simplement composée du runtime (et eventuellement des composants compilés de l'interface, mais je n'en suis pas certain). Le code Basic lui sera inévitablement compilé seulement et imperativement lors de l'execution du run-time.*<HR></BLOCKQUOTE>

J'ai été visité le site de RealBasic...J'y avais pas mis le pied depuis des lustres...Il semble qu'officiellement sur la version 3.5, ils affirment que l'application resultant de la compilation soit integralement compilée sans "run-time". Cela me semble louche, car je ne vois pas techniquement comment ils peuvent faire.


----------



## Cocoa (14 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*En effet, ca retire une part des capacites de portabilite. Il n'y a pas trop d'interet.
D'autre part, un runtime ne fait pas de compilation a la volee, il ne fait qu'interpreter. Renseigne toi la dessus, et reviens me voir sur le forum.
Certaines machines virtuelles Java interpretent le code, d'autres font une compilation a la volee ce qui les rendent plus rapide.*<HR></BLOCKQUOTE>

Je récapitule sur ce débat interessant 

La JVM, inclue un JIT (Just In Time compiler). Le JIT est chargé de traduire le code JVM d'un classe directement en code natif, et ce dès la première utilisation d'une classe du programme. 

Cette phase de "traduction" prend certes un peu de temps, mais une fois celle-ci effectuée, et ce jusqu'à la fin de l'exécution du programme, plus aucune traduction de code (sur la classe considéré) ne sera refaite (ce sont tes fichiers .class que tu retrouves apres un javac sous le terminal). Cette technique améliore considérablement la rapidité d'exécution des programmes, bien qu'une phase de traduction persiste. 

 <BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>*C'est comme un emulateur, il y en a 3 types :
ceux qui compilent directement, ceux qui interpretent, et ceux qui font une compilation a la volee. Ces derniers sont souvent les plus rapides, mais par contre, c'est beaucoup plus chaud a programmer.
Renseigne toi un peu la dessus, et fais moi un rapport detaille a ton retour. ;-)*<HR></BLOCKQUOTE>


J'ai pas bien compris le rapport entre un émulateur et une compilation de code


----------



## SuperCed (14 Septembre 2001)

eh bien, un emulateur lit un langage. Un compilateur et un interpreteur aussi, ca marche de la meme facon. Tu as deja etudie la theorie du langage?


----------



## Hurrican (14 Septembre 2001)

Dis Cocoa tu programmes depuis combien de temps ?
Ca fait belle lurette que les Basic interprêtés se font rares ... Ils sont compilés à 95 % (VB, RealBasic, Blitz, ...) et ce depuis la fin des années 80, début 90 avec les TurboBasic, QuickBasic et autres GfaBasic ... J'ai compilé mon premier programme Basic (du Gfa) en 89 sur mon Amiga !

Les Java compilés existent également ... et essentiellement sur plate-forme Windows ... vu que le standard c'est eux, la portabilité ils s'en fichent comme de leur première chemise ! C'est entre autre pour çà que Sun à mis Microsoft devant les tribunaux (et a gagné), parce qu'il étaient en train de faire une version Java spécifiquement Windows (et appartenant alors à Microsoft) ...


----------



## Cocoa (15 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
*Dis Cocoa tu programmes depuis combien de temps ?*<HR></BLOCKQUOTE>

1985 sur mon amiga également. A l'epoque c'etait en assembleur que je faisais mes premieres conneries.

  <BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>*Ca fait belle lurette que les Basic interprêtés se font rares ... Ils sont compilés à 95 % (VB, RealBasic, Blitz, ...) et ce depuis la fin des années 80, début 90 avec les TurboBasic, QuickBasic et autres GfaBasic ... J'ai compilé mon premier programme Basic (du Gfa) en 89 sur mon Amiga !*<HR></BLOCKQUOTE>

Je parlais specifiquement de RealBasic qui dans ses premieres moutures (j'en suis certain) faisait tourner ses projets compilés via un run-time.

  <BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>*Les Java compilés existent également ... et essentiellement sur plate-forme Windows ... vu que le standard c'est eux, la portabilité ils s'en fichent comme de leur première chemise ! C'est entre autre pour çà que Sun à mis Microsoft devant les tribunaux (et a gagné), parce qu'il étaient en train de faire une version Java spécifiquement Windows (et appartenant alors à Microsoft) ...*<HR></BLOCKQUOTE>

C'est ce que j'ai dit plus haut...Ca existe mais ce n'est pas un standard Sun....Et ce n'est pas non plus la "maniere" de faire des principaux RAD comme jbuilder ou IB/PB...

[14 septembre 2001 : message édité par Cocoa]


----------



## Hurrican (15 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Cocoa:
*89 sur Amiga ...*<HR></BLOCKQUOTE>

Décidemment !
Qui sur ces forums (à part les fondateurs), n'a jamais eu d'amiga ?
Faut faire un sondage !

Moi j'ai commencé en 1983 sur Zx81, puis sur Alice 90, puis Amiga 1000 (1986), Amiga 500 (1989) , Amiga 2000(1991), Amiga 1200 (1992)... iMac 350 (1999). Et je travaille sur minis et gros systèmes IBM ...


----------



## SuperCed (15 Septembre 2001)

Heu Cocoa, je comprends plus rien a ce que tu dis. J'ai du mal a te faire confiance...
Tu dis que RealBasic faisait tourner des projet compiler grace a un runtime??? Mais quand un projet est compile, ya pas besoin de runtime... Ou alors il est pas compile. C'est soit l'un, soit l'autre, mais les deux en meme temps, je crois vraiment pas que ca existe.

Pour l'Amiga, perso, j'ai pas connu, ca fait vieux quand meme ce truc la. Le premier que j'ai connu, c'est le Mac SE.


----------



## Cocoa (15 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
*

Décidemment !
Qui sur ces forums (à part les fondateurs), n'a jamais eu d'amiga ?
Faut faire un sondage !

Moi j'ai commencé en 1983 sur Zx81, puis sur Alice 90, puis Amiga 1000 (1986), Amiga 500 (1989) , Amiga 2000(1991), Amiga 1200 (1992)... iMac 350 (1999). Et je travaille sur minis et gros systèmes IBM ...*<HR></BLOCKQUOTE>

Ben grosso-modo, pour ma part ce fut Apple II en 80 je crois...Puis, la serie des TO/MO de Thomson, des Sinclair, Atari ST 520 et 1040, Commodore 64, Amiga 1000, 500, 600, Mac II, LC, Powermac 6100/66, et en ce moment PowerMac bleu...

Et je les possede encore tous...


----------



## Cocoa (15 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*Heu Cocoa, je comprends plus rien a ce que tu dis. J'ai du mal a te faire confiance...
Tu dis que RealBasic faisait tourner des projet compiler grace a un runtime??? Mais quand un projet est compile, ya pas besoin de runtime... Ou alors il est pas compile. C'est soit l'un, soit l'autre, mais les deux en meme temps, je crois vraiment pas que ca existe.

Pour l'Amiga, perso, j'ai pas connu, ca fait vieux quand meme ce truc la. Le premier que j'ai connu, c'est le Mac SE.*<HR></BLOCKQUOTE>

Bon je recommence plus clairement. Dans les versions precedentes de RealBasic quand tu selectionnais la fonction "compiler" pour compiler ton projet, il etait crée une application à part entiere. Nous sommes d'accord jusque là. 

Dans cette application, etait encapsulé d'une part, les ressources relatives à l'interface (comme tout appli classique) et son run-time qui se chargeait de traduire le code RealBasic (lui aussi stocké d'une facon ou d'une autre dans l'appli) en langage machine. D'ou la relative lenteur des applis RealBasic de l'epoque (ex ; Prestissimo, petit utilitaire de modifs d'interface). Aujourd'hui je n'ai pas essayé ni Realbasic, ni des applis developpées avec lui...


----------



## SuperCed (15 Septembre 2001)

Donc tu compilais pas ton projet...
En gros, la fonction d'appelait "Compiler" mais elle ne compilait pas.


----------



## Cocoa (15 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*Donc tu compilais pas ton projet...
En gros, la fonction d'appelait "Compiler" mais elle ne compilait pas.*<HR></BLOCKQUOTE>

Tu joues sur les mots là.


----------



## SuperCed (15 Septembre 2001)

Désolé, mais j'ai du louper un épisode là ! 
La seule façon de faire de que tu dis, constituerait à implanter une "puce" java dans la machine (ce qui a été envisagé par Sun, mais jamais mis en oeuvre). 

Sinon point de salut. La particularité INTRINSEQUE de Java est d'etre un langage interprété, c'est donc necessairement la JVM qui se charge de ça....Si tu doutes, tu as le site de sun 


Non, justement, ce n'est pas necessairement la JVM qui se charge de ca. Le Java peut etre compile pour les processeur Intel. C'est a dire qu'on trouve bien du code Intel dedant. Ok, ca enleve tout l'interet de Java, mais il faut savoir que ca existe. Pour le deuxieme point, la puce Java est totalement operationnelle, Sun possede des machines capables de comprendre directement le Java.

Pour l'histoire du runtime, je comprend pas vraiment ce que tu me dis, une fois tu me dis que c'est un runtime, l'autre fois, tu me dis qu'il s'agit d'un compilateur a la volee... Il y a une petite contradiction.
Explique toi mieux.


----------



## Cocoa (15 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>*Non, justement, ce n'est pas necessairement la JVM qui se charge de ca. Le Java peut etre compile pour les processeur Intel. C'est a dire qu'on trouve bien du code Intel dedant. Ok, ca enleve tout l'interet de Java, mais il faut savoir que ca existe. Pour le deuxieme point, la puce Java est totalement operationnelle, Sun possede des machines capables de comprendre directement le Java.

Pour l'histoire du runtime, je comprend pas vraiment ce que tu me dis, une fois tu me dis que c'est un runtime, l'autre fois, tu me dis qu'il s'agit d'un compilateur a la volee... Il y a une petite contradiction.
Explique toi mieux.*<HR></BLOCKQUOTE>

Alors si cela existe vraiment du java non-interpreté, cela retire d'une part sa capacité de portabilité, et d'autre part, ce n'est surement pas Sun qui supporte ça. Pour ce qui est de la puce, elle est effectivement operationnelle, mais n'est absolument pas distribuée sur des stations grand-public...Pour des raisons évidentes de stratégies de la part de Microsoft par exemple.....

Un runtime est fait pour compiler du code à la volée lors de son execution. En clair, la partie executable de ton application "realbasic" est en fait simplement composée du runtime (et eventuellement des composants compilés de l'interface, mais je n'en suis pas certain). Le code Basic lui sera inévitablement compilé seulement et imperativement lors de l'execution du run-time.


----------



## Membre supprimé 2 (18 Septembre 2001)

J'arrive un peu en retard, mais j'ai une hypothèse à poser:

D'après moi RealBasic compile réellement le projet et y rajoute un runtime (une sorte de bibliothèque de fonctions adaptée à l'utilisation que l'on en fait).
C'est d'après-moi comme des modules ou classes déjà compilés. Mais le code que tu programmes est bien compilé et fait appel aux fonctions présentes dans le runtime.
C'est pas facile à expliquer, ce truc. Mais sache que les 2 sont compilés et 1 fait appel à l'autre.

Par contre j'ai remarqué que depuis la version 3.2, la compilation est beacoup plus rapide et l'on ne voit plus de trace d'ajout de runtime dans la fenêtre de progression (est ce qu'ils ont réussi à intégrer les fonctions du runtime directement dans le projet ??)


En clair:
- Quand tu exécute le projet dans l'IDE de RealBasic, il est interprèté (ce qui explique qu'il est plus lent dans ce cas).
- Quand tu créé une application, il compile le projet.


C'est mon avis, mais je peux me tromper.  
	

	
	
		
		

		
		
	


	



J'utilise beaucoup RB pour mes besoins personnel et je suis son évolution d'alpha en béta et en version finale depuis la version 1. Et je suis d'accord pour dire que la 1ere version était sans doute interprété en grande partie.


----------



## SuperCed (18 Septembre 2001)

Bonne reponse, tres claire, je pense que tu as raison, ca me semble le plus probable.


----------



## Hurrican (18 Septembre 2001)

Un runtime, çà ne marche pas comme çà. Son but est d'obliger l'utilisateur à payer une licence pour faire tourner le programme.
- soit le programme objet ne peut s'éxécuter seul (c'est souvent le cas des premiers basic), et le runtime fournit une bibliothèque de fonctions. La différence avec ces dernières et alors infime, je l'avoue.
- soit le runtime est un simple verrou, qui s'il n'est pas présent empêche le code de s'exécuter.

Je ne connais pas les premières versions de RB, et peut être y avait il un runtime, mais depuis la version 2 au moins, tout est compilé et librement distribuable, le runtime est peut être toujours présent, mais alors il est inclus dans chaque compilation, ce qui me semblerait bizarre ... Pourquoi laisser un bout qui ne sert à rien ?
Il n'y a pas non plus d'interprétation (ce qui alourdirait considérablement RB et serait générateur d'erreurs), la compilation est également  effectuée dans l'éditeur, simplement une partie est faite "à la volée". La phase de contrôle est déroulée entièrement, puis les modules sont compilés lorsqu'ils sont appelés (d'où la différence de vitesse), ce qui permet d'éditer le code pendant l'éxécution. En revanche les modules ne sot pas linkés, les fonctions ne sont pas incluses, puisqu'il ne génère pas l'objet.


----------



## Membre supprimé 2 (19 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
*Un runtime, çà ne marche pas comme çà. Son but est d'obliger l'utilisateur à payer une licence pour faire tourner le programme.*<HR></BLOCKQUOTE>

Excuse ma brutalitée, mais tu fais fausse route !
Si tu ne sais pas ce qu'est un runtime, alors ne dit pas de conneries.

Un runtime peut très bien être séparé du fichier à exécuter, comme il peut y être intégré. Cela n'a rien à voir avec les licences !

Pour donner un exemple:
HyperCard servait de runtime aux "piles". Mais on pouvait très bien créer une pile autonome et dans ce cas le code de HyperCard était intégré à la pile.
(Je ne sais pas si tu a connu cette époque, en tout cas c'est le meilleur exemple que je peux te donner.)


----------



## SuperCed (19 Septembre 2001)

Kris a tout a fait raison, le Runtime peut tres bien etre integre dans le programme. Sous Director, c'est pareil, soit tu utilises le Runtime Sockwave qui est externe, soit tu fais un programme qui contient le runtime et qui interprete un script, lui aussi integre dans le programme final.
Ca remet un peu en question ta definition de l'executable dont tu etais si certain...
Pour toi, Kris, c'est quoi un executable?


----------



## Membre supprimé 2 (19 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
*mais depuis la version 2 au moins, tout est compilé et librement distribuable, le runtime est peut être toujours présent, mais alors il est inclus dans chaque compilation, ce qui me semblerait bizarre ... Pourquoi laisser un bout qui ne sert à rien ?*<HR></BLOCKQUOTE>

Qui te dit qu'il ne sert à rien !!!
Pourquoi répéter le code qui fait peut-etre des dizaines de lignes à chaque fois que l'on a besoin ?
Le runtime est toujours nécessaire à RB sinon il devrait adapter les fonctions à chaque cas précis ce qui est impossible.


----------



## Membre supprimé 2 (19 Septembre 2001)

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
*Pour toi, Kris, c'est quoi un executable?*<HR></BLOCKQUOTE>

Un executable, c'est une application.
Pour être plus précis: C'est tout fichiers qui contient le code nécéssaire pour se lancer de manière autonome après un doubleclick sur son icône.
Bref, c'est l'inverse d'un document.

Pour revenir sur mon exemple d'avant:
- Une pile HyperCard est un document.
- L'application HyperCard est un executable.
- Une pile autonome (avec runtime intégré) est un executable.


----------



## SuperCed (19 Septembre 2001)

C'est bien ce qu'il me semblait mais on m'a dit le contraire sur ce forum...
Merci pour ces eclaircissements.


----------

