Non, mais ça n'a rien à voir. Le fait est que Windows 9X n'était pas juste une couche au dessus de MS-DOS (Windows 3.X non plus d'ailleurs), mais un vrai OS avec son propre kernel, ses propres APIs et applications, et un modèle d'accès préemeptif pour les application Win32 (collaboratif pour les applications Win16 et MS-DOS), point.
Il y a eu beaucoup de marketing,
Le marketing mensonger, c'est dire que Windows 9X n'était qu'un shell pour DOS, ce qui est totalement faux.
et il a fallu attendre Win95 OSR2 pour que le système de fichiers accepte sans manipulation hasardeuse les noms de fichiers longs.
Jusqu'à Win 3.x, c'était une surcouche graphique de MS-DOS.
Encore faux. Windows 3.X disposait déjà de son propre kernel, APIs, applications, modèle mémoire, etc... C'était un OS à part entière, comme Windows 9X, dont MS-DOS n'était plus qu'un composant dont le rôle était de plus en plus diminué au fil des versions.
Ça a commencé à changer par la suite. Mais la branche Windows 4.x (en clair les 9x et Millenium), il ne pouvait pas démarrer sans un DOS en dessous.
D'ailleurs, essaie d'exécuter une application utilisant Windows sous DOS, tu auras ceci (qui fait parti du header de n'importe quelle PE/EXE compilé pour Windows) :
This Program Cannot Be Run in DOS Mode
Et t'as DirectX sous DOS ? Un modèle mémoire unifié ? Non, rien de tout ça.
Mais le mélange 16 bits (de DOS) et 32 bits (de Windows), côté stabilité, bof, quoi !
C'est soit ça, soit tu exiges de tout le monde d'acheter plein de mémoire pour faire fonctionner ton nouvel OS qui va tout déchirer (la mémoire en 1995, ça coûte un bras). Si personne ou presque ne peut exécuter ton OS, bah c'est de l'argent jeté par les fenêtres au final...
Windows 9X a assuré la transition. Oui il plantait souvent à cause du modèle collaboratif sans protection mémoire - mais très léger en usage mémoire - pour les application Win16/MS-DOS (et parfois à cause de pilotes écrits avec les pieds).
(enfin du moment qu'on se limitait à des application Win32 ça allait :) )
Mais en contrepartie, il pouvait fonctionner avec 8 Mo de mémoire (ce qui n'était pas le cas de Windows NT. NT 4 Workstation exigera d'ailleurs, en 1996, 64 Mo de mémoire pour s'installer !)
La gestion mémoire des PCs à l'époque, quelle joie... J'en frissonne encore d'horreur :(
Ceci n'était valable que pour MS-DOS. Bon à la limite avec Win16 aussi (et ses fameuses ressources "USER" et "SYSTEME". Tôt ou tard une application Win16 oubliait de libérer la mémoire, et il fallait redémarrer pour en exécuter d'autres... Le sous-système Win16 de la lignée NT - absent des versions 64 bits par manque d'intérêt pour le porter - règle ce problème en utilisant une VM, et la mémoire virtuelle rapporte toujours à l'application Win16 qu'elle a 100% des ressources USER et SYSTEM disponibles. :) )
Pour la popularité d'un OS, c'est plus un truc de technophile qu'autre chose. Faut rester réaliste.
Il n'empêche que personne n'utilise Hurd en partie parce que ... personne n'utilise Hurd (kernel au stade de alpha depuis 20 ans, support matériel très en retard par rapport à Linux). Donc oui, la popularité ça compte (+ de contributions, etc...)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: T'en veux pas, tu l'installes pas Windows 10 bordel.
Posté par xcomcmdr . En réponse à la dépêche Lettre ouverte de Mozilla au CEO de Microsoft. Évalué à 4. Dernière modification le 06 août 2015 à 14:05.
Non, mais ça n'a rien à voir. Le fait est que Windows 9X n'était pas juste une couche au dessus de MS-DOS (Windows 3.X non plus d'ailleurs), mais un vrai OS avec son propre kernel, ses propres APIs et applications, et un modèle d'accès préemeptif pour les application Win32 (collaboratif pour les applications Win16 et MS-DOS), point.
Le marketing mensonger, c'est dire que Windows 9X n'était qu'un shell pour DOS, ce qui est totalement faux.
En fait, il a fallu attendre FAT32 ET Win95 OSR2, surtout. Les noms longs étaient pris en charge au prix d'une bidouille d'ingénierie logicielle horrible, d'ailleurs.
Encore faux. Windows 3.X disposait déjà de son propre kernel, APIs, applications, modèle mémoire, etc... C'était un OS à part entière, comme Windows 9X, dont MS-DOS n'était plus qu'un composant dont le rôle était de plus en plus diminué au fil des versions.
MS-DOS était certes le bootloader sous 9X/ME, mais pas grand chose de plus. Le véritable système d'exploitation, une fois Windows démarré, c'était Windows.
D'ailleurs, essaie d'exécuter une application utilisant Windows sous DOS, tu auras ceci (qui fait parti du header de n'importe quelle PE/EXE compilé pour Windows) :
Et t'as DirectX sous DOS ? Un modèle mémoire unifié ? Non, rien de tout ça.
C'est soit ça, soit tu exiges de tout le monde d'acheter plein de mémoire pour faire fonctionner ton nouvel OS qui va tout déchirer (la mémoire en 1995, ça coûte un bras). Si personne ou presque ne peut exécuter ton OS, bah c'est de l'argent jeté par les fenêtres au final...
Windows 9X a assuré la transition. Oui il plantait souvent à cause du modèle collaboratif sans protection mémoire - mais très léger en usage mémoire - pour les application Win16/MS-DOS (et parfois à cause de pilotes écrits avec les pieds).
(enfin du moment qu'on se limitait à des application Win32 ça allait :) )
Mais en contrepartie, il pouvait fonctionner avec 8 Mo de mémoire (ce qui n'était pas le cas de Windows NT. NT 4 Workstation exigera d'ailleurs, en 1996, 64 Mo de mémoire pour s'installer !)
Ceci n'était valable que pour MS-DOS. Bon à la limite avec Win16 aussi (et ses fameuses ressources "USER" et "SYSTEME". Tôt ou tard une application Win16 oubliait de libérer la mémoire, et il fallait redémarrer pour en exécuter d'autres... Le sous-système Win16 de la lignée NT - absent des versions 64 bits par manque d'intérêt pour le porter - règle ce problème en utilisant une VM, et la mémoire virtuelle rapporte toujours à l'application Win16 qu'elle a 100% des ressources USER et SYSTEM disponibles. :) )
Il n'empêche que personne n'utilise Hurd en partie parce que ... personne n'utilise Hurd (kernel au stade de alpha depuis 20 ans, support matériel très en retard par rapport à Linux). Donc oui, la popularité ça compte (+ de contributions, etc...)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)