Mensajes

@kub0x la página de tu aplicación no muestra nada.

[Autor:]

Autor: 0xDani
Nombre de la aplicación: Process Monitor
Lenguaje: C++ con las librerías Qt
Sistema Operativo: Linux y quizá algún otro Unix-like
Descarga: ProcessMonitor.zip (253 KB) Source + ejecutable 32 bits
https://mega.co.nz/#!rwR2FLgY!fbM_rXYm27sY9sevptQC639OBtZj_2IXbb3HPv3NalE

Descripción

Process Monitor es una aplicación que te permite listar los procesos activos en tu ordenador, matarlos, obtener información sobre el uso de memoria que estos hacen y los archivos que abren.

Se basa en la información proporcionada por el sistema operativo mediante el sistema de archivos virtual /proc.

La aplicación está en inglés, si alguien quiere una traducción o alguna aclaración sobre el código o la aplicación misma, MP y listo. Excepto si estás leyendo esto varios años después de que yo lo escriba.

Bueno, suerte y que gane el mejor!

Y necesitas almacenar esos números en un archivo? No te sale mejor generarlos al vuelo?

Para los que han señalado el inconmensurable trabajo que conllevaría mi idea:

Precisamente eso es lo que quería señalar. Porque en el post originalmente se pretendía convertir ejecutables.

Saludos.

A ver... qué dificulta la portabilidad de un ejecutable? Yo veo dos causas:

1. Los distintos procesadores tienen diferentes juegos de instrucciones y opcodes.

2. Los ejecutables están en un formato de ejecutable propio de un sistema determinado, y llaman a las APIs de ese sistema determinado.

La primera dificultad se puede salvar desde la creación de los lenguajes de alto nivel, en los que un compilador traduce el código al lenguaje ensamblador del procesador en cuestión (sin tener en cuenta los lenguajes interpretados).

La segunda dificultad hay que explorarla un poco más. Dividamos los ejecutables en dos grupos, a saber:

1. Los que usan el formato PE y llaman a las APIs de Windows.

2. Los que usan el formato ELF y llaman a las APIs de POSIX, y posiblemente, a otras específicas del sistema.

Bien, ahora supongamos que queremos un programa que, dado un ejecutable, lo convierta en uno equivalente del otro grupo.

Mi aproximación mental:

Se crean dos librerías, una que implemente las APIs de POSIX, las syscalls de Linux, BSD, etc... en Windows, y otra que implemente las APIs de Windows en Linux y otros sistemas.

El programa debe, además, cambiar el formato de ejecutable. Esto se presenta muy costoso, pero se puede extraer el código ensamblador y los datos de un ejecutable y construir un ejecutable válido para el otro sistema a partir de esos datos, añadiendo headers y demás.

Supongamos que ya hemos hecho lo anterior. Ahora tenemos un ejecutable de Windows que queremos portar a Linux, y lo pasamos por el hipotético programa descrito más arriba. Nos queda un ejecutable ELF con el código ensamblador y los datos del programa original, que llama a APIs de Windows. Sólo queda volverlo a enlazar con nuestras hipotéticas librerías, que implementan todas las APIs de Windows en Linux, y relocalizar los símbolos de los propios datos del ejecutable.

Parece enorme, no?

Hola,

La presentación de aplicaciones termina exactamente el día 5 de Julio de 2013 a las 23:59 tiempo España (península) [UTC+1 (verano UTC+2)]. Por tanto, tenéis el día 5 entero

Saludos

Gracias, eso era lo que quería saber 

El 5 es el día máximo.
Te recomiendo entregarlo mañana, para que no haya malentendidos

Ya, pero quiero saber si puedo entregarla el mismo día 5 y a qué hora si es el caso.

Una duda, exactamente cuándo termina el plazo de entrega? Porque pienso entregar mi app el último día, pero no quiero entregarla tarde.

Sin ánimo de ofensa, creo que la única posibilidad realista que he leído en este topic es la aportada por @daryo.

Veamos:

·Que el exe se envíe a un servidor Windows y este inspeccionando los cambios que ha realizado el ejecutable en su sistema devuelva un programa compilado para linux que altere Linux de la misma manera. Es decir, un programa con las mismas condiciones y similar al original. (Demasiado complejo para realizarse pero totalmente posible aún que no viable.)

·Que se recojan todas las instrucciones que el programa realice en código máquina y que se cree un ejecutable. (Demasiado complejo)

Y la última y la mas viable que se me ocurre de momento.
·Recrear en Linux el sistema que abre los exes en Windows.

Si se consiguiese hacer esta última simplemente habría que substituir algunos cambios que se realicen en Windows para Linux. Imaginaros el ejemplo de un programa que abra el disco local C: y copie un archivo dentro. Pues solo habría que indicarle al programa que creemos que sin el programa intenta acceder a la ruta C: pues que en Linux se copie el archivo en Raiz o en donde sea, en vez de en C. Llevaría trabajo, cierto. Podemos ser muchísimos en el proyecto, aún más cierto aún. La mayoría de distribuciones Linux han sido creadas por millones de desarrolladores.

• 1^a forma:
  
  Tú mismo has señalado la complejidad de este método, date cuenta de lo difícil que sería que tu programa crease otro programa en base a los cambios que el programa que se quiere portar a Linux ha hecho en el equipo. Y no te olvides de que los cambios que un programa haga en un equipo dependen de una serie de condiciones, cómo emular todo eso?
  
  
• 2^a forma:
  
  Esa no sería tan difícil, conociendo el formato de ejecutable de ambos sistemas, el problema estaría en los cambios de arquitectura y en que el programa resultante quedaría llamando a APIs que no existen en el otro sistema.
  
  Se podría crear una librería que recreara todas las funciones de la API de Windows en Linux, y relocalizar los símbolos del ejecutable para enlazar con esta librería. Cuántas funciones API tiene Windows?
  
  
• 3^a forma:
   
    El loader de Windows? Ok, pero Linux ya tiene un loader, sólo que trabaja con el formato ELF en vez de con el PE. Supón que cargas un ejecutable PE en memoria, tal cómo lo haría el loader de Windows, en Linux. De qué te sirve, si el programa sigue teniendo referencias indefinidas a APIs que no existen en Linux?
  
  En fin, ahí te dejo mi crítica para que te vayas haciendo una idea más realista, y te des cuenta de todo lo que implica lo que quieres hacer.
  
  Saludos.

Tienes que dividir el zoom cuyo inverso quieres calcular entre 100, y multiplicar por la inversa del resultado.

De esta forma, el zoom inverso de 50:

Código [Seleccionar] Expandir


50/100 = 1/2
Inversa de 1/2 = 2
100*2  = 200


Creo que es eso lo que quieres, comprueba que funcione.


Saludos.

PD: La inversa de un número es, por definición, aquel que multiplicado por el primero resulta en 1, esto es 1/x.