Was uns alles für 0.4 erwartet
Moderators: frik85, EmuandCo, Dr. Fred
-
- Website Coordinator
- Posts: 261
- Joined: Mon Mar 20, 2006 1:48 am
- Location: Ilmenau, Germany
- Contact:
Re: Was uns alles für 0.4 erwartet
Windows NT lief auch mal auf der PowerPC Architektur, die Unterstützung wurde aber eingestellt.
Re: Was uns alles für 0.4 erwartet
Soweit ich weiß war das aber auch nur NT 4.0, oder?
-
- Posts: 1808
- Joined: Tue Dec 20, 2005 12:55 pm
- Contact:
Re: Was uns alles für 0.4 erwartet
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
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
Re: Was uns alles für 0.4 erwartet
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.
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.
-
- Posts: 15
- Joined: Fri Jan 07, 2005 5:08 pm
- Location: Vienna (Wien)
Re: Was uns alles für 0.4 erwartet
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.
-
- Posts: 1808
- Joined: Tue Dec 20, 2005 12:55 pm
- Contact:
Re: Was uns alles für 0.4 erwartet
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.
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
Re: Was uns alles für 0.4 erwartet
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
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
Re: Was uns alles für 0.4 erwartet
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?
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?
Re: Was uns alles für 0.4 erwartet
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.
Re: Was uns alles für 0.4 erwartet
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.
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.)
Re: Was uns alles für 0.4 erwartet
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.
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.
Re: Was uns alles für 0.4 erwartet
Auch ich pflege nachzudenken, bevor ich schreibe.
.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.)
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.
.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.)
Re: Was uns alles für 0.4 erwartet
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.
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.
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.
Re: Was uns alles für 0.4 erwartet
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.
Noch ein Vermerk zur ngen.exe. Die macht im Endeffekt nur das was die CLR beim ersten Applikationsstart sowieso gemacht haette.
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
Noch ein Vermerk zur ngen.exe. Die macht im Endeffekt nur das was die CLR beim ersten Applikationsstart sowieso gemacht haette.
Re: Was uns alles für 0.4 erwartet
Vielen Dank für's intensive Zerpflücken.
"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).
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.
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.
"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).
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.
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.
Who is online
Users browsing this forum: No registered users and 8 guests