Software > Alternative Betriebssysteme
Diskussion: Weiter-Entwicklung einer universellen MiNT Distribution
Thorsten Otto:
--- Zitat von: ari.tao am So 27.05.2018, 23:56:55 ---^^-- Das liegt aber nicht an MiNT bzw. seiner Mem.Prot., sondern daran, daß sehr viel Atari-Software diesbzgl. ProgrammierFehler enthält, die nicht mehr beseitigt wurden.
--- Ende Zitat ---
Den meisten Programmen kann man das aber gar nicht vorwerfen, weil sie geschrieben wurden bevor es MP überhaupt gab. Problem ist halt daß es von den meisten dieser Programme danach keine Updates mehr gab.
--- Zitat ---Wäre schön, wenn es zumindest irgendwann eine MiNT-Version gäbe, mit der man das für einzelne Prge. festlegen könnte
--- Ende Zitat ---
Sofern es Protokolle betrifft, könnte man das theoretisch auch im AES erledigen, indem man dort die Parameter umkopiert. Dann müsste man MP für solche Programme nicht mal ausschalten. Kostet aber natürlich wieder ein bisschen Speicher, und ist theoretisch auch etwas unschön.
Gast120501:
--- Zitat von: ari.tao am So 27.05.2018, 23:56:55 ---Jeder Progr´er sollte sich eine Partition mit Mem.Prot. einrichten, um die eigenen Prge. daraufhin zu checken.
--- Ende Zitat ---
Warum sollte man das über eine eigene Partition mit einer weiteren MiNT Installation erledigen? Man kann es doch beim Booten von MiNT umschalten?!?!?
mfro:
--- Zitat von: ari.tao am So 27.05.2018, 23:56:55 ---... Wäre schön, wenn es zumindest irgendwann eine MiNT-Version gäbe, mit der man das für einzelne Prge. festlegen könnte ...
--- Ende Zitat ---
Wozu soll das gut sein?
Wenn Du einem einzigen Programm erlaubst, in Speicherbereiche zu schreiben, die ihm nicht gehören, kannst Du MP gleich für alle ausschalten - es verliert seinen Sinn.
Das wäre, wie wenn man festlegen würde, dass Rot-Grün-Blinde an roten Ampeln nicht mehr zu halten brauchen.
--- Zitat ---... Wäre schön, wenn es zumindest irgendwann eine MiNT-Version gäbe, mit der man das für einzelne Prge. festlegen könnte ...
--- Ende Zitat ---
--- Zitat ---... das ist wirklich etwas mühsam, diese für jedes einzelne Prg. einzurichten
--- Ende Zitat ---
... und dass Du hier einen etwas seltsamen Widerspruch produzierst, ist dir schon klar, oder?
Gast160608:
^^-- Kein Widerspruch - da hat mich TO in #60 besser verstanden als Du. Aber wie er das mit dem AES regeln will, das weiß ich auch nicht (genauer: Ich kenne ein berüchtigtes Bsp., das imho per AES unlösbar ist).
Aber Leute, das artet jetzt in eine Diskussion über MiNT-Interna aus, dafür ist an dieser Stelle nicht der richtige Ort! Es geht doch um´s Einrichten von MiNT für Anfänger? Es ist schon irgendwo zwischen dreist und unverschämt, wenn ein Anfänger entgegen dem Rat der Hl. Schriften - rtfm! - mal eben MP einschaltet und sich dann über Probleme beschwert. Und man säge nicht am Ast auf dem man sitzt!
Ich habe selbst schon die nötigen Flags in unzähligen Prg.-Headern gesetzt, aber leider keine Liste davon angelegt.
--- Zitat von: Thorsten Otto am Mo 28.05.2018, 03:05:49 ---
--- Zitat von: ari.tao am So 27.05.2018, 23:56:55 --- ... Mem.Prot. ... ProgrammierFehler...
--- Ende Zitat ---
Den meisten Programmen kann man das aber gar nicht vorwerfen, weil sie geschrieben wurden bevor es MP überhaupt gab.
--- Ende Zitat ---
Mangelnde Hygiene ist nicht ein Problem, das erst durch Erfindung der Seife erzeugt wird.
PS: noBuddy is pörfaked. Ich bemühe mich immer um sorgfältige Formulierung - aber das schriftliche Medium ist und bleibt tückisch.
mfro:
--- Zitat von: ari.tao am Mo 28.05.2018, 10:20:05 ---^^-- Kein Widerspruch - da hat mich TO in #60 besser verstanden als Du. Aber wie er das mit dem AES regeln will, das weiß ich auch nicht (genauer: Ich kenne ein berüchtigtes Bsp., das imho per AES unlösbar ist)...
--- Ende Zitat ---
Thorsten Otto redet - wenn ich das richtig verstehe - i.W. von Protokollen (wie beispielsweise dem AV-Protokoll oder OLGA, oder ...).
Diese Protokolle basieren auf AES-Messages, die zwischen Applikationen hin- und hergeschickt werden und so gegenseitig Daten, aber auch Zeiger auf applikationsinterne Speicherbereiche austauschen.
Mit MP krachts dann beim Zugriff auf solche Speicherbereiche, wenn sie nicht per Mxalloc(..., MX_GLOBAL) allokiert wurden (was bei Programmen, die davon nichts wissen, natürlich nicht der Fall ist).
Thorsten's Ansatz ist nun wohl, im AES (das das als Kernel-Bestandteil darf) die referenzierten Speicherbereiche in einen solcherart allokierten Puffer umzukopieren (und nach dem Call wieder zurück).
Von welchem geheimnissvollen "Bsp." redest Du?
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln