3. Multiplatform Source-QSU Win32/POSIX Threads (SFU/Cygwin vs. gcc in a bochs)

Multiplatform Source-QSU Win32/POSIX Threads (SFU/Cygwin vs. gcc in a bochs)

  • G

    Hallo!

    Für ein Projekt das Win32 und Linux (jeweils IA32) als Zielplatformen hat muss ich eine Entwicklungs- und vorläufige Qualitätssicherungsumgebung (QSU) definieren.

    Erste Aufgabe z.Zt. ist es die Parallelentwicklung der - sehr komplexen - applkationseigenen Threadmimik sicherzustellen.
    (Anm: "Boost" können wir nicht einsetzen!)
    Primäre Entwicklungsplatform ist z.Zt. Win XP Pro SP 2 mit MSVC.

    Mein Ideal wäre es, die POSIX-Implementierung auf einem zentralen Linux-Host zu betreiben; das stösst jedoch auf Grenzen in der Machbarkeit da ein Teil der Entwicklung dezentral erfolgt und SSH (von Telnet/RSH oder gar X reden wir besser erst gar nicht 🙂 ) von der Firewall geblockt wird; und dies kann ich nicht auch nicht ändern.

    Irgendwie muss ich's aber trotzdem hinkriegen. Es bieten sich mehrere Möglichkeiten an

    - MS Windows Services für UNIX
    http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
    - Third Party POSIX Implementierungen für Win32 wie
    http://sourceware.org/pthreads-win32/
    - Cygwin/GCC
    http://cygwin.com/

    Habt Ihr Erfahrungswerte aus der Verwendung dieser Bibliotheken, insbesondere in Hinblick auf pthreads ?

    Dann gibt's natürlich noch Bochs mit einem "richtigen" Linux und gcc.
    Abgesehen davon dass ich bei Win/Bochs noch nicht den PCAP Treiber, also die Netzwerkverbindung mit der "Host"-Maschine zum Laufen gekriegt habe; ist es realistisch in der Umgebung mit einem Compiler arbeiten zu wollen?
    Die "Host"-Rechner, also die Entwicklermaschinen, liegen zwischen 2Ghz/1GB und 3Ghz/2GB.

    Wenn mit Bochs etwas ginge wärs fast optimal; ich könnte dann ein vorbereitetes Image zum Download anbieten und wir hätten so eine exakt definierte und reproduzierbare Umgebung mit dem Targetcompiler.

    Dass keine der Lösungen regelmässige Tests auf der Zielplatform ersetzt ist mir klar; im Moment geht es darum "den Fuss in die POSIX-Tür" zu kriegen.
    Es geht mir derzeit vor allem darum dass der platformabhängige Teil kompiliert und parallel zur Win32-Entwicklung eine Infrastruktur für spätere Linux-Releases entsteht so dass man dann nicht bei Null anfangen muss.

    Wenn Ihr Erfahrungswerte mit einer oder mehrerer der Möglichkeiten habt, fände ich es echt super wenn ihr mir Eure Meinung dazu mitteilen würdet! 🙂

    Danke fürs Lesen und

    Grüsse

    *this

    0
  • C

    Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • P

    *knusperknusperknusper ...schmatz*

    http://www.cs.wustl.edu/~schmidt/ACE.html

    Oder gleich Java ...

    0
  • G

    [quote="Prof84"]*knusperknusperknusper ...schmatz*{/quote]
    LOL 🙂

    Ja, ACE is ne wahre Legende...

    Aber das nützt mir nicht so viel - für jede Third-Party Komponente müsste ich für den Betrieb Support sicherstellen. Und das geht nicht im Rahmen der Budgetstruktur. Sonst stünde auch Boost auf dem Speiseplan.. 🙂

    Wir dürfen da nur mit Wasser kochen; als Entwicklungsumgebung dürfen wir uns bauen was wir möchten, aber das fertige Projekt muss mit Wasser gekocht sein.
    Und bei Threads heisst das
    Windows : "Win32" Threads; Linux : pthreads - that's it!

    Wir können die Schicht nicht substituieren - wir müssen die selbst schreiben!

    Aber das macht's für mich auch spannend! 🙂

    Grüsse

    *this

    0
  • P

    Joh, war gerade beim Essen... 🕶

    Hmmmm... Raffnix 2.0! 😕

    1. Wenn Du ein 3rd-party componente hast, die die API nutzt, dann ist die fest auf ein OS gemünzt (PSM).
    2. Nach dem Build/Compiling hast Du eine PSM Komponete(Win/Lin) geschaffen, nur der Code ist PIM und genau das ist doch dein Ziel.

    Wenn Du allerdings wieder mit solchen Nasen zu tunen hast -
    "Bitte verwenden Sie keine Templates und Operator Overloads! Unsere Entwickler kommen damit nicht klar..."
    - dann kann ich Dir auch nicht helfen. 😞
    Dann kann man wohl jedes Framework oder jede Lib vergessen.

    0
  • G

    Prof84 schrieb:

    Wenn Du allerdings wieder mit solchen Nasen zu tunen hast -

    So "nasenhaft" finde ich das gar nicht.

    Das ist eine Frage der Kalkulation. Wenn man MS Support einkauft und POSIX Kompetenz hat versteh ich durchaus dass man nicht das Vorgehensmodell an "Neuerungen" von externen Entwicklern anpasst und sich dergetalt abhängig macht.

    Das Projekt muss sich halt in eine etwas grössere IT-Struktur einfügen.

    Eigentlich finde ich das Projekt in deren Landschaft strategisch genau richtig plaziert; es ist systemische Kompetenz im Haus vorhanden mit der das Projekt erfolgreich weiterzuführen sein wird.

    Grüsse

    *this

    P.S.: Den Sprchumfang von C++ 03 darf ich schon ausnutzen... 🙂

    0
  • P

    Gast++ schrieb:

    Dann gibt's natürlich noch Bochs mit einem "richtigen" Linux und gcc.
    Abgesehen davon dass ich bei Win/Bochs noch nicht den PCAP Treiber, also die Netzwerkverbindung mit der "Host"-Maschine zum Laufen gekriegt habe; ist es realistisch in der Umgebung mit einem Compiler arbeiten zu wollen?
    Die "Host"-Rechner, also die Entwicklermaschinen, liegen zwischen 2Ghz/1GB und 3Ghz/2GB.
    Wenn mit Bochs etwas ginge wärs fast optimal; ich könnte dann ein vorbereitetes Image zum Download anbieten und wir hätten so eine exakt definierte und reproduzierbare Umgebung mit dem Targetcompiler.

    saug' dir vmware (kostet auch nix) und mach da ein linux rein.
    🙂

    0
Anmelden zum Antworten