Klotzkopp

Vermutlich machst du immer noch etwas falsch. Ein etwas deutlicherer Hinweis: Wenn du konkretere Hilfe suchst, solltest du eine konkretere Problembeschreibung als "ich bekomme es nicht hin" abliefern.

Hm, dann machst du wohl etwas falsch...

Es ist möglich, aber nicht so einfach, wie du dir das vielleicht vorstellst. Du kannst dich auch nicht mit Lenkrad und Stuhl auf die Straße setzen und hoffen, dass du ohne ein Auto ans Ziel kommst, wenn du nur etwas andere Lenkbewegungen machst. Der "natürliche Lebensraum" von PHP-Skripten ist eine ziemlich komplexe und komfortable Laufzeitumgebung aus dem Browser, der die GUI darstellt und die Eingabedaten liefert, und dem Webserver, der sich um die Ausführung kümmert. PHP-Skripte sind natürlich auf diese Laufzeitumgebung ausgelegt. Wenn du die Abhängigkeit von dieser Infrastruktur loswerden willst, muss sich dein Programm um alles, was vorher Browser und Webserver erledigt haben, selbst kümmern. Es gibt dann niemanden mehr, der für dich die GUI aus HTML rendert, und niemanden, der dir die Eingabedaten in einem handlichen $_POST liefert. Das geht nicht einfach so mit "umcodieren". Zudem musst du dafür sorgen, dass du entweder direkt ausführbare Dateien aus dem PHP-Code erstellst (mit einem Compiler), oder lokal ein PHP-Interpreter vorhanden ist, der deinen Code ausführt.

Was meinst du denn mit Zugang? Bei einem guten Passwortmanager ist weder Kenntnis des Algorithmus noch der Zugriff auf die verschlüsselten Daten ein Problem. Alle Verschlüsselungen sind umkehrbar. Du benutzt den Begriff "Verschlüsselung" falsch. In deinem Programm ist nirgendwo eine Verschlüsselung. Du verknüpfst mehrere Hash-Funktionen. Und wo ist die zusätzliche Sicherheit? Statt den Dienst selbst mit Passwortlisten zu füttern, füttere ich eben dein Programm mit diesen Listen. Mit etwas Glück verwendet der Benutzer dasselbe Geheimnis für mehrere Dienste, dann gute Nacht.

Ohne Beteiligung eines Webservers ist es sinnlos, da einen Browser einzubeziehen. Dann mach es eben erst einmal über die Konsole. Print ist Ausgabe. Konsoleneingabe bei PHP funktioniert über fscanf auf STDIN, soweit ich weiß. Nein, das kann man dem Code ansehen. Eine wichtige Eigenschaft einer Verschlüsselung ist, dass man sie umkehren kann. Was du da machst, ist nicht umkehrbar. Auch SHA1 und MD5 sind keine Verschlüsselungen, aus genau demselben Grund: Weil du den Klartext nicht wiederherstellen kann. Ein Password-Manager, aus dem man die Passwörter nicht wieder herausholen kann, klingt für mich ziemlich kaputt.

Weißt du denn, wie man PHP-Code lokal, ohne Webserver ausführt? Naja, das ganze HTML-Zeug muss natürlich weg, statt dessen musst du deine Eingabedaten aus der Konsole oder GUI lesen. Mag sein, dass du das für korrekt und gewollt hältst. Aber das ist kein Verschlüsselungsalgorithmus.

Wie sollen denn zwei direkt aufeinanderfolgende return-Anweisungen funktionieren? Die zweite wird nie erreicht.

Funktioniert es auch, wenn du add mit 2 Parametern aufrufst, und der zweite 0 ist?

Moment, das passt nicht zusammen. add(2) kann nur entweder ein Ergebnis zurückgeben, oder eine Funktion, die einen weiteren Parameter erwartet. Beides geht nicht.

Ich habe doch beschrieben, wie man auf fehlende Parameter prüft. Mit Google findet man das auch ziemlich leicht. Wenn du eine Fehlermeldung bekommst, solltest du sie uns verraten.

"irgendwie bekomme ich es nicht hin" ist keine ausreichende Problembeschreibung. Fehlende Parameter erkennt man z.B. durch Identitätsvergleich mit undefined.

Dann machst du wohl etwas falsch. Siehe meine Signatur.

Bist du sicher, dass du nicht eine alte Version startest?

http://www.fachinformatiker.de/daily-talk/149507-umfrage-kaffee-konsum.html -> Zu.

Es gibt da keine nennenswerten Unterschiede. Irgendwelche Besonderheiten zu Klassen, Namensräumen und Überladung kannst du ignorieren, weil es so etwas in C nicht gibt.

Mit %d weist du scanf an, einen vorzeichenbehafteten Zahlenwert in Dezimalschreibweise einzulesen. Dazu würde dann auch ein int*-Parameter gehören. Daher kann scanf mit dem eingegebenen Buchstaben nichts anfangen, lässt ihn im Eingabepuffer stehen und gibt 0 zurück (für 0 gefüllte Parameter). Den Rückgabewert von scanf prüfst du leider nicht. Beim nächsten Schleifendurchlauf steht der Buchstabe natürlich immer noch im Eingabepuffer. Scanf wartet also nicht auf eine Eingabe, sondern kommt wieder sofort mit 0 zurück -> Endlosschleife. Lösung: Siehe carstenj Beachte aber, dass dir scanf im nächsten Durchlauf einen Zeilenvorschub ('\n') liefern wird.

Ich hätte gern eine 1000%-Definition von Unternehmensumgebung

Binde die Visibility der Steuerelemente in XAML über einen passenden ValueConverter an Value.Bezahlart.

Nein. Das einleitende Zeichen wird selbst auch durch eine Escape-Sequenz wiedergegeben.

Unsinn. Textdaten sind immer Binärdaten, umgekehrt nicht. Wenn das Funktionieren des Protokolls auf Wahrscheinlichkeiten beruht, ist es kaputt. Es gibt erprobte Lösungen für dieses Problem, und ich habe sie genannt.

- Kein "Premier Support" direkt vom Hersteller - Verwendung auf eigene Gefahr

Das verlagert das Problem nur. Was machst du, wenn diese Byte-Folge in deinen Nutzdaten auftaucht?

Das ist ja toll, wenn man Texte überträgt. Aber sobald man Binärdaten hat, hilft das auch nicht weiter.

Du könntest eine Escape-Sequenz benutzen, wenn im Datenstrom ein Steuerzeichen (in deinem Fall #) auftritt. Beispielsweise könntest du das Steuerzeichen verdoppeln, wenn es als Teil der Daten und nicht als Steuerzeichen interpretiert werden soll. Oder du baust die Länge der Nachricht mit ins Protokoll ein.

Wie unterscheidest du eine Raute im Data-Teil vom Ende der Nachricht?