BSD-Sockets für Windows?

NES-Spieler

Janjan schrieb:

Viel spaß. Befasse dich mit den konkreten Unterschieden und schreibe diesen Wrapper selbst. Aber nein.. Du willst ja nicht programmieren. Du willst nur ein Linuxprogramm für Windows kompilieren.

Ja, genau. Was ist daran so abwegig? Unter Cygwin geht es auch. Und Cygwin ist ein Windows-Programm. Man kann die Programme, die man mit Cygwin kompiliert hat, sogar außerhalb von Cygwin benutzen, wenn man "cygwin1.dll" im Pfad zu liegen hat. Also tu doch nicht so, als wäre meine Idee so dämlich, als würde ich versuchen, ein in Assembler geschriebenes Atari2600-Programm nativ unter Windows zu kompilieren. Fakt ist: Die BSD-Sockets wurden schon unter Windows bereitgestellt. Was da wie gewrappt wird, ist mir doch egal. Aber es läuft auf jeden Fall. Und ich wollte nur wissen, ob die BSD-Sockets auch für andere Compiler und ohne Abhängigkeit zu einer DLL-Datei erstellt wurden.
Einerseits beharrt Ihr darauf, daß so ziemlich alles, was es in den BSD-Sockets gibt, auch in den Winsockets gibt und man für die Sachen, die nicht kompatibel sind, Wrapper schreiben kann. Andererseits bin ich jetzt der Trottel, wenn ich frage, ob es irgendwo einen Windows-Wrapper der BSD-Sockets gibt, mit dem man die BSD-Header einbinden kann, die dann von mir aus ihrerseits intern auf Winsockets verweisen.

Janjan schrieb:

Wie bereits gesagt wrappt Cygwin den ganzen Kram. Es ist mehr als nur eine Linux-Konsole für Windows.

Aber es ist immer noch ein reines, natives Win32-Programm. Und wenn Cygwin in der Lage ist, ein Programm zu erstellen, daß unter Windows ganz normal läuft, solange sich die Datei "cygwin1.dll" im selben Pfad befindet, was bitteschön ist dann so dumm an dem Gedanken, daß die Funktionen, die in Cygwin benutzt werden, auch anderswo für Compiler für Windows bereitgestellt wurden? Wieso dieses ständige Beharren auf der Tatsache: "Das ist ein Linux-Programm!!!!!111einseinself"? Ja, und? Es läuft aber unter Windows. Und das einzige, was ich wissen wollte: Kann man die BSD-Sockets unter Windows nur mit Cygwin benutzen oder gibt es außerdem noch andere Implementierungen davon?

Janjan schrieb:

Bitte lerne doch die Grundkenntnisse von C.

Was hat das jetzt mit den Grundkenntnissen von C zu tun?

Zeus schrieb:

Wieso nicht eine platform-independent Socket-lib (like Java! - Write Once, Run Anywhere).

Weil ich das Programm nicht geschrieben habe, sondern es nur ausführen will.

hibbes schrieb:

Cygwin stellt doch nur die API von Linux bereit, ähnlich wie WINE die WinAPI unter Linux verfügbar macht.
Wenn Du also unter Cygwin mit gcc dein Zeug kompilierst musst du immer die cygwin.dll mit dazugeben, sonst laufen die API-Aufrufe ins Leere. Korrigiert mich wenn ich hier Mist erzähle...

Ja, das ist soweit richtig. Und worum es mir nun geht: Da man es ja mit Cygwin geschafft hat, die Linuxfunktionen in Windows nachzubauen, wäre es doch theoretisch auch möglich, diese Linuxfunktionen losgelöst ganz allgemein in Form von Libdateien (oder als offener Quellcode) zu erstellen, gegen die ein Compiler linken kann. Und meine Frage war eben, ob das in der Praxis schonmal getan wurde.

Zeus

Vergiss es.

NES-Spieler

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 Zeug

etc.

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.

Janjan

Man muss die Berkley-Socket-Schnittstelle nicht nachbilden, da sie vollständig in Winsock enthalten ist.

Zeus

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.

NES-Spieler

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.

Zeus

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?

NES-Spieler

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.

Janjan

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.

Zeus

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.

NES-Spieler

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.

Tanren

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?

NES-Spieler

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?

Janjan

Gibt es nicht. Noob.

NES-Spieler

Wenn das so ist, würde mich interessieren: Wie wurde die Datei "cygwin1.dll" kompiliert?

Zeus

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????

Janjan

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