Zitat:

---

Original von Solar:
Eine ziemlich dösige Angewohnheit mancher Progger, Zeiger und Integers lustig hin- und herzuwandeln. Ich wäre auch dran interessiert zu erfahren, was die Leute da reitet...

---

Hm, vielleicht sollte ich mir mal Informationen zu den SAS-C-Optionen besorgen... ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht. Vor allem taucht dieser Cast nicht überall dort auf, wo die angesprochene Funktion verwendet wird (Projektsuche in StormC ist wirklich eine feine Sache ). Das muß einen Grund haben...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MaikG:
>Zumindest in so weit, wie es der Code überhaupt zuläßt.
>So tief bin ich noch nicht drin, um definitiv sagen zu
>können, daß alle Hits relativ einfach zu kriegen sind
>(soll heißen: Ohne massiven Umbau der Quellen).


Ein Hit weniger ist schon besser als nichts.

Cyberguard hat öfters etwas mit ReadLong 0000008
angezeigt.

Also in Basic vielleicht der Fehler:
inbuf&=Allocmem...

.
.
.


a&=Peekl ibuf&+8

---

Ja, sowas taucht da im Quellcode auch dann und wann mal auf, sollte aber keinen Hit erzeugen (obwohl... "Sag niemals nie" ).

Wird aber noch etwas dauern, die programmeigenen Includes sind schon ne Lustbarkeit für sich... aber nimmer lang, und das Ganze ist entrümpelt und halbwegs sauber organisiert. Dann kommt der erste Compilerlauf. Und damit evtl. das böse Erwachen

Scherz Das Ganze ist allerdings alles andere als sauber implementiert, kann also noch unvorhergesehene Probleme mit sich bringen. Da gibts z.B. so lustige Zeilen, in denen eine Funktion, die einen Zeiger auf UBYTE zurückgibt, gezwungen wird, den Zeiger in ein ULONG zu schmeißen...

Kann mir mal jemand verraten, wozu das gut sein sollte? Ich frage, weil ich den Verdacht habe, daß der Originalautor auch an anderen Stellen "Tricks" eingebaut hat, die evtl. dazu dienen, auf 68000er Maschinen "besser" zu laufen. Trotzdem verstehe ich den Sinn dabei nicht, einen Zeiger explizit in einem ULONG unterzubringen, statt getrennt Versionen für 68000 und 020+ zu compilieren...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Aero:
Danke whose

Es hat genau daran gelegen. Erst nachdem ich die max Obergrenze von 20 MB auf 200 MB gesetzt habe druckt er nun auch die Bilder einwandfrei.

Ich wunsche einen schönen Tag ..

---

Dito. Hm, kann man mal sehen... an die einstellbaren Obergrenzen habe ich gar nicht mehr gedacht...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MaikG:
>Aber instabil... nunja, inwiefern? Mit welchem Assembler?

Das war ein Komplettpaket aus dem Aminet, da war alles
was man benötigt dabei.
Die Executables stürzten manchmal mit diese 8000000x Fehler ab.

---

Da solltest Du etwas spezifischer werden, finde ich. Welche Executables? Die des Compilers oder die, die der Compiler erzeugt hat? Hast Du mal probiert, die Beispiele für Deine Maschine passend zu recompilieren? Mit den dafür notwendigen (oder angebrachten) Optionen? Zu sagen, die von ACE erzeugten Programme wären generell instabil ist halt etwas zu verallgemeinernd

Immerhin hängt die Stabilität von Programmen entscheidend davon ab, _wie_ sie implementiert und compiliert wurden. Da spielen z.B. so lustige Hintergedanken wie "höchste Effizienz auf 68000-Systemen" eine große Rolle.

Ein Programm, daß mit diesem Hintergedanken geschrieben wurde, kann sich auf einem 68020-System schon als Rohrkrepierer erweisen. Bei manchen Programmen reichts aber, diese spezifisch für 68020-CPUs erzeugen zu lassen, um Probleme zu "beseitigen".

Ich hatte bisher jedenfalls mit ACE und den mitgelieferten Beispielen keine größeren Probleme als die, die in der Dokumentation bereits erwähnt wurden.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Aero:
Hallo Amigafreunde ...

Ich habe hier ein Problem mit meinem Arbeitssystem. Bei dem Ausdruck einer großen Grafik(Scanbild oder Foto)passiert vollgendes: Der Drucker hört nach ca der Hälfte oder dreivirtel der Arbeit auf zu drucken und Turboprint Meldet mir Ich soll überprüfen er nich Offline geschaltet sei. Ein Ausdruck zB einer Textseite mit Final Writer oder mit Pagestream funktioniert einwandfrei.. Jetzt Habe ich mal zu Test auch die Auflösung des Ausdruckes auf 150 dpi gestellt und das ging..
Bei verwendung von 360 oder 720 dpi passiert dieses Phänomen.Kennt jemand dafür eine Lösung ?
...
Hat hier jemand eine Idee für mich ?

---

TurboPrint legt beim Ausdruck mehrere temporäre Dateien an (sozusagen eine art VMem), die in TurboPrint:Temp abgelegt werden (schau da mal rein, da findest Du manchmal noch "Überbleibsel"). Wenn große Grafiken gedruckt werden sollen, kommt da eine Riesenmenge an Daten zusammen, die irgendwie in TurboPrint:Temp hineinpassen müssen oder der Ausdruck bricht ab.

Wie viel Platz hast Du denn noch auf der Partition, auf der TP seine temporären Daten ablegt? Da solltest Du für derart große Bilder mehrere hundert MB einplanen, wenn Du mit hohen Auflösungen drucken willst. Sollte da nicht genug Platz sein, kannst Du den Pfad für das Temp-Directory auch auf eine andere Partition legen. Wenn da drauf genug Platz ist, sollte der Ausdruck hinhauen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:
Ja.

---

Danke schon mal im voraus.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:
Ursprünglich mit "Greenhills C" (Cross-Compiler auf einer Sun), vermutlich Lattice C and später dann SAS/C. Teile des OS (zb. Intuition) wurden aber immer mit "Greenhills C" übersetzt. Wie gesagt das Zusammenfassen von Strings kenne ich nur von ANSI/ISO Compilern. Und SAS/C ist das erst seit 5.x (?) von 1990.

---

Gehört zwar nicht zum Thread, aber ich weiß nicht, ob Du meine Frage im "SASC"-Thread gelesen hast.

Besitzt Du den SAS und kann ich ggf. auf Dich zurückkommen, um die Kompatibilität der FileMaster-Sourcen zum SAS zu testen, wenn ich die GCC-freundlich umgebaut habe?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Warum man das *so* machen kann, habe ich oben erläutert. Weniger Tipparbeit, und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar.

---

Hmm, über die nicht vorhandene Speicherersparnis und den kaum meßbaren Performancegewinn (wo es nicht gerade eine Einbuße verusacht), wurde ja schon gesprochen. Aber weniger Tipparbeit?
Für mich ist
bm=AllocBitMap();
immer kürzer als
bm=AllocMem(sizeof(struct BitMap), ...);
InitBitMap(bm);
und
ptr=" "
InitBitMap(bm);

ist keine wirkliche Verbesserung, selbst wenn es kürzer als Variante 2 wäre, stellt es doch nur ein Herumdoktorn an den Symptomen dar. Denn die das eigentliche Problem ist, daß man keine AllocBitMap-Funktion hatte. Die bedeutet nämlich auch weniger TippArbeit.

---

Zitat:

---

Zitat:

---

Anders herum hast Du sonst den "Verwaltungskram" (Speicher anfordern/freigeben) und den eigentlich benötigten Speicher, was den Gesamtspeicherplatz doch mehr reduziert als die "Holzhammermethode".

---

Könntest Du mir bitte erklären, was die "Holzhammermethode" gewesen wäre? Ich bin mit dieser Denkweise der ex-C= Entwickler nicht vertraut. Welche Alternativen spukten diesen Leuten denn noch im Kopf herum?

---

Die Holzhammermethode, die ich meine, ist die, die Du schon erkannt hast. ROM-Code, welcher später im RAM landet, so statisch wie möglich zu halten, um eine Speicherverwaltung im klassischen Sinn für kleine Datenbereiche zu umgehen. Das ist ne uralte Vorgehensweise. Beim PET/VC20/C64 etc. hat man oft so gearbeitet (da spielten Datentypen allerdings keine Rolle ).

Alternativen hatten die Cracks aus der Zeit sicher noch genug auf Lager, ich kenne selbst nur einen Bruchteil davon. Eine wäre z.B. die "Voraussage von Adresswerten". Eine gefährliche Annahme zwar, aber bei geschickter Auslegung des Codes funktioniert auch das. Wurde häufig auf dem C64 angewandt in Verbindung mit dem BASIC-Interpreter und der Zeropage. Da ergaben sich bestimmte Adressberechnungen quasi "von selbst" (als Ergebnis der Arbeit der BASIC-Routinen), was man sich dann im eigenen Programm sparen konnte.

Im AmigaOS habe ich sowas bisher aber zum Glück noch nicht entdeckt.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von DariusBrewka:
das ist die Frage, aber ggf. könnte man auch eine ENV Variable definieren, oder es ganz einfach lassen.

Mir ist es wichtiger an die Daten heranzukommen, über die Datatypes muss ich nicht unbedingt zeichen, d.h. wenn man weiss das man das nicht über DTM_Draw machen kann, dann kann man sich ruhig die daten per ReadPixels holen. Hauptsache es geht!

---

Aargh.
Irgendwie werden Env-Variable inzwischen für alles mögliche mißbraucht. Env-Variablen sind nicht dafür da, tiefgreifende System-Routinen zu steuern. Schlimm genug, daß WarpOS Benutzer sich damit quälen müssen.

---

Amen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

So isses und maximal 8 Farben.

---

Quatsch, Grünstufen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:
Wenn Du meinst. Dummerweise *gibt* es nichts zu klären. Die AC3-Bibliothek in den ffmeg Quellen ist GPL. Was es da noch zu klären gibt würde ich doch gerne wissen.

---

Zitat:

---

Merkwürdig ich seh nur eins im TopLevel-Verzeichnis. Was für ein zweites soll wo sein?

---

Zitat:

---

Zitat:

---

Und beide sind da etwas... unterschiedlich.

---

Dann guckst Du in die Quellen vo liba52.

---

Zitat:

---

Zitat:

---

Wie es aussieht aufgrund einer ungeklärten Lizenzfrage.

---

:-(

---

Genau. :-(


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:

Zitat:

---

gni:
Wer nicht lesen kann, hat halt ein Problem. Ein README ist immer das erste was man sich durchlesen sollte. Das beweisst nur, das Piru lesen kann.

---

Tja, und deswegen ist DVPlayer jetzt wieder zum Download freigegeben, mit ner avcodec.library, die den "umstrittenen" AC3-Codec nicht mehr enthält "bis die Frage nach der Lizenz des umstrittenen Codecs zweifelsfrei geklärt ist".

---

Sowas nennt sich "Schutzbehauptung".

---

Zitat:

---

Warum ließt Du nicht selber das README bevor Du Dich dazu äußerst?

---

Zitat:

---

Zitat:

---

Wie war das mit dem Verallgemeinern?

---

Mag sein, das einige die GPL als Noplusultra betrachten. Das hat aber rein garnichts mit dem Thema dieses Threads zu tun. Fakt ist, das es eine Lizenzverletzung gab/gibt.

---

Wie es aussieht aufgrund einer ungeklärten Lizenzfrage. Und was hat das mit "Lesen können" zu tun?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von AC-Pseudo:

Zitat:

---

Original von whose:

Tja, und was macht der Schlauberger, wenn die Lizenzlage nicht so eindeutig ist? Hast Du Dir mal das Posting von AC-Pseudo angesehen? Und die Antwort von gni darauf? Ist doch wunderbar, wie einig sich die beiden sind, oder?

---

Hab ich was verpaßt? Ich hab mich doch garnicht geäußert...

---

Mein Fehler, verzeihung. Hier beginnen einfach zu viele Namen mit ac

Ich meinte ac-logic. Da habe ich wohl ein wenig zu schnell gelesen. Nochmal: Entschuldigung.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
Das Konstrukt habe ich aus uraltem Code, teilweise ist der auf FishDisks zu finden, teilweise habe ich den vom CATS.

---

Dann war das eben fehlerhaften Code. Nur was hat das jetzt alles mit dem Design des AmigaOS zu tun? Ich habe irgendwo den Faden verloren.

Zitat:

---

Es ist halt simpler, Code mitsamt (kleinen) Datenbereichen einfach in den Speicher zu kopieren.

---

Diese Methode zum Platz reservieren mag unorthodox sein, aber wo genau ist jetzt das Problem? Das der String read-only ist? Das sich das mit neuen Compilern nicht übersetzen läßt?

---

Das der String ReadOnly ist und sich sowas mit bestimmten _alten_ Compilern auch nicht übersetzen ließ.

Üble Tricksereien halt.

Und das Thema lautete: Wie geht man mit Altlasten um?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Solar:

Zitat:

---

Original von whose:

...und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar.

---

Ach, ROM-Speicher darf's auch noch kosten? War ja quasi für lau und in rauhen Mengen zu haben seinerzeit, hat auch kaum was gekostet...

---

Was beißt Dich wohl mehr, wenn Du einen Computer baust? Ein ROM, welches keine oder "heruntergedrehte" Ausschmückungen enthält (Bootlogo), oder RAM, das zu schnell voll ist, den Computer unbenutzbar macht und teurer als das ROM ist?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:
Wer nicht lesen kann, hat halt ein Problem. Ein README ist immer das erste was man sich durchlesen sollte. Das beweisst nur, das Piru lesen kann.

---

Tja, und deswegen ist DVPlayer jetzt wieder zum Download freigegeben, mit ner avcodec.library, die den "umstrittenen" AC3-Codec nicht mehr enthält "bis die Frage nach der Lizenz des umstrittenen Codecs zweifelsfrei geklärt ist".

Das README scheint doch nicht so eindeutig zu sein, oder? Oder können alle anderen außer Piru nicht lesen? Noch nicht mal der Autor der library?

Wie war das mit dem Verallgemeinern?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
Stell Dir vor, jemand wäre so brilliant, das char *bla=" " exakt so groß zu definieren, daß ne BitMap-Struktur reinpaßt. Also sizeof(bla) == sizeof(struct BitMap). Kein AllocMem(), kein FreeMem()...

---

Woher hast Du dieses Konstrukt? Warum sollte man es *so* machen? Da kann ich auch gleich ein BitMap Objekt definieren. Ich kann immer noch nicht folgen.

---

InitBitMap() als Beispiel kam von Holger. Das Spielchen kannst Du bei vielen Funktionen des AmigaOS treiben, nicht nur bei denen, die mit "Init" beginnen.

Das Konstrukt habe ich aus uraltem Code, teilweise ist der auf FishDisks zu finden, teilweise habe ich den vom CATS.

Warum man das *so* machen kann, habe ich oben erläutert. Weniger Tipparbeit, und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar. Es ist halt simpler, Code mitsamt (kleinen) Datenbereichen einfach in den Speicher zu kopieren. Dank Relocation ist es noch nicht einmal ein Problem, an den Datenbereich heranzukommen.

Anders herum hast Du sonst den "Verwaltungskram" (Speicher anfordern/freigeben) und den eigentlich benötigten Speicher, was den Gesamtspeicherplatz doch mehr reduziert als die "Holzhammermethode".

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 16.08.2005 um 14:33 Uhr editiert. ]

Zitat:

---

Original von Solar:
Also wird der Speicherbedarf durch den Linker gedeckt, bläst das Executable auf, verlangsamt den Ladevorgang, benötigt den Speicher während der gesamten Programmausführung statt nur bei Bedarf... riesig effizient.

---

Das hängt a) vom Compiler/Linker ab, b)von der Faulheit des Programmierers. Ist halt bedeutend weniger Tipparbeit und die Freigabe nimmt einem der Compiler auch noch ab

Ganz nebenbei spart man sich dadurch einiges an Speicher, der sonst erst extern angefordert werden müßte (inkl. Overhead). Das der Speicher während der gesamten Programmausführung "verbraten" wird, war vielen Leuten gar nicht so bewußt und beim (teilweise handoptimierten) ROM-Code war das nicht wirklich ein Problem. Ein großes Thema vor nicht allzu langer Zeit...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 16.08.2005 um 14:23 Uhr editiert. ]

Zitat:

---

Original von ChrisP:

Ok und hier laufen unsere Meinungen auseinander. Software, wie Linux, Apache, Samba, etc., haette es IMHO ohne die GPL (oder Derivate nicht gegeben)

---

Zitat:

---

Du meinst, der Author wuerde den Quellcode fuer "ein paar Euros" freigeben?

---

Das wohl weniger. Aber wer hindert den Autor denn daran, eine MOS-Version aufzulegen? Als Anreiz läßt man dann halt "ein paar Euro" springen...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von schluckebier:

Zitat:

---

Original von whose:
Inzwischen bin ich mir gar nicht mehr so sicher, ob der Autor sich darüber im Klaren war, daß er GPL-Code verwendete oder eben nicht. Hier gehen die Meinungen dazu ja auch schon wieder auseinander.

---

Wie gerade schon geschrieben: Wer Code von anderen nimmt, muss sich halt vorher schlaumachen, wie die Lizenz dafür aussieht.

---

Tja, und was macht der Schlauberger, wenn die Lizenzlage nicht so eindeutig ist? Hast Du Dir mal das Posting von AC-Pseudo angesehen? Und die Antwort von gni darauf? Ist doch wunderbar, wie einig sich die beiden sind, oder?

Und was den "Unsinn" mit der "infektiösen Natur der GPL" angeht: Ja, streng betrachtet ist es so. Ein Fehler, und Dein Programm steht auch unter GPL, ob Du das willst oder nicht.

Und nochwas: Ich betreibe hier kein GPL-Bashing. Ich schreibe meine Meinung dazu, was ich von den Leuten halte, die die GPL ebenso pauschal als Heilsbringer betrachten, ohne die Folgen zu bedenken.

Radikale Standpunkte sind nie gut, egal, ob auf der "freien" Seite oder der "patentierbaren" Seite.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

Original von Holger:
char* bla=" ";
InitBitMap(bla);

---

Bahnhof.

[ Dieser Beitrag wurde von gni am 16.08.2005 um 10:03 Uhr editiert. ]

---

Stell Dir vor, jemand wäre so brilliant, das char *bla=" " exakt so groß zu definieren, daß ne BitMap-Struktur reinpaßt. Also sizeof(bla) == sizeof(struct BitMap). Kein AllocMem(), kein FreeMem()...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
Noch jemand der Meinung, daß GPL in jedem Fall ein Segen ist?

---

Warum mußt Du *immer* alles verallgemeinern? Jeder kann sich für seine Software eine Lizenz suchen, die *ihm* genehm ist, egal ob die anderen passt oder nicht. Und wenn dann jemand die Software dann benutzt, dann *muß* er die Lizenzbestimmungen einhalten!

---

Das Gleiche könnte ich Dich fragen...

Du weißt genau, daß ich nicht immer alles verallgemeinere. Meine Frage war provokativ angelegt, weil es hier halt Leute gibt, die die GPL-Lizenz verallgemeinernd als "Segen für die Software-Landschaft" verkaufen. Das das durchaus nicht immer der Fall ist, sehen wir hier gerade.

Und ja, es ist richtig, daß jeder für sich entscheiden kann, ob er GPL-Software einsetzt oder nicht. Manchmal ist es aber gar nicht so klar, ob die GPL zur Anwendung kommt oder die LGPL oder oder...

Der kleine "Streit" hier zeigts doch mal wieder. Inzwischen bin ich mir gar nicht mehr so sicher, ob der Autor sich darüber im Klaren war, daß er GPL-Code verwendete oder eben nicht. Hier gehen die Meinungen dazu ja auch schon wieder auseinander.

Wie kann man sich als Entwickler da absolut frei entscheiden, wenn ein Buchstabe darüber entscheidet, ob man seine Arbeit voll preisgeben muß oder nicht?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Andreas_Wolf:
Die der Autor natürlich anteilig an die Autoren zahlt, deren Code er sich "geborgt" hat. Alles klar.

---

Das ist wahrer OpenSource-Gedanke... ist das nicht schön?

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Neo:
@Lemmink:

Sehr gut erkannt und genau so seh ich das auch.

Gut damit er die Sourcen für Avicodec.library freigeben muß wenn es sich um GPL verletzte software handelt sehe ich das noch gelassen, das schließt aber nicht DvPlayer mit ein um genau das geht es aber er will nicht nur den Source der lib sondern den kompletten source inklusive DvPlayer.Seit ihr alle so blind? Die Mos entwickler haben erkannt das ein sehr guter Player für Aos4.0 entwicklt wurde der MPlayer in fast allen punkten das Wasser reichen kann und nun versucht man mit allen mitteln den Player auch für MorphOs zu tragen.

---

Das ist die Natur der GPL. Manche sprechen auch von einer "infektiösen" Natur. Nämlich weil die Verwendung von Software, die unter GPL veröffentlicht wurde, die Veröffentlichung anderer Software unter GPL erzwingt, wenn diese auf GPL-Software aufbaut bzw. in ihrer Funktion von GPL-Software abhängig ist.

Der Fall wäre hier gegeben, wenn die Anschuldigungen in Bezug auf den aktuellen DVPlayer mit der avcodec.library zutreffen sollten.

Dann hat der Autor schlicht gepennt oder ist, wenn die nebulöse Geschichte mit dem Anwalt halbwegs stimmt, bescheiden beraten worden.

Nun sollte er zügig zusehen, wie er das Problem umgehen kann. Wege dazu gibts. Vielleicht solltest Du ihm mal eine freundliche Mail zur moralischen Unterstützung schicken.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von ChrisP:

Das ist aber nun die "Microsoftsche" Argumentation. Open Source ist schlecht, weil man damit kein Geld verdienen kann (her mit den Software-Patenten). Aber wenn sich jemand aus einem Pool bedient, muss er es in den Pool zurueck geben. Sonst ginge doch jeder her, nimmt sich Open Source, packt ein wenig Mehrwert drauf oder portiert es auf ein anderes OS und nimmt Geld dafuer. Das ist IMHO unfair. Frei ist frei, es zwingt niemand jemanden, sich auf Open Source zu stuetzen.

---

Das mit der "Microsoftschen" Argumentation ist allerdings auch kein guter Vergleich.

Da gabs mal jemanden (den Namen habe ich vergessen), der bei der GPL gewisse Parallelen zur Zwangskollektivierung im Kommunismus zog. So ganz Unrecht hat derjenige nicht.

Es ist zwar richtig, daß niemand gezwungen wird, GPLd Software einzusetzen, andererseits werden Leute, die GPLd-Software als Unterbau verwenden, dazu gezwungen, ihr geistiges Eigentum (den "Oberbau") preiszugeben, ob sie das wollen oder nicht.

Man könnte das auch als "kommunistischen" Gegenpart zu Softwarepatenten sehen.

Beides ist nicht besonders förderlich, finde ich. Wenn jemand freiwillig sein "geistiges Eigentum" der breiten Öffentlichkeit zur Verfügung stellen will, ist das völlig okay. Wenn das jemand nicht will, ist das auch okay. Sobald allerdings Zwang ins Spiel kommt, wirds unschön.

Meiner Meinung nach sollte sich der Autor von DVPlayer darum bemühen, die Zwänge der GPL in einer neuen Version zu umgehen, z.B. wie bereits auf AW vorgeschlagen mit Hilfe einer Plugin-Schnittstelle für die Codecs. Dann wären beide Seiten zufrieden.

Piru vielleicht nicht ganz so, aber das wäre dann sein Problem. Er kann dann ja ein paar Euro springen lassen für ne MOS-Version

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von ChrisP:

Zitat:

---

Original von Neo:
ps. http://www.iki.fi/sintonen/dvplayer_gpl/mail.txt sollte sich jeder mal angucken die Email stammt vom Mos kernentwickler "Pirus" die er an den Athor geschrieben hat und dort den besagten kompletten Source für DvPlayer verlangt.Sehr unhöfliche Email aber jeder kann sich ja seine eigne meinung bilden für mich ist das ein ganz linkes ding was abgezogen wird-

---

Also Harry Sintonen solltest Du kennen, wenn Du mal mit Amiga OS gearbeitet hast. IMHO war da Software, die er geschrieben hat recht oft im Gebrauch

---

Zitat:

---

Und was die Mail angeht: er hat recht. GPL ist GPL ist GPL. Wer etwas aus der GPL nimmt, muss es auch unter GPL veroeffentlichen. So funktioniert Open Source. Ob Harrys Ziel war, die Software komplett vom Netz zu schiessen, bezweifle ich, aber evt. hat das Ganze ein gutes und die Software wird unter der GPL weiter entwickelt.

---

Zitat:

---

Das hat auch ein gutes fuer OS4, denn je freier die Software, desto mehr arbeiten dran, desto besser kann die Software werden.

---

Ich betone: Kann.

Muß aber nicht.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MaikG:
Willst du die Hits auch gleich mit weck machen?
Cool.

---

Zitat:

---

Beim Bildanzeiger wird z.B. "getrickst" da wird die
ModeID von der Datei geöffnet, nur wenn das ein Grafikkarten
Screen ist wird kein Bild gezeichnet. FM macht das nur
mit Amiga-Screens.

---

Ja, das isn "toller" Trick, den habe ich auch schon gesehen

Ich denke, die Funktion kann man dann noch, wenn die Grundlagen "erschlagen" sind, in Angriff nehmen. Die hängt nämlich nicht mit gar so vielen Modulen zusammen wie der Rest des Quellcodes.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Neo:
@CarstenS:


Sorry, aber hast du dir die Email mal durchgelesen? Und ja irgendwas muß an der sache darn sein das bestreitet ja niemand aber nur wie vorgegangen wird das ist das was mich persönlich ärgert, auch kann ich in der Email kein einziges wort von "Bitte" lesen. Die Email hört sich eher wie eine vorderung an.

---

Das dürfte daran liegen, daß es sich da mehr oder weniger um eine "politische" Sache handelt. Die GPL-Geschichte ist anscheinend auch noch gar nicht so 100% klar, da Piru seltsamerweise nur Vergleiche mit statischen Daten anstellte, die (ebenfalls merkwürdigerweise) niemand mehr nachvollziehen kann, da das Vergleichsmaterial nicht mehr zum Download zur Verfügung steht (hier darf man durchaus fragend in die Landschaft schauen ).

Wie auch immer, DVPlayer steht im Moment nicht zur Verfügung, also hat man auf MOS-Seite das erreicht, was man wollte. Entweder DVPlayer auch für MOS oder für niemanden, und wenn das nur temporär so ist.

Im Zweifelsfall dürfen wir uns dann halt wieder mit dem technisch überragenden MPlayer herumschlagen. Was solls...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MichaelMerkel:
ja - ist schon schade, dass das gleich solche kommentare wie "blue troll" hervorruft.

---

Ich denke, das wäre im umgekehrten Fall nicht anders gewesen. Da hätte es dann halt nur "red trolls" geheißen.

Ist alles nicht schön, aber der Autor findet hoffentlich eine Lösung dafür. Noch jemand der Meinung, daß GPL in jedem Fall ein Segen ist?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Ich werd auch nie wieder versuchen, die lustigen (und funktionierenden, lieber Holger. Ich sage dazu nur Init...()) Tricks von damals zu erläutern.

---

Ich glaube aber, jetzt wird mir klarer, was Du eigentlich meinst. Nicht daß C= Entwickler diese Programmiertechnik benutzt hätten, sondern die zur Verfügung gestellten Routinen, die den Anwendungsprogrammierer zu einer solchen Programmierweise ermutigt haben, ala
char* bla=" ";
InitBitMap(bla);
meintest Du diese Art von tollen Ideen? (Die auf dem A500 wahrscheinlich 0.5 ms auf einer Laufzeit zwei Stunden Gewinn gebracht haben, wenn sie richtig angewendet wurden und zwei Tage zusätzliches Debugging wenn nicht).

---

Jep, u.A. das meinte ich. Bis Kickstart 3.0 kamen solche "Tricks" aber durchaus auch im Kickstart vor, Reste davon findest Du heute noch u.A. in der locale.libary (der Stringpuffer. Wird zwar für jede Inkarnation der locale.library neu angelegt, sieht mir aber verdächtig nach einer "ehemaligen" Konstanten aus, wenn ich mir den Code drumherum so anschaue. Auf jeden Fall hats nen triftigen Grund, warum diese Stringzeiger nicht als CONST_STRPTR deklariert sind, sondern statt dessen als READ ONLY kommentiert wurden).

Frag mich aber bitte nicht, warum diese "Tricks" sich so lange gehalten haben. Vermutlich spielt Bequemlichkeit da eine große Rolle. Und die Tatsache, daß da einige Leute wohl lieber Assemblertricks benutzten, statt sich mit "Förmlichkeiten" zu arrangieren

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233



[ Dieser Beitrag wurde von whose am 15.08.2005 um 21:11 Uhr editiert. ]