ReactOS Forum

Windows NT lief auch mal auf der PowerPC Architektur, die Unterstützung wurde aber eingestellt.

Soweit ich weiß war das aber auch nur NT 4.0, oder?

TiKu wrote:

Guennie1568 wrote:Na, ich glaube z.B. nicht, das ein MAC (mit Ausnahme des Intel-MACs) mit Windows laufen würde

Was daran liegt, dass es kein für diese Architektur kompiliertes Windows gibt.

hach ist das leben nich schöön
Hy Tiku *freu* Dir auch noch n' gutes neues Jahr

aber das kann sich ja mit Reactos ändern, denn ich glaub, wenn das soweit fertig ist,
werden sich die Leutz drauf stürzen und mal richtig mächtig drann rumbasteln sowie
das dann führ ihre Zwecke zurecht schustern und mit unter es dann sicherlich auch
auf andere Architeckturen portieren, 100 pro sogar und jetzt macht ja Balmer ne öffentliche beta,
der weis, weshalb er das ganze jetzt immer mehr öffnen muss und nicht anders kann..
Reactos wird 1000 Pro Win den Rang ablaufen sowie auch weil die sourcecodes offen sind..
jeder X-Belibige entwickler kann damit rum werkeln und es passt dann. dann ist man nichtmehr auf
Microsoft angewiesen *hehe*

von daher, denk ich, daß es nichtnur später auf ppc sondern auch auf mac's rennen wird..
die Politik, die Apple+Microsoft betrieben haben, wird sich bei beiden Firmen schmerzlich rächen..

von daher seh ich da keine Schranken von wegen portierung..

liebe Grüße
Blacky

Erstmal finde ich es gut, dass hier wenigstens versucht wird, wirklich mal einen Thread aufzumachen bei dem die wirklich kommenden Neuerungen aufgezeigt und erläutert werden. Wäre schön, wenn man dazu noch einiges von technisch Erfahrenen hören könnte.

Zum Thema Port auf PPC und Co.:
Sicherlich ist es möglich ReactOS auf so ein System zu portieren. Nur ist es mehr als fraglich, ob das ganze konzeptionell sinnbringend ist.
ReactOS definiert sich ja daraus ein Windows-kompatibles System zu sein, das halt open source ist. Das heißt im wesentlichen, dass die Programme, die für Windows veröffentlicht wurden, auf unter ReactOS laufen zu lassen.

Daraus besteht das ganze Interesse an diesem Projekt, da man sonst ja schon eine Breite an alternativen Betriebsystemen hat. Ein Support von PPC etc. würde eine Abkehr bedeuten. Nun kann man versuchen ein PPC-Port möglichst API-konform zu halten. Eine zusätzliche Kompilierung ist aber zwingend erforderlich. Reden wir gar nicht von den nicht zu vermeindenden Code-Änderungen(siehe 64-bit unter Windows...).

Doch dazu muss man die Hersteller(OSS-Programme klammern wir mal aus, weil diese im wesentlichen kein Argument für ReactOS sind) erstmal bewegen. Und das wird schwierig ohne Markt. Dafür braucht man eine entsprechende Größe(>=Linux) auf dem Desktop, auf den ReactOS ja konzeptionell primär ausgerichtet scheint. Entsprechend brauchen wir uns für die nächste Dekade darüber keine wirklichen Gedanken machen. Und wie dann Windows aussieht und inwieweit x86(32bit und 64 bit) dann Konkurrenz auf dem Desktop hat, mischt die Karten sowieso wieder neu.

Speedator wrote:Zum Thema Port auf PPC und Co.:
Sicherlich ist es möglich ReactOS auf so ein System zu portieren. Nur ist es mehr als fraglich, ob das ganze konzeptionell sinnbringend ist.
ReactOS definiert sich ja daraus ein Windows-kompatibles System zu sein, das halt open source ist. Das heißt im wesentlichen, dass die Programme, die für Windows veröffentlicht wurden, auf unter ReactOS laufen zu lassen.

naja, es gab zumindest früher ein projekt, das ein java-betriebssystem entwickeln wollte. dafür kam die idee auf reactos als unterbau zu verwenden, um darin eine java-vm als teilsystem laufen zu lassen (anstatt des win32 teilsystems). insofern macht es durchaus sinn, weil der nt-kernel vom design her auch was anderes als win32-programme laufen lassen kann. davon wurde früher auch fleißig gebrauch gemacht (nt 4 wars glaub ich, das noch os/2-programme unterstützte), aber bis auf win32, win16 und dos wurde mittlerweile alles fallengelassen.

Pythagoras1 wrote:

Speedator wrote:Zum Thema Port auf PPC und Co.:
Sicherlich ist es möglich ReactOS auf so ein System zu portieren. Nur ist es mehr als fraglich, ob das ganze konzeptionell sinnbringend ist.
ReactOS definiert sich ja daraus ein Windows-kompatibles System zu sein, das halt open source ist. Das heißt im wesentlichen, dass die Programme, die für Windows veröffentlicht wurden, auf unter ReactOS laufen zu lassen.

naja, es gab zumindest früher ein projekt, das ein java-betriebssystem entwickeln wollte. dafür kam die idee auf reactos als unterbau zu verwenden, um darin eine java-vm als teilsystem laufen zu lassen (anstatt des win32 teilsystems). insofern macht es durchaus sinn, weil der nt-kernel vom design her auch was anderes als win32-programme laufen lassen kann. davon wurde früher auch fleißig gebrauch gemacht (nt 4 wars glaub ich, das noch os/2-programme unterstützte), aber bis auf win32, win16 und dos wurde mittlerweile alles fallengelassen.

ztztztzt.. es gibt auch leute die Scheuklappen haben

eine portierung auf generelle Architekturen wie die des Handys , Arm und vieles andere ist deshalb sehr vorstellbar, weil es eben funtionabilität mit sich bringt.. Genauso wie das Java-Project das denn als Aufsatz auf den Kernel sowie die vorhandene Treiberarchitectur die derzeit flexibler Programmiert wird, als die von Microsoft das machen , ergibt einiges an Sinn denn dadurch resultiren genauso, als wenn jetzt Python genommen werden würde(soll jetzt nur ein Beispiel sein) oder Pascal, eine Reihe von Lösungsansätze oder Lösungen, die wiederrum flexiblere oder detaiertere Lösungen resultieren. Der eine ist Webberreich, mit Java, Sowie im reinen Anwendungsbereich beim US-Militär um div. anderen Einrichtungen.. Wo zum Beispiel "M" Benutzt wird wie in Krankenhäuser auch als MUMPS bekannt das genauso stabiel ,wenn nicht stabieler, als c+ sowie um einiges funktioneller, auch AI-Algoryghment werden in M geschrieben, denn dadurch geben sich nicht nur flexible verarbeitungsmöglichkeiten, sondern es gibt in dieser programmiersprache "M" nicht nur 1/0 sondern 1 und oder 0 dadurch bekommt man auch Entscheidungs sowie Lehrnmöglichkeiten , ich glaub Elledan programmiert sogar AI, aber ich glaub nicht mit "M" ... ist auch egal, das soll alleine als Beispiel dienen .. es ist egal, auf welcher Architectur Reactos laufen wird, es ist egal mit welcher Oberfläche Reactos laufen wird, ein ist klar, die Source Codes sind offen und frei, dadurch resultieren für jeden Hobbyprogrammierer, Vollprogrammierer sowie Nerd, Geek und Vollirren sowie Vollkkirren (Lieb gemeint*kicher*) Möglichkeiten, die man frei und unbedenklich ausschöpfen kann, wenn dann ein Reactos steht mit Systemverzeichniss - Spiegellung in's Userverzeichniss ,das erlaubt Dinge zu ersetzen/aus zu tauschen, direckt in das Systein ein zu flechten des Users, das im Useraccount rennt ,so ist es denn auch möglich weiterführende Programmierarbeit zutätigen und etwas auf zu bauen, das wir kaum für Möglich glaubten, weil wir nicht ein einziges mal daran gedacht haben,
aber es möglich ist durch Portierung und Netzwerk-zusammenschluss. Danach dies dann/danach in das System als solches ein fließen lassen kann, sei es denn als Update, Systemerweiterung oder Zubehör. Alleine durch die Möglichkeit der Portierung auf andere Systeme und der nicht Wegfall um Win32binarys aus führen zu können ergeben sich in Reactos wiederrum Möglichkeiten die dem des Linuxsystems gleich kommen .. Wenn man Linux auf einen Mac installiert, fällt doch nicht die Binärkompatiebilität weg.. das ist Schwachsinn... irgendwo hab ich doch das gelesen.. von wegen portieren und dann muß man die apps auch um bauen.. ich glaub das war wegen ARM ...
Das der Kernel auf ARM rennt und das dann die Treiber/Achtektur-unterstützung- für die Architectur dabei sein müssen, ist klar, aber daß dadurch die Win32 Binärkompatiebilitöt wegfällt find ich für Schwachsinn.. aber ich hab mich darauf eingelassen alleine wegen der Menge an Open source um einfach auf zu zeigen, daß es eben echt genug Open Source gibt um auf Kommerzielle oder Propitätre Lizenzen verzichten zu können, hier, Reactos entsteht auch auf einer freien Lizenz.. uff.. das war jetzt mal über meine finger gesprochen... lag mir hald jetzt auf den Fingernäglen..

Das mal im Allgemeinen einfach so Lapidar dahin gesagt..

liebe Grüße
Blacky

Pythagoras1: Theoretisch ist viel möglich. Java-Bytecode ist kein Maschinencode. Dafür müsste man dann nur eine angepasste virtuelle Maschine für das System haben. Das habe ich auch nie ausgeschlossen. Aber was macht es momentan für einen Sinn ein Java-Betriebssystem aus ReactOS aufzubauen, obwohl es da doch diverse Alternativen gibt, die im Gegensatz zu Reactos bereits einen "stabilen Stauts" aufweisen?

Und auch in Hinblick auf Blackcracks Kommentar - nichts neues und nicht wirklich bezogen auf meine Ausführungen - will ich nochmal betonen, dass es mir um das Konzept hinter ReactOS, warum es ReactOS gibt, warum es vorangetrieben wird, geht. Wie gesagt theoretisch kann man alles machen. Aber ob das sinnvoll ist oder nicht ist immer eine andere Frage. Und wenn sich einer findet und ReactOS auf eine andere Hardwarearchitektur portiert, dann bin ich der letzte der sagt: "lass das!". Wenn jemand daran Spaß hat, dann freut mich das. Aber ob das jetzt ein zentrales Ziel für ReactOS sein sollte, weiß ich nicht...

Btw. Blackcrack: Den Mac/Linuxbezug musst du dir selber ersonnen haben. Also ich habe das nicht erwähnt. Da die Macs heute bekanntlich im wesentlichen PCs sind, braucht es da keine extra Kompilierung. Anders kann man z.B. beim Mac am PowerPC-x86-Switch(Stichwort: Rosetta) sehen, dass deine weiteren Ausführen diesbezüglich keine Ansichtssache sind, sondern schlichtweg flasch oder wie du sagen würdest "Schwachsinn" . Ein Programm, das auf einer x86-Architektur mit einer Linux-Distribution nativ läuft, läuft ohne Emulation nicht auf der gleichen Distribution unter PowerPC. Es sei denn man kompiliert den Quellcode neu.

Da muss man kein Programmierer zu sein. Das ist Allgemeinbildung. "Informieren" und "begründen" sind ganz nette Vokabeln. Die kann man auch im Duden finden und nicht nur "behaupten". Behaupten kann man viel und sich ausdenken. Ich kann auch behaupten und mir denken, dass hier grad ein rosa Kaninchen hinter mir sitzt. Ob ich mich da nun informiert(mich mal umgedreht und nachgeschaut) habe und hier eine Begründung hinterlege, ist eine andere Frage

Grundsätzlich ist die Idee für ein ARM Reactos prima. Es stimmt schon: Erstmal laufen damit keine 'üblichen' Anwendungen. Aber in Verbindung mit einer passenden JIT Engine für .NET (hier könnte man mal Richtung MONO:ARM schauen) wird die ganze Geschichte zukunftstauglich.
Die grössten Probleme der Linuxwelt und der non-x86 Welt bleiben jedoch. Treiber sind und bleiben inkompatibel und 98% der verfügbaren Applikationbasis sind nicht nativ ausführbar; wo jedoch zu hoffen bleibt dass .NET oder ähnliche Konzepte in Zukunft auch in der kommerziellen Softwareentwicklung verbreiteter werden.

Wenn das Entwicklerteam mit der ARM-Adaption Hilfe braucht bin ich gern bereit ein wenig mitzuhelfen. Wo klemmts hier noch?

PS.: Den Low-End-Markt nicht zu vergessen. Auf Embedded Devices koennte so ein ReactOS einschlagen wo noch Windows CE zu finden ist. Sehr viel eher als auf Desktops wuerde ich schaetzen.

Sivar wrote:wo jedoch zu hoffen bleibt dass .NET oder ähnliche Konzepte in Zukunft auch in der kommerziellen Softwareentwicklung verbreiteter werden.

Ich glaub', es hackt!
Ein Programm, dass ohnehin in 99% der Fälle auf ein und derselben Architektur ausgeführt werden wird, soll gefälligst auch für diese kompiliert sein.
Plattformunabhängigkeit hin oder her. Die Nachteile von auf ein einziges proprietäres Betriebssystem ausgerichteter dynamischer Kompilierung liegen eben auf der Hand.
(Wer z.B. würde freiwillig außerhalb des Internets ausschließlich Java-Programme benutzen? Java wirbt dabei noch damit, portabel zu sein, .NET ist es offiziell nicht einmal.)

Dann jag die .net-Programme eben durch ngen.exe, dann hast du deine nativen Programme.

Java und .net haben noch viel mehr Vorteile als nur die Portabilität. Außerdem bezieht sich Portabilität nicht nur auf die Rechnerarchitektur, sondern auch auf das Betriebssystem. Und so auf Windows festgenagelt wie du anscheinend glaubst, ist .net auch nicht mehr. System.Windows.Forms war schon vom Design her im Grunde Windows-only, richtig. Der Nachfolger WPF ist es nicht. Welche Bereiche von .net sind sonst noch vom Design her Windows-only?

Falls du mich jetzt für einen .net-Fanboy hältst: Ich entwickle seit über 10 Jahren Software, beschäftige mich seit ca. 6 Jahren mit .net, habe .net bisher aber nicht ernsthaft eingesetzt. Warum? Ich finde .net prinzipiell gut, finde aber, dass es Bereiche gibt, für die es ungeeignet ist (und in denen bewege ich mich meistens). Ferner stören mich z. B. das Hickhack um die GUI-Schnittstelle (Windows Forms wurde nach kurzer Zeit durch WPF abgelöst, wie lange wird nun WPF leben?), die bei WPF fehlende bzw. gerade erst kommende Hardwarebeschleunigung sowie die vor allem JIT-Compiler-bedingten langen Ladezeiten und der relativ hohe Speicherbedarf.

Auch ich pflege nachzudenken, bevor ich schreibe.

TiKu wrote:Welche Bereiche von .net sind sonst noch vom Design her Windows-only?

Eben gerade keine. Das ist ja der Haken. Nenne mir eine offizielle .NET Runtime für nicht-Microsoft-Systeme. Wenn man ohnehin vor hat, nur ein System zu unterstützen ist eine derartige Abstraktion einfach suboptimal und kontraproduktiv.

TiKu wrote:sowie die vor allem JIT-Compiler-bedingten langen Ladezeiten und der relativ hohe Speicherbedarf.

Und das ist der Knackpunkt. Muss ein 10 Jahre jüngeres Programm ohne nennenswerten Funktionszuwachs 10 mal so viele Resourcen verbrauchen? Müsste Vista anstelle der 8MB von Win98 satte 224MB RAM brauchen? Nein!
.NET in der Art wie wir es kennen ist eine Fehlkonstruktion. Sinnvoll wäre es gewesen, einen Zwischencode zu erzeugen (wie es .NET bekanntlich tut; daran ist nichts auszusetzen) und ihn z.B. vom Windows Install System kompilieren zu lassen, und zwar standardmäßig. Voila: Völlige Plattformunabhängigkeit ohne Resourcen- und/oder Geschwindigkeitseinbußen. Ein zweites Java jedoch braucht niemand.
Fazit: Was Windows-Programmierung angeht bleibe ich wohl bei C + WinAPI. Es gibt nämlich nichts, was ich mehr hasse, als resourcenfressende überflüssige Kapselungen.
(Ich denke, diesbezüglich können wir uns beide auf die geltende Meinungsfreiheit berufen.)

gyROS wrote:

TiKu wrote:Welche Bereiche von .net sind sonst noch vom Design her Windows-only?

Eben gerade keine. Das ist ja der Haken. Nenne mir eine offizielle .NET Runtime für nicht-Microsoft-Systeme.

Mono. Ist zwar nicht von Microsoft, aber da steckt Novell dahinter, die mit Microsoft zusammenarbeiten.

gyROS wrote:Wenn man ohnehin vor hat, nur ein System zu unterstützen ist eine derartige Abstraktion einfach suboptimal und kontraproduktiv.

Nö, auch innerhalb der Windows-Welt hat die Abstraktion Vorteile. Zwischen Windows 2000, XP und Vista gibt es bspw. zum Teil erhebliche Unterschiede, um die man sich mit einer Abstraktionsschicht keinen Kopf mehr machen muss. Bzw. werden bestimmte Dinge deutlich einfacher als wenn man direkt mit dem Win32-API arbeitet.

gyROS wrote:

TiKu wrote:sowie die vor allem JIT-Compiler-bedingten langen Ladezeiten und der relativ hohe Speicherbedarf.

Und das ist der Knackpunkt. Muss ein 10 Jahre jüngeres Programm ohne nennenswerten Funktionszuwachs 10 mal so viele Resourcen verbrauchen? Müsste Vista anstelle der 8MB von Win98 satte 224MB RAM brauchen? Nein!

Zum Teil stimme ich dir hier zu, zum Teil ist es aber auch Unsinn. Den Funktionszuwachs gibt es nämlich durchaus: Rechteverwaltung, Unicode, Accessibility usw. Beim Betriebssystem sollte ja eh klar sein, dass ein Vergleich Win98 vs. Vista lächerlich ist.
Dazu kommt, dass man heute einfach auch mehr RAM zur Verfügung hat. Warum sollte man den nicht auch nutzen? Klar, natürlich nicht verschwenderisch, aber mitunter lässt sich auf Kosten des RAM-Bedarfs auch die Geschwindigkeit steigern.

gyROS wrote:.NET in der Art wie wir es kennen ist eine Fehlkonstruktion. Sinnvoll wäre es gewesen, einen Zwischencode zu erzeugen (wie es .NET bekanntlich tut; daran ist nichts auszusetzen) und ihn z.B. vom Windows Install System kompilieren zu lassen, und zwar standardmäßig.

Der Entwickler braucht dem MSI nur zu sagen, dass er das tun soll. Und als Anwender kann man jederzeit ngen.exe nutzen um .net-Assemblies dauerhaft in nativen Code zu übersetzen.

gyROS, mal im ernst. Wieviel Ahnung von dem was du da schreibst hast du wirklich? Halbwissen gepaart mit Hörensagen trifft wohl den Nagel auf den Kopf. Ich empfehle auf jeden Fall mal deine Signatur selbst ernst zu nehmen.

Ein Programm, dass ohnehin in 99% der Fälle auf ein und derselben Architektur ausgeführt werden wird, soll gefälligst auch für diese kompiliert sein.

Das ist >immer< der Fall. Du solltest dich mal ueber JIT-Compilierung im .NET Konzept informieren >bevor< du so etwas schreibst.

(Wer z.B. würde freiwillig außerhalb des Internets ausschließlich Java-Programme benutzen? Java wirbt dabei noch damit, portabel zu sein, .NET ist es offiziell nicht einmal.

Java ist eine andere Welt. Entscheidest du immer fuer oder gegen eine Technologie anhand dessen was dafuer beworben ist?!

.NET in der Art wie wir es kennen ist eine Fehlkonstruktion. Sinnvoll wäre es gewesen, einen Zwischencode zu erzeugen (wie es .NET bekanntlich tut; daran ist nichts auszusetzen) und ihn z.B. vom Windows Install System kompilieren zu lassen, und zwar standardmäßig. Voila: Völlige Plattformunabhängigkeit ohne Resourcen- und/oder Geschwindigkeitseinbußen. Ein zweites Java jedoch braucht niemand.

An dieser Stelle breiten sich in meinem ganzen Koerper schon Schmerzen aus ob deiner Mutmassungen. JAVA != .NET. Bitte bitte bitte informiere dich nochmal. Was du forderst ist >exakt< das was heute schon Stand der Technik ist.

Eben gerade keine. Das ist ja der Haken. Nenne mir eine offizielle .NET Runtime für nicht-Microsoft-Systeme. Wenn man ohnehin vor hat, nur ein System zu unterstützen ist eine derartige Abstraktion einfach suboptimal und kontraproduktiv.

Es gibt eine offizielle "offene" Implementierung, die leider einen etwas aelteren Stand hat und soweit ich weiss fuer BSD-Systeme geschrieben ist. Bei nicht-MS OSes ist weiters .NET fuer Symbian anzufuehren, bei Architekturen eben genanntes und weitere Compact Framework Versionen.

Fazit: Was Windows-Programmierung angeht bleibe ich wohl bei C + WinAPI. Es gibt nämlich nichts, was ich mehr hasse, als resourcenfressende überflüssige Kapselungen.
(Ich denke, diesbezüglich können wir uns beide auf die geltende Meinungsfreiheit berufen

Das ist dir absolut selbst ueberlassen. Es ist sicherlich auch besser dass du dabei bleibst bis du dich umfassend weitergebildet hast.

Noch ein Vermerk zur ngen.exe. Die macht im Endeffekt nur das was die CLR beim ersten Applikationsstart sowieso gemacht haette.

Vielen Dank für's intensive Zerpflücken.

Sivar wrote:Wieviel Ahnung von dem was du da schreibst hast du wirklich?

Zugegebenermaßen weniger als von Java (privat benutze ich beides nur, wenn zwingend erforderlich), aber versuch doch einmal in .NET die Felder einer Datenstruktur geschlossen aus einer Datei zu lesen.

Sivar wrote:Noch ein Vermerk zur ngen.exe. Die macht im Endeffekt nur das was die CLR beim ersten Applikationsstart sowieso gemacht haette.

Meine Vorzüge würden beinhalten, ausschließlich einen statischen Kompilierer zu verwenden und die komplette Runtime dem RAM zuliebe über Bord zu werfen.

"Das ist >immer< der Fall. [...]" - Ja, wenn aber ein Programm erst beim Programmstart kompiliert wird (auch wenn das Binary gepuffert wird) fallen langwierige Optimierungen weg.
Durch die API-Differenz werden zudem entweder zusätzliche DLLs gebraucht (=Resourcenverbrauch) oder das Programm muss sämtliche WinAPI-Kapselungen selbst auflösen (=Resourcenverbrauch).

TiKu wrote:Beim Betriebssystem sollte ja eh klar sein, dass ein Vergleich Win98 vs. Vista lächerlich ist.

Wie erklärst du dir, dass Win 2000 nur 12 und Win 2003 nur 32 MB brauchten?

Zurück zum Thread-Thema:

Den anderen Foren ist zu entnehmen, dass auf das kommende 0.3.9 wahrscheinlich Versionen wie 0.3.10, 0.3.11 etc. folgen werden. Trotzdem bleibt zu hoffen, dass mit 0.4.0, wann immer es kommt, endlich der alte Explorer rausfliegt. Zudem hoffe ich auf bessere Netzwerkkartenunterstützung (insbesondere RTL8139) und stabile Soundunterstützung. Wenn wir Glück haben, wird 0.4.0 dann immer noch mit Pentium 1 und 40 MB RAM laufen.