Les problèmes qui sont liés à l'endianness sont aussi présents
en langage C, et tous les langages de haut niveau. Pas seulement
en assembleur (langage machine).
En plus, il y a des OS, comme NetBSD, qui sont stables sur Intel et
d'autres CPU.
Probablement, je n'ai pas testé ... Mais il me semble que ces
systèmes ont un format d'exécutable qui ne correspond pas au
langage machine du processeur. Il y a un code intermédiaire non ?
L'évolution (x86) risque de faire apparaître des problèmes certains
de stabilité de MacOSX ... J'en ai bien peur !
Moi pas vraiment.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au monde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
Les problèmes qui sont liés à l'endianness sont aussi présents
en langage C, et tous les langages de haut niveau. Pas seulement
en assembleur (langage machine).
En plus, il y a des OS, comme NetBSD, qui sont stables sur Intel et
d'autres CPU.
Probablement, je n'ai pas testé ... Mais il me semble que ces
systèmes ont un format d'exécutable qui ne correspond pas au
langage machine du processeur. Il y a un code intermédiaire non ?
L'évolution (x86) risque de faire apparaître des problèmes certains
de stabilité de MacOSX ... J'en ai bien peur !
Moi pas vraiment.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au monde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
Les problèmes qui sont liés à l'endianness sont aussi présents
en langage C, et tous les langages de haut niveau. Pas seulement
en assembleur (langage machine).
En plus, il y a des OS, comme NetBSD, qui sont stables sur Intel et
d'autres CPU.
Probablement, je n'ai pas testé ... Mais il me semble que ces
systèmes ont un format d'exécutable qui ne correspond pas au
langage machine du processeur. Il y a un code intermédiaire non ?
L'évolution (x86) risque de faire apparaître des problèmes certains
de stabilité de MacOSX ... J'en ai bien peur !
Moi pas vraiment.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au monde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
Ce que je me demandais c'est si cette puce ViiV est la même chose ou
presque que la puce Fritz qui en plus de controler les DRM pouvait aussi
empécher le lancement d'applications "interdites".
Ce que je me demandais c'est si cette puce ViiV est la même chose ou
presque que la puce Fritz qui en plus de controler les DRM pouvait aussi
empécher le lancement d'applications "interdites".
Ce que je me demandais c'est si cette puce ViiV est la même chose ou
presque que la puce Fritz qui en plus de controler les DRM pouvait aussi
empécher le lancement d'applications "interdites".
Les problèmes qui sont liés à l'endianness sont aussi présents
en langage C, et tous les langages de haut niveau. Pas seulement
en assembleur (langage machine).
Mais généralement on programme avec des types 32-bit, comme "int" o u
"chose *". On ne touche presque jamais les bytes individuels, alors on
ne sait presque pas si la machine est big- ou little endian. ;)
En plus, il y a des OS, comme NetBSD, qui sont stables sur Intel et
d'autres CPU.
Probablement, je n'ai pas testé ... Mais il me semble que ces
systèmes ont un format d'exécutable qui ne correspond pas au
langage machine du processeur. Il y a un code intermédiaire non ?
NetBSD ressemble à Linux. Tout le système est écrit en C et asse mbleur.
Chaque système a des routines particulières, mais tous possèdent les
même noyau et drivers.
L'évolution (x86) risque de faire apparaître des problèmes cer tains
de stabilité de MacOSX ... J'en ai bien peur !
Moi pas vraiment.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au m onde
a définitivement échoué ...
Où est-ce qu'elle a échoué ? Aux adaptations de Windows pour d'a utres
machines, ou à la stabilité ? Pour la première chose, il n'y ava it pas
assez d'interessés, et la seconde s'a amélioré beaucoup.
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
Hé, c'est assez amusant :)
Les problèmes qui sont liés à l'endianness sont aussi présents
en langage C, et tous les langages de haut niveau. Pas seulement
en assembleur (langage machine).
Mais généralement on programme avec des types 32-bit, comme "int" o u
"chose *". On ne touche presque jamais les bytes individuels, alors on
ne sait presque pas si la machine est big- ou little endian. ;)
En plus, il y a des OS, comme NetBSD, qui sont stables sur Intel et
d'autres CPU.
Probablement, je n'ai pas testé ... Mais il me semble que ces
systèmes ont un format d'exécutable qui ne correspond pas au
langage machine du processeur. Il y a un code intermédiaire non ?
NetBSD ressemble à Linux. Tout le système est écrit en C et asse mbleur.
Chaque système a des routines particulières, mais tous possèdent les
même noyau et drivers.
L'évolution (x86) risque de faire apparaître des problèmes cer tains
de stabilité de MacOSX ... J'en ai bien peur !
Moi pas vraiment.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au m onde
a définitivement échoué ...
Où est-ce qu'elle a échoué ? Aux adaptations de Windows pour d'a utres
machines, ou à la stabilité ? Pour la première chose, il n'y ava it pas
assez d'interessés, et la seconde s'a amélioré beaucoup.
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
Hé, c'est assez amusant :)
Les problèmes qui sont liés à l'endianness sont aussi présents
en langage C, et tous les langages de haut niveau. Pas seulement
en assembleur (langage machine).
Mais généralement on programme avec des types 32-bit, comme "int" o u
"chose *". On ne touche presque jamais les bytes individuels, alors on
ne sait presque pas si la machine est big- ou little endian. ;)
En plus, il y a des OS, comme NetBSD, qui sont stables sur Intel et
d'autres CPU.
Probablement, je n'ai pas testé ... Mais il me semble que ces
systèmes ont un format d'exécutable qui ne correspond pas au
langage machine du processeur. Il y a un code intermédiaire non ?
NetBSD ressemble à Linux. Tout le système est écrit en C et asse mbleur.
Chaque système a des routines particulières, mais tous possèdent les
même noyau et drivers.
L'évolution (x86) risque de faire apparaître des problèmes cer tains
de stabilité de MacOSX ... J'en ai bien peur !
Moi pas vraiment.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au m onde
a définitivement échoué ...
Où est-ce qu'elle a échoué ? Aux adaptations de Windows pour d'a utres
machines, ou à la stabilité ? Pour la première chose, il n'y ava it pas
assez d'interessés, et la seconde s'a amélioré beaucoup.
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
Hé, c'est assez amusant :)
Quand je parle de code intermédiaire, c'est qu'il me semble que les
binaires avec BSD sont portables d'une plateforme à une autre (x86,
PPC ...) car il y a une couche d'abstraction ... C'est ce que j'ai
compris ... C'est une manière élégante de contourner le problème.
Quand je parle de code intermédiaire, c'est qu'il me semble que les
binaires avec BSD sont portables d'une plateforme à une autre (x86,
PPC ...) car il y a une couche d'abstraction ... C'est ce que j'ai
compris ... C'est une manière élégante de contourner le problème.
Quand je parle de code intermédiaire, c'est qu'il me semble que les
binaires avec BSD sont portables d'une plateforme à une autre (x86,
PPC ...) car il y a une couche d'abstraction ... C'est ce que j'ai
compris ... C'est une manière élégante de contourner le problème.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au monde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au monde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au monde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
Quand je parle de code intermédiaire, c'est qu'il me semble que les
binaires avec BSD sont portables d'une plateforme à une autre (x86,
PPC ...) car il y a une couche d'abstraction ... C'est ce que j'ai
compris ... C'est une manière élégante de contourner le problèm e.
Non. J'administre des machines sous Linux et les diverses variantes de
BSD (Open, Net), et tout est compilé en natif (d'ailleurs sur toutes ces
plateformes, c'est gcc qui est généralement utilisé).
BSD et *nix en général permet une compatibilité/portabilité au niveau
*source*, pas au niveau *binaire*.
Et je rejoint Ulrich sur le fait que l'endianisme ne pose généralem ent
pas de problème, même en C/C++. Et quand il est nécessaire d'alle r
"bidouiller" directement des octets ou des mots de plusieurs octets,
tout code source bien écrit fait appel a des "librairies" standards o u
personnelles qui elles seulent devront être adaptées pour tenir com pte
de l'architecture (cf. les "ntoh" et "hton" en ce qui concerne la
programmation socket)...
Quand je parle de code intermédiaire, c'est qu'il me semble que les
binaires avec BSD sont portables d'une plateforme à une autre (x86,
PPC ...) car il y a une couche d'abstraction ... C'est ce que j'ai
compris ... C'est une manière élégante de contourner le problèm e.
Non. J'administre des machines sous Linux et les diverses variantes de
BSD (Open, Net), et tout est compilé en natif (d'ailleurs sur toutes ces
plateformes, c'est gcc qui est généralement utilisé).
BSD et *nix en général permet une compatibilité/portabilité au niveau
*source*, pas au niveau *binaire*.
Et je rejoint Ulrich sur le fait que l'endianisme ne pose généralem ent
pas de problème, même en C/C++. Et quand il est nécessaire d'alle r
"bidouiller" directement des octets ou des mots de plusieurs octets,
tout code source bien écrit fait appel a des "librairies" standards o u
personnelles qui elles seulent devront être adaptées pour tenir com pte
de l'architecture (cf. les "ntoh" et "hton" en ce qui concerne la
programmation socket)...
Quand je parle de code intermédiaire, c'est qu'il me semble que les
binaires avec BSD sont portables d'une plateforme à une autre (x86,
PPC ...) car il y a une couche d'abstraction ... C'est ce que j'ai
compris ... C'est une manière élégante de contourner le problèm e.
Non. J'administre des machines sous Linux et les diverses variantes de
BSD (Open, Net), et tout est compilé en natif (d'ailleurs sur toutes ces
plateformes, c'est gcc qui est généralement utilisé).
BSD et *nix en général permet une compatibilité/portabilité au niveau
*source*, pas au niveau *binaire*.
Et je rejoint Ulrich sur le fait que l'endianisme ne pose généralem ent
pas de problème, même en C/C++. Et quand il est nécessaire d'alle r
"bidouiller" directement des octets ou des mots de plusieurs octets,
tout code source bien écrit fait appel a des "librairies" standards o u
personnelles qui elles seulent devront être adaptées pour tenir com pte
de l'architecture (cf. les "ntoh" et "hton" en ce qui concerne la
programmation socket)...
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au m onde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
D'un : La stratégie MS consiste à faire du fric et non à sortir d es
produits stables.
De deux : La stratégie MS consiste à ajouter des fonctionnalités (c'est
vendeur) sans [presque] jamais améliorer ou corriger l'existant (qui
paierait pour du vieux ?).
Regarde par exemple l'état lamentable dans lequel a été abandonné le
MS-DOS, comparé aux capacités du bash de l'époque.
Un autre problème est la structure de validation d'une idée.
Chez MS, un chef peut facilement faire passer une idée à la con alo rs
qu'un developpeur subalterne ne sera probablement pas écouté, mêm e si
son idée est meilleure. Sur linux, le meilleur code a des chances d'ê tre
adopté, quel que soit son origine.
Chez Apple, c'est un peu différent mais au moins c'est plus dynamique
que chez MS et les bases sont saines.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au m onde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
D'un : La stratégie MS consiste à faire du fric et non à sortir d es
produits stables.
De deux : La stratégie MS consiste à ajouter des fonctionnalités (c'est
vendeur) sans [presque] jamais améliorer ou corriger l'existant (qui
paierait pour du vieux ?).
Regarde par exemple l'état lamentable dans lequel a été abandonné le
MS-DOS, comparé aux capacités du bash de l'époque.
Un autre problème est la structure de validation d'une idée.
Chez MS, un chef peut facilement faire passer une idée à la con alo rs
qu'un developpeur subalterne ne sera probablement pas écouté, mêm e si
son idée est meilleure. Sur linux, le meilleur code a des chances d'ê tre
adopté, quel que soit son origine.
Chez Apple, c'est un peu différent mais au moins c'est plus dynamique
que chez MS et les bases sont saines.
En fait, je ne peux pas comprendre comment MacOSX (ou Linux)
réussirait, là où la société informatique la plus riche au m onde
a définitivement échoué ...
Surtout que la stratégie de la société en question consiste à
migrer ses machines de jeux vers des processeurs PPC ...
D'un : La stratégie MS consiste à faire du fric et non à sortir d es
produits stables.
De deux : La stratégie MS consiste à ajouter des fonctionnalités (c'est
vendeur) sans [presque] jamais améliorer ou corriger l'existant (qui
paierait pour du vieux ?).
Regarde par exemple l'état lamentable dans lequel a été abandonné le
MS-DOS, comparé aux capacités du bash de l'époque.
Un autre problème est la structure de validation d'une idée.
Chez MS, un chef peut facilement faire passer une idée à la con alo rs
qu'un developpeur subalterne ne sera probablement pas écouté, mêm e si
son idée est meilleure. Sur linux, le meilleur code a des chances d'ê tre
adopté, quel que soit son origine.
Chez Apple, c'est un peu différent mais au moins c'est plus dynamique
que chez MS et les bases sont saines.
Bah quand même ! La plateforme tient plus à des avantages liés à la qualité
de l'OS, alors si windows rattrape Mac OS, ne pensez-vous pas que ça peut
refaire le coup de Windows 95 ???
Bah quand même ! La plateforme tient plus à des avantages liés à la qualité
de l'OS, alors si windows rattrape Mac OS, ne pensez-vous pas que ça peut
refaire le coup de Windows 95 ???
Bah quand même ! La plateforme tient plus à des avantages liés à la qualité
de l'OS, alors si windows rattrape Mac OS, ne pensez-vous pas que ça peut
refaire le coup de Windows 95 ???
