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 << 44 45 46 47 48 -49- 50 51 52 53 54 >> Letzte Ergebnisse der Suche: 8130 Treffer (30 pro Seite)
Holger   Nutzer

05.05.2010, 11:26 Uhr

[ - Direktlink - ] 		Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von jolo:
2) Mit Windows-NT wurde zwingend die Benutzung der Referenznamen eingeführt um diese Probleme zu umgehen. Man kann aber heute noch die Referenztabellen verwenden (kann man?), diese sollten nach wie vor nominell vorhanden sein; macht nur keiner mehr, wegen der ungeliebten Blue-Screens - denke ich. ;)
Man kann Funktionen auch anhand ihres Index aufrufen. Das passiert auch in der Praxis, habe mal gerade auf die Schnelle nachgeschaut, die Funktion "Desktop anzeigen" in der Taskbar ist eine Verknüpfung auf shell32.dll, Funktionsindex -10113.

BlueScreens verursacht das allerdings höchstens, wenn jemand so verrückt ist, so etwas mit Treibern zu machen.

Zitat:
3) Eine DLL ist eine stinknormale, ausführbare Datei;
Das sind Amiga-Libraries auch.
Zitat:
... demnach müssen Suchvorgänge gestartet werden, um die Referenznamen zu ermitteln.
Schon klar, das ist eben der Unterschied zwischen symbolischen Linken und numerischen (oder manuellem).
Zitat:
5) Eine DLL klont immer ihren nicht-statischen Datenbereich, und zwar für jeden Thread/Prozess, das heißt, beim Öffnen und Schließen ist wesentlich mehr Arbeit seitens einer CPU gefragt als das bloße Hochzählen bzw. Runterzählen einer Variablen (OpenCount) auf Seiten einer Amiga Shared-Bibliothek.
Nun ja, so etwas wird heutzutage mit Sicherheit über Copy-on-Write Pages implementiert. Das heißt, es beeinflusst nur dann die Performance, wenn die Bibliothek auch tatsächlich unterschiedliche Daten pro Prozess haben will.
In dem Moment, wo das der Fall ist, kann man den Overhead sowieso nicht umgehen.

Zitat:
Dass die classic AmigaOS Bibliotheken unter m68k so effizient sind, hat den Grund, wie wir alle wissen, dass sie ausschließlich für m68k gedacht waren. Für andere Prozessoren und andere Programmiersprachen als m68k Assembler ist dieses Format aber alles andere als passend, so weit gebe ich euch Recht.
Und das ist umso faszinierender, wenn man bedenkt, dass Assembler zu keiner Zeit auf dem Amiga dominiert hat, von Demos und Spielen, die diese Bibliotheken eh nicht verwendet haben, mal abgesehen. Das AmigaOS selbst besteht größtenteils aus C-Code. (und BCPL...)
Zitat:
Nur, DLLs und Shared-Objects sind aber auch nicht gerade der Weisheit letzter Schluss, meiner bescheidender Meinung nach.
Das unterschreib ich sofort.

Zitat:
Da verwechselst Du was. Jede Bibliothek kann einen ganz anderen Initialisierungscode haben; Sprungtabellen können anhand von 32-Bit absoluten Adressen generiert werden (in C macht man das üblicherweise so), für Bibliotheken die ich in Assembler erstellt habe, benutzte ich aber 16-Bit Offsets relativ zur Funktion; zudem kann man im Initialisierungscode reinschreiben was man will, wie will da das Betriebssystem wissen, was es machen soll?
Die Betonung liegt auf kann. In der Praxis habe die wenigsten Bibliotheken anderen Initialisierungscode als der in den Beispiel-Bibliotheken und ob die wenigen, die davon abweichen, alle effizienter oder überhaupt korrekt sind, steht auf einem anderen Blatt.

Es geht hier nicht darum, dass die Möglichkeit zur individuellen Anpassung schlecht wäre, sondern um die Komplexität und Code-Doppelung bezüglich des Trivialfalls.
Zitat:
Zudem, wie ich oben schon einmal geschrieben habe, macht das Betriebssystem nichts mehr nachdem die Bibliothek einmal erstellt wurde; eine Bibliothek ist dann nur noch ein Haufen Code der irgendwo im Speicher schlummert und darauf wartet, dass irgendein Anwenderprogramm diesen Haufen Code ausführt. Nix mit Verwaltung seitens des OS. :)
Nun ja, das OS verwaltet schon die Bibliotheken. Anders kann ich das führen einer globalen Liste aller geladenen Bibliotheken und Bereitstellen der Verwaltungsfunktionen wie zum Öffnen und Schließen nicht bezeichnen.

Zitat:
Allerdings sollten Amiga Bibliotheken nicht nur thread-safe sein, sondern reentrant, dass heißt dann, dass keine modifizierbaren Daten den Funktionsaufruf überleben. Demnach braucht man auch keinen geklonten Datenbereich.
Ob man einen braucht oder nicht, entscheidet nicht das Bibliothekskonzept, sondern die Funktion. Und es gibt etliche Beispiele von modifizierbaren Daten, die einen Funktionsaufruf überleben.
Die einen sind Task-affin, wie zum Beispiel der ganze in der Prozess-Struktur untergebrachte I/O-Kontext, andere werden in globale Datenstrukturen eingehängt, wie geöffnete Fenster, wiederum andere müssen für jede Funktion von der Anwendung übergeben werden, wie z.B. ein RastPort.

Zitat:
Können wir dem Ganzen ein Ende setzen und sagen, dass Holger und Du nichts gegen Sprungadressenermittlung anhand von Bezeichnern habt, wogegen ich statische Offsets fest verankert im Programm favorisiere?
Mir geht es gar nicht darum, etwas zu favorisieren. Ich habe nur die Größenordnung des Performance-Unterschieds bezweifelt.
Es wäre auch nicht allzuschwer, eine symbolische Verlinkung für Programme zu implementieren, die auf dem Offset-Mechanismus aufbaut, wenn man das braucht. Die Schwierigkeiten von Thilo würden davon aber nicht verschwinden...

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

04.05.2010, 17:38 Uhr

[ - Direktlink - ] 		Thema: SFS-Error ?
Brett: Amiga, AmigaOS 4

Zitat:
Original von DaxB:
Die Fehlermeldung hatte ich auch schon. Bin mir nicht mehr sicher, ob das harmlos war, ...
Wie kann eine Fehlermeldung, die auf korrupte Daten hinweist, harmlos sein?

Zitat:
Original von McFly:
so, nach dem Backup der Partition nen Quickformat gemacht, Fehler weg :D
Ja, leere Partitionen haben selten strukturelle Fehler.
Zitat:
Dennoch doof, weil ich nicht weiß was den Fehler verursacht hat ?(
Ich finde es gut, dass Dich diese Frage beschäftigt.

Du solltest Deine Kopie der Daten besser behalten und ab zu aktualisieren (der Vorgang wird auch Backup genannt)...
Zitat:
das kopieren übers Netzwerk? Das wär ja dann blöd, wenn man viel Daten schaufelt....
aber egal, keine Daten wech....ist die Hauptsache :D
Ja, bis zum nächsten Mal...

Neben den hier bislang genannten Hardwarefehlern, an die ich nicht so recht glaube, können natürlich auch Fehler, wie z.B. eine falsche Partitionierung mit sich überlappende Partitionsgrenzen oder ein Bug im Dateisystem dazu führen. Solche Fehler werden erst mit größerem Füllstand der Partitionen akut.

Die Fehlermeldung deutet darauf hin, dass da wo eigentlich wichtige Partitionsdaten (wohl die Bitmap, die nicht mehr gelesen werden konnte) liegen müssten, plötzlich etwas anderes gefunden wurde (in diesem Fall der Beginn einer XML-Datei), d.h. diese Daten wurden von anderen Daten, die da nicht hingehören, überschrieben.

So etwas würde mich auch beunruhigen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

04.05.2010, 15:49 Uhr

[ - Direktlink - ] 		Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Eine GUI Applikation unter Windows kann auch ausgaben mittels printf machen. Man sieht sie nur nicht, weil keine Console aufgeht.
Aber man kann sie in eine File pipen.
Also als No-Go würde ich das nicht bezeichnen.
Das hängt von der Frage nach dem Warum ab. Wenn ich eine Library-Funktion für Berechnungen aufrufe, gehe ich nicht davon aus, diese Output erzeugt.
Wenn es etwas zu sagen gibt, sollte die Bibliothek das auf einen sauberen Weg dem Aufrufer mitteilen.

Es wäre schon inakzeptabel, wenn wichtige Meldungen verloren gehen, weil die Konsole unsichtbar ist, schlimmer wäre es wenn stdout eine Dateiumleitung ist, weil ich ein Resultat an ein anderes Programm weiterreiche. Da haben irgendwelche printf's nichts zu suchen.

Wenn die Bibliothek einen eigenen Logging-Mechanismus benötigt, der nichts mit dem I/O-Kontext des Aufrufers zu tun hat, wäre das ok und auch auf dem Amiga machbar. Das würde aber auch auf anderen Systemen nicht mit stdio funktionieren (und wird deshalb auch nicht mit stdio gemacht).
Zitat:
Wenn ich das richtig sehe ist der große Unterschied, dass DLLs jedesmal beim öffnen ihren eigenen Kontext erzeugen, während Amiga Shared Libraries nur einmal gestartet werden, und dann von mehreren Prozessen verwendet werden können. Das bringt natürlich einige Probleme mit sich, z.B. man kann bei printf nicht sofort sagen, was der richtige File Handle für den Output wäre.
Oder in welche Speicheradresse der Fehlercode geschrieben werden soll. Und vor allem benutzen die typischen Implementierungen, wie bereits gesagt, Puffer, die nicht thread-safe sind.

Trotzdem bereiten auch auf anderen Systemen Bibliotheken, die unerwartete I/O-Operationen durchführen, Probleme. Davon sollte man die Finger lassen.

Das gilt im Übrigen auch für die AmigaDOS-Funktionen. Wenn der Aufrufer beispielsweise asynchrone I/O benutzt, kann die Verwendung von AmigaDOS-Routinen in der Bibliothek zum Absturz führen.
Zitat:
Wenn man die vor und Nachteile abwiegt, ist die Amiga Shared Library etwas leichtgewichtiger als die DLL, aber viel schwerer vom Entwickler korrekt zu implementieren. Und eine Library, die 2ms länger braucht zum starten ist besser als keine Library. Dafür würde man sich heute wohl kaum mehr entscheiden.
So einfach ist das nicht.
Unter Linux geht man z.B. immer davon aus, dass das gesamte System von ein und demselben Compiler in exakt derselben Version mit denselben wesentlichen Optionen übersetzt wurde. Je mehr man davon abweicht, desto mehr Probleme kann man erwarten.

Bei den neueren Amiga-Betriebssystemen kann man ähnliches machen, weil es auch dort im Prinzip außer gcc nichts anderes mehr gibt, höchstens noch vbcc.

Aber beim "Classic" AmigaOS war das nie eine Option.
Zitat:
Zu Amiblitz:

...

Consolen Output ist möglich, wenn man sich den File Handle der Console bei jedem Aufruf vom aufrufenden Thread besorgt. Global darf man den natürlich nicht speichern.
Berücksichtigt das auch den Fall, dass es keine Console gibt, bzw. dass der Aufrufer nicht einmal ein Prozess ist?

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

04.05.2010, 14:20 Uhr

[ - Direktlink - ] 		Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von whose:
Wie von meinem Vorredner schon aufgezeigt, sooo doll ist der Aufwand eigentlich nicht. Davon ab, Nutzung der C-Runtime bedeutet nur "portabel bei ausschließlicher Nutzung der Möglichkeiten der Runtime/Standard-Link-Library". Streng genommen ist nicht einmal der Weg DLL/.so im Sinne des C-Standards "portabel".
Real-life Code und portabler Code im Sinne von C scheinen sich ohnehin von vornherein auszuschließen.
Zitat:
Mir ist auch nicht ganz klar, weswegen Du z.B. printf() verwenden willst. Für GUI-Programme wäre das selbst unter Win ein No-Go, es sei denn, Du baust auch dafür wieder Wrapper bzw. nutzt systemabhängige Lösungen.
Für shared libraries ist es sowieso ein No-Go, denn die Bibliothek weiß ja gar nicht, ob das aufrufende Programm ein GUI-Programm ist, bzw. ob es überhaupt eine Konsole besitzt, bzw. was es bedeutet, in die jeweilige Standardausgabe zu schreiben. Hinter dieser kann sich schließlich auch etwas ganz anderes als eine Konsole verbergen.


Zitat:
Original von jolo:
@whose:

"Winzigweich"?

Habe den Ausdruck noch nicht vernommen. :)
Das ist der Hersteller von äußerst bekannter Software namens "Fenster" und "Büro", wobei aber nicht, wie man meinen könnte, das Büro ein oder mehrere Fenster besitzt, sondern "Büro" innerhalb von "Fenster" installiert wird...

Zitat:
Ja, da hast Du Recht.
Allerdings kommt so etwas als zentrale Schnittstelle für ein schlankes, halbwegs effizientes Betriebssystem nicht infrage, weil:
a) zur Laufzeit externe Verweise aufgelöst werden müssen
b) zur Laufzeit die Sprungadressen ermittelt werden müssen
c) die Sprungadressen anhand des Namens ermittelt werden
d) ein zentraler Prozess die Nutzung dieser dynamischen Bibliotheken gewährleisten muss
Ähem.
So etwas passiert genau einmal nach dem Laden der Bibliothek, und ähnliches passiert auch beim Amiga, wenn nach dem Laden einer ausführbare Datei Adressen an die tatsächliche Position im Speicher angepasst werden.
Zitat:
In Zeiten von C#/Java und zig Giga-Hertz spielt das für Endanwender aber keine Rolle mehr, weil man es nicht wahrnimmt, bzw. die Geschwindigkeit als ausreichend erachtet.
Das gleiche für OS3, selbst mit einer 100 MHz 68060 CPU, würde abschreckend wirken.
Deshalb funktionieren DLLs selbst unter Windows 3.1 auf einem 386 mit 14MHz...

Zitat:
Ich gebe zu, dass eine Amiga-Shared Bibliothek um ein vielfaches schwieriger zu erstellen ist als eine '.dll', jedoch ist ihre Verwaltung aus Sicht einer CPU effektiver.
Wenn man bedenkt, dass der identische Library-Initialisierungscode, inkl. der Verwaltung des Zählers für Anzahl benutzender Programme sich in jeder Bibliothek erneut wiederfinden, statt einmal im Betriebssystem, relativiert sich diese Effizienz erheblich.

Die Design-Entscheidung, keine symbolischen Namen, sondern eine Tabelle mit 68k-Sprungbefehlen relativ zum Register A6 zu benutzen, die selbst unter der bevorzugten Programmiersprache C ein Fremdkörper ist, muss man akzeptieren. Aber nicht unbedingt glorifizieren.

Diese Art des Linkens ist aber auch gar nicht der Grund, warum man Amiga-Libraries nicht so wie Windows oder Unix-Libraries benutzen kann. Der springende Punkt ist hier, dass man nicht die Datensegmente einer Objektdatei automatisch pro Prozess anlegen lassen kann.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

29.04.2010, 19:06 Uhr

[ - Direktlink - ] 		Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Also, darf ich nun "sprintf" oder "fopen" in einer Shared Lib benutzen oder nicht?
sprintf könnte vielleicht noch funktionieren, von fopen würde ich die Finger lassen.
Zitat:
Unter Windows und Linux scheint das kein Problem zu sein. Haben dort die DLLs/SOs für jede offene Instanz eigene Addressräume, und die Funktionen müssen deshalb nicht thread-safe sein?
Ob die Funktionen thread-safe sind oder nicht, ist noch mal eine eigene Baustelle. Allgemein lautet die Antwort auf Deine erste Frage ja, die dynamisch geladenen Bibliotheken verhalten sich auf diesen Systemen kaum anders als zum Programm statisch gelinkte Bibliotheken.

Der (read-only) Programmcode wird zwar geteilt, alle Variablen existieren aber jeweils pro Prozess. Das heißt aber nicht zwangsläufig, dass die jeweilige Bibliothek noch korrekt arbeitet, wenn dieser Prozess mehrere Threads erzeugt und die Funktionen von mehreren Threads aus aufruft.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

28.04.2010, 21:01 Uhr

[ - Direktlink - ] 		Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von akl:
@Holger:

>Die C-Funktionen sind grundsätzlich nicht für den Einsatz in einer
>Amiga-Bibliothek geeignet

Das hängt davon ab, welchen Compiler mit welcher C-Laufzeitumgebung man nutzt, welche Funktionen man davon nutzt und ob und wie man sicherstellt, dass der Code "threadsafe" bleibt.

So verallgemeinert ist die Aussage nicht richtig.
Du hast ja auch die Aussage verallgemeinert, in dem Du sie aus dem Zusammenhang gerissen, und den einschränkenden Teil "es sei denn der Autor der spezifischen Version weist ausdrücklich auf eine solche Eignung hin" unterschlagen hast.

Dass es um stdio und real existierende Amiga-Compiler ging, war eigentlich auch klar.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

28.04.2010, 15:46 Uhr

[ - Direktlink - ] 		Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Ich kann mich erinnern, als ich mal eine Library compiliert habe, dass es Probleme mit fopen, printf etc. gab, irgendwas mit libnix in der Commandozeile war notwendig.
Wenn das alleine ausgereicht hatte, hattest Du nur verdammt viel Glück (Bzw. nicht ausreichend getestet). Die C-Funktionen sind grundsätzlich nicht für den Einsatz in einer Amiga-Bibliothek geeignet, es sei denn der Autor der spezifischen Version weist ausdrücklich auf eine solche Eignung hin.

Zitat:
Ist aber lange her, letztendlich hatte ich alles über AmigaOS API gemacht, aber das will ich eigentlich vermeiden.
Wenn es eine Amiga-Bibliothek werden soll, wirst Du nicht um Amiga-spezifischen Code herumkommen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

26.04.2010, 22:19 Uhr

[ - Direktlink - ] 		Thema: PlanePick / PlaneOnOff
Brett: Programmierung

Zitat:
Original von AGSzabo:
jetzt das so schön funktionierende blitten mit maske, funktioniert auch unter morphos, zeichnet auf einem a4000 mit kick 3.0 den hintergrund immer voll ORANGE ohne transparenz. will sagen das BlitMask..() will unter os 3.0 nicht funktionieren. was ist jetzt wieder los?
Du musst das OS im NO_ORANGE_BACKGROUND Modus starten.

Im Ernst, woher sollen wir wissen, was bei Dir los ist, wenn wir nicht mal ansatzweise wissen, was Du gemacht hast?

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

26.04.2010, 13:13 Uhr

[ - Direktlink - ] 		Thema: Virtualisierung?
Brett: Andere Systeme

Zitat:
Original von Rudi:
Einen neuen PC hab ich mir zugegebener zugelegt, da ich ein paar Spiele zocken wollte, die mein betagter 1,2 MHz PC nicht mehr "geschaft" hat (u. a. Bioshock und Doom 3).
Das ist ja kein Wunder, dass er das nicht geschafft hat. Ich hätte bei einem 1,2 MHz PC allerdings schon vor zwanzig Jahren ans Aufrüsten oder Ersetzen gedacht ;)

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

26.04.2010, 12:17 Uhr

[ - Direktlink - ] 		Thema: PlanePick / PlaneOnOff
Brett: Programmierung

Zitat:
Original von AGSzabo:
so, geschafft. jetzt funktioniert es: transparente images. wieso hat commodore nicht schon von anfang an so ne funktion bereitgestellt...
Das haben sie doch. Dass Du nach zwei Tagen begriffen hast, wie man sie benutzt, heißt ja nicht, dass Du plötzlich der Erfinder dieser Routinen bist.
Zitat:
lass mich doch, ich bin eben unsicher weil ich das nicht benutze in der regel.
Da hilft es dann vielleicht, wenn man Englisch-Kenntnisse anwenden kann, minimale reichen ja schon aus, um den Unterschied zwischen Carry und Equal herzuleiten.

Und wenn Du das "in der Regel" nicht benutzt, frage ich mich besorgt, was Du dann eigentlich machst, wenn Du zu programmieren glaubst.

Nun gut, die Anzahl derer, die glauben "programmieren" bedeute "in Foren fragen", scheint ja stetig zuzunehmen...

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

23.04.2010, 12:02 Uhr

[ - Direktlink - ] 		Thema: Bargeldloser Verkehr ! Einge gute Idee?
Brett: Get a Life

Zitat:
Original von DrNOP:
Ach, damit sollte ich warten, bis mir jemand was schuldet? :lach:
Iwo. Gründe einfach ein Inkassounternehmen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

23.04.2010, 12:00 Uhr

[ - Direktlink - ] 		Thema: Algo zum Kreiszeichnen
Brett: Programmierung

Zitat:
Original von Ralf27:
MB ist extrem langsam. In diesem Beispiel scheint es recht schnell zu sein,...
Eben. Und nur um dieses eine Beispiel ging es ja. Und da sich ja auch noch herausgestellt hatte, dass WritePixel() das Nadelöhr ist, und nicht der Basic-Code...
Zitat:
Eigentlich nicht. Aber hier scheint es mir wirklich so, das man denn Amiga auch noch Softwaretechnisch beschleunigen könnte.
Das wird nicht die einzige Routine sein, die weit von der Perfektion entfernt ist. Die allgegenwärtigen doppelt-verketteten Listen z.B. sind auch nicht für jede Operation die optimale Datenstruktur.

Das System hatte damals den anderen ein paar grundsätzliche Dinge voraus, man sollte es aber nicht als heilige Kuh der IT betrachten.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

22.04.2010, 19:14 Uhr

[ - Direktlink - ] 		Thema: Bargeldloser Verkehr ! Einge gute Idee?
Brett: Get a Life

Zitat:
Original von Maja:
Zitat:
Original von Holger:
Nix, aber darum ging es ja nicht. Es ging ja nur darum, dass ein System, in dem Buchgeld, warum auch immer, unmöglich wäre, ein System ohne Kredite wäre.
Wäre es nicht.
Danke für diese ausführliche Argumentation. Sie überzeugt mich allerdings nicht ganz, dass Du das Wesen von Buchgeld wirklich verstanden hast.
Zitat:
Zitat:
Und in dieser Hinsicht war Deine Formulierung "Eine Abwesenheit von Buchgeld" irreführend.
Auch nicht irreführender aus Deine Formulierung, "Schließlich sind Schulden eine Form von Papiergeld.".
Papiergeld ist eine Form eines Schuldscheins. Es stimmt zwar, dass die Umkehrung nicht 100% gilt, weil man natürlich auch Steintafeln oder Baumrinde benutzen könnte. Im Zusammenhang dieser Diskussion ging es aber lediglich um die Grobeinteilungen "Geld mit Materialwert", "Geld mit materiellem Träger ohne Wert (des Trägers natürlich)" und "Geld ohne materiellen Träger".
Zitat:
Original von DrNOP:
Sofern ich immer wieder ein neues Südamerika finde, von dem ich mir eine weitere Inflation importieren kann, ist eine Inflation mit Metallgeld möglich, ja.
Ob man das Material auf dem Grund der Meere oder im Weltraum findet, wäre dabei unerheblich. Aber neben der Vermehrung des Materials gibt es noch eine zweite Quelle für eine mögliche Verminderung des Wertes: eine Verringerung der Wirtschaftskraft bei gleichbleibender Geldmenge.
Zitat:
Original von Maja:
So oder so war der inlationäre Karakter von Papier als physikalische Erscheinungsform von Zahlungmitteln meines Wissens nie allein ursächlich für eine Inflation oder gar Hyperinflation.
So sieht's aus.
Allerdings wurde das auch nicht abgestritten. Amaris glaubt nur an eine unterschiedlich starke psychologische Hemmschwelle der Geldarten.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

21.04.2010, 18:59 Uhr

[ - Direktlink - ] 		Thema: Bargeldloser Verkehr ! Einge gute Idee?
Brett: Get a Life

Zitat:
Original von Maja:
Und? Was ändert das am Buchgeldmangel beim Schuldner?
Nix, aber darum ging es ja nicht. Es ging ja nur darum, dass ein System, in dem Buchgeld, warum auch immer, unmöglich wäre, ein System ohne Kredite wäre. Und in dieser Hinsicht war Deine Formulierung "Eine Abwesenheit von Buchgeld" irreführend. Die Anwesenheit eines Schuldners impliziert auch die Anwesenheit von Buchgeld, nur halt bei jemand anderen.
Zitat:
Original von DrNOP:
Und was haben wir dabei gesehen? Daß Spanien sich eigentlich nur eine Inflation importiert hat. Wenn ein Bauer vor diesen Plünderungen seine Wiese für 3 Silberstücke hergeben mußte, so bekam er nach der Silberschwemme eben 30 oder 300 Silberstücke für die gleiche Wiese.
Genau das nennt man Inflation. Dass also mit Metallgeld keine Inflation möglich wäre, ist damit widerlegt. Genau darauf wollte ich Amaris hinweisen.
Zitat:
Und ich denke schon, daß die Hemmschwelle an dieser Entsprechung willkürlich zu drehen höher ist, wenn man dafür neue Scheine drucken muß anstatt nur eine Zahl im Computer mit 1000 zu multiplizieren.
Da liegt ein Denkfehler vor. Unsere Staatsoberhäupter beschließen nicht einfach mal, ein paar Nullen an unser Geld anzuhängen. Die Festlegung des Euro-Wertes war eine Ausnahme. Heutzutage entsteht Inflation vorzugsweise dadurch, dass unsere Staatsoberhäupter Schulden machen, was einer Erhöhung der Buchgeldmenge entspricht und das vollkommen unabhängig von der Frage, ob es nebenher auch noch Scheine gibt oder nicht.

Der gesamte Staatshaushalt besteht nur aus Buchgeld. Alle Steuern und andere Abgaben werden per Überweisungen getätigt und fließen auch in die andere Richtung wieder per Überweisung.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

21.04.2010, 11:33 Uhr

[ - Direktlink - ] 		Thema: Bargeldloser Verkehr ! Einge gute Idee?
Brett: Get a Life

Zitat:
Original von Maja:
Zitat:
Schließlich sind Schulden eine Form von Papiergeld.
Eine Abwesenheit von Buchgeld.
Nö.
Wenn jemand Schulden hat, muss ein anderer zwangsläufig ein Guthaben besitzen. Also Buchgeld.
Zitat:
Zitat:
Das wusste man schon vor einigen tausend Jahren...
Hat Dir das ein Neandertaler beim Bier erzählt? ;)
Falsche Zeit und falsche Spezies, würde ich mal sagen. Neuer Versuch...


--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

20.04.2010, 15:30 Uhr

[ - Direktlink - ] 		Thema: Bargeldloser Verkehr ! Einge gute Idee?
Brett: Get a Life

Zitat:
Original von Amaris:
Wenn es nur Metallgeld gäbe (wie vor Jahrhunderten einmal), dann verliert das Metall nicht an Wert - falls nicht gerade riesige Gold-Vorkommen entdeckt würden oder sowas, die Geldmenge also konstant bleibt.
Oder zum Beispiel Spanien Südamerika plündert und große Silbermengen in Europa einführt oder England bei einer Währungsreform Gold mit Absicht überbewertet, um dafür zu sorgen, dass sich Silber als Umlaufwährung, Gold dagegen als Sparform durchsetzt.

Deshalb verwies ich ja darauf, dass es in der Vergangenheit bereits passiert ist. Nicht nur passieren kann.
Zitat:
Vielleicht verstehe ich jetzt aber auch deinen Einwand irgendwie falsch.
Scheint so.

Zitat:
Original von AC-Pseudo:
Der Wert von Gold und Silber war nie absolut, sondern immer nur in der Relation zu den Waren und Leistungen zu setzen, die man dafür erwerben konnte (von der Nutzung für Schmuckzwecke mal abgesehen).
Na ja, man kann Gold zu mehr als nur Schmuckzwecken gebrauchen. Aktive Computernutzer, die sich auch für die Vorgänge im Inneren etwas interessieren, sollten das wissen...

Zitat:
Original von Maja:
Jedenfalls schützt Bargeld gemeinhin offenbar nicht davor, auf Dauer mehr auszugeben als regelmäßig reinkommt.
Ein ausschließlich Edelmetall zulassender Zahlungsverkehr würde das durchaus verhindern. Schließlich sind Schulden eine Form von Papiergeld.

Allerdings wäre ein System, das grundsätzlich keine Schulden zulassen würde, sehr ineffizient. Das wusste man schon vor einigen tausend Jahren...

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

20.04.2010, 12:13 Uhr

[ - Direktlink - ] 		Thema: Daten retten
Brett: Amiga, AmigaOS 4

Zitat:
Original von ZeroG:
@Maja:
Ohne Hintergrundwissen über das verwendete Dateisystem dürfte das bestenfalls mit Dateien klappen die nur einen Block auf der Platte einnehmen und selbst dann ist da noch einiges (wie z.B. der Dateiname) im Argen.
Genau das ist bei SFS die bevorzugte Art, Dateien zu speichern.

Schließlich war das die Stärke von SFS gegenüber älteren Dateisystemen: Dateien nicht mehr als Ansammlung von Blöcken, sondern von Bereichen von Blöcken, für die es sich nur Start und Endblock merken muss, aufzufassen. Deshalb ist es gerade bei Seek innerhalb von größeren Dateien so viel effizienter (ich sag nur: ID3-Scan über mehrere Verzeichnisse...).

Und wenn man dem Defragmentierer auch ab und an eine Chance gegeben hat, schließlich konnte der auch im Hintergrund werkeln, dürften die Chancen ziemlich hoch sein, dass ein Scan der rohen Plattendaten Dateien erkennen kann.

Das klappt natürlich nur für bekannte Formate (JPG, etc.), und die Dateinamen kann man so natürlich nicht finden, das ist klar.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

20.04.2010, 11:52 Uhr

[ - Direktlink - ] 		Thema: Hintergrundbild für eigenen Screen laden
Brett: Programmierung

Zitat:
Original von whose:
Die Grafik setzt sich eigentlich hauptsächlich aus Bitmaps zusammen, die maskiert geblittet werden müssen, weil sie eben nicht rechteckig sind und zusätzlich sehr viele Überlagerungskombinationen bestehen.
Das habe ich schon verstanden.
Zitat:
Deswegen meinte ich, daß er, wie ausgefuchst der Algorithmus für die Blit-Reihenfolge auch sein mag, kaum Geschwindigkeitsgewinn bekommen wird. Die Möglichkeiten, maskierte Blits einzusparen, sind einfach an Zahl viel zu gering.
Ich habe ja von Anfang an betont, dass es sehr stark davon abhängt, wieviele Objekte vorhanden sind, und wie viele davon sich verändern.

Wenn Du 100 Objekte hast und alle Objekte von hinten nach vorne neu zeichnen musst, weil sich eines bewegt hat, kann ein Algorithmus, der dafür sorgt, dass Du nur 10 Objekte aktualisieren musst, enorm viel einsparen.
Zitat:
Meiner Meinung nach ist es daher sinnvoller, mehr Denk-Aufwand in die Übertragung der Grafiken ins Bild zu investieren. Sprich, eigene "Blit"-Funktionen zu entwickeln, die die beschriebenen Schwächen der graphics.library-Funktionen eben nicht haben.
Möglicherweise bringt es ja etwas, die 3D-Funktion der Grafikkarte zu benutzen. Das hängt von der jeweiligen Grafikkarte (und natürlich den Treibern) ab.
Zitat:
Original von Reth:
Und das wird vom System automatisch erledigt?
Ja.
Zitat:
Wie gesagt wäre das beim Hintergrund kein Problem, wenn dieser erst einmal vollständig ist, da er sich nicht ändert. Daher kann ich aus diesem immer rechteckige Bereiche nehmen. Diese müsste ich aber zunächst einmal den fertigen Hinter als eigenes Bild bzw. eigene BitMap verwenden, da er ja ursprünglich aus lauter 6-Ecken erstellt wurde!
Wenn Du den Hintergrund in einer eigenen BitMap vorhältst, wäre es Ressourcenverschwendung, beim Hintergrund-Layer auch noch Smart-Refresh einzustellen.

Die manuelle Variante ist aber auch nicht so schwer zu programmieren. Der Hintergrund-Layer muss nur dann aktualisiert werden, wenn sich ein darüber liegender Layer bewegt oder geschlossen wird. Wann immer Du eine solche Aktion durchführst, musst Du also danach das Dirty-Flag des Layers überprüfen. Wenn es gesetzt ist, dann rufst Du BeginRefresh auf, das bewirkt, dass die betroffenen Regionen in umgekehrte Clipping-Bereiche umgewandelt werden, auf deutsch, ab diesem Moment zeichnest Du nur in Bereiche, die die layers.library als beschädigt markiert hat. Dann musst Du nur einen Blit des gesamten Hintergrund-Bilders in diesen Layer durchführen und das System begrenzt diesen automatisch auf den neu zu zeichnenden Bereich. Danach rufst Du EndRefresh auf, um den Normalzustand wiederherzustellen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

16.04.2010, 18:27 Uhr

[ - Direktlink - ] 		Thema: Hintergrundbild für eigenen Screen laden
Brett: Programmierung

Zitat:
Original von whose:
Da bringt es ihm dann nicht viel, wenn er den Flaschenhals in der Tiefensortierung seiner Grafikobjekte vermutet, obwohl er eigentlich ganz woanders steckt und sein eigener Algorithmus zur Objektsortierung möglicherweise schon effizient genug ist, oder?
Es geht ja nicht um den Algorithmus zur Sortierung (die Objekte müssen so oder so sortiert vorliegen), sondern darum, dass man mit dem richtigen Algorithmus unterm Strich möglicherweise weniger Pixel transferieren muss, wovon man gerade dann profitiert, wenn der Transfer so langsam ist.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

16.04.2010, 18:22 Uhr

[ - Direktlink - ] 		Thema: Bargeldloser Verkehr ! Einge gute Idee?
Brett: Get a Life

Zitat:
Original von Amaris:
In früheren Jahrhunderten entsprach der auf einer Münze aufgeprägte Wert auch gleichzeitig ihrem Metallwert, siehe Kurantmünze.
Papiergeld war eher die Ausnahme. Und selbst das war vor nicht allzu langer Zeit noch mit Gold gedeckt.
Auch ein Metallwert ist nicht konstant.
So hat zum Beispiel Silber im Vergleich zu Gold in der Vergangenheit stark verloren.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

16.04.2010, 18:18 Uhr

[ - Direktlink - ] 		Thema: Telefonterror durch Anrufautomat
Brett: Get a Life

Zitat:
Original von Bogomil76:
http://amiga-news.de/forum/thread.php?id=32399&start=121&BoardID=5#336600
Was ich nicht verstehe ist der Fakt, was wollen die erreichen durch 10 Terroranrufe am Tag? Meinen die, irgendwann bin ich so blöde und gebe meine Daten raus?
Laut Deinen eigenen Aussagen hast Du Deine Daten (bzw. die Deiner Schwester) rausgerückt.
Zitat:
Original von Bogomil76:
http://www.amiga-news.de/forum/thread.php?id=32399&BoardID=5#330920
Ich habe auch mal zugesagt, nur um die Adresse zu haben (und dann dahin zu fahren und denen eine reinhauen, und ja das würde ich machen, sogar mit Ankündigung!, wobei die Adresse ja eh nicht stimmen wird), aber die haben nix abgebucht und nie was zu geschickt.
Zitat:
Original von Bogomil76:
http://www.amiga-news.de/forum/thread.php?id=32399&start=31&BoardID=5#331016
Ich habe ja auch wie gesagt schonmal zugesagt, Namen abgeglichen Kto Nummer (die die schon hatten usw), und die haben nix abgebucht und rufen dennoch an.
Zitat:
Original von Bogomil76:
http://amiga-news.de/forum/thread.php?id=32399&start=31&BoardID=5#331055
Ja, meine Schwester is auch schonmal drann gegangen, und hat das Gespräch bis zum Ende geführt, inkl. Bestätigung der Bankdaten (das habe ich ja schon geschrieben), das hat zu nix eführt. Keine Post, keine Abbuchung nur erneute Anrufe.
Zitat:
Original von Bogomil76:
http://amiga-news.de/forum/thread.php?id=32399&start=31&BoardID=5#331039
Aber auch der Fall das man denen ja sagt, bucht ab, macht was Ihr wollt (natürlich sachlich gesprochen) und es passiert NIX. Es wird nichts abgebucht, es kommt kein Zahlungsbeleg usw.

Deine Beiträge lesen sich immer noch schizophren...

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

16.04.2010, 17:50 Uhr

[ - Direktlink - ] 		Thema: Algo zum Kreiszeichnen
Brett: Programmierung

Zitat:
Original von Ralf27:
Zitat:
Versteh ich nicht. Wenn Du jetzt schon mit WritePixel und Bresenham schneller als die originale Routine bist, warum sollte es dann ohne plötzlich zu langsam sein?
Nur aus reinem Interesse.
Die Frage war nicht, warum Du Dich damit beschäftigst, sondern warum Du MB von vornherein ausschließt.
Zitat:
Hm, interesant. Müßte man mal testen um zu sehn ob das eventuell schneller wäre.
Davon gehe ich aus. Die Frage ist nur, ob der Gewinn den Aufwand rechtfertigt.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

16.04.2010, 17:46 Uhr

[ - Direktlink - ] 		Thema: Hintergrundbild für eigenen Screen laden
Brett: Programmierung

@whose:
Was Du schreibst, ist ja alles richtig. Aber ändert letztendlich nichts daran, dass ein Spiel, das nunmal nicht nur rechteckige Objekte besitzt (wie sähe das denn aus...), diese Objekte irgendwie zeichnen muss. Und egal, ob die Routine zum Zeichnen eines Objekts den Blitter oder die CPU, Chip-, Fast- oder VideoRAM verwendet, ändert das nichts daran, dass um diese Routine herum ein Algorithmus gebaut werden muss, der alle Objekt zeichnet, bzw. aktualisiert und das möglichst effizient.

Zitat:
Original von Reth:
Kann ich denn mit Layern und ClipRegions verhindern, dass dargestellte Objekte innerhalb eines Layers durch darüber liegende Layer und deren Darstellung "zerstört" werden?
Das würde eine Neudarstellung von überdeckten Objekten von "unten" nach "oben" erleichtern!
Was meinst Du mit zerstört? Die Teile, die von einem anderen Objekt verdeckt sind, sind auf dem Bildschirm auch nicht vorhanden. Wenn sich ein Objekt aus einer Verdeckung hervor bewegt, muss der Teil, der vorher nicht sichtbar war, aktualisiert werden, und zwar nur dieser Teil. Das beherrscht die layer.library.

Das ganze ist doch gar nicht so schwierig zu verstehen. Guck Dir die Workbench an, mache ein Dutzend Fenster auf und schiebe diese hin und her, auch mal eines, das teilweise hinter anderen liegt. Das sind nichts anderes als Layer, nur halt um Rahmen, Gadgets, MessagePort und Eingabeverwaltung erweitert. Aber die logische Zeichenfläche, das ist ein Layer.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

16.04.2010, 17:38 Uhr

[ - Direktlink - ] 		Thema: custom sizing gadget
Brett: Programmierung

Zitat:
Original von AGSzabo:
ich male ja jetzt schon dauernd das fensterhintergrund muster dahin. es sieht so aus als ob das gagdget trotz dass es unsichbar ist, einen eigenen layer hat?
Gadgets haben keine Layer. Nur der Rahmen hat einen, wenn Dein Fenster vom Typ GZZ ist.
Zitat:
Original von AGSzabo:
@thomas:
ja, genau so habe ich es gemacht.
Wenn Du es so gemacht hast wie thomas, dann fehlt bei Dir das Flag, dass es sich um ein Border-Gadget handeln soll.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

13.04.2010, 19:41 Uhr

[ - Direktlink - ] 		Thema: Algo zum Kreiszeichnen
Brett: Programmierung

Zitat:
Original von Ralf27:
Aber: Es kann doch nicht sein das das langsame MaxonBasic schneller ist als eine Systemroutine?!?
Doch, das kann.
Du schreibst selbst nur wenige Zeilen darüber:
Zitat:
Vorallem was interesant ist: Die Kreise vom System und die mit dem Besenham-Algo passen nicht 100% übereinander.
Also wenn das kein Indiz dafür ist, dass unterschiedliche Algorithmen verwendet werden...
Zitat:
Original von Der_Wanderer:
Der atomare Maxon Circle Befehl ist vermutlich deshalb schneller, weil er kein WritePixel verwendet (das mss ja jedesmal den Layer abklopfen), sondern evtl. nur einmal und dann direkt die Bitmap bearbeitet.
Gewagte Theorie, die sich aber leicht überprüfen ließe. Einfach mal ein Fenster so über das MB-Fenster legen, dass es den Kreis teilweise verdeckt.

Wenn die Zeichenroutine direkt in die BitMap schreibt, müsste sie das Fenster überschreiben.

Zitat:
Direkt spart man sich da massig Arbeit. Also die Bitmap EINMAL locken, einen Pixel zeichnen, Pixel Wort-Breite ermitteln und den Pixel dann direkt im Speicher kopieren.

?( Was genau willst Du locken, bei einer nicht-RTG-BitMap?

Zitat:
Original von Ralf27:
Die Frage die sich jetzt für mich stellt: Wie könnte man den WritePixel() Befehl jetzt "dreckig" umgehn? Also, wie am besten "Handmade" machen? Und MB versuch ich das erst nicht, da ich da vermutlich eh langsamer wäre.

Versteh ich nicht. Wenn Du jetzt schon mit WritePixel und Bresenham schneller als die originale Routine bist, warum sollte es dann ohne plötzlich zu langsam sein?

Von welcher OS-Version gehst Du eigentlich aus? Ältere Version sind, was WritePixel angeht, sogar noch schlimmer als AOS3.1: die verwendeten den Blitter, dessen Initialisierung schon mehr Zeit kostet, als einfach via CPU in die BitMap zu schreiben.

Es gibt, um auf Deine Frage zurück zu kommen, auch eine saubere Lösung, um WritePixel zu umgehen:

Erzeuge eine BitMap der Tiefe eins und setze in dieser die Pixel direkt von Hand. Das ist für eine OCS/ECS/AGA BitMap vollkommen legal, da es sich um Deine private BitMap handelt und keinerlei Layer o.ä. zu berücksichtigen sind.

Danach blitte diese BitMap in einer einzigen Operation in die Ziel-BitMap, unter Verwendung derselben BitMap als Maske. Verwende BltBitMapRastPort, damit die Layer korrekt berücksichtigt werden.


--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

13.04.2010, 19:12 Uhr

[ - Direktlink - ] 		Thema: Hintergrundbild für eigenen Screen laden
Brett: Programmierung

Zitat:
Original von Reth:
Vielleicht nicht ganz! Ich ermittle immer, welche Objekte sich überdecken und blitte diese dann vollständig durch ihre Masken neu.
Wenn ich das Layer-Beispiel richtig verstanden habe, wird durch Layer bereits die Ermittlung der Überdeckung gemacht, blitten muss ich allerdings immer noch selbst.
Irgendwie scheinen wir aneinander vorbei zu reden.

Nochmal: bis einschl. AOS3.9 hat ein Layer immer eine rechteckige Form und das heißt, alle Pixel unterhalb dieses Rechtecks werden immer als verdeckt betrachtet und deshalb werden alle darunter liegenden Pixel niemals neu gezeichnet.

Wenn Du in dieses Rechteck mit einer Maske blittest, bleiben alle in der Maske nicht gesetzten Pixel unverändert und enthalten somit einen unspezifischen Wert, der nur im absoluten Glücksfall dem Hintergrund entspricht, von dem Du offensichtlich willst, dass er an diesen Stellen durchscheint.

Die Form eines Objekts bestimmt zwei grundsätzliche Dinge:
  • welche Pixel es verdeckt und welche Pixel darunter liegende Objekte durchscheinen lassen, die somit gezeichnet werden müssen
  • welche Pixel beim Zeichnen durch das Objekt selbst verändert werden

    Mit Deiner Maske erledigst Du den zweiten Punkt, der erste fehlt aber.

    Zitat:
    Wie das? Indem man alle Objekte einer Ebene in denselben Layer legt und alle nicht betroffenen, darüber liegenden Layer vor dem Neuzeichnen sperrt?
    Um Himmels Willen nein.
    Wenn Du Layer verwendest, sorgt die Layers-Library automatisch dafür, dass nur die Zeichenoperationen im sichtbaren Bereich ausgeführt werden. Das hat mit dem Sperren von Layern überhaupt nichts zu tun.

    Einzige Voraussetzung ist, dass Du die Graphics-Funktionen benutzt, die ein RastPort-Argument erwarten, und dass in diesem RastPort auf den zugehörigen Layer verwiesen wird (bei RastPorts von Intuition-Fenstern ist das vom System bereits so eingerichtet).

    Genau deshalb kannst Du die Layer auch nicht für nicht-rechteckige Objekte verwenden: es wird automatisch alles beim Refresh weggelassen, was unterhalb eines solchen Rechtecks liegt. Und das ist für Deinen Anwendungsfall zuviel.

    --
    Good coders do not comment. What was hard to write should be hard to read too.
    •  
    Holger   Nutzer

    11.04.2010, 14:03 Uhr

    [ - Direktlink - ]     		Thema: Problem mit smbfs
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von Maja:
    Zum Beispiel Spiele speichern Konfig-Dateien u.a. im Programmordner als simple Textdatei. Doch wieso sollte ausgerechnet das Schreiben von Konfigurationsänderungen in eine Datei in C:Program FilesProgrammname höhere Rechte beim Programmstart erfodern als Änderungen an der Registry, die immerhin im Rootverzeichnis des BS liegt?
    Die Registry besteht aus mehreren Teilen, sog. Hives, von denen der, der für die persönlichen Einstellungen eines Benutzers zuständig ist, auch im Profil-Ordner des Benutzers liegt. Davon abgesehen gibt es für jeden einzelnen Registry-Eintrag, genauso wie für Dateien, explizit setzbare Zugriffsrechte.

    Natürlich kann man systemweite Einstellungen für ein Programm auch im Programmordner speichern. Man kann aber mit solch einer INI-Datei weder Änderungen an den Default-Werten für einen Benutzer ohne Administratorrechte, noch unterschiedlichen Einstellungen pro Benutzer verwalten.

    Das könnte man dann zwar mit mehreren INI-Dateien oder einer gemischung Verwendung von INI-Dateien und Registry hinbekommen, das resultiert aber letztendlich im Neuerfinden des Rads und entsprechender Ressourcen-Verschwendung.

    Mit der Registry hat man eine einheitliche Schnittstelle für alle Einstellungen.


    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    11.04.2010, 13:56 Uhr

    [ - Direktlink - ]     		Thema: Problem mit smbfs
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von tploetz:
    @Maja:
    Windows ist meiner Ansicht sehr kompliziert, ...
    Was ist denn bitteschön daran kompliziert, dass die Systemwiederherstellung dazu dient, das System wiederherzustellen, und damit zu einer System Neuinstallation komplett im Widerspruch steht?

    Nehmen wir mal für einen Augenblick an, die Systemwiederherstellung hätte nach der Neuinstallation funktioniert. Dann hättest Du jetzt ein System exakt im Zustand vor der Neuinstallation, also komplett vermurkst.

    Welche Sinn hätte dann Deine Neuinstallation gehabt?

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    10.04.2010, 19:44 Uhr

    [ - Direktlink - ]     		Thema: Problem mit smbfs
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von Maja:
    Windows Software und Registry:
    Vorausgesetzt es gibt tatsächlich eine Richtline, mit der Microsoft das Ablegen von Konfigurationsdaten im Programmordner kategorisch ausschließt, verstoßen aber reichlich viele Programmierer dagegen. Nämlich alle, deren Programme (auch) über Konfig-Dateien im Programmordner verfügen.
    Richtig, das sind meistens die Programme, die nur im Administratormodus funktionieren, weil sie sonst nicht ihre Konfigurationen schreiben können.
    Gibt's allerdings heutzutage wieder, und zwar als "portable Software", die allerdings vorzugsweise nicht in "C:Programme", sondern auf einem Wechseldatenträger, der nur von einem User benutzt wird, installiert werden soll.
    Zitat:
    tploetz fehlt es offenbar an den einfachsten Grundlagen. Hat daher IMHO keinen Zweck, ihn mit endlosen Details zuzuschütten.
    Ich weiß nicht so recht, was überhaupt Zweck hat, wenn jemand sein System neu installiert, und es dann mit der "Systemwiederherstellung" wiederherstellen will...

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    10.04.2010, 19:39 Uhr

    [ - Direktlink - ]     		Thema: Problem mit smbfs
    Brett: Amiga, AmigaOS 4

    Bild: http://www.smilies.4-user.de/include/Wut/smilie_wut_027.gif

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
     
    Erste << 44 45 46 47 48 -49- 50 51 52 53 54 >> Letzte Ergebnisse der Suche: 8130 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-2024 by amiga-news.de - alle Rechte vorbehalten.
    .