Hallo Liste, hallo Egbert,
Du schriebst:
Frank Heckenbach (14.Jan 2003 (23:42 (+0100))):
Andreas K. Foerster schrieb:
liest hier überhaupt jemand mit?
Nein. ;-) Frank
Echt schade was? Grüße Egbert
Naja, so ganz niemand liest ja hier auch nicht mit. ;-)
Fröhliche Grüße Roland
On Fri, Jan 17, 2003 at 06:46:23AM +0100, Dr. Egbert Seibertz wrote:
Mitlesen ist gut gesagt: Ich würd's ja tun, nur es gibt nichts mitzulesen ... Andererseits kann man das ja auch gutes Zeichen werten: Keine Fragen somit keine Probleme!
Oder der gpc ist doch nicht so beliebt.
Ich weiß nicht, ob das hier so angebracht ist, aber ich hätte doch ein paar Sachen an dem auszusetzen...
Zum einen ist der auf manchen Systemen viel zu kompliziert zu installieren. Er braucht den gcc oder djgpp oder emx oder cygwin oder mingw32 oder djgpp oder emx und einen Assembler und Linker... und möglichst alles noch im Quellcode und in der richtigen Version. Wer soll da noch durchschauen? Und er ist noch bei viel zu wenig Distributionen dabei. Bei meiner war in Sachen Pascal zB. nur der p2c dabei. :-(
Zum anderen hab ich das Problem, dass Programme, die man damit erstellt, viel zu groß werden (trotz Optimierung). Ein Programm, das ich unter GNU/Linux mal mit GNU Pascal und mal mit FreePascal compiliert habe, wurde mit GNU Pascal mehr als 10 mal so groß! Außerdem war das Ergebnis vom gpc im Gegensatz zum Ergebnis von fpc auch noch dynamisch gelinkt, so dass man nicht einfach das fertige Programm veröffentlichen kann. Was bringt das dynamische Linken, wenn das Programm trotzdem größer wird?
... nun gut, ich will nicht sagen, dass der fpc in jedem Fall besser ist. Bei dem gibt es auch genug, worüber man meckern könnte. Am besten wäre wirklich, wenn sich beide zusammen täten... falls das überhaupt noch möglich ist.
Was ich aber wirklich noch suche, wäre ein freier 16-Bit Compiler (für FreeDOS).
Hallo zusammen!
On Fri, Jan 17, 2003 at 09:51:57AM +0100, Andreas K. Foerster wrote:
Ich weiß nicht, ob das hier so angebracht ist, aber ich hätte doch ein paar Sachen an dem [GPC] auszusetzen...
Au ja, nur her damit. :-)
Zum einen ist der auf manchen Systemen viel zu kompliziert zu installieren. Er braucht den gcc oder djgpp oder emx oder cygwin oder mingw32 oder djgpp oder emx und einen Assembler und Linker... und möglichst alles noch im Quellcode und in der richtigen Version. Wer soll da noch durchschauen? Und er ist noch bei viel zu wenig Distributionen dabei. Bei meiner war in Sachen Pascal zB. nur der p2c dabei. :-(
Es sollte unter Linux (je nach Distributionsart) reichen, ein 'apt-get' oder 'rpm' auszuführen. Dazu müssen aber bestimmte Vorikkehrungen getroffen werden: jemand muss sich hinsetzen und diese Pakete zusammenstellen.
Für Windows gibt es schon so ein Paket, siehe http://www.gnu-pascal.de/contrib/chief/
Zum anderen hab ich das Problem, dass Programme, die man damit erstellt, viel zu groß werden (trotz Optimierung).
Festplattenplatz ist im Zeitalter der 100GB-Platten nicht mehr das grosse Problem. Viel stärker zu bewerten ist die Ausführungsgeschwindigkeit. Wenn du Dir die Größen der mit GPC erstellten ausführbaren Dateien anschaust, so stellst Du fest, dass diese auch nicht mehr beliebig stark anwächst, auch wenn du eine doppelte Quellcodelänge verwendest. Am Anfang werden eben solche rudimentären Sachen wie die Mathe-Bibliothek dazugebunden, die unglaublich viel Platz wegnehmen.
Mit dem Programmm `strip` kannst Du die Dateigröße ein wenig herabsetzen.
Außerdem war das Ergebnis vom gpc im Gegensatz zum Ergebnis von fpc auch noch dynamisch gelinkt, so dass man nicht einfach das fertige Programm veröffentlichen kann.
Die Option -static kann dabei statisch gelinkten Code erzeugen.
Am besten wäre wirklich, wenn sich beide zusammen täten... falls das überhaupt noch möglich ist.
Nein, ist es nicht. Beide Projekte haben eine unterschiedliche Zielsetzung, die nicht in einem Compiler vereinbar ist.
Was ich aber wirklich noch suche, wäre ein freier 16-Bit Compiler (für FreeDOS).
Früher oder später nutzt Du doch, wegen der unendlich größeren Vielfalt an Möglichkeiten eh Linux. Warum nicht jetzt? ;-)
Eike
On Fri, Jan 17, 2003 at 11:41:48AM +0100, Eike Lange wrote:
On Fri, Jan 17, 2003 at 09:51:57AM +0100, Andreas K. Foerster wrote:
Ich weiß nicht, ob das hier so angebracht ist, aber ich hätte doch ein paar Sachen an dem [GPC] auszusetzen...
Au ja, nur her damit. :-)
Zum einen ist der auf manchen Systemen viel zu kompliziert zu installieren. Er braucht den gcc oder djgpp oder emx oder cygwin oder mingw32 oder djgpp oder emx und einen Assembler und Linker... und möglichst alles noch im Quellcode und in der richtigen Version. Wer soll da noch durchschauen? Und er ist noch bei viel zu wenig Distributionen dabei. Bei meiner war in Sachen Pascal zB. nur der p2c dabei. :-(
Es sollte unter Linux (je nach Distributionsart) reichen, ein 'apt-get' oder 'rpm' auszuführen.
Bei mir weder noch - Slackware. ;->
Aber unter Linux hab ich das am laufen. Da waren die angebotenen Binärdateien für schon in Ordnung. Auch wenn es schon seltsam war, dass man es nochmal mit dem gcc runterladen musste, nur weil die Versionsnummer nicht ganz übereinstimmte. :-\
Aber unter Dos und Windows sah ich erstmal den Wald vor lauter Bäumen nicht. :-(
Dazu müssen aber bestimmte Vorikkehrungen getroffen werden: jemand muss sich hinsetzen und diese Pakete zusammenstellen.
Genau das wollte ich vorschlagen. (der Schreibfehler deutet auf vi hin, richtig? ;-) )
Für Windows gibt es schon so ein Paket, siehe http://www.gnu-pascal.de/contrib/chief/
Ah, da werd'ich nochmal schauen... Danke! :-)
Kann man das auch über die Homepage finden? Das dürft ihr auch nicht so gut verstecken!
Zum anderen hab ich das Problem, dass Programme, die man damit erstellt, viel zu groß werden (trotz Optimierung).
Festplattenplatz ist im Zeitalter der 100GB-Platten nicht mehr das große Problem.
Urks! Da haben wir doch recht unterschiedliche Vorstellungen. Festplattenplatz ist vielleicht wirklich kein Problem mehr, aber für die Weitergabe Diskettenplatz... und vor allem Downloadzeit!
Man kann heute doch noch nicht davon ausgehen, dass jeder selbst einen passenden Compiler hat - vor allem bei Pascal! <del> vielleicht bei Visual Basic. >:->>> </del>
Viel stärker zu bewerten ist die Ausführungsgeschwindigkeit.
Okay, das akzeptiere ich als Argument. Das habe ich noch nicht getestet.
Wenn du Dir die Größen der mit GPC erstellten ausführbaren Dateien anschaust, so stellst Du fest, dass diese auch nicht mehr beliebig stark anwächst, auch wenn du eine doppelte Quellcodelänge verwendest. Am Anfang werden eben solche rudimentären Sachen wie die Mathe-Bibliothek dazugebunden, die unglaublich viel Platz wegnehmen.
Was ist mit "Smartlinking"...? In dem Fall würde ich auch dynamisches Bibliotheken gutheißen: Entweder ganz, oder gar nicht.
Mit dem Programmm `strip` kannst Du die Dateigröße ein wenig herabsetzen.
bekannt.
Außerdem war das Ergebnis vom gpc im Gegensatz zum Ergebnis von fpc auch noch dynamisch gelinkt, so dass man nicht einfach das fertige Programm veröffentlichen kann.
Die Option -static kann dabei statisch gelinkten Code erzeugen.
...und noch riesigeren.
Am besten wäre wirklich, wenn sich beide zusammen täten... falls das überhaupt noch möglich ist.
Nein, ist es nicht. Beide Projekte haben eine unterschiedliche Zielsetzung, die nicht in einem Compiler vereinbar ist.
Hmmm? Meinst du standard Pascal versus Borland Pascal? Das versucht gpc ja schon zu vereinen und das ist wirklich der große Pluspunkt, den ich dem gebe.
Oder meinst du, dass die nichts vom "Copyleft" halten? Nun, in der Frage bin ich selbst noch gespalten.
Was ich aber wirklich noch suche, wäre ein freier 16-Bit Compiler (für FreeDOS).
Früher oder später nutzt Du doch, wegen der unendlich größeren Vielfalt an Möglichkeiten eh Linux. Warum nicht jetzt? ;-)
Oh doch, das benutze ich schon lange für meine ernsthaften Sachen.
Aber meine alten Maschinchen würde ich nur ungern wegschmeißen müssen; und meine alten Spielchen erst recht nicht.
Außerdem kann man mit FreeDOS schön mal eben schnell eine selbstbootende Diskette oder CD machen. Mit Linux ginge das uU. zwar auch, aber längst nicht so schön einfach und platzsparend. Manche nehmen das auch für eingebettete Systeme...
Also ein 16-Bit DOS hat auch in heutiger Zeit noch seine Nischen. Mit FreeDOS gibt es auch eine freie Variante, es fehlen halt nur freie Compiler. Über die Lizenz von OpenWatcom kann man ja auch streiten...
Übrigens Linux wird ja auch auf 16-Bit portiert (Stichwort ELKS). Aber jetzt bin ich völlig vom Thema abgekommen, sorry.
Andreas K. Foerster schrieb:
Zum anderen hab ich das Problem, dass Programme, die man damit erstellt, viel zu groß werden (trotz Optimierung).
Festplattenplatz ist im Zeitalter der 100GB-Platten nicht mehr das große Problem.
Urks! Da haben wir doch recht unterschiedliche Vorstellungen. Festplattenplatz ist vielleicht wirklich kein Problem mehr, aber für die Weitergabe Diskettenplatz... und vor allem Downloadzeit!
Downloadzeit sehe ich vielleicht noch ein (andererseits, wenn ich mir meine Server-Logs so anschaue, habe ich den Eindruck, dass sich viele auch 20 MB-Dateien erst mal runterladen, bevor sie überlegen, ob sie sie brauchen ...), Diskettenplatz eher weniger. Ein kurzes Programm braucht bei mir ca. 100 KB (gestrippt und bzip2-komprimiert), statisch gelinkt 150 KB. Das ist gerade mal 1/10 einer Diskette ...
Wenn du Dir die Größen der mit GPC erstellten ausführbaren Dateien anschaust, so stellst Du fest, dass diese auch nicht mehr beliebig stark anwächst, auch wenn du eine doppelte Quellcodelänge verwendest. Am Anfang werden eben solche rudimentären Sachen wie die Mathe-Bibliothek dazugebunden, die unglaublich viel Platz wegnehmen.
Was ist mit "Smartlinking"...?
Ich habe ein paar Ideen dazu, und werde es irgendwann mal probieren.
In dem Fall würde ich auch dynamisches Bibliotheken gutheißen: Entweder ganz, oder gar nicht.
Prinzipiell geht das auch. Allerdings muss man dabei mit den Versionen aufpassen (bei den Systembibliotheken z.B. zwischen verschiedenen Linux-Distributionen, und die GPC-Laufzeitbibliothek ändert sich i.a. mit jeder GPC-Version). Da erfahrungsgemäß etliche Leute damit Probleme hätten und letztlich mir dann wieder zusätzliche Arbeit beim Fehler-Beheben verursachen würden, lasse ich diese Möglichkeit vorerst "undokumentiert".
Am besten wäre wirklich, wenn sich beide zusammen täten... falls das überhaupt noch möglich ist.
Nein, ist es nicht. Beide Projekte haben eine unterschiedliche Zielsetzung, die nicht in einem Compiler vereinbar ist.
Hmmm? Meinst du standard Pascal versus Borland Pascal? Das versucht gpc ja schon zu vereinen und das ist wirklich der große Pluspunkt, den ich dem gebe.
Aber FPC leider nicht. Von Standard-Pascal halten die Entwickler nicht viel. Ähnlich sieht es bei Portabilität aus. FPC hält am dem BP-Prinzip fest, Code nur für ein System zu schreiben, während GPC-Code i.a. auf jedem System laufbar sein sollte.
Oder meinst du, dass die nichts vom "Copyleft" halten?
Doch, in diesem Punkt sind sich beide Compiler einig.
Außerdem kann man mit FreeDOS schön mal eben schnell eine selbstbootende Diskette oder CD machen. Mit Linux ginge das uU. zwar auch, aber längst nicht so schön einfach und platzsparend. Manche nehmen das auch für eingebettete Systeme...
Also ein 16-Bit DOS hat auch in heutiger Zeit noch seine Nischen. Mit FreeDOS gibt es auch eine freie Variante, es fehlen halt nur freie Compiler. Über die Lizenz von OpenWatcom kann man ja auch streiten...
GCC/GPC auf 16-Bit-Systeme zu portieren, dürfte schwer bis unmöglich sein. -- Ich weiß, RMS hat so was vor etlichen Jahren mal zu DJ Delorie gesagt, und heraus kam dann DJGPP. Aber das ist halt ein 32-Bit Dos-Extender. Läuft das eigentlich inzwischen unter FreeDOS? Wenn ja, wäre das wohl eine Lösung (für 386+). (DJGPP selbst muss ja nicht installiert sein, um ein DJGPP-compiliertes Program auszuführen, lediglich ggf. cwsdpmi (20 KB)).
Für Windows gibt es schon so ein Paket, siehe http://www.gnu-pascal.de/contrib/chief/
Muss man dafür auch noch diese riesige MinGW ziehen? Inakzeptabel! :-(
Tja, beschwer dich bei Microsoft, dass sie so viele wesentliche Systemkomponenten weglassen ...
Frank
On Sun, Jan 19, 2003 at 03:48:54AM +0100, Frank Heckenbach wrote:
Urks! Da haben wir doch recht unterschiedliche Vorstellungen. Festplattenplatz ist vielleicht wirklich kein Problem mehr, aber für die Weitergabe Diskettenplatz... und vor allem Downloadzeit!
Downloadzeit sehe ich vielleicht noch ein (andererseits, wenn ich mir meine Server-Logs so anschaue, habe ich den Eindruck, dass sich viele auch 20 MB-Dateien erst mal runterladen, bevor sie überlegen, ob sie sie brauchen ...),
Aber bestimmt nicht die Leute mit analogen Modems (wie ich).
Diskettenplatz eher weniger. Ein kurzes Programm braucht bei mir ca. 100 KB (gestrippt und bzip2-komprimiert), statisch gelinkt 150 KB. Das ist gerade mal 1/10 einer Diskette ...
Nun gut, wenn du _ein_ großes Programm schreibst mag das okay sein. Aber wenn du viele kleine Tools schreibst, wird das doch zum Problem.
In dem Fall würde ich auch dynamisches Bibliotheken gutheißen: Entweder ganz, oder gar nicht.
Prinzipiell geht das auch. Allerdings muss man dabei mit den Versionen aufpassen (bei den Systembibliotheken z.B. zwischen verschiedenen Linux-Distributionen, und die GPC-Laufzeitbibliothek ändert sich i.a. mit jeder GPC-Version). Da erfahrungsgemäß etliche Leute damit Probleme hätten und letztlich mir dann wieder zusätzliche Arbeit beim Fehler-Beheben verursachen würden, lasse ich diese Möglichkeit vorerst "undokumentiert".
Wenn man viele kleine Tools schreibt, macht es durchaus auch Sinn, die Bibliothek separat dabeizulegen.
Die Möglichkeit gibt es also schon? Es wäre vielleicht doch gut, wenn ihr die mal dokumentieren könntet. Ihr könnt ja dabei schreiben, dass ihr davon abratet.
Nunja, aber gerade hier liegt der große Vorteil von FPC. Die machen kleinere Binärdateien (ua. auch durch Smartlinking) und für die libc haben die auch einen Ersatz in Pascal selbst geschrieben. Vor allem aber unter DOS/Windows muss man weit weniger Aufwand treiben. Dafür gibt es aber wiederum den GPC für weitaus mehr Systeme...
Hmmm? Meinst du standard Pascal versus Borland Pascal? Das versucht gpc ja schon zu vereinen und das ist wirklich der große Pluspunkt, den ich dem gebe.
Aber FPC leider nicht. Von Standard-Pascal halten die Entwickler nicht viel.
Ja, wie gesagt, das ist der große Pluspunkt von GPC gegenüber FPC. Ein anderer ist, dass es auch den Compiler selbst für wesentlich mehr Systeme gibt.
Ähnlich sieht es bei Portabilität aus. FPC hält am dem BP-Prinzip fest, Code nur für ein System zu schreiben, während GPC-Code i.a. auf jedem System laufbar sein sollte.
Nunja, FPC geht auch dazu über, abstraktere Units zu schreiben. Und der Weg ist vielleicht auch gut so. So hat man dann sowohl systemspezifische, als auch abstrakte Units zur Verfügung und kann beim Programmieren selbst wählen, ob einem Portabilität oder Effizienz wichtiger ist.
Nunja, das betrifft nur die Portabilität zwischen verschiedenen Plattformen. Code zu schreiben, der mit verschiedenen Compilern läuft, ist mit deren Ansatz wirklich schwer. :-(
Damit musste ich auch schon eine leidliche Erfahrung machen, als ich versuchte, ein Programm, das ich für FPC geschrieben habe, mit GPC zu compilieren. (Mehr dazu in einer privaten Mail)
GCC/GPC auf 16-Bit-Systeme zu portieren, dürfte schwer bis unmöglich sein. --
Ich sagte auch nur, dass ich einen freien 16-Bit Compiler /suche/. Also wenn jemand einen für DOS kennt, bitte bescheid sagen. Es kann zur Not auch ein Interpreter sein.
Ich weiß, RMS hat so was vor etlichen Jahren mal zu DJ Delorie gesagt, und heraus kam dann DJGPP. Aber das ist halt ein 32-Bit Dos-Extender. Läuft das eigentlich inzwischen unter FreeDOS? Wenn ja, wäre das wohl eine Lösung (für 386+). (DJGPP selbst muss ja nicht installiert sein, um ein DJGPP-compiliertes Program auszuführen, lediglich ggf. cwsdpmi (20 KB)).
Ja doch, das müsste laufen. Den cwsdpmi braucht man. Man darf nur nicht den EMM386 von FreeDOS laden! Die beißen sich. (...falls mal jemand fragt)
Probiert habe ich das bisher zwar nur mit FreePascal, aber wenn es damit läuft, dürfte GNU Pascal ja auch kein Problem sein. Der DJGPP steht bei denen auch in der Linkliste als Empfehlung. Und ich glaube, die grafische Benutzeroberfläche SEAL wurde damit auch geschrieben.
Nur wenn man was schreiben will, das direkt ins System aufgenommen werden soll, akzeptieren die halt keine 32-Bit Programme. Das System hat halt vor allem alte Maschinen als Zielsetzung.
Der Tatstaturtreiber war in BP geschrieben und wird jetzt auf C portiert. :-(
Für Windows gibt es schon so ein Paket, siehe http://www.gnu-pascal.de/contrib/chief/
Muss man dafür auch noch diese riesige MinGW ziehen? Inakzeptabel! :-(
Tja, beschwer dich bei Microsoft, dass sie so viele wesentliche Systemkomponenten weglassen ...
Ich soll mich also darüber beschweren, dass Windows nicht Unix ist? ...andererseits der Ratschlag, sich bei Microsoft zu beschweren ist immer gut. >;->>>
Frage: Braucht man MinGW nur zum Compilieren, oder muss der Endanwender das auch haben?
Nunja, für Windows sehe ich nun leider GPC nicht als akzeptable Alternative zu FPC an. Da muss ich wohl erstmal weiter bei Borland Syntax bleiben, obwohl ich das auch als Problem ansehe.
Andreas K. Foerster schrieb:
Wenn man viele kleine Tools schreibt, macht es durchaus auch Sinn, die Bibliothek separat dabeizulegen.
Ja, in dem Fall wohl schon.
Die Möglichkeit gibt es also schon? Es wäre vielleicht doch gut, wenn ihr die mal dokumentieren könntet. Ihr könnt ja dabei schreiben, dass ihr davon abratet.
Kurz gesagt, `WITH_SHARED=yes' auf der make-Kommandozeile angeben (wenn man GPC baut bzw. zumindest das RTS neu baut). Getestet habe ich es bisher nur unter Linux -- es kann sein, dass die Optionen zum Bauen der dynamischen Bibliotheken noch etwas angepasst werden müssen, das würde dann kleinere Änderungen im RTS-Makefile erfordern ...
Ich weiß, RMS hat so was vor etlichen Jahren mal zu DJ Delorie gesagt, und heraus kam dann DJGPP. Aber das ist halt ein 32-Bit Dos-Extender. Läuft das eigentlich inzwischen unter FreeDOS? Wenn ja, wäre das wohl eine Lösung (für 386+). (DJGPP selbst muss ja nicht installiert sein, um ein DJGPP-compiliertes Program auszuführen, lediglich ggf. cwsdpmi (20 KB)).
Ja doch, das müsste laufen. Den cwsdpmi braucht man. Man darf nur nicht den EMM386 von FreeDOS laden! Die beißen sich. (...falls mal jemand fragt)
Probiert habe ich das bisher zwar nur mit FreePascal, aber wenn es damit läuft, dürfte GNU Pascal ja auch kein Problem sein. Der DJGPP steht bei denen auch in der Linkliste als Empfehlung. Und ich glaube, die grafische Benutzeroberfläche SEAL wurde damit auch geschrieben.
Werde ich mir bei Gelegenheit mal anschauen. Ich hatte FreeDOS vor etlichen Jahren mal getestet, als es praktisch noch unbenutzbar war. Aber da ich eh nicht viel unter Dos mache, außer GPC da zu testen, muss ich mal sehen, wann ich dazu komme ...
Muss man dafür auch noch diese riesige MinGW ziehen? Inakzeptabel! :-(
Tja, beschwer dich bei Microsoft, dass sie so viele wesentliche Systemkomponenten weglassen ...
Ich soll mich also darüber beschweren, dass Windows nicht Unix ist?
Das vielleicht auch ;-), aber das meinte ich nicht unbedingt. Die ganzen Programme, die bei MinGW und CygWin dabei sind, laufen ja offensichtlich unter Windows, ohne dass es Unix ist, und MS könnte entweder die Programme selbst oder welche mit gleicher Funktionalität (z.B. eine vernünftige Shell und vieles andere) mitliefern, wenn sie nur wollten.
Frage: Braucht man MinGW nur zum Compilieren, oder muss der Endanwender das auch haben?
Soweit ich weiß ersteres.
Frank
On Fri, Jan 17, 2003 at 11:41:48AM +0100, Eike Lange wrote:
Für Windows gibt es schon so ein Paket, siehe http://www.gnu-pascal.de/contrib/chief/
Muss man dafür auch noch diese riesige MinGW ziehen? Inakzeptabel! :-(
-
Andreas K. Foerster -
Dr. Egbert Seibertz -
Eike Lange -
Frank Heckenbach -
Roland Goretzki