BSD-Sockets für Windows?
-
Vergiss es.
-
Wieso sollte ich es vergessen? Es wurde gesagt:
Janjan schrieb:
Alle Berkley-Socket-Funktionen sind auch in der Winsock-Bibliothek enthalten.
Was hindert die Leute, die sich mit dem Netzwerkkram ein bißchen auskennen, also daran, beispielsweise folgende Dateien zu erstellen:
/* "sys/socket.h" */ #include <winsock2.h> #define MSG_NOSIGNAL 0x20 // Weiteres Zeug, das von Winsock abweicht/* "sys/ioctl.h" */ #include <winsock2.h> // Vom Winsock abweichendes Zeugetc.
Und was ist so abwegig daran, mal nachzufragen, ob das schonmal gemacht wurde, so daß ich in einem vorhandenen Quellcode nicht selbst rumfrickeln muß und möglichwerweise einen Fehler mache, sondern wo ich einfach gegen ein paar Wrapperdateien linke, die nach außen wie das typische Linuxzeug aussehen und intern die Winsock benutzen, die ja angeblich sowieso auch alles das kann, was die BSD-Sockets können?
Entweder man kann die BSD-Socket-Funktionen ganz einfach nachbilden, dann ist meine Frage, ob es solche Dateien gibt, gerechtfertigt. Oder das ganze ist wirklich absolut unixtypisch und in Windows nicht nachbildbar. Dann wäre aber Euer Vorschlag, Winsock zu nehmen, Blödsinn gewesen. Wie auch immer, ich sehe trotzdem keine Situation, in der jetzt meine Anfrage irgendwie blöd und undurchdacht wäre. Denn wenn man das BSD-Zeug mit Winsock nachbauen kann, dann wird man ja wohl mal nach einem Wrapper fragen dürfen, der einem auf Codeebene die Möglichkeit gibt, einen in Linux geschriebenen Code unverändert unter Windows zu benutzen.
-
Man muss die Berkley-Socket-Schnittstelle nicht nachbilden, da sie vollständig in Winsock enthalten ist.
-
Ich hab das Gefühl ich red mit ne Tonne.
- Du hast die beste Lösung schon.
- Dein Programm ist Unix/Linux-spezifisch.
- Du hast keine Wissen über das Programm.
Dein Versuch irgendetwas hinzufrickeln wird dich nirgendwo führen. Falls das Programm klein ist, kannst du es gerne Versuchen. Wenns groß ist, wirst du wahrscheinlich verzweifeln.
-
Janjan schrieb:
Man muss die Berkley-Socket-Schnittstelle nicht nachbilden, da sie vollständig in Winsock enthalten ist.
Offenbar nicht, sonst würden da nicht noch ein paar Compilerfehler kommen. Und selbst wenn sie vollständig in Winsock nachgebildet ist, würde so ein Wrapper trotzdem Sinn machen, da man in Winsock nicht dieselben Headerdateien einbindet und somit erstmal den Quellcode ändern muß.
Zeus schrieb:
Ich hab das Gefühl ich red mit ne Tonne.
Das sagt der richtige:
Zeus schrieb:
Dein Versuch irgendetwas hinzufrickeln wird dich nirgendwo führen.
Das gesamte Thema hier lief darauf hinaus, nicht irgendwas hinzufrickeln, sondern eine fertige Bibliothek zu nehmen, die exakt genauso funktioniert wie die BSD-Dateien in Linux. Die anderen haben mir empfohlen, das Programm umzuschreiben, also wieso bin ich jetzt der Blöde? Ich habe von Anfang an gesagt, daß ich den Code nicht verändern will. Ergo kann auch nicht die Rede davon sein, daß ich versuche, hier irgendwas hinzufrickeln.
-
Du Checkst nicht, dass dein Programm mehr als nur BSD Socket benutzt.
vasprintf(3) - Linux man page
These functions are GNU extensions, not in C or POSIX. They are also available under *BSD. The FreeBSD implementation sets strp to NULL on error.
Mit was für ein Wrapper willst diese Funktion ersetzen? Willst du jetzt den Code Reverse-Engineering?
-
Zeus schrieb:
Du Checkst nicht, dass dein Programm mehr als nur BSD Socket benutzt.
Und? Analog zu meiner ursprünglichen Frage würde ich in dem Fall gucken, ob es für die anderen Funktionen auch eine Windows-Implementierung gibt. Ich meine, bloß weil diese Funktionen nicht Teil des C-Standards sind, heißt das ja nicht, daß man die Funktionalität nicht in Windows nachbauen kann.
Zeus schrieb:
Mit was für ein Wrapper willst diese Funktion ersetzen? Willst du jetzt den Code Reverse-Engineering?
Ich selbst will das überhaupt nicht machen. Ich frage nur, ob es solche Implementierungen für Windows schon gibt.
-
NES-Spieler schrieb:
Janjan schrieb:
Man muss die Berkley-Socket-Schnittstelle nicht nachbilden, da sie vollständig in Winsock enthalten ist.
Offenbar nicht, sonst würden da nicht noch ein paar Compilerfehler kommen. Und selbst wenn sie vollständig in Winsock nachgebildet ist, würde so ein Wrapper trotzdem Sinn machen, da man in Winsock nicht dieselben Headerdateien einbindet und somit erstmal den Quellcode ändern muß.
Verstehst du es ernsthaft nicht? Dein Code benutzt Kram, der nicht Bestandteil der Berkley-Socket-Schnittstelle ist. Und genau der Kram macht Probleme.
-
NES-Spieler schrieb:
Ich selbst will das überhaupt nicht machen. Ich frage nur, ob es solche Implementierungen für Windows schon gibt.
Dann ist das Thema endlich in der Tonne.
-
Janjan schrieb:
Verstehst du es ernsthaft nicht? Dein Code benutzt Kram, der nicht Bestandteil der Berkley-Socket-Schnittstelle ist. Und genau der Kram macht Probleme.
Und diesen Quatsch gibt's nicht für Windows? Ich meine, wenn man sich mal die Definition ansieht:
The functions asprintf() and vasprintf() are analogues of sprintf() and vsprintf(), except that they allocate a string large enough to hold the output including the terminating null byte, and return a pointer to it via the first parameter. This pointer should be passed to free(3) to release the allocated storage when it is no longer needed.
Das klingt nicht so, als müßten diese Funktionen zwangsläufig nur unter Linux verfügbar sein. Also wieso gibt's diesen Mist nicht für Windows? Wer denkt sich sowas aus?
Zeus schrieb:
Dann ist das Thema endlich in der Tonne.
Für Tonnen scheinst Du eine ganz besondere Vorliebe zu haben, was?
-
Sag mal NES-Spieler,
du bist hier seit 2006 angemeldet und hast nicht den blassen Schimmer wie man Programme kompiliert??? Dazu muss ja nicht mal programmieren können!!! Ich denke das die IT nicht das richtige Gebiet für dich ist....ehrlich pack die Kiste wieder ein, mach ein Aufkleber rauf "Ich raff es nicht" und schicke die Technologie wieder zurück an den Hersteller und fang mit Angeln an oder Stricken oder irgendwas wo du nach Jahren auch was lernen wirst.
-
NES-Spieler schrieb:
Janjan schrieb:
Verstehst du es ernsthaft nicht? Dein Code benutzt Kram, der nicht Bestandteil der Berkley-Socket-Schnittstelle ist. Und genau der Kram macht Probleme.
Und diesen Quatsch gibt's nicht für Windows? Ich meine, wenn man sich mal die Definition ansieht:
The functions asprintf() and vasprintf() are analogues of sprintf() and vsprintf(), except that they allocate a string large enough to hold the output including the terminating null byte, and return a pointer to it via the first parameter. This pointer should be passed to free(3) to release the allocated storage when it is no longer needed.
Das klingt nicht so, als müßten diese Funktionen zwangsläufig nur unter Linux verfügbar sein. Also wieso gibt's diesen Mist nicht für Windows? Wer denkt sich sowas aus?
Dafür wurde ja Cygwin gemacht und scheinbar läuft dein Programm ja mit Cygwin, also was hast du denn für ein Problem?
Also:
1. Es handelt sich um ein Linux Programm. Linux Programme können nicht einfach unter Windows kompiliert werden.
2. Um Linux Programme trotzdem unter Windows kompilieren zu können gibt es Cygwin das du ja schon kennst.
3. Willst du Cygwin nicht verwenden, musst du das Programm auf Windows portieren was Änderungen im Code bedeutet.Das ist doch echt nicht so schwer zu kapieren, oder? Was gibt es denn da noch gross zu diskutiere?
-
kein-Spieler schrieb:
du bist hier seit 2006 angemeldet und hast nicht den blassen Schimmer wie man Programme kompiliert???
Was hat meine Frage, ob es diese oder jene Bibliothek auch für Windows gibt, mit der Fähigkeit, ein Programm zu kompilieren, zu tun?
Tanren schrieb:
Dafür wurde ja Cygwin gemacht und scheinbar läuft dein Programm ja mit Cygwin, also was hast du denn für ein Problem?
Ich wollte einfach nur wissen, ob es dafür auch eine Standalone-Bibliothek gibt, die man mit MinGW verwenden kann.
Tanren schrieb:
1. Es handelt sich um ein Linux Programm. Linux Programme können nicht einfach unter Windows kompiliert werden.
Das ist mir auch klar. Aber die Funktionen, die es hier unter Windows nicht gibt, heißen ja nicht GetLowLevelUnixKernelData, sondern sie heißen unter anderem vasprintf. Und auch wenn es diese Funktion in der Praxis unter Windows nicht geben mag, heißt das nicht, daß sie prinzipiell nicht unter Windows implementiert werden kann. Und meine Frage war nun, ob es so eine Implementierung tatsächlich gibt. conio.h ist auch eine Windows-spezifische Datei. Aber trotzdem könnte ja jemand diese Datei in Linux nachbauen und in den Funktionsdefinitionen dann eben entsprechende Linuxfunktionen benutzen. Würde also ein Linuxbenutzer fragen, wie er ein Programm, das die conio.h einbindet, in Linux kompilieren kann, könnte man ihm sagen: "conio.h ist eine spezielle Datei für Windows. Leider ist mir nicht bekannt, daß jemand diese Datei für Linux nachgebaut hat. Du müßtest die Funktionsaufrufe also durch analoge Funktionen aus Linux ersetzen oder Dich selbst daranmachen, eine conio.h für Linux zu entwickeln und dann dagegenlinken. Aber eine fertige Linuximplementierung von conio.h ist mir nicht bekannt, obwohl es prinzipiell wahrscheinlich machbar wäre." Es gäbe keinen Grund, ihm an den Kopf zu knallen: "Mann, das is ne Windows-Datei, Du b00n!!! Weißt Du, was Windows ist? Du kannst Windows-Programme nicht unter Linux kompilieren, geht das nicht in Deinen Schädel?"
Tanren schrieb:
Das ist doch echt nicht so schwer zu kapieren, oder?
Nein, ist es nicht. Aber offenbar scheint es für Euch etwas schwer zu sein, zu kapieren, daß ich lediglich wissen wollte, ob es für die entsprechenden Dateien eine Windows-Implementierung gibt (auch wenn die Dateien ursprünglich nur unter Linux verfügbar sind) oder ob das noch keiner in Angriff genommen hat. Und wenn zweiteres der Fall ist, wollte ich wissen, wie Cygwin das dann gemacht hat, wo dieses Programm ja meines Wissens nach eine Windows-Anwendung ist, aber keine echte Emulation von Linux, so daß alle Funktionen, die Cygwin beherrscht, ja irgendwann mal unter Windows kompiliert worden sein müssen. (Oder kann Cygwin etwa die für Linux kompilierten Binaries lesen?) Und wenn das gemacht wurde, dann ist der Gedanke, daß es die BSD-Sockets und dieses vasprintf etc. vielleicht auch als Standalone-Produkt für die Verwendung unter MinGW oder Visual Studio gibt, nicht mehr so weit hergeholt, oder?
-
Gibt es nicht. Noob.
-
Wenn das so ist, würde mich interessieren: Wie wurde die Datei "cygwin1.dll" kompiliert?
-
Mit einem Kompiler natürlich.
Wenn dich das so brennent interessiert, lad dir Quellcode runter und schau nach.
-
cygwin.dll wrappt unter anderem die Linux POSIX API, hat also deine gesuchten Funktionalitäten irgendwo drinne. Ich glaube kaum das sich hier einer die Mühe macht und nachschaut wie dort deine printf funktion auf die winapi gewrappt ist.
Guckt dir doch die Linux printfs und Winapi printfs an und schau ob man da einen ganz kleinen Wrapper schreiben kann. Ansonster frag die Entwickler von cygwin. Wie soll denn hier einer Wissen ob das schon mal einer gewrappt hat????
-
NES-Spieler schrieb:
Wenn das so ist, würde mich interessieren: Wie wurde die Datei "cygwin1.dll" kompiliert?
Und wenn du auch nur ein kleines bischen vom Programmieren verstehen würdest, dann wüsstest du die Antwort bereits.
-
Ich schätze so, aber nich weiterverraten
gcc -c cygwin.c gcc -shared -o cygwin.dll cygwin.o
-
Mann, ey, Ihr seid aber auch schwer von Begriff: Als ich fragte, wie cygwin1.dll kompiliert wurde, meinte ich nicht, daß ich eine genaue Beschreibung haben will, sondern ich wollte bloß wissen: Besteht die Funktionalität darin, daß die Linux-Binaries gelesen und konvertiert werden können, oder wurden die Linuxfunktionen mit Windows nachgebaut?
Um mal ein analoges Vergleichsbeispiel zu benutzen, das meinem Benutzernamen entspricht: Ist Cygwin eher wie ein NES-Emulator, der von den Spielekassetten kopierte Binärdateien liest und somit ein exaktes Abbild des entsprechenden Spiels auf dem PC liefert? Oder ist Cygwin eher zu vergleichen mit einem selbstgemachten Remake von "Super Mario Bros.", wo jemand das Originalspiel studiert hat, dann die Grafiken als Bitmap nachgezeichnet, die Sounds aufgenommen und dann die gesamte Spielephysik in einem DirectX-Programm nachgebaut hat?
Worauf ich nämlich hinauswill (und die ganze Zeit hinauswollte, aber das checkt Ihr ja nicht): Wenn Cygwin eher mit dem "Mario"-Remake zu vergleichen ist, statt mit der Emulation, dann bedeutet das, daß es native Windows-Implementierungen der Linuxfunktionen gibt, die man auch außerhalb von Cygwin verwenden könnte. Und das war ja der Anlaß meines ersten Posts in diesem Thread. Wenn's aber nur eine Emulation ist, hättet Ihr gleich am Anfang sagen können: "Die Funktionen laufen nicht unter Windows. Und Cygwin ist zwar ein Windows-Programm, aber da wurden sie nicht nachprogrammiert, sondern Cygwin benutzt die originalen Linux-Binaries und emuliert diese."