BlackHole escribió:Eso es un problema que ha tenido Microsoft durante 24 meses, así que no es que si alguien lo ha notado, es que si alguien en el planeta no lo ha notado... ya comenté por aquí mismo que para arreglarlo hay que instalar la actualización
KB3168965 (boletín de seguridad MS16-090) de Julio de 2016.
He estado observando este problema desde XP al menos, y es algo que afecta exclusivamente a mis portátiles. Siguiendo tu consejo, he bajado la actualización mencionada en el único portátil afectado que me queda (ejecuta Vista 64) y ya lleva una hora buscando actualizaciones. Me parece que no se ha curado.
GXY escribió:lo del .net es un follon de mil pares
Yo añadiría que también es una gran oportunidad perdida, junto con un montón de runtimes que han ido sacando.
Cuando empezaron a hacer lo de .NET (pero ya llevaban años con las VB runtime y VC runtime), pensaba que apuntaban a un sistema de librerías/paquetes parecidos a los de Unix, donde las librerías se eliminan del programa principal para que ocupe menos (aunque no veía las dependencias por ninguna parte).
Y una mierda. No sé si es la cultura de Windows, pero todos los instaladores seguían incluyendo las runtimes "por si no estaban instaladas". Nunca ha habido un sistema de dependencias efectivo (que un paquete/programa pida o descargue las librerías que le faltan al instalarse), y programas que podían haber necesitado pocos Ks para bajarse acaban necesitando 50 megas porque incluyen la puñetera .NET.
Muchas .NET no son acumulativas, y al final hay que tenerlas instaladas todas "por si acaso". No hay manera de saber qué runtimes están instaladas en realidad (aunque hay utilidades que las buscan indirectamente a través del registro) y el hecho de que algunas runtimes se instalen con el sistema operativo y no aparezcan listadas en los programas a desinstalar no ayuda a tener una visión clara de lo que tienes y lo que te falta. Que tengas una versión 2.0 no significa que tu programa 2.0 vaya a funcionar, porque quizás requiera 2.0.muchosdigitos.
.NET es un follón, pero ya se veía venir desde Visual BASIC... con cada versión de Visual BASIC inventaban un nuevo método de acceso a datos que iba a ser el definitivo... hasta que pasaban a la siguiente versión. Afortunadamente, las librerías de acceso a datos han sido más estables que las .NET (en el sentido de que era más claro saber cuál faltaba y las pequeñas revisiones no daban problemas de compatibilidad).