Bon j'en ai marre de vb c'est cool mais fo tj les dlls qui lourdes bon alors si kke avait une solution ...(blague debile du genre fait en delphi ou en c++ s'abstenir) et je veut une verritable solution, pas du genre :
ben tu bind ton fichier vb exe avec els dlls vb6 a l'aide d'un logiciel de bindage paske cte solution elle pese minimum 1Mo ce ki est un peu lourd sans compter le reste ...

C completement debile ta kestion.
Reflechi un peu si il y a des dll qui traine avec ton exe fait en VB , c'est que justement ton exe en a besoin. Comment tu veux faire autrement ? la vraiment je vois pas, a moins que tu re developpe a ta sauce Visual Basic ...
 
Et j'ajouterai de plus que effectivement , un programme fait en Delphi et encore mieux en C/C++ ne posera plus ce pb des dlls de merd.. Alors au lieu de chercher des solutions a un pb ki n'en a pas, tu ferai mieux d'apprendre le C/C++...
 
Br@scoo

effectivement, tu peux pas créer un .exe en VB qui n'utilisera pas les DLL de VB    
(vbrun.dll" je crois)
 
et si tu veux ne pas avoir de dll requis avec ton programme, change de langage de programmation  

ya que vbrun, ta aussi plein d'autre truc a la con qui fond 1Mo.
pas cool pour distrib ca  
 
C++ rulleeeeeeeeeeeeeeeeeeeeeeeeeeeeezzzzzzzzzzzzzzz

Evidemment a par que apprendre le c++ tout seul ca peut etre vachement long et j'ai pas que ca a faire ce ki serai bien c au moin un compilateur avec l'option integre les dlls vb6

Avec Microsoft Visual Basic 6 tu peux integrer toutes les dll dont tu as besoin (avec l'editeur de ressources) pour ke ton programme tourne tout seul ...
Mais bon ... cette solution n'est pas top puisque ton programme va prendre bcp de poids d'un coup ... tu peux atteindre plusieurs Mo !!

le probleme viens du fais qu'il me semble que basic est un language interpreter, et non compiler (contrairement au C).. donc le .exe generer n'est pas exploitable comme tel, et abesoin de vbrun60.exe pour 'se faire interpreter', 'est pour ca qu'une application ecrite en VB est bien plus lente qu'une en C ou autre.. depassé la 20taine de forms.. ca commence a ramer a mort
 
Quand a la solution 'integrer les Dll dans l'exe.. quel interet, car il integre toute la dll, et donc tu alourdi ton progrmme pour rien, sans jamais opuvoir te debarasser de vbrun**.dll

[edit]--Message édité par trictrac--[/edit]

Depuis VB5 & 6, VB n'est plus interprété (contrairement à avant).
Il est bien compilé en code natif, mais tout ce code natif repose sur un RunTime (Une machine virtuelle comme pour Java)
Exemple, pour créer une fenêtre, il utilise les fonctions précompilées (et normalement sécurisées) du VBRuntime.
 
La seule solution, c'est effectivement le C++ (ou autre du même type)
 
NOTE : Pour des raisons d'interopérabilité, la tendance actuelle (du moins chez Microsoft), c'est de tout faire reposer sur un runtime (cf. .Net Framework). Même VisualC++.Net exploite un Runtime QUI FAIT PLUS DE 100 Megs
(On peut bien entendu travailler en prog Win32 classique, mais la brêche est ouverte)
 
Alors désolé pour les anti-machine virtuelle, mais c'est mal barré pour vous les gars )

tu es sur de ce que tu dis en ce qui concerne le fait que VB ne soit plus interprter, car j'ai un bouquin pour VB6 qui dit que vb est interpreter, et que c'est a ca que sert vbrun**.dll : a pouvoir interpreter un programme sans avoir besoin de VB.
Et s'il faut le compiler en .exe, c'est effectivement pour le metre en code natif.. mais uniquement pour que le systeme puisse le lancer et sache que c'est un exe.... mais il fait ensuite appel a la dll pour exploiter tout le reste du code, a savoir toutes les fonctions que tu as ecrites

tu l'as eu où ce bouquin ?
VB5 + 6 ne sont plus interprétés, c'est une certitude ... les dll gerent contiennent tout plein de fonctions (convertion, gestion fenetres + fichiers ...) et donc quand tu fais un open il va utiliser sa dll de m***e pour ouvrir le fichier mais si tu fais un for bidule next ca sera du vrai code executé ...
 
j'aimerais savoir moi : quand il se produit une erreur genre "fichier deja ouvert", bref une erreur fatale, c'est la dll qui gere ca ou l'exe ?

La runtime principale s'appelle MSVBVM60.dll (MSVBVM50.dll pour VB5) qui signifie MicroSoft Visual Basic Virtual Machine. A mon avis c'est interprété ...

Je développe sur VB depuis la version 3.0, depuis la 5.0 VB est COMPILE ! Content ou pas, c'est un fait, j'ajouterais comme information que le compilateur est le meme (ou presque) que celui de visual c++, il convertit au vole (Smart Linking) les données, tokens, bytes et aures joyeusetées. Le bouquin que tu as lu est a jeter tout simplement. D'ou je tient mes propors ? de la msdn (avril 2000), qui explique clairement ce qu'est le P-Code (option de compilation natif pour VB entre autre).
 
Kyle>Visual C++ a besoin de Msvcirt.dll (Microsoft visualC++ Reuntime Librairie), le C++ est il interprete pour auant ?

d'apres mon bouquin mon bouquin: vb6 chez Sybex:
microsoft proclame que vb poduit du code natif [...] mais la realite est bien moins enthousiasmante
 
Karl> "[...] les programmes ainsi obtenus sont plus rapides que leur PREDECESSEURS, compiles eux en P-Code ..."
 
Donc pas de P-Code a la compilation... mais la presence d'une VM implique la presence d'un programme non executable directement sur le systeme (sans doute interpreter, j'insiste et je signe) tout comme java. En revanche, Msvcirt.dll n'a rien d'une VM, mais contient des fonctions que VC++ niclut tout seul dans le code, et qu'il doit bien aller chercher qqpart sans alourdir chaque programme.

chope WinDASM et dessassemble un programme VB, tu vas voir s'il est interprete.
interpretation = perte de temps enOrme.
d'ailleurs, lors ds comparaisons VB3 avec Delphi, le 2° etait 20 fois plus rapide que le 1°
donc ben microsoft ils se sont dit "Ouh la, faut p'tet faire qq chose" et les prog VB ne sont plus interpretes.
je pense que ton bouquin veut dire que le code généré par VB est truffé (j'ai déssassemblé et constaté) d'appels à la dll.
mais je pense pas que ces appels ralentissent.
ces dll contiennent un max de fonction, tout comme ces fonctions seraient dans ton exe dans le cas du C si tu utilisait printf ou autre.
sauf que la ben printf il est dans le dll.
une ligne du genre open "fichier"  genere plein d'appels à la dll : car "fichier" n'est pas un chemin valide et VB va faire plein de manip sur ta chaine ...
ou alors UnEntier = val(UneString) va aussi générer plein d'appels à la dll pour convertir etc ...
 
"mais la presence d'une VM implique la presence d'un programme non executable directement sur le systeme (sans doute interpreter, j'insiste et je signe) tout comme java"
ben oui, si ta pas ta dll, ton programme il est pas executable
mais tu as bien un exe autonome, qui utilise les fonctions mises à disposition par la dll ...
 
enfin, je commence à n'etre plus sûr de rien ...
 
par contre si qq'un pouvais répondre à ma question concernat la gestion des erreurs ...

par defaut, c'est la dll qui gere ca, a moins que tu intercepte l'erreur, auquel cas la dll renvoie le traitement de l'erreur vers ton programme.. si j'ai bien compris ce que tu demande