Zitat:

---

whose:
Zeiger auf UBYTE in ein ULONG "hineincastete" (worüber sich der GCC übrigens nicht wirklich beschwert hat, er schmiß nur die (verständliche) Warnung, daß man versucht, aus einem Zeiger einen Integerwert zu machen).

---

Zitat:

---

Zitat:

---

Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.

---

Wie ist der letzte Satz hier genau zu verstehen? Oder meinst Du damit, daß die Resource-Base als #define vorliegen muß statt als "extern" Deklaration?

---

Zitat:

---

Zitat:

---

Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.

---

Die sind mir in den Quellen noch gar nicht aufgefallen. Bisher waren's nur die Warnungen Zeiger<->Integer ( (ULONG) statt (UBYTE *) )und "Different width due to prototype" aufgrund des festen "-traditional" des StormC-GCC (implizite Erweiterung von short auf int), welche dann zum größten Teil beim "normalen" GCC wegfallen dürften.

---

Zitat:

---

whose:
Auch nicht, wenn Du versuchst, 16Bit relative und 32Bit absolut-Adressierung im selben Quellcode unterzubringen

---

Zitat:

---

whose:
...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

---

Zitat:

---

whose:
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?

---

Zitat:

---

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.

---

Zitat:

---

whose:
Zirkelbezüge in den Includes

---

Zitat:

---

whose:
ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht.

---

Zitat:

---

aPEX:
noe, sicher nicht, aber das sind die die ich kenne und wo alle aus einer hand kommen...

---

Zitat:

---

klar im aminet liegen tausend mal mehr, aber viele sind um 1995-1998 erschienen

---

Zitat:

---

softwarefailure:
Für mich als Softwareentwickler ist OS3.9 alles andere als tot.

---

Zitat:

---

aPEX:
welche Datatypes sind für ein 060-System eher zu empfehlen:
Die Sammlung von Andreas Kleiner, oder die WarpDatatypes?

---

Zitat:

---

ac-logic:
@DJBase:
Es hat nichts damit zu tun, daß das Produkt an dem er arbeit MorphOS ist

---

Zitat:

---

Micha1701:
Wenn ich die verfechter der GPL hier richtig verstehe _ist_ also ein Programm, welches Teile von Linux benutzt ebenfalls GPL.

---

Zitat:

---

Also muß der Quellcode offengelegt werden.

---

Zitat:

---

Also warum schreiben wir dann nicht mal eine Mail an ID-Software, damit die die Quellcodes von Doom3 freigeben. Die werden wohl Teile von Linux (Grafikkartentreiber, Inputkram) benutzen (die GPL sind) damit ihr Game läuft. Also ist Doom3 ebenfalls GPL - ist ja klar...

---

Zitat:

---

softwarefailure:
Aber ich kann mir wirklich nicht vorstellen, dass die Ignoranz beim OS3.9 Team so weit geht, dass man es durch Nichtanpassung vorzieht, dass ein Großteil der User den OS3.9 picture.datatype durch den minderfunktionellen AROS Datatype ersetzt, nur damit ein Byte pro Pixel von der Subclass durchgeschliffen wird.

---

Zitat:

---

whose:
Besitzt Du den SAS

---

Zitat:

---

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?

---

Zitat:

---

Holger:

Zitat:

---

gni:
Ich kennen keinen ANSI/ISO C Compiler, der das nicht macht. Wobei zb. der der SAS/C sogar etwas cleverer vorgeht als GCC. SAS/C kann erkennt auch Substrings am Ende eines Strings.

---

Dann hätte SAS/C also alle Leerstrings auf denselben Speicherbereich legen müssen?

---

Zitat:

---

Mit welchem Compiler haben die Commodore-Entwickler dann gearbeitet?

---

Zitat:

---

whose:

Zitat:

---

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

---

Siehe OS4Depot, da siehst Du dann auch das passende Readme der eigentlich älteren Version der avcodec lib, welche schon lange vorher unter LGPL stand...

---

Zitat:

---

Zitat:

---

Dann guckst Du in die Quellen vo liba52.

---

Womit wir bei der Frage wären, ob sich die GPL von dort auf das gesamte Projekt ausweitet oder doch nur für den AC3 Codec gilt.

---

Zitat:

---

Holger:
Denn einige Compiler optimieren konstante Strings, in dem sie identische String in denselben statischen Speicherbereich legen.

---

Zitat:

---

bubblebobble:
Ich nutze auch den AK-Datatype. Die 15 Pfund für das WarpDatatpye
finde ich etwas viel, nur damit man .png Grafiken laden kann

---

Zitat:

---

whose:

Zitat:

---

Original von gni:
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ß.

---

Zitat:

---

Üble Tricksereien halt.

---

Zitat:

---

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

---

Zitat:

---

bubblebobble:
@gni:
Ich dachte, die einzelnen Datatypes sind normale AmigaShared Libs,
die man auch direkt nutzen kann.

---

Zitat:

---

Und wenn das so ist, bräuchte ich auch eine Docu + .fd File dazu.

---

Zitat:

---

Evtl. hat das png Datatype ja Funktionen, um an die Alphamakse zu kommen.

---

Zitat:

---

Beste Lösung wäre aber tatsächlich, wenn ich das DoMethod hinbekomme
und Olaf das datatype fixed.

---

Zitat:

---

whose:

Zitat:

---

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

---

Das wiederum könnte man "Unterstellung" nennen...

---

Zitat:

---

Zitat:

---

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

---

Du wirst lachen, ich habe _beide_ ReadMe gelesen.

---

Zitat:

---

Und beide sind da etwas... unterschiedlich.

---

Zitat:

---

Wie es aussieht aufgrund einer ungeklärten Lizenzfrage.

---

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

---

Zitat:

---

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?

---

Zitat:

---

Wie war das mit dem Verallgemeinern?

---

Zitat:

---

bubblebobble:
Gibt es eine Doku zu den einzelnen Datatypes, z.B. png?

---

Zitat:

---

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

---

Zitat:

---

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

---

Zitat:

---

Lemmink:

Zitat:

---

Die erforderliche und zum Download angebotetene Bibliothek ist GPL. DvPlayer benutzt die Bibliothek. DvPlayer ist automatisch ein GPL Produkt.

---

Hmm, wenn diese Kausalitätskette stimmt, das selbst die indirekte Nutzung von GPL-Software dazu führt, daß das eigene Programm unter GPL fällt, dann dürfte es völlig unmöglich sein, für z.B. Linux auch nur irgendeine kommerzielle Software zu schreiben:

---

Zitat:

---

whose:

Zitat:

---

schluckebier:
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?

---

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()...

---

Zitat:

---

ac-logic:
3. Die avcodec.library basiert auf Sourcen des "ffmpeg" und diese stehen unter LGPL.

---

Zitat:

---

Es gibt also eine Version der avcodec.library (die ohne AC3-Codec) die zweifelsfrei unter LGPL steht und eine Version die zur ersten Version kompatibel ist aber möglicherweise unter GPL steht, aufgrund des jetzt enthaltenen AC3-codec. Es dürfte wohl jedem unter Berücksichtigung dieser Tatsachen klar sein das Stephen keinen Sourcecode rausgeben muß,
- den Source für die avcodec.library nicht weil er nicht der Author ist und diesen wahrscheinlich gar nicht hat - den Source für den DVPlayer nicht da dieser nicht unter GPL steht, da eine spätere Änderung des Lizenzmodels, einer nicht statisch gelinkten kompatiblen externen Komponente, keinen Einfluß auf das Lizenzmodell des Programms hat.

---

Zitat:

---

Georg:
Ansonsten kann man sich auch den Source vom AROS png.datatype anschauen, der auf libpng basiert.

---

Zitat:

---

DariusBrewka:

Zitat:

---

gni:
Welcher picture.datatype unterstützt PBPAFMT_ARGB?

---

Was meinst du mit unterstützt PBAFMT_ARGB?, also aufrufen kann ich das immer und bekomme auch ein 32 Bit Image heraus nur ist dann das Alpha==0, also Sinnlos.

---

Zitat:

---

Zitat:

---

Ich bezweifle auch nicht, das ALPHA nutzlos ist. Ich weis nur nicht, wie ein DT diese Information weitergeben soll bzw. behandeln soll, da meines Wissens PBPAFMT_ARGB nicht unterstützt wird.

---

Hoffe zuerst einmal dass du dich verschrieben hast

---

Zitat:

---

AmigaPapst:
Da steht LGPL nicht GPL, das ist ein Unterschied wie Tag und Nacht.

---