BSD-Sockets für Windows?



  • 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."



  • Warum liest du nicht einmal nach, was Cygwin genau ist: http://www.cygwin.com/ 🙄

    Dann wüsstest du, dass es sich bei Cygwin nicht um einen Emulator handelt, sondern um genau das, was du schon die ganze Zeit suchst. Einfach eine Library die POSIX für Windows wrapt.

    A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.

    # Cygwin is not a way to run native linux apps on Windows. You have to rebuild your application from source if you want it to run on Windows.

    Wenn du nun immer noch kein Cygwin willst, dann kannst du dir ja MKS für ein paar k€ kaufen 🙄.



  • Warum einfach wenns aus kompliziert geht, um es in deiner Sprache auszudrücken:

    Die cygwin.dll bildet die Linuxfunktionen nach, so dass sie auch von Windowsprogrammen genutzt werden können.
    Du kannst damit also Linuxprogamme unter Windows kompilieren und dann zusammen mit der cygwin.dll nutzen.



  • iknowit schrieb:

    Warum liest du nicht einmal nach, was Cygwin genau ist: http://www.cygwin.com/ 🙄

    Dann wüsstest du, dass es sich bei Cygwin nicht um einen Emulator handelt, sondern um genau das, was du schon die ganze Zeit suchst. Einfach eine Library die POSIX für Windows wrapt.

    Und meine Frage war nun, ob es diese Wrapper auch ohne Cygwin gibt. Daß ich mir also die BSD-Sockets irgendwo herhole und mit meinem normalen MinGW dagegenlinke. Denn wenn's keine Emulation ist, müßten die ja auch ohne Cygwin neukompilierbar sein, da in dem Fall ja nur ganz normaler Windows-Code dahintersteckt.



  • Omg jetzt Recyclin wir den Thread.



  • n00b-Buster schrieb:

    Warum einfach wenns aus kompliziert geht, um es in deiner Sprache auszudrücken:

    Die cygwin.dll bildet die Linuxfunktionen nach, so dass sie auch von Windowsprogrammen genutzt werden können.
    Du kannst damit also Linuxprogamme unter Windows kompilieren und dann zusammen mit der cygwin.dll nutzen.

    Aber wie bildet sie sie nach? Ganz normal auf Codeebene im Stil von:

    int LinuxNotificationBox(std::string message)
    {
        return MessageBoxA(NULL, message.c_str(), "Message", MB_OK);
    }
    

    ?
    Wenn das nämlich der Fall ist, wäre es möglich, die Quellcodes rauszunehmen und als normale Lib für Compiler zu verwenden.



  • Keine Ahnung ob ausserhalb des Cygwin-Projektes noch jemand Teile der POSIX API wrapt. Dir bleiben ja nur zwei Wege:

    1. Du kompiliert gegen Cygwin mit all den Abhängigkeiten die da auftreten
    2. Du portierst die Anwendung nach Windows

    Kann Beides ein ganz schöner Aufwand sein und da du nicht die große Leuchte im Bezug auf C++ etc. zu seinen scheint denke ich mal dass du mit beidem extremsst überfordert bist.



  • Ja, so ungefair machen die das.



  • n00b-Buster schrieb:

    Ja, so ungefair machen die das.

    Wenn die das so machen, dann hatte ich mit meiner Vermutung die ganze Zeit recht. Und dann ist es völlig ungerechtfertigt, zu sagen: "Das Programm benutzt vasprintf, das kannst Du also nicht unter Windows kompilieren, weil das eine Linux-Funktion ist", denn offenbar gibt es ja dann irgednwo einen Quellcode, in dem folgendes drinsteht:

    int vasprintf(char **strp, const char *fmt, va_list ap)
    {
        // Irgendwelches Windows-Zeug
    }
    

    Wenn aber einer sowas gemacht hat, ist es auch möglich, daß zwei Leute das gemacht haben und einer von denen das nicht in eine DLL linkt und mit einem Programm ausliefert, sondern als Lib-Dateien und als Quellcode zur Verfügung stellt. Und unter diesen Gesichtspunkten muß ich mich echt fragen, was an meiner Anfrage, ob man diese Implementierung irgendwo für Windows herbekommt, so noobig sein soll.



  • NES-Spieler schrieb:

    iknowit schrieb:

    Warum liest du nicht einmal nach, was Cygwin genau ist: http://www.cygwin.com/ 🙄

    Dann wüsstest du, dass es sich bei Cygwin nicht um einen Emulator handelt, sondern um genau das, was du schon die ganze Zeit suchst. Einfach eine Library die POSIX für Windows wrapt.

    Und meine Frage war nun, ob es diese Wrapper auch ohne Cygwin gibt. Daß ich mir also die BSD-Sockets irgendwo herhole und mit meinem normalen MinGW dagegenlinke. Denn wenn's keine Emulation ist, müßten die ja auch ohne Cygwin neukompilierbar sein, da in dem Fall ja nur ganz normaler Windows-Code dahintersteckt.

    Die Cygwin-DLL ist der Wrapper. Das zweite L in DLL steht für Library! Wie auf der Homepage steht besteht Cygwin aus zwei Teilen: Dem Wrapper (der DLL) und Programmen die bereits mit diesem Wrapper kompiliert wurden (die brauchst du natürlich nicht).

    hier kannst du dir den Code anschauen http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/?cvsroot=src 🙄



  • Wenn du ein Linux Programm versuchst gegen die Windows API zu compilieren, ist es völlig rechtfertig, dass wir dir sagen, das es nicht geht.

    Hier ist der Quellcode. Die Lib besteht aus 6024 Dateien. Viel Spaß.
    http://cygwin.com/snapshots/cygwin-src-20100518.tar.bz2



  • Lad dir doch den Sourcecode von Cygwin runter und suche dir die Implementierung raus. Wo ist das Problem???



  • Die Datei heist newlib\libc\stdio\vfprintf.c und hat über 2000 Zeilen Code...viel Spass



  • NES-Spieler schrieb:

    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?

    Man ey, bist du schwer von Begriff. Das wurde bereits mehrfach gesagt.



  • Echt Spitzenklasse! Einfache Frage: Gibt es eine lib, die die Linux-BSD-Sockets in Windows bereit stellt auch außerhalb von Cygwin?

    Die Leute brauchen 5 Seiten um das zu kapieren und behaupten noch du seist der Idiot. Respekt, Herr Spieler, dass sie so eine Geduld und Ruhe an den Tag legen. 😃

    Mir ist sowas auch nicht bekannt, es scheint wohl jeder mit Cygwin zufrieden zu sein. Rein für ein paar inkompatible Netzwerkfunktionen ist das ziemlich fett, aber dir bleibt dann wohl nichts über, als Cygwin komplett zu nutzen, die Teile aus dem Cygwin Code zu extrahieren, oder selbst etwas zu implementieren.



  • Totaler Mist, er fragte nicht nach Linux-BSD-Sockets sondern nach allgeimein BSD-Sockets und die nutzt definitiv Windows auch und die sind auch sehr stark kompatibel untereinander. Mann muss nix besonderes machen um BSD-Sockets unter Windows zu nutzen.

    Dann wollte er unbedingt sowas wie cygwin aber ohne cygwin nutzen zu wollen, das wird schwer, was er nicht einsah.

    Die Möglichkeiten die er hat wurden ihm aufgezeigt und so langsam müsste ihm klar sein das es keine cut&paste Lösung dafür gibt, sprich er müsste programmieren können oder die cygwin.dll nutzen. Beides kann oder will er nich also is das Projekt gestorben.

    Der Typ is der Hammer, sowas habe ich noch nich gelesen.



  • Beste Unterhaltung! schrieb:

    Mir ist sowas auch nicht bekannt, es scheint wohl jeder mit Cygwin zufrieden zu sein. Rein für ein paar inkompatible Netzwerkfunktionen ist das ziemlich fett, aber dir bleibt dann wohl nichts über, als Cygwin komplett zu nutzen, die Teile aus dem Cygwin Code zu extrahieren, oder selbst etwas zu implementieren.

    Es ging eben nich nur um ein paar Netzwerkfunktionen du Nase.



  • iknowit schrieb:

    Warum liest du nicht einmal nach, was Cygwin genau ist: http://www.cygwin.com/ 🙄

    Dann wüsstest du, dass es sich bei Cygwin nicht um einen Emulator handelt, sondern um genau das, was du schon die ganze Zeit suchst. Einfach eine Library die POSIX für Windows wrapt.

    A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.

    # Cygwin is not a way to run native linux apps on Windows. You have to rebuild your application from source if you want it to run on Windows.

    Wenn du nun immer noch kein Cygwin willst, dann kannst du dir ja MKS für ein paar k€ kaufen 🙄.

    Wozu die Posix Wrappen unter Windows, wenn Windows schon die Posix im Kernel hat ?
    Vista/W7/W2k8/W2k3 -> Software Subsystem für Unix aktivieren und Tools runterladen von MS, da ist GCC, K/C und S5K Shell und XClient bei, sowie alle Shell Tools nach Posix Standart. Die olle OS2 Api schlummert da auch irgendwo noch rum.



  • Du Nase, und jeder soll sich dann die POSIX Erweiterung installieren der das nutzen will???

    Is doch derselbe Mist als wenn sich jeder Java, das neuste .NET oder ne Interpreter installieren muss um die Software zu nutzen. Ein User will runterladen anklicken fertig, alles andere is crap.



  • viel schlimmer ist dass das Subsystem for UNIX-based Applications nicht mehr weiterentwickelt wird.


Anmelden zum Antworten