RENDRE LES EXE VB AUTONOME (SANS RUNTIME - MSVBVM60.DLL, VB6FR.DLL)
cs_khalilo
Messages postés
71
Date d'inscription
jeudi 17 janvier 2002
Statut
Membre
Dernière intervention
12 mai 2004
-
3 juin 2002 à 21:38
veloce35 Messages postés 27 Date d'inscription jeudi 2 octobre 2003 Statut Membre Dernière intervention 18 avril 2010 - 18 avril 2010 à 09:40
veloce35 Messages postés 27 Date d'inscription jeudi 2 octobre 2003 Statut Membre Dernière intervention 18 avril 2010 - 18 avril 2010 à 09:40
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/1502-rendre-les-exe-vb-autonome-sans-runtime-msvbvm60-dll-vb6fr-dll
https://codes-sources.commentcamarche.net/source/1502-rendre-les-exe-vb-autonome-sans-runtime-msvbvm60-dll-vb6fr-dll
18 avril 2010 à 09:40
C:\moi\C_Runner_VB.exe pour que cela fonctionne sinon Erreur chemin d'accés introuvable.
10/10
veloce35
16 févr. 2007 à 10:14
24 janv. 2007 à 20:19
> Chemin relatif
> ...
12 juil. 2006 à 02:02
http://www.codyx.org/snippet_variables-environnement_161.aspx
12 juil. 2006 à 01:59
Pour avoir la lettre du disque sur lequel est installé le systeme, tu peux faire Environ("HOMEDRIVE")
Les variables d'environnement c'est bien pratique quand on veut faire rapide.
Je te renvois à un code qui permet de lister ces variables, ca peut toujours servir :)
11 juil. 2006 à 18:49
8 janv. 2006 à 07:15
7 nov. 2005 à 18:28
C loin tt ça!
merci kan meme pour la solution.
bonne continuation.
++
6 nov. 2005 à 21:25
Moi aussi j'ai le même problème j'ai regardé le code source l'érreur vient de là:
newfich = "C:\Windows\Bureau\C_Runner_VB.exe" 'ON EST OBLIGE DE METTRE TON PROG DANS C:\WINDOWS\BUREAU POUR QUE CA MARCHE SINON
nom_Cprog = "C_Runner_VB.exe"
nom_dll1 = "Msvbvm60.dll"
nom_dll2 = "Vb6fr.dll"
nom_exe = Dir.Path & "" & File.FileName
'nom = File.FileName
Open newfich For Binary As #1'CA PLANTE ICI CAR VB NE TROUVE PAS TON PROG là où IL LE CHERCHE.
Open nom_Cprog For Binary As #2
Open nom_dll1 For Binary As #3
Open nom_dll2 For Binary As #4
Open nom_exe For Binary As #5
Voilà pour l'explication donc soit vous mettez son prog dans c:\windows\bureau même si vous avez xp ;-) soit vous modifiez le chemin d'accès dans le code source.
14 sept. 2004 à 18:05
14 sept. 2004 à 17:41
23 juil. 2004 à 19:35
DamienI > pour recuperer le chemin du rep temporaire on peux faire ca en une ligne sans declarer d'API et compatible Win9x & 2000/XP :
RepertoireTemporaire=Environ$("TEMP")
Pour ce qui est du titre il TOTALEMENT FAUX !
UN PROG QUI REND VOS EXE VB AUTONOME ( SANS RUNTIME CAD NI MSVBVM60.DLL, NI VB6FR.DLL)
hmmm, il dépend TOUJOURS des runtimes puiske tu passe par un prog en C pour les mettre non ?
Donc Il dépends toujours des runtimes et en plus tu le fait dependre d'un autre programme qui sans lui il faudrais kan meme installer les runtimes VB
CQFD
Si tu veux faire un programme vraiement autonome n'utilise pas VB car c'est impossible sans accrochage. Ya bien des solution ki existent mais y a toujours dependance meme si c un joiner d'EXE ...
Une vrai solution SANS runtime n'est donc pas possible !
@++
17 juil. 2004 à 23:30
tu doit mettre
newfich="c:\windows\documents and settings\nom_de_ton_compte_XP\bureau\machinchose"
toujours est il que l idée est bonne mais moi aussi j ai un pb :
ca me créé bien le exe modifier sur le bureau mais oh surprise
qd je lance cet exe... il y a juste lancement du prog en cours
suivi d une fenetre dos (qui disparait aussi sec mais ca c est normal si je ne me trompe pas)
et puis.........plus rien
qd je vais voir dans le fichier temp j ai bien mes DLL qui ont ete decompresser
et aussi ce que je suppose etre sa copie de lui meme
par contre pour la copie de mon exe a moi je peut me brosser je ne l ai pas trouver.... :'( :'(
j ai aussi une deuxieme question a poser:
est ce que ce programme traque les *.OCX qui sont necessaire au bon fonctionnement de certain programme?
si ce n est pas le cas et que Damien I veut bien revenir sur sa programmation, alors il me semble que cela pourrait etre fort pratique/utile
quitte a ce que l utilisateur place lui meme les OCX dans un repertoire specifique pour qu il soit traiter par le programme..
enfin voila... sinon l idee est bonne a mon sens.. mais je n ai pu juger de la qualiter effective car je n ai pas reussi a faire fonctionner les appli transformer..
et... ayer pitier de moi: pardonner mes faute de francais... :') AdRieN
9 mai 2004 à 22:47
ou ton repertoire temp
moi ca marche j ai xp pro sp1
7 avril 2004 à 00:08
tres bon prog sauf que chez moi il ne fonctionne pas ! :(
au moment de l assemblage du nouvel exe j ai une erreur d'execution 76 : chemin d acces introuvable .
si quelqu un a un soluce ou si il a le mm prob qu il laisse un mess qu on en parle @+
20 janv. 2004 à 19:25
Pour ma part, j'utilisais un petit soft russe d'empaquetage, il code un exécutable indépendant qui décompresse tous les fichiers sélectionnés auparavant, *.ocx, *.dll, *.*.
Merci beaucoup d'avoir fait ce code, ça permet d'analyser un peu plus en profondeur le fonctionnement.
25 août 2003 à 16:43
il faut ouvrir le fichier Mainrun.cpp et modifier les lignes ou il y a la taille des DLL :
for (i=0; i<1384448; i++)
et
for (ii=0; ii<119568; ii++)
l'idéal serait que DamienI ou un autre bon en VC++ patch son C_Runner_VB.exe pour qu'il lise automatiquement la taille des 2 DLL, ou qu'il la demande à l'utilisateur...
(j'ai essayé mais y a une redefinition de ShellExecuteA et CopyFileA qui me bloque)
23 août 2003 à 20:35
j suis tres intersser a votre programme mais jarrivais jamais a voir un exe avec des dll inclus veuillez m 'eclairsir le chemain et essaye bien d me xpliquer comment ca marche ton program..je te remercier
salut..
5 mai 2003 à 15:36
je suis debutant en VB et j'aimerai savoir comment executer (la commande et les sources a telecharger pour l'execution) des sources VB sans que j'ai le KIT de VB.
merci d'avance pour votre aide
17 avril 2003 à 10:29
ptdr ;-)
31 janv. 2003 à 11:40
19 janv. 2003 à 16:32
1 janv. 2003 à 10:22
21 déc. 2002 à 23:15
6 déc. 2002 à 23:50
'pour toi moustachu et tt ceux qui veulent porter ma source ss XP,etc...
'pour le reste : le principe n'a pas changé et reste valable ss d'autres OS.
'++ et bonne prog à tous !!!
'API de Windows repertoire finder
Private Declare Function GetWindowsDirectory Lib "Kernel32" Alias "GetWindowsDirectoryA" (ByVal lpbuffer As String, ByVal nSize As Long) As Long
Public Function WinDir() As String
Temp$ = Space$(255)
X% = GetWindowsDirectory(Temp$, Len(Temp$))
WinDir = Left$(Temp$, X%)
5 déc. 2002 à 10:16
En tout cas l'idée est très bonne donc bonne note mais je ne sais pas si on peut récupérer le chemin système de windows
25 juil. 2002 à 13:49
Mais au niveau interface....Pas cool!
La fusion Vb/C est ce qui reste de plus performant mais le seul probleme etait les dll VB...
Résolu par ton Prog!
J'met dix pour l'utilisation de deux language totalement différent et pour l'innovation
lol
21 juin 2002 à 15:30
Sinon l'idée est très bonne mais t'aurais du faire ca pour un programme d'installation. On exécute pas des installations tout les jours (la plus-part des gens du moin lol)
8 juin 2002 à 17:01
J'espère avoir été clair : c'est pas facile en qq lignes...alors je résume :
Bref, autrement dit : on peut faire un prog qui contient:
1 - le prog C ( installe les 2 dll vb et le prog1 VB ) qui lance prog1 VB.
2 - un premier prog VB ( cad prog1 VB ) qui a pour objet d'installer les autres fichiers de dépendances ( ocx et dll ) et de les enregsitrer, mais qui installe aussi LE prog2 VB (qui a besoin des dites dépendances ) et le lance.
Encore autrement dit :
Le prog C : contient lui même et les deux dll et prog1 VB
Le prog1 VB : contient lui même, et contient le prog2 VB et les dll et ocx dont ce dernier a besoin.
On pourrait dire : une sorte de récursion, tt en répétant que seul le premier prog vb nécessite les deux dll vb fondamentales, c'est ça l'intérêt du prog C, de rendre le programmeur vb LIBRE de tout faire avec un seul fichier, car ça : VB NE LE PERMET MALHEUREUSEMENT PAS et c'est ça qui m'énervait ...
A++
DamienI
Bonne prog.....
5 juin 2002 à 10:35
Bref je cherche encore ou ca marche pas chez moi pour le "Assemblage auto des Runtimes dans un EXE VB" parsque ca m'interresse ce truc .. mais dommage qu'on ne puisse pas inclure les OCX a la difference de Fusion ...Mais DamienI , c'est quant meme pas mal , (l'ide surtout) moi j'aurais pas pu faire cette source :-(
5 juin 2002 à 02:12
10/10
4 juin 2002 à 15:07
4 juin 2002 à 13:55
Il n'est pas gratuit mais costaud (y a moyen de le trouver ailleurs...)!
Bonne programmation tout de même et l'idée est sympa.
4 juin 2002 à 13:54
1 - La possibilité de choisir une extraction dans le répertoire TMP (système) ou dans le rép de l'EXE. Et oui, certaines appli utilisent le App.Path qui est très utile.
2 - Idem pour le déchargement des DLL VB.
3 - Ben faut quand même supprimer les fichiers au déchargement de l'appli, sinon c'est caca. En tout cas si c'est dans le répertoire TMP c'est important.
Skrol29
4 juin 2002 à 13:25
Voyez le code et la lumière sera ! Bonne prog à tous : A++
PS : il est bien sur possible d'enlever la fenêtre C au démarrage, pour cela faut mofifier les paramètres dela wndclass et la rendre invisible, aibsi l'utilisateur ne vera pas le lanceur.
A++ DamienI
4 juin 2002 à 12:30
4 juin 2002 à 04:21
4 juin 2002 à 03:15
3 juin 2002 à 23:10
3 juin 2002 à 22:40
Est ce ke les progs en C sont automone?
3 juin 2002 à 21:38
@+