> Le jour où je travaillerai gratuitement je serais en retraite. :-)
>
> Moi ce que je veux avec des outils c'est qu'ils puissent faire au moins le
> minimum des choses dont j'ai besoin.
> Et je veux aussi savoir s'ils seront fiables à longs termes.
>
> Pour Linux, il reste encore des zones d'ombre.
Oui, tellement de zônes d'ombres que 98% des utilisateurs utilisent
Windows.
Je trouve aussi un peu fou de payer l'adhésion au club Mandriva pour
avoir des ditros Linux comportant des milliers de softs dévloppé
souvent gratos par des autres personnes.
De plus, les milliers de softs fournis me laissent indifférents. Je
n'en ai besoin que de 5, les meilleures, utilisés par le plus grand
nombre afin d'échanger facilement mes données.
Si je compte combien m'aurait couté 5 ans d'abonnement au Club, cela
m'aurait payé une bonne partie de logiciels haut de gamme, faciles à
mettre en oeuvre.
A force de vouloir faire dans le bon marché, on fait dans la
médiocrité.
C'est très francais -> On n'aime ni le succès, ni l'échec.
Parce qu'il a été écrit avec le pied gauche pendant que le droit tenait une banane ?
Parceque, comme le dit l'article en question, que Michel Billaud a certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un programme peut très bien appeler 2 librairies partagées, chacune desquelles pouvant appeler d'autres librairies partagées, en particulier peut être deux versions différentes de la même! Dans le cas d'espèce je crois que ça se produit avec ssl. Le résultat est que ton programme se trouve lié avec deux versions d'une même librairie et à la première occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
mauvais programme ... changer de programmeur
Parce qu'il a été écrit avec le pied gauche pendant que le droit tenait
une banane ?
Parceque, comme le dit l'article en question, que Michel Billaud a
certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un
programme peut très bien appeler 2 librairies partagées, chacune
desquelles pouvant appeler d'autres librairies partagées, en particulier
peut être deux versions différentes de la même! Dans le cas d'espèce je
crois que ça se produit avec ssl. Le résultat est que ton programme se
trouve lié avec deux versions d'une même librairie et à la première
occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
Parce qu'il a été écrit avec le pied gauche pendant que le droit tenait une banane ?
Parceque, comme le dit l'article en question, que Michel Billaud a certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un programme peut très bien appeler 2 librairies partagées, chacune desquelles pouvant appeler d'autres librairies partagées, en particulier peut être deux versions différentes de la même! Dans le cas d'espèce je crois que ça se produit avec ssl. Le résultat est que ton programme se trouve lié avec deux versions d'une même librairie et à la première occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
mauvais programme ... changer de programmeur
X.B
La question n'est pas de faire tourner Gnome sur un Pentium 100, la question est de faire tourner Linux sans Gnome sur un Pentium 100, et on peut. Alors que justement, faire tourner un windows récent sans son interface graphique lourdingue, on ne peut tout simplement pas.
Certes, mais Win98 tourne sans problème sur une vieille machine *avec* son interface graphique.
C'est puissant, ca. Un systeme de 98 tourne sur une machine de la meme
epoque. Fort.
alors que mon DaSL de 2006 et son interface graphique de 2006 et le
dillo/firefo de 2006 tourne sur mon tecra de 1996 ... J'ai pas osé tester XP dessus ...
La question n'est pas de faire tourner Gnome sur un Pentium 100, la
question est de faire tourner Linux sans Gnome sur un Pentium 100, et on
peut. Alors que justement, faire tourner un windows récent sans son
interface graphique lourdingue, on ne peut tout simplement pas.
Certes, mais Win98 tourne sans problème sur une vieille machine *avec*
son interface graphique.
C'est puissant, ca. Un systeme de 98 tourne sur une machine de la meme
epoque. Fort.
alors que mon DaSL de 2006 et son interface graphique de 2006 et le
dillo/firefo de 2006 tourne sur mon tecra de 1996 ... J'ai pas osé tester
XP dessus ...
La question n'est pas de faire tourner Gnome sur un Pentium 100, la question est de faire tourner Linux sans Gnome sur un Pentium 100, et on peut. Alors que justement, faire tourner un windows récent sans son interface graphique lourdingue, on ne peut tout simplement pas.
Certes, mais Win98 tourne sans problème sur une vieille machine *avec* son interface graphique.
C'est puissant, ca. Un systeme de 98 tourne sur une machine de la meme
epoque. Fort.
alors que mon DaSL de 2006 et son interface graphique de 2006 et le
dillo/firefo de 2006 tourne sur mon tecra de 1996 ... J'ai pas osé tester XP dessus ...
X.B
Moi, je ne gueule pas spécialement sur Mandriva 2006, que je trouve assez bonne pour un débutant. D'ailleurs, je l'ai installée, et je trouve le produit pas mal du tout.
C'est une affirmation basé sur une première impression, ou sur une période d'utilisation sérieuse de plusieurs semaines ? pour mandrake : quelques année
pour mandriva : quelques semaines, m'étant decider a migrer ma 10.0 en MDVa 2006, via les outils MDVa ... cela s'est tres bien passé et tout remarche comma avant la migration. Et pourtant je suis le genre a installer des package RedHat/Suse d'il y a 3 ou 4 ans pour installer LE soft que je cherche et qui n'est plus maintenu depuis ... et qui tourne toujours.
Moi, je ne gueule pas spécialement sur Mandriva 2006, que je trouve
assez bonne pour un débutant. D'ailleurs, je l'ai installée, et je
trouve le produit pas mal du tout.
C'est une affirmation basé sur une première impression, ou sur une
période d'utilisation sérieuse de plusieurs semaines ?
pour mandrake : quelques année
pour mandriva : quelques semaines, m'étant decider a migrer ma 10.0 en MDVa
2006, via les outils MDVa ... cela s'est tres bien passé et tout remarche
comma avant la migration. Et pourtant je suis le genre a installer des
package RedHat/Suse d'il y a 3 ou 4 ans pour installer LE soft que je
cherche et qui n'est plus maintenu depuis ... et qui tourne toujours.
Moi, je ne gueule pas spécialement sur Mandriva 2006, que je trouve assez bonne pour un débutant. D'ailleurs, je l'ai installée, et je trouve le produit pas mal du tout.
C'est une affirmation basé sur une première impression, ou sur une période d'utilisation sérieuse de plusieurs semaines ? pour mandrake : quelques année
pour mandriva : quelques semaines, m'étant decider a migrer ma 10.0 en MDVa 2006, via les outils MDVa ... cela s'est tres bien passé et tout remarche comma avant la migration. Et pourtant je suis le genre a installer des package RedHat/Suse d'il y a 3 ou 4 ans pour installer LE soft que je cherche et qui n'est plus maintenu depuis ... et qui tourne toujours.
talon
X.B wrote:
Parce qu'il a été écrit avec le pied gauche pendant que le droit tenait une banane ?
Parceque, comme le dit l'article en question, que Michel Billaud a certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un programme peut très bien appeler 2 librairies partagées, chacune desquelles pouvant appeler d'autres librairies partagées, en particulier peut être deux versions différentes de la même! Dans le cas d'espèce je crois que ça se produit avec ssl. Le résultat est que ton programme se trouve lié avec deux versions d'une même librairie et à la première occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
On dirait que tu n'as pas compris. Ca arrive parceque le programmeur utilise des librairies écrites par d'autres. Il n'a aucune raison d'aller voir ce que les autres ont fait et quelles librairies partagées eux mêmes utilisent. Si par hasard ça marche sur sa machine il ne s'aperçoit de rien, et bingo.
mauvais programme ... changer de programmeur
--
Michel TALON
X.B <moi@meme.fr> wrote:
Parce qu'il a été écrit avec le pied gauche pendant que le droit tenait
une banane ?
Parceque, comme le dit l'article en question, que Michel Billaud a
certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un
programme peut très bien appeler 2 librairies partagées, chacune
desquelles pouvant appeler d'autres librairies partagées, en particulier
peut être deux versions différentes de la même! Dans le cas d'espèce je
crois que ça se produit avec ssl. Le résultat est que ton programme se
trouve lié avec deux versions d'une même librairie et à la première
occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
On dirait que tu n'as pas compris. Ca arrive parceque le programmeur utilise
des librairies écrites par d'autres. Il n'a aucune raison d'aller voir ce que
les autres ont fait et quelles librairies partagées eux mêmes utilisent. Si
par hasard ça marche sur sa machine il ne s'aperçoit de rien, et bingo.
Parce qu'il a été écrit avec le pied gauche pendant que le droit tenait une banane ?
Parceque, comme le dit l'article en question, que Michel Billaud a certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un programme peut très bien appeler 2 librairies partagées, chacune desquelles pouvant appeler d'autres librairies partagées, en particulier peut être deux versions différentes de la même! Dans le cas d'espèce je crois que ça se produit avec ssl. Le résultat est que ton programme se trouve lié avec deux versions d'une même librairie et à la première occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
On dirait que tu n'as pas compris. Ca arrive parceque le programmeur utilise des librairies écrites par d'autres. Il n'a aucune raison d'aller voir ce que les autres ont fait et quelles librairies partagées eux mêmes utilisent. Si par hasard ça marche sur sa machine il ne s'aperçoit de rien, et bingo.
mauvais programme ... changer de programmeur
--
Michel TALON
Thierry Thomas
Samedi 18 mars 2006 à 08:57 GMT, Michel Talon a écrit :
Parceque, comme le dit l'article en question, que Michel Billaud a certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un programme peut très bien appeler 2 librairies partagées, chacune desquelles pouvant appeler d'autres librairies partagées, en particulier peut être deux versions différentes de la même! Dans le cas d'espèce je crois que ça se produit avec ssl. Le résultat est que ton programme se trouve lié avec deux versions d'une même librairie et à la première occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
On dirait que tu n'as pas compris. Ca arrive parceque le programmeur utilise des librairies écrites par d'autres. Il n'a aucune raison d'aller voir ce que les autres ont fait et quelles librairies partagées eux mêmes utilisent. Si par hasard ça marche sur sa machine il ne s'aperçoit de rien, et bingo.
Si on a les sources, qu'est ce qui empêche de recompiler la bibliothèque partagée qui utilise la version de la bibliothèque dont on ne veut plus pour qu'elle utilise la bonne ? Si on n'a pas les sources, une entrée dans /etc/libmap.conf¹ devrait permettre de régler le problème.
¹ /etc/libmap.conf sous FreeBSD - il y a un truc similaire sous Linux, mais j'ai oublié son nom... -- Th. Thomas.
Samedi 18 mars 2006 à 08:57 GMT, Michel Talon a écrit :
Parceque, comme le dit l'article en question, que Michel Billaud a
certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un
programme peut très bien appeler 2 librairies partagées, chacune
desquelles pouvant appeler d'autres librairies partagées, en particulier
peut être deux versions différentes de la même! Dans le cas d'espèce je
crois que ça se produit avec ssl. Le résultat est que ton programme se
trouve lié avec deux versions d'une même librairie et à la première
occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
On dirait que tu n'as pas compris. Ca arrive parceque le programmeur utilise
des librairies écrites par d'autres. Il n'a aucune raison d'aller voir ce que
les autres ont fait et quelles librairies partagées eux mêmes utilisent. Si
par hasard ça marche sur sa machine il ne s'aperçoit de rien, et bingo.
Si on a les sources, qu'est ce qui empêche de recompiler la bibliothèque
partagée qui utilise la version de la bibliothèque dont on ne veut plus
pour qu'elle utilise la bonne ? Si on n'a pas les sources, une entrée
dans /etc/libmap.conf¹ devrait permettre de régler le problème.
¹ /etc/libmap.conf sous FreeBSD - il y a un truc similaire sous Linux,
mais j'ai oublié son nom...
--
Th. Thomas.
Samedi 18 mars 2006 à 08:57 GMT, Michel Talon a écrit :
Parceque, comme le dit l'article en question, que Michel Billaud a certainement lu, ce pourquoi il faisait des remarques subtiles sur gcc, un programme peut très bien appeler 2 librairies partagées, chacune desquelles pouvant appeler d'autres librairies partagées, en particulier peut être deux versions différentes de la même! Dans le cas d'espèce je crois que ça se produit avec ssl. Le résultat est que ton programme se trouve lié avec deux versions d'une même librairie et à la première occasion il crashe. Aucune recompilation ne te protège contre cette merde.
c'est bien ce qu'il disait : Parce qu'il a été écrit avec le pied gauche
pendant que le droit se tringlait la banane.
On dirait que tu n'as pas compris. Ca arrive parceque le programmeur utilise des librairies écrites par d'autres. Il n'a aucune raison d'aller voir ce que les autres ont fait et quelles librairies partagées eux mêmes utilisent. Si par hasard ça marche sur sa machine il ne s'aperçoit de rien, et bingo.
Si on a les sources, qu'est ce qui empêche de recompiler la bibliothèque partagée qui utilise la version de la bibliothèque dont on ne veut plus pour qu'elle utilise la bonne ? Si on n'a pas les sources, une entrée dans /etc/libmap.conf¹ devrait permettre de régler le problème.
¹ /etc/libmap.conf sous FreeBSD - il y a un truc similaire sous Linux, mais j'ai oublié son nom... -- Th. Thomas.
Nicolas George
Michel Talon, dans le message <dv8uhb$2c9u$, a écrit :
en particulier peut être deux versions différentes de la même!
Ça arrive, oui. Et c'est le signe que le système a été mal packagé. Une distribution correcte du système ne devrait pas permettre l'installation des paquets de développement dépendant de versions binairement incompatibles d'une même bibliothèque. La vérification systématique est d'ailleurs tout à fait possible.
Michel Talon, dans le message <dv8uhb$2c9u$1@asmodee.lpthe.jussieu.fr>,
a écrit :
en particulier peut être deux
versions différentes de la même!
Ça arrive, oui. Et c'est le signe que le système a été mal packagé. Une
distribution correcte du système ne devrait pas permettre l'installation des
paquets de développement dépendant de versions binairement incompatibles
d'une même bibliothèque. La vérification systématique est d'ailleurs tout à
fait possible.
Michel Talon, dans le message <dv8uhb$2c9u$, a écrit :
en particulier peut être deux versions différentes de la même!
Ça arrive, oui. Et c'est le signe que le système a été mal packagé. Une distribution correcte du système ne devrait pas permettre l'installation des paquets de développement dépendant de versions binairement incompatibles d'une même bibliothèque. La vérification systématique est d'ailleurs tout à fait possible.
talon
Nicolas George <nicolas$ wrote:
Michel Talon, dans le message <dv8uhb$2c9u$, a écrit :
en particulier peut être deux versions différentes de la même!
Ça arrive, oui. Et c'est le signe que le système a été mal packagé. Une distribution correcte du système ne devrait pas permettre l'installation des paquets de développement dépendant de versions binairement incompatibles d'une même bibliothèque. La vérification systématique est d'ailleurs tout à fait possible.
Nous sommes d'accord. Et ça prend combien d'années à Debian pour faire ce genre de vérifications systématiques? Et ne parlons pas du problème que l'article original mentionnait au sujet de python, plus précisément de la manière d'interfacer python et C qui change tout le temps. Résultat ça t'oblige à utiliser telle version de librairie à cause d'un programme, telle autre à cause d'un autre et le sac de noeuds se produit. Tout ça pour dire que le manque de stabilité et d'uniformité des interfaces a des effets *dévastateurs*, ce qui était tout le but de la discussion "pourquoi Windows réussit là où Linux échoue". D'un coté tu as un monopole qui impose une interface, stable depuis des années, bonne ou mauvaise importe peu, de l'autre une anarchie qui bouge tous les interfaces sans cesse comme un mouvement brownien pour se faire plaisir.
--
Michel TALON
Nicolas George <nicolas$george@salle-s.org> wrote:
Michel Talon, dans le message <dv8uhb$2c9u$1@asmodee.lpthe.jussieu.fr>,
a écrit :
en particulier peut être deux
versions différentes de la même!
Ça arrive, oui. Et c'est le signe que le système a été mal packagé. Une
distribution correcte du système ne devrait pas permettre l'installation des
paquets de développement dépendant de versions binairement incompatibles
d'une même bibliothèque. La vérification systématique est d'ailleurs tout à
fait possible.
Nous sommes d'accord. Et ça prend combien d'années à Debian pour faire ce
genre de vérifications systématiques? Et ne parlons pas du problème que
l'article original mentionnait au sujet de python, plus précisément de la
manière d'interfacer python et C qui change tout le temps. Résultat ça
t'oblige à utiliser telle version de librairie à cause d'un programme, telle
autre à cause d'un autre et le sac de noeuds se produit. Tout ça pour dire que
le manque de stabilité et d'uniformité des interfaces a des effets
*dévastateurs*, ce qui était tout le but de la discussion "pourquoi Windows
réussit là où Linux échoue". D'un coté tu as un monopole qui impose une
interface, stable depuis des années, bonne ou mauvaise importe peu, de l'autre
une anarchie qui bouge tous les interfaces sans cesse comme un mouvement
brownien pour se faire plaisir.
Michel Talon, dans le message <dv8uhb$2c9u$, a écrit :
en particulier peut être deux versions différentes de la même!
Ça arrive, oui. Et c'est le signe que le système a été mal packagé. Une distribution correcte du système ne devrait pas permettre l'installation des paquets de développement dépendant de versions binairement incompatibles d'une même bibliothèque. La vérification systématique est d'ailleurs tout à fait possible.
Nous sommes d'accord. Et ça prend combien d'années à Debian pour faire ce genre de vérifications systématiques? Et ne parlons pas du problème que l'article original mentionnait au sujet de python, plus précisément de la manière d'interfacer python et C qui change tout le temps. Résultat ça t'oblige à utiliser telle version de librairie à cause d'un programme, telle autre à cause d'un autre et le sac de noeuds se produit. Tout ça pour dire que le manque de stabilité et d'uniformité des interfaces a des effets *dévastateurs*, ce qui était tout le but de la discussion "pourquoi Windows réussit là où Linux échoue". D'un coté tu as un monopole qui impose une interface, stable depuis des années, bonne ou mauvaise importe peu, de l'autre une anarchie qui bouge tous les interfaces sans cesse comme un mouvement brownien pour se faire plaisir.
--
Michel TALON
Blaise Potard
MELI wrote:
Je suis dans Windows depuis 3.1, et il est vrai que de nombreux softs écrits voici bien longtemps fonctionne encore dans XP SP2.
De plus, sous Windows 2000, une simple manipulation du registre rajoutait les fonctionnalités d'émulation que l'on a eu dans XP...
Rien à dire. Les softs Windows bénéficient d'une sacrée longévité.
Bof. Comparés aux Macs, c'est *vraiment* pas grand chose. Je me souviens que MacPaint (une version de 1986 fournie avec MacOS 3.x, si je me souviens bien) fonctionnait toujours sur mon ibook G4 sous MacOS X, alors qu'il y a tout de même eu quelques légers changements (un changement complet d'archi et d'OS, quand même). Mais tout se perd : classic ne fonctionne apparemment plus avec MacOS X pour Intel, et donc on ne peut plus faire fonctionner les bonnes vieilles applis 68k.
Je suis un peu mal avec XP 64 bits: Il n'y a plus de support 16 bits, et même les softs 32 bits s'installant avec une routine 16 bits ne marchent pas...Mais XP 64, c'est un choix perso ;>))
Je n'ai jamais vu de soft qui ne marchaient pas sous SP2, il suffisait dans le pire des cas de virer le firewall
Gasp. Tu veux dire qu'en virant le firewall j'aurais pu faire marcher mon matériel utilisant le port firewire sans avoir à bidouiller dans la base de registre ? Tout bien considéré, c'est assez logique : il y a quand même 5 lettres en commun entre les deux !
MELI wrote:
Je suis dans Windows depuis 3.1, et il est vrai que de nombreux softs
écrits voici bien longtemps fonctionne encore dans XP SP2.
De plus, sous Windows 2000, une simple manipulation du registre
rajoutait les fonctionnalités d'émulation que l'on a eu dans XP...
Rien à dire. Les softs Windows bénéficient d'une sacrée longévité.
Bof. Comparés aux Macs, c'est *vraiment* pas grand chose. Je me souviens
que MacPaint (une version de 1986 fournie avec MacOS 3.x, si je me
souviens bien) fonctionnait toujours sur mon ibook G4 sous MacOS X,
alors qu'il y a tout de même eu quelques légers changements (un
changement complet d'archi et d'OS, quand même). Mais tout se perd :
classic ne fonctionne apparemment plus avec MacOS X pour Intel, et donc
on ne peut plus faire fonctionner les bonnes vieilles applis 68k.
Je suis un peu mal avec XP 64 bits: Il n'y a plus de support 16 bits, et
même les softs 32 bits s'installant avec une routine 16 bits ne marchent
pas...Mais XP 64, c'est un choix perso ;>))
Je n'ai jamais vu de soft qui ne marchaient pas sous SP2, il suffisait
dans le pire des cas de virer le firewall
Gasp. Tu veux dire qu'en virant le firewall j'aurais pu faire marcher
mon matériel utilisant le port firewire sans avoir à bidouiller dans
la base de registre ? Tout bien considéré, c'est assez logique : il y a
quand même 5 lettres en commun entre les deux !
Je suis dans Windows depuis 3.1, et il est vrai que de nombreux softs écrits voici bien longtemps fonctionne encore dans XP SP2.
De plus, sous Windows 2000, une simple manipulation du registre rajoutait les fonctionnalités d'émulation que l'on a eu dans XP...
Rien à dire. Les softs Windows bénéficient d'une sacrée longévité.
Bof. Comparés aux Macs, c'est *vraiment* pas grand chose. Je me souviens que MacPaint (une version de 1986 fournie avec MacOS 3.x, si je me souviens bien) fonctionnait toujours sur mon ibook G4 sous MacOS X, alors qu'il y a tout de même eu quelques légers changements (un changement complet d'archi et d'OS, quand même). Mais tout se perd : classic ne fonctionne apparemment plus avec MacOS X pour Intel, et donc on ne peut plus faire fonctionner les bonnes vieilles applis 68k.
Je suis un peu mal avec XP 64 bits: Il n'y a plus de support 16 bits, et même les softs 32 bits s'installant avec une routine 16 bits ne marchent pas...Mais XP 64, c'est un choix perso ;>))
Je n'ai jamais vu de soft qui ne marchaient pas sous SP2, il suffisait dans le pire des cas de virer le firewall
Gasp. Tu veux dire qu'en virant le firewall j'aurais pu faire marcher mon matériel utilisant le port firewire sans avoir à bidouiller dans la base de registre ? Tout bien considéré, c'est assez logique : il y a quand même 5 lettres en commun entre les deux !
Emmanuel Florac
Le Mon, 20 Mar 2006 19:08:05 +0100, Blaise Potard a écrit :
classic ne fonctionne apparemment plus avec MacOS X pour Intel, et donc on ne peut plus faire fonctionner les bonnes vieilles applis 68k.
Il reste Basilisk II.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Mon, 20 Mar 2006 19:08:05 +0100, Blaise Potard a écrit :
classic ne fonctionne apparemment plus avec MacOS X pour Intel, et donc
on ne peut plus faire fonctionner les bonnes vieilles applis 68k.
Il reste Basilisk II.
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Mon, 20 Mar 2006 19:08:05 +0100, Blaise Potard a écrit :
classic ne fonctionne apparemment plus avec MacOS X pour Intel, et donc on ne peut plus faire fonctionner les bonnes vieilles applis 68k.
Il reste Basilisk II.
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
sansflotusspam
MELI wrote:
Michel Talon a formulé la demande :
Je me permets de te rappeler que Win-3.1 utilisait encore des pointeurs de 16 bits, des "far pointers" et autres atrocités du même genre. Je n'ai jamais prétendu que les programmes tournant sur Win 3.1 étaient portables sans problème vers les versions récentes (quoi que quelqu'un a dit que oui, en ce qui concerne WinXP. Tout le monde sait que les vieux jeux ne passaient pas sous Win2000 et que le support de ces vieilleries a été amélioré dans WinXP). Ce que j'ai dit, et que tout le monde peut constater, c'est qu'on peut installer les mêmes programmes de Win98 à WinXP SP1, avec effectivement quelques problèmes pour le SP2. Ca veut dire grosso modo au moins de 1998 à 2004 et probablement nettement plus. Avec un Linux ou autre système libre la duréee de vie d'un programme est loin d'être aussi grande.
Mouai,
Je suis dans Windows depuis 3.1, et il est vrai que de nombreux softs écrits voici bien longtemps fonctionne encore dans XP SP2.
De plus, sous Windows 2000, une simple manipulation du registre rajoutait les fonctionnalités d'émulation que l'on a eu dans XP...
Rien à dire. Les softs Windows bénéficient d'une sacrée longévité.
Je suis un peu mal avec XP 64 bits: Il n'y a plus de support 16 bits, et même les softs 32 bits s'installant avec une routine 16 bits ne marchent pas...Mais XP 64, c'est un choix perso ;>))
Je n'ai jamais vu de soft qui ne marchaient pas sous SP2, il suffisait dans le pire des cas de virer le firewall
Tu en as de la chance ! quasiment tous le mois, je vois des clients virer XP pour revenir à win98, because leurs applis "métier" ne tournent pas sous XP !
MELI wrote:
Michel Talon a formulé la demande :
Je me permets de te rappeler que Win-3.1 utilisait encore des pointeurs
de 16 bits, des "far pointers" et autres atrocités du même genre. Je n'ai
jamais prétendu que les programmes tournant sur Win 3.1 étaient portables
sans problème vers les versions récentes (quoi que quelqu'un a dit que
oui, en ce qui concerne WinXP. Tout le monde sait que les vieux jeux ne
passaient pas sous Win2000 et que le support de ces vieilleries a été
amélioré dans WinXP). Ce que j'ai dit, et que tout le monde peut
constater, c'est qu'on peut installer les mêmes programmes de Win98 à
WinXP SP1, avec effectivement quelques problèmes pour le SP2. Ca veut
dire grosso modo au moins de 1998 à 2004 et probablement nettement plus.
Avec un Linux ou autre système libre la duréee de vie d'un programme est
loin d'être aussi grande.
Mouai,
Je suis dans Windows depuis 3.1, et il est vrai que de nombreux softs
écrits voici bien longtemps fonctionne encore dans XP SP2.
De plus, sous Windows 2000, une simple manipulation du registre
rajoutait les fonctionnalités d'émulation que l'on a eu dans XP...
Rien à dire. Les softs Windows bénéficient d'une sacrée longévité.
Je suis un peu mal avec XP 64 bits: Il n'y a plus de support 16 bits,
et même les softs 32 bits s'installant avec une routine 16 bits ne
marchent pas...Mais XP 64, c'est un choix perso ;>))
Je n'ai jamais vu de soft qui ne marchaient pas sous SP2, il suffisait
dans le pire des cas de virer le firewall
Tu en as de la chance !
quasiment tous le mois, je vois des clients virer XP pour revenir à win98,
because leurs applis "métier" ne tournent pas sous XP !
Je me permets de te rappeler que Win-3.1 utilisait encore des pointeurs de 16 bits, des "far pointers" et autres atrocités du même genre. Je n'ai jamais prétendu que les programmes tournant sur Win 3.1 étaient portables sans problème vers les versions récentes (quoi que quelqu'un a dit que oui, en ce qui concerne WinXP. Tout le monde sait que les vieux jeux ne passaient pas sous Win2000 et que le support de ces vieilleries a été amélioré dans WinXP). Ce que j'ai dit, et que tout le monde peut constater, c'est qu'on peut installer les mêmes programmes de Win98 à WinXP SP1, avec effectivement quelques problèmes pour le SP2. Ca veut dire grosso modo au moins de 1998 à 2004 et probablement nettement plus. Avec un Linux ou autre système libre la duréee de vie d'un programme est loin d'être aussi grande.
Mouai,
Je suis dans Windows depuis 3.1, et il est vrai que de nombreux softs écrits voici bien longtemps fonctionne encore dans XP SP2.
De plus, sous Windows 2000, une simple manipulation du registre rajoutait les fonctionnalités d'émulation que l'on a eu dans XP...
Rien à dire. Les softs Windows bénéficient d'une sacrée longévité.
Je suis un peu mal avec XP 64 bits: Il n'y a plus de support 16 bits, et même les softs 32 bits s'installant avec une routine 16 bits ne marchent pas...Mais XP 64, c'est un choix perso ;>))
Je n'ai jamais vu de soft qui ne marchaient pas sous SP2, il suffisait dans le pire des cas de virer le firewall
Tu en as de la chance ! quasiment tous le mois, je vois des clients virer XP pour revenir à win98, because leurs applis "métier" ne tournent pas sous XP !
