Sam: *.EXE-Programme

0 50

*.EXE-Programme

Sam
  • sonstiges
  1. 0
    Adromir
  2. 0
    Rouven
    1. 0
      Sam
      1. 0
        Ingo Turski
        1. 0
          agapanthus
      2. 1
        kerta
        1. 0
          Jörg Lorenz
          1. 0
            kerta
            1. 0
              Ashura
            2. 0
              Manuel B.
        2. 1
          Biesterfeld
          1. 0
            kerta
            1. 0
              Biesterfeld
              1. 0
                Martin Speiser
                1. 0
                  Biesterfeld
                  1. 0
                    kerta
                    1. 0
                      Tim Tepaße
                  2. 0
                    Martin Speiser
                    1. 0
                      Biesterfeld
                      1. 0
                        Anonymous
                        1. 0
                          Biesterfeld
                          1. 0
                            Manuel B.
                      2. 0
                        Martin Speiser
              2. 0
                Anonymous
            2. 0
              WebViper
            3. 0
              Der Martin
          2. 0
            Anonymous
            1. 0
              Biesterfeld
              1. 0
                Anonymous
                1. 0
                  Biesterfeld
        3. 0

          ein umkehr compiler für *.EXE-Programme ?

          Alain
          1. 0
            Ingo Turski
            1. 0
              Anonymous
          2. 0
            Biesterfeld
          3. 0
            Manuel B.
            1. 0
              Christoph Zurnieden
              1. 0
                Tim Tepaße
                1. 0
                  Christoph Zurnieden
                  1. 0
                    Tim Tepaße
                  2. 0
                    Manuel B.
                    1. 1
                      Christoph Zurnieden
                      1. 0
                        at
                        1. 0
                          Der Martin
                        2. 0
                          Christian Kruse
                          1. 0
                            at
                      2. 0
                        Manuel B.
                        1. 0
                          Christoph Zurnieden
      3. 0
        Biesterfeld
  3. 0
    JürgenB

Hi,

Hat jmnd 'ne Ahnung wie man Programme mit der Endung *.exe selbst schreiebn kann?

Sam

  1. Da musst du eine Entsprechende Programmiersprache nehmen (ich glaube, das geht mit C, C++ oder Delphi und einigen anderen) und diese musst du dann zu einer Exe- Datei kompilieren..

  2. Hallo,

    na ja, eigentlich 2 Zutaten:

    1. ca. 250ml Quellcode
    2. ein Teelöffel Compiler

    Auf gut Deutsch: Man schnappe sich eine Programmiersprache, einen dazugehörigen Quelltexteditor, im Zweifelsfall auch einfach ein Texteditor und jage den Quelltext am Ende durch einen Compiler. Was unter Windows rauskommt ist idR eine .exe (na ja, es gehen auch dlls etc.)

    MfG
    Rouven

    --
    -------------------
    ss:) zu:) ls:& fo:) de:< va:{ ch:? sh:) n4:( rl:? br:$ js:| ie:) fl:(
    1. Hi,

      Auf gut Deutsch: Man schnappe sich eine Programmiersprache, einen dazugehörigen Quelltexteditor, im Zweifelsfall auch einfach ein Texteditor und jage den Quelltext am Ende durch einen Compiler.

      Woher bekomm' ich so 'nen Compiler?
      Und welche Programmiersprachen werden da unterstützt?

      Sam

      1. Hi,

        Woher bekomm' ich so 'nen Compiler?
        Und welche Programmiersprachen werden da unterstützt?

        Du gehst die Sache vin der falschen Seite an. Eigentlich willst Du doch wohl ein Programm erstellen, das "standalone" ablauffähig ist, oder? Dann informiere Dich über die verschiedenen Programmiersprachen und entscheide Dich, welche Du _lernen_ willst, um ein Programm damit zu erstellen. Beachte dabei auch, daß Compiler nicht immer kostenlos sind...

        Übrigens: da Du ja wohl Windows nutzt, hast Du bereits ein Programm auf Deiner Platte: debug.
        Damit ablauffähige *.com-Dateien zu erstellen, ist allerdings nicht jedermanns Sache. ;-)

        freundliche Grüße
        Ingo

        1. Moin.

          Du gehst die Sache vin der falschen Seite an. Eigentlich willst Du doch wohl ein Programm erstellen, das "standalone" ablauffähig ist, oder? Dann informiere Dich über die verschiedenen Programmiersprachen und entscheide Dich, welche Du _lernen_ willst, um ein Programm damit zu erstellen.

          Das ist prinzipiell richtig. Und es sollte auch der wichtigere Teil der Entscheidung sein.

          Beachte dabei auch, daß Compiler nicht immer kostenlos sind...

          Wenn ich aber eine komplette Entwicklungsumgebung incl. Debugger (z.B. Delphi2005 personal auf der letzten c't-DVD) kostenlos bekommen kann, dann kann der erste Teil der Frage plötzlich unwichtig sein - wenn ich zum Schluß gekommen bin, daß damit meine Aufgabe lösbar ist.

          Und wer bisher keine Sprache gelernt hat, für den ist es (fast) egal, welche Sprache er spricht. Wichtig ist doch, das Problem, welches mit der Software gelöst werden soll, richtig zu analysieren. Die Umsetztung ist dann der kleinere Schritt.

          Gruß Frank

      2. Woher bekomm' ich so 'nen Compiler?
        Und welche Programmiersprachen werden da unterstützt?

        Du scheinst dich da ja überhaupt nicht mit auszukennen. Ich versuche dir, das mal zu erklären.

        Compiler übersetzen den Code, was du geschrieben hast, in die Computersprache (also Nullen und Einsen). Heraus kommt eine EXE-Datei (engl. EXE = execute = ausführen). Ein Java-Compiler übersetzt nur Java-Quellcode, ein C-Compiler nur C-Quellcode.
        Compiler findest du wie Sand am Meer. Sie sind alle verschieden, manche kosten sogar etwas. Wenn du einen hast, dann kannst du mit der DOS-Box bzw. Konsole (bei Linux) den Quellcode übersetzen.
        Linux hat bei so was vorgesorgt, es liefert OpenSource-Compiler mit.

        DIE Programmiersprache für EXE-Dateien ist C bzw. C++ bzw. C# (die genauen Unterschiede kennt irgendwie keiner, nur dass C++ auf C basiert). Aber natürlich kannst du auch Java zum erstellen von EXE-Dateien verwenden, das ist überhaupt kein Problem. Die Erfahrung, die ich damit gemacht habe, ist, dass in C geschriebene Programme stabiler sind, als solche in Java oder VBA.

        Kurz: Besorge dir einen C-Compiler, und übersetze C-Quellcode.
              Nehme einen Java-Compiler, und übersetze Java-Quellcode.

        Beachte aber: Einige Compiler reagieren anders auf Fehler als wieder andere Compiler. Also, es kann sein, dass dir ein Compiler einen Fehler ausgibt, ein anderer aber nicht. Das gilt für alle Programmiersprachen, nicht nur C.

        Da du aber, wie ich vermute, noch nie programmiert hast, müsstest du zuerst programmieren lernen. Das ist erst primär zu erledigen, bevor du dich um einen Compiler kümmerst.

        Ich wünsche dir viel Glück, und vor allem viel Geduld
        kerta

        1. Hallo kerta,

          nur eine kleine Korrektur bzw. Ergänzung:

          DIE Programmiersprache für EXE-Dateien ist C bzw. C++ bzw. C# (die genauen Unterschiede kennt irgendwie keiner, nur dass C++ auf C basiert). Aber natürlich kannst du auch Java zum erstellen von EXE-Dateien verwenden, das ist überhaupt kein Problem. Die Erfahrung, die ich damit gemacht habe, ist, dass in C geschriebene Programme stabiler sind, als solche in Java oder VBA.

          Man kann zwar VBA-Code unter bestimmten Umständen in VB verwenden, aber VBA-Code als solcher läßt sich nicht kompilieren - im Unterschied zu VB.

          Zur Ausführung von VBA-Code braucht man die entsprechende Anwendung (z. B. Excel). Da der VBA-Code dann auch ausführbar ist, braucht man nicht mal eine exe (oder andere ausführbare Datei) zu erstellen. Es ist halt die Frage, was man genau vorhat.

          Viele Grüße

          Jörg

          1. Hi

            Du musst dich da ja besser auskennen als ich. Ich habe schon seit Jahren nicht mehr mit VB/VBA geschafft. Kannst du mir den Unterschied erklären?

            kerta

            1. Hallo kerta.

              Du musst dich da ja besser auskennen als ich. Ich habe schon seit Jahren nicht mehr mit VB/VBA geschafft. Kannst du mir den Unterschied erklären?

              Visual Basic und Visual Basic for Applications.

              Gruß, Ashura

              --
              Selfcode: sh:( fo:) ch:? rl:( br:^ n4:& ie:{ mo:) va:) de:> zu:) fl:( ss:| ls:[ js:|
              30 Days to becoming an Opera8 Lover -- Day 19: Notes
              Meine Browser: Opera 8.0 | Firefox 1.0.4 | Lynx 2.8.3 | Netscape 4.7 | IE 6.0
              [Deshalb frei! - Argumente pro freie Software]
            2. Hi

              Du musst dich da ja besser auskennen als ich. Ich habe schon seit Jahren nicht mehr mit VB/VBA geschafft. Kannst du mir den Unterschied erklären?

              Ganz einfach: Das A steht für Application und ist somit nur innerhalb einer anderen Anwendung lauffähig. Z.B. Makros in Word, Excel etc.

        2. Hej,

          DIE Programmiersprache für EXE-Dateien ist C bzw. C++ bzw. C#

          und noch viele mehr,

          (die genauen Unterschiede kennt irgendwie keiner, nur dass C++ auf C basiert).

          C ist eine prozedurale Programmiersprache, C++ ist wohl von der Mächtigkeit wie von den Spracheigenarten C sehr verwandt, verfolgt aber den objektorientierten Ansatz. C# (sprich C-sharp) ist wohl C, welches aber innerhalb des .NET-Frameworks seine Daseinsberechtigung fristet. Alle drei Sprachen sind gegenüber anderen Sprachen wie Java, Javascript oder Perl nicht Plattformunabhängig.

          Aber natürlich kannst du auch Java zum erstellen von EXE-Dateien verwenden, das ist überhaupt kein Problem.

          Du kannst nachdem du dein Java-Programm fertig hast zwar einen exe-Wrapper drum bauen, ist aber nie im Sinne des Erfinders gewesen und ist m.W. auch keine von Sun unterstützte Technik.
          a) Musst du die JRE mit einpacken und blähst damit jedes Java-Programm und sei es 'hello world' um AFAIK mindest 11 MB auf.
          b) Verlierst du die Plattformunabhängigkeit.

          Man kann aber Java Programme in ein JAR (JavaARchiv) einpacken welches sich, wenn eine JRE installiert ist, z.B. auch unter Windows durch doppelklick starten lässt. Oder unter Linux. Oder unter ...

          Die Erfahrung, die ich damit gemacht habe, ist, dass in C geschriebene Programme stabiler sind, als solche in Java oder VBA.

          Was verstehst du unter "stabil"? Für mich ist es stabil wenn das Programm z.B. nicht unerwartet durch Programmierfehler abstürzt. Leider ist die Gefahr fehlerhafte Programme zu schreiben unter C m.W. größer.

          Beachte aber: Einige Compiler reagieren anders auf Fehler als wieder andere Compiler. Also, es kann sein, dass dir ein Compiler einen Fehler ausgibt, ein anderer aber nicht.

          Ähm, das versteh ich jetzt nicht, hast du da ein Beispiel zu? Ein Compiler führt eine lexikalische, syntaktische und semantische Analyse durch. Alle drei Eigenschaften sind im Sprachstandard festgelegt und lassen dem Compiler meinen Verständnis nach keinen Spielraum. Wie kann da ein Compiler Fehler verzeihen ein, anderer nicht?

          Beste Grüße
          Biesterfeld

          --
          "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
          1. DIE Programmiersprache für EXE-Dateien ist C bzw. C++ bzw. C#

            und noch viele mehr,

            Das stimmt schon, aber sage mir bitte, welche am meisten verwendet wird, um Anwendungen (keine Webanwendungen) zu schreiben. Es wird eigentlich nur noch mit C programmiert. Ich glaube, das nicht ohne Grund.

            (die genauen Unterschiede kennt irgendwie keiner, nur dass C++ auf C basiert).

            C ist eine prozedurale Programmiersprache, C++ ist wohl von der Mächtigkeit wie von den Spracheigenarten C sehr verwandt, verfolgt aber den objektorientierten Ansatz. C# (sprich C-sharp) ist wohl C, welches aber innerhalb des .NET-Frameworks seine Daseinsberechtigung fristet.

            Also ist C# ein Microsoft-Produkt?

            Alle drei Sprachen sind gegenüber anderen Sprachen wie Java, Javascript oder Perl nicht Plattformunabhängig.

            C ist doch plattformunabhängig?! Du behauptest hier etwas falsches. Wäre doch sonst unsinnig, Compiler auf Linux und auf Windows anzubieten. Schaue doch mal bei Wikipedia:

            "C ist eine Programmiersprache, die auf fast allen Computersystemen zur Verfügung steht." => (fast) plattformunabhängig.

            Aber natürlich kannst du auch Java zum erstellen von EXE-Dateien verwenden, das ist überhaupt kein Problem.

            Du kannst nachdem du dein Java-Programm fertig hast zwar einen exe-Wrapper drum bauen, ist aber nie im Sinne des Erfinders gewesen und ist m.W. auch keine von Sun unterstützte Technik.

            Macht m.E. auch keiner.

            a) Musst du die JRE mit einpacken und blähst damit jedes Java-Programm und sei es 'hello world' um AFAIK mindest 11 MB auf.

            Bestes Beispiel: Die Opera-Installationsdatei. Mit Java ist es um fast 13,5 MB größer.

            b) Verlierst du die Plattformunabhängigkeit.

            Was ja bei C nicht der Fall ist, man muss es ja auch nicht in ein Archiv packen :)

            Die Erfahrung, die ich damit gemacht habe, ist, dass in C geschriebene Programme stabiler sind, als solche in Java oder VBA.

            Was verstehst du unter "stabil"? Für mich ist es stabil wenn das Programm z.B. nicht unerwartet durch Programmierfehler abstürzt. Leider ist die Gefahr fehlerhafte Programme zu schreiben unter C m.W. größer.

            Ein Programm empfinde ich (unter Window jedenfalls) stabil, wenn es sich, falls es einmal nicht mehr reagiert, sofort und ohne Murren über den Taskmanager beenden lässt. Etliche Programme lassen sich einfach nicht schließen, da nützt der beste Taskmanager nichts mehr, nur noch ein reboot.

            Beachte aber: Einige Compiler reagieren anders auf Fehler als wieder andere Compiler. Also, es kann sein, dass dir ein Compiler einen Fehler ausgibt, ein anderer aber nicht.

            Ähm, das versteh ich jetzt nicht, hast du da ein Beispiel zu? Ein Compiler führt eine lexikalische, syntaktische und semantische Analyse durch. Alle drei Eigenschaften sind im Sprachstandard festgelegt und lassen dem Compiler meinen Verständnis nach keinen Spielraum. Wie kann da ein Compiler Fehler verzeihen ein, anderer nicht?

            Ich hatte einmal solch einen Fall unter Java. Aber leider den Quellcode nicht mehr...
            Wenn sich doch alle Compiler an dieselben Regeln halten, warum gibt es dann verschiedene? Bräuchte man doch dann nicht mehr. Es gibt schon Unterschiede zwischen den Compilern (die ich im Detail aber nicht kenne), die von ihrer unterschiedlichen Programmierweise her rührt.

            kerta

            1. Hej,

              DIE Programmiersprache für EXE-Dateien ist C bzw. C++ bzw. C#

              und noch viele mehr,

              Das stimmt schon, aber sage mir bitte, welche am meisten verwendet wird, um Anwendungen (keine Webanwendungen) zu schreiben. Es wird eigentlich nur noch mit C programmiert. Ich glaube, das nicht ohne Grund.

              Ähm, mag schon sein, dass C und seine Derivate eine der am weitesten verbreiteten Sprachen sind. Nicht zuletzt wegen der Performance und Mächtigkeit. Andererseits bezweifel ich zum einen, dass es für einen offensichtlichen Anfänger die richtige Sprache ist, den Einstieg zu finden, zum anderen erfreun sich überhaupt auch viele andere Sprachen zunehmender Verbreitung.

              Im übrigen kenne ich inwzischen eine ganze Reihe hervorragender Programme die z.B. in Java oder Perl oder sogar Matlab implementiert sind. Es hängt eben immer sehr vom Einsatzgebiet ab.

              Also ist C# ein Microsoft-Produkt?

              Könnte man meinen, gell? ;)

              C ist doch plattformunabhängig?! Du behauptest hier etwas falsches.
              "C ist eine Programmiersprache, die auf fast allen Computersystemen zur Verfügung steht." => (fast) plattformunabhängig.

              Diese Interpretation ist es leider, die falsch ist. Bitte setze dich mit dem Begriff der Plattformunabhängigkeit auseinander. Nur soviel: Sobald du plattformnahe Aufgaben erledigen möchtest (z.B. Dateizugriffe) wirst du ein geschriebenes C-Programm nicht so ohne weiteres auf verschiedenen Plattformen ans laufen bekommen.

              Was verstehst du unter "stabil"? Für mich ist es stabil wenn das Programm z.B. nicht unerwartet durch Programmierfehler abstürzt. Leider ist die Gefahr fehlerhafte Programme zu schreiben unter C m.W. größer.

              Ein Programm empfinde ich (unter Window jedenfalls) stabil, wenn es sich, falls es einmal nicht mehr reagiert, sofort und ohne Murren über den Taskmanager beenden lässt. Etliche Programme lassen sich einfach nicht schließen, da nützt der beste Taskmanager nichts mehr, nur noch ein reboot.

              Und wo liegt da jetzt der Unterschied in der Wahl der Sprache begründet? Im Fall von Java kill ich z.B. schlicht den JRE-Prozess und Feierabend ist.

              Wie kann da ein Compiler Fehler verzeihen ein, anderer nicht?

              Ich hatte einmal solch einen Fall unter Java. Aber leider den Quellcode nicht mehr...

              ? Welche verschiedenen Compiler sind dir denn für Java bekannt? Ich kenn eigentlich nur javac, bzw. den, der mir von Eclipse mitgebracht wird, wobei natürlich ein IDE-Compiler auch eine ganz andere _Art_ von Fehlermeldung auspuckt.

              Beste Grüße
              Biesterfeld

              --
              "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
              1. Hallo,

                Also ist C# ein Microsoft-Produkt?

                Könnte man meinen, gell? ;)

                es wurde von MS erfunden, richtig. Die native Umgebung ist das .NET-Framework, auch richtig. Aber es ist insoweit plattformunabhängig als dass es auch Mono gibt. Siehe http://de.wikipedia.org/wiki/Mono-Projekt.

                C# hat übrigens mehr Ähnlichkeit zu Java als zu C oder C++.

                C ist doch plattformunabhängig?! Du behauptest hier etwas falsches.
                "C ist eine Programmiersprache, die auf fast allen Computersystemen zur Verfügung steht." => (fast) plattformunabhängig.

                Diese Interpretation ist es leider, die falsch ist. Bitte setze dich mit dem Begriff der Plattformunabhängigkeit auseinander. Nur soviel: Sobald du plattformnahe Aufgaben erledigen möchtest (z.B. Dateizugriffe) wirst du ein geschriebenes C-Programm nicht so ohne weiteres auf verschiedenen Plattformen ans laufen bekommen.

                Du irrst teilweise. Solche Sachen wie Dateizugriffe sind in den Standard-Bibliotheken, und die gibt es für jeden C-Compiler unter jedem Betriebssystem. Sicher, man kann plattformabhängige Programme schreiben in C. Aber auch plattformunabhängige. Genauso wie in C++.

                ? Welche verschiedenen Compiler sind dir denn für Java bekannt? Ich kenn eigentlich nur javac, bzw. den, der mir von Eclipse mitgebracht wird, wobei natürlich ein IDE-Compiler auch eine ganz andere _Art_ von Fehlermeldung auspuckt.

                Den von Sun und den von Eclipse hast du ja schon erwähnt, daneben gibt es noch Implementationen von Borland oder IBM. Es gibt nicht nur Sun, auch wenn die (leider) weiterhin die Hand über Java halten. Und damit IMO die Entwicklung zu sehr bremsen.

                Gruß,
                Martin

                1. Hej,

                  Aber es ist insoweit plattformunabhängig als dass es auch Mono gibt. Siehe http://de.wikipedia.org/wiki/Mono-Projekt.

                  C# hat übrigens mehr Ähnlichkeit zu Java als zu C oder C++.

                  Das hatte ich (wahrscheinlich während du das schriebst) auch nachgelesen. Danke für die Aufklärung.

                  Du irrst teilweise. Solche Sachen wie Dateizugriffe sind in den Standard-Bibliotheken, und die gibt es für jeden C-Compiler unter jedem Betriebssystem.

                  Hmm, aber ein einmal kompiliertes Programm ist eben nicht mehr plattformunabhängig. Wohingegen ich meinen Java-Bytecode jeder JRE (die zugegeben wiederrum plattformabhängig ist) zum Fressen geben kann.

                  Beste Grüße
                  Biesterfeld

                  --
                  "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
                  1. Hmm, aber ein einmal kompiliertes Programm ist eben nicht mehr plattformunabhängig. Wohingegen ich meinen Java-Bytecode jeder JRE (die zugegeben wiederrum plattformabhängig ist) zum Fressen geben kann.

                    Es heißt ja auch, dass die _Sprache_ plattforumunabhängig ist - und nicht die kompilierten Programme.
                    Zwar versucht Linux mit Windows-Emulatoren diese Plattforumabhängigkeit zu umgehen, was aber nie für alle Windows-EXE-Programme möglich sein wird. Aber ein Schritt in die richtige Richtung ist es schon.
                    PS: Ich habe keine Ahnung von Mac - haben die auch Windows-Emulatoren? Sind die besser als die auf Linux?

                    1. Hallo,

                      PS: Ich habe keine Ahnung von Mac - haben die auch Windows-Emulatoren?

                      Ja, aus dem Hause Microsoft gibt es Virtual PC.

                      Sind die besser als die auf Linux?

                      Keine Ahnung, nie verglichen. Solltest Du aber an WINE denken, nein Virtual PC ist ein Im-Fenster-Emulator

                      Tim

                  2. Hi,

                    Das hatte ich (wahrscheinlich während du das schriebst) auch nachgelesen. Danke für die Aufklärung.

                    gern geschehen.

                    Hmm, aber ein einmal kompiliertes Programm ist eben nicht mehr plattformunabhängig. Wohingegen ich meinen Java-Bytecode jeder JRE (die zugegeben wiederrum plattformabhängig ist) zum Fressen geben kann.

                    Aber du hast doch selbst den Link zu Wikipedia geschrieben. Da steht auch, dass es eine Plattformunabhängigkeit auf Quellcode-Ebene gibt.

                    Deinen Java-Bytecode kannst du auch nicht jeder JRE vorwerfen, da gibt es auch manch Unterschiede. Nachdem der Streit mit MS nun beigelegt ist versucht sich Sun ja an der VM von IBM.

                    Gruß,
                    Martin

                    1. Hej,

                      Aber du hast doch selbst den Link zu Wikipedia geschrieben. Da steht auch, dass es eine Plattformunabhängigkeit auf Quellcode-Ebene gibt.

                      Gut, gut, gut! Ich muss auch zugeben, dass ich mich außerhalb der Scriptsprachen nur mit Java auskenne. Mein restliches Wissen ist theoretischer Natur. Nichts desto trotz, für mich als Entwickler macht es aber einen enormen Unterschied ob ich wirklich nur eine Software vom Design bis zum kompilierten Produkt pflegen muss, oder mich ab einem Gewissen Punkt im Entwicklungsprozess gabeln muss.

                      Es bleibt aber dabei, dass Plattformunabhängigkeit nicht bedeutet, dass ich in einer Sprache für verschiedene Plattformen entwickeln kann.

                      Deinen Java-Bytecode kannst du auch nicht jeder JRE vorwerfen, da gibt es auch manch Unterschiede. Nachdem der Streit mit MS nun beigelegt ist versucht sich Sun ja an der VM von IBM.

                      Natürlich kann ich jetzt auch hingehen und irgendeine Schrott-Laufzeitumgebung enwicklen, die sich nicht an den Standard hält (nein, gut kann _ich_ nicht) und ihn JRE taufen.
                      Aber ich gehe davon aus, dass wenn mir Sun eine JRE für nen Windows PC und eine für meine Kaffeemaschine anbietet, dass beide auch meinen Bytecode gleich verarbeiten. Tun sie das denn nicht? Hast du da ein Beispiel für?

                      Beste Grüße
                      Biesterfeld

                      --
                      "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
                      1. Aber ich gehe davon aus, dass wenn mir Sun eine JRE für nen Windows PC und eine für meine Kaffeemaschine anbietet, dass beide auch meinen Bytecode gleich verarbeiten. Tun sie das denn nicht? Hast du da ein Beispiel für?

                        Der Bytecode von Java hat sich in der Version von 1.3 auf 1.4 Rückwärts-inkompatibel geändert. Java-1.4-Bytecode kann von einer Java-1.3-JRE nicht interpretiert werden.

                        Ich meine mich zu erinnern, dass für Java 1.5 zu Java 1.4 ähnliches gilt.

                        1. Hej,

                          Der Bytecode von Java hat sich in der Version von 1.3 auf 1.4 Rückwärts-inkompatibel geändert. Java-1.4-Bytecode kann von einer Java-1.3-JRE nicht interpretiert werden.
                          Ich meine mich zu erinnern, dass für Java 1.5 zu Java 1.4 ähnliches gilt.

                          Ja natürlich nicht! Aber dass das der berühmte Vergleich ist der hinkt, liegt doch auf der Hand? Versionsinkompatiblitäten aufzuführen wenn wir über Plattformunabhänggkeit sprechen ...

                          Beste Grüße
                          Biesterfeld

                          --
                          "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
                          1. Hi,

                            Ja natürlich nicht! Aber dass das der berühmte Vergleich ist der hinkt, liegt doch auf der Hand? Versionsinkompatiblitäten aufzuführen wenn wir über Plattformunabhänggkeit sprechen ...

                            Ist aber insofern relevant, das div. Versionen der JRE für verschiedene Plattformen unterschiedliche Erscheinungstermine haben.
                            Somit ist das Produkt zumindest zeitweise nicht Plattformunabhängig </wortklauberei>

                      2. Tagchen!

                        Nichts desto trotz, für mich als Entwickler macht es aber einen enormen Unterschied ob ich wirklich nur eine Software vom Design bis zum kompilierten Produkt pflegen muss, oder mich ab einem Gewissen Punkt im Entwicklungsprozess gabeln muss.

                        Für mich als Entwickler macht das keinen großen Unterschied, denn es kann immer einen Fehler geben, der sich dann beim Debuggen als Plattform-abhängig rausstellt. Irgendwo werden die Unterschiede zwischen den Plattformen halt aufgefangen, aber da komtm Murphys Gesetz zum Tragen.

                        Es bleibt aber dabei, dass Plattformunabhängigkeit nicht bedeutet, dass ich in einer Sprache für verschiedene Plattformen entwickeln kann.

                        Nö, das nicht.

                        Aber ich gehe davon aus, dass wenn mir Sun eine JRE für nen Windows PC und eine für meine Kaffeemaschine anbietet, dass beide auch meinen Bytecode gleich verarbeiten. Tun sie das denn nicht? Hast du da ein Beispiel für?

                        Aus dem Stegreif nicht, und ich bin so froh, dass ich mich seit 2 1/2 Monaten nicht mehr mit Java rumquälen muss. 3 Jahre haben mir gelangt.

                        Gruß,
                        Martin

              2. Sobald du plattformnahe Aufgaben erledigen möchtest (z.B. Dateizugriffe) wirst du ein geschriebenes C-Programm nicht so ohne weiteres auf verschiedenen Plattformen ans laufen bekommen.

                Das Beispiel ist falsch. Um auf Dateien zuzugreifen definiert die C-Standard-Bibliothek plattformunabhängige Funktionen.

            2. Hi,

              Bestes Beispiel: Die Opera-Installationsdatei. Mit Java ist es um fast 13,5 MB größer.

              Ja, aber nicht, weil die in Java geschrieben ist, sondern weil die eine Virtual Machine für Java mitbringt (damit Java-Code) ausgeführt werden kann.
              Das hat mit der Programmiersprache von Opera gar nix zu tun... ;))

              mfg
              -WebViper-

              --
              Real programmers confuse Halloween and Christmas because OCT 31 = DEC 25
            3. Hallo,

              Ein Programm empfinde ich (unter Window jedenfalls) stabil, wenn es sich, falls es einmal nicht mehr reagiert, sofort und ohne Murren über den Taskmanager beenden lässt. Etliche Programme lassen sich einfach nicht schließen, da nützt der beste Taskmanager nichts mehr, nur noch ein reboot.

              Du hast ein seltsames Verständnis von "stabil". Ein Programm, das das von dir beschriebene Verhalten zeigt (nämlich dass es nicht mehr reagiert), würde ich per se schon nicht mehr als stabil bezeichnen. Ein stabiles, zuverlässiges Programm macht sowas nicht.

              Ähm, das versteh ich jetzt nicht, hast du da ein Beispiel zu? Ein Compiler führt eine lexikalische, syntaktische und semantische Analyse durch. Alle drei Eigenschaften sind im Sprachstandard festgelegt und lassen dem Compiler meinen Verständnis nach keinen Spielraum. Wie kann da ein Compiler Fehler verzeihen ein, anderer nicht?

              Speziell bei den C-Compilern gibt es typischerweise zwei Stufen von Fehlern, nämlich Errors und Warnings.
              Bei den Errors handelt es sich in der Regel um klare Verletzungen der Sprachspezifikation, und daran gibt es üblicherweise nicht viel zu deuten.
              Aber ob ein Compiler bei bestimmten Anweisungen Warnungen ausgibt oder nicht, ist implementierungsabhängig, lässt sich teilweise sogar individuell an- und abschalten. Kandidaten für Warnings sind Anweisungen, die zwar syntaktisch richtig sind, aber im Kontext nicht eindeutig, fragwürdig oder ungewöhnlich.
              Zum Beispiel:

              if (k<0)                // Warning: Condition is always false
                                            [wenn k als unsigned deklariert ist]
                 while (c=check(input))  // Warning: Possibly incorrect assignment
                                            [vielleicht war hier ein Vergleich gemeint und keine Zuweisung]
                 ... and many more ...

              Hier liegt es tatsächlich im Ermessen des Compilerherstellers, solche Anweisungen mit einer Warnung zu kommentieren oder es bleiben zu lassen.

              So long,

              Martin

          2. (die genauen Unterschiede kennt irgendwie keiner, nur dass C++ auf C basiert).

            C ist eine prozedurale Programmiersprache, C++ ist wohl von der Mächtigkeit wie von den Spracheigenarten C sehr verwandt, verfolgt aber den objektorientierten Ansatz.

            C++ ist eine hybride Sprache, keine objekt-orientierte.

            C# (sprich C-sharp) ist wohl C,

            Nein, C# hat mit C nichts mehr gemeinsam.

            Alle drei Sprachen sind gegenüber anderen Sprachen wie Java, Javascript oder Perl nicht Plattformunabhängig.

            C# wird auch in Byte-Code übersetzt; das Runtime-Environment ist das .NET-Framework, dass unter Unix in der Implementation Mono zur Verfügung steht.

            Aber natürlich kannst du auch Java zum erstellen von EXE-Dateien verwenden, das ist überhaupt kein Problem.

            Du kannst nachdem du dein Java-Programm fertig hast zwar einen exe-Wrapper drum bauen, ist aber nie im Sinne des Erfinders gewesen und ist m.W. auch keine von Sun unterstützte Technik.
            a) Musst du die JRE mit einpacken und blähst damit jedes Java-Programm und sei es 'hello world' um AFAIK mindest 11 MB auf.

            Der gjc kann native Java-Binaries erstellen. Ohne, dass die JRE oder ähnliches notwendig ist.

            Beachte aber: Einige Compiler reagieren anders auf Fehler als wieder andere Compiler. Also, es kann sein, dass dir ein Compiler einen Fehler ausgibt, ein anderer aber nicht.

            Ähm, das versteh ich jetzt nicht, hast du da ein Beispiel zu? Ein Compiler führt eine lexikalische, syntaktische und semantische Analyse durch. Alle drei Eigenschaften sind im Sprachstandard festgelegt und lassen dem Compiler meinen Verständnis nach keinen Spielraum. Wie kann da ein Compiler Fehler verzeihen ein, anderer nicht?

            Viele Compiler haben proprietäre Erweiterungen (clrscr() im Borland C), einige Compiler sind grosszügiger was die Auslegung des Sprach-Standards angeht als andere. Es gibt Unterschiede, und manche sind gar nicht so klein.

            1. Hej,

              C# (sprich C-sharp) ist wohl C,

              Nein, C# hat mit C nichts mehr gemeinsam.

              Alle drei Sprachen sind gegenüber anderen Sprachen wie Java, Javascript oder Perl nicht Plattformunabhängig.

              C# wird auch in Byte-Code übersetzt; das Runtime-Environment ist das .NET-Framework, dass unter Unix in der Implementation Mono zur Verfügung steht.

              Bitte lies erst den ganzen Thread, das hatten wir inzwischen alles geklärt.

              Der gjc kann native Java-Binaries erstellen. Ohne, dass die JRE oder ähnliches notwendig ist.

              Und was nützts mir dann? Ja es geht und ja es ist sinnbefreit! Ob ich jetzt auf ein *.jar doppel klicke oder ein *.exe. Aber ja du hast recht, gibts auch.

              Viele Compiler haben proprietäre Erweiterungen (clrscr() im Borland C), einige Compiler sind grosszügiger was die Auslegung des Sprach-Standards angeht als andere. Es gibt Unterschiede, und manche sind gar nicht so klein.

              Aha ... wozu brauchen wir dann überhaupt noch Sprachstandards wenn gar die Dolmetscher nach eigenem Gusto übersetzen? Is mir langsam auch egal, mag es geben, habt mich überzeugt.

              Beste Grüße
              Biesterfeld

              --
              "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
              1. Der gjc kann native Java-Binaries erstellen. Ohne, dass die JRE oder ähnliches notwendig ist.

                Und was nützts mir dann?

                Ich kann Java-Applikationen ausliefern, ohne dass eine JRE vorhanden sein muss. Die Startup-Time verkürzt sich. Nur um mal zwei Vorteile zu nennen.

                Ja es geht und ja es ist sinnbefreit!

                Nur weil du es nicht brauchst gilt das noch lange nicht für jeden anderen.

                Viele Compiler haben proprietäre Erweiterungen (clrscr() im Borland C), einige Compiler sind grosszügiger was die Auslegung des Sprach-Standards angeht als andere. Es gibt Unterschiede, und manche sind gar nicht so klein.

                Aha ... wozu brauchen wir dann überhaupt noch Sprachstandards wenn gar die Dolmetscher nach eigenem Gusto übersetzen?

                Das ist wie bei HTML und JS. Da gibt es auch Standards, und sie werden auch nicht immer 100% eingehalten. So ist das halt im freien Wettbewerb...

                1. Hej,

                  Der gjc kann native Java-Binaries erstellen. Ohne, dass die JRE oder ähnliches notwendig ist.

                  Ups, hab da hatte ich gestern zu schlampig gelsen gehabt, bzw. falsch verstanden. Wusste nicht, dass es das gibt und kannte bisher nur die zwei Sorten exe-Wrapper: Die, die einmal die JRE einpacken und die, die es nicht tun und weiterhin auf eine Externe angewiesen sind.

                  Nur weil du es nicht brauchst gilt das noch lange nicht für jeden anderen.

                  Neee, wenn du so echte native Java-Binaries bekommst kann das selbsteverständlich sinnvoll sein. Danke für die Aufklärung.

                  Beste Grüße
                  Biesterfeld

                  --
                  "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
        3. Hi,

          Woher bekomm' ich so 'nen Compiler?
          Und welche Programmiersprachen werden da unterstützt?

          Du scheinst dich da ja überhaupt nicht mit auszukennen. Ich versuche dir, das mal zu erklären.

          Compiler übersetzen den Code, was du geschrieben hast, in die Computersprache (also Nullen und Einsen). Heraus kommt eine EXE-Datei (engl. EXE = execute = ausführen).

          Da hätt ich aber auch mal ne frage:
          Gibts sowas wie einen umkehr compiler,der eine exe datei in den quellcode verwandelt oder sind das nur einweg compilers so nach dem md5-crypt prinzip?
          Gruss
          Alain

          1. Hi,

            Gibts sowas wie einen umkehr compiler,der eine exe datei in den quellcode verwandelt oder sind das nur einweg compilers so nach dem md5-crypt prinzip?

            Ja und nein. Der Quelltext (der vielleicht noch einigermaßen verständlich ist) geht verloren. Was übrig bleibt, sind die maschinenlesbaren Befehle. Diese kannst Du Dir z.B. mit debug anschauen oder auch komfortablere Programme verwenden, die vielleicht ein wenig Übersicht verschaffen können. Nur ist es je größer das Programm ist umso schwieriger, hier noch einen Durchblick zu bekommen.

            freundliche Grüße
            Ingo

            1. Gibts sowas wie einen umkehr compiler,der eine exe datei in den quellcode verwandelt oder sind das nur einweg compilers so nach dem md5-crypt prinzip?

              Ja und nein. Der Quelltext (der vielleicht noch einigermaßen verständlich ist) geht verloren.

              Das stimmt nur bedingt. Solange Debugging-Symbole im Code sind, lässt sich relativ viel Code wiederherstellen.

              Ausserdem können moderne Disassembler viele Konstrukte direkt in C-Code übersetzen.

          2. Hej,

            Gibts sowas wie einen umkehr compiler,der eine exe datei in den quellcode verwandelt

            Dein Googlebgriff lautet Decompiler + <Programmiersprache> und ja die gibt es!

            oder sind das nur einweg compilers so nach dem md5-crypt prinzip?

            Mein Wissen ist zwar rein theoretischer Natur, aber es muss eine gewisse Eindeutigkeit zwischen Maschinensprache oder Bytecode zur verwendeten Programmiersprache geben. Allerdings beachte, dass beim Übersetzen (wie es jeder gute Dolmetscher macht) Optimierungen vorgenommen werden. Das Produkt aus compilen -> decompilen, muss also nicht mit dem Edukt identisch, sollte aber gleichen "Inhalts" sein.

            Beste Grüße
            Biesterfeld

            --
            "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
          3. Hi,

            Da hätt ich aber auch mal ne frage:
            Gibts sowas wie einen umkehr compiler,der eine exe datei in den quellcode verwandelt oder sind das nur einweg compilers so nach dem md5-crypt prinzip?

            Auch wenn du es schaffst, mit einem Decompiler halbwegs lesbaren Quellcode zu erzeugen, sollte erwähnt werden, das es bei ziemlch allen komerziellen Programmen verboten ist, die Software zu dekompilieren.

            1. Hi,

              Auch wenn du es schaffst, mit einem Decompiler halbwegs lesbaren Quellcode zu erzeugen, sollte erwähnt werden, das es bei ziemlch allen komerziellen Programmen verboten ist, die Software zu dekompilieren.

              Es ist bei keinem Programm verboten es zu dekompilieren. Nur was Du danach mit dem Dekompilat anstellst unterliegt Einschränkungen.

              so short

              Christoph Zurnieden

              1. Hallo Christoph,

                Es ist bei keinem Programm verboten es zu dekompilieren. Nur was Du danach mit dem Dekompilat anstellst unterliegt Einschränkungen.

                Hm? Ich habe gerade mal den Softwarelizenzvertrag von Mac OS X 10.4 heraus gekramt, dort steht:

                »Sie verpflichten sich, es zu unterlassen, die Apple Software zu kopieren,
                  dekompilieren, zurückzuentwickeln oder disassemblieren (..)«

                Meiner Erfahrung nach steht ähnliches in den meisten Lizenzverträgen kommerzieller Software. Sprichst Du eventuell von einem anderen Konzept?

                Tim

                1. Hi,

                  Meiner Erfahrung nach steht ähnliches in den meisten Lizenzverträgen kommerzieller Software.

                  Papier ist geduldig.

                  Sprichst Du eventuell von einem anderen Konzept?

                  Ja, siehe §69e.
                  Die Vertragsfreiheit unterliegt zudem in D. auch Einschränkungen, wenn auch sehr wenigen.

                  so short

                  Christoph Zurnieden

                  1. Hallo Christoph,

                    Ja, siehe §69e.

                    Ah, Danke Dir.

                    Tim

                  2. Hi,

                    Ja, siehe §69e.
                    Die Vertragsfreiheit unterliegt zudem in D. auch Einschränkungen, wenn auch sehr wenigen.

                    Also ich lese das so, das ein Programm nicht einfach wegen Neugierde o.ä. decompiliert werden darf, bzw. dann nicht ohne Zustimmung des Rechteinhabers.

                    Aber dennoch interessant zu wissen. Danke für die Info

                    1. Hi,

                      Also ich lese das so, das ein Programm nicht einfach wegen Neugierde o.ä. decompiliert werden darf, bzw. dann nicht ohne Zustimmung des Rechteinhabers.

                      Der dort verwandte Begriff "Interoperabilität" ist _sehr_ dehnbar >;->

                      Ein wenig beklopft ist es sowieso. Laut diesem Gesetz wäre es sogar verboten, ein OpenSource-Programm zu dekompilieren. Die Genehmigung dafür liegt ja nicht vor und §69e,1,2:
                      " die für die Herstellung der Interoperabilität notwendigen Informationen sind für die in Nummer 1 genannten Personen noch nicht ohne weiteres zugänglich gemacht;"
                      trifft auch nicht zu, da die Quellen ja verfügbar sind. Ergo: ein Opensourceprogramm darf nicht dekompiliert werden, das _gleiche_ Programm in der Closed-Source-Variante darf jedoch.

                      Das ist aber nicht die einzige merkwürdige Stelle bezüglich Computern im UrhG, da müßte unbedingt mal versäubert werden.

                      so short

                      Christoph Zurnieden

                      1. Hallo.

                        Ergo: ein Opensourceprogramm darf nicht dekompiliert werden, das _gleiche_ Programm in der Closed-Source-Variante darf jedoch.

                        Eine ernst gemeinte Frage: Welchem Zweck könnte das Dekompilieren von quelltextoffener Software dienen?
                        MfG, at

                        1. Hallo at,

                          Eine ernst gemeinte Frage: Welchem Zweck könnte das Dekompilieren von quelltextoffener Software dienen?

                          Keinem, soweit ich das überblicken kann.
                          Das war von Christoph wahrscheinlich nur als konstruiertes Beispiel gemeint, um die Absurdität der Vorschrift zu demonstrieren.

                          Ciao,

                          Martin

                        2. 你好 at,

                          Ergo: ein Opensourceprogramm darf nicht dekompiliert werden, das
                          _gleiche_ Programm in der Closed-Source-Variante darf jedoch.

                          Eine ernst gemeinte Frage: Welchem Zweck könnte das Dekompilieren von
                          quelltextoffener Software dienen?

                          Debugging; manchmal ist das, was man programmiert hat und das, was der
                          Compiler daraus gemacht hat nicht zwingend ähnlich. Ausserdem gibt es ganz
                          gern auch schonmal manipulierte Binaries -- in dem Fall dann Reverse
                          Engeniering.

                          再见,
                          克里斯蒂安

                          --
                          Der Mund ist das Portal zum Unglück.
                          http://wwwtech.de/
                          1. Hallo.

                            Debugging; manchmal ist das, was man programmiert hat und das, was der
                            Compiler daraus gemacht hat nicht zwingend ähnlich. Ausserdem gibt es ganz
                            gern auch schonmal manipulierte Binaries -- in dem Fall dann Reverse
                            Engeniering.

                            Danke für die Erleuchtung.
                            MfG, at

                      2. Hi,

                        trifft auch nicht zu, da die Quellen ja verfügbar sind. Ergo: ein Opensourceprogramm darf nicht dekompiliert werden, das _gleiche_ Programm in der Closed-Source-Variante darf jedoch.

                        In dem Fall greift aber doch die entsprechende Lizenz, und soweit ich weiss, ist es bei den meisten OS Lizenzen ausdrücklich erlaubt, zu decompilieren. Diese Aussage erfolgt aber ohne Gewähr ;)

                        1. Hi,

                          In dem Fall greift aber doch die entsprechende Lizenz, und soweit ich weiss, ist es bei den meisten OS Lizenzen ausdrücklich erlaubt, zu decompilieren. Diese Aussage erfolgt aber ohne Gewähr ;)

                          Ich kann zwar jetzt schwerlich _alle_ Lizenzen kontrollieren, aber in den mir untergekommenen steht höchstens etwas davon, das es verboten ist, nicht, das es erlaubt sei. Das "die meisten" trifft also nicht so ganz zu.

                          so short

                          Christoph Zurnieden

      3. Hej,

        Woher bekomm' ich so 'nen Compiler?

        Sam, vielleicht erzählst du uns mal so ein bisschen, was du überhaupt vorhast. Weil, wie dir bereits mitgeteilt wurde, hast du einen etwas falschen Blick auf die Dinge.

        Und welche Programmiersprachen werden da unterstützt?

        Welche 'sprichst' du denn?

        Beste Grüße
        Biesterfeld

        --
        "Nein! ... Nein, schneller, leichter, verführerischer die dunkle Seite ist."
  3. Hallo Sam,

    versuch es mal mit: http://www.openwatcom.org/.

    Gruß, Jürgen