Nun, es ist eigentlich anders herum.
==> Die Entwicklung der ETS erfolgt unter und für Windows und dort auf .NET. Der Kern der ETS ist mithin in .NET programmiert.
Da nun der Kern der ETS nach Linux zu portieren ist, bietet es sich an - bzw. dürfte die einzige Möglichkeit sein - das dann mit ".NET CORE" zu machen. Ich kann die Entscheidung der KNX Assoc. da hier verstehen.
Die ETS ist im inneren sehr viel komplexer, als sich Anwender das vorstellt. Denn - anders als es der Standard suggerieren möchte - sind die 8000 zertifizierten Produkte nicht gleich, sondern entsprechen dem jeweiligen Stand bei Veröffentlichung. Mithin hat es die eine ETS mit einem oder zwei Dutzend verschiedener Stacks in entsprechenden Variationen zu tun, die sich eben nicht gleich verhalten. Da man die Stacks in den ausgerollten Produkten nicht mehr anpassen kann, muss die ETS das Produkt erkennen und sich darauf anpassen. Es dürften also tausende von Ausnahmen im ETS-Core über die zwei Jahrzehnte hinzugekommen sein, damit auch alles funktioniert.
Die KNX Assoc. geht sogar soweit, die ETS auch kompatibel zu nicht zertifizierten (und fehlerhaften) Produkten wie dem eibd / knxd zu halten. Die ETS baut da quasi um deren Fehler drumherum. Es gibt mittlerweile sogar - wegen dem falschen Routingzähler im eibd - extra neue Bestimmungen für Bereichs- und Linienkoppler, um den dort angerichteten Mist wieder zu heilen.
Bei allem eingedresche auf die KNX Assoc., das möge man auch beachten, dass große Anstrengungen unternommen werden, auch die nicht zertifizierten Community-Stacks und deren Fehler nicht zu tolerieren sondern durch extra bezahlte Anpassungen zu unterstützen.
==> Danke KNX Assoc.!
Diese immerwährende Kompatibilität der ETS zu allem was einen KNX-Audkleber hat ist der KNX Assoc. heilig und das ist auch uneingeschränkt richtig so, weil das ist das größte Asset neben dem Standard. Und das geht ein wenig zu Lasten der Geschwindigkeit und das macht die Portierung auch schwieriger.
lg
Stefan