Re: Was uns alles für 0.4 erwartet
Posted: Thu Jan 08, 2009 6:11 pm
Windows NT lief auch mal auf der PowerPC Architektur, die Unterstützung wurde aber eingestellt.
hach ist das leben nich schöönTiKu wrote:Was daran liegt, dass es kein für diese Architektur kompiliertes Windows gibt.Guennie1568 wrote:Na, ich glaube z.B. nicht, das ein MAC (mit Ausnahme des Intel-MACs) mit Windows laufen würde
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.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.
ztztztzt.. es gibt auch leute die Scheuklappen habenPythagoras1 wrote: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.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.
Ich glaub', es hackt!Sivar wrote:wo jedoch zu hoffen bleibt dass .NET oder ähnliche Konzepte in Zukunft auch in der kommerziellen Softwareentwicklung verbreiteter werden.
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:Welche Bereiche von .net sind sonst noch vom Design her Windows-only?
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!TiKu wrote:sowie die vor allem JIT-Compiler-bedingten langen Ladezeiten und der relativ hohe Speicherbedarf.
Mono. Ist zwar nicht von Microsoft, aber da steckt Novell dahinter, die mit Microsoft zusammenarbeiten.gyROS wrote:Eben gerade keine. Das ist ja der Haken. Nenne mir eine offizielle .NET Runtime für nicht-Microsoft-Systeme.TiKu wrote:Welche Bereiche von .net sind sonst noch vom Design her Windows-only?
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:Wenn man ohnehin vor hat, nur ein System zu unterstützen ist eine derartige Abstraktion einfach suboptimal und kontraproduktiv.
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.gyROS wrote: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!TiKu wrote:sowie die vor allem JIT-Compiler-bedingten langen Ladezeiten und der relativ hohe Speicherbedarf.
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 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.
Das ist >immer< der Fall. Du solltest dich mal ueber JIT-Compilierung im .NET Konzept informieren >bevor< du so etwas schreibst.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.
Java ist eine andere Welt. Entscheidest du immer fuer oder gegen eine Technologie anhand dessen was dafuer beworben ist?!(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.
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..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.
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.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.
Das ist dir absolut selbst ueberlassen. Es ist sicherlich auch besser dass du dabei bleibst bis du dich umfassend weitergebildet hast.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
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:Wieviel Ahnung von dem was du da schreibst hast du wirklich?
Meine Vorzüge würden beinhalten, ausschließlich einen statischen Kompilierer zu verwenden und die komplette Runtime dem RAM zuliebe über Bord zu werfen.Sivar wrote:Noch ein Vermerk zur ngen.exe. Die macht im Endeffekt nur das was die CLR beim ersten Applikationsstart sowieso gemacht haette.
Wie erklärst du dir, dass Win 2000 nur 12 und Win 2003 nur 32 MB brauchten?TiKu wrote:Beim Betriebssystem sollte ja eh klar sein, dass ein Vergleich Win98 vs. Vista lächerlich ist.