Mais surtout pour un logiciel écris sous Win32 (ce dont on parle), sa portabilité ne sera pas évidente.
Même s'il permet de faire tourner des soft M$, wine tourne sous Linux, donc il peut pas être écris sous win32, non ? Sauf erreur il apporte surtout des lib qui sont en fait des portages de dll windose. Autrement dit le travail a déjà été fait...
Le site de sourceforge est down pour l'instant, donc je ne peux pas aller voir de quoi il en retourne.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Mais surtout pour un logiciel écris sous Win32 (ce dont on parle), sa
portabilité ne sera pas évidente.
Même s'il permet de faire tourner des soft M$, wine tourne sous Linux,
donc il peut pas être écris sous win32, non ?
Sauf erreur il apporte surtout des lib qui sont en fait des portages de
dll windose. Autrement dit le travail a déjà été fait...
Le site de sourceforge est down pour l'instant, donc je ne peux pas
aller voir de quoi il en retourne.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Mais surtout pour un logiciel écris sous Win32 (ce dont on parle), sa portabilité ne sera pas évidente.
Même s'il permet de faire tourner des soft M$, wine tourne sous Linux, donc il peut pas être écris sous win32, non ? Sauf erreur il apporte surtout des lib qui sont en fait des portages de dll windose. Autrement dit le travail a déjà été fait...
Le site de sourceforge est down pour l'instant, donc je ne peux pas aller voir de quoi il en retourne.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
fra
michel langlois wrote:
Il fait tourner quel W$ ce wine ?
D'après ce que j'en ai compris aucun. Il fait tourner des applis pour windows sans windows, dans une fenêtre. -- Fra
michel langlois <langmc@free.fr.invalid> wrote:
Il fait tourner quel W$ ce wine ?
D'après ce que j'en ai compris aucun. Il fait tourner des applis pour
windows sans windows, dans une fenêtre.
--
Fra
Ou alors les Mec de Wine travaille comme Apple en ayant dans leurs cartons secrets une version Wine/Mac maintenu en permanence au fil des révisions...
Bein wine c'est pour linux à la base, ça devrait pas être trop dur non ? -- Fra
Schmurtz
(Pierre-Alain Dorange) wrote:
Ca s'appelle "Accelerate Framework" : <http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi nary/universal_binary_vector/chapter_6_section_2.html>
et comprend VectorLib et Image Accelerate.
Je ne sais pas exactement ce que ça vaut (je m'en sers pas) mais ça me parait être un effort intéressant.
Ça marche mieux que de faire les calculs à la main sans utiliser altivec. Après, j'ai jamais eu le courage de faire de l'altivec, donc je ne peux pas dire si l'accelerate framework est à la hauteur du code pure altivec.
Ca s'appelle "Accelerate Framework" :
<http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi
nary/universal_binary_vector/chapter_6_section_2.html>
et comprend VectorLib et Image Accelerate.
Je ne sais pas exactement ce que ça vaut (je m'en sers pas) mais ça me
parait être un effort intéressant.
Ça marche mieux que de faire les calculs à la main sans utiliser
altivec. Après, j'ai jamais eu le courage de faire de l'altivec, donc je
ne peux pas dire si l'accelerate framework est à la hauteur du code pure
altivec.
Ca s'appelle "Accelerate Framework" : <http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi nary/universal_binary_vector/chapter_6_section_2.html>
et comprend VectorLib et Image Accelerate.
Je ne sais pas exactement ce que ça vaut (je m'en sers pas) mais ça me parait être un effort intéressant.
Ça marche mieux que de faire les calculs à la main sans utiliser altivec. Après, j'ai jamais eu le courage de faire de l'altivec, donc je ne peux pas dire si l'accelerate framework est à la hauteur du code pure altivec.
-- Schmurtz
pdorange
Fra wrote:
Ou alors les Mec de Wine travaille comme Apple en ayant dans leurs cartons secrets une version Wine/Mac maintenu en permanence au fil des révisions...
Bein wine c'est pour linux à la base, ça devrait pas être trop dur non ?
Je sais pas, mais ce qui reste toujours difficile a porter c'est (hors le processeur) l'interface graphique. Donc Wine devrait pouvoir être relativement facile a porter sur Mac/Intel mais sous X11 (si Wine utilise X11), sinon faut revoir tout ce qui est interface graphique...
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Fra <fra@alussinan.org> wrote:
Ou alors les Mec de Wine travaille comme Apple en ayant dans leurs
cartons secrets une version Wine/Mac maintenu en permanence au fil des
révisions...
Bein wine c'est pour linux à la base, ça devrait pas être trop dur non ?
Je sais pas, mais ce qui reste toujours difficile a porter c'est (hors
le processeur) l'interface graphique.
Donc Wine devrait pouvoir être relativement facile a porter sur
Mac/Intel mais sous X11 (si Wine utilise X11), sinon faut revoir tout ce
qui est interface graphique...
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/>
Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Ou alors les Mec de Wine travaille comme Apple en ayant dans leurs cartons secrets une version Wine/Mac maintenu en permanence au fil des révisions...
Bein wine c'est pour linux à la base, ça devrait pas être trop dur non ?
Je sais pas, mais ce qui reste toujours difficile a porter c'est (hors le processeur) l'interface graphique. Donc Wine devrait pouvoir être relativement facile a porter sur Mac/Intel mais sous X11 (si Wine utilise X11), sinon faut revoir tout ce qui est interface graphique...
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Patrick Stadelmann
In article <42a82d93$0$4914$, Schmurtz wrote:
Ça marche mieux que de faire les calculs à la main sans utiliser altivec. Après, j'ai jamais eu le courage de faire de l'altivec, donc je ne peux pas dire si l'accelerate framework est à la hauteur du code pure altivec.
C'est du pur AltiVec ! Et se sera du pur SSEx sur Intel.
Patrick -- Patrick Stadelmann
In article <42a82d93$0$4914$636a15ce@news.free.fr>,
Schmurtz <moi@ici.com> wrote:
Ça marche mieux que de faire les calculs à la main sans utiliser
altivec. Après, j'ai jamais eu le courage de faire de l'altivec, donc je
ne peux pas dire si l'accelerate framework est à la hauteur du code pure
altivec.
C'est du pur AltiVec ! Et se sera du pur SSEx sur Intel.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Ça marche mieux que de faire les calculs à la main sans utiliser altivec. Après, j'ai jamais eu le courage de faire de l'altivec, donc je ne peux pas dire si l'accelerate framework est à la hauteur du code pure altivec.
C'est du pur AltiVec ! Et se sera du pur SSEx sur Intel.
Patrick -- Patrick Stadelmann
Saïd
Pierre-Alain Dorange :
Fra wrote:
Ou alors les Mec de Wine travaille comme Apple en ayant dans leurs cartons secrets une version Wine/Mac maintenu en permanence au fil des révisions...
Bein wine c'est pour linux à la base, ça devrait pas être trop dur non ?
Je sais pas, mais ce qui reste toujours difficile a porter c'est (hors le processeur) l'interface graphique. Donc Wine devrait pouvoir être relativement facile a porter sur Mac/Intel mais sous X11 (si Wine utilise X11), sinon faut revoir tout ce qui est interface graphique...
Wine n'a pas d'interface graphique complique. Il ne fait que l'interprete entre X11 et les applications lancees. Son adaptation (du cote interface) devrait etre triviale.
-- Saïd. C programmers never die - they're just cast into void.
Pierre-Alain Dorange :
Fra <fra@alussinan.org> wrote:
Ou alors les Mec de Wine travaille comme Apple en ayant dans leurs
cartons secrets une version Wine/Mac maintenu en permanence au fil des
révisions...
Bein wine c'est pour linux à la base, ça devrait pas être trop dur non ?
Je sais pas, mais ce qui reste toujours difficile a porter c'est (hors
le processeur) l'interface graphique.
Donc Wine devrait pouvoir être relativement facile a porter sur
Mac/Intel mais sous X11 (si Wine utilise X11), sinon faut revoir tout ce
qui est interface graphique...
Wine n'a pas d'interface graphique complique. Il ne fait que l'interprete
entre X11 et les applications lancees. Son adaptation (du cote interface)
devrait etre triviale.
--
Saïd.
C programmers never die - they're just cast into void.
Ou alors les Mec de Wine travaille comme Apple en ayant dans leurs cartons secrets une version Wine/Mac maintenu en permanence au fil des révisions...
Bein wine c'est pour linux à la base, ça devrait pas être trop dur non ?
Je sais pas, mais ce qui reste toujours difficile a porter c'est (hors le processeur) l'interface graphique. Donc Wine devrait pouvoir être relativement facile a porter sur Mac/Intel mais sous X11 (si Wine utilise X11), sinon faut revoir tout ce qui est interface graphique...
Wine n'a pas d'interface graphique complique. Il ne fait que l'interprete entre X11 et les applications lancees. Son adaptation (du cote interface) devrait etre triviale.
-- Saïd. C programmers never die - they're just cast into void.
pmanet
michel langlois wrote:
Le renouvellement de la game va s'étaler de juin 2006 à juin 2007, à l'AE 2007 plus de PPC.
en 95, Intel disait : dans 2 ans, le Merced pour tout le monde, le Pentium n'est qu'une étape de transition.
michel langlois <langmc@free.fr.invalid> wrote:
Le renouvellement de la game va s'étaler de juin 2006 à juin 2007, à
l'AE 2007 plus de PPC.
en 95, Intel disait : dans 2 ans, le Merced pour tout le monde, le
Pentium n'est qu'une étape de transition.
Le renouvellement de la game va s'étaler de juin 2006 à juin 2007, à l'AE 2007 plus de PPC.
en 95, Intel disait : dans 2 ans, le Merced pour tout le monde, le Pentium n'est qu'une étape de transition.
Eric Lévénez
Le 9/06/05 8:44, dans <1gxvrrz.1q4ucy1jun4g1N%, « Fahimy » a écrit :
Eric Lévénez wrote:
Disons que les programmeurs sont en majorité sur x86 avec un GCC (par ex) plus optimisé, alors que passé sur sur Mac, ils découvrent et il faut dire que le compilo GCC est moins bon.
finalement est ce que ce n'est pas plutot une question de compilateur libre (gcc) peu optimisé parce que destiné à etre portable et à etre révisé en permanence, alors que sur windows on tourne plutot sur du propriétaire (piraté souvent) dont l'évolution est bloquée sur une longue durée et l'optimisation plus importante?
Le problème n'est pas libre vs payant, le problème est juste la part de marcher des CPU. Linux tourne en grande majorité sur x86 et donc les efforts d'optimisation de GCC se font sur cette machine (et cela malgré le fait que Linus utilise un Macintosh).
Tout dépend quel type de programme on fait. L'environnement Cocoa est plus lourd à l'exécution, mais apporte beaucoup plus de richesse et de fonctionnalité sans que le programmeur ait à faire quoique ce soit. Un des dernier exemple est le fameux Pomme-Ctrl-D.
Dashboard?
C'est le raccourci pour afficher la définition du dictionnaire Oxford du mot qui se trouve sous la souris.
J'espère que ce sera le deuxième cas. OPENSTEP a été conçu en vue de la portabilité, et les utilisateurs de Mac OS X vont s'en apercevoir.
donc tout faire en haut niveau et en objet, en objective C- java, arreter les bout de code en C, y compris pour optimiser des opérations très élémentaires et répétitives?
Non, bien sûr. Il y a des tas d'outils d'optimisation disponibles, et souvent la simple optimisation d'un petit bout de code booste les performances d'une grosse application. Apple fournit CHUD par exemple <http://developer.apple.com/tools/performance/overview.html>
Le C est portable pourtant.
Le C est portable si le programmeur a pensé "portable". De plus les fonctions Altivec ou MMX/SSE sont des extensions du langage C et donc ne sont pas portables.
En tant qu'utilisatrice je le sens quand je vois les freewares d'émulation ou d'encodage pour mes acquisition TV, que mon mac ne tourne pas à fond comme un windows sous virtual dub. C'est dommage il n'y a pas d'intermédiare entre la programmation crade mais efficace et la programmation propre mais lourde?
La programmation propre n'est pas forcément lourde, mais pour faire un bon programme il faut de la réflexion, de l'expérience, beaucoup de tests, du temps et encore du temps, et c'est là le problème. Les programmes sortent dès qu'ils tournottent (voir toutes les versions en 0.x ou les early releases et autre previews), il est très rare d'avoir le temps et l'argent de créer le programme que le programmeur aimerait faire.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 9/06/05 8:44, dans
<1gxvrrz.1q4ucy1jun4g1N%fbarrin@altern.org.nopub.invalid>, « Fahimy »
<fbarrin@altern.org.nopub.invalid> a écrit :
Eric Lévénez <eric@levenez.com> wrote:
Disons que les programmeurs sont en majorité sur x86 avec un GCC (par ex)
plus optimisé, alors que passé sur sur Mac, ils découvrent et il faut dire
que le compilo GCC est moins bon.
finalement est ce que ce n'est pas plutot une question de compilateur
libre (gcc) peu optimisé parce que destiné à etre portable et à etre
révisé en permanence, alors que sur windows on tourne plutot sur du
propriétaire (piraté souvent) dont l'évolution est bloquée sur une
longue durée et l'optimisation plus importante?
Le problème n'est pas libre vs payant, le problème est juste la part de
marcher des CPU. Linux tourne en grande majorité sur x86 et donc les efforts
d'optimisation de GCC se font sur cette machine (et cela malgré le fait que
Linus utilise un Macintosh).
Tout dépend quel type de programme on fait. L'environnement Cocoa est plus
lourd à l'exécution, mais apporte beaucoup plus de richesse et de
fonctionnalité sans que le programmeur ait à faire quoique ce soit. Un des
dernier exemple est le fameux Pomme-Ctrl-D.
Dashboard?
C'est le raccourci pour afficher la définition du dictionnaire Oxford du mot
qui se trouve sous la souris.
J'espère que ce sera le deuxième cas. OPENSTEP a été conçu en vue de la
portabilité, et les utilisateurs de Mac OS X vont s'en apercevoir.
donc tout faire en haut niveau et en objet, en objective C- java,
arreter les bout de code en C, y compris pour optimiser des opérations
très élémentaires et répétitives?
Non, bien sûr. Il y a des tas d'outils d'optimisation disponibles, et
souvent la simple optimisation d'un petit bout de code booste les
performances d'une grosse application. Apple fournit CHUD par exemple
<http://developer.apple.com/tools/performance/overview.html>
Le C est portable pourtant.
Le C est portable si le programmeur a pensé "portable". De plus les
fonctions Altivec ou MMX/SSE sont des extensions du langage C et donc ne
sont pas portables.
En tant qu'utilisatrice je le sens quand je
vois les freewares d'émulation ou d'encodage pour mes acquisition TV,
que mon mac ne tourne pas à fond comme un windows sous virtual dub.
C'est dommage il n'y a pas d'intermédiare entre la programmation crade
mais efficace et la programmation propre mais lourde?
La programmation propre n'est pas forcément lourde, mais pour faire un bon
programme il faut de la réflexion, de l'expérience, beaucoup de tests, du
temps et encore du temps, et c'est là le problème. Les programmes sortent
dès qu'ils tournottent (voir toutes les versions en 0.x ou les early
releases et autre previews), il est très rare d'avoir le temps et l'argent
de créer le programme que le programmeur aimerait faire.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 9/06/05 8:44, dans <1gxvrrz.1q4ucy1jun4g1N%, « Fahimy » a écrit :
Eric Lévénez wrote:
Disons que les programmeurs sont en majorité sur x86 avec un GCC (par ex) plus optimisé, alors que passé sur sur Mac, ils découvrent et il faut dire que le compilo GCC est moins bon.
finalement est ce que ce n'est pas plutot une question de compilateur libre (gcc) peu optimisé parce que destiné à etre portable et à etre révisé en permanence, alors que sur windows on tourne plutot sur du propriétaire (piraté souvent) dont l'évolution est bloquée sur une longue durée et l'optimisation plus importante?
Le problème n'est pas libre vs payant, le problème est juste la part de marcher des CPU. Linux tourne en grande majorité sur x86 et donc les efforts d'optimisation de GCC se font sur cette machine (et cela malgré le fait que Linus utilise un Macintosh).
Tout dépend quel type de programme on fait. L'environnement Cocoa est plus lourd à l'exécution, mais apporte beaucoup plus de richesse et de fonctionnalité sans que le programmeur ait à faire quoique ce soit. Un des dernier exemple est le fameux Pomme-Ctrl-D.
Dashboard?
C'est le raccourci pour afficher la définition du dictionnaire Oxford du mot qui se trouve sous la souris.
J'espère que ce sera le deuxième cas. OPENSTEP a été conçu en vue de la portabilité, et les utilisateurs de Mac OS X vont s'en apercevoir.
donc tout faire en haut niveau et en objet, en objective C- java, arreter les bout de code en C, y compris pour optimiser des opérations très élémentaires et répétitives?
Non, bien sûr. Il y a des tas d'outils d'optimisation disponibles, et souvent la simple optimisation d'un petit bout de code booste les performances d'une grosse application. Apple fournit CHUD par exemple <http://developer.apple.com/tools/performance/overview.html>
Le C est portable pourtant.
Le C est portable si le programmeur a pensé "portable". De plus les fonctions Altivec ou MMX/SSE sont des extensions du langage C et donc ne sont pas portables.
En tant qu'utilisatrice je le sens quand je vois les freewares d'émulation ou d'encodage pour mes acquisition TV, que mon mac ne tourne pas à fond comme un windows sous virtual dub. C'est dommage il n'y a pas d'intermédiare entre la programmation crade mais efficace et la programmation propre mais lourde?
La programmation propre n'est pas forcément lourde, mais pour faire un bon programme il faut de la réflexion, de l'expérience, beaucoup de tests, du temps et encore du temps, et c'est là le problème. Les programmes sortent dès qu'ils tournottent (voir toutes les versions en 0.x ou les early releases et autre previews), il est très rare d'avoir le temps et l'argent de créer le programme que le programmeur aimerait faire.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
langmc
manet wrote:
michel langlois wrote:
Le renouvellement de la game va s'étaler de juin 2006 à juin 2007, à l'AE 2007 plus de PPC.
en 95, Intel disait : dans 2 ans, le Merced pour tout le monde, le Pentium n'est qu'une étape de transition.
Oui, et !!!
-- Le sage montre la lune, l'imbécile regarde le doigt.
manet <pmanet@invivo.edu> wrote:
michel langlois <langmc@free.fr.invalid> wrote:
Le renouvellement de la game va s'étaler de juin 2006 à juin 2007, à
l'AE 2007 plus de PPC.
en 95, Intel disait : dans 2 ans, le Merced pour tout le monde, le
Pentium n'est qu'une étape de transition.
Oui, et !!!
--
Le sage montre la lune, l'imbécile regarde le doigt.
