Bueno... Y aun cuando tengas la distribucion instalada en el disco, es practicamente nula la posibilidad de que te contagies.

Cabe destacar que para contagiarte de algo, tiene que ser un virus especificamente creado para Linux. Aparte de eso, por el tema de los permisos de los directorios y los ficheros, el virus solo podria afectar los archivos que esten en la carpeta del usuario, y en el escritorio. nada mas.

Siempre y cuando, claro esta, estes siguiendo la recomendacion de usar una cuenta de no administrador para tu dia a dia!.

Si tienes una preocupacion MUY grande sobre el tema de la seguridad, te recomendaria que te instalaras Gentoo Linux, que compilaras una instalacion minima, kernel totalmente customizado por ti, y que te leyeras sobre SELinux.

Actualmente la puedes utilizar. Claro que si, pero esta marcada como deprecada. Si ahora haces una aplicacion que utilize esa api, en una proxima version de Windows podras toparte con que ya tu aplicacion no funciona.

Lo mismo ha pasado antes. No se que error salte ahora, porque estoy un poco desconectado del tema de las API de Windows (A Dios Gracias). Pero, antes el error que saltaba cuando intentabas llamar un api que ya no existia era:

"Cannot find entry point in dynamic link library in ??????.dll" donde ????? es el nombre del .dll que contenia el API

Pues, se hace para eliminar codigo obsoleto. Pero OJO: No es que las borran y te quedaste sin pito y sin flauta.

Primero se desarrolla una API alternativa, y se implementa. Durante un tiempo ambas API's estan en funcionamiento, salvo que la vieja esta marcada como deprecada. pasado ya mucho tiempo, se supone que tu, como buen programador, has actualizado ya tu programa para usar la nueva API. y en ese entonces, ya si se elimina la API vieja.

Tener todo ese codigo obsoleto ahi, es una carga muerta tremenda al momento de dar mantenimiento! Muchas veces lo que se hace es refactorizar el codigo, para modernizarlo sin cambiar la firma de sus funciones.

Pues, porque naturalmente no todas las apis van a ser eliminadas. Solo se eliminan las que van quedando muy obsoletas, y esto incluso se hace luego de dos lanzamientos de la plataforma o asi.

Conoces el Blog de Reed and Steve? Es un blog oficial de microsoft.

Mira lo que dice el de las API's que estan marcadas como deprecadas:


Traduccion:

Por otra parte, cuando salio Windows 7, a nuestra institucion se le entrego un documento marcado como Confidencial por Microsoft Dominicana. Por motivos obvios, no puedo hablar abiertamente de ello, pero el encabezado dice asi:


Poniendote un ejemplo:

Windows 95, 98, ME, utilizan un modelo de Drivers llamado "VxD". Luego, en Windows 2000, Xp, 2003, Vista, 7, etc... se utiliza un modelo de drivers llamado WDM.

Supongamos que realizas una aplicacion que utiliza API's relacionadas con el modelo VxD, y intentas correr esa aplicacion en Windows 7... que crees que pasara!? No funcionara. Porque? Porque... que sentido tiene soportar API's en Windows 7, para un modelo de drivers que quedo obsoleto hace 10 años?!

No tiene ningun sentido. Aparte, una de las mejores practicas al momento de dar Mantenimiento a las aplicaciones es remover funcionalidad obsoleta. Esto es recomendado en un libro de Microsoft Programming llamado Code Complete 2.

Otro caso de ejemplo: El api de QoS (Quality of Service). Esta deprecada y sera eliminada en cualquier proxima version de windows.

Que dicen en Microsoft al respecto?


Traduccion:

Fuente: http://blogs.msdn.com/b/wndp/archive/2006/07/05/657196.aspx

En resumen: En microsoft SI eliminan API's. Que es un proceso lento? Es cierto. Que ellos tratan de no hacerlo para evitar problemas de compatibilidad? Es cierto. Pero tambien es cierto que no todas las apis siguen ahi, como afirmas tu.

Por cierto... tambien en Windows Mobile deprecan y eliminan API's:
Fuente: http://msdn.microsoft.com/en-us/library/bb629458.aspx

Y de Linux ni te hablo... En Linux se eliminan API's constantemente tambien.

Porque crees que dice

?

Cuando un api esta marcado como "Deprecated", el programa te funciona, pero el compilador arroja advertencias, de que el api que estas usando esta marcado como "Deprecated" y que debes usar otro.

Porque crees que los marcan "Deprecated"? Crees que los marcan "Deprecated" y los dejan por ahi y ya??

No, la cosa no va asi. Funciona de esta forma:

El api X, se usaba en Xp.

En Windows vista, es marcada como "Deprecated". El programa te funciona, pero, ya sabes que el api X va a dejar de funcionar en proximas versiones, asi que, buscas alternativas. Generalmente el mismo compilador te lo advierte "X is deprecated. Use Y instead".

Luego, en Windows 7, el API que estaba Deprecated en Windows Vista, es removida en 7.

Ojo: No significa que tenga que ser removida en 7. En Windows 7 puede continuar Deprecated, pero ser removida en Windows 8.

Si y no. Ciertamente por definicion, una aplicacion C++ es mas rapida que una aplicacion hecha en .net. Esto es porque al compilar una aplicacion .net, esta se compila a un lenguaje intermedio (MSIL), y luego el CLR, en tiempo de ejecucion, "traduce" el MSIL al lenguaje de maquina.

Ahora bien... el MSIL y el CLR estan tan bien optimizados que la diferencia entre C++ y .net muchas veces se reduce al buen uso que de un programador del lenguaje.

Me explico: Un algoritmo eficiente en C#, puede ser mas rapido que un algoritmo pobremente creado en C++.

Que hay diferencia? Claro que la hay. Pero programando de forma eficiente, esas diferencias son simplemente minusculas. Claro esta, si hablas de aplicaciones de mision critica en tiempo real, C++ es C++, eso no entra en discucion.


Simplemente NO es cierto. En el 2003 yo realize una aplicacion que procesa unos archivos que nos llegan atravez de un frame relay.... y adivina que? Esa aplicacion fue compilada por ultima vez el 12 de diciembre del 2003. Y adivina donde la tengo corriendo?? Windows server 2008. Y para los fines, tambien funciona con Mono 2.4 en linux SIN recompilar.

Lo de que tienes que tener instalado el framework!? Cierto. Ahora bien... cuantas maquinas has visto estos dias que no tengan instalado Framework 2.0??

Por el hecho de que .net 4 ya este afuera, no tienes que actualizarte. Si lo que buscas es la mayor compatibilidad, te quedas con .net 2.0 y listo.

Es como ubuntu: Ubuntu es compilado para la arquitectura 386 en vez de la 686. Porque? porque si bien es menos optimizado, es mucho mas compatible.

Pues si. Microsoft si retira API's de Windows de una version a la otra. Por eso en mi trabajo antes de desplegar un proyecto tenemos que verificarlo con el Application Compatibility Toolkit de Microsoft.

Una de las funciones del Application Compatibility Toolkit es verificar que el programa que creaste no este haciendo llamadas a API's que esten marcadas como deprecadas.


Fuente: http://technet.microsoft.com/en-us/library/cc766242%28WS.10%29.aspx

Pues... depende que busques.

Si quieres hacer cosas que se supone, no deberías (Inyecciones) pues .net no es la mejor herramienta. Ahora bien, si lo que te interesa es tener acceso remoto para espiar, .net es una excelente herramienta.

C# no tiene 10 años. Tiene 8 y meses. Casi 9.

Como tengo 11 años de experiencia programando? Pues, muy fácil. Tengo 25, y empece a aprender a los 14.

Mis "Pinitos" en programacion, fueron con Turbo Pascal. Despues, mi primer contacto con la programacion visual y las API fueron con Delphi 5. Luego, como en ese entonces no sabia ingles y no encontraba mucha documentacion en espanol sobre delphi, me pase a VB5. Luego continue con VB6.

Luego en 2002, me puse a aprender C# y VB.net. Actualmente ambos lenguajes son los que me pagan la renta, el carro, y me ponen la comida en la mesa, pues no los uso de "hobby" sino para crear aplicaciones para la entidad financiera donde trabajo.

Esta interesante lo de los gusanos y las redes sociales. Voy a investigar sobre eso!.

Sobre lo de hacer malware en .net.... pues, hacer un troyano es perfectamente factible, siempre y cuando compiles de cara al Framework 2.0 y no a versiones superiores. Practicamente toda maquina con Xp tiene Framework 2.0, y en Vista, y 7, el Framework viene por default.

Siempre y cuando, no pretendas usar .net para meterte con otras aplicaciones (Por ejemplo, haciendo inyecciones de memoria), todo estara bien. Porque el CLR NO permite andar trasteando por todos lados, como pueden hacerlo los lenguajes no manejados. Lo cual es bueno si haces aplicaciones comerciales, pero no tan bueno si quieres hacer malware complejo.

Descuida... lo hare!  

Un troyano en .net funciona... Siempre y cuando no quieras andar molestando los espacios de memoria de otras aplicaciones (inyecciones!?) todo estará bien