O problema maior, no entanto, é quando uma software house decide parar de suportar um produto. Ou simplesmente a empresa pede falência e não há meios de comprar o software. Felizmente, a maioria desses produtos (que são muito específicos), são daqueles softwares que funcionam por uma quantidade de dias e depois não abrem mais até que se compre a licença.

Por explorarem pequenos nichos de mercado (para uma plataforma não tão disseminada por aí), nem sempre é possível achar soluções paleativas prontas. E na falta (eu desconheço alguma coisa tão boa quanto o IDA Pro para OS X) de um disassembler ou um debugger (para software sem símbolos de debug) é que surgem as soluções mais bizarras.

Esses programas usam a biblioteca padrão C para obter do sistema a data e a hora atual, e fazer um cálculo para determinar se o programa deve continuar funcionando ou não. Geralmente, em UNIX, usa-se as chamadas time() e gettimeofday() para obter essa informação. Como geralmente a biblioteca C não é compilada estaticamente (isto é: soldada ao binário do programa), é possível fazer um truque legal e parar o tempo.

O truque é simples e consiste apenas em criar uma biblioteca compartilhada que substitua as chamadas da biblioteca C do sistema. As funções que queremos substituir são simples: apenas retornam (de alguma forma) o UNIX time, portanto podem ser escritas em pouquíssimas linhas de C. Por exemplo, a chamada time() pode ser escrita dessa forma (retornando o UNIX time de agora pouco):

int time(void *trash) { return 1213097388; }

No caso da chamada gettimeofday(), precisamos de uma estrutura timeval (copiada da página de manual, mas trocamos os tipos time_t e suseconds_t por um unsigned, pois não queremos fazer o #include de cabeçalhos do sistema para evitar que a estrutura e/ou a chamada seja definida e cause um erro de compilação):

struct timeval {
unsigned tv_sec;    /* seconds since Jan. 1, 1970 */
unsigned tv_usec;  /* and microseconds */
};

Com essa estrutura em mãos, é fácil fazer a função substituta:

int gettimeofday(struct timeval *tv, void *trash) {
tv->tv_sec = 1213097388;
tv->tv_usec = 0;

return 0;
}

Pronto. O artefato capaz de parar o tempo está quase construído. Basta compilar.

A parte de compilar uma biblioteca compartilhada depende muito do sistema operacional; consulte o manual do gcc para saber dos específicos. No caso do OS X, é só usar a flag “-dynamiclib” e gerar o binário com uma extensão “.dylib” (não é realmente necessário, mas é interessante):

gcc -dynamiclib -o hiro-nakamura.dylib hiro-nakamura.c

Para carregar essa biblioteca junto com o programa também é uma tarefa que depende do sistema operacional. No caso do OS X, usa-se uma combinação de variáveis de ambiente:

export DYLD_FORCE_FLAT_NAMESPACE=1
export DYLD_INSERT_LIBRARIES=hiro-nakamura.dylib
export DYLD_BIND_AT_LAUNCH=YES

Pronto. Assim que rodar qualquer programa neste shell (no caso, bash, adapte o export para sua concha preferida), o tempo estará congelado.

Yatta!

No HardInfo, um módulo consiste em:

• Uma lista de entradas (cada item da lista é mostrado como subitem da árvore na GUI; por exemplo, o módulo “Devices” tem as entradas “Processor”, “Memory”, “PCI Devices” e assim por diante)
• Cada entrada possui uma função de obtenção de informações e uma função de callback
  • As funções de callback apenas retornam o que foi encontrado, como uma string (usando o formato do GKeyFile da GLib). É garantido que essas funções só serão chamadas após as funções de obtenção
  • Já as funções de obtenção são as que vasculham o ambiente procurando as informações necessárias
• Uma lista de métodos exportados (módulos podem chamar métodos de outros módulos)
• Uma lista de dependências de módulos (por causa da chamada de métodos de outros módulos)
• Informações de versão, copyright, descrição, etc.

É bastante coisa, mas acredite: tudo necessário. Os módulos atuais, embora não estejam com o código mais limpo e simples de entender possíveis, são uma boa fonte de consulta para entender como essas coisas se encaixam.

De qualquer forma, ao incluir o cabeçalho “hardinfo.h”, algumas estruturas e funções serão prototipadas. A partir disso, pode-se começar a criar o módulo:

#include "hardinfo.h"

void   scan_entrada(gboolean reload);
gchar *callback_entrada();

static ModuleEntry entries[] = {
 { "Entrada", "entrada.png", callback_entrada, scan_entrada },
};

static gchar *__entrada = NULL;

void
scan_entrada(gboolean reload)
{
   SCAN_START();

   if (!__entrada) {
      entrada = g_strdup("[Entrada]n"
                         "Olá Mundo=n");
   } else {
      g_free(entrada);

      entrada = g_strdup("[Entrada]n"
                         "Refresh=:)n");
   }

   SCAN_END();
}

gchar *callback_entrada()
{
   return __entrada;
}

/*
 * Retorna a lista de módulos. Não é necessário informar o tamanho, pois isso
 * é calculado em runtime.
 */
ModuleEntry *
hi_module_get_entries(void)
{
    return entries;
}

/*
 * O nome do módulo (como será mostrado na interface). O ícone não precisa ser
 * especificado, pois ele é o nome do arquivo ".so", mas com a extensão ".png".
 */
gchar *
hi_module_get_name(void)
{
    return g_strdup("Módulo Exemplo");
}

/*
 * O peso. Usado para selecionar a ordem do módulo na interface. Quanto maior o
 * seu valor (0~255), mais para baixo ficará.
 */
guchar
hi_module_get_weight(void)
{
    return 160;
}

/*
 * Se houver necessidade de inicializar alguma variável do módulo (como criar
 * tabelas hash, listas ligadas, árvores, etc), faça isso aqui.
 */
void
hi_module_init(void)
{
    g_warning("Olá mundo!");
}

/*
 * Chamado quando o usuário pede informações sobre o módulo (Help -> About Modules ->
 * Nome do Módulo).
 */
ModuleAbout *
hi_module_get_about(void)
{
    static ModuleAbout ma[] = {
      {
          .author       = "Foobar da Silva",
          .description  = "Exemplo de módulo para o HardInfo",
          .version      = VERSION,
          .license      = "GNU GPL version 2"
      }
    }; 

    return ma;
}

Feito isso, é só compilar o módulo. A maneira mais fácil é colocar o módulo no diretório do HardInfo, editar o Makefile.in e adicionar o nome do arquivo na variável MODULES; e, após isso, rodar o configure novamente. Ao executar make, seu módulo será compilado também.

Agora é só instalar e executar o HardInfo. Seu módulo deve aparecer automagicamente. Tente apertar o botão “Refresh” para ver o que acontece. Monitore também a saída no console, para ver se o Warning é realmente mostrado lá (ou se foi mostrado em uma caixa de diálogo). De agora em diante, basta transformar este módulo em algo útil, obtendo informações sobre o hardware ou software básico. E, claro, não deixe de contribuí-lo: as chances dele ser distribuído em uma nova versão são bem grandes.

Quando se programa com GTK+ (ou GLib) em C, muitas vezes faz-se necessário o uso de variáveis temporárias alocadas dinamicamente. O problema é ter que lembrar de liberá-las na hora correta — ou pior — ter que usar mais variávies auxiliares, como no exemplo abaixo:

gchar *funcao(void) {
gchar *temp = g_strdup("sou uma string temporaria");
return g_strdup_printf("%s -> %f", temp, G_PI);
}

Nesse exemplo, a variável temp irá vazar memória, pois ela não foi liberada após a execução do g_strdup_printf e do retorno da função. Uma maneira de resolver isso seria reescrevendo funcao como:

gchar *funcao(void) {
gchar *temp = g_strdup("sou uma string temporaria");
gchar *temp2 = g_strdup_printf("%s -> %f", temp, G_PI);
g_free(temp);
return temp2;
}

Agora está melhor: a variável temp não irá vazar, mas fomos obrigados a usar mais uma variável. A solução que proponho é bem simples, mas requer que seu programa rode na main loop da GLib. É para ser usado apenas em funções de callback. Não é threadsafe. Inclua essas duas pequenas funções em seu programa:

static gboolean __idle_free_do(gpointer ptr) {
g_free(ptr);
return FALSE;
}

void gpointer idle_free(gpointer ptr) {
g_idle_add(__idle_free_do, ptr);
return ptr;
}

Agora podemos reescrever a função teste como:

gchar *funcao(void) {
gchar *temp = idle_free(g_strdup("sou uma string temporaria"));
return g_strdup_printf("%s -> %f", temp, G_PI);
}

Assim a variável temp será liberada logo que o loop da GLib estiver livre para processar eventos. É uma idéia simples e prática… acho que deveria ser inclusa na GLib por padrão.

(façam o uso que quiser desse código, está em domínio público)

Using GLib main loop to free up temporary memory

When you program with GTK+ (or GLib) with C, sometimes there’s a need for temporary dynamically-allocated variables. The problem is to free them in the right time — or worse — having to use even more auxiliary variables, like in the example below:

gchar *func(void) {
gchar *temp = g_strdup("i am a temporary string");
return g_strdup_printf("%s -> %f", temp, G_PI);
}

In this example, the temp variable will leak memory, since it was not freed after g_strdup_printf. A way to fix this would be rewriting func as:

gchar *func(void) {
gchar *temp = g_strdup("i am a temporary string");
gchar *temp2 = g_strdup_printf("%s -> %f", temp, G_PI);
g_free(temp);
return temp2;
}

Much better: temp won’t leak anymore, but we had to use another variable. I propose a simpler solution, but it requires that your program runs in the GLib main loop. It should be used only on callback functions and is not threadsafe. Include these two tiny functions in your program:

static gboolean __idle_free_do(gpointer ptr) {
g_free(ptr);
return FALSE;
}

void gpointer idle_free(gpointer ptr) {
g_idle_add(__idle_free_do, ptr);
return ptr;
}

Now we can rewrite func as:

gchar *func(void) {
gchar *temp = idle_free(g_strdup("i am a temporary variable"));
return g_strdup_printf("%s -> %f", temp, G_PI);
}

This way the memory will be freed as soon as GLib gains control and the main loop is ready to process events.

• Ícones do Projeto Tango
• Reorganização dos módulos

• Adição de benchmark de FPU
• Possibilidade de salvar os resultados do benchmark como imagem (com barras de porcentagem relativa)

• Possibilidade de copiar as informações para a área de transferência
• Escolha do formato do relatório (texto puro ou HTML)
• Módulos podem exportar métodos. Outros módulos podem chamá-los. Isso adicionou um pouco de complexidade no carregamento dos módulos, já que há verificação de dependências
• Bugfixes (todos os reportados por email e pelos bugtrackers do Ubuntu e Debian)
• Nova API de módulos (mais eficiente e madura que a anterior, embora incompatível)

Todas as novidades mencionadas aqui (e na página de coisas a fazer do projeto) estão disponíveis no repositório Subversion. Quem tiver a possibilidade de testar, por favor o faça.