Unter Mac OS X 10.5 sollen Windows-Programme laufen - ohne Windows

[Jochen]

las ich grad bei macnews in einer längeren news.

Nun ist die Info wieder weg ?

Weiss da wer was.

Hinweis auf WINE = Windows Is Not an Emulator

Werd mal im Internet suchen

Jochen

[Jochen]

Bei

http://de.wikipedia.org/wiki/WINE

steht ja was unter WINE

Jochen

[Jochen]

Nun der Link

http://www.macnews.de/news/73505

Jochen

[Jochen]

Nun steht da was von gefälscht

Nun wird's spannend

Jochen

[Florian]

Na, dann ist ja alles klar. Aber wieso spannend?
Das WINE früher oder später kommt, ist ja glücklicherweise schon klar. Ob's dann für den Unix-unerfahrenen Benutzer wirklich stressfrei zu installieren und zu nutzen ist, ist aber eine andere Frage.

[MacFlieger]

Naja, ob Wine in 10.5 integriert wird oder nicht. Laufen wird es nur auf Intel-Macs. Zudem wird Wine garantiert vorher schon verfügbar sein. Schließlich läuft das schon auf mehreren Unix-Varianten und unter anderem auch auf BSD.

Ob das gut oder schlecht ist, wer weiß. Die Win-Applikationen werden sich dann unter OS X etwas schlechter einfügen als Classic-Programme auf PPC-Macs. Schlechter deshalb, da WINE nur mit X11 läuft und daher Aqua nicht benutzt wird. Ist wie bei OpenOffice/X11, das sich ja auch schlechter integriert als NeoOffice.

Auf jeden Fall wieder ein Grund mehr für Entwickler zu sagen: "Eine X-Version machen wir nicht, nehmen Sie doch WINE." Wier das auch schon bei Lunix geschieht.

[Jochen]

Na, dann ist ja alles klar. Aber wieso spannend?
Das WINE früher oder später kommt, ist ja glücklicherweise schon klar. Ob's dann für den Unix-unerfahrenen Benutzer wirklich stressfrei zu installieren und zu nutzen ist, ist aber eine andere Frage.

Nun ja, momentan ist die Installation hakelig.
Aber dass müsste sich doch programmtechnisch in den Griff bekommen lassen.

Schlechter fände ich es, wenn es so käme, wie MacFlieger es sagt.

Nun gibt es ja aber auch schon eine Vielzahl von neuen X Cocoa Programmen.

Die sind z. T. ja auch schon im im neuen Code programmiert.

Gennerell ist aber doch die Frage, ob der Programmieraufwand für apps direkt für X evtl geringer ist, als irgendwelche Umprogrammierungen vorhandener apps.

Es kamen doch in der letzten Zeit viel neue Programmen für X raus.

Evtl. lassen sich neue Programme explizit für X in Cocoa besser und schneller coden als mit ältere Programmiertechniken ?

Dazu könnte ein (unser) fachmann ;-) mal was zu sagen

Jochen

[Florian]

Naja, ob Wine in 10.5 integriert wird oder nicht. Laufen wird es nur auf Intel-Macs. Zudem wird Wine garantiert vorher schon verfügbar sein. Schließlich läuft das schon auf mehreren Unix-Varianten und unter anderem auch auf BSD.

Apple wird WINE garantiert nicht in Leopard integrieren. Da braucht man gar nicht spekulieren.
Auch hat das WINE-Team schon längst angekündigt, daß sie es für die Intel-Macs rausbringen wollen.

Ob das gut oder schlecht ist, wer weiß. Die Win-Applikationen werden sich dann unter OS X etwas schlechter einfügen als Classic-Programme auf PPC-Macs. Schlechter deshalb, da WINE nur mit X11 läuft und daher Aqua nicht benutzt wird. Ist wie bei OpenOffice/X11, das sich ja auch schlechter integriert als NeoOffice.

Auf jeden Fall wieder ein Grund mehr für Entwickler zu sagen: "Eine X-Version machen wir nicht, nehmen Sie doch WINE." Wier das auch schon bei Lunix geschieht.

Habe mich auch schon so geäußert, glaube aber immer weniger daran. Eben wegen dieser Non-Aqua-Sache. Selbst eine kostenlose (!) Variante für Open Office wurde extra auf Aqua getrimmt... X11 setzen 90% der Mac-User nicht ein, und zwar oft mit Absicht nicht. Die meisten Hersteller werden schon einsehen (müssen), daß es einen Unterschied gibt in dem was man einem typischen Linux-User und einem typischen Mac-User zumuten kann.
"Schlimmer" wäre wahrscheinlich, wenn man Windows booten kann. Das ist ja auch das größere Problem für Linux x86.
Nun sehe ich da aber auch noch einen Unterschied: Wer einen Mac kauft, tut dies explizit, um OS X zu nutzen. Das Statement ist also schon recht stark. Ich kann mir eigentlich kaum vorstellen, daß es eine größere Firma gibt, die es sich leisten will, es zu ignorieren. Die kleineren vielleicht eher, aber auch hier sehe ich das eher als Ausnahme.
Vielleicht ist es ja auch so, daß immer mehr Leute Macs kaufen, weil eben die alten Programme funktionieren und dadurch OS X als Zielplattform immer interessanter wird.

[Florian]

Nun ja, momentan ist die Installation hakelig.
Aber dass müsste sich doch programmtechnisch in den Griff bekommen lassen.

Kennst Du WINE also doch schon?

Nun, sicher könnte es da Methoden geben, ist halt die Frage, wer das macht, und wann, und ob er dann Geld dafür sehen will...

Schlechter fände ich es, wenn es so käme, wie MacFlieger es sagt.

Nun gibt es ja aber auch schon eine Vielzahl von neuen X Cocoa Programmen.

Die sind z. T. ja auch schon im im neuen Code programmiert.

Ich nehme an, Du meinst Aqua? Denn Cocoa ist der "neue Code".

Gennerell ist aber doch die Frage, ob der Programmieraufwand für apps direkt für X evtl geringer ist, als irgendwelche Umprogrammierungen vorhandener apps.

Es kamen doch in der letzten Zeit viel neue Programmen für X raus.

Evtl. lassen sich neue Programme explizit für X in Cocoa besser und schneller coden als mit ältere Programmiertechniken ?

Dazu könnte ein (unser) fachmann ;-) mal was zu sagen

Ich würde mal, als Laie. , behaupten:
Das kommt alles auf den Einzelfall an.

[MacFlieger]

Nun ja, momentan ist die Installation hakelig.
Aber dass müsste sich doch programmtechnisch in den Griff bekommen lassen.

Ja, das kann man relativ einfach machen. siehe GIMP. _Das_ ist nicht das Problem.

Gennerell ist aber doch die Frage, ob der Programmieraufwand für apps direkt für X evtl geringer ist, als irgendwelche Umprogrammierungen vorhandener apps.

Das Umprogrammieren ist nicht ohne. Du mußt denken, daß jede GUI (ob X11, Aqua oder Win) eigene Schnittstellen für den Programmierer anbietet, die sich in ihrem Konzept stark unterscheiden. Und das ist das Hauptproblem. Da sich die Konzepte unterscheiden, ist es nicht eben schnell getan, nur die Schnittstellen auszutauschen, sondern es müssen große Teile völlig anders programmiert werden. Das ist ja gerade auch das Problem bei OpenOffice gewesen
WINE funktioniert doch so, daß es die Win-Schnittstellen auf die  X11-Schnittstellen abbildet, d.h. es wandelt die Aufrufe entsprechend um. Wenn man das unter Aqua machen sollte, wäre das ein völlig anderes Programm, denn dann müßten die Win-Schnittstellen auf die Aqua-Schnittstellen um gewandelt werden.

Stell Dir das so vor: Du hast einen Autodachträger (Win-Programm), welches nicht auf Dein Auto (X11-GUI) paßt, weil das ein anderes Dach (Schnittstellen) hat. Nun gibt es einen Adapter (WINE), welcher den Anschluß des Autodachträgers an Dein Dach erlaubt. Nun kaufst Du Dir einen LKW (Aqua-GUI), der natürlich ein völlig anderes Dach hat. Um Deinen Autodachträger trotzdem zu verwenden, benötigst Du einen neuen Adapter, der sich doch stark von Deinem alten unterscheidet.

Ich liebe Autovergleiche. 

[Jochen]

WINE kenne ich nicht.

Mein statement hakelige Installation bezog sich auf Installation von Programmen bei der X11 o. s. ä. notwendig ist.

Hatte mal Matlab installiert, da war das so.

Mit neuem code meinte ich die universal binaries.

Das habe ich so verstanden dass solche Programme sowohl unter X auf IBM / Motorola CPU's laufen als auch auf INTEL CPU's

Denke hier an:

GrafikConverter
RagTime 6
Merlin

Jochen

[Jochen]

Ich liebe Autovergleiche. 

Prima, dass verstehe sogar ich ;-)

Jochen

[MacFlieger]

Mit neuem code meinte ich die universal binaries.
Das habe ich so verstanden dass solche Programme sowohl unter X auf IBM / Motorola CPU's laufen als auch auf INTEL CPU's

Ach so, ne, da hast Du was falsch verstanden.
Universal Binaries heißt, daß in dem Programm die Programmcodes für beide CPUs einzeln drin liegen. D.h. der Code läuft nicht auf beiden CPUs (wie auch, die benutzen ja unterschiedliche Codes), sondern je nachdem was für einen Prozessor Du hast, wird der eine oder der andere enthaltene Code verwendet. Dadurch werden die Programme natürlich größer.
Im Prinzip ist das wie mit den Sprachen. Ein Programm kann mehrere Sprachpakete enthalten und eines davon (welches auf Dich paßt), wird verwendet. Alle anderen sind eigentlich nur Platzverschwendung.
Bei dem Wechsel von 68K->PPC gabs das auch schon. Sogenannte FAT-Programme enthielten 68K- und PPC-Code. Je nachdem, was man für eine Maschine hat, wird der entsprechende Code verwendet. Schnell gab es Programme, mit dem man den überflüssigen Code entfernen konnte, genauso wie es ja jetzt Programme gibt, um die überflüssigen Sprachpakete zu entfernen.

Bei WINE sieht die Lage noch anders aus. WINE ist kein(!) Emulator, der den Prozessor nachbildet, sondern es ist nur ein Adapter, der die nicht vorhandenen Win-Schnittstellen unter Unix bereit stellt. Das Win-Programm selber wird nicht verändert und wir nativ auf dem Prozessor ausgeführt. Man muß also einen x86-Prozessor haben. WINE läuft daher nicht unter Linux-PPC oder anderen nicht x86-Unixen.

[maya]

...

Stell Dir das so vor: Du hast einen Autodachträger (Win-Programm), welches nicht auf Dein Auto (X11-GUI) paßt, weil das ein anderes Dach (Schnittstellen) hat. Nun gibt es einen Adapter (WINE), welcher den Anschluß des Autodachträgers an Dein Dach erlaubt. Nun kaufst Du Dir einen LKW (Aqua-GUI), der natürlich ein völlig anderes Dach hat. Um Deinen Autodachträger trotzdem zu verwenden, benötigst Du einen neuen Adapter, der sich doch stark von Deinem alten unterscheidet.

Ich liebe Autovergleiche. 

Der Vergleich ist wirklich gut 

Re: Unter Mac OS X 10.5 sollen Windows-Programme laufen - ohne Windows )

Vielleicht kauft der Apfel ja die Parallelen und schon springt der Leo durch alle verschieden farbigen Reifengrößen.

m.

[Florian]

Tjaja, so wird man mit älteren Statements seiner selbst konfrontiert.

Die Realität walzt über unsere Vorstellungen hinweg, wir gucken hinterher. Sollte es nicht anders herum sein?