¿Como se hacen los programas estilo "keygen"?

[roman]

Pues tienes razón David. Ya lo he probado yo mismo y funciona como dices.

// Saludos

[xander]

A todo esto, ¿que c#ing@o$ es el XP Manifiesto ese??? pa que sirve o que onda??... me sirve de algo si estoy trabajando con Delphi2007 que según ya es para Vista y no para XP ???? o que onda?

[dec]

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:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
  	type="win32"
    name="DelphiApplication"
    version="1.0.0.0" 
  	processorArchitecture="*"/>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        publicKeyToken="6595b64144ccf1df"
        language="*"
        processorArchitecture="*"/>
    </dependentAssembly>
  </dependency>
</assembly>

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.

[xander]

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

[dec]

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.

[DarKraZY]

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.

[Black_Ocean]

Empezado por xander

A todo esto, ¿que c#ing@o$ es el XP Manifiesto ese??? pa que sirve o que onda??... me sirve de algo si estoy trabajando con Delphi2007 que según ya es para Vista y no para XP ???? o que onda?

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.

[Ñuño Martínez]

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.

[roman]

O sea, que de RAD pasó a SAD

// Saludos

[xander]

Empezado por Ñuño Martínez

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.

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?

[roman]

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

[[seoane]]

Empezado por xander

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

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) , es decir, un montón de lineas para crear una ventana, un montón de lineas para crear un boton, etc ...

[xander]

Empezado por seoane

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.

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.

[roman]

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

[Ñuño Martínez]

Empezado por seoane

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) , es decir, un montón de lineas para crear una ventana, un montón de lineas para crear un boton, etc ...

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...