Wenn die Prozessorarchitektur sich ändert, wie reagiert man da als Windowsnutzer? Unter Linux wird das Package ja einfach neu compiliert.
Um die x86 Architektur zu emulieren hat ein Arm sicher auch nicht genug Leistung. Ist das am Ende kein bischen kompatibel?
Das ist dann Aufgabe des Herstellers der Software, das entsprechend neu zu kompilieren.
Könnte mir vorstellen, dass M$ nen Emu dazupackt - muss aber aus marketingtechnischen Gründen nicht das beste sein, weil ja die Performance schon recht grottig sein dürfte, wie du bereits erwähnt hast…
war das .net framework nicht als so eine art bytecode-sache ähnlich java?
Das Problem ist, dass das meiste, was ich an Software verwende, garkeinen Hersteller hat. Eher Opensource (im besseren Fall) oder es wurde von irgendwem irgendwann compiliert.
Das ist aber wohl eher ein psychologisches Problem. Genau betrachtet will ich die meisten dieser Programme auch garnicht auf einem Gerät nutzen, dass nur mit einem ARM betrieben wird und etwas wie den IM, das Mailprogramm usw. wird schon jemand bereitstellen.
Ich wäre aber dafür, dass Microsoft Packages entwickelt, die dann jeweils auf dem System compiliert werden, wenn man sich nicht mehr darauf verlassen kann, dass es sich um x86 Systeme handelt.
Nun soweit ich es sehe wird das binary schlicht und ergreifend nicht funktionieren. Sprich es braucht entsprechende Software für Windows 8 auf ARM.
OK, Bytecode könnte helfen. Mit Javaapplikationen habe ich bis jetzt unter Windows aber nicht so sehr gute Erfahrungen gemacht. In Homepages eingebettet laufen sie gut, aber sobald sie etwas wichtiges erledigen sollen, hängen sie sehr oft.
Ich würd mich da schon freuen, wenn der code direkt laufen würde. Das wäre außerdem noch ein klein wenig performanter.
Kompatibilitätsproblem schrieb:
--------------------------------------------------------------------------------
> Ich wäre aber dafür, dass Microsoft Packages entwickelt, die dann jeweils
> auf dem System compiliert werden, wenn man sich nicht mehr darauf verlassen
> kann, dass es sich um x86 Systeme handelt.
Du meinst So was die damals die Apple Universal Binaries?
http://de.wikipedia.org/wiki/Universal_Binaries
Bedeutet für den Hersteller nen erheblichen Aufwand ohne die Garantie das die ARM-Plattform mit Windows 8 zum Erfolg wird.
Schön wäre das sicher - nur - ohne damit trollen zu wollen: wieviel Prozent Anteil am Windowsmarkt hat OS-Software? Die breite Masse an Softwareherstellern wird wohl einfach dazu gezwungen sein, neu zu kompilieren…
Vorerst gibts also sicher einfach nur ne .axe statt .exe für natives Zeugs und natürlich ne ARM-.NET-VM ;)
und wenn alles nichts hilft, kann man immer noch einen emulator alla rosetta einsetzen.
Die Universal Binaries kannte ich bis jetzt nicht. Von Fat Binary hatte ich schon gehört, das Problem ist da vielleicht, dass die für kleine Geräte auch zu fett werden könnten. Ich habe eher direkt an etwas gedacht, so wie es unter Linux funktioniert. Vielleicht etwas einfacher, da man sowas sicher auf MSVC++ aufbauen könnte und sich dann nicht extra mit dem Lexer und Parser usw. beschäftigen muss. Am Ende sollte dann eine Exe mit ein paar DLL Dateien in einem Ordner liegen, den man so verwenden kann. Das wäre für kleine Programme wie InstandMessenger sicher nicht schlecht. Wobei gerade da vielleicht auch eine Universal Binarie garnicht so groß wäre und nüchtern Betrachtet ist bei größeren Applikationen das Problem, dass man dadurch den Code mitveröffentlichen würde. Naja, mal sehen, was kommt.
yesitsme schrieb:
--------------------------------------------------------------------------------
> war das .net framework nicht als so eine art bytecode-sache ähnlich java?
Richtig. Es wird einfach ein .NET Framework für ARM geben und fertig. .NET-Entwickler müssen am wenigsten schwitzen. ;)
Kompatibilitätsproblem schrieb:
--------------------------------------------------------------------------------
> Ich wäre aber dafür, dass Microsoft Packages entwickelt, die dann jeweils
> auf dem System compiliert werden, wenn man sich nicht mehr darauf verlassen
> kann, dass es sich um x86 Systeme handelt.
Nennt sich .NET und wird immer erst vor dem Start kompiliert! :P
Kompatibilitätsproblem schrieb:
--------------------------------------------------------------------------------
> Die Universal Binaries kannte ich bis jetzt nicht. Von Fat Binary hatte ich
> schon gehört, das Problem ist da vielleicht, dass die für kleine Geräte
> auch zu fett werden könnten.
Das Hinzufügen von Executables in anderen Prozessorarchitekturen macht die Programmpakete nicht viel größer. Am meisten Speicherplatz belegen i.d.R. Grafiken oder Daten, die für alle Prozessorarchitekuren identisch sind.
Noch ein Vorteil der Universal Binaries: Das Programmpaket kann speziell optimierte Executables für PPC G4, G5, i386, AM64 und z.B. Atom oder Phenom 2 enthalten. Es wird immer automatisch das passendste verwendet.
Ich habe eher direkt an etwas gedacht, so wie
> es unter Linux funktioniert. Vielleicht etwas einfacher, da man sowas
> sicher auf MSVC++ aufbauen könnte und sich dann nicht extra mit dem Lexer
> und Parser usw. beschäftigen muss. Am Ende sollte dann eine Exe mit ein
> paar DLL Dateien in einem Ordner liegen, den man so verwenden kann.
??? Du hast noch nicht viel mit Linux gemacht, stimmt's? Ich behaupte mal dass es unter Linux einfacher ist ein Programm aus em Quellcode zu kompilieren als unter Windows. Mit Lex und Yacc braucht sich da auch keiner beschäftigen (es sei denn du hast Quellcode in einer unbekannten Programmiersprache und baust dir gerade den passenden Compiler dafür ;-))
Im Regelfall installiert man unter Linux wie bei jedem anderen Betriebssystem auch aber bereits fertig übersetzte Programme.
> wäre für kleine Programme wie InstandMessenger sicher nicht schlecht. Wobei
> gerade da vielleicht auch eine Universal Binarie garnicht so groß wäre und
> nüchtern Betrachtet ist bei größeren Applikationen das Problem, dass man
> dadurch den Code mitveröffentlichen würde. Naja, mal sehen, was kommt.
Bei Universal Binaries ist mitnichten der Quellcode dabei. Und auch bei größeren Projekten ist es kein Problem den Quellcode zu veröffentlichen. Das Kompilieren dauert halt länger.
Die ARM-Architektur ist ja nicht umsonst soviel sparsamer:
Im Gegensatz zu den x86er Prozessoren fehlen da ziemlich viele Befehlssätze/Rechneinheiten.
Interessant für die Kompatibilität wären an der Stelle vielleicht optionale Co-Prozessoren, die nur bei Bedarf gestartet werden, falls sich so etwas realisieren lässt, aber ich glaube nicht wirklich daran.
//----------Signatur----------!
Die Deutsche Rechtschreibung ist Freeware, sprich, du kannst sie kostenlos nutzen.
Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Kompatibilitätsproblem schrieb:
--------------------------------------------------------------------------------
> Wenn die Prozessorarchitektur sich ändert, wie reagiert man da als
> Windowsnutzer?
Der erfahrene Anwender wird MS dafür verteufeln, dass die vor IIRC ca. 10 Jahren angekündigte Umstellung des XP-Nachfolgers (also Vista) komplett auf .NET nicht stattgefunden hat. Hätte MS das nämlich durchgedrückt, würde die Software nämlich ganz einfach laufen, ohne dass man noch was anpassen muss. Aber naja, hatte MS auch mal angekündigt (IIRC so um 2003 oder 2004), dass der XP-Nachfolger auf 5 CPU-Architekturen läuft... stattdessen wurde mittlerweile die IA64-Version eingestellt und lediglich die x86-64-Version zusätzlich zur x86-32-Version weitergeführt...
ARM war damals schon als eine der 5 Architekturen gehandelt worden. Mit der Ankündigung, eigene CPUs auf PowerPC-Basis für die Xbox360 herzustellen, hatte man auch gemunkelt, dass PPC die vierte sein wird. Und als fünfte SPARC oder so für Server.
Geworden ist bis zu dieser ARM-Ankündigung aber nichts. So viel zu Microsofts Ankündigungen....
> Unter Linux wird das Package ja einfach neu compiliert.
Und wieso sollte das bei Win8 nicht auch so sein?
Microsoft wird jetzt nicht die Probleme haben, in Visual Studio eine "Als ARM-Anwendung kompilieren"-Option einzubauen. Müssen halt die jeweiligen Entwickler selbst machen, statt dass ein Linux-Distributor das zentral macht, aber sonst?
FULLACK.
Es wird halt vieles an Tools und Programmen geben, die mit VB / C++ erstellt wurden und mangels Wartung / Compiler (VB) nicht auf der ARM Platform zur Verfügung stehen.
Seitan-Sushi-Fan schrieb:
--------------------------------------------------------------------------------
> Microsoft wird jetzt nicht die Probleme haben, in Visual Studio eine "Als
> ARM-Anwendung kompilieren"-Option einzubauen.
Das gilt aber nur für die paar Entwickler, die noch nativ mit C++ entwickeln.
Kompatibilitätsproblem schrieb:
--------------------------------------------------------------------------------
> Wenn die Prozessorarchitektur sich ändert, wie reagiert man da als
> Windowsnutzer? Unter Linux wird das Package ja einfach neu compiliert.
> Um die x86 Architektur zu emulieren hat ein Arm sicher auch nicht genug
> Leistung. Ist das am Ende kein bischen kompatibel?
Schaun wir doch mal rüber zum Ökosystem des halbverfaulten Fallobstes. Da wurde bereits zweimal die Architektur über den Haufen geworfen. Wie wurde denn das dort gelöst?
Zum zweiten schaun wir uns mal bei WindowsNT für Alpha um. Wie hat DEC das damals gelöst?
Und zuguterletzt, ab in die Gegenwart, schaun wir rüber zu Wine und VirtualBox.
Fazit über alles: Emulation ist möglich, aber meist zu langsam. On the fly compiler mit Cache haben Potential, die üblichen Applikationen bis auf erträgliche Geschwindigkeit zu beschleunigen und wenn man dann die Funktionsaufrufe abfängt und native ausführt tendiert das ganze richtung brauchbar.
Vermutlich wird aber nichts davon passieren. MS hat mit Phone7 vorgemacht wohin die Reise geht. Der Kunde darf wohl "für wenig Geld" eine von MS crosscompilte App kaufen.
dergenervte schrieb:
--------
> Das gilt aber nur für die paar Entwickler, die noch nativ mit C++
> entwickeln.
Also fast alle, inkl. Microsoft selbst?
MS hat die mit Vista ausgelieferten Anwendungen sind auf .NET umgestellt, weil MS es selbst nicht hingekriegt hat.
Wäre MS Office eine .NET-Anwendung mit komplett vom GUI getrennten Kern, wäre eine Touch-Variante ein Leichtes für MS, die Mac-Version würde zur Win-Variante im Kern identisch sein und nur ein eigenes GUI haben usw.
dergenervte schrieb:
--------------------------------------------------------------------------------
> yesitsme schrieb:
> ---------------------------------------------------------------------------
> -----
> > war das .net framework nicht als so eine art bytecode-sache ähnlich
> java?
>
> Richtig. Es wird einfach ein .NET Framework für ARM geben und fertig.
> .NET-Entwickler müssen am wenigsten schwitzen. ;)
meinst du so ein ding, das es für symbian 60 + windows phone 7 gibt?
Kommentare: 373 | letzter Beitrag 21:16 Uhr
Kommentare: 216 | letzter Beitrag 15:00 Uhr
Kommentare: 195 | letzter Beitrag 21:23 Uhr
Kommentare: 174 | letzter Beitrag 21:13 Uhr
Kommentare: 161 | letzter Beitrag 21:27 Uhr
E-Mail an news@golem.de
Open Source muss sich als Konzept nicht mehr behaupten, sagt Johannes Loxen auf dem Linuxtag 2012. Stattdessen müssen sich OSS-Projekte jetzt den üblichen Marktmechanismen stellen - und damit rechnen, dass proprietäre Software für Kunden manchmal die bessere Lösung ist.
Linux Mint 13 alias "Maya" bietet Nutzern zwei alternative Desktops zur Auswahl an, die den Machern zufolge zu den besten derzeit verfügbaren Desktops zählen und perfekt in Linux Mint integriert sind.
Der Internet Explorer 10 könnte unter der neuen Metro-Oberfläche von Windows 8 Adobe Flash doch unterstützen, obwohl die Metro-Version des IE keine Plugins unterstützen wird.
Eine neue Fabrik von Foxconn und Sharp in China soll hochauflösende Displays für Smartphones und Tablets bauen. Der Kunde ist Apple, er ist aber nicht der einzige.
Ein Schuss, die Tischlampe ist aus und der Lampenschirm hängt schief. Noch ein Schuss und die interaktive Lampe von Bitplay leuchtet wieder.
Fälscher infiltrieren die US-Streitkräfte: In mehr als 1800 Fällen hat ein Komitee des Washingtoner Senats gefälschte Elektronikteile in High-Tech-Waffen entdeckt. Mehr als eine Million Komponenten sollen auf Umwegen in die Lieferkette der Rüstungsindustrie gelangt sein. Die meisten der Ramsch-Teile stammen aus China.