das kann ich dir leider nicht sagen....
Naja, du bist hier natürlich im Forum für die auf CAD optimierte W-Serie. Vielleicht ist es ein spezielles Problem deiner T-Reihe? Auch wenn das eigentlich auch laufen sollte...
Alte Versionen von Visual C++ Distributable: Nein, offensichtlich ersetzen neue Versionen die alten nicht. Ich hab die Erfahrung gemacht, dass dann Software nicht mehr läuft, die das alte benötigt.
.NET-Framework: Dafür muss man etwas tiefer in Programmiersprachen einsteigen. Ich probiers mal möglichst einfach zu erklären: Normalerweise ist es so, dass man Anwendungen programmiert und dann in Maschinensprache kompiliert. Beim Kompilieren werden aber alle Eigenschaften des Prozessors und sogar des Betriebssystems mit einbezogen. Eine kompilierte Anwendung läuft daher ausschließlich unter einer Prozessorarchitektur (z.B. nur auf x86 (32bit) und evtl. noch auf x64 Systemen im Kompatibilitätsmodus) und mit einem bestimmten Betriebssystem (z.B. Windows). Das lässt sich dann also nativ direkt auf der Hardware ausführen und man braucht keine Hilfsmittel, man kann "die .exe einfach starten". Will man es auf einen anderen Prozessor haben (Itanium, x64, ARM, ...), muss man es neu kompilieren. Für ein anderes Betriebssystem genau so. Abhilfe schafft es, wenn man den Quellcode nicht in Maschinensprache übersetzt, sondern erst bei der Ausführung auf die aktuell vorhandene "Ausstattung" anpasst. Das nennt man dann "Interpreter" (anstatt "Compiler"), zur Ausführung muss also ein Interpreter gestartet werden, der den Quellcode liest. Das Problem ist: Das ist verdammt lahm. Außerdem legt man als Programmierer damit all seinen Quellcode offen. Das ist also auch doof. Mit Just-in-Time-Compilern kann man das noch etwas umgehen. Aber es bleibt langsamer und der Quellcode liegt offen. Ein Optimum aus beidem ist es also, wenn man alles in eine Art Pseudo-Maschinensprache übersetzt/compiliert. Das muss noch so universell sein, dass es noch keine speziellen Eigenarten der Hard- und Software anspricht, so dass es auf verschiedenen Hardwarekomponenten und verschiedenen Betriebssystemen lauffähig ist, sollte aber natürlich schon möglichst stark kompiliert sein, damit nicht die Langsamkeit der Interpreter hervortritt. Genau genommen wird ein sogenannter "Bytecode" generiert, der nicht für einen realen Prozessor und ein reales Betriebssystem ist, sondern der quasi für eine virtuelle Maschine kompiliert ist. Zur Ausführung muss dann eine virtuelle Maschine gestartet bzw. zwischengeschaltet werden, die diesen Bytecode zur Laufzeit auf die Hardware anpasst bzw. "übersetzt". Da der Großteil der "Übersetzung" in Maschinensprache schon geschehen ist und nur das letzte bisschen angepasst wird, ist das relativ schnell, aber eben trotzdem universell. Man benötigt aber eben immer diese Art virtuelle Maschine zum Ausführen. Und genau dies ist das .NET-Framework, das ist die virtuelle Maschine. Bei Java läuft das übrigens genau so, deswegen muss man ja auch Java installieren, um Java-Anwendungen ausführen zu können.
Beispiele übrigens: kompiliert wird alles in C und C++ geschriebene, die meisten Spiele sind gute Beispiele dafür. Lauffähig nur unter Windows und nur unter 32bit (wobei die 64bit-Systeme und 64bit Prozessoren in einen 32bit-Modus umschalten, damit das funktioniert). Das sorgt für das letzte bisschen Leistung - die Linux-Freunde oder Besitzer von ARM oder Itanium-Systemen können aber halt meist nichts mit den Dateien anfangen, es sei denn, der Hersteller hat speziell für sie auch noch was kompiliert.
Interpretersprachen sind z.B. Basic, aber auch PHP liegt als Quelltext auf dem Server und wird bei jeder Ausführung durch einen PHP-Interpreter neu interpretiert.
Und typische Bytecode-Sprachen als "Zwischending" sind C# und Java.
