Zitat:

---

Hab ich mir angesehen, brauchts dafür wirklich sooo viel zeugs?

---

Zitat:

---

Habe von SSL leider keine Ahnung

---

Zitat:

---

Original von tploetz:
es wird bei AmiDVD und FryingPan angezeigt, das das Laufwerk 24fach schreiben kann auf CDRW.

---

Zitat:

---

Original von AGSzabo:
stell euch vor, ich HABE in den docs gelesen. das feld das ich meinte war darin aber NICHT explizit mit "darf null sein" gekennzeichnet. ich habe es inzwischen aber so gelöst, dass ich einfach auf dem stack genügend platz schaffe, obwohl ich den inhalt dann nacher nicht brauche..

---

Zitat:

---

Original von AGSzabo:
ps: jetzt beginne ich zu verstehen. aber was hat es mit der textExtent-Struktur auf sich? muss ich die providen? ich brauche sie nicht! darf das feld null sein?

---

Zitat:

---

Original von Ralf27:
Ich hab noch nie denn Rückgabewert von Seek() benötigt. Dann dürfte gerade das doch eigentlich kein Problem sein?

---

Zitat:

---

Original von Ralf27:
Es dürften dann aber auch mehr als 4GB möglich sein, wenn man bei Seek nicht zu große Sprünge (<2^31) macht. Seh ich das richtig?

---

Zitat:

---

Original von nujack:
Ich habe nun auch die aktuelle Version von YAM 2.5 unter OS4 ClassicPPC installiert. Alte Mails habe ich unter OS3.9 in YAM2.4 exportiert und dann in YAM2.5 wieder importiert. Beim Aufruf alter Mails kommt es nun vereinzelt zu folgender Fehlermeldung:

Beim Dekodieren der Quoted-Printable (QP) Datei 'T:YAMr00000023-p1.txt' wurden unerlaubte Zeichen gefunden und in der undekodierten Version entfernt.

---

Zitat:

---

Dann werden Selbstlaute wie ä,ö,ü etc. nicht mehr korrekt dargestellt. In den Prefs/Zeichekodierung ist fest ISO-8859-1 eingestellt(analog Systemeinstellung), das Flag für Autoerkennung kyrillischer Zeichensätze ist angeflagt.

---

Zitat:

---

Original von Maverik:
Wie sich durch andere User bei A1k raustellte sind wirklich die MUI Klassen an dem Fehler schuld. Ich selber kam noch nicht dazu die alten wieder zu installieren, aber andere waren schon schneller die hatten auch den gleichen Fehler.

---

Zitat:

---

Original von mboehmer:
Also: sind die CachePreCMA() und CachePostDMA() Funktionen unter OS4 momentan broken, oder handelt es sich um ein prinzipielles Problem?
Zweiteres scheint nicht so, denn MOS benutzt ebenfalls den PPC, und dort gehts ja...

---

code:

---

With release 50, CachePreDMA/CachePostDMA is considered obsolete.
Instead, StartDMA/EndDMA should be used.

Due to the virtualized address space of AmigaOS 4, device drivers
doing DMA *MUST* use either CachePreDMA/CachePostDMA or
StartDMA/EndDMA, *and* be prepared for segmented transfers.

---

Zitat:

---

Original von Bluebird:
und was das lange laden angeht haste wohl recht wobei der umfang auch ganz schoen zugelegt hat , also die prefs sind ja jetzt fast doppelt soviele geworden und ne prog datei von ueber 1mb !
also mit dem schnellen mails holen ist nun nix mehr hehe

---

Zitat:

---

Original von Mason:
Derzeit spiele ich etwas mit YAM herum und habe das Problem, daß ich zwar Mails über meine 1&1 Adresse empfangen, aber nicht senden kann.

---

Zitat:

---

Original von MaikG:
Das die statt 128/256MB, 1 GB benutzen können und daher kein
Virtuellen Speicher brauchen.

---

Sag mal, wie überzeugungsresistent bist du eigentlich? Virtueller Speicher hat nichts, aber auch wirklich gar nichts mit dem zu tun, was du dir gerade vorstellst.

Du meinst virtueller Speicher würde bedeuten, daß bei Speichermangel lange unbenutzte Speicherbereiche auf die Festplatte ausgelagert werden und dann anschließend wieder realer Speicher zur Verfügung steht.

Diese Meinung ist falsch!!!

Virtueller Speicher bedeutet nur, daß die Adresse, die ein Programm sieht, nicht notwendigerweise mit der Adresse, die die CPU sieht, übereinstimmen muß. Durch diesen Unterschied zwischen physikalischer und virtueller Adresse müssen DMA-fähige Treiber halt bestimmte Aktionen unternehmen, um trotzdem noch korrekt zu funktionieren.
Virtueller Speicher bietet den großen Vorteil, daß eine Ansammlung von physikalisch zerstückelten Speicherbereichen von dem Programm als ein zusammenhängender Block adressiert werden kann. Man braucht sich also um die einzelnen Fragmente keine Gedanken zu machen. Die nötige Adressumsetzung erledigt die MMU on-the-fly und transparent. Und darum ist es auch nicht möglich die langsamen 16MB vom Motherboard mit einer niedrigeren Priorität, so wie es beim alten Speichersystem möglich war, als zusätzlichen Block ins System einzubinden. Die Basis für virtuellen Speicher ist ein großer, zusammenhängender Block, in dem alle Addressierungen passieren. Wäre es möglich die zusätzlichen 16MB da irgendwie mit einzubinden, dann könnte es passieren, daß ein Zugriff auf die (virtuelle) Adresse x ein vielfaches der Zeit wie der Zugriff auf Adresse x+1 dauert, weil die aufeinanderfolgenden virtuellen Adressen an 2 komplett unterschiedlichen physikalischen Adresse liegen. Nicht sehr erstrebenswert, möchte ich mal sagen.

Was du unter virtuellem Speicher verstehst nennt sich "Pager". Aber den hat OS4 zur Zeit noch gar nicht. So ein Ding würde dir wirklich bis zu einem gewissen Grad "mehr" Speicher geben. Aber auch nur bis zu einer (für dich wahrscheinlich zu kleinen) sinnvollen Obergrenze. Allerdings ist der Wirkungsgrad eines Pagers auch stark vom verfügbaren physikalischen Speicher abhängig. Wenn das System mehr Zeit damit verbringt Daten zwischen RAM und Platte hin- und herzuschaufeln, weil dauerhaft nicht genug physikalischer Speicher zur Verfügung steht, dann "steht" alles und man hört nur die Platte rödeln. Das wiederum nennt man dann "Windows"

code:

---

While *psn

---

code:

---

While *psnpsn_Nodeln_Succ

---

Zitat:

---

Wenn ein 604e@180 mit JIT 060@50 bringt, stimmt die angenomme
wartezeit in etwa. Allerdings wird ein 020 angenommen hat man da enorme
differenzen.

---