Windows 11 tendrá nuevas apps de correo, calendario, calculadora y capturas actualizadas con cambios en la interfaz y funciones

A mi la de correo, con una cuenta de Google Workspaces, me funciona bastante mal y no confío nada en ella. Nos pasó a varios en la empresa que simplemente escribías un correo, lo enviabas, y luego no estaba en ningún lado: ni se había enviado, ni en borradores, ni en bandeja de salida. Me sucedió un par de veces hasta que perdí mensajes que me había llevado tiempo redactar, y dejé de usarla porque no se en que momento vuelve a suceder.

Hay que ver si sacan alguna vez una version LTSC... Que parece que no habrá.

Ya no son azules, son verdes.

En Windows 11, concretamente, son negros.

Son verdes pero solo si eres beta juraria, son asi para diferenciarlos creo.

Paint: https://www.laptopmag.com/news/microsoft-paint-for-windows-11-gets-a-fresh-new-look-heres-a-sneak-peek

Notepad: que no lo toquen.

Ya dijeron que Notepad también va a recibir un rediseño.

Dejen ya de pedir que “no toquen” programas de Windows 95 y empiecen a aceptar tantito cambio en Windows, gran parte de la culpa de que Windows no tenga una interfaz consistente es que algunos usuarios de entrada rechazan cualquier cambio cuando ni siquiera se ha visto como será la nueva interfaz…

No hablo de la interfaz de Notepad, sino de lo que se puede hacer con él. Quien quiera un editor de código que se pille Notepad++, no hace falta convertir el Notepad en otra cosa que no sea lo que es: un editor de texto pelado, sin más.

joder pero anda que no se pueden añadir cosas... sin llegar a ser notepad++

¿Qué cosas se podrían añadir?

Hijo mio, para eso esta la opción de "pausar actualizaciones".

Ostia, y yo viviendo en el mundo de los actualizadores automáticos que lo hacen sin que te enteres...

Que perezaaa, tener que actualizar el software para estar mas protegidos

Actualizar, actualizar, actualizar... hasta que el Windows vaya tan lento como un caracol.

A veces Microsoft la pifia con la actualizaciones...

peor es no actualizar, no actualizar, no actualizar... pero bueno, si no lo hiciera sería el argumento preferido de algunos para enseñarnos a todos lo importante que es tener un software actualizado, ya sabemos como funciona esto de la crítica

.... con un MacOS no? Linux es tán.....old-shool XD

En realidad con el propio windows pero sin ceder a los patrones oscuros y las trampas para novatos que mete microsoft para que usemos sus servicios online.

😈😈👏🏻👏🏻👏🏻 😈🍺👊🏻👍🏻

Pues ese es justo el problema, que Linux no está diseñado (aún, y ya lleva mucho tiempo así) para ser usado por todo el mundo. Y ni te cuento de las aplicaciones, incomparablemente inferiores a las homólogas en otros S.O. comerciales, por más que algunos usuarios puedan tener un más que aceptable rendimiento con las mismas.

Se pierde el norte con el S.O.: el sistema tiene que ser transparente al usuario, que no tiene que convertirse en un experto en el sistema operativo para manejar una aplicación.

Otros S.O. están muy orientados a la usabilidad, si bien es necesario un cierto aprendizaje, infinitamente menor que el Linux.

apt-get no es el objetivo. Manejar aplicaciones que crean resultados y la comunicación con terceros, sí.

No es tan así: depende de la situación y de los gustos también.
Por viejo que parezca todavía se programa en ensamblador y la gente que se pone sería con optimizar el código es gente que mira el ensamblador que genera el compilador.
Cada cosa tiene su sitio.

Quiero ver esos benchmarks comparativos. Si están a mas de un 10% de diferencia vamos xDD. La última vez que vi algo similar fue un micro-benchmark Java y C++ en algo sencillo:

Y tanto en una version mal optimizada: array sin ordenar, lo cual le hacia la puñeta al predictor de ramas de la CPU.
Array ordenado: mucho más rápido.

En ambas situaciones C++ no era más de un 5% más rápido que lo que producía la JVM.

Vamos, actualmente es más importante si buscas rendimiento que escribas líneas bien tiradas que las diferencias de runtime en este caso concreto.

Vamos a ver el tema en si no es solo por rendimiento en tiempo de hacer multiplicaciones, es por uso de memoria, localidad de recursos y startup time del .NET (aunque bueno no se si esta integrado en windows al arrancar el OS, lo desconozco).

A lo que me refiero es que que C# es un lenguaje que abusa del heap como ningún otro, hasta Java es más precavido con el alloc. Como tu dices el JIT de java no es moco de pavo, pero la comparativa que tu haces es irreal: no cuentas el startup de la JVM

Y con esto llego a mi punto: si ya tienen la app en C++ porque cambiar a C#? Que si, uno me puede argumentar que la diferencia en rendimiento es minúscula (como tu mismo haces) pero no tienes en cuenta el startup del runtime del .NET (repito que no se como va en windows pero el resto de OS necesitarán Mono). También me podéis decir que el C# es más fácil de mantener y eso es un punto válido, pero que igualmente no creo que C# sea la solución.

Por otra parte, al menos no la han escrito en JS como el vscode

Te has quedado un poco en el pasado (por no decir muchisimo)

En las nuevas versiones de C#, existen varias caracteristicas para ubicar e incluso manipular strings en el stack, en vez de crear espacios de memoria en el heap.

Tan solo debes de ver la locura que es .NET 6. Lo unico que realmente le falta es compilacion por AOT, pero lo demas va sobrado en rendimiento y optimizaciones de su nucleo/CLR.

Eh, no, no tienes que pasar por unsafe a fuerzas.

Puedes hacer un stackalloc directamente en un Memory, y usar cualquiera de estos metodos que no usan nada de ubicación de memoria:

https://docs.microsoft.com/en-us/dotnet/api/system.memoryextensions?view=net-5.0

Y tambien hay otro fallo garrafal. Microsoft solo usa Mono oficialmente en su framework solo para soportar moviles (siendo el runtime de Mono una cosa aparte de .NET Core)

Asi que no, hace mucho que no se depende de Mono para otras plataformas.

En C# tu decides cuanto abusas del heap:
class=> gestionadas por el GC. Al heap y luego se referencian con puntero.
struct=>no gestionadas por el GC. Heap o stack según como las utilices. Ciclo de vida implícito hasta que se vayan fuera de ámbito: el método donde se crearon termina o el objeto que las contiene se destruye.

La localidad de recursos la misma o mejor que controlándola el programador explícitamente. Esto como todo: un mago del ensamblador puede hacer mejor código que un compilador, pero alguien que no sabe lo va a hacer peor que el compilador seguro. Los GC tienen rutinas para compactar la parte del montón que controlan cuando gestionan objetos para mantener la localidad.

El uso de memoria si es cierto que va a ser algo más grande que nativo: hay un modelo de metadatos del código que el compilador esta manteniendo y trabajando con el para generar código. El runtime también usa el modelo de metadatos para sus funcionalidades y tu incluso puedes usarlo.

Respecto a .NET integrado en el OS. No, nunca estuvo integrado en nada del sistema operativo. Toda la integración que hubo y hay es que vienen las dependencias pre-instaladas y que algunas APIs se programaron asumiendo que la WinAPI siempre iba a estar disponible.

.NET en si es:
hostfrx.dll(C/C++): añadida en .NET Core para multiplat
hostpolicy.dll(C/C++): añadida en .NET Core para multiplat
coreclr.dll(C/C++): clr.dll en .NET Framework
System.Private.CoreLib.dll(C#): mscorlib.dll en .NET Framework
clrJit.dll(C/C++)

Es decir, en famoso CLR es un programa nativo escrito en C/C++ y la única magia es que el compilador de C# al generar ejecutables de .NET emite una plantilla que carga e inicializa todas las dlls anteriores en el proceso antes de llamar al entry point en C#.
Es obviamente algo más de inicialización que lo que tiene un programa nativo por razones obvias: el CLR ES el programa nativo donde todo empieza. Pero ni mucho menos es algo brutal. La diferencia está como siempre en quienes hacer el código y las APIs usadas para diseñar la solución.

Desconozco el estado actual de la librería estandar de C# (por ahí arriba comentan que con .NET 6 la cosa cambió, no programo en C#), pero la ultima vez que la miré cada vez que querías hacer algo necesitabas tirar de objetos. Claro que es un lenguaje de POO, es comprensible, pero mi punto es: Si ya tienes una aplicación en C++ sin necesidad de runtime y de calidad, para que la reescribes. Sobre el papel todo son desventajas:
- Si abusas de objetos pierdes localidad (es una calculadora, debería tener pocos objetos en la lógica)
- La stdlib de C# son todos objetos por lo que pierdes localidad si quieres usarla (como digo no se si esto ha cambiado o que)
- Más memoria
- Tienes que esperar al .NET, si no está cargado en memoria (espera mínima, pero es una calculadora!!!)

La única ventaja que le veo es que no tienes punteros, que bueno lo entiendo es difícil. Pero saber usar C# de forma que minimice las desventajas que tiene también lo es. No veo como el cambio de C++ a C# ha sido beneficioso ni desde el punto de vista del usuario ni del programador. Especialmente cuando la versión de C++ ya era una maravilla

De todas formas sería cuestión de echarle un vistazo al código a ver que hacen exactamente. Quizás con el .NET reducen el código muchísimo en la GUI o algo similar.

Esto debería aclararlo: https://github.com/microsoft/calculator/issues/893

El artículo no se para a contar la historia completa supongo que porque es Xataka, no Genbeta y eso no es de interés para usuarios comunes pero igualmente.

Resumiendo:

-La UI se migra a C# para facilitar la colaboración de gente al proyecto.
-El backend de la calculadora: intérprete de expresiones se mantiene en C++ por el momento.

Creo que ya lo dije antes y lo repito. En .NET existen las struct desde las primeras versiones que son básicamente objetos que no controla el GC. El lenguaje tiene soporte para punteros y la condición para poder usarlos libremente es que tienen que ser sobre objetos que no administra el GC o alternativamente se pueden usar sobre objetos administrados mediante "pinning"(se notifica al GC que no destruya ni mueva el objeto por X sección de código).
El runtime es lazy: lo que no se usa no se compila ni se toca y si usas pues te lo comes, que para eso lo pediste...por eso vuelvo a insistir a ver si más claro: todo esta en la APIs usadas, es lo que realmente soporta el peso de todo. Pero las APIs no son el lenguaje ni el compilador: precisamente por eso C# y Java no distan demasiado en rendimiento de C/C++ cuando se realizan operaciones estrictamente matemáticas, porque cualquier compilador puede hacer un trabajo muy decente.

PS: por otro lado el rendimiento es muy relativo. Hay gente que se quejo igualmente cuando migraron calc de WinAPI a UWP por rendimiento y blabla...y no se. Yo en mi PC la inicio y no me da ni tiempo a llevar la mano al ratón o aporrear una tecla antes de tenerla en pantalla.

No había visto ese issue de Github. Con eso queda mas claro el cambio. Se ve que lo que tenian antes era un intento de UWP en C++ que se quedo en intento y decidieron migrar a C#