[mOved] [F] Votre bureau » Windows 8 - Page 19

Je pense c'est un bug, ce type a l'air d'avoir le même soucis : http://superuser.com/questions/398015/how-to-disable-windows-8-lock-screen

Faudrait que je soumette ça quelque part.

Gniiiiiihihihiihiihihihihih… J'ai décidé de réinstaller Windows 8, mais dans une VM cette fois, histoire de pas péter mon installation de Windows 7 actuelle.

Première étape : télécharger l'ISO de Windows 8. Indiquer la clé que j'ai achetée tout seul comme un grand quand elle n'était pas chère. L'ISO se télécharge. Enfin, les fichiers relatifs à l'installation de Windows 8. Parce que pour en faire un ISO, il faut sélectionner l'option « Installer à partir d'un média ». Voilà pour la première partie.
Deuxième étape : télécharger VirtualBox, allouer 4 Go de RAM, utiliser l'accélération matérielle, démarrer à partir de l'ISO et roulaize.
L'installation se passe correctement, et en trois quarts d'heure j'atterris… directement sur le bureau de Windows 8. Ah. Bon, pas grave, je commence déjà à personnaliser le peu auquel j'ai droit. Et là, c'est le drame. Je ne peux personnaliser que si Windows est activé. C'est bien.
Via Modern UI, Windows jette ma clé sans autre forme de procès. En passant par le bureau, j'obtiens le splendide code 0xC004F061 qui me dit que ce Windows a été installé à partir du CD, et pas à partir d'un Windows 7. Des envies de meurtre commencent à naître.

Ni une, ni deux, je « formate » le disque dur virtuel, et j'installe un Windows 7 SP1 à l'arrache. Puis je recommence l'installation depuis Windows 7. Clé OK, un redémarrage à la mano s'avère nécessaire, je suis sous Windows 8 une demi-heure plus tard, pas besoin d'activer le Windows 7 de passage.
Puis vient l'activation Windows. « Ce Windows est déjà installé sur un autre PC. » Non, il ÉTAIT installé, je suis revenu à Windows 7 depuis. Krosoft aurait fait en sorte qu'une machine a une licence immuable ? Heureusement, il existe une commande qui peut sauver la vie : « slui 4 », qui est l'assistant d'activation par téléphone. Alors, oui, c'est casse-burnes, on se croirait revenu au temps de Windows XP, mais quoi qu'il en soit, j'ai enfin réussi à transférer ma licence d'une machine réelle à ma machine virtuelle. La faute aux machines de confiance liées au compte Microsoft Live. Ou comment transformer une formalité en parcours chaotique cahotique, du Krosoft tout craché.

Pour faire simple, le but que je recherche, c'est : « Est-ce qu'un Windows 8 qui a hiberné pendant 6 mois est-il utilisable sans trop de saletés de mise à jour et d'incompatibilités ? »

[edit 1] : bon, je récupère quelques applications sur le Windows Store, qui est très long à s'ouvrir la première fois. Je récupère une application que je croyais être Bing Maps mais en fait non. Donc j'annule l'installation via le menu contextuel qui s'affiche en bas de l'écran. Un quart d'heure plus tard, W8 me dit que l'application a été correctement installée

Pardon, mais c'est drôle, en tout cas ta manière de raconter. Je t'imagine trop bien avec le furaxomètre à ras bord derrière ta machine

(me dis pas que ce sont mes périgrinations avec ma VM qui sont à la base de tes malheurs quand même )

Folco (./543) :
Pardon, mais c'est drôle, en tout cas ta manière de raconter. Je t'imagine trop bien avec le furaxomètre à ras bord derrière ta machine

Non, je fulmine pas, je suis juste comme cette personne bavarde à droite :

Folco (./543) :
(me dis pas que ce sont mes périgrinations avec ma VM qui sont à la base de tes malheurs quand même )

Hum, je ne pense pas

Moi ce qui me soûle bien c'est que je dois complètement réinstaller ma VM en 64 bits pour pouvoir installer le SDK Windows Phone 8. J'avais mis la version 32 bits initialement parce que ça prenait moins de place sur le DD & RAM & de temps à télécharger & installer, mais en fait y a juste rien à faire, le SDK ne tourne QUE sous Windows 8, en 64 teubs. Assez insupportable.

On se croirait chez Apple

Plutôt oui (enfin Apple n'a même pas de version 32 c'est réglé au moins )

MS est de pire en pire...

Je comprends pas trop le coup du SDK qui ne fonctionne qu'en 64 bits alros que la plupart des outils de développement Microsoft n'ont toujours pas été portés en x64… 
Ils ont vraiment du faire n'imp…

(./545 > Si tu trouves la réponse dans ta VM 64 bits, je veux bien la connaître ^^)

Mmmmh je trouve pas ça déconnant d'avoir besoin d'un OS qui supporte plus (64 et 32) pour faire du développement.
Après comme dit en ./548, le top est encore une fois... de ne pas avoir le choix. Quel est l'intérêt en 2012 de sortir un OS 32 bits? (utiliser moins de disque et de ram? Bah vaudrait mieux optimiser la grosse mouture que faire 2 optims parallèles...)
La transition en 64 bits chez Apple, je l'ai vécu sans le voir.
Chez crosoft, c'est des installs en plus, des isos dans tous les coins, le support de 3GO qui n'y est pas en 32bits, etc.

redangel (./551) :
Mmmmh je trouve pas ça déconnant d'avoir besoin d'un OS qui supporte plus (64 et 32) pour faire du développement.

Ouep, sur le principe je suis tout à fait d'accord. Si tu es développeurs pour une plateforme moderne (c'est le cas de WP8 et WinRT), tu devrais sans nul doute développer sur une config x64, ce qui te permettrai de tester la plupart des configurations PC standard. Mais si tu développes pour WP8 (ARM, donc…) je ne vois pas l'intérêt du CPU x64 là dedans

Après comme dit en ./548, le top est encore une fois... de ne pas avoir le choix.

Les clients (certains) de Microsoft ne pensent pas comme toi ^^
Les clients Apple sont habitués à suivre en étant souvent ignorés. (Au final ça marche quand même ! )

Quel est l'intérêt en 2012 de sortir un OS 32 bits?

Ben je suppose que tu sais que par souci de simplicité, les applications 16 bits ne peuvent tourner que sur un OS Win32 natif 32 bits. D'autre part c'est quasi impossible (comprendre méga relou) d'installer des drivers non signés sur un Windows 64 bits.
En ce sens, le Windows 32 bits est un Windows "plus traditionnel" et sert ainsi les frileux qui on peur de migrer aux 64 bits, ou bien qui ont une bonne raison de ne pas le faire (ou bien qui croient en avoir une… )
Dans beaucoup d'entreprises on pourrait basculer sans problèmes en 64 bits. Mais le fait qu'un système 64 bits se compose à la fois d'une couche 32 bits et d'une couche 64 bits complique les choses, et il faut juste que les gens qui gèrent le système et les applis comprennent comment ça marche. Sans ça, ça peut poser des problèmes…

utiliser moins de disque et de ram?

Bah ça peut être ça en partie. Tu as quand même presque le double de DLL et d'exécutables sur un système Windows x64 (à la louche).
Après il faut savoir que chez Microsoft, l'ABI est bien plus raisonnable que chez Apple, donc la mise à jour coûte moins cher en RAM.
Chez Apple -> On passe *tout* en 32 bits. (Int32 -> Int64; Float32 -> Float64 )
Chez Microsoft > On passe juste les pointeurs et les handle en 64 bits, le reste n'a pas besoin de changer. (Sauf besoin explicite)
D'autre part le principe de la RAM a été invoqué (à l'envers) comme raison pour ne pas développer d'applications en 64 bits. Si les applications tournent en 32 bits et n'ont pas besoin d'utiliser plus de 2Go/3Go de RAM, alors elles peuvent rester 32 bits, et c'est "mieux". (Le "mieux" étant une histoire de cache et donc de performances… Sur ce point ils ont tout à fait raison à mon avis.)
Bon, c'est quand même un peu vaseux quand on parle d'un outil comme Visual Studio (avec certaines extensions, la limite d'espace adressage se fait sentir facilement) mais pour le reste, ça a mené à la décision d'exécuter par défaut les applications .NET 4.5 en x86 même lorsque compilées en AnyCPU (C'est en fait un "AnyCPU spécial", mais l'ancien existe toujours. Enfin c'est un peu con car les deux runtime n'optimisent pas les applications de la même manière )

Bah vaudrait mieux optimiser la grosse mouture que faire 2 optims parallèles...

Beaucoup d'optimisations sont quand mêmes communes au deux systèmes. Au final, une grosse partie du boulot doit se faire directement dans le compilateur. La majeure partie de Windows étant codé en C/C++ cela doit suffire. Par contre, c'est un fait que ça dédouble les efforts de tests. (Car là il y a vraiment deux branches à tester…)

La transition en 64 bits chez Apple, je l'ai vécu sans le voir.

C'est vrai que c'était assez transparent, par contre pour les développeurs ça devait l'être beaucoup moins parfois…

Chez crosoft, c'est des installs en plus, des isos dans tous les coins, le support de 3GO qui n'y est pas en 32bits, etc.

Mais Microsoft se préoccupe (à mon avis un peu trop) de ses clients qui dépendent d'anciennes technologies. (Et encore, seulement quand ça les arrange en réalité…)
C'est probablement ce qui a joué un grand rôle dans leur réussite. Mais c'est peut-être aussi (partiellement) ce qui les empêche aujourd'hui d'avancer correctement.

Redangel : on est en 2013

GoldenCrystal (./552) :
D'autre part c'est quasi impossible (comprendre méga relou) d'installer des drivers non signés sur un Windows 64 bits.

? Heu, ben, il me semble bien que ça ne posait pas de problème particulier autre qu'un popup d'avertissement jusqu'à windows 7 inclus ?!

Non, ça c'est en 32 bits. En 64 bits, Windows ne te laisse pas du tout installer un driver non signé, sauf bidouille (je crois qu'il faut ajouter une option en ligne de commande au démarrage, ou un truc comme ça).

Je suis sous win7 64 bits, j'ai jamais eu de driver "refusé" à cause de défaut de signature (et pourtant j'ai installé des trucs genre du noname)

Idem, jamais eu de driver "refusé", même pour des drivers "homemade". (ex: openKinect)

GoldenCrystal > Deux trois trucs que j'ai mal compris:
Avec .NET 4.5 on ne peut compiler qu'en x86?
Windows en 32 bits n'avait pas l'équivalent d'une machine virtuelle pour faire tourner les appli 16 bits? Qu'est ce qui empêche de faire la même chose pour les OS 64 bits?

En fait pour les Windows 64bit, le problème de signature semble dépendre de comment et par qui le windows a été installé. Sur 3 PC, un sous Windows 7 64bit, et deux sous Windows 8 64Bit, un seul a pas voulu sans manip d'un driver non signé (en l'occurence il était sous Win8 mais qu'importe)

Ah oui, sous Windows 7 ça pouvait être fait de manière permanente, mais sous Windows 8 c'est (à priori) impossible sans logiciel tiers… (Personnellement, j'ai pas réussi avec grand succès donc j'ai abandonné…)
En plus, l'option pour redémarrer n'est pas évidente à trouver dans leurs nouveaux menus "modernes"… :/

GoldenCrystal (./552) :
Ben je suppose que tu sais que par souci de simplicité, les applications 16 bits ne peuvent tourner que sur un OS Win32 natif 32 bits.

Tu supposes trop de mes connaissances Mais ton assertion ne me paraît pas raisonnable: 16bits tourne sur 32 mais ni 16 ni 32 sur 64? Y'a forcément moyen, comme en émulant (dit plus haut).

GoldenCrystal (./552) :
D'autre part c'est quasi impossible (comprendre méga relou) d'installer des drivers non signés sur un Windows 64 bits.

Ca c'est possiblement une bonne raison. Mais aussi une connerie je trouve... enfin verrouillage toussa quoi.

GoldenCrystal (./552) :
le Windows 32 bits est un Windows "plus traditionnel" et sert ainsi les frileux qui on peur de migrer aux 64 bits

Bah c'est dommage d'être frileux . Il faut surtout comprendre que microsoft fait tout pour pas céder (ie imposer) des trucs à ses clients.
Enfin, je vais sûrement passer pour un idiot, mais aujourd'hui le standard c'est 4-8GO de ram, donc le standard c'est un OS 64bits, y'a pas à chipoter!!! Je comprends pas pourquoi on tourne autour de ça... les industriels peuvent comprendre cette simple assertion!

GoldenCrystal (./552) :
ou bien qui ont une bonne raison de ne pas le faire (ou bien qui croient en avoir une… )

C'est plus souvent la parenthèse qui l'emporte, en fait.

GoldenCrystal (./552) :
Tu as quand même presque le double de DLL et d'exécutables sur un système Windows x64 (à la louche).

Attends, on ne peut pas utiliser la même dll compilée en 64 bits pour une appli 32 bits? J'avoue complètement mon ignorance, là. Enfin je veux dire, j'ai bien remarqué qu'il y avait 2 dossiers dans windows 64 bits et tout, mais est-ce que ce n'est pas "compatibilisable" avec une seule version "à jour" (et donc 64) pour "presque toutes" les applis?

GoldenCrystal (./552) :
Chez Apple -> On passe *tout* en 32 bits. (Int32 -> Int64; Float32 -> Float64 )

Ca a au moins le mérite d'être propre.

GoldenCrystal (./552) :
le reste n'a pas besoin de changer. (Sauf besoin explicite)

Pas besoin... sauf... : pas propre

vince (./553) :
Redangel : on est en 2013

Pas à la sortie de win 8.

redangel (./560) :

GoldenCrystal (./552) :
Tu as quand même presque le double de DLL et d'exécutables sur un système Windows x64 (à la louche).

Attends, on ne peut pas utiliser la même dll compilée en 64 bits pour une appli 32 bits? J'avoue complètement mon ignorance, là. Enfin je veux dire, j'ai bien remarqué qu'il y avait 2 dossiers dans windows 64 bits et tout, mais est-ce que ce n'est pas "compatibilisable" avec une seule version "à jour" (et donc 64) pour "presque toutes" les applis?

Eeeeh non (mais c'est logique, hein : tu ne parles pas çà la machine de la même façon, donc tu ne peux pas compiler de la même façon)... et pour simplifier les choses, les dll 64 bits sont dans system32 et les dll 32 bits sont dans SysWOW64 (il y a une explication à ça, hein... bonne, pas forcément, mais ça s'explique ).

Surtout qu'avant on avait

system ->Win16
system32 -> Win32

Maintenant on a :
System32 -> 64b
SysWOW64 -> 32b

C'est bien Folco, au moins tu suis ce que j'ai écrit 2 posts avant

(ah merde kèlkon )

WOW64 == "Windows On Windows 64"

La raison du "system32 -> 64b" c'est a cause d'applications a la con qui ont hardcodé %WINDOWS%\system32 pour aller chercher certains fichiers...


Mais ma vrai question, c'est pourquoi microsoft n'a pas porté le VDM vers le 64b, quitte a utiliser une emulation a la DosBOX plutot que switcher le CPU en mode 16b comme ils le font en Win32 (chose qui de mémoire est en fait possible, meme en 64b)

Ok il n'y a plus bcp d'application Win16/DOS mais quand meme

Godzil (./567) :
La raison du "system32 -> 64b" c'est a cause d'applications a la con qui ont hardcodé %WINDOWS%\system32 pour aller chercher certains fichiers...

merci, capitaine Godzil

()

redangel (./560) :

GoldenCrystal (./552) :
Chez Apple -> On passe *tout* en 32 bits. (Int32 -> Int64; Float32 -> Float64 )

Ca a au moins le mérite d'être propre.

GoldenCrystal (./552) :
le reste n'a pas besoin de changer. (Sauf besoin explicite)

Pas besoin... sauf... : pas propre

Ça n'a rien de "pas propre". La solution d'apple est à mon humble avis complètement conne. Si ton programme tournait parfaitement avec des entiers limités sur 32 bits (ce qui est le cas de l'API Cocoa), il n'y a aucune raison d'utiliser des champs qui prennent deux fois plus de place. (Surtout que parfois ça va être pour y stocker des valeurs d'enum qui n'occupent que quelques bits en réalité… )
La décision sur les float est encore plus irrationnelle. Cela n'a aucun sens d'utiliser des float32 en 32 bits et des float64 en 64 bits. La différence entre float et double, c'est une histoire de précision, pas d'ABI… Pourtant ils l'ont fait, et ça n'a là encore aucun intérêt. (Même histoire qu'avant, si ça tournait nickel avec des float32, c'était pas la peine d'y mettre des float64…)
Au final, si tu utilises des types de l'API OSX comme NSInteger ou CGFloat, ben tes structures mémoires vont prendre exactement le double de mémoire par rapport à la version 32 bits et ça n'apportera rien de spécial, hors cas particulier genre "je met un pointeur dans un entier". Pire encore, tes applications auront peut-être un comportement différent entre x86 et x64… et ARM…
Concernant les entier, y'a aussi le choix de l'ABI native LP64 (pour le compilateur C/C++/Objective-C) qui fait qu'un long est 32 bits sur une plateforme 32 bits et 64 bits sur une plateforme 64 bits. C'est le même choix que celui fait par Linux, que je trouve con aussi, mais à la limite, dans ce cas le problème vient du langage C qui à la base ne définit pas des types de taille stricte… Et ça ne t'affecte que si tu utilises explicitement des long (32 bits sur CPU x86 32 bits… En fait j'ai jamais trouvé ça logique à la base, mais bon ) donc c'est pas aussi gênant que le choix complètement crétin de Apple.
./567 > Certainement parce que ça demandait de nouveaux développement quelle que soit la solution choisie, pour une audience extrêmement réduite. (i.e. l'effort n'en valait pas la peine) Après tout, on est quand même loin d'être nombreux à avoir besoin d'une telle fonction. (Personnellement, je ne connais personne dans ce cas dans mon entourage proche ou moins proche. Et si je veux lancer un vieux jeux, ben j'utiliserai DOSBox, et en prime ça tournera sous OSX ou Linux )
D'autre part, ça leur permet d'assainir leur système. On peut facilement envisager que dans une hypothétique future version de Windows (Windows 9 ?) la seule architecture disponible sera 64 bits, et toutes les applications tourneront en mode WOW64 ou bien en mode 64 bits natif… Dans ce cas ils pourront purement et simplement dégager la branche de compatibilité 16 bits qui doit quand même leur peser assez lourd… (Je suis certain qu'ils seront ravis de s'en débarrasser )