amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste << 10 11 12 13 14 -15- 16 17 18 19 20 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

16.08.2005, 10:02 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

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

Bahnhof.

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

16.08.2005, 09:59 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
AmigaPapst:
Zitat:
gni:
Ich bezweifle, das jetzt kein weiterer GPL-Code mehr verwendet wird.

Woher nimmst du diese Behauptung? Hast du den Quellcode vor dir? Deine Freunde werden schon prüfen ob sich darin noch GPL-Code versteckt.
Na dann erklär mir bitte, warum das Archiv avcodeclib_OS4.lha eine Datei "COPYING.txt" enthält. Das ReadMe des Archives hast Du natürlich auch nicht gelesen...
 
gni   Nutzer

16.08.2005, 09:48 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
AmigaPapst:
Der DvPlayer ist ab sofort wieder unter http://amigos.amiga.hu/dvplayer/ verfügbar. Der umstrittene AC3-Teil wurde erstmal aus dem Quellcode der avcodec.library entfernt.

Ich bezweifle, das jetzt kein weiterer GPL-Code mehr verwendet wird.
 
gni   Nutzer

16.08.2005, 09:46 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
whose:
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.

Wie kann man nur so einen Unfung schreiben? Wenn ich nicht will, das meine Software einer bestimmten Lizenz unterliegt, dann muß ich dafür sorgen, das das nicht passieren kann. Und erzähl jetzt nicht, das er nicht wußte, das er GPL-Software verwendet.
 
gni   Nutzer

16.08.2005, 09:38 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
ChrisP:
So funktioniert Open Source eben nicht.

Open Source != GPL
 
gni   Nutzer

16.08.2005, 09:27 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

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!
 
gni   Nutzer

16.08.2005, 09:17 Uhr

[ - Direktlink - ]
Thema: Bildschirmschoner
Brett: Amiga, AmigaOS 4

Zitat:
Harague:
Gab oder gibt es Bildschirmschoner die auch mit nem MC68000 laufen.

Warum sollte so was nicht laufen? Ich benutze ASwarm 1.3 (uralt) und der sollte problemlos auch auf einem 68000 laufen.
Zitat:
Vielleicht sowas ähnliches wie vom CDTV?
Was macht das besonderes?
Zitat:
und was muß ich machen um JPG auf dem 500er zu sehen? Geht das überhaupt
Es geht, aber vermutlich sehr langsam.

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

15.08.2005, 17:30 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
Original von bubblebobble:
Wenn das AROS picture.datatype das auch kann, könnte man das doch evtl. für OS3.x kompilieren, oder nicht?

Möglicherweise. Nur mußt Du dem garantiert noch beibringen CyberGraphics Funktionen zu verwenden. Ich vermute, das wäre eine schwieriges Unterfangen.
 
gni   Nutzer

15.08.2005, 17:27 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
DariusBrewka:
Zitat:
DTs können ohne weiteres den Alpha-Kanal laden. Nur was dann damit machen?
z.B. mit DoMethod(...PDTM_READPIXELARRAY,...PixelFormat = PBPAFMT_ARGB)
den User ermöglichen etwas von dem Kanal zu haben?

Welcher picture.datatype unterstützt PBPAFMT_ARGB?
Zitat:
Tschuldigung, das "Nur was dann damit machen?" ist eine ziemlich blöde Antwort.
Warum? Wenn der picture.datatype damit nichts anfangen kann, muß/kann ich den Alpha-Kanal auch nicht berücksichtigen.
Zitat:
Ich könnte das sehr gut gebrauchen und muss auf 68K die Maske immer als zusätzliche Datei speichern. AROS kann das ja und so schwierig das in 68 zu implementieren kann das wohl auch nicht sein.
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.
 
gni   Nutzer

15.08.2005, 17:19 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
whose:
Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen.

Es wäre nett, wenn man die Quellen danach immernoch mit SAS/C übersetzen kann.
 
gni   Nutzer

15.08.2005, 17:17 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
MaikG:
und GCC bekommt man aber im Internet?

Ja.
 
gni   Nutzer

15.08.2005, 11:53 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
bubblebobble:
Gibt es die als Amiga Shared Lib mit Doku irgendwo?

Nicht das ich wüßte.
Zitat:
ArtEffects schreibt einen "ALPHA" Chunk in die IFF Dateien, ist das eine eigene Erfindung oder gibt es andere Programme oder Datatypes, die das Unterstützen?
DTs können ohne weiteres den Alpha-Kanal laden. Nur was dann damit machen?
 
gni   Nutzer

15.08.2005, 10:17 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
Holger:
Zitat:
gni:
Zitat:
Solar:
Kinder, solange ihr von der Semantik von "const" keine Ahnung habt, und ernsthaft glaubt der Hauptzweck von C++ sei, "sicherere" Anwendungen zu schreiben, diskutiert doch besser nicht darüber, OK?

Schön das wenigstens einer Durchblick hat...
Was meinst Du damit?
Mich stört seine undifferenzierte Sichtweise, die in dem Zitat nur allzu deutlich wird.
 
gni   Nutzer

15.08.2005, 10:09 Uhr

[ - Direktlink - ]
Thema: MP3 VBR Laufzeit berechnen
Brett: Programmierung

Zitat:
Ralf27:
Hab auch gleich mal eine mp3-Datei mit einem Bild versehn und sie da, AMP kann sie nicht mehr abspielen.

Schreib einen Bug-Report an den AMP-Autor. Und wie sieht es bei mpega (den Shell-Tool) aus?
 
gni   Nutzer

15.08.2005, 10:01 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
bubblebobble:
Weiss jemand wie man die Alphamaske aus PNG und/oder IFF-ILBM Grafiken laden kann? Datatypes (bzw. via guigfx) scheint das nicht zu unterstüten?

Wie machen das die PNG Icons ?

Vermutlich mit einer eigenen Laderoutine, die die libpng direkt benutzt.
 
gni   Nutzer

12.08.2005, 17:07 Uhr

[ - Direktlink - ]
Thema: Probleme mit HD-Toolbox von OS 3.9
Brett: Amiga, AmigaOS 4

Zitat:
thomas:
Jedenfalls dient mein USB-Stick sowohl am PC als auch am Amiga als Boot-Gerät. Ohne irgendwas an den Dateien zu ändern.

Du _bootest_ vom Stöckchen? Kannst Du das bitte etwas genauer ausführen?
 
gni   Nutzer

12.08.2005, 15:17 Uhr

[ - Direktlink - ]
Thema: Fragen zu G-REX
Brett: Amiga, AmigaOS 4

Zitat:
_PAB_:
Wenn man schon ein Mediator hat, macht es keinen Sinn noch eine alte Amiga-Grafikkarte weiterzubenutzen, die den Videoslot braucht, da nimmt man lieber eine (kompatible) PCI-Karte und erhält gleich viel mehr Leistung.

Beim Mediator hat man doch gar keine Wahl, ohne PCI-Graka gehts doch nicht.
 
gni   Nutzer

12.08.2005, 12:18 Uhr

[ - Direktlink - ]
Thema: Probleme mit HD-Toolbox von OS 3.9
Brett: Amiga, AmigaOS 4

Zitat:
thomas:
wenn die HDToolbox mit ASKDEVICE abstürzt, heißt das meistens, daß du ein Device in DEVS: hast, das nicht korrekt auf unbekannte Befehle reagiert.

Das sollte NSDPatch eigentlich beheben oder? Ohne ASKDEVICE und mit richtigem DEVICE= sollte die HDToolBox klaglos tun.
 
gni   Nutzer

12.08.2005, 10:29 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
Solar:
Kinder, solange ihr von der Semantik von "const" keine Ahnung habt, und ernsthaft glaubt der Hauptzweck von C++ sei, "sicherere" Anwendungen zu schreiben, diskutiert doch besser nicht darüber, OK?

Schön das wenigstens einer Durchblick hat...
Zitat:
Wenn etwas durch eine Konstante initialisiert werden darf (weil es von den entsprechenden Funktionen nicht verändert wird), muß es auch "const" deklariert werden! Das hat nichts mit C++ zu tun und ist schon in C schlichtweg falsch - nur daß sich der Compiler nicht so sehr darüber beschwert.
Warum sollte ich bei 'char *foo = "ein string"' zwingend const brauchen?
Zitat:
Und der Grund, warum heute kaum noch in C und hauptsächlich in C++ entwickelt wird, ist die bessere Wartbarkeit von C++-Code.
Ach?
 
gni   Nutzer

11.08.2005, 13:43 Uhr

[ - Direktlink - ]
Thema: C++ mit GoldED AIX ?
Brett: Programmierung

Zitat:
Dietmar:
Gibt es eine Chance, dass Du 3.4.3 in den nächsten Tagen zusammenstellst/veröffentlichst?

Für m68k? Für die neuen Versionen sollte man dann auch passende binutils haben. Die müßte ich auch noch erstellen. Leider macht mir 3.4.3 bei PPC etwas Schwierigkeiten. Das möchte ich erst noch genauer untersuchen.
Zitat:
Ich werde heute einen neuen morphos-gcc von Marcin Kurek integrieren (nicht wirklich neu, habe den 2.95.4-4-altivec Release im Juli übersehen).
Wo kann man die finden? Sind diesmal die diffs dabei? Ohne die hast Du Probleme...
Zitat:
Wenn Du mit 3.4.3 in nächster Zeit fertig wirst, würde ich diese Version gerne mit in das nächste Update nehmen.
Ich kann wirklich keinen genauen Termin nennen :-(
 
gni   Nutzer

11.08.2005, 13:13 Uhr

[ - Direktlink - ]
Thema: C++ mit GoldED AIX ?
Brett: Programmierung

Zitat:
Mazze:
Ich habe jetzt das Problem, dass beim Kompilieren mit gcc folgende Fehlermeldung angezeigt wird: "undefined reference to AllocChooserNode". Es fehlen offenbar die Funktionen, die seit OS3.5 hinzugekommen sind.

Nimm "AllocChooserNodeA", schreib "AllocChooserNode()" selber oder verwenden eine andere amiga.lib.
Zitat:
Bitte beim nächsten Update berücksichtigen.
Da ich nicht glaube, das Dietmar die amiga.lib für den GCC selber erstellt, wird sich da wohl nichts ändern.
 
gni   Nutzer

11.08.2005, 13:05 Uhr

[ - Direktlink - ]
Thema: MP3 VBR Laufzeit berechnen
Brett: Programmierung

Zitat:
Ralf27:
Den Lame-Tag versuch ich später mal im Internet zu finden. Mal sehn was da drin steht. Denn die meisten MP3 sind bei mir mit LAME gepackt.

Schau Dir die Quellen der libmad an. Da wird sowohl der Xing- als auch der Lame-Tag ausgewertet.
 
gni   Nutzer

11.08.2005, 11:35 Uhr

[ - Direktlink - ]
Thema: C++ mit GoldED AIX ?
Brett: Programmierung

Zitat:
Dietmar:
Das nächste für Dich interessante Update dürfte kommen, wenn es die von gni angekündigten neuen 68k-gcc-Versionen gibt (gcc 4.x).

Ich habe gestern einen mpega_libmad Test gemacht. Dabei habe ich die Bibliothek für PowerUp mit verschiedenen Compilern erstellt: 3.3.3, 3.4.3, 4.0.0 und 4.1.0/20050805. Im Test war die Version von 3.4.3 am schnellsten, die 4.x Versionen waren merklich langsamer, aber das mag für andere Programme anders aussehen. Dennoch denke ich, das 4.x derzeit nur verbesserte Fehler- und Warnmeldungen bietet.
 
gni   Nutzer

10.08.2005, 15:54 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
whose:
Zitat:
gni:
Die VarArgs-Varianten sind nur _Hilfsfunktionen_ ("convenience")!

Genau. Und davon schrieb ich einen Post vorher. Das vieles, was einem heute in den Includes merkwürdig vorkommen mag, damals dazu gedacht war, den externen Entwicklern das Leben zu erleichtern.
Die Funktionen haben schon einen Sinn: So kann man bequemer variable Taglisten erzeugen, dh. was hinzunehmen bzw. weglassen ohne einen Index anpassen zu müssen. Motif hat im übrigen auch solche Funktionen.
Zitat:
Zitat:
Beim Füllen der TagList mußt Du _auch_ Casten.
Eben. Deswegen sagte ich ja auch, daß das keine besonders glückliche Lösung war mit den Taglisten.
Das sehe ich anders. Es ist bei weitem flexibler und kann ohne größere Anstrengung verändert werden. Das war mit den alten Strukturen nicht möglich. Und wie bereits gesagt, auch Motif verwendet "TagListen" und das gibt es für viele Systeme.
Zitat:
Die Inlines/Stubs bauen noch dazu auf einer Eigenschaft auf, die nicht auf jeder Maschine garantiert sein muß.
Ich sehe da das Problem nicht. Inline/Stubs sind maschinen- und Compilerspezifisch. Solange "sizeof(long) == sizeof(long*)" gilt, gibt es kein Problem.
Zitat:
Zitat:
Zitat:
Da kommt dann sowas wie "...pointer to function makes pointer from integer without a cast"... also doch nicht ganz glücklich gelöst.
Das ist _ausschließlich_ ein Problem "Implementation". Der GCC unterstützt Makros mit variablen Argumenten und dieses Feature wird von den Inlines verwendet. Die Argumente werden in ein ULONG-Array gepackt. Und genau das ist die Stelle, an der die Warnung kommen _muß_. Die beschriebene Methode ist äußerst ineffizient. Deshalb empfehle ich generell mit NO_INLINE_STDARG zu arbeiten. Zum einem gibt es dann keine Warnung und außerdem ist der generierte Code dann um Längen besser.
Naja, im Groben habe ich das auch gesagt. "Es gibt ja immer noch die Stubs" ;)
Es ging um die Warnung und wie sie zu Stande kommt.
Zitat:
Weiter unten in dem Post habe ich aber auch gesagt, daß die IText-Struktur zur _Wiederverwendung_ gedacht war und das wäre mit nem CONST UBYTE * als Member nun mal unmöglich. Einmal zugewiesen, nie mehr verändert.
Siehe Solars Posting: Es kommt auf die Platzierung von const an.
Zitat:
Im Fall der IText-Struktur wäre es aber witzlos, in einer neuen OS-Version Rücksicht auf die enorme Typstrenge der C++-Compiler zu nehmen.
Das Problem ist _nicht_ const. Das kann man einführen ohne das alte Quellen geändert werden müßten. Das Problem ist "UBYTE". Der "richtige/bessere" Typ wäre "char" in einem typedef gewesen.
Zitat:
Wie ich weiter oben schon sagte: Im AmigaOS gibts vieles, was historisch gewachsen ist und zu einer Zeit entstand, als man von strenger Typprüfung eines C++-Compilers noch nicht allzu viel Ahnung hatte.
Stringkonstanen haben einen Typ: "char*". Den meisten C Compilern ist bis heute egal, ob man das einem "passendem" Charactertyp zuweist. C++ hat da schon immer draufgeschaut und GCC 4.0 warnt auch im C Mode.
Zitat:
Ich fasse das Ganze mal so zusammen: Manchmal sind die Casts nicht schön, aber wer den alten Krempel in AmigaOS benutzen will, wird sich wohl oder übel damit anfreunden müssen.
So ganz richtig ist das nicht. Das API macht Probleme mit C++. Mit einem entsprechenden C Compiler bekommt man neuerdings auch Warnungen bezüglich Zeigervorzeichen. Auch wenn das AMiga API Schwächen hat, kann man oft Casts vermeiden. Viele sind nur zu faul es zu tun und unglücklicherweise enthalten viele Beispiele Casts :-(

[ Dieser Beitrag wurde von gni am 10.08.2005 um 17:08 Uhr editiert. ]
 
gni   Nutzer

10.08.2005, 09:27 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
whose:
Die Funktionen, die die Taglisten als VarArg-Parameter akzeptieren (und genau dafür sind die Taglisten gedacht!), bauen darauf, daß man Zeiger- und ULONG-Typ innerhalb der TagItem-Struktur beliebig casten kann.

Die VarArgs-Varianten sind nur _Hilfsfunktionen_ ("convenience")!
Zitat:
Ansonsten wären z.B. die inline-Aufrufe der VarArg-Varianten gar nicht machbar.
Die normale Funktion mit TagList* als Argument aber auch nicht. Beim Füllen der TagList mußt Du _auch_ Casten.
Zitat:
Der GCC meckert trotzdem gerne bei solchen Funktionen, wie z.B. BestModeID(). Da kommt dann sowas wie "...pointer to function makes pointer from integer without a cast"... also doch nicht ganz glücklich gelöst.
Das ist _ausschließlich_ ein Problem "Implementation". Der GCC unterstützt Makros mit variablen Argumenten und dieses Feature wird von den Inlines verwendet. Die Argumente werden in ein ULONG-Array gepackt. Und genau das ist die Stelle, an der die Warnung kommen _muß_. Die beschriebene Methode ist äußerst ineffizient. Deshalb empfehle ich generell mit NO_INLINE_STDARG zu arbeiten. Zum einem gibt es dann keine Warnung und außerdem ist der generierte Code dann um Längen besser.
Zitat:
Sei mir bitte nicht böse, aber Konstanten verwende ich z.B. eher selten im Zusammenhang mit IText. Da kommen höchstens Texte hinein, die mir die locale.library liefert, und diese Strings sind nur scheinbar konstant...
Irrelevant. Der Texteintrag in IText kann trotzdem ein "const" haben und Du kannst dennoch Deinen const-losen Typ zuweisen.
Zitat:
Streng genommen bräuchte man den jeweiligen String nie konstant zu definieren.
Weisst Du eigentlich wie const funktioniert und was es aussagt? :-(
 
gni   Nutzer

10.08.2005, 09:12 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
Holger:
Die TagList sind im Gegensatz zum Rest überhaupt kein Problem. Das sind ja ausnahmesweise sogar mal Strukturen, die keine Abhängigkeiten zu Internas des OS enthalten.

Probleme haben sie trotzdem, wegen Zeiger/Nichtzeiger in ti_Data. AFAICT wurden TagListen zuerst bei Motif verwendet.
 
gni   Nutzer

10.08.2005, 09:08 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
whose:
Wie will man denn Casts vermeiden, wenn viel mit Zeigern auf unterschiedliche Strukturen gearbeitet wird? Abgesehen davon bietet sich dadurch doch erst die Möglichkeit, den Compiler einen Großteil der Typüberprüfung erledigen zu lassen... (?)

Irrtum. Durch Casts nimmst Du dem Compiler die Möglichkeit zur Typprüfung. Mit Casts sagst Du ja explizit, das Du es besser weisst.
Zitat:
Naja, was heute sinnvoll erscheint war damals (1984) halt noch kein Thema (und C++ war auch noch keins zu dieser Zeit :D ). Insofern sind die Definitionen den Strukturen schon recht sinnvoll
Nö, sind sie nicht. Die Verwendung von UBYTE ist ein Problem, genau wie STRPTR.
Zitat:
Zu der Zeit, als man auf diese (zugegebenermaßen "glorreiche" I-) ) Idee kam, hat noch niemand daran gedacht, Funktionseinsprünge per Makro erledigen zu lassen anstatt über eine Linkerbibliothek mit Stub-Funktionen. Daher auch die Probleme damit, wenn C++-Compiler da dran müssen.
Funktionsaufrufe per Makro? Das ging damals eh nicht, da Du die Parameter immernoch in Registern übergeben mußt und das konnte damals kein Compiler.
Zitat:
Und es wäre etwas dumm, wenn man das als const char * bzw. CONST UBYTE definiert hätte, dann würde ein C++-Compiler wohl noch viel öfter meckern bzw. Nicht-konstante Strings (wie sie doch ziemlich häufig vorkommen) würden halsbrecherische Casts erzwingen...
Unsinn, das ist kein Problem. Umgekehrt wird ein Schuh draus.
 
gni   Nutzer

08.08.2005, 14:21 Uhr

[ - Direktlink - ]
Thema: Welcher Programierer traut sich an UPX
Brett: Amiga, AmigaOS 4

Zitat:
fisch08:
Packalgorithmen waren früher einfach schwerfälliger, weil die Rechner nicht schnell genug waren

Nö. PowerPacker, Imploder, CrunchMania etc. waren auch auf Rechner vor 10 bis 15 Jahren schnell. Das Auspacken fiel nicht wirklich auf, es sei denn man ließ die Farben des Mauszeiger scrollen und man hat mit dem Copper Farbbalken auf den Bildschirm gezaubert.
Zitat:
Und wenn ich bei 250 GByte 30% durch Packer einsparen kann, so sind das mal so eben 75 GByte an Speicher, der "mal eben" zur Verfügung steht...
Du solltest besser unnützen Kram löschen.
 
gni   Nutzer

08.08.2005, 14:15 Uhr

[ - Direktlink - ]
Thema: Welcher Programierer traut sich an UPX
Brett: Amiga, AmigaOS 4

Zitat:
Holger:
Ich kann mir auch nicht vorstellen, daß ein Archiv, daß als selbstentpackend für OS XYZ daherkommt, für den Amiga verwertbare Informationen enthält.

Richtig. Es geht aber auch nur darum, das man UPX gepackte Programme mit einem nativen UPX auf jedem anderen System auspacken kann.
BTW, es gibt Würmer/Tojaner, die mit UPX gepackt worden sind...
 
gni   Nutzer

08.08.2005, 14:12 Uhr

[ - Direktlink - ]
Thema: Welcher Programierer traut sich an UPX
Brett: Amiga, AmigaOS 4

Zitat:
alphamann:
UPX ist kein Packer im herkömmlichen Sinne er Packt ausfürbare Dateien so das sie ausführbar bleiben!!!

Das ist ein alter Hut.
 
 
Erste << 10 11 12 13 14 -15- 16 17 18 19 20 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.