Création d'un executable avec vb6.0

ça passe en mode execution mais ce dont je parle c'est du fichier executable crée à partir du projet. C'est ce fichier qui sera utilisé pour faire l'empaquettage et le deploiement soit avec visual studio soit avec inno setup

ça passe en mode exécution
Avec Ctrl+F5 ????

Bonjour,

VB6 ne fait pas exécutables, c'est de l'interprété. Si VB6.0 cree des executables que vous pouvez empaqueter avec l'assistant d'empaquetage de VB6.0 ou avec InnoSetup.

A+

Bonjour,
@Celien : VB6 ne fait pas exécutables, c'est de l'interprété.
Quand ont ne sait pas de quoi ont parle ont s'abstient d'intervenir.

Je sais très bien de quoi je parles, ça n'est pas un vrai exécutable, c'est comme vous dites un empaquetage de votre appli plus un runtime. Voila une page écrite par une personne qui sais ce qu'est un runtime, et qui explique ce qu'il y à à savoir sur le runtime VB.

Pour info ce débat était monnaie courante il y à plusieurs années avec des fanboy VB6 qui essaient de faire croire que VB6 fait de vrais exécutables hors c'est faux.
Vous faites de vrais exécutables avec un compilo C++, C, ou Pascal, par exemple, mais pas du tout avec VB6. Si vous voulez faire un vrai exe avec du Microsoft alors vous utilisez Visual Studio et vous faites du C++, la vous avez un vrai exe.

La vérité est la "By default, applications created in Visual Basic are compiled as interpreted or p-code executables. At run time, the instructions in the executables are translated or interpreted by a run-time dynamic-link library (DLL)".

Bien que les programmes puissent être compilés en code natif depuis la version 5, ils requièrent toujours pour fonctionner la présence du moteur d'exécution ou runtime, pour une taille d'environ 2 MB. Ce moteur d'exécution est inclus par défaut dans Windows 2000 et versions supérieures, sous formes de bibliothèques dynamiques.

Le compilateur employé par Visual Basic est le même que celui d'autres langages fournis avec Visual Studio 6 (C, C++), mais des restrictions placées au niveau de l'environnement de développement intégré empêchent la génération de code particulier (DLL Windows ou Threads).

Dans les années 70/80 j'ai programmé avec du Basic interpréter et je peu t'assurer que ce n'est pas du tout, mais alors pas du tout la même chose. A cette époque il est vrai qu'il n'y avait que le C pour avoir un code compiler, j'ai d'ailleurs du y passer ainsi que de l'ASM pour des questions de rapidité d'exécution.
Alors quand tu viens me dire que VB6 est un langage interpréter.. laisse-moi rire.
EDIT : je viens de regarder le lien que tu communique, là aussi je dois rire, pourquoi installer tout les "RunTime" quand tu achetait une version (j'ai eu la 3 et la 6) le RunTime adéquoit est installer avec.
Si tu fait une application avec par exemple VB6 et que tu veux la publier et bien tu fait un Installe (Setup) qui se charge de mettre le (bon) RunTime sur le PC hôte, comme quoi.. faut lire AVANT.

Si VB6 t'apporte plus de satisfaction que les anciens basic interprété j'en suis content pour toi.

Mais plus sérieusement, si tu fais un benchmark entre de vrais compilateurs (VC++ ou Delphi par exemple) versus VB6 tu arrive à ce résultat, à savoir aucune comparaison possible, et que une application VB6 s'exécute même moins vite que Java.

A savoir que la sois disant "compilation native" est une invention Marketing destinée à vendre à l'époque des éditions Pro et Entreprise de VB6 plus chère mais que les benchmarks montrent que c'est que un argumentaire marketing. Un vrai compilateur n'a pas besoin d'un runtime.

Sur ce je rappelle que Microsoft à abandonné VB6, pour proposer maintenant VB.NET ou C#, et que microsoft à très bien optimisé son just in time compiler dotnet pour proposer une meilleure performance que VB6, exemple ici

Microsoft à même réussi à faire un just in time compiler Dotnet plus performance que celui de Java sous windows, donc somme toute une belle réussite.