Windows Programme umprogrammieren

[Kevinst]

...

 

[below]

*** Werbung ***

Ich kann Euch entsprechende Beratung anbieten. Das werdet ihr brauchen

*** Ende Werbung ***

Erstmal freut mich das, wenn wieder jemand richtig auf den Mac portieren will. Aber das wird Arbeit. Ihr müsst Euch überlegen, ob ihr das UI vollkommen vom Kern trennt, oder da ein Cross-Platform Tool verwendet etc. Bei "Millionen Zeilen Code" fällt es mir schwer, pauschal Tips zu geben

Ale

 

[Kevinst]

...

 

[action]

wine emuliert windows. also nicht wirklich das was du suchst. um welche art von anwendung handelt es sich??

 

[Kevinst]

...

 

[Skeeve]

Sinnvollerweise klingt mir das nicht nach einer Aufgabe für eine Person. Vorallem dann nciht, wenn weiter an der Windowsversion programmiert wird. Ansonsten fängst Du nämlich nachher von vorne an.

Dazu sollte man die Windowsversion erstmal so umstellen, daß die windowsspezifischen Teile gut vom Rest getrennt sind.

An diesem Rest kann dann gearbeitet werden. Die windowsspezifischen werden dann zunächst eingefroren und Du hast Zeit, sie auf Mac umsetzen.

 

[hanebambel]

Hi!

Mal ein Tipp von mir: Da es sich scheinbar um ein Programm handelt, bei welchem viel wert auf die Benutzeroberfläche gelegt wurde ist WINE keine gute Idee für die Umsetzung. Der Mac User tendiert dazu, sehr viel wert auf die Oberfläche zu legen und akzeptiert daher Programme die nicht zum "Look and Feel" von OSX passen eher weniger (siehe OpenOffice). Un ein mit WINE gestartetes Programm sieht eben immer noch aus wie ein Windows Programm...

CU Jan

p.s.: Falls es sich um ein MFC-Programm handelt wünsche ich Dir viel Spass bei der Umsetzung

 

[tjp]

Geplant ist, dass wir nichts vom Kern trennen werden, da täglich mehrere Windowsprogrammierer den Windowscode aktualisieren. Dieser soll dann ohne große Probleme auf das MAC OS portiert werden können.

Chancenlos das geht nicht! Wenn ihr einen MacOS X Port haben wollt müßt ihr Euch darauf einlassen und die restliche Applikation entsprechend sauber umgestalten. Wenn ihr das nicht machen wollt, laßt den ganzen Vorgang lieber gleich sein. Es kostet nur Geld und wird nichts bringen.

Soll heißen: Wäre das für den Endbenutzer komfortabel oder umständlich zu bedienen?

Ja, unkomfortabel und instabil ist die ganze Geschichte. Wine kann man für ein kommerziell vertriebenes Produkt vollständig vergessen. Kein MacNutzer wäre bereit für sowas Geld zu bezahlen.

Ist das Ganze für mich als Einzelperson ( macht kein ganzes Team.. wie gesagt bin ich der Glückspilz der die Portierung vornehmen darf ) überhaupt realisierbar oder bin ich von Beginn als professioneller Windowsprogrammierer schon verloren?

Wenn ihr bereit wäret den Programmcode umzugestalten wäre diese Aufgabe zu schaffen, so aber ist das von Anfang an zum Scheitern verurteilt. Man kann kein Windows Sourcecode 1:1 auf MacOS X übertragen und dort einfach compilieren und er läuft.

Es gibt zwar MFC für UNIX aber meines Wissens gehört MacOS X nicht zu den unterstützen Plattformen und der ganze Spaß ist teuer, richtig teuer: Mehrere tausend Euro pro Arbeitsplatz und es fallen meines Wissens nicht unerhebliche Lizenzkosten pro verkauftes Softwarepaket an.

Schau Dir am besten folgende Seite an GUITools, da kannst Du sehen was es so an Möglichkeiten für Crossplattformlösungen gibt. Die Seite ist wohl nicht vollständig, aber sie enthält alle wichtigen Tools.

 

[Kevinst]

-..

 

[Kernelpanik]

Hier bist Du besser aufgehoben. In diesem Forum gehts nich ums Programmieren.

 

[Kevinst]

oh sorry, vielen dank.

 

[Peter Maurer]

In diesem Forum gehts nich ums Programmieren.

Haett' ich das frueher gewusst, dann haette ich mir hier schon ein paar Beitraege sparen koennen. Jetzt nur noch eine Frage: Was glaubst Du denn, warum dieses Unterforum "OS X-Developer" heisst? Zufall? Mutwillige Irrefuehrung?

Und das von Dir verlinkte Entwicklerforum mag zwar eindeutiger in seiner thematischen Ausrichtung sein; aber die Hoelle ist da ja auch nicht wirklich los.

 

[MacApple]

WINE fällt weg.
Eure Argumente haben überzeugt und auch mein Chef ist dagegen.

Warum solltet Ihr Euch auch auf Intel-Macs beschränken? Es gibt noch massenweise PPC-Macs im Einsatz.

Gibt es eine Art MAC-Api die zu mindest ein wenig der von Windows ähnelt?
(normale Dinge wie CreateWindowEx, SetWindowPos etc.)

Na, welches API für grafische Oberflächen hat den solche Dinge nicht? Wie sollen denn sonst die Fenster etc. auf den Bildschirm kommen. Dokumentation zum Entwickeln auf dem Mac gibt es auf den Developer Seiten. Speziell für Dich dürfte auch das hier interessant sein.

Dann haltet ihr das Ganze aber schon für durchführbar?
Oder ist die MAC-Api (wenn es denn eine gibt) im Vergleich zu der von Windows extrem beschränkt?

Was hast Du denn für eine Vorstellung von Mac OS X? Apple liefert seit 1984 Rechner mit grafischer Oberfläche aus. Auch wenn ich das Windows API kaum kenne, glaube ich nicht, dass Mac OS X im Vergleich dazu extrem beschränkt ist. Eher im Gegenteil.

MacApple

 

[MacApple]

Und das von Dir verlinkte Entwicklerforum mag zwar eindeutiger in seiner thematischen Ausrichtung sein; aber die Hoelle ist da ja auch nicht wirklich los.

Quantität sagt aber auch nichts über die Qualität aus.

MacApple

 

[osfreak]

Somit muss also der Code komplett übersetzt werden in Macsprache..
Gibt es eine Art MAC-Api die zu mindest ein wenig der von Windows ähnelt?
(normale Dinge wie CreateWindowEx, SetWindowPos etc.)

Es gibt zwei Umgebungen (also 2 API's) auf dem Mac die Carbon und Cocoa heissen und mehr oder weniger dasselbe tun. Carbon ist entstanden um seinerzeit eine Brücke zu bauen zwischen dem älteren MacOS und MacOSX und Cocoa ist von Nextstep mitgekommen. Das führt zu zwei verschiedenen Programmiertechniken die prinzipiell beide zum Ziel führen und auch gemixt werden können. Cocoa ist allerdings eng mit der Programmiersprache Objective-C verbandelt was für Portabilität vielleicht weniger günstig ist als Carbon, dafür aber im Mac-Lager höchst populär. Prinzipiell gibt es natürlich für alles Entsprechungen zur Windows-API aber die technische Umsetzung ist anders.

Man muss aber nicht das gesamte Programm umschreiben sondern nur die API-relevanten Sachen anders behandeln. Das betrifft die ganzen Fensterelemente, die Eventverwaltung, das Drucken (MaxOSX macht ja auch selber PDF's) usw. Mit dem Interface-Builder ist bestimmt vieles relativ gut machbar. Das kann man so ein kleines bisschen mit dem Vorgehen in Delphi vergleichen. Die Verwaltung der Rechte ist im Unix auch anders als im Windows aber bedeutend transparenter und weniger verschachtelt. Die Hilfe (F1) ist HTML-basiert im MacOSX und wenn sie es bei Euch auch ist dann ist dort zB wirklich extrem wenig Aufwand.

Der Kern von MacOSX ist allerdings ein FreeBSD-Unix mit Mach-Kernel und ist genauso Open Source wie zB Linux.

Dann haltet ihr das Ganze aber schon für durchführbar?
Oder ist die MAC-Api (wenn es denn eine gibt) im Vergleich zu der von Windows extrem beschränkt?

Überhaupt nicht beschränkt. Aber ganz sicher auch nicht in einer Woche mal fix erledigt.

Thomas

 

[MatzeLoCal]

Hier bist Du besser aufgehoben. In diesem Forum gehts nich ums Programmieren.

Wo Du recht hast, hast Du recht.
Meist gehts hier ums Kakao- oder Kaffeekochen.

Ist ja wohl eindeutig, dass das hier ein Sekretärinnen Forum ist.