socketfehler 10054 bei Mailversand

[Perlsau]

Ah, sorry, hatte überlesen, daß sich deine SSL-DLLs bereits im Programmverzeichnis befinden. Über den geposteten Link kommst du zu weiteren Threads über SLL mit den Indy-Komponenten.

Du könntest dennoch einmal versuchen, die SSL-DLLs nach C:\Windows\System32 zu kopieren, wo sich die allermeisten anderen DLLs tummeln. Daß es erst seit der SSL-Einbindung auf dem Tablet nicht funktioniert, besagt ja eindeutig, daß es damit zusammenhängt.

Übrigens: Was sind VCS-Dateien? Meinst du vielleicht CSV-Dateien?

Ich muß demnächst auch eine Anwendung auf SSL umstellen, da bin ich schon jetzt gespannt, ob das problemlos über die Bühne geht

[mkinzler]

Zitat:

Übrigens: Was sind VCS-Dateien?

Nein eine vCalendar Datei
http://de.wikipedia.org/wiki/VCalendar

[multipro]

Hallo,

ich versuche das mal mit dem System32-Verzeichnis. Allerdings habe ich das Tablet gerade nicht da.

Zu den vcs-Dateien:

Das sind Kalenderdateien für Microsoft-Outlook. Ich kann also die per Mail erhaltenen Dateien einfach öffnen und in meinem Outlook speichern. Damit kann ich jederzeit
nachvollziehen, wann ich bei welchem Kunden war.
Das Format ist zwar schon älter (wurde von iCalendar -> ICS abgelöst), funktioniert aber zumindest mit Outlook gut.

siehe auch hier: http://de.wikipedia.org/wiki/VCalendar

Mit freundlichen Grüßen
Multipro

[multipro]

Hallo,

es funktioniert.
Was habe ich getan:

-> Download des OpenSSL-Paketes von hier: http://www.heise.de/download (einfach nach OpenSSL suchen und das passende Paket downloaden)
-> Das Paket habe ich installiert und die DLL's nach Windows\system32 kopieren lassen. (Frage kommt während der Installation)
-> Funktionstest negativ (Fehler 10054)
-> Die "alten" OpenSSL-DLL's aus meinen Programmverzeichnis gelöscht
-> Funktionstest positiv (Mail wurde verschickt und ist auch angekommen)
-> Also war etwas mit den DLL's. Bleibt die Frage, warum es auf dem Notebook mit den "alten" DLL's funktioniert.
-> Es war in diesem Sinne also kein Delphi-Problem. Mein XE3 hatte ich während der ganzen Problembehandlungsphase nicht einmal gestartet.

Vielleicht als Ergänzung:
Auf dem Notebook funktioniert es immer, also:
alte DLL's im Programmverzeichnis
alte DLL's im windows\system32
neue DLL's im Prgrammverzeichnis
neue DLL's im windwos\system32
Ich habe auch darauf geachtet, immer nur eine DLL-Version an einer Stelle auf der PLatte zu haben.


schon komisch...

Aber trotzdem Vielen Dank für die Hilfe

Mit freundlichen Grüßen
Multipro

[Perlsau]

Na das ist ja mal eine erfreuliche Nachricht

Bist du sicher, daß auf deinem Entwickler-Rechner keine neueren SSL-DLLs im Windows-Verzeichnis waren? Es gibt ja eine Such-Reihenfolge, die kann wohl auch bei jedem Rechner unterschiedlich sein. Zuerst wird da wohl im Programmverzeichnis gesucht, danach vermutlich je nach Reihenfolge der Path-Einträge ... Ich würde mal das Tablet und deinen PC gründlich nach diesen SSL-Dateien suchen lassen, vielleicht findest du auf diese Weise ja doch noch heraus, weshalb genau es auf dem PC ging und auf dem Tablet nicht.

Daß du dir das neueste SSL gezogen hast, ist lobenswert und wichtig, denn erst kürzlich wurde ja diese SSL-Lücke Heartbleed aufgedeckt. Und es gibt scheinbar noch weitere Probleme mit SSL.

[multipro]

Hallo,

ich habe noch einmal nach den SSL-Dateien gesucht, ohne neues Ergebnis.
Ein Unterschied fällt mir aber noch ein:
Das Notebook wurde sofort mit Win8.1 installiert und das Tablet war original mit Win8.
Das habe ich erst über den Store auf 8.1 gebracht.
Die Theorie ist aber auch weit hergeholt. Ich nehme es halt so hin.

Mit freundlichen Grüßen
Multipro

[Sir Rufo]

Ich wette mal es lag an

Zitat:

benötigt Microsoft Visual C++ 2008 Redistributables

und auf einem 64bit System gehören 32bit DLLs nicht in "%systemroot%\system32" sondern in "%systemroot%\SysWOW64".