Hola,

Existe una unidad en Delphi 7 de nombre "XpMan.pas". Esta unidad se limita exclusivamente a añadir al ejecutable (como un recurso más) el archivo "WindowsXP.res", que puede encontrarse en: "C:\Archivos de programa\Borland\Delphi7\Lib".

Pues bien, dicho archivo ".res" contiene el siguiente XML:

El cual es "leído" por Windows cuando se ejecuta el ejecutable que lo contiene. Entonces Windows aplica a los controles "comunes" ("TEdit", "TButton", "TMemo", "TMainMenu", etc.) que contenga dicho ejecutable, le aplica, digo, el tema que esté establecido en Windows XP.

¿Si te sirve de algo en Delphi 2007? Ignoro siquiera si se incluye la unidad "XpMan.pas", empero, a no ser que se incluya el recurso "WindowsXP.res" por defecto en los ejecutables (cosa que dudo, pero por pura intuición), si quieres que tu programa adopte el tema de Windows XP... deberá usarse igual que en Delphi 7, por ejemplo.

En general podría decirse que cualquier ejecutable (de Delphi o de otro lenguaje/entorno) que contenga el XML referido (como un recurso más dentro del ejecutable), tomará en sus controles comunes (de Windows) la apariencia del tema de Windows XP que esté usando el usuario.

PD. Pero no mezclemos distintos temas en un mismo Hilo que puedo acabar echándome la bronca a mí mismo y no veas tú qué compromiso. :)

Gracias Dec, las cosas de las que se entera uno... no tenía ni idea de eso

:D

Hola,

Vamos a ampliar ambos la información, ya puestos, y a leer el artículo de Michael A. Allen y Zarko Gajic: Windows XP Manifest in Delphi. :)

Volviendo al tema de los KeyGen... yo pensaba que los sacaban las propias compañías de software.
Aunque suene a broma, lo digo en serio. El interés de dicha acción sería para permitir que usuarios no profesionales puedan acceder a sus productos.

Para todos aquellos que tienen esta duda tan extraña, el XPManifest es para que los formularios, botones, paneles, etc de tu programa soporten los temas (apariencia) de Windows XP y superior que tenga el usuario, de otra manera si no está el XPManifest presente los formularios no podrán soportar esta cualidad, y se verán con la misma apariencia antigua y no grata de Windows 2000 hacia abajo(ploma y poco vistosa) a pesar que el usuario tenga un tema de apariencia configurado en XP. Desde Delphi 7 este componente viene incorporado en la paleta Win32. Para usuarios con versiones inferiores a la 7 deben hacerlo manualmente, primero haciendo un archivo como se mencionó anteriormente con esas características y guardándolo con extensión .Manifest, luego creando un archivo especificando el tipo de recurso guardándolo en extensión con el mismo nombre del anterior pero con extensión .RC, luego compilándolo con el archivo Bcc32.exe que se encuentra en la carpeta bin, el cual les generará un archivo .RES que luego lo tienen que especificar en su código de la unidad del formulario.

Ejemplo de cómo especificarlo:

Código Delphi [-]

implementation

{$R *.dfm}
{$R Ejemplo.RES}

También el otro método que existe es simplemente poniendo el archivo .manifest en la misma carpeta en donde radicará el ejecutable de tu proyecto pero con el mismo nombre del ejecutable, es decir, si nuestro ejecutable se llama MiProyecto.exe, el archivo manifest se tendrá que llamar MiProyecto.manifest

Espero que les haya servido la información.

Sé que llego tarde, y que esto está degenerando un poco, pero voy a recuperar el hilo inicial de esta conversación.

Lo de los programas "keygen" que muestran esas impresionantes presentaciones en poco más de 30Ko de ejecutable es herencia de las "tech-demos" que se empezaron a hacer en los '80. En estas se intentaba hacer el programa más impresionante (e inútil, todo sea dicho de paso) en el menor espacio posible.

Yo fui demo-maker en mis tiempos, pero yo lo hacía en MSX y no en PC. Para ahorrar el máximo de memoria las demos se programaban exclusivamente en ensamblador, realizando llamadas directas al BIOS y accediendo a los puertos y a la memoria del sistema de forma directa, sin pasar por el sistema operativo.

Por otro lado, lo que hincha un programa Windows suelen ser los recursos. Si en lugar de crear las ventanas y diálogos con el IDE, arrastrando y soltando componentes con el ratón, lo hacemos a golpe de código podemos reducir considerablemente el tamaño de los ejecutables. Hace ya algunos años hice una demostración con Delphi 6 en el que ahorré una media de 1'5Ko por control (no sólo los visibles como los botones sino también los invisibles como los TQuery, TDialog, etc.) al reproducir un programa RAD a golpe de código. Si un programa tiene 200 componentes, lo cual es bastante común, podemos ahorrar casi 300Ko.

Eso sí, es mucho más difícil diseñar un formulario escribiendo el código directamente en Pascal que utilizando los componentes visuales.

O sea, que de RAD pasó a SAD :p :D

// Saludos

Aver, a ver, ¿quieres decir que si creo mis componentes desde código? al estilo de:

Código Delphi [-]
var
  Form1: TForm1;
  Button1: TButton;
  JvDBGrid1: TJvDBGrid;
  Table1: TTable;
  Jv: TJvCsvDataSet;
  M: TJvMemoryData;
  JvDataSource1: TJvDataSource;

  Form1 := TForm1.Create(Self);
  Button1 := TButton.Create(Form1);
  JvDBGrid1 := TJvDBGrid.Create(Form1);
  Table1 := TTable.Create(Self);
  Jv := TJvCsvDataSet.Create(Self);
  M := TJvMemoryData.Create(Self);
  JvDataSource1 := TJvDataSource.Create(Self);
  with Form1 do
  begin
    Name := 'Form1';
    Left := 0;
    Top := 0;
    Caption := 'Form1';
    ClientHeight := 530;
    ClientWidth := 399;
    Color := clBtnFace;
    Font.Charset := DEFAULT_CHARSET;
    Font.Color := clWindowText;
    Font.Height := -11;
    Font.Name := 'Tahoma';
    Font.Style := [];
    OldCreateOrder := False;
    PixelsPerInch := 96;
  end;
  with Button1 do
  begin
    Name := 'Button1';
    Parent := Form1;
    Left := 32;
    Top := 64;
    Width := 75;
    Height := 25;
    Caption := 'Button1';
    TabOrder := 0;
    OnClick := Button1Click;
  end;
  with JvDBGrid1 do
  begin
    Name := 'JvDBGrid1';
    Parent := Form1;
    Left := 24;
    Top := 112;
    Width := 345;
    Height := 385;
    DataSource := JvDataSource1;
    TabOrder := 1;
    TitleFont.Charset := DEFAULT_CHARSET;
    TitleFont.Color := clWindowText;
    TitleFont.Height := -11;
    TitleFont.Name := 'Tahoma';
    TitleFont.Style := [];
    SelectColumnsDialogStrings.Caption := 'Select columns';
    SelectColumnsDialogStrings.OK := '&OK';
    SelectColumnsDialogStrings.NoSelectionWarning := 'At least one column must be visible!';
    EditControls := <>;
    RowsHeight := 17;
    TitleRowHeight := 17;
  end;
  with Table1 do
  begin
    Name := 'Table1';
    DatabaseName := 'DBDEMOS';
    TableName := 'customers.dbf';
    Left := 24;
    Top := 16;
  end;
  with Jv do
  begin
    Name := 'Jv';
    Changed := False;
    CsvUniqueKeys := False;
    ExtendedHeaderInfo := False;
    CaseInsensitive := False;
    LoadsFromFile := False;
    AutoBackupCount := 0;
    StoreDefs := True;
    Left := 88;
    Top := 16;
  end;
  with M do
  begin
    Name := 'M';
    FieldDefs := <>;
    Left := 160;
    Top := 16;
  end;
  with JvDataSource1 do
  begin
    Name := 'JvDataSource1';
    DataSet := Jv;
    Left := 248;
    Top := 24;
  end;

Mi programa va a medir menos que usando el editor de formularios de Delphi??? Me puedes firmar con tu sangre eso??

Y de ser así, porque es que sucede eso??? al final de cuentas eso es lo que hace el compilador de Delphi al crear el formulario, que no?

No estaría yo tan seguro que sea tanto el ahorro, pero sí debe disminuir el tamaño. Todas las propiedades de las componentes y formularios que se establecen en tiempo de diseño (es decir, el DFM), se guardan como recursos dentro del ejecutable. Al hacerlo por código, eliminas ese recurso del ejecutable.

// Saludos

Yo creo que mas bien se refería a eliminar la unidad Forms, que es un peso pesado, de tu proyecto y crear las ventanas llamando solo a funciones de la API. Así si que la reducción es espectacular. Y si además eliminas la unit Classes, ya estamos hablando de algo realmente pequeño.

Lo malo es que quitando esas clases pasamos, como bien dice roman, de RAD (Rapid application development) a SAD (Slow ??? application development) :D , es decir, un montón de lineas para crear una ventana, un montón de lineas para crear un boton, etc ...

Pero Nuño habla de crear hasta Querys y controles dataaware ahorrando 1.5 kb por control, ahi si me imagino que sería una jodienda crear un IBQuery o ADOQuery por llamadas al API, mas bien le habia entendido que las creaba por código, pero aún asi ahorrarse 1.5 Kb por cada componente no se se me hace muy dificil de creer.

SAD de slow y de :(

Yo también había pensado que Ñuño se refería a lo que hemos dicho antes: crear formularios a mano, con la API de Windows. Pero aún haciéndolo así, si te pones a usar las unidades DB, DBCtrls, StdCtrls, ExtCtrls, necesarias para lo que menciona (botones, querys, etc) pues viene a ser casi lo mismo: ejecutables de más de 300kb. Por ello, cuando leí el mensaje de xander, pensé que realmente se refería a quitar el dfm del ejecutable. Pero, al igual que xander, estoy escéptico en este punto.

// Saludos

Regresando al tema.
 

En definitiva si quieren crear una aplicacion buena de ese tipo (virus?) lo mejor es solo usar las APIs de Guindos... y lenguaje de maquina, ñuño me comprenderá en la idea, el pasarse a 32 bits no creo que le sea mucho lio.

Lo que yo cuido en mis aplicaciones son dos cosas... la primera es no utilizar ningun tipo de concatenacion de cadenas, pues suele ocupar varios Kb. lo mejor es siempre usar vectores concatenados con metodos de movimientos de memoria... lo segundo es no utilizar por ningun motivo la unidad SysUtils pues esa engorda en gran medida al ejecutable...

En algun momento les pasaré algunas de mis aplicaciones de esta clase... tengo como una docena y si realmente estan interesados les pasare parte del codigo, no si este foro lo permite pero si no, les paso por mail (los programas) y el codigo lo hago publico aca mismo.

PD: "uses windows;" y nada mas!!!

Ahh me olvidaba!
 

El asunto de lo que comentaba roman de las BDs... este tema de los "keygens" en definitiva es "bajar de nivel" lastimosamente estamos muy acostumbrados a utilizar lo que el IDE nos dá a primera vista... pero alguna vez hicieron Ctrl+Click... vieron todo lo que hay por debajo? y que pasa si se nos ocurre realizar nuestra propia interfaz con una base de datos creada por nosotros mismos? entonces si logramos menos de 100 Kb. con una BD.

Si hablamos de KeyGens y parecidos, necesariamente hablamos de bajo nivel y no es necesario hacer uso de las interfaces de BDs DBxxxx.pas

No, no, utilizaba las mismas clases VCL/CLX. Sólo asignaba las propiedades que utilizaba, dejando la mayor parte de los valores con su valor "por defecto" (por ejemplo: name, color, font, etc.), y eliminando todo lo posible de las cláusulas USES.

Es cierto que el ahorro no era mucho, pero siempre hay que valorar si el esfuerzo de hacerlo así merece la pena por el ahorro conseguido.

Eso sí, estuve una temporada aprendiendo a programar GTK+ y ahí sí que se notó un ahorro bárbaro...

Tengo serias dudas acerca de esa afirmación.
Simplemente por pura lógica.
Un Keygen no es más que un programa que a partir de un dato (Nombre de usuario) genera otro dato (Serial) utilizando una serie de cálculos. Para eso no hace falta en absoluto programar en ensamblador. Es más, en ensamblador sería bastante más tedioso que en cualquier otro lenguaje de medio-alto nivel.

Para hacer un "Patcher" pasa algo similar; Se trata de cambiar una serie de Bits de un fichero por otros distintos; BIS de lo explicado antes.

Doy por supuesto que una persona que genera Keygens no es tonta, por lo tanto no hay razón para usar ensamblador en una cosa que no se necesita.
En cuanto a los "patchers", como ya han dicho, ni siquiera programan, ya que existen múltiples herramientas que a partir de una plantilla y los datos que se le dan, genera ese ejecutable (que parchea otro) con un par de clicks.

La única razón para usar ensamblador sería el tamaño, pero existen otras alternativas; por ejemplo las KOL son un gran ejemplo, aunque hay más...

Volviendo al tema del lenguaje, he realizado una simple prueba, con varios programas; 7 en concreto. Después de desempaquetarlos y desemcriptarlos he obtenido:

* 2 Programados con Borland Delphi (delphi 4.0 y Delphi 7.0)
* 2 programado con Microsoft Visual C++
* 1 programado con LCC Win32
* 1 Microsoft Visual Basic 5.0 o 6.0
* 1 Desconocido

NOTA: Cierto que hay que saber ensamblador, pero no para generar los Keygen.
NOTA2: Llego un poco tarde, ya habéis avanzado bastante en el tema...

Ok
 

Comparto la idea naftali... el uso de lenguaje de maquina esta directamente relacionado con el tamaño y velocidad del producto final (ver tema).

Lo de los resultados analizados, en definitiva si eres bueno en lo que haces hasta en lenguajes etiquetados (HTML?) podemos dominar el mundo con pocos Kb. Pero no nos alejemos de Delphi que es nuestra herramienta principal.

mira te explico breve mente yo soy cracker y tu preguntas como programamos los keygen. a lo mejor ya se te contesto tu duda pero por si no te explico en el caso de la musica utilizamos bueno la mayoria utiliza musica en formato XM la cual no pesa mucho y es de buen formato para eso utilizamos la libreria Ufmod la cual nos permite reproducir la musica en XM aparte de eso utilizamos la herramienta eff la cual nos convierte la musica XM en un archivo .PAS que utiliza delphi el cual contiene el codigo de esa musica y se agrega de esta manera:
primero en uses declaramos Ufmod

despues abrimos el archivo .Pas y copiamos el codigo de la musica
en el evento oncreate metemos
Ufmod_Playsong(@xm,length(xm),xm_memory);
para tener la musica mientras este abierto el keygen

jaja creo que no me pero mira hace algunos dias hice un tutorial de como hacerlo te lo dejo aqui para que lo descargues espero que te sirva

http://rapidshare.com/files/22140361...i_by_ZELT_.rar

en cuanto los demas efectos por lo regular es puro codigo como para lograr el movimiento de algun texto o el desvanecimiento de la ventana a y porcierto a mi me gusta hacer mis keygen en delphi pero a otros en ensamblador y otros en visual todo depende del cracker y en que lenguaje le guste programar

Hola, tengo un programa que lleva una protección consistente en un "usb dongle" con el sistema Guardant Stealth III.

¿eso puede piratearse?

Lo pregunto sólo por curiosidad :D

Hola!

Si, si se puede. Te lo digo no porque yo conosca como hacerlo, sino porque tengo un software que viene con una llave usb en la version "flotante" es decir que primero debes de copiar la clave que viene en la llave a tu sistema y de ahi ya puedes usar el software en la pc que lo hayas instalado, el software lo puedes instalara en todas las maquinas que quieras pero solo con los datos de la usb funcionara. Cuando quieres ir a otra maquina debes de devolver la clave a la llave e instalarlo en la otra maquina. Es un gorro eso!

Pero como siempre los programadores rusos (¿que les enseñaban alla en el bloque oriental?) ya te dan la forma de brincarte eso y colocar tu clave en todas las maquinas que quieras.

No hay nada seguro e inviolable.