ZitatOriginal geschrieben von frank_aus_wedau
Ich hatte mich immer schon gefragt, warum Software für verschiedene Windows-Versionen nicht (in geeigneten Fällen) dieselbe Programmiersprache nutzt, so dass sie sie unter allen Versionen lauffähig ist, wodurch über die Implementierung passender Schnittstellen bereits in der Vergangenheit Kompatibilitätsprobleme hätten vermieden werden könnten - was nun wohl durch die gemeinsame Runtime-Umgebung realisiert wird.
Du wirfst da ein bisschen was durcheinander. Ich versuche da mal, ein wenig Licht hinein zu bringen.
Fangen wir beim Prozessor an. Es gibt unterschiedliche Prozessoren. Jeder Prozessor hat einen bestimmten Satz an Operationen, die er ausführen kann, und einen unterschiedlichen Aufbau. In Windows-PCs steckt ein Prozessor der x86-Familie drin, die seit 20 Jahren nach demselben Schema aufgebaut sind und über den gleichen Befehlssatz beherrschen. Mit jeder Prozessorgeneration werden diese weiter entwickelt, optimiert und erweitert. Der Grundstock bleibt jedoch derselbe. So kannst du auch heute noch einen modernen Prozessor mit denselben Befehlen wie vor 20 Jahren steuern. Es sind jedoch auch neue hinzu gekommen, die bestimmte Operationen vereinfachen oder beschleunigen.
Ein Programm ist nichts weiter als eine Aneinanderkettung von Befehlen und Speicheroperationen, die der Prozessor ausführt.
Da diese Maschinensprache jedoch sehr umständlich ist, gibt es Programmiersprachen, die das vereinfachen. Der Quellcode eines Programms ist also in einer bestimmten Sprache geschrieben, aber wird am Ende wieder in Maschinencode übersetzt, damit das auf dem Prozessor läuft.
Dabei gibt es zwei Varianten: Entweder übersetzt man den Quellcode einmalig in eine Datei mit Maschinencode, die dann so direkt ausführbar ist. Das nennt man Kompilieren.
Oder man nutzt einen Interpreter, der bei jeder Ausführung des Programms den Quellcode direkt übersetzt.
Ein kompiliertes Programm liegt im fertigen Maschinencode vor und kann sofort ausgeführt werden. Jedoch muss man diesen Maschinencode für jeden Prozessor einzeln erzeugen.
Ein interpretiertes hingegen muss während der Ausführung übersetzt werden. Dabei kann dann jeweils der Interpreter verwendet werden, der den Befehlssatz des jeweiligen Prozessors kennt. Das hat den Vorteil, dass man nicht für jeden Prozessor eine eigene Version des Programms zur Verfügung stellen muss, sondern nur den Quellcode, den Rest erledigt der Interpreter dann zur Laufzeit. Das kostet jedoch Rechenleistung, weshalb diese Programme wenig performant sind.
Natürlich gibt es noch diverse Zwischendinger, also dass ein Programm vorkompiliert ist, so dass der Interpreter dann weniger Leistung benötigt.
Doch leider ist das alles nicht so einfach, denn auch innerhalb der Programmiersprache verwendet man zwangsläufig Befehle und Strukturen, die von der jeweiligen Plattform abhängen, auf der man arbeitet. Das betrifft zum Beispiel die Größe von Variablen, die u.a. davon abhängt, ob man ein 8-, 16-, 32- oder 64-Bit-System verwendet. Ohne jetzt zu sehr ins Detail gehen zu wollen: Diese "Bit"-Angaben besagen, wieviele Daten parallel vom Prozessor verarbeitet bzw. mit dem Speicher ausgetauscht werden kann.
So muss auf einem System mit schmaler Busbreite z.B. eine Rechenoperation mit großen Zahlen in mehrere Einzelschritte aufgespalten werden, da die gesamte Zahl nicht in eine Speicherzelle passt. Musst du dir so vorstellen wie die angezeigten Stellen bei deinem Taschenrechner.
All diese kleinen Unterschiede führen dazu, dass ein Programm, auch wenn es in einer eher allgemeinen Programmiersprache verfasst ist, nicht so ohne weiteres für einen anderen Prozessor kompiliert oder interpretiert werden kann.
Darum gibt es noch eine Möglichkeit: Eine Virtuelle Maschine.
Die bekannteste Variante ist Java. Die Java-VM ist nichts anderes, als ein Simulator eines Prozessors, der immer gleich ist. Das Java-Programm hat also immer dieselbe Umgebung, die Java-VM kümmert sich dann darum, dass dies in die Befehle, Variablen, usw. übersetzt wird, die das jeweilige Gerät kennt. Es ist also auch eine Art Interpreter, nur dass eben hier alles simuliert wird.
Deshalb laufen Java-Programme auch auf einem Windows-PC genauso wie auf einem Mac, sind jedoch auch keine Performance-Wunder.
So. Das wäre erstmal die Prozessor-Seite. Jetzt zum Betriebssystem. Dessen Aufgabe ist es, über standardisierte Schnittstellen einem Programm eine Umgebung zur Verfügung zu stellen, um z.B. ein Dateien von der Festplatte zu lesen, Fenster zu zeichnen oder einen Ton abzuspielen. Das Programm muss nicht wissen, was das für ein Datenträger ist, welcher Monitor angeschlossen ist oder welche Soundkarte im Rechner steckt. Das erledigt alles das System.
Auch hier haben wir jetzt wieder das Problem, dass jedes Betriebssystem natürlich andere Schnittstellen zur Verfügung stellt. Ein Windows-Programm läuft daher nicht unter Linux und auch nicht auf dem Mac, auch wenn in allen drei Rechnern derselbe Prozessor steckt.
Bei Java wird auch das alles so weit standardisiert gekapselt, dass das Programm immer dieselbe Umgebung vorfindet, aber die Java-VM sich eben darum kümmert, dass ein Dateitzugriff bei Windows so, bei MacOS eben so läuft.
Eine solche Generalisierung hat den Vorteil, dass man eben nicht plattformspezifisch programmieren muss, aber den Nachteil, dass man nicht die spezifischen Eigenschaften der jeweiligen Plattform nutzen kann. Man einigt sich innerhalb der Java-VM eben mehr oder weniger auf den kleinsten gemeinsamen Nenner.
Womit wir jetzt zur Windows Runtime kämen. Im weitesten Sinne könnte man diese Technik mit der Java-VM vergleichen. Eine Universal App unter Windows nutzt die Windows Runtime, um den generalisierten Befehlssatz auf dem jeweiligen System nutzen zu können. Aber genau genommen sind es intern letztlich mehrere Programmversionen, die sowohl plattformspezifische als auch universelle Teile enthalten können.
Ich schrieb ja bereits, dass der Kernel des Betriebssystems der gleiche sei. Das ist nicht ganz richtig, denn selbstverständlich haben ARM und x86 unterschiedliche Systemkerne. Sie bieten jedoch zur Anwendungsseite hin dieselben Schnittstellen und verhalten sich auch gleich. So kann eine Anwendung eben sowohl unter ARM, als auch unter x86 auf dieselben Funktionen des Betriebssystems zugreifen.
Unterschiede gibt es dann jedoch wieder bei den höheren Schichten, wie z.B. die Oberfläche oder die Peripheriegeräte.
Warum kann man nun ein herkömmliches Windows-Programm nicht auf Windows-Phone oder Windows RT laufen lassen, wenn es doch zur Anwendungsseite derselbe Kernel ist? Ganz einfach. War gibt es dieselben Basis-Schnittstellen zum Betriebssystem, jedoch sind diese Programme für einen bestimmten Prozessortyp kompiliert – nämlich x86. Und bei Windows Phone sind eben nicht alle Schnittstellen vorhanden, wie auf dem "richtigen" Windows.
Ich hoffe, dass das damit ein bisschen klarer wurde. Also soooo einfach ist das alles nicht. Man hat eben immer die Wahl zwischen hoch performanter Software, die dann plattformspezifisch sein muss, oder eine universelle, die dann in einer Zwischenschicht an Leistung einbüßt.
ZitatFür mich ist es ohnehin ein Armutszeugnis, dass mehrere Outlook-Installationen nicht schon entwicklerseitig miteinander kommunizieren können.
Selbstverständlich kann Outlook das – über den Exchange-Server. Denn genau dafür wurde Outlook entwickelt und ist in dieser Form weltweit millionenfach im Einsatz. Und wenn mir diese Bemerkung erlaubt sei: Erst mit einem Exchange-Server kann man mit Outlook richtig gut arbeiten. Es funktioniert bestens, alle Geräte sind stets synchron. Egal, ob ich einen Kalendereintrag im Handy setze oder an einem meiner PCs – Sekunden später sind die anderen Clients auf dem aktuellen Stand. So muss es sein.
ZitatIn MS OneNote macht Microsoft vor, wie eine perfekte Koexistenz mehrerer Installationen zu organisieren ist. OneNote ist für mich zwischenzeitlich der Dreh-und Angelpunkt meiner Arbeit am privaten PC. Nur Outlook-Installationen auf Clients machen bei der Synchronisation nicht mit.
OneNote erzeugt Dateien, genauso wie Word, Excel, usw. Da wird nichts "synchronisiert".
Für die Synchronisierung ist ein Sharepoint Server notwendig – oder eben neuerdings die Cloud.
