Win3x.Org

Un conseil, dans l'avenir si tu veux lancer du DOS, utilise un emulateur genre Dosbox. Il n'y a pas que le processeur qui compte, l'archi aussi. Certes aujourd'hui les CPU intel savent encore exécuter du legacy 16bits, mais le reste du matériel n'a plus rien a voir. Plus de BUS ISA, plus de IDE, plus de BIOS sur certaines machines et surtout plus les mêmes classes de composants. Donc oui ton CPU pourra calculer avec du code 16bits mais pas communiquer avec les périphériques. En plus a terme le support 16bits est voue a disparaitre donc autant utiliser un emulateur/virtualiseur qui va émuler une architecture complète d'époque. Carte graphique d'époque, port serie, //, carte son d'époque.

tombcore a écrit :

(pour ceux qui savent pas, Unix et C ça vient du même homme)

Non UNIX c'est Ken Thompson et "C" c'est Dennis Ritchie.
Par contre et là tu as raison, Ken a commencé UNIX en utilisant un dérivé de BCPL qu'il avait inventé et qui s'appelait B, et qui en fait était une sorte de meta assembleur PDP. Ritchie a repris B et a produit C. Ensuite quand la notoriété d'Unix s'est accrue d'autres personnes ont réécrit UNIX en C.

Je tire mes info du souvenir de la lecture du "Bell system laboratories Journal" mais sur Wikipedia Français la présentation est légèrement différente et me semble un peu divergente:
http://fr.wikipedia.org/wiki/UNIX#La_ge ... e_d.27UNIX
Version Anglaise où il n'y a pas de mention de TMG.:
http://en.wikipedia.org/wiki/Unix#History

TOut a fait Linux For ever ^^
Sur le même laptop j'ai mit Windows 2000 Professionnal SP4
et sur une autre partoche Linux Kubuntu ^^ Mais ca ram a mort faudrais que je trouve des vieilles barettes de ram SDRAM pour mon ptit pc histoire de monter jusu'a 256Mo voir 512 ^^

Utilise kubuntu ou même une distrib vraiment lite. Après tout est dans le nombre de processus lancée. Sur mon eeepc j'ai une configuration gnome de base : 80 mega de ram au lancement, je pourais faire moins en changent de WM mais pas envie de changer les bonnes habitudes. Avec un XFCE sous ubuntu j'étais descendu jusqu'à 45 mega sur le bureau, avec XP, 43Mega :):)

Après il faut savoir que Ubuntu est compilé avec un max d'options ce qui veux dire que la même appli, sur une distrib lite pourra peser beaucoup moins.

Exemple : Htop sur ubuntu 2472Ko
Htop sur distrib perso basée uClibc : ~/500Kilo
Même version, même code juste la dépendance en lib qui change. Si ton pc a genre 64 mega de RAM, passe a Damn Small Linux ça va tracer (comme w95 en gros mais avec des logiciels récents)

Sinon (X/K)ubuntu c'est très bien grand public pas prise de tête, ...

ouit j'ai kubuntu (kde) la dernière version.
Sauf qu'il faut que je commande le cd et le reinstall car installer depuis Windows...
Enfin bref...
X est plus lourd ou moins lourd que kde ?
(je ne m'y connais pas trop en Linux je suis un débutant a Linuxland ^^)

A ma connaissance, KDE utilise X. Tu dois confondre Gnome et X.

X est le programme qui permet l'affichage de 'fenêtre' sur la carte vidéo alors que Gnome et KDE sont des programmes qui 'remplissent' ces fenêtres.
C'est simpliste mais vrai. X permet l'accès au matériel et gère les fenêtres mais c'est gnome ou kde qui demande a X de créer les fenêtres et de les remplir, en d'autre terme de former le bureau.

X gère le fonctionnement bas niveau, et Gnome l'interface utilisateur.

Pour une analogie sous windows : Noyau + csrss.exe + les dll qui vont avec (win32, ...) gère le bas niveau, le fait de pouvoir afficher une fenetre et autre, et Explorer.exe utilise l'API win32 pour creer l'interface.

Donc, on peux faire l'analogie :
X <=> Noyau + Api win32
Gnome, Kde, XFCE, Icevm,... <=> Explorer.exe

Architecture graphique de Windows NT : (image retirée du serveur MS)

De même il est possible d'utiliser KDE sous windows pour remplacer le explorer.exe

un shell linux sous win trop classe

cygwin, powershell

gm86 a écrit :

Je me alors deux questions :
A-t-on toujours affaire à de « vrais PC » compatibles 16 bits où on peut lancer le sytème avec une disquette DOS ?

La réponse est oui, du moment que tu trouves une disquette encore vivante et que ton PC dispose d'un lecteur de disquettes. Quant aux carte mères, elles ont encore, le plus souvent, un contrôleur de lecteur de disquettes compatible avec les premiers PC. Même les BIOS sont compatibles avec ceux de l'IBM PC. C'est marrant pour les claviers PS/2 dont les scan codes sont convertis des codes "AT" vers les codes "XT", logiciellement, par le BIOS. Certains BIOS supportent aussi les claviers USB. Les disques durs, qu'ils soient PATA ou SATA ou même les clés USB, peuvent être exposés, par le BIOS, comme les disques de l'IBM AT. Par contre, les OS accédant directement au matériel auront besoin des pilotes appropriés (par exemple, les vieux OS comme Win95 n'ont pas, par défaut, de pilotes pour dd SATA, quoique Win95 peut toujours recourir à l'accès par le BIOS, malheureusement très lent).
Un PC moderne 64 bits, démarre toujours en mode réel 16 bits, avec un adressage limité à 1Mo de RAM. Si on active la ligne A20 on peut gagner 64K-16 octets.
On peut toujours exécuter un OS 16 bits en mode réel, ou un OS en mode protégé 16 bits.
On peut aussi utiliser un OS 32 bits comme Windows 95, qui gère à la fois des segments 16 et 32 bits en mode protégé, ainsi que du Virtual86 et il peut même repasser en mode réel pour certaines opérations.

J'ai un Athlon 64 sur lequel j'ai déja démarré MS-DOS en mode réel, sans problème.
Par contre, là où le bas blesse, c'est que pour bénéficier du mode 64 bits, les OS doivent passer dans un nouveau mode du processeur (le mode LONG), dans lequel il est facile de faire coopérer des segments 64 bits et 32 bits, mais dans lequel les segments 16 bits de code ne peuvent être directement accessible à partir du code 64 bits, car il n'existe pas de call gates pour sauter d'un segment 64 bits à un segment 16 bits (pour un programme Windows 3.x). Je suppose que l'on doit quand même pouvoir exécuter du code 16 bits en passant par l'intermédiaire d'un segment 32 bits, mais ça doit ralentir considérablement l'exécution, et puis il y a peut-être des problèmes de gestion des interruptions matérielles. Quant au Virtual86 (pour les applications MS-DOS) il n'est pas supporté en mode LONG.

Citation :

Vu que les ordinateurs 32 bits ont longtemps continué à faire tourner des applications 16 bits, pensez-vous, par analogie, que les logiciels 64 bits resteront rares ?

ça dépend de l'OS.
Linux a vite migré au 64 bits, puisqu'il suffit de recompiler, avec des correctifs mineurs, toutes les applications open source. Quelques grosses bouses commerciales, comme Flash Player ont longtemps posé problème.
Quant à Windows, la migration sera beaucoup plus lente, puisqu'il s'agit d'une plateforme vivant principalement sur des binaires.
Même si les nouvelles applications peuvent être 64 bits, les anciennes resteront pour toujours 32 bits.
Je considère qu'il s'est déja écoulé beaucoup de temps (environ 5 ans) entre l'apparition des premiers x86-64 et maintenant, et il y a encore beaucoup de logiciels actuels 32 bits.
Il faut aussi prendre en compte le fait que le nombre de logiciels 16 bits, était déja énorme au temps des premiers OS Win32 (Windows NT 3.x, puis Windows 95), mais, pour le 32 bits, ce chiffre est encore plus gigantesque.
Mais, seul l'avenir nous dira.