Hallo, ich schreibe gerade eine Software mit Visual Studio, welche allerdings anschließend auch auf einer neuen Macintosh Plattform laufen können muss. Mit welchen Tools kann ich unter Windows ein Programm entwickeln, welches auf dem MAC ausgeführt werden kann? Gruß Olaf
:
Verschoben durch User
für den User sollte das Programm (im Macintosh) ohne weitere Zusatzprogramme (wie Parallels Bootcamp oder VirtualBox) laufen können. Mit dem Visual Studio wird das so wahrscheinlich nicht möglich sein. Ist eher die Frage ob es solche Tools gibt, die das Mac-Compatible machen; oder ob es eine Software gibt mit der man das Programm unter Windows für Macintosh kombilieren kann.
es soll ja mittlerweile .net(mono) für mac geben aber das muss auch erst auf dem mac installiert werden. Sonst bleibt nur java übrig was aber schlecht mit dem Visual Studio geht.
momentan schreib ich alles in c++: hab ein paar Klassen aus der MFC aber die könnte man ja über entsprechende Header auch importieren (CString class z.B.)....
Wenn die Anwendung nicht übermäßig komplex, aber dafür umso kompatibler sein soll können auch Umgebungen wie RunRev LiveCode genutzt werden. Damit ist ein- und dieselbe Anwendung dann ggf. unter Win/Mac/Linux und auch gleich Android/iOS/WinMobile oder direkt im Webbrowser ausführbar und kann, im Gegensatz zu Java, bei entsprechender Anpassung auch auf jeder Plattform die Vorteile jeweils nativer Applikationen nutzen.
Realbasic resp. RealStudio. Je nach Version kann man damit unter einem Betriebssystem direkt ausführbare Dateien für ein anderes Betriebssystem erzeugen.
...- - - ... schrieb: > Was ist mit Qt, dann entsprechende Version compil das klingt ziemlich vielversprechend: hat da jmd von euch schon mal herum-gespielt? Hab gelesen, es gibt ein PlugIn für VS2010 und dann sollte man Applications für Windows (.exe) und Macintosh erstellen können. Auf die schönen Dialogfelder Buttons etc. werd ich hoffentlich nicht verzichten müssen, oder? Ist Qt auch mit der MFC kompatibel (zumindestens die schöne CString Class hätte ich gerne weiterhin :-) Gruß Olaf
Ich benutze wxWidgets, das geht auch recht gut; Qt ist jedoch etwas umfangreicher.
Olaf schrieb: > Hab gelesen, es gibt ein PlugIn für VS2010 und dann > sollte man Applications für Windows (.exe) und Macintosh erstellen > können. Das ist eher unwahrscheinlich, Mac-Binärdateien kann VS2010 nicht erzeugen. Allerdings kann ein Qt-Programm mit einem geeigneten Compiler auf einem Mac übersetzt werden. Olaf schrieb: > Auf die schönen Dialogfelder Buttons etc. werd ich hoffentlich nicht > verzichten müssen, oder? Nein, darauf musst Du nicht verzichten, nur sind sie anders und werden anders genutzt als das, was das VS2010 von sich aus macht. > Ist Qt auch mit der MFC kompatibel Absolut überhaupt gar nicht. Allerdings bietet auch Qt eine leistungsfähige Stringklasse, nur ist die natürlich auch anders als CString aus der MFC. Bei wxWidgets sieht es übrigens nicht anders aus.
Rufus Τ. Firefly schrieb: > Absolut überhaupt gar nicht. Allerdings bietet auch Qt eine > leistungsfähige Stringklasse, nur ist die natürlich auch anders als > CString aus der MFC. d.h. entweder QT oder MFC. Hoffe die Umstellung ist nicht so schwierig und VS2010 bietet den gleichen Support wie für die MFC classes. Kennt jmd noch ein gutes Tutorial wie man QT in VS2010 integrieren muss, damit beides zusammen spielt? Gruß Olaf
Olaf schrieb: > Hoffe die Umstellung ist nicht so schwierig > und VS2010 bietet den gleichen Support wie für die MFC classes. VS2010 bietet exakt gar keinen "Support" für QT oder andere Klassenbibliotheken, aber Qt und andere Klassenbibliotheken haben ihre eigene Unterstützung. Oberflächen werden nicht mit dem Windows-Resourceeditor in VS erzeugt, sondern mit entsprechenden zu den anderen Klassenbibliotheken gehörenden Werkzeugen -- oder direkt im Quelltext.
vielen Dank für diese Informationen: momentan bin ich grad dabei den nmake Befehl auszuführen und dieser dauert scheinbar stundenlang.... :-( Kann ich anschließend auf einem Windows-System mittels QT qmake eine ausführbare Datei für den MAC OSX erstellen? Oder muss ich hierfür die QT Library auch für den MAC auf einem MAC installieren?
Olaf schrieb: > vielen Dank für diese Informationen: momentan bin ich grad dabei den > nmake Befehl auszuführen und dieser dauert scheinbar stundenlang.... :-( Weil er die QT neu kompiliert. Die gibts auch vorkompiliert, dann aber für den GCC (Mingw) und nicht den VC++. > Kann ich anschließend auf einem Windows-System mittels QT qmake eine > ausführbare Datei für den MAC OSX erstellen? Kann dein VC++ - Compiler ausführbare Dateien für den Mac erstellen? Nein? Dann kann das auch deine QT nicht. Könntest natürlich versuchen einen Cross-Compiler + Cross-Compilierte QT zu installieren. Ist aber vermutlich nicht ganz einfach. > Oder muss ich hierfür die > QT Library auch für den MAC auf einem MAC installieren? Wäre der übliche und einfachste Weg.
Du kannst doch deine software für linux schreiben bei macos ist ein X server mitgeliefert (matlab macht so was weiß allerdings nicht genau wie)
Olaf schrieb: > Kann ich anschließend auf einem Windows-System mittels QT qmake eine > ausführbare Datei für den MAC OSX erstellen? Nein. > Oder muss ich hierfür die QT Library auch für den MAC auf > einem MAC installieren? Ja. Wie ich bereits schrieb, gibt es mit Realbasic/RealStudio einen echten Crosscompiler, der auf einem Windows-Rechner laufend Programme für OS X erzeugen kann (und umgekehrt). Ob so etwas ohne genaueren Test/Debugsitzungen unter OS X sinnvoll ist, steht auf einem anderen Blatt, aber rein prinzipiell geht es damit. Hinzu kommt, daß das halt ein Basic-Dialekt ist und nichts mit C++ am Hut hat. Übrigens kann man mit Wine bzw. CrossOver auch Windows-Programme direkt auf einem Mac laufen lassen (sofern das ein Intel-Mac und kein alter PPC-Mac ist), vielleicht wäre das ja auch eine in Betracht zu ziehende Variante?
Lass doch Visual Studio weg und nimm den QtCreator. Ist kleiner, schlanker, schneller nutzt den GCC und das ist ein Cross-Compiler. Wie das mit dem Mac geht, schau mal in den Assistant, das ist der Doku-Browser für Qt.
Olaf schrieb: > für den User sollte das Programm (im Macintosh) ohne weitere > Zusatzprogramme (wie Parallels Bootcamp oder VirtualBox) laufen können. > > Mit dem Visual Studio wird das so wahrscheinlich nicht möglich sein. Silverlight 4 gibt's von MS offiziell für OSX. Die Tools (Blend, VS) natürlich nur für Windows. Falls das reicht, würde ich mir die anderen Sachen erst gar nicht ansehen.
Arc Net schrieb: > Olaf schrieb: >> für den User sollte das Programm (im Macintosh) ohne weitere >> Zusatzprogramme (wie Parallels Bootcamp oder VirtualBox) laufen können. >> >> Mit dem Visual Studio wird das so wahrscheinlich nicht möglich sein. > > Silverlight 4 gibt's von MS offiziell für OSX. Kann man denn schon ganz seriös Programme auf Silverlight aufsetzen, ohne Gefahr zu laufen, dass die Mac-Version oder gleich das ganze Silverlight wieder eingestampft wird? Ich erinnere mich so düster an OS/2...
Das dürfte eine Glaubensfrage sein, die in Frage zu stellen an Ketzerei grenzt. Software für OS X sollte mit dafür vorgesehenen Werkzeugen auf OS X entwickelt werden, wie sonst wollte man die Integration in die Betriebssystemumgebung und den Aufruf von betriebssystemspezifischen API-Funktionen testen?
Sven P. schrieb: > Arc Net schrieb: >> Olaf schrieb: >>> für den User sollte das Programm (im Macintosh) ohne weitere >>> Zusatzprogramme (wie Parallels Bootcamp oder VirtualBox) laufen können. >>> >>> Mit dem Visual Studio wird das so wahrscheinlich nicht möglich sein. >> >> Silverlight 4 gibt's von MS offiziell für OSX. > Kann man denn schon ganz seriös Programme auf Silverlight aufsetzen, > ohne Gefahr zu laufen, dass die Mac-Version oder gleich das ganze > Silverlight wieder eingestampft wird? > > Ich erinnere mich so düster an OS/2... Internal Bureaucratic Mess sagt doch eigentlich alles Zu MS gibt's ein nettes Video (Upgrade-Prozess von DOS 5 bis Win 7) http://www.youtube.com/watch?v=vPnehDhGa14 Ernsthaft... - Silverlight gibt es als native (C++ nicht C++/CLI) Variante für Windows CE (ab 6.0) - SL ist das Framework für Windows Phone 7 (z.Z. SL3.x, SL4 beim nächsten Update) - XBOX soll wohl auch unterstützt werden - VS LightSwitch (das Werkzeug für Geschäftsanwendungen) setzt auf SL - Windows 8 (App-Store, Jupiter) wird wohl (zumindest in einigen Bereichen) auch auf SL setzen
Naja, im Wesentlichen also nur die Microsoft-Welt. Dem gegenüber stünde QT mit Win und Mac, sowie Unix/Linux und das auf nahezu allen verfügbaren Rechnerarchitekturen. Dazu frei zugängliche Quellen und eine LGPL-Lizenzbasis. Wie im Thread nebenan bemerkt, bietet QT dann noch eine brauchbare Umgebung für Lokalisierung der Anwendungen. Sofern noch keine Quelltextbasis vorhanden ist, müsste ich ganz persönlich da nur kurz überlegen. Man sollte auch mal klären, um welchen Anwendungstyp es überhaupt geht. QT abstrahiert recht weit weg vom Betriebssystem. Mittlerweile erscheinen z.B. selbst die Knöpfe in Dialogen (Ok, Abbrechen, Schließen, Wiederholen...) je nach Betriebssystem in der dort üblichen Reihenfolge.
Sven P. schrieb: > Naja, im Wesentlichen also nur die Microsoft-Welt. Abgesehen von OSX und dem was Novell liefert (MonoTouch/MonoDroid (iOS, Android) und Moonlight), ja. > Dem gegenüber stünde QT mit Win und Mac, sowie Unix/Linux und das auf > nahezu allen verfügbaren Rechnerarchitekturen. Dazu frei zugängliche > Quellen und eine LGPL-Lizenzbasis. Kurze Antwort: Ist das auch nur im entferntesten Sinne kommerziell: Keine Komponenten unter der GPL, LGPL oder ähnlichen (Derivaten), sondern nur BSD und vergleichbare. > Wie im Thread nebenan bemerkt, bietet > QT dann noch eine brauchbare Umgebung für Lokalisierung der Anwendungen. siehe anderer Thread > Sofern noch keine Quelltextbasis vorhanden ist, müsste ich ganz > persönlich da nur kurz überlegen. Ich auch, Produktivität, Funktionalität, Tools -> kein Qt oder Java > Man sollte auch mal klären, um welchen Anwendungstyp es überhaupt geht. > QT abstrahiert recht weit weg vom Betriebssystem. Die Zeit der minimalen Wrapper ist vorbei... > Mittlerweile > erscheinen z.B. selbst die Knöpfe in Dialogen (Ok, Abbrechen, Schließen, > Wiederholen...) je nach Betriebssystem in der dort üblichen Reihenfolge.
Arc Net schrieb: > Sven P. schrieb: >> Naja, im Wesentlichen also nur die Microsoft-Welt. > > Abgesehen von OSX und dem was Novell liefert (MonoTouch/MonoDroid (iOS, > Android) und Moonlight), ja. Naja, ist halt wieder 'Hinterherlaufen'. >> Dem gegenüber stünde QT mit Win und Mac, sowie Unix/Linux und das auf >> nahezu allen verfügbaren Rechnerarchitekturen. Dazu frei zugängliche >> Quellen und eine LGPL-Lizenzbasis. > > Kurze Antwort: Ist das auch nur im entferntesten Sinne kommerziell: > Keine Komponenten unter der GPL, LGPL oder ähnlichen (Derivaten), > sondern nur BSD und vergleichbare. Wo steht denn das? Bei mir steht unter Siverlight immer noch die EULA. Oder beziehst du das auf Moonlight? >> Wie im Thread nebenan bemerkt, bietet >> QT dann noch eine brauchbare Umgebung für Lokalisierung der Anwendungen. > > siehe anderer Thread siehe dort. >> Sofern noch keine Quelltextbasis vorhanden ist, müsste ich ganz >> persönlich da nur kurz überlegen. > > Ich auch, Produktivität, Funktionalität, Tools -> kein Qt oder Java Sollte Silverlight in 5 Jahren noch in Mode sein, komm ich gern dadrauf zurück :-) >> Man sollte auch mal klären, um welchen Anwendungstyp es überhaupt geht. >> QT abstrahiert recht weit weg vom Betriebssystem. > > Die Zeit der minimalen Wrapper ist vorbei... Leider.
tux85 schrieb: > Du kannst doch deine software für linux schreiben bei macos ist ein X > server mitgeliefert (matlab macht so was weiß allerdings nicht genau > wie) Eine X11-Anwendung wird allerdings kein Mac-Nutzer freiwillig verwenden.
Andreas Schwarz schrieb: > Eine X11-Anwendung wird allerdings kein Mac-Nutzer freiwillig verwenden. Wenn sich deren Ersteller ausreichend Mühe damit gegeben hat, die Apple-GUI nachzubilden, dann ja, aber der Aufwand ist wohl erheblich. Und als Mac-Nutzer legt man Wert auf eine einheitliche und konsistente Benutzeroberfläche.
Rufus Τ. Firefly schrieb: > Andreas Schwarz schrieb: >> Eine X11-Anwendung wird allerdings kein Mac-Nutzer freiwillig verwenden. > > Wenn sich deren Ersteller ausreichend Mühe damit gegeben hat, die > Apple-GUI nachzubilden, dann ja, aber der Aufwand ist wohl erheblich. > Und als Mac-Nutzer legt man Wert auf eine einheitliche und konsistente > Benutzeroberfläche. Stell dir vor, es gibt Leute die das GUI von LTspice als toll empfinden. Nach der Ansage ware mir dann das Genörgel wegen meiner Verbesserungswünsche an LTspice klar. Offensichtlich kennen viele Leute nichts besseres als Windows. Und obendrauf sind da wohl viele auch nicht in der Lage was besseres überhaupt zu erkennen. Das erinnert mich stark an den Bilderqualität-Thread. Irgendwie enttäuschend. Nicht das ich LTspice nicht toll fände was die eigentliche Engine angeht. Aber das Bedienkonzept ist eine Ausgeburt von 1985 ! Mein Vorschlag, der Entwickler solle sich genau um die SPICE-Engine kümmern und das GUI im Sinne von Client-Server Betrieb einem diesbezüglichen Profi überlassen, wurde offensichtlich überhaupt nicht verstanden und nur provokativ aufgefasst. Das nur so am Rande.
Wie sähe die GUI von LTSpice denn dann aus? Also ich meine, die GUI fällt mir recht wenig auf -- die Simulation steht im Zentrum, der Rest geht über recht sinnige Tastenbelegungen. Guck dir doch als Vergleich mal Simplorer an: Eine einzige Katastrophe: - kein Zoom per Strg+Mausrad, - kein horizontales Scrollen mit Umschalt+Mausrad, - permanent Glitches beim Zeichnen (Linien plötzlich mal einen Pixel versetzt), - die 1000. Toolbar-Komponente statt der Windows-eigenen, - die 1000000. unterentwickelte Menü-Komponente, statt der Windows-eigenen Menüfunktionen; wenn man mit der Maus ein Menü öffnet, dann verliert das Simplorer-Hauptfenster allen ernstes den Eingabefokus (!), sieht man an der Titelzeile, die bei mir dann z.B. (für inaktive Fenster) grau wird, - grottiges Gefrickel mit Werteeingaben, - ... Unterm Strich immer voll gegen alles, was an Ergonomie bzw. GUI-Richtlinien unter Windows so angesagt ist. Null Desktop-Integration. Muss das sein? Target kann das zum Beispiel auch gut, noch eine Toolbar-Komponente, die lahm bzw. auf kleinen Monitoren garnicht brauchbar rendert, hirnverbranntes MDI-Konzept, wodurch es effektiv unbrauchbar für den Betrieb mit zwei Monitoren ist. Dann überall statt Windows-eigener Verzeichnisdialoge selbst konstruierte Auswahllisten, die Dialogbuttons (OK, Abbrechen, Schließen usw.) jedes Mal woanders angeordnet und so weiter. Beides Software, die ein Schweinegeld kostet. Dagegen ist das GUI vom (kostenlosen!) LTSpice mehr oder weniger optimal: Es benutzt Windows-eigene Menü- und Toolbars, es benutzt Windows-eigene Dateidialoge, die Knöpfe stehen in der für Windows typischen Reihenfolge. Ansonsten hält es einfach nur die Fresse und tut, was es soll. Ganz ohne 'Wussten Sie schon?', 'Ihre Uhr geht falsch', 'Ja, ich möchte jetzt starten'.
Hab dich schon verstanden. Ich mache einen Dialog auf und der ist nicht skalierbar. Schon fällt bei mir die Klappe! Unter der Haube siehts auch nicht besser aus: LTspice benutzt beim Internet-Update sinnigerweise gzip Kompression, also '.gzip' an die Datei angehangen. Klein-Abdul also gleich ausprobiert: Lokal *.asc.gzip Geht nicht! Naja, nur ein Beispiel. Es gibt sicherlich sinnigere für LTspice. Auf die Idee die unsäglich vielen Anfragen nach Modell-Import in LTspice einfach mit einem Import Model im Datei-Dialog zu beenden, will man auch nicht kommen... Einem geschenkten Gaul... Aber der Thread hieß wohl anders ;-)
> - kein Zoom per Strg+Mausrad, > - kein horizontales Scrollen mit Umschalt+Mausrad, !!!! > - permanent Glitches beim Zeichnen (Linien plötzlich mal einen Pixel > versetzt), > - grottiges Gefrickel mit Werteeingaben, > - ... Hab grad das Gefühl, du redest von Eagle...
Windows war ein Fortschritt gegenüber DOS. Vor allem was die Druckertreiber anging. OK, befürchte, die meisten hier werden das nun nicht verstehen - mangels Alter. Dann ist Windoof aber schlicht stehengeblieben! Typisch BWLer eben.
Verstehe ich. Aber auch beim Druckertreiber haben sie es bis heute nicht geschafft, dass man Druckaufträge zuverlässig und wirksam abbrechen kann :->
Du wirst lachen: Genau das hat mich vor einigen Minuten meine Frau gefragt! Meine Antwort war: Soweit ich weiß, geht das nur bei Postscript-Druckern wirklich.
Abdul K. schrieb: > Dann ist Windoof aber schlicht stehengeblieben! Typisch BWLer eben. Das ist nicht Windows in die Schuhe zu schieben, sondern den zunehmend unfähiger werdenden "Programmierern", die Programme für Windows zusammenfrickeln. Microsoft hat schon vor Ewigkeiten mit den User Interface Guidelines ein sehr intensiv ignoriertes Werk veröffentlicht. Nur die 10 Gebote dürften noch häufiger ignoriert werden. Unter OS X wird wesentlich mehr auf die Einhaltung der entsprechenden Richtlinien geachtet; so nimmt Apple Software nur dann in den AppStore auf, wenn sie sich an die Richtlinien hält, und in vor-AppStore-Zeiten sah es mit dem von Apple gepflegten Softwareverzeichnis nicht anders aus. Und die Nutzer von OS X legen Wert darauf; wenn Apple selbst eigenmächtig die GUI ändert, gibt es teilweise erheblichen Gegenwind, der sich durchaus auch niederschlagen kann. Vor einiger Zeit wurde die Hintergrundfarbe für die Albenliste in iTunes von Schwarz auf Weiß geändert - nur wenig später (und viel Gefluche seitens der Anwender) gab es ein Update, mit dem wieder die alte Darstellung gewählt werden konnte. Ergonomiekatastrophen wie üblichen Beigabenprogramme für Soundkarten sind unter OS X auch sehr selten.
Es ist einfach ne Frage der persönlichen Reife. Keine Frage.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.