No outono deste ano, após 6 anos de desenvolvimento, foi lançada a primeira versão beta do "R1 / beta1" do sistema operacional
Haiku . Eu acompanho este projeto interessante há muito tempo, que visa recriar e desenvolver ainda mais o sistema
BeOS que existia em 1994-2000. Portanto, assim que vi notícias sobre o lançamento da versão beta do Haiku nos sites de notícias de TI, decidi imediatamente ver o que seria adicionado a esse tão esperado lançamento. Depois de instalar o sistema na máquina virtual
VirtualBox e conhecer um pouco da funcionalidade principal, achei que seria bom ajudar a comunidade OpenSource, que está desenvolvendo esse sistema operacional, um pouco hoje. Decidi começar com o que ganhei um pouco de experiência: portando alguns projetos de jogos.
A área de trabalho do sistema operacional Haiku.Mais tarde, tentei refinar alguns aplicativos e bibliotecas existentes. Esta é minha pequena atividade em vários repositórios de código aberto aos quais este artigo será dedicado. Nele, descreverei consistentemente os problemas que encontrei e falarei sobre métodos para resolvê-los. Tentei enviar a maioria dos patches que foram feitos durante esse trabalho para os projetos existentes, a fim de fornecer suporte ao Haiku e interessar seus desenvolvedores à existência de sistemas operacionais alternativos.
O sistema operacional Haiku usa um
núcleo híbrido , que é uma implementação da arquitetura de microkernel com a capacidade de carregar dinamicamente os módulos necessários. Ele é baseado no fork do kernel do
NewOS , desenvolvido por um ex-engenheiro da
Be Inc. , Por Travis Geiselbrecht. Hoje, esse desenvolvedor está trabalhando no Google em um kernel chamado
Zircon para o novo sistema operacional
Google Fuchsia , mas isso é outra história. Portanto, como os desenvolvedores do Haiku declaram compatibilidade binária com o BeOS, eles são forçados a suportar não dois ramos arquitetônicos familiares, mas três: x86_64, x86 e x86_gcc2. A última arquitetura é uma carga de compatibilidade com o compilador da versão antiga do
GCC 2.95. É graças a ela que é possível executar aplicativos escritos para o sistema operacional BeOS original. Infelizmente, devido a essa carga de compatibilidade, os desenvolvedores do Haiku não podem usar os recursos modernos da linguagem de programação C ++ nas APIs do sistema. No entanto, eles preparam imagens de instalação para apenas duas arquiteturas: x86_64 e x86. O fato é que a distribuição do Haiku para x86 é híbrida: apesar de todos os componentes do sistema serem construídos sob x86_gcc2 para compatibilidade binária, o usuário tem a oportunidade de instalar ou criar aplicativos modernos projetados com compiladores modernos e arquitetura x86 . A distribuição do Haiku para a arquitetura x86_64 é totalmente de 64 bits e não tem a capacidade de executar aplicativos BeOS e Haiku de 32 bits. No entanto, há compatibilidade no nível da API, portanto, se você tiver o código-fonte do aplicativo para BeOS ou Haiku x86 em mãos, poderá compilá-lo facilmente no Haiku x86_64 e tudo deverá funcionar. Uma imagem do sistema operacional para a arquitetura x86_64 é recomendada para instalação em hardware real, se você não precisar de suporte para aplicativos BeOS específicos ou aplicativos Haiku de 32 bits.
Vale dizer que neste sistema operacional há suporte parcial para o padrão
POSIX . Essa base o torna semelhante a sistemas do tipo UNIX e facilita a portabilidade de seu software. A principal linguagem de programação é C ++, é usada ativamente, uma vez que as APIs públicas do Haiku buscam principalmente um paradigma de programação orientada a objetos. No entanto, ninguém proíbe o uso da linguagem de programação C, apenas na maioria dos casos é necessário escrever as camadas de compatibilidade correspondentes. A interface do software do sistema operacional é agrupada em estruturas de sistema separadas, responsáveis por uma oportunidade específica, por exemplo, por uma interface ou suporte de rede. É um pouco como o que está disponível no
macOS ou na estrutura
Qt . Observe que este sistema operacional é de usuário único, embora haja algum progresso no sentido de fornecer um modo de trabalho multiusuário para os desenvolvedores do Haiku.
Não posso deixar de compartilhar com os leitores deste artigo a experiência positiva do uso do sistema avançado de gerenciamento de janelas de aplicativos que está disponível no Haiku. Na minha opinião, é um dos mais convenientes e, a seu modo, é a marca registrada deste sistema operacional.
Gerenciamento avançado de janelas no sistema operacional Haiku: suporte para ladrilhos e guias.O Windows pode ser fixado em guias, como é feito nos navegadores modernos, anexados um ao outro e redimensionados de maneira conveniente.
Lado a lado simples , transferindo os contextos de alguns aplicativos de uma janela para outra, e os
replicantes são suportados. Você pode ler mais sobre todos os recursos do sistema de janelas local na
documentação oficial , onde todas as teclas de atalho necessárias estão descritas lá.
Não escreverei neste artigo uma visão geral completa de todos os recursos e capacidades do Haiku, pois quem estiver interessado poderá encontrar facilmente as informações necessárias na Internet.
Conteúdo:
1. Pacotes e repositórios no Haiku2. Primeiros Passos: Portando Adamant Armor Affection Adventure3. Modificação da porta NXEngine existente (Cave Story)4. Portando o jogo Gish5. O projeto BeGameLauncher, que permite criar rapidamente lançadores para jogos6. Portando o Xash3D: Jogo Lendário da Meia-Vida e Complementos Oficiais7. Portando as duas partes do jogo Serious Sam: The First Encounter e The Second Encounter8. Portando o jogo Vangers9. Implementação de diálogos na biblioteca SDL2 para Haiku10. Portando meu garfo do Cool Reader11. Finalização do programa KeymapSwitcher12. Conclusão1. Pacotes e repositórios no Haiku
Comparado ao BeOS original, uma inovação significativa apareceu no Haiku: um sistema de gerenciamento de pacotes que inclui várias ferramentas para obter e instalar software de várias fontes. Essas fontes podem ser os repositórios oficiais do
Haiku e
HaikuPorts , repositórios não oficiais e simplesmente pacotes HPKG separados e especialmente preparados. Tais recursos para instalação e atualização de software são conhecidos no mundo dos sistemas operacionais semelhantes ao Unix, mas agora todo o seu poder e conveniência chegaram com sucesso ao Haiku, que não pode deixar de agradar aos usuários comuns desse sistema operacional. Graças à infraestrutura criada em torno do gerenciador de pacotes, agora qualquer desenvolvedor pode portar facilmente um novo ou modificar um aplicativo de código aberto existente e adicionar os resultados de seu trabalho ao repositório de portas do software HaikuPorts, após o qual estarão disponíveis para todos os usuários do Haiku. Como resultado, o ecossistema resultante se assemelha ao dos sistemas operacionais macOS com seu
Homebrew , FreeBSD com suas
portas , Windows com
MSYS2 ou Arch Linux com seu
AUR .
Uma ferramenta para criar pacotes e software de portabilidade, chamada
HaikuPorter , é fornecida separadamente do sistema operacional e é instalada usando um pequeno
manual localizado no repositório no GitHub. Depois de instalar esse utilitário no mesmo GitHub, a árvore inteira da receita é baixada, na qual o desenvolvedor está trabalhando. A receita é um script comum do Shell com instruções nas quais o HaikuPorter coletará o pacote HPKG necessário. Vale ressaltar que a ferramenta em si é escrita na
linguagem de programação
Python 2, interage estreitamente com o sistema de gerenciamento de pacotes existente e usa a ferramenta padrão
Git internamente para corrigir alterações no código fonte do software e gerar um conjunto de patches. Graças a essa pilha de tecnologias, fazer receitas para criar pacotes HPKG e patches de software na forma de arquivos de conjunto de patches é muito conveniente e simples. Na maioria dos casos, tive que usar apenas três comandos ao trabalhar com o HaikuPorter:
alias hp="haikuporter -S -j4 --get-dependencies --no-source-packages" hp libsdl2 hp libsdl2 -c hp libsdl2 -e
O primeiro comando simplesmente coleta o pacote selecionado, o segundo comando limpa o diretório de construção e o terceiro cria ou atualiza um conjunto de correções de acordo com suas alterações que foram registradas no repositório Git do diretório de trabalho por meio de confirmações.
Portanto, para publicar um pacote no repositório do HaikuPorts e disponibilizá-lo a todos os usuários do Haiku, o desenvolvedor deve instalar o HaikuPorter, expandir a árvore de receitas, coletar o pacote HPKG localmente e testá-lo, e depois se comprometer com o garfo da árvore de receitas. faça uma
solicitação Pull no GitHub. Os desenvolvedores do Haiku devem considerar o trabalho publicado, após o qual decidem mesclar suas alterações no repositório ou enviá-las para revisão. Se as alterações forem aceitas, o mesmo HaikuPorter instalado no servidor de compilação coletará remotamente o pacote e o publicará automaticamente no repositório.
Um programa especial do
HaikuDepot foi adicionado à versão beta do "R1 / beta1" do sistema operacional Haiku, que permite trabalhar com pacotes e repositórios por meio de uma interface gráfica do usuário, em vez dos comandos do console no terminal.
O programa HaikuDepot em execução no sistema operacional Haiku.Graças a essa ferramenta, usuários inexperientes e iniciantes do Haiku podem gerenciar convenientemente sua base de pacotes. Vale ressaltar que esse aplicativo não é apenas um shell da GUI sobre o gerenciador de pacotes existente, mas também implementa funcionalidades adicionais. Por exemplo, usuários autorizados podem avaliar e escrever resenhas em pacotes disponíveis para instalação. Além disso, o HaikuDepot possui um site especial do
Haiku Depot que permite exibir alterações de pacotes na Internet ou fazer download de pacotes individuais de HPKG.
<< Pular para o conteúdo2. Primeiros Passos: Portando Adamant Armor Affection Adventure
Depois de me familiarizar com a funcionalidade do sistema operacional na máquina virtual VirtualBox, decidi avaliar a biblioteca SDL2 nela e portar o jogo
Adamant Armour Affection Adventure para o Haiku, que escrevi sobre a transferência para a plataforma Android anteriormente. A criação do programa não exigiu nenhuma alteração no código-fonte, apenas instalei todas as ferramentas, bibliotecas e arquivos de cabeçalho necessários no repositório e executei o seguinte:
cmake -DCMAKE_BUILD_TYPE=Release -DGLES=off -DANDROID=off -DCMAKE_C_FLAGS="-D__linux__" -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake --build . = off -DCMAKE_C_FLAGS = "- D__linux__" -DSDL2_INCLUDE_DIR = `finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR =` finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake -DCMAKE_BUILD_TYPE=Release -DGLES=off -DANDROID=off -DCMAKE_C_FLAGS="-D__linux__" -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake --build .
Como o Haiku possui POSIX, o -D__linux__ ou
-D__unix__ define muitos dos problemas associados à definição de uma plataforma. No entanto, vale ressaltar que é melhor abandonar seu uso e implementar o suporte do Haiku no código-fonte do projeto, se houver problemas de construção semelhantes. Chamar o utilitário de sistema
finddir com um argumento específico permite obter o caminho correto para os arquivos de cabeçalho de várias arquiteturas.
Então, executando os comandos acima, compilei um arquivo executável que funcionava perfeitamente e o jogo funcionava perfeitamente. Eu pensei que seria legal preparar um pacote auto-suficiente de HPKG com o jogo e, para isso, entrei na Internet em busca das informações necessárias. Então, eu não conhecia nenhuma ferramenta conveniente para portar software, como o HaikuPorter, sobre o qual escrevi na seção acima; portanto, para alcançar meu objetivo, decidi trapacear e desmontar alguns pacotes do sistema para ver como eles estão organizados por dentro e por fora. faça por analogia.
Na Internet, encontrei as
informações desejadas, após as quais descompactei um pacote aleatório do sistema usando o arquivador
Expander incorporado ao gerenciador de arquivos local, encontrei o arquivo
.PackageInfo , editei-o e, de acordo com a estrutura do meu aplicativo, substitui os arquivos. Depois, executei os comandos para criar o pacote HPKG e instalá-lo no sistema:
package create -C AAAA/ aaaa.pkg pkgman install aaaa.pkg
Infelizmente, o lançamento do jogo no menu "Aplicativos" não teve êxito. Ao executar o executável no terminal, recebi um erro dizendo que era impossível encontrar os arquivos de dados necessários para executar e executar o aplicativo. Nesse caso, se no terminal, vá para o diretório do pacote de aplicativos, tudo começou bem. Isso me levou à ideia de que, ao iniciar o jogo no menu, é necessário fazer uma alteração forçada no diretório do aplicativo. Isso pode ser feito com um script do Shell ou alterando a fonte do jogo. Eu escolhi a segunda opção e adicionei algo semelhante a este código:
#ifdef __HAIKU__
No início da função start
main () , que resolveu completamente esse problema e o pacote acabou sendo viável. Nos comentários das notícias sobre o lançamento da versão beta do Haiku no
Linux.org.ru, deixei o link para o meu pacote montado e pedi a alguém que me enviasse para algumas comunidades de usuários ativas desse sistema operacional e depois fui para a cama.
Porta de jogo Adamant Armor Affection Adventure rodando no Haiku.De manhã, uma pessoa usando o apelido
3dEyes me escreveu um e-mail. Como se viu depois,
Gerasim Troeglazov , um dos desenvolvedores ativos do Haiku e autor da porta do framework Qt para esse sistema operacional, estava escondido atrás desse nome. Ele me mostrou o repositório HaikuPorts e me disse como usar o utilitário HaikuPorter. Além disso, ele escreveu uma receita para a construção do pacote HPKG para a Adamant Armour Affection Adventure e o adicionou ao HaikuDepot.
Após analisar todas as alterações feitas por esse desenvolvedor, notei que havia algumas desvantagens no meu pacote montado manualmente, por exemplo, as configurações não foram salvas, pois os diretórios montados dos pacotes instalados não tinham recursos de gravação. Esse problema com a gravação de configurações ou salvamentos em seu pacote foi resolvido de forma elegante com a ajuda de links simbólicos em um diretório especial acessível para gravação e destinado a salvar dados do usuário. Meu pacote também não tinha seu próprio ícone original.
Além disso, aprendi que o Haiku não possui aceleração de hardware de gráficos 3D e o mesmo OpenGL é renderizado programaticamente usando a energia da CPU. Para aplicações gráficas pesadas, isso obviamente não é bom, mas para jogos mais antigos isso é mais do que suficiente. Até decidi verificar especificamente o pacote do jogo e instalei o Haiku no meu laptop antigo, ou seja, em hardware real. Para minha surpresa, a imagem Adamant Armor Affection Adventure foi renderizada com tanta rapidez que, se eu não soubesse da falta de aceleração de hardware, não teria notado que a renderização foi feita pelo meu processador.
Fonte do projeto: https://github.com/EXL/AdamantArmorAffectionAdventureAdiei a criação manual de pacotes HPKG até tempos melhores e mudei completamente para usar a ferramenta HaikuPorter e escrever receitas. Mas às vezes há situações em que é necessária a reconstrução manual do pacote. Por exemplo, se o HaikuPorter definir a versão noturna do Haiku no arquivo
.PackageInfo muito alta e o pacote precisar ser testado na versão de lançamento do sistema operacional. Vale a pena notar que foi graças à capacidade de resposta e à experiência do Gerasim que eu pude entender as muitas sutilezas da criação de pacotes para o sistema operacional Haiku e continuei meu trabalho ainda mais.
<< Pular para o conteúdo3. Modificação da porta NXEngine existente (Cave Story)
Fiquei incrivelmente surpreso ao encontrar uma receita no repositório HaikuPorts que referenciava meu fork do mecanismo
NXEngine para o jogo Cave Story , que eu estava
analisando no meu
blog há muito tempo. A receita e os patches foram preparados por um desenvolvedor chamado
Zoltán Mizsei , que usa o apelido
extrowerk e é um mantenedor ativo de muitos pacotes para o Haiku.
Uma análise superficial, instalando o pacote e iniciando o aplicativo, revelou os mesmos problemas que descrevi na seção anterior deste artigo: o salvamento do jogo não funcionou, as configurações também não foram salvas e o pacote não tinha o ícone original. Decidi corrigir essas deficiências e comecei a trabalhar no patch, integrando primeiro todas as idéias da extrowerk. Eu escrevi o
Makefile original para o sistema operacional Haiku e corrigi a gravação e salvou vários dados do usuário.
Jogo Port of the Cave Story baseado no mecanismo NXEngine, lançado no sistema operacional Haiku.Como o jogo assumiu as versões em russo e inglês com um conjunto diferente de arquivos executáveis e arquivos de dados, decidi criar um pacote comum que combina duas versões ao mesmo tempo e seleciona automaticamente a correta com base no idioma do sistema escolhido pelo usuário. Isso foi implementado pelo script Shell mais simples:
Este script é iniciado quando um item de jogo é selecionado no menu "Aplicativos" e determina a localidade atual do sistema. Caso o usuário escolha o russo como idioma do sistema, a versão em russo do jogo iniciará e, em todos os outros casos, a versão em inglês.
Mas com a criação do ícone original para o aplicativo eu tive que mexer bastante. O fato é que no sistema operacional Haiku são
permitidos apenas ícones vetoriais do formato
HVIF especial, que são configurados como atributos do
sistema de arquivos
Be File System . Na documentação oficial, existem dois manuais grandes sobre como criar seus próprios ícones para aplicativos: o
primeiro manual descreve o estilo de desenho e design e o
segundo manual detalha como usar o programa de sistema
Icon-O-Matic projetado para criar ícones.
O Icon-O-Matic permite importar os arquivos SVG mais simples e exportar o ícone resultante para o formato necessário para o HaikuPorter, chamado HVIF RDef e representando o mesmo HVIF, mas convertido em uma exibição de texto. Os arquivos RDef podem conter não apenas imagens, mas também informações adicionais, por exemplo, a versão do aplicativo e sua descrição. De certa forma, esses arquivos se assemelham aos arquivos RES usados no Windows. Os seguintes comandos na receita compilam os arquivos RDef e configuram o resultado para atributos especiais:
rc nxengine-launcher.rdef resattr -o "$appsDir/NXEngine/Cave Story" nxengine-launcher.rsrc addResourcesToBinaries $sourceDir/build/nxengine-rus.rdef "$appsDir/NXEngine/RUS/Cave Story"
Além disso, a função
addResourcesToBinaries é definida nas receitas, o que permite automatizar este trabalho. Há um problema, mas muito sério, com o Icon-O-Matic: os arquivos SVG salvos pelo popular editor de vetores do
Inkscape não abrem ou são importados sem o suporte de alguns recursos necessários, por exemplo, gradientes. Portanto, em uma missão de aventura com a conversão de imagens raster em vetor, usando vários conversores online e offline pagos e gratuitos e abrindo os arquivos SVG resultantes no Icon-O-Matic, falhei miseravelmente. Mais tarde, resolvi o problema de abrir arquivos SVG e encontrei uma solução alternativa, mas escreverei sobre isso abaixo. Enquanto isso, decidi aproveitar os recursos padrão do Icon-O-Matic e desenhar o ícone sozinho. Após meia hora de cópia impressa de pixels, obtive a seguinte arte:
O programa Icon-O-Matic padrão no sistema operacional Haiku.Sim, usei um editor de vetores para criar uma imagem no gênero Pixel Art. Na minha visão amadora de um homem pouco versado em arte, ficou muito bem. Salvei este ícone no formato necessário, preparei todas as alterações, atualizei a receita e enviei tudo para o repositório HaikuPorts.
Código fonte do projeto: https://github.com/EXL/NXEngineEnviei os pacotes resultantes apenas por precaução e para o site de fãs do jogo
Cave Story (Doukutsu Monogatari) , cuja administração adicionou o sistema operacional Haiku à seção de downloads.
<< Pular para o conteúdo4. Portando o jogo Gish
O próximo projeto que decidi transferir para o Haiku foi o jogo
Gish , que eu já havia portado para o Android. O repositório HaikuPorts tinha uma receita para uma implementação gratuita inacabada de um jogo chamado
Freegish , então decidi adicionar o jogo original também, mas sem arquivos de dados, pois eles, ao contrário do mecanismo, são entregues separadamente e não são de todo gratuitos.
Porta de jogo Gish em execução no sistema operacional Haiku.Não tive problemas especiais com a portabilidade deste jogo. O arquivo executável foi compilado imediatamente após a execução dos seguintes comandos de compilação:
cmake gish/src/main/cpp/ \ -DGLES=0 \ -DANDROID=0 \ -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` \ -DCMAKE_C_FLAGS="`sdl2-config --cflags` -D__linux__" \ -DCMAKE_BUILD_TYPE=Release cmake --build .
Em seguida, implementei a capacidade de iniciar o jogo no menu "Aplicativos" e forneci suporte para salvar dados do usuário em um diretório acessível para gravação e destinado a isso:
char* getHaikuSettingsPath() { char path[PATH_MAX]; find_directory(B_USER_SETTINGS_DIRECTORY, -1, false, path, sizeof(path)); strcat(path, "/Gish/"); return strdup(path); }
A função
getHaikuSettingsPath () usando a função
find_directory () da API do Haiku forma o caminho completo para o diretório que eu preciso.
Código fonte do projeto: https://github.com/EXL/GishFaltava resolver a seguinte pergunta: como o usuário deveria escolher o diretório com os arquivos originais do jogo Gish? Você poderia tentar resolver o problema usando scripts do Shell e o utilitário do sistema de
alerta , mas decidi abordar esse problema mais detalhadamente e implementar um conveniente iniciador de GUI usando a API Haiku e a estrutura do
Kit de interface .
<< Pular para o conteúdo5. O projeto BeGameLauncher, que permite criar rapidamente lançadores para jogos
Foi decidido escrever meu projeto BeGameLauncher em C ++ do antigo padrão de 1998, usando as ferramentas nativas do sistema operacional para criar aplicativos com uma interface gráfica do usuário. Como os nomes de muitos programas do Haiku e BeOS começam com o prefixo "Be", também decidi escolher esse nome para o projeto. Decidi começar familiarizando-me com a estrutura do Kit de Interface, que faz parte da API do Haiku. Além da documentação bastante detalhada no site oficial do Haiku, encontrei dois
cursos de aula simplesmente excelentes do
DarkWyrm que permitem que um desenvolvedor iniciante entenda rapidamente como determinadas classes do sistema funcionam. O primeiro curso é chamado
Aprendendo a Programar com o Haiku e, no início, aborda os conceitos básicos da linguagem de programação C ++, que será muito útil para iniciantes. O segundo curso é chamado de
Programação com o Haiku e é direcionado para aqueles que já conhecem o C ++ e possuem conhecimentos básicos dessa linguagem. Ambos os cursos falam sobre os mais diversos aspectos da API do Haiku e, portanto, serão muito úteis para quem deseja começar a criar aplicativos para esse sistema operacional.
Depois de ler este excelente material na diagonal, fiz uma impressão geral da API do Haiku e comecei a pensar nos meus próximos passos. Eu já tinha alguma experiência no desenvolvimento de aplicativos usando a estrutura Qt, que também é escrita na linguagem de programação C ++ e usa o paradigma de programação orientada a objetos. Portanto, a API do Haiku é muito semelhante a ela, exceto pela falta de um sistema de sinal e slots, então muitas vezes traçarei alguns paralelos e comparações com o Qt. Além disso, vale ressaltar o uso do princípio de
programação orientada a
eventos , comum na API do Haiku, que permite que várias entidades interajam através da transmissão de eventos ou mensagens. Um análogo da classe
QEvent aqui é a classe
BMessage , em torno da qual o sistema de interação de objetos é construído. Uma instância da classe
BMessage geralmente obtém um número exclusivo que permite identificar o remetente e sua ação em um filtro de evento comum.
Para o meu projeto, tive que escolher as classes apropriadas da API do Haiku que me permitiriam implementar a funcionalidade pretendida. Primeiramente, para iniciar um aplicativo externo, era necessário encontrar um análogo da classe
QProcess ou da função
execve () POSIX, que, aliás, também funciona bem no sistema operacional Haiku, no entanto, decidi que seria preferível usar ferramentas nativas, mas apenas no caso o caso deixou a possibilidade de iniciar aplicativos por meio da função POSIX. A classe de comunicação entre processos
BRoster foi ótima para esse fim. Ele encontrou um método
Launch () adequado que permite especificar o caminho para o arquivo executável e passar argumentos para ele. Como o iniciador deve salvar alguns parâmetros, por exemplo, um diretório selecionado pelo usuário com arquivos de dados do jogo, eu precisava de uma classe que faça tudo isso. No Qt, essa classe é chamada
QSettings e, na API do Haiku, como o Gerasim me solicitou, existe uma classe
BMessage que eu já
conheço , que possui um recurso muito útil. O fato é que as informações dessa classe podem ser facilmente serializadas e, por exemplo, salvas no disco. Isso é muito conveniente e costuma ser usado para registrar quaisquer dados do usuário em programas, e foi por isso que escolhi essa classe para salvar as configurações do meu projeto para implementar os lançadores.
Infelizmente, a API Haiku não encontrou um análogo da classe QDebug , então acabei de enviar a saída de depuração para mim durante o processo de desenvolvimento para stderr usando a função fprintf () da linguagem de programação C padrão:
Eu agrupei essa função em uma entidade BeDebug () que é conveniente para mim , que, dependendo do padrão de idioma selecionado, é uma macro ou também uma função. Isso foi feito devido ao fato de o C ++ 98 não suportar macros com um número variável de argumentos.A estrutura Qt também possui uma classe QMessageBox útil, através da qual você pode criar uma caixa de diálogo modal com qualquer informação que o usuário deva prestar atenção, por exemplo, um erro ou aviso. A API do Haiku possui uma classe BAlert para esse fim .cuja implementação é um pouco diferente do que está disponível no Qt. Por exemplo, um objeto dessa classe deve ser criado no heap, e não na pilha, porque após alguma ação do usuário, ele deve se excluir. Quanto às outras classes da interface gráfica, aqui não tive absolutamente nenhuma dificuldade e encontrei tudo o que precisava sem problemas.Agora eu deveria ter pensado sobre a arquitetura simples do projeto. Decidi me concentrar na criação de uma biblioteca estática, na qual haveria duas classes projetadas para herdar suas próprias classes derivadas. A primeira e mais importante classe, BeLauncherBase, é responsável pela criação da janela principal do iniciador, pela transferência de todos os parâmetros do usuário e pela capacidade de adicionar seus próprios elementos da GUI. A segunda classe, BeAboutWindow , é simplesmente responsável por abrir a caixa de diálogo "Sobre o programa ..." com informações exibidas em uma janela separada. Assim, um programador precisa executar duas etapas simples para criar seu iniciador, por exemplo, para jogar Gish: class GishAboutWindow : public BeAboutWindow { ... }; class GishLauncher : public BeLauncherBase { ... }; int main(void) { BeApp *beApp = new BeApp(SIGNATURE); GishLauncher *gishLauncher = new GishLauncher(BeUtils::GetPathToHomeDir()); beApp->SetMainWindow(gishLauncher); beApp->Run(); delete beApp; beApp = NULL; return 0; }
Primeiro, crie uma função inicial apropriada main () e, em segundo lugar, simplesmente herde das duas classes acima e implemente os métodos necessários nelas. Depois disso, compilamos o arquivo C ++ resultante com um link para minha biblioteca estática e nosso iniciador para o jogo Gish está pronto.Diálogo "Sobre o programa ..." no iniciador do porto do jogo Gish.Em seguida, pensei em como transferir parâmetros do meu iniciador para o próprio mecanismo ou para o arquivo executável do jogo. Vi apenas duas maneiras de resolver esse problema. A primeira maneira foi alterar as variáveis de ambiente. Na prática, depois de clicar no botão "Executar", o iniciador simplesmente coloca todos os parâmetros nas variáveis de ambiente, chamando a função setenv () , e o mecanismo do jogo lê esses parâmetros usando a função getenv () , que parece bastante simples. O único problema que poderia surgir aqui era na classe BRoster e seu método Launch (): Não sabia se o aplicativo iniciado com a ajuda dessa classe herdaria todas as variáveis de ambiente definidas no iniciador. Após um pequeno experimento, a herança das variáveis de ambiente foi confirmada e eu implementei completamente esse método no meu projeto. A segunda maneira de resolver o problema era definir parâmetros especiais da linha de comando. Na prática, o iniciador simplesmente coloca todas as configurações nos argumentos apropriados e chama o aplicativo executável com elas. Mas o mecanismo de jogo já tinha que processá-los de forma independente, o que criou algumas dificuldades. Por exemplo, se o jogo não assumisse a possibilidade de especificar o caminho para os arquivos do jogo por meio de parâmetros da linha de comando, seria necessário modificar o analisador de argumentos no próprio mecanismo. Apesar desses problemas,Eu implementei esse modo de interação e, como resultado, tive uma grande oportunidade de combinar tudo. Isso me permitiu criar uma string para especificar argumentos do usuário em alguns lançadores.Quando tudo foi projetado, decidi escolher um sistema de montagem para o meu projeto. Apenas duas opções foram consideradas: Makefile "on steroids" e CMake . No primeiro caso, os desenvolvedores do sistema operacional Haiku prepararam um pacote conveniente de mecanismo de makefile no qual coletaram todos os recursos necessários que um desenvolvedor enfrentaria ao começar a escrever um aplicativo na API do Haiku, por exemplo, geração automática de tradução e compilação de recursos de aplicativos. Mas eu não sou um dos que procuram maneiras fáceis, então escolhi o CMake e transferi parte do trabalho do pacote makefile-engine para ele. Como resultado, você pode ver o script de montagem monstruoso resultante no repositório do projeto, um link para o qual deixarei abaixo.Captura de tela do iniciador de portas de jogos Gish para o Haiku.Gostaria de escrever algumas palavras sobre a localização de aplicativos. Na estrutura Qt, existe uma conveniente função de empacotador tr () para isso , dois utilitários auxiliares lrelease e lupdate , envolvidos na geração de arquivos de tradução. Incluso na estrutura, existe ainda um programa Qt Linguist especial, com uma conveniente interface gráfica de usuário projetada para tradutores. Na API do Haiku, as ferramentas de localização de aplicativos são menos convenientes e mais arcaicas. Propõe-se quebrar as linhas que precisam ser traduzidas em uma macro especial B_TRANSLATE () e adicionar a definição B_TRANSLATION_CONTEXT ao arquivo de origem, que separa um grupo de cadeias de caracteres traduzíveis de outro. Depois disso, algo muito estranho precisa ser feito: defina o pré-processador do compilador com o sinalizador -DB_COLLECTING_CATKEYS em absolutamente todos os arquivos de origem do projeto, faça alguma mágica com o utilitário grep e, finalmente, obtenha um enorme arquivo PRE. É com esse arquivo que o utilitário collectcatkeys funcionará , o que já criará arquivos CATKEYS tradutores legíveis por humanos e fáceis de editar. Após localizar as seqüências, você precisa usar o utilitário linkcatkeys , . , . , Haiku API . ,
Localizing an application , . , BeOS
Locale Kit Haiku.
C++. , Haiku Qt, HaikuPorts IDE,
Qt Creator KDevelop . Além disso, existe uma porta JVM que permite usar IDEs gravados na linguagem de programação Java, por exemplo, NetBeans ou IntelliJ IDEA . Optei pelo ambiente de desenvolvimento do Qt Creator, especialmente porque em suas versões mais recentes há uma análise de alta qualidade do código usando o analisador LibClang , que funciona com muito mais precisão e rapidez do que o analisador padrão.O ambiente de desenvolvimento integrado Qt Creator em execução no sistema operacional Haiku.Em termos de IDEs conhecidos e de plataforma cruzada no Haiku, está tudo bem. Mas e as soluções exclusivas? Não posso deixar de mencionar um projeto muito interessante, patrocinado pela DarkWyrm e que atualmente apóia Adam Fowler , chamado Paladin . Este programa torna o editor de texto Pe disponível na distribuição do sistema operacional quase um IDE real.Paladin IDE para Haiku instalado a partir do repositório HaikuPorts.Usando o mosaico integrado no sistema de janelas Haiku, você pode anexar a janela do Paladin na lateral do editor Pe e adicionar um terminal. Também no repositório HaikuPorts, existe um conveniente editor de texto Koder que se assemelha ao popular programa Notepad ++ para Windows e também se baseia na experiência do projeto Scintilla . Para o meu aplicativo, criei um arquivo PLD do projeto e agora qualquer desenvolvedor que use o Paladin IDE pode facilmente abrir meu projeto neste programa.Quando o ambiente de desenvolvimento do Qt Creator foi configurado e pronto para começar, comecei a perceber todos os recursos planejados. O primeiro problema que encontrei foi relacionado a controles de dimensionamento ao alterar o tamanho da fonte do sistema. Inicialmente, no BeOS, todo o código de posicionamento de elemento da GUI era definido explicitamente em coordenadas. Foi muito inconveniente, detalhado e criou uma enorme pilha de problemas, por exemplo, com a mesma alteração no tamanho da fonte, toda a forma do aplicativo foi dispersa e tornou-se inutilizável. Felizmente, o Haiku tentou resolver esse problema e adicionou a API de layout , que faz parte da estrutura do Kit de interface.Layout API Haiku.Layout API, . Haiku
Laying It All Out , , .
Outro problema foi identificado por Gerasim quando ele tentou usar minha biblioteca para criar um iniciador para o jogo que ele portava. O fato é que muitas vezes recorri ao código fonte do próprio sistema operacional Haiku para implementar várias funcionalidades. Em particular, encontrei um exemplo de como usar o método Launch () em um objeto da classe BRoster . O problema se manifestou no fato de que este exemplo estava incorreto e o mecanismo de jogo portado pela Gerasim não pôde analisar corretamente os argumentos definidos pelo iniciador. Tendo estudado o código-fonte do Haiku mais profundamente, consegui descobrir que o primeiro argumento, que deve conter o caminho completo para o arquivo executável, não precisa ser definido explicitamente no caso do método Launch () , pois ele será definido automaticamente.
A documentação para o método Launch () não diz que o primeiro argumento não é necessário, e provavelmente é por isso que o desenvolvedor escreveu esse código incorretamente. Corrigi esse erro no meu projeto e o problema do Gerasim resolveu sozinho. Mas e esse pequeno erro no próprio sistema operacional Haiku? Eu decidi consertá-la também. Felizmente, acabou sendo muito fácil de fazer! Você precisa fazer login usando o GitHub no recurso Gerrit do Haiku Code Review , adicionar sua chave pública SSH, bifurcar o código-fonte do Haiku, criar um commit commit e enviar o patch resultante à revisão do código para desenvolvedores privilegiados: git clone ssh://EXL@git.haiku-os.org/haiku --depth=1 -b master && cd haiku git commit git push origin master:refs/for/master
Se você precisar atualizar os patches que já foram enviados, antes de enviar confirmações alteradas ou novas, adicione o ID que o serviço Haiku Code Review nos forneceu no final da mensagem de confirmação. Após o envio do patch, os desenvolvedores do Haiku devem aprová-lo, rejeitá-lo ou enviá-lo para revisão. No meu caso, a correção foi aceita imediatamente e esse pequeno defeito agora está corrigido em todos os lugares. Se você precisar testar seus patches antes de enviá-los para o repositório, tente compilar um aplicativo separado usando o utilitário jam , que é uma bifurcação do sistema de compilação Perforce Jam e é usado para criar toda a base de códigos do sistema operacional Haiku. O repositório de código-fonte possui o arquivo ReadMe.Compiling.md, o que ajudará você a lidar com todos os truques de compilação.Ao finalizar meu projeto, descobri o motivo pelo qual o programa Icon-O-Matic não abre arquivos SVG criados usando o editor de vetores Inkscape. O problema é que o Icon-O-Matic não pode processar o atributo viewBox , no entanto, se você encontrar um arquivo SVG simples sem esse atributo, edite-o com o Inkscape e salve-o como um arquivo SVG comum , ele será aberto no Icon-O -Matic. Portanto, coloquei no meu repositório um arquivo SVG especialmente preparado que pode ser editado e que será aberto no Icon-O-Matic sem problemas. Além disso, adicionei uma pequena instrução ao arquivo Leia-me do projeto sobre como criar ícones para meus lançadores usando o Inkscape.Decidi verificar o código do meu projeto com uma variedade de analisadores estáticos, mas eles não encontraram nenhum problema sério. Mais tarde, porém, encontrei um problema que eles não conseguiram detectar. O fato de que o método estático GetBitmap () da classe BTranslationUtils poderia retornar NULL:
E no método Draw () , esqueci-me inadvertidamente de verificar a validade do campo da classe fBitmap . Portanto, o aplicativo provavelmente falharia se não encontrasse uma determinada imagem, mas de acordo com o plano, era para desenhar um quadrado vermelho. Contei essa história ao fato de que os analisadores estáticos estão longe de ser uma panacéia e atenção quando o trabalho com código na linguagem de programação C ++ é necessário em qualquer caso.O código-fonte do projeto BeGameLauncher e todas as minhas melhores práticas são carregadas no repositório no GitHub. Espero que este programa seja útil para alguém e possa ser algum tipo de tutorial como um aplicativo simples para o Haiku:Código-fonte do projeto: https://github.com/EXL/BeGameLauncherUm pequeno conselho para quem usará o meu iniciador em suas receitas para o repositório HaikuPorts. Se você deseja ocultar o jogo executável da lista de aplicativos Haiku que alguns programas leem e deixar apenas o iniciador lá, você pode usar o seguinte truque: settype -t application/x-vnd.Be-elfexecutable $appsDir/Gish/engine/Gish rc $portDir/additional-files/gish.rdef -o gish.rsrc resattr -o $appsDir/Gish/engine/Gish gish.rsrc
Isso excluirá a capacidade de executar arquivos executáveis sem parâmetros passados pelo iniciador de vários programas, como o QuickLaunch , que estão envolvidos no início rápido de aplicativos. Nesse caso, seu ícone original no arquivo executável será salvo.<< Pular para o conteúdo6. Portando o Xash3D: Jogo Lendário da Meia-Vida e Complementos Oficiais
O projeto Xash3D é uma implementação gratuita do mecanismo GoldSrc, usado no jogo Half-Life e em seus complementos oficiais. Por trás do desenvolvimento do Xash3D está o programador doméstico Tio Misha , que ainda coordena seu desenvolvimento e aprimoramento. Um pouco mais tarde, outros desenvolvedores ingressaram no projeto que criaram o fork do FWGS Xash3D , com suporte para um grande número de sistemas operacionais não Windows. Hoje, os principais programadores do projeto FWGS Xash3D são mittorn e a1batross ( libpony ), a última pessoa que participou ativamente do fórum popular de MotoFan.Ruque ainda administro no meu tempo livre.Eu me perguntava: por que não portar esse mecanismo para o Haiku, adicionando suporte para um sistema operacional tão interessante ao projeto Xash3D e dando aos usuários do Haiku a oportunidade de jogar o lendário Half-Life, um jogo de todos os tempos? O assunto permaneceu pequeno - era necessário iniciar imediatamente o trabalho de portabilidade e, se for bem-sucedido, publicar os resultados desse trabalho.Depois de passar várias horas estudando a estrutura do projeto e as partes do código responsáveis pelo suporte a várias plataformas, comecei a fazer alterações no mecanismo Xash3D para fornecer suporte ao sistema operacional Haiku. À moda antiga, defini o compilador -D__linux__e tentou criar um executável e um monte de bibliotecas. Surpreendentemente, as coisas foram bem rápidas e, à noite, depois de encaminhar os arquivos de dados para o jogo, consegui lançar o Half-Life e pegar o trem para a estação principal em Black Mesa.O processo de portar o mecanismo Xash3D para o Haiku no Qt Creator IDE.Devido ao fato de o projeto usar a biblioteca SDL2 de plataforma cruzada, a portabilidade do mecanismo é bastante simplificada, pois você não precisa escrever nenhum código que dependa da plataforma, por exemplo: emitir som, criar uma janela com um contexto OpenGL ou manipular eventos de entrada. Tudo isso já foi implementado na biblioteca SDL2 e está pronto para uso. Um pequeno problema surgiu com o suporte de rede, porque o Haiku possui uma biblioteca separada que implementa a pilha de rede, portanto, ele precisava estar vinculado ao mecanismo.O projeto para criar lançadores, sobre o qual escrevi um pouco mais, foi muito útil para mim. Usando a herança das classes C ++, ampliei seriamente sua funcionalidade e implementei a capacidade de selecionar várias adições ao jogo:Captura de tela do iniciador de portas do mecanismo Xash3D para o Haiku.A idéia era a seguinte: defina três variáveis de ambiente que permitiriam que você configurasse com flexibilidade o mecanismo de jogo para iniciar um complemento específico. Nesse caso, seria útil deixar o usuário jogar com os vários argumentos do arquivo executável e deixar a possibilidade de inicialização portátil do mecanismo quando ele estiver apenas no diretório com os arquivos de dados necessários. Portanto, a primeira variável de ambiente XASH3D_BASEDIR é responsável pelo diretório com os arquivos do jogo que o usuário seleciona no iniciador. A segunda variável XASH3D_GAME é responsável por qual adição o usuário selecionou para iniciar no iniciador. E aqui está a terceira variável XASH3D_MIRRORDIR, útil apenas para usuários avançados. Ele permite que você espelhe o diretório do sistema Xash3D em qualquer espaço em disco gravável para o usuário. Portanto, uma pessoa que deseja lançar seu jogo complementar no mecanismo Xash3D no Haiku só precisa coletar várias bibliotecas dinâmicas para arquiteturas diferentes a partir do código-fonte do seu projeto:• ./cl_dlls/libclient-haiku.so• ./dlls/libserver-haiku .so• ./cl_dlls/libclient-haiku64.so• ./dlls/libserver-haiku64.soE, em seguida, coloque-os nos diretórios apropriados do seu complemento. Para minha porta Xash3D, decidi pré-compilar bibliotecas de complementos populares para o jogo Half-Life, a saber: Blue Shift e Oposing Force, que permite aos usuários simplesmente baixar seus arquivos de dados, selecionar um diretório e iniciar o jogo sem nenhuma compilação de biblioteca.No processo de portar o mecanismo Xash3D, tive alguns problemas engraçados. Acontece que, para determinar o tamanho da mensagem de ajuda para os argumentos do arquivo executável gerado quando o parâmetro --help é passado , o mecanismo usou o tamanho predefinido da constante MAX_SYSPATH , que é um alias de outra constante MAX_PATH , cujo valor já é retirado da API do Haiku. Por muito tempo, não entendi por que esse certificado é emitido incompleto e cortado no local mais interessante. No começo, pequei que, de alguma maneira estranha, no fluxo de saída de erro padrãoO stderr conectou o buffer e até tentou desativá-lo à força. Depois de algum tempo, lembrei-me de que fiquei surpreso com o tamanho muito pequeno da constante MAX_PATH no sistema operacional Haiku. Essa constante assume um tamanho de caminho de apenas 1024 bytes. Meu palpite valeu a pena, assim que aumentei o tamanho da mensagem para 4096 bytes padrão, o problema foi resolvido. A seguinte conclusão deve ser tirada dessa história engraçada: você não deve usar a constante MAX_PATH em matrizes de caracteres que não estejam de forma alguma associadas aos caminhos do arquivo.Uma colagem de capturas de tela do jogo Half-Life, bem como suas adições oficiais Blue Shift e Oposing Force, lançadas usando o mecanismo Xash3D no sistema operacional Haiku (pré-visualização, aumento por referência ).Outro problema foi a falha ao usar a funcionalidade do próprio mecanismo para selecionar o complemento para o jogo. Aconteceu que, quando a definição XASH_INTERNAL_GAMELIBS foi definida, a biblioteca do cliente foi carregada não uma vez, mas duas vezes. O que implicava um problema semelhante. Como o a1batross me explicou , isso foi feito para que fosse possível vincular estaticamente a biblioteca OpenVGUI à biblioteca cliente. Na minha porta Xash3D no Haiku, essa biblioteca não é usada de forma alguma, então evitei usar o padrãoXASH_INTERNAL_GAMELIBS e relatou esse bug aos desenvolvedores do mecanismo.Então me deparei com a impossibilidade de abrir o navegador WebPositive embutido no Haiku ao clicar em links dentro de um jogo rodando no Xash3D. O problema era realmente estranho, porque quando o mecanismo foi iniciado a partir do terminal, o navegador foi aberto, mas quando foi iniciado o uso do iniciador, ele se recusou a fazê-lo. Depois de estudar um pouco o código, encontrei a chamada execve () lá , que tentei substituir por system () , após o qual o navegador começou a abrir sem problemas.Quando ocorre um erro, o mecanismo Xash3D usa ativamente as chamadas de função SDL_ShowSimpleMessageBox () e SDL_ShowMessageBox (), apenas a porta atual da biblioteca SDL2 para o Haiku não suporta a criação desses diálogos. Nossa versão da biblioteca simplesmente não possui essa funcionalidade. Mas vou falar sobre como corrigir esse problema abaixo.A porta do mecanismo Xash3D, publicada no repositório Haiku Depot., Xash3D Haiku, SDL2 ; 3D- . , , . , , . , . SDL2 Haiku Half-Life . , 3D- . , FPS. GPU, Intel.
Código fonte do projeto: https://github.com/FWGS/xash3dEnviei todas as alterações no código fonte aos desenvolvedores do projeto FWGS Xash3D que os aceitaram no repositório, e os pacotes com esse mecanismo já estão disponíveis há muito tempo no HaikuPorts e no programa HaikuDepot para qualquer usuário do Haiku .<< Pular para o conteúdo7. Portando as duas partes do jogo Serious Sam: The First Encounter e The Second Encounter
Recentemente, os desenvolvedores da Croteam publicaram o código-fonte do Serious Engine , usado em jogos da série Serious Sam: The First Encounter e The Second Encounter . Decidi portá-lo para o sistema operacional Haiku, baixei o código fonte e comecei a trabalhar.Serious Engine Haiku.- , - , SDL2, Haiku.
stderr , .
Serious Sam: The Second Encounter, Serious Engine Haiku.Tendo decomposto os arquivos baixados nos diretórios necessários, eu pude executar a segunda parte deste jogo maravilhoso sem problemas e até corri um pouco pela bela floresta. Apesar da falta de aceleração 3D, o processador desenha os encantos gráficos do jogo se você o rodar em uma janela e não no modo de tela cheia. Esse mecanismo funciona, é claro, com um FPS muito menor do que o mecanismo Xash3D, sobre o qual escrevi acima, mas os gráficos aqui são mais modernos e melhores. Após pequenas manipulações, conseguimos iniciar a primeira parte do jogo, que requer um arquivo executável diferente e um conjunto diferente de bibliotecas dinâmicas. Surpreendentemente, ela ganhou um pouco mais rápido, aparentemente os gráficos não são tão exigentes. Ao escalar as configurações do mecanismo, encontrei um grande número de parâmetros gráficos que podem reduzir significativamente a carga no processador,o que no caso do Haiku acabou sendo muito útil.
void CUnixDynamicLoader::DoOpen(const char *lib) {
Um pequeno truque que substituiu o caminho completo da biblioteca necessária para a função acabou sendo uma solução completamente funcional. E como a biblioteca, na sua ausência, é pesquisada várias vezes pelo mecanismo, deixei para o futuro a possibilidade de carregar a próxima versão principal. Espero que eles não quebrem a API nele.O próximo problema que encontrei foi a incapacidade de determinar a frequência do processador na arquitetura x86, embora tudo funcionasse bem no x86_64. Ao executar no x86, o mecanismo pediu para definir uma variável de ambiente com o nome SERIOUS_MHZe definir a frequência apropriada, o que me surpreendeu muito. Tentei fazê-lo e o jogo realmente começou, mas por algum motivo funcionou muito devagar. Escalando o código fonte do jogo, por um longo tempo, não consegui encontrar a fonte do problema e até escrevi um pedaço de código que usa a API Haiku para obter a frequência correta do processador e substituí-la no mecanismo do jogo, assim: #include <kernel/OS.h> #include <stdio.h> ... uint64 cpuFreq = 0; uint32 count = 0; get_cpu_topology_info(NULL, &count); if (count != 0) { cpu_topology_node_info *topology = new cpu_topology_node_info[count]; get_cpu_topology_info(topology, &count); for (uint32 i = 0; i < count; ++i) { if(topology[i].type == B_TOPOLOGY_CORE) { cpuFreq = topology[i].data.core.default_frequency; } } delete[] topology; } fprintf(stderr, "%llu\n", cpuFreq);
. x86_64 , CPU 1 MHz, . ,
__GNU_INLINE_X86_32__ , , x86, x86_64. , SDL2, inline-
rdtsc /proc/cpuinfo , , x86, .
.
CMakeLists.txt definindo o sinalizador -march = native , que literalmente informa ao compilador: ao gerar blocos de código de máquina, use todas as instruções sofisticadas e modernas disponíveis no processador do seu computador. if(NOT PANDORA AND NOT HAIKU) message("Warning: arch-native will be used!") add_compile_options(-march=native) endif() if(HAIKU) if(CMAKE_SIZEOF_VOID_P EQUAL 4)
Por esse motivo, os pacotes no repositório se reuniram exclusivamente no servidor de compilação mais poderoso e se recusaram a rodar nos computadores das pessoas comuns, jurando as instruções e códigos de operação incorretos. Desabilitar esse sinalizador e adicionar manualmente o suporte às instruções MMX, SSE e SSE2 não apenas resolveu esse problema, como também nos permitiu compilar um monte de montadores inline neste projeto, que caíram após a remoção do sinalizador.Para meu grande pesar, os desenvolvedores do Croteam não aceitam nenhuma correção no repositório do mecanismo, por isso garimpei e coloquei todo o meu trabalho lá:Código-fonte do projeto: https://github.com/EXLMOTODEV/Serious-EnginePacotes prontos para instalação para o lançamento de jogos de Serious Sam já estão disponíveis no repositório HaikuPorts. Lembre-se de baixar os arquivos de dados do jogo.<< Pular para o conteúdo8. Portando o jogo Vangers
Francamente, até recentemente, eu não conhecia completamente esse jogo, que nos anos 90 distantes era feito pelo estúdio de desenvolvimento doméstico KD Lab. Mas os participantes da conferência no Telegram IM , que se dedica a discutir o sistema operacional Haiku, pediram para eu portar Vangerov e me deram um link para o repositório GitHub , no qual as fontes desse jogo estavam localizadas.Captura de tela do iniciador de portas de jogos Vanger para o Haiku.Tendo puxado o código fonte para o Haiku, tentei compilá-lo e consegui sem problemas especiais. Eu tive que mexer um pouco com a falta de alguns arquivos de cabeçalho e com os caminhos para as bibliotecas FFmpeg que são usadas pelo mecanismo deste jogo. Comecei imediatamente a preparar o código-fonte para o empacotamento, então adicionei a variável de ambiente VANGERS_DATA e movi o log do mecanismo para o diretório do usuário que é gravável.Haiku Qt Creator., KD Lab. «» «» «» «», «» . , , .
, Haiku., , , ,
GOG.com Steam , . ,
stalkerg Linux. , . , .
Como no caso da porta NXEngine (Cave Story), sobre a qual escrevi acima, as versões em russo e inglês diferem em diferentes arquivos executáveis, mas o diretório com arquivos de dados é comum, as diferenças estão apenas nos scripts. Na ponta do stalkerg, tentei compilar o mecanismo de jogo com a opção -DBINARY_SCRIPT = Off , que ativava a compilação dinâmica desses scripts em tempo de execução, se eles estavam no diretório do arquivo de dados do jogo. Tudo isso me permitiu criar um lançador, no qual há a capacidade de mudar o idioma. A idéia é a seguinte: o diretório do jogo é pré-verificado e, se não tiver os scripts necessários, eles são copiados das tripas do pacote, após o qual o arquivo executável da versão em russo ou inglês já está em execução.A porta do jogo de Vanger, publicada no repositório Haiku Depot.Ao portar o Wanger, usei um recurso interessante relacionado às bibliotecas compartilhadas que eu gosto no Haiku. O mecanismo do jogo depende da biblioteca dinâmica libclunk.so , responsável por gerar sons binaurais em tempo real. E se no Linux, eu tenho que quebrar meus dedos, substituindo o caminho para esta biblioteca na variável de ambiente LD_LIBRARY_PATH , para que o que estava nessa variável antes também seja salvo, no Haiku é feito de maneira conveniente, como no Windows. Basta colocar a biblioteca compartilhada ao lado do arquivo executável e ela será selecionada, com a única diferença que, no caso do Haiku, a biblioteca deve ser colocada no diretório ./lib/, o que, na minha opinião, pode economizar muito tempo e nervos. Portanto, decidi não considerar a compilação estática desta biblioteca.Código-fonte do projeto: https://github.com/KranX/Vangers Osdesenvolvedores do Wanger aceitaram minhas alterações no mecanismo de jogo e pacotes prontos para instalação estão disponíveis para download no repositório HaikuPorts ou no programa HaikuDepot, apesar do recente fakap na infraestrutura de repositório que ocorreu depois Atualizando a distribuição do Fedora Linux para a nova versão.<< Pular para o conteúdo9. Implementação de diálogos na biblioteca SDL2 para Haiku
Ao portar os mecanismos Xash3D e Serious Engine, sobre os quais escrevi acima, deparei-me com uma porta local na biblioteca SDL2 de que havia uma completa falta de implementação de diálogos. Os diálogos são chamados pelas duas funções SDL_ShowSimpleMessageBox () e SDL_ShowMessageBox () , que permitem informar o usuário sobre qualquer informação importante, por exemplo, sobre um erro. A implementação dessas caixas de diálogo está disponível em muitas plataformas e sistemas operacionais: Windows, macOS, iOS, X11 e Android, mas, por algum motivo, está ausente no Haiku. Decidi corrigir essa omissão e adicionar essa funcionalidade à porta da biblioteca SDL2.Na API do Haiku, ou melhor, na estrutura do Kit de interface, existe uma maravilhosa classe BAlerto que é ótimo para implementar essas caixas de diálogo. Eu decidi escolher como base. A única coisa que me incomodou foi que eu não tinha certeza de que mais de três botões pudessem ser colocados na caixa de diálogo que o BAlert constrói . Também me lembrei dos recursos de gerenciamento de memória nesta classe sobre os quais escrevi acima: seus objetos só podem ser criados na pilha e não podem ser criados na pilha, porque depois de chamar o método Go () e a ação subsequente do usuário, ele se exclui. Depois de realizar alguns experimentos, tirei todas as minhas dúvidas, herdei dessa classe e comecei a escrever uma implementação.Implementação de diálogos na biblioteca SDL2 para o sistema operacional Haiku.A primeira dificuldade que encontrei foi que, ao usar qualquer objeto da classe BAlert ou seus descendentes, era necessário criar uma instância da classe do sistema BApplication , aparentemente para registrar o aplicativo no app_server para poder interagir com ele. Criei uma instância dessa classe, mas ao chamar a caixa de diálogo BAlert de outro processo ou da janela criada, recebi outro erro relacionado ao fato de o aplicativo não poder ter dois objetos da classe BApplication , felizmente encontrei uma solução para esse problema. A API do Haiku possui um ponteiro global para a instância atual da classeBApplication , chamado be_app , sua contrapartida na estrutura Qt é uma macro qApp especial , que também define um ponteiro para o objeto de aplicativo atual. Portanto, basta verificar NULL no ponteiro be_app e, se a verificação for bem-sucedida, crie o objeto necessário. Assim, todos esses problemas foram resolvidos.Vale ressaltar que a biblioteca SDL2 é escrita na linguagem de programação C, e a API Haiku, como você sabe, usa a linguagem de programação C ++. Por esse motivo, algumas partes do código devem ser revestidas com convenções de ligação externas "C" para que não haja problemas com a resolução de caracteres durante a vinculação. Além disso, em vez denew new(std::nothrow) , NULL, , SDL2, , .
. , SDL2 , Haiku API .
, que periodicamente executava em diferentes sistemas operacionais, analisava os resultados e avaliava meu trabalho. No final, fiquei tão empolgado que até apoiei a personalização, como definir cores diferentes para os botões e o plano de fundo da caixa de diálogo. Isso é suportado na API da biblioteca SDL2, mas inicialmente não planejei implementar essas coisas.Se o programador decidir cuspir uma linha muito, muito longa nessa caixa de diálogo, o objeto da classe BTextView , usado dentro do objeto da classe BAlert , precisará chamar o método SetWordWrap () com o argumento trueacertar um programador nos braços e ajustar o diálogo na tela. Parece que não há nada mais fácil: verificamos o comprimento da string usando a função strlen () e fazemos a coisa certa. O único problema é que o SDL2 também funciona com UTF-8, o que significa que a função strlen () retornará o número de bytes, não o número de caracteres. A API do Haiku e a classe de string BString vêm ao resgate , que possui o método CountChars () , que permite descobrir o comprimento de uma string em caracteres, não em bytes: bool CheckLongLines(const char *aMessage) { int final = 0;
Essa função verifica o texto da mensagem em busca de linhas com mais de 120 caracteres e, se houver, retorna true. Quanto ao UTF-8, ainda havia um momento em que, em algumas fontes do sistema Haiku, não havia suporte para caracteres chineses. Portanto, por exemplo, você não pode definir nenhuma inscrição em chinês no título da janela. Mas o texto em russo é instalado sem problemas.Ao preparar o pacote, encontrei um erro de construção para a arquitetura x86_gcc2, que é ativada na receita da biblioteca SDL2. Aconteceu que o compilador mais antigo do GCC 2.95 não conseguiu adivinhar que o código comentado é equivalente ao código abaixo: rgb_color ConvertColorType(const SDL_MessageBoxColor *aColor) const {
Portanto, tive que reescrever esse fragmento no estilo antigo e ainda remover a inicialização de algumas constantes da classe diretamente em suas declarações; o compilador antigo também não gostou disso.Enviei patches para a implementação de diálogos SDL2 no repositório HaikuPorts, para que agora os mecanismos Xash3D e Serious Engine possam emitir corretamente qualquer informação ao usuário, por exemplo, sobre erros. Mas ainda não entrei em contato com os desenvolvedores do SDL2, mas seria bom transferir todos os patches do repositório HaikuPorts para a biblioteca SDL2 upstream. Embora o trabalho de portar nossos patches tenha se tornado um pouco mais complicado devido à recente renomeação de prefixos de função de BE_ * para HAIKU_ * , esse não é um problema tão sério.<< Pular para o conteúdo10. Portando meu garfo do Cool Reader
Desenvolvo um fork do programa Cool Reader há muito tempo , escrito por Vadim Lopatin ( Buggins ), o artigo correspondente sobre isso está disponível no meu site. Nos comentários desse artigo, os leitores do meu blog estão constantemente cancelando a inscrição que desejam ver algum novo recurso em seu aplicativo favorito para leitura de livros eletrônicos, ou desejam corrigir erros e deficiências nas funções do programa já implementadas.Meu garfo do Cool Reader rodando no Haiku.No repositório HaikuPorts, encontrei uma receita para a criação do programa Cool Reader original; no entanto, devido a algumas mudanças constantes no recurso SourceForge , essa receita ficou inoperante, porque o código-fonte do aplicativo ficou indisponível para download. Decidi transferir meu fork para o repositório HaikuPorts, como uma nova versão do Cool Reader. Coloquei todos os patches do Gerasim no código, corrigi algumas falhas na receita e, com base nele, criei um novo pacote que já está disponível para todos os usuários do Haiku. Você pode encontrar o código fonte do meu fork do Cool Reader neste repositório GitHub:Código fonte do projeto: https://github.com/EXLMOTODEV/coolreaderO único problema que encontrei foram as imprecisões na transferência dos patches da Gerasim. Além da definição de __HAIKU__ , em outro lugar do sistema de construção o _LINUX define também foi definido e, na maioria dos casos, o último na lista de códigos-fonte foi a primeira compilação condicional que me decepcionou. De acordo com as regras de prioridade do pré-processador, para o Haiku foram compilados exatamente esses trechos de código que foram enquadrados pela definição do _LINUX , embora eu precisasse de algo completamente diferente. Mas, apesar disso, o programa foi iniciado e funcionou, mas apenas salvou suas configurações onde era necessário. Priorizei corretamente, reconstruí o pacote e o problema foi completamente resolvido.<< Pular para o conteúdo11. Finalização do programa KeymapSwitcher
Recentemente, muitos sistemas operacionais populares mudaram para um novo atalho de teclado Meta / Opt / Cmd / Win + Space para alternar os layouts de teclado. Pareceu-me muito conveniente, pois agora não preciso alterar nada e configurá-lo. Você se senta em qualquer computador executando o macOS, Windows ou Linux com o shell GNOME 3 e essa combinação conveniente de alterar o idioma de entrada funciona em qualquer lugar. Até o sistema operacional móvel Android tem seu análogo. Em geral, mudei para este atalho de teclado há muito tempo e me acostumei.Para meu grande pesar, KeymapSwitcher, que acompanha o Haiku, não me permitiu definir uma combinação de teclas tão conveniente para alternar layouts, e é por isso que constantemente me sinto desconfortável ao trabalhar com texto neste sistema operacional. Por isso, decidi modificar um pouco esse aplicativo e comecei a procurar seu código-fonte. Aconteceu que este programa, embora incluído na distribuição do Haiku, é fornecido separadamente do código-fonte do próprio sistema operacional. Além disso, o aplicativo está disponível no repositório HaikuPorts e também é atualizado por meio dele. Como fui informado, o KeymapSwitcher não foi incluído no Haiku, pois está planejado implementar uma API especial para alterar os layouts de teclado e, algum dia, a necessidade desse programa desaparecerá completamente.KeymapSwitcher no Haiku com um atalho de teclado popular para alternar layouts de teclado.Apesar de estar assustado com a complexidade do código KeymapSwitcher, rapidamente encontrei o lugar certo graças aos comentários e introduzi um pequeno patch no código do programa, o que me facilitou bastante a digitação de qualquer texto no Haiku. A única falha menor que não pude superar é que a tecla Opt precisa ser liberada para mudar o idioma. Ou seja, segure Opt . , HaikuPorts, KeymapSwitcher Haiku.
: https://github.com/HaikuArchives/KeymapSwitcher, .
<<12.
Estudar a API do Haiku, bem como resolver vários problemas exóticos que surgiram como resultado da portabilidade de aplicativos novos e atualizados para este sistema operacional, trouxeram muita experiência e prazer valiosos. Consegui promover os patches de suporte do Haiku no repositório de código-fonte de alguns grandes projetos e conheci novas pessoas interessantes que estavam de alguma forma relacionadas a esse belo sistema operacional.Vários aplicativos em execução no sistema operacional Haiku.Espero sinceramente que, no futuro, todos os problemas atuais, como a falta de aceleração de hardware 3D e navegadores populares, bem como o baixo suporte para hardware moderno, sejam resolvidos com sucesso e o Haiku receba um influxo de sangue novo de desenvolvedores e usuários que apreciarão suas capacidades exclusivas e design original . Felizmente, o desenvolvimento está longe de ser parado e hoje no fórum local deste sistema operacional são abordados os principais tópicos sobre aceleração 3D e portabilidade da biblioteca GTK + 3 , e a possibilidade de portar o componente QtWebEngine é discutida nos repositórios HaikuPorts. A porta GTK + 3 pode implicar a possibilidade de iniciar e trabalhar os populares navegadores Firefox e Chromium, e o QtWebEngine permitirá o uso do mecanismo Blink em navegadores modernos baseados na estrutura Qt, como Otter Browser ou Falkon .Já posso recomendar esse sistema operacional para aqueles que possuem laptops ou netbooks antigos e fracos, por exemplo, em vez da distribuição Lubuntu ou Windows XP. Você ficará surpreso com o quão rápido e responsivo funciona. Sim, você deve limitar-se um pouco à visualização de alguns sites devido a navegadores antigos e muitas falhas associadas a eles, mas, na maioria dos casos, em hardware antigo, essa limitação não tem significado.Todas as minhas portas e melhorias já foram publicadas e estão disponíveis para instalação em todos os usuários do Haiku. Todas as alterações no código fonte estão disponíveis nos respectivos repositórios sob suas licenças originais. Neste trabalho, usei uma enorme quantidade de materiais, os principais dos quais destacarei nos links úteis abaixo. Muito obrigado a stackoverflow.com e google.com por estarem lá.1. O site oficial do sistema operacional Haiku .2. O fórum oficial do sistema operacional Haiku .3. Documentação oficial para usuários do Haiku .4. Documentação oficial para desenvolvedores do Haiku .5. Descrição dos recursos da interface gráfica do usuário do Haiku .6. Recomendações para criar ícones para aplicativos Haiku .7. Descrição do programa Icon-O-Matic e dicas para seu uso .8. Descrição do formato dos ícones HVIF do vetor .9. A documentação oficial para a estrutura do Kit de Interface .10. A documentação oficial para a estrutura do Locale Kit .11. Artigo sobre aspectos de localização de aplicativos para o Haiku .12. A documentação oficial da API de layout .13. Uma série de artigos que descrevem a implementação da API de layout no Haiku .14. Repositório do GitHub do código fonte do sistema operacional Haiku .15. Repositório do GitHub da árvore de receitas HaikuPorts .16. A versão da Internet do repositório de pacotes HPKG prontos para uso Haiku Depot Web .17. Um artigo interessante "Haiku: lamp geek-OS" no blog do desenvolvedor do INSTEAD, Peter Kosykh .18. O artigo Haiku: Imersão no blog de desenvolvedores do INSTEAD, Pyotr Kosykh .19. O curso das lições de programação "Aprendendo a programar com o Haiku" da DarkWyrm .20. O curso das lições de programação "Programming With Haiku" da DarkWyrm .21. Publicação “Existe vida no Haiku?” no recurso Linux.org.ru, de mim .22. Conferência no Telegram IM, dedicada à discussão do sistema operacional Haiku .Parabéns a todos os usuários do recursohabr ! , , 2019 !
<<