Mit dem Config-Setting RTI_Mode kann angegeben werden, ob Laufzeitinformationen (zur Zeit immer Ressourcen-Dlls) über „VirtualAddressMapping“ (RTI_Mode = 0) oder als „PortableExecutable“ (RTI_Mode = 1) geladen werden. Empfohlene Einstellung ist zur Zeit RTI_Mode=1 (ab 9.01 Default).
RTI_Mode 0 entspricht dem Verhalten der TAA bis Rel. 8.15: Die Ressourcen werden in den virtuellen Adressraum geladen und können dort direkt über ihre Adresse angesprochen werden. Das heißt aber auch, dass immer so viel Adressraum verwendet wird, wie die Ressourcen-DLL groß ist. Gerade in Prozessen mit unterschiedlichen Versionen bestimmter Anwendungen kann so der Adressraum sehr schnell erschöpft sein. Da die Ressourcen-DLLs immer als 32-Bit DLL erstellt werden, steht dieser RTI_Mode für 64-Bit Anwendungen nicht zur Verfügung. Sollte eine 64-Bit Anwendung Ressourcen-DLLs brauchen, so wird im Falle von RTI_Mode 0 in einem solchen Prozess automatisch auf RTI_Mode 1 gewechselt.
Bei RTI_Mode 1 werden die Ressourcen-Dlls nicht in den Adressraum geladen, sondern wie eine Art Datenbank benutzt. Die Ressourcenladeroutinen suchen in der Dll die jeweils benutzte Ressource, und nur diese wird geladen und belegt Speicher. Der hier gelegte Speicher ist ein anderer als der bei RTI_Mode 0 belegte Speicher. Insgesamt wird weniger Speicher verbraucht.
Folgende weitere Varianten sind vorgesehen, aber noch nicht oder nicht vollständig implementiert und noch nicht freigeschaltet:
RTI_Mode 2: Ist vorgesehen für das Lagern von Ressourcen in OPC (Open Package Convention) Dateien.
RTI_Mode 3: Ist vorgesehen für das Lagern von Ressourcen in einer SQL-Express Datenbank.
RTI_Mode 4: Ist vorgesehen für das Lagern von Ressourcen in statischen Klassen einer C++-Assembly, wo sie zur Laufzeit dynamisch angesprochen werden können.
RTI_Mode 5: Ressourcen werden in Verzeichnissen/Dateien gespeichert.
Bei RTI_Mode=1 gibt es die Möglichkeit, die Ressourcen-DLL nicht im ComponentPath zu öffnen, sondern zuerst ins Temp-Verzeichnis zu kopieren und dann von dort aus zu öffnen. Damit wird erreicht, dass die DLL im ComponentPath nicht gesperrt wird.
Nach der letzten Benutzung wird die Kopie im Temp-Verzeichnis automatisch wieder gelöscht.
Diese Option wird über die binäre Registry-Einstellung RTI_CopyToTemp im Abschnitt Config gesteuert. Der Wert 0 verhindert das Kopieren, bei einem Wert ungleich 0 werden die Ressourcen-DLLs vorher nach Temp kopiert. Die Einstellung kann jederzeit geändert werden und wird für alle ab dem Zeitpunkt neu zu öffnenden Ressourcen-DLLs berücksichtigt. Wenn keine explizite Angabe für RTI_CopyToTemp gemacht wurde, ist das Standardverhalten in der Redist-Fassung, dass nicht kopiert wird, in der non-Redist Fassung wird kopiert.
Dieses Verfahren wird (derzeit) nur für RTI_Mode=1 unterstützt.
In Zukunft wären durchaus ausgefeiltere Mechanismen denkbar, bspw. über ein Cache-Verzeichnis, in dem die DLLs nicht gelöscht werden, sondern immer dann kopiert werden, wenn die DLL im ComponentPath abweicht von der im Cache.