Dein Script baut die Verbindung meiner Meinung nach nicht auf.
Dachte ich ja auch, aber sieh selbst:
Ich vermute Folgendes:
Du arbeitest mit SQLite - und vor einiger Zeit wurde das SQLite-Include (SQLite.dll) aber von der AutoIt-Installation entfernt. (komplett bescheuert!!)
Dein Skript prüft mit dem vorhandenen SQLite-Include ob es lokal eien SQLite.dll findet, wenn nicht wird eine Internetverbindung aufgebaut und diese Dll vom AutoIt-Server heruntergeladen. Inwiefern das evtl. zusätzlichen Mailverkehr mit autoitscript.com anschiebt, kann ich nur raten.
In Projekten empfiehlt es sich immer, die SqLite.dll als eigene Datei mit in den Skriptpfad zu installieren z.B. mit FileInstall.
Startup muss dann so aussehen: _SQLite_Startup(@ScriptDir & "\sqlite3.dll", False, 1)
Vor einiger Zeit hatte ich die Dll auch mal als Binärdatei-Include erstellt (so, wie es früher von Haus aus war). Den Post finde ich gerade nicht, kannst ja mal suchen.
@UEZ, woher kommt der Codegenerator?
@UEZ, woher kommt der Codegenerator?
Guckst du hier: File to Base64 String Code Generator v1.20 Build 2015-01-20
Gruß,
UEZ
wenn nicht wird eine Internetverbindung aufgebaut und diese Dll vom AutoIt-Server heruntergeladen.
Was ziemlich unklug ist... zum einen dürften diverse Virenscanner Alarm schlagen wenn eine Software einfach mal so zur Laufzeit eine DLL aus dem Internet nachlädt, zum anderen ist das geradezu eine Einladung Schadsoftware auf den Servern von autoit.com zu platzieren.
Ich stimme dem Rat von Bugfix also zu, dass es sinnvoller ist die DLL selbst beizulegen. Nur so kann man sicherstellen, dass es sich um eine originale und unveränderte DLL handelt. Davon ab hat man so auch eine Garantie die richtige zur UDF passende Version der DLL zu nutzen.
Schadsoftware auf den Servern von autoit.com zu platzieren.
wie das denn?:D
bei mir baut keine getestete .exe eine verbindung zu mail.autoscript.com auf.
Kannst ja selber mal mit wireshark kucken was geladen wird
Ich hab das nicht selbst nachgeprüft und mich auf die Vermutung von Bugfix gestützt. Ich verwende auch noch eine alte Autoit Version und kann sowieso nichts zu den aktuellen Versionen sagen. Allerdings könnte ich mir bei der Kommunikation mit mail.autoitscript.com auch vorstellen, dass das lediglich in Alpha oder Beta Versionen von Autoit passiert. Aber auch das wäre nur eine Vermutung.
Noch mal zur Klarstellung:
Mit dem SQLite-Include findet ausschliesslich ein Download vom AutoIt-Server statt. Dazu wird die Adresse "http://www.autoitscript.com/autoit3/files/beta/autoit/archive/sqlite/" angewählt.
Dass im Protokoll als Gegenstelle "mail.autoitscript.com" auftaucht, ist evtl. auf einen Alias zurückzuführen (reine Vermutung).
Ja, diese Vorgehensweise ist m. M. nach dreist und frech. Diese Tatsache ist zwar in der Hilfe zu _SQLite_Startup erwähnt, sollte meines Erachtens aber fett und als Warnung dort hinterlegt werden. Wer möchte schon gern, dass sein Skript "nach Hause telefoniert". 
Ich habe letztens ein Tool für die Firma programmiert, wo ich eine MySQL Datenbank ausgelesen habe und mich wunderte, warum das Tool so unterschiedlich lange benötigt, bis es startet.
Grund war eben immer der Download der DLL.
Hier der Code aus SQLite.au3
[autoit]
Func __SQLite_Download_SQLite3File(ByRef $sFilePath, $sFileName, $sVersion, $sFileExt, $bDownload = False, $iScripLineNumber = @ScriptLineNumber)
Local $sRetFile = $sFileName & $sVersion & $sFileExt
Local $sTempfile = $sFilePath & $sRetFile
If $bDownload And FileExists($sTempfile) Then Return $sTempfile
Local $sURL = "http://www.autoitscript.com/autoit3/files/beta/autoit/archive/sqlite/"
Local $iInetRet = InetGet($sURL & $sRetFile, $sTempfile, $INET_FORCERELOAD)
Local $iError = @error
If @error And StringInStr($sTempfile, @SystemDir) Then
$sFilePath = @TempDir & "\"
$sTempfile = _TempFile(@TempDir, "~", ".dll")
_ArrayAdd($__g_aTempFiles_SQLite, $sTempfile)
OnAutoItExitRegister("_SQLite_Shutdown") ; in case the script exit without calling _SQLite_Shutdown()
$iInetRet = InetGet($sURL & $sRetFile, $sTempfile, $INET_FORCERELOAD)
$iError = @error
Local $iPos = StringInStr($sTempfile, "\", 0, -1)
$sRetFile = StringTrimLeft($sTempFile, $iPos)
EndIf
If $iError Then __SQLite_Print('@@ Debug(' & $iScripLineNumber & ') : __SQLite_Download_SQLite3File : $URL = ' & $sURL & $sFileName & $sFileExt & @CRLF & @TAB & '$sTempfile = ' & $sTempfile & @CRLF & '>Error: ' & $iError & @CRLF)
Local $sModifiedTime = Call('__SQLite_Inline_Modified')
If Not @error Then FileSetTime($sTempfile, $sModifiedTime, 0) ; update filetime if defined
Return SetError($iError, $iInetRet, $sRetFile)
EndFunc ;==>__SQLite_Download_SQLite3File
Am Besten die DLL in das Skript integrieren...
Gruß,
UEZ
Sollte man das mal im engl. Forum einwerfen um den Grund zu klären und ev. Abhilfe zu schaffen?
Dass im Protokoll als Gegenstelle "mail.autoitscript.com" auftaucht, ist evtl. auf einen Alias zurückzuführen (reine Vermutung).
Alias ist der falsche Begriff dafür. mail.autoitscript.com ist der Reverse DNS Eintrag für die Server IP auf der neben der Webseite autoitscript.com scheinbar auch noch ein Mail Server läuft. Da es für Mailserver wichtig ist einen korrekten Reverse DNS Eintrag zu haben wurde der wohl so gesetzt.
nslookup autoitscript.com
Name: autoitscript.com
Address: 87.106.181.57
nslookup 87.106.181.57
Name: mail.autoitscript.com
Address: 87.106.181.57Sprich wenn das Analysetool die IP mit der da kommuniziert wurde zurückauflöst wird es mail.autoitscript.com anzeigen, auch wenn es sich hier wohl dann wie vermutet nur um den Download der sqlite.DLL vom Webserver handelt und nicht um Emailkommunikation.
Mit welchem programm hast du das rausgefunden? wireshark ist es jedenfalls nicht oder gibt es eine neuere version?:D
lg Phil
Öffne doch einfach eine CMD Box und gibt Zeile 1 / 5 ein...
Gruß,
UEZ
Ich glaube er meinte den Screenshot von Post #3.
Sieht aus wie der Windows Ressourcenmonitor.
Gruß,
UEZ
Sieht aus wie der Windows Ressourcenmonitor.
Schaut nicht nur so aus, sondern ist er auch hehe.
