Hi Leute,

Ich arbeite in einem Unternehmen wo das Hauptprodukt eine Windows Software im medizinischen Bereich ist. Als vertrieblicher Außendienstmitarbeiter werde ich immer wieder mit der Situation konfrontiert, dass potentielle Kunden Macs nutzen. Meistens sind das individuelle Ärzte. In Krankenhausstrukturen herrscht nach wie vor Windows. Auf dieser Basis wurde die strategische Entscheidung zur Entwicklung unserer Software auf der Windows x86 Plattform vor über 20 Jahren getroffen.

Nun kann man sicherlich Parallels Desktop benutzen. Mit Einzug des M1 Chips sehe ich da aber noch ein Hindernis. Hier müsste Microsoft eine ausgereifte ARM Windows Version mit vernünftiger "Rosetta 2" Alternative bereitstellen um existierende x86 SW vernünftig laufen zu lassen.

Da die M-Chips sehr leistungsfähig sind, finde ich es super interessant welchen Vorteil es haben könnte unsere SW auf diese Technologie zu portieren. Sprich, für Mac zu programmieren.

Ich bin allerdings kein Entwickler und nach meinem Kenntnisstand hat keines unserer Entwickler im Hause Berührungspunkte mit MacOS Entwicklung. Freiwillig bemüht sich daher keiner um der Sache nachzugehen. Daher wende ich mich ganz naiv an dieses Forum... Ich würde nämlich einfach gerne in Erfahrung bringen welchen tatsächlichen Aufwand es mit sich bringen könnte.

Wie kompliziert war es denn bisher, x86 SW von Windows (C++ bzw. C#) auf x86 MacOS (Intel) zu portieren? Wieviel Aufwand kann das beinhalten? <- Notfalls um die SW unter Rosetta 2 auf Arm-Macs laufen zu lassen.

Ist die direkte Portierung zur ARM MacOS Plattform jetzt schwieriger als zuvor zu Intel MacOS?

Gibt es Entwicklerprogramme/Weiterbildungen und Plattformen die es Windows Entwicklern erleichtert und relativ schnell ermöglicht existierende x86 Windows Software auf MacOS zu portieren?

Weitere Infos: Für unsere klassische SW nutzen wir .net Framework und C++. Dazu kommen Dritthersteller Bibliotheken die benutzt werden. Unsere aktuellere SW ist in C# und C++ programmiert und nutzt Microsoft SQL 2012, 2013, 2015/17.

Von Grund auf neu programmieren ist aus Ressourcensicht leider nicht möglich.

Ich hoffe ich werde nicht gleich für meine vielleicht naiven Fragen erschlagen.

Vielen Dank im Voraus!

Ben

Hallo,

So eine Software kann man nicht "mal eben" portieren. Selbst wenn das möglich wäre bräuchte man immer noch Leute, die wissen, wie die Mac-Platform funktioniert und die Portierung laufend betreuen. Sofern also in deiner Chefetage keiner Bedarf sieht und bereit ist das Portemonnaie aufzumachen, wird das nichts. Da ihr vermutlich keine hochperformanten Routinen in eurem Code habt, die architekturspezifisch optimiert werden müssten, ist die CPU-Architektur eher unerheblich für den Portierungsaufwand. Schwieriger wird es mit Windows-spezifischen Abhängigkeiten, für die es auf dem Mac bestenfalls Drittanbieterlösungen, im schlimmsten Fall nichts gibt.

Wenn euer Markt wirklich mehr und mehr auf Macs wechselt, müsst ihr aber früher oder später tätig werden. Sonst kommt irgendwann jemand mit einer webbasierten Lösung die überall läuft (sogar auf iPads) (am besten noch mit Server in der Cloud) und dann wird es eng für euch.

Ansonsten müsst ihr halt darauf hoffen, dass eventuell jemand einen brauchbaren x86 Emulator baut der Windows stabil und performant ausführen kann.

Und noch eins sollte man da gleich bedenken: Um die wahren Vorteile des M1 zu nutzen, sollte man möglichst nativ (also die dafür vorgesehen APIs) programmieren.

Leider geht der Trend immer mehr zu solcher Cross-Plattform-Grütze, heraus kommen dann solche Apps wie Disney+, oder alles was mit z.B. Flutter zusammengeklöppelt ist.

Ergänzend zu dem was ChrisK schon geschrieben hat....

C++ ist relativ einfach von Objective C bzw Swift, den beiden Standard-Programmiersprachen von Apple, aus aufzurufen.

Was du als konvertieren beschreibst ist im einfachsten Sinne ein umsetzen der Windows-GUI nach macOS-GUI. Für solche Aufgaben gibt es schon fertige GUI-Bibliotheken mit denen man dann ein und das selbe Programm für Windows, macOS und Linux compilieren kann.
Als open source Lösung wäre da wxWidgets zu nennen.
Kommerzielle Lösungen ist QT die ausgereifteste Lösung.

Aber Achtung. Auch mit diesen Tools ist es nicht einfach. Damit deine Firma nicht alles neu schreiben muss, ist erst Mal ein Bewerten des C++ / C# Codes notwendig. Wenn jetzt schon eine strikte Trennung von Datenhaltung und Datenanzeige bei der Definition der Klassen und Schnittstellen geachtet wurde, dann muss "nur" der Datenanzeige-Code an das neue GUI-Toolkit angepasst werden. Im anderen Fall muß deine Firma erst mal den Zwischenschritt gehen und für eine saubere Trennung zwischen den beiden ebenen sorgen.
Dieses Prinzip nennt sich Model-View-Controller. Hier gibt es eine sehr gute allgemeine Abhandlung ; . Auch in diesen Artikel wir unter "Widget-Bibliotheken für Desktop-Applikationen" oben genanntes Problem besprochen.

Wie ChrisK schon aufgezeigt hat, gibt es verschiedene zusätzliche Probleme (Web-Lösung etc..), welche schlicht einen Zeitfaktor darstellen. Deswegen kann man (in Mangel an Kenntnis um welches Programm es sich handelt) nur generell empfehlen : Je früher deine Firma seine "Hausaufgaben" macht, desto entspannter kann sie am Markt agieren, desto niedriger sind die "Umstellungskosten".

Ich glaube nicht, dass hier eine pauschale Aussage möglich ist. Theoretisch kannst du mit C# geschriebene Software wenigstens zum Teil über Xamarin auch auf macOS abbilden. Bibliotheken von Drittanbietern - nur wenn diese auch macOS-Versionen haben.
Ich tippe auch mal vorsichtig darauf, dass zu der Zeit niemand an eine saubere Trennung von plattformspezifischem Code und plattformneutralen Code gedacht hat oder auch Entwicklungsmustern wie MVVM gefolgt ist. Was es auch nicht einfacher macht.
Komplett neu schreiben ist vermutlich einfacher, schneller und kostet weniger.
Aber hey, das ist so ein wenig wie Kaffeesatzlesen

Exakt, und man muss sich dann auch Gedanken machen, wie kriege ich dann die gleiche Funktionalität auf der Windows-Seite auch hin, ober muss ich dann doch Abstriche machen...

Bestes Beispiel sind die Adobe-Produkte. Nicht umsonst arbeiten da viele Leute, die sich den Kopf zerbrechen, wie sie sowohl das Windows als auch das macOS Produkt funktional gleich halten.

Nein gibt es nicht ! Apple selbst hat mal vor laaanger Zeit nur einen Porting Guide für Linux herausgegeben und dann nie mehr das Thema angefasst...
Es existiert keine Swift oder Objective C Bibliothek zum nativen Zugriff auf den Datenbank-Server. Es existiert aber ein SwiftODBC-Framework...

Von Seiten der Technik ist ja hier schon einiges geschrieben worden. Beim ersten Durchlesen würde mir vor allem auch "MS SQL" Bauchschmerzen bereiten. Ist eure SW eine Client-Server-Anwendung (wo zunächst nur der Client auf macOS laufen müsste) oder ist MS SQL in die Desktop-Software integriert? Bei zweitem würde ich bei einer Portierung eher schwarz sehen.

Organisatorisch würde ich Dir raten, darauf zu warten, dass Eure Entwicklungs-Abteilung ein neues Major-Release plant (was in vielen Firmen alle paar Jahre mal angegangen wird). Dann würde ich über den Vertrieb und die GL versuchen, Einfluss darauf zu nehmen, dass das nächste Major-Release auch für macOS entwickelt wird. Vielleicht kannst Du schon Zahlen vorlegen, dass Du den Umsatz um x% steigern könntest, weil inzwischen y% der Kunden zum Mac gewechselt sind oder dies vorhaben. Wie die Kollegen oben schon geschrieben haben, ist es möglich für Win und mac zu entwickeln - aber halt nicht über Nacht.

Das ist zwar nicht in jedem Fall möglich, aber viele Lösungen setzen auf ein Frontend im Browser und der Server läuft dann - in Deinem Fall unter Windows - weiter. Könnte man auch als SaaS liefern und erweiterte Kollaborationsmöglichkeiten wären einfacher einzubauen.

Wenn das nicht geht, könnte man mal schauen, ob das unter Wine läuft.
Oder Du stellst einen Windows-Server hin, auf den die Kunden dann mit dem Windows Remote Desktop zugreifen.

Die einzige richtige Antwort ist auch hier: Kommt drauf an.

WOW Danke an alle für die ausführlichen Antworten.

Ich sehe schon, dass es scheinbar nicht so einfach ist.

Thema WEB-Lösung: Da arbeiten wir dran und das ist vermutlich ein, wenn nicht der sinnvollste, Weg. Für unsere klassische "2D" Lösung auch schon gut umgesetzt. Allerdings auch auf lokaler Intel-Windows-Web-Server Basis. Cloud Server wegen Datenschutz maximal für Praxen/Individuelle Ärzte interessant. Kliniken machen da selten mit.
Wir haben aber auch 3D Software zum Betrachten und Bearbeiten von CT Datensätzen und diese ist wesentlich Leistungshungriger. Das Rohmaterial (CT Datensätze) wird in 3D auf Basis einer Engine dargestellt. Hier geht es also nicht um STL Files oder so. Da muss schon dediziert die Leistung des Workstations abgerufen werden. Ich kann mir nicht vorstellen wie man daraus eine gute Weblösung mit einer 3D-Engine ableiten kann. Aber da kenn ich mich nicht aus...

Kommerziell ist nach wie vor Windows innerhalb der Klinikarchitektur King. Da werde ich mit einem Businesscase auf Mac Basis beim Management vermutlich nicht viel erreichen. Es sei denn die Portierung ist jetzt wirklich nicht "so kompliziert". Unsere Firma hat ca. 50-60 Mitarbeiter und ist daher kein riesen Player verglichen mit Adobe etc.
Die ganzen Einflussreichen "key opinion leader", aka Ärzte, nutzen halt alle Macs. Bis jetzt kein Problem weil Boot Camp.
Mit M1 ändert sich aber nun die Situation und da kamen mir die Fragen auf.

Nun, dann werde ich jetzt erst mal die ganzen Infos verdauen.

Vielen Dank

LG
Ben

Mal aus Anwender- bzw. Admin-Sicht: in Praxen finde ich meist "Mac"-Software auf Java-Basis. Da spart der Entwickler aber das Ergebnis ist gruselig. Nur um ein Beispiel zu nennen, in der Windows-Version kann man über die TAPI-Schnittstelle eine Telefonnummer im Programm anklicken und den Anruf starten. TAPI gibt es beim Mac nicht (so auch die lapidare Auskunft des Supports) aber beim Mac müsste man einfach nur einen Link mit callto: (analog zu mailto: ) hinterlegen ... warte ich seit Jahren drauf.
Damit machst du die Kunden nicht glücklich. Wer Software für Mac anbieten will, sollte auch direkt für den Mac programmieren und dessen Fähigkeiten ausschöpfen.

Das gibt es auf dem Mac schon
die SW ist Open Source. somit könnt ihr die auch an eure Bedürfnisse anpassen

Ergänzung: Ich hab‘ grad noch mal nachgeschaut…
Das github-repoitory ist schon seit 7 Jahren tot, aber es ist immer noch sehr gutes Anschauungsmaterial wie man sowas geschickt macht.

Wieso fragst du nicht einfach bei euren Entwicklern nach?
Das ist immer sehr individuell aber mit MS SQL Server sieht es nicht unbedingt einfach aus. Mal abgesehen vom UI Problem.

Das klingt beinahe nach der schlimmstmöglichen Situation. Ich denke, da ist ein echtes Windows, das in der Emulation läuft (oder auf Intel-Macs in Paralells) das Einfachste. Der QEmu ist zwar nicht die schnellste Methode um Windows laufen zu lassen aber für normale Anwendungssoftware ohne zu viel Grafik würde die Leistung sicher reichen.

Für ARM-Windows kompilieren wäre vielleicht ein Kompromiss. Das sollte doch machbar sein oder?

Ich arbeite seit einigen Jahren als freier Mitarbeiter für eine Firma, die schon seit Jahrzehnten eine Software für Windows anbietet und auch eine Mac-Version brauchte. Das haben wir erst sehr getrennt gemacht. Vor kurzem haben wir aber begonnen, einen gemeinsamen Kern für Business-Logik in C#/.Net Core aufzubauen. Da hat sich in letzter Zeit sehr viel getan, was Cross-Platform-Entwicklung angeht. Die UI wird natürlich immer nativ bleiben. Man sollte den Aufwand aber auch nicht unterschätzen, und man braucht auf jeden Fall die Unterstützung der anderen Entwickler und der Geschäftsführung.

Dass in Krankenhäusern Windows vorherrscht würde ich per se jetzt nicht so unterschreiben. Es gibt nicht wenige Linux bzw. Unix basierende PACS-Systeme und auch viele Printserver im medizinischen Bereich laufen auf Linux.

Und auch der Mac ist in dem Bereich kein Exot z.B. ist Osirix ein recht beliebtes Tool in der Radiologie. Ich habe vor einigen Jahren, als Osirix noch keine FDA-Zertifizierung hatte, für ein Unternehmen gearbeitet, die eine zertifizierte Software aus Osirix-basis vertrieb.

Aber ist die Frage da erstmal nicht viel mehr: Wollen eure Kunden einen Wechsel?
Ihr habt natürlich den Vorteil, dass ihr nicht sofort euer gesamtes Softwareangebot portieren müsst, denn ob eine DICOM-Datei von einem Mac an einen Windows oder von Mac zu Mac oder von Windows zu Windows geschickt wird ist ja eigentlich egal. Ihr könntet also mit dem "logischsten" Schritt anfangen … also dem Programm für das eine Portierung den größten Nutzen ergeben würde.
Ich habe leider noch keinen M1 im Radiologieumfeld live erlebt um z.B. sagen zu könne, dass er die "bessere" Bildbetrachtungsstation wäre …

Diese Frage wird dir hier niemand seriös beantworten können. Dazu muss man die Applikationen und idealerweise auch den Code kennen.
Nur mal ganz ganz grob: Wenn eure Software sauber zwischen GUI und "Core" trennt und der "Core" (mir fällt da leider gerade kein passendes Wort ein), sich in ein Mono-Framework giessen lässt, dann kann man recht einfach eine native Mac-App bauen, die dieses Framework einbindet … solch eine saubere Trennung ist aber meistens nur eine Utopie … auch im code-technisch eigentlich sehr sauberen Medizin-Sektor.

Auch die Frage ist zu allgemein, das kommt immer auf die einzelne Software an und wie sauber diese entwickelt wurde.

Die 98%-Antwort lautet nein, das ist kaum mehr Aufwand … beim Rest kann der Aufwand dafür extrem sein (Hardware-nahe Programmierung)

Nicht von Apple, aber es gibt diverse Schulungsunternehmen, die entsprechende Kurse anbieten.
Aber Achtung, einem eingefleischten Windows-Entwickler machst Du nur schwer zum Mac-Entwickler (und umgekehrt!) … das hat weniger mit der Fähigkeit als mit dem Willen zu tun.

Vielen Dank.

Es ist nicht unbedingt die Klinikumgebung bei denen ich speziell den Wechsel zum Mac sehe. Ich sehe allerdings, dass ARM eine große Zukunft hat und ich überlege einfach welche Auswirkungen das auf den Markt haben kann. Wenn Microsoft mit Windows ARM nachzieht, dann wäre es ja vermutlich auch einfach sinnvoller unsere SW auf Windows ARM zu portieren. Dadurch mit Parallels auf Macs nutzbar zu machen und gut ist.
Der Wechsel künftig zur ARM Technologie, egal ob Windows oder Mac, könnte potentiell Vorteile für die Kliniken bringen: Stromverbrauch, Leistung etc.

Unsere SW arbeitet zwar mit den DICOM Bildern von den Radiologien, die Anwender befinden sich allerdings in der Orthopädie oder Traumatologie.

Da mein Fokus die internationale Expandierung ist bin ich teils auf "key opinion leader" angewiesen. Aber die benutzen alle Macs Mit Parallels ging das ja bisher, aber wiegesagt, mit den M1 Chips wird das in Zukunft schwieriger. Esseidenn Microsoft zieht halt mit.

Unsere neuere Software in 3D (Allerdings noch nicht die Cashcow) hat soweit ich weiß eine Core. Unsere klassische SW wurde meines Wissens so vor sich hin programmiert.... Nun, immerhin schon 20+ Jahre alt. Die ursprünglichen Entwickler schon lange nicht mehr an Bord.

Ich werde wohl einfach wieder das Gespräch mit den Entwicklern suchen müssen. Die Wege sind bei uns zum Glück relativ kurz. Aber bei den letzten Versuchen haben die sich halt davor gedrückt. Verständlich, es scheint ja eine recht komplexes Thema zu sein.

Ich hatte einfach die Hoffnung, dass Heutzutage alles etwas einfacher geworden ist.

Als Vertriebsmitarbeiter will ich nur sicherstellen, dass wir es nicht verpassen auf gewisse Züge aufzuspringen. Vor Allem mit Hinblick auf ARM. Muss jetzt ja nicht der M1 sein. Aber Apple hat derzeit nach meinem Kenntnisstand mit ARM einfach die Nase vorn und ich finde es sind einfach unglaublich spannende Zeiten.

Ich denke hiermit ist meine Neugierde vorerst gestillt und ich bedanke mich bei den Zahlreichen Antworten.

Hallo,
Ich arbeite selbst in dem gleichen Sektor, jedoch auf Entwicklerseite. Wenn die Software auch nur im Ansatz so komplex ist wie unsere Software, braucht eine ernsthafte Portierung so lange wie es bräuchte alles komplett neu zu machen. Gut, wir haben den Vorteil, dass die Client-Seite unter Java läuft und überall funktioniert (wobei sie eigentlich von fast allen unter Windows genutzt wird). Aber eine ernsthafte Portierung käme fast einer Neu-Entwicklung gleich.

Kannst aus Spaß ja mal euren Leiter der Entwicklung fragen,

Nur mal als Vergleich. Ich habe mal nur die Datenbankseite erweitert von rein MySQL auf SQL Server und Oracle. Bis das komplett lief ging alleine dafür ein Jahr drauf.

Die Kosten, die eine solche Portierung verschlingen würde, wirst Du mit einzelnen Verkäufen nicht kompensieren können. Und ein Kunde wird niemals das Geld aufbringen wollen das zu machen. Da stellt er sich lieber für den Zweck einen Intel-Mac oder einen PC hin oder wartet bis es Windows-ARM Versionen gibt, dEin dann irgendwann auch unter Apple-Silicon laufen könnten, und sei es nur in Parallels.

Viele Grüße

Es gibt zwar .NET auch für Linux und macOS (bisher jeweils nur für x86-64), aber eben nur ohne GUI. Alternativ kann man Mono nutzen, das lässt sich dann auch auf anderen CPU Architekturen und OS nutzen. Aber alle haben keine WPF-Unterstützung. Für .NET 6 soll es zwar etwas in Zukunft geben, aber ob das für 3D Grafik wirklich funktioniert bleibt unklar.

Bisher gab es zwei Möglichkeiten Software für verschiedene Plattformen zu schreiben. Man nimmt eine CrossPlattform GUI wie etwa Qt (Lizenz beachten), Gtk, … oder man schreibt für jede Plattform die GUI neu. Letzteres erwarten viele Mac Nutzer, weil nur so die Applikation sich perfekt ins System integriert, aber das macht die Sache teuer.

Man muss auch über das 3D Backend reden. Apple hat den Support für OpenGL eingestellt und unterstützt in Zukunft nur noch Metal, was neben macOS nur noch von Apples iOS genutzt wird. Auf Windows wird von MS das eigene DirectX hauptsächlich propagiert, aber OpenGL und Vulkan sind ebenfalls vorhanden. Linux unterstützt nur OpenGL und nun Vulkan.

Persönlich sehe ich die Portierung auf Linux als sehr viel einfacher an, und es gäbe da die Möglichkeit durch Qt, Gtk, … Kosten sparen zu können.


Qt, Gtk, … haben gegenüber Electron den Vorteil, dass die GUI in nativer Geschwindigkeit läuft und so hochperformante Applikationen erlauben.