Videoaula de programação em Lazarus/Delphi/Pascal
Enviado por Marcos Elias Picão (marquinhosxpΘgmail·com):
Encontrar material em português para dar os primeiros passos nesse mundo nem sempre é fácil. Eu fiz uma videoaula extensa sobre o Lazarus, com duas horas. Quem não sabe nada de programação poderá iniciar nesse fantástico mundo de criar seus próprios programas.
Se você gosta de Shell Script para automatizar ações, ficará fascinado com as possibilidades de interface gráfica para suas aplicações. A ferramenta de programação escolhida foi o Lazarus, que é multiplataforma e open source. Ele é muito parecido com o Delphi (o mesmo exemplo e vídeo serve perfeitamente para quem quer aprender Delphi!). Ele usa o compilador Free Pascal, só que tem algumas coisas que o Delphi não tem:
- É open source, gratuito, não exige licenciamento. O Delphi, em contrapartida, é caro e só tem para Windows. Mas se você quiser criar aplicações fechadas ou comerciais, pode fazer tranquilo, a licença permite.
- É multiplataforma! “Write once, compile anywhere”, literalmente. Seu código pode ser compilado sem alteração para todas as plataformas suportadas: Windows de 32 e 64-bit (o Delphi atualmente só compila para 32-bit), Linux (escolha entre GTK ou QT!) e Mac (entre outras, se você não usar alguns recursos gráficos).
- É mais garantido poder continuar seus programas no futuro. O Delphi já teve versões gratuitas, as edições “Personal” e o TurboDelphi. Mas foram descontinuadas. O Lazarus é software livre e vem evoluindo aos poucos (ainda não é 1.0 mas já é muito competente). Espero que goste. Em poucos minutos você poderá criar seus programas com essa maravilhosa ferramenta.” [referência: explorando.viamep.com]
@brlinuxblog
Feed RSS
Essa notícia também foi noticiada no Gguia do Hardware, onde há o seguinte texto:
Com ferramentas como o Lazarus o desenho da interface do programa é visual, extremamente simples: ele te dá uma janela vazia, você adiciona botões, campos de texto e tudo mais em modo visual, e depois digita o código referente a cada componente – no código você define o que irá acontecer quando um evento for chamado, como por exemplo, um clique num botão, um preenchimento de texto, etc.
Essa maneira de programação é conceitualmente incorreta, pois faz om que seja misturado código de interface gráfica com o código da regra de negócios. O correto é escrever uma classe separada com a regra de negócios e, ao escrever o evento nos botões, chamar o método na classe da regra de negócios. Exceto quando o evento é relativo à interface gráfica, como exibir um campo de texto ao aperar um botão, já que é algo relativo à interface.
@Alan
como ja diria Einstein tudo é relativo
@Alan
O trecho que citaste diz:
“no código você define o que irá acontecer quando um evento for chamado, como por exemplo, um clique num botão, um preenchimento de texto, etc”.
Ele não diz que a regra de negócio estará na chamada de evento.
Ele poderia estar se referindo exatamente ao que mencionaste:
“O correto é escrever uma classe separada com a regra de negócios e, ao escrever o evento nos botões, chamar o método na classe da regra de negócios.”
[]s
@Allan, discordo do seu ponto de vista. A maneira de programar a interface gráfica no Lazarus é a mesma usada pelo NetBeans e não vejo como ela pode levar à mistura de código. A única razão para que alguém trabalhe de forma monolítica é a falta de experiência ou de conhecimento das boas práticas, nunca uma ferramenta.
Mas, na maioria das vezes, o programador acaba escrevendo a regra de negócios direto no botão. Então, achei válido lembrar dessa boa prática de programação, que é a de isolar o código da interface (que, no caso do Lazarus, é, em grande parte, gerado pela IDE) do código da regra de negócios a fim de lembrar os novos programadores saberem disso e evitarem cometer esse erro.
No parágrafo que citei, não foi falado explicitamente, mas tá meio que implícito isso, dependendo da interpretação de quem lê.
Da ultima vez que testei o Lazarus, ele capotava tantas vezes que desistí.
Talvez seja a hora de reavalia-lo novamente.
Venho usando o lazarus desde a versao 0.9.24 e a evolução é notável, ele está infinitamente mais estável na ultima versão 0.9.28
O Lazarus começou a atingir um grau de maturidade que já o faz viável como RAD para projetos sérios e um pouco mais sofisticados.
E ele anda evoluindo bem rápido.
É ferramenta diária aqui na empresa hoje, junto com outras IDEs para C/C++.
Alguem saberia informar como ele tá com respeito a componentes de base dedados PG/Firebird/MSSQL ?
São as bases que comumente uso.
Para Firebird, acho que o IBObjects estará fora de cogitação.
@Allan, discordo do seu ponto de vista. A maneira de programar a interface gráfica no Lazarus é a mesma usada pelo NetBeans e não vejo como ela pode levar à mistura de código. A única razão para que alguém trabalhe de forma monolítica é a falta de experiência ou de conhecimento das boas práticas, nunca uma ferramenta.
Vou exemplificar como essa maneira de programar pode levar à mistura de códigos:
Um programador Java está usando o NetBeans para criar um programa que toca um arquivo de áudio através da API Java Sound. Aí o programador cria um Form e arrasta um componente de botão (o botão play do tocador de áudio, por exemplo) neste Form, e então clica duas vezes para escrever a ação do botão (creio que seja assim no NetBeans, como eu só uso Eclipse e sempre escrevo as telas na mão, pois é mais produtivo para mim, então eu não conheço o desenhador de interfaces do NetBeans), e aí ele escreve a regra de negócios no evento desse botão, e essa regra de negócios usa a API Java Sound.
O que ocorre por baixo dos panos? O NetBeans irá gerar uma classe que herda JFrame (classe responsável pelos Forms no Java) e que possui um botão e, nesse botão, vai gerar um evento contendo código da API JavaSound, tudo isso na classe que herda JFrame, que deveria conter apenas código da tela. O NetBeans não vai criar uma classe separada contendo a regra de negócios e alterar por baixo dos panos a implementação dlo evento do botão para um método que chama a regra de negócios.
Aí, os desenvolvedores do software (ou o cliente que encomendou o programa) decidem que a interface gráfica agora deverá ser baseada na API SWT, já que a implementação com a API Swing ficou muito pesada. Aí o desenvolvedor terá que reescrever a regra de negócios ou fazer malabarismos para pegar toda a regra de negócios e colocar na nova implementação. E, se a interface é daquelas tipo a do OpenOffice.org Writer, que possui várias e várias funções espalhadas entre botões, menus e outros eventos diversos, a migração se tornará um pesadelo.
Com a separação do software em camadas, basta trocar a interface gráfica e pronto, os eventos dos botões da nova interface chamarão os mesmos métodos da interface antiga, métodos estes que poderão ser chamados mais de uma vez, caso dois componentes tenham a mesma ação (um botão e uma tecla de atalho para iniciar a reprodução do áudio, por exemplo).
O uso do desenhador de interfaces do NetBeans não é errado, assim como o desenhador de interfaces do Lazarus e de outras ferramentas de desenvolvimento (apesar de eu preferir escrever o código na mão sempre que possível, e no Eclipse). Como eu escrevi, é perfeitamente possível usar o desenhador do NetBeans e desenvolver o software em camadas da forma conceitualmente correta.
Aproveitando o assunto, já faz um ano que estou desenvolvendo um player de áudio em Java. Ele será, futuramente, quando estiver em um estado mais maduro e com algumas features prontas, lançado sob a GPLv3 e noticiado aqui no Br-Linux. Uma das características dele será a do usuário poder escolher a interface que preferir. O player terá sete interfaces diferentes, uma delas em modo texto. E outros desenvolvedores poderão escrever facilmente novas interfaces para o player, caso desejassem. Essa diversidade de interfaces só é possível graças à separação do código da interface do código da regra de negócios.
Concordo com tudo o que você disse @Alan. Separação em camadas evita problemas de nervos na hora de manter um software :)
@Allan Taborda dos Santos
Eu desistir de apis como Swing e SWT, pois sinceramente construir interfaces usando essas duas APIs e ainda mais interfaces complexas é um verdadeiro pesadelo, um sistema que andei fazendo usando a api swing ficou tão verborragico e grande que resolvir recomeçar a aplicacao do zero, durante o tempo pesquisei por técnicas e patterns que pudessem tornar o código mais simples e reaproveitável até que desisitir e resolvir fazer tudo usando o griffon, no geral a aplicação esta longe da minha idéia inicial, mas pelo menos é o mais próximo daquilo que eu tinha em mente.
Sinceramente na próxima vez vou usar o jMonkey ou mesmo criar minha própria api pessoal para aplicações desktop.
Mas até vou continuar como webdeveloper de JAVA.
Eu uso Free Pascal/Lazarus em um projeto de 3D MMORPG:
http://sourceforge.net/projects/gamemundo/
É uma ferramenta extremamente poderosa.
@Hamacker:
“Alguem saberia informar como ele tá com respeito a componentes de base dedados PG/Firebird/MSSQL ?”
Existe uma nativa, mas é fraquinha ainda. Mas pode usar a Zeos. Dentro do mesmo zip que baixa para delphi tem o pacote(lpk) para Lazarus.
@Allan Taborda dos Santos
Nesse seu último comentário, gigante, você basicamente explicou MVC, mas continua a mesma questão. Quem determina o que código deve ser colocado onde é quem está programando.
O netbeans, quando você coloca um botão no form, tenta deixar o código que gera a interface como inacessível. Mas lógico, é possível fazer na marra, usando outro editor.
Bobagem essa idéia que basta programar em java e/ou usar Eclipse / Netbeans e o sujeito é garantidamente um bom desenvolvedor. Muitos fóruns de java por aí como prova.
E eu sei java(o suficiente para sobreviver :) e sou fã do Eclipse.
@Allan Taborda dos Santos
Não é preciso separar a lógica da visualização para se trabalhar de forma correta ;)
@Hell:
Você já utilizou o QT Jambi? Tô aprendendo Java agora, e já vi que o Swing e o SWT não são essa maravilha toda.
Eu desistir de apis como Swing e SWT, pois sinceramente construir interfaces usando essas duas APIs e ainda mais interfaces complexas é um verdadeiro pesadelo,[...]
Na API Swing, existem várias formas de se construir interfaces gráficas, usando diferentes gerenciadores de layout. Nos meus softwares, eu costumo usar um misto de BorderLayout com BoxLayout. O gerenciador de layout setado é o BorderLayout, que é o padrão do JFrame, aí eu vou agrupando os componentes visuais (botões, labels, tabelas, etc) em Boxes horizontais (com espaçamentos horizontais entre os componentes), então eu adiciono todos os boxes horizontais num Box vertical (com espaçamentos verticais entre os Boxes) e adiciono este Box vertical na área central do BorderLayout. Nas outras áreas (norte, sul, leste e oeste), eu posso não adicionar nada ou adicionar algum outro componente, como um outro Box, por exemplo. Dessa forma, fica fácil de se construir interfaces gráficas com Swing.
Nesse seu último comentário, gigante, você basicamente explicou MVC, mas continua a mesma questão. Quem determina o que código deve ser colocado onde é quem está programando.
Sim, claro, como eu disse, é perfeitamente possível usar o desenhador do NetBeans e desenvolver o software em camadas da forma conceitualmente correta. Assim como é possível escrever a tela do software na mão e misturar os códigos da tela e da regra de negócios. Vide o código-fonte do JLGui, outro player de áudio escrito em Java. O código dele é um pesadelo.
Entretanto, acredito que a forma de desenvolver interfaces com desenhador de telas, de certa forma, meio que incentiva o desenvolvimento do software com o código da regra de negócios junto à tela, principalmente quem está iniciando no Java, não possui noções da API Swing e já pega o desenhador do NetBeans logo de cara.
O netbeans, quando você coloca um botão no form, tenta deixar o código que gera a interface como inacessível. Mas lógico, é possível fazer na marra, usando outro editor.
Não conheço o desenhador de telas do NetBeans, mas já vi códigos gerados por ele. Muitos deles com detalhes da regra de negócios no JFrame.
Bobagem essa idéia que basta programar em java e/ou usar Eclipse / Netbeans e o sujeito é garantidamente um bom desenvolvedor. Muitos fóruns de java por aí como prova.
Concordo.
Não é preciso separar a lógica da visualização para se trabalhar de forma correta ;)
Discordo.
Esqueci de falar…
A principal vantagem, que creio que é o que mais atrai os iniciantes, do Delphi(por conseqüência o Lazarus) é a parte de desenhar interfaces.
E isso é melhor que qualquer ferramenta Java. Ao menos até a última vez que conferi. É muito rápido.
Eclipse tinha um plugin para isso que era terrível, acho que foi até descontinuado. O netbeans é bom, mas para estender é meio complicado.
Mas independe um pouco da implementação, java é meio burocrático por natureza. E principalmente, java está na onda que web é o caminho, e o resto é resto.
Eu, além do “desenhador de interfaces”, vejo no Lazarus o diferencial de gerar código compilado para diversas plataformas, coisa cada vez mais rara em tempos de VMs.
Mas não há como discutir a ampla vantagem que java tem em ferramentas e bibliotecas disponíveis.
Parece até besteira, mas acho que deveriam desenvolver mais programas de automação comercial, controle de estoque, de serviço e afins para Linux. Pois vejo que há uma carência grande nesse área para o Linux…Eu mesmo estou pensando em desenvolver essa “modalidade” de software, em Java, para uma Loja aqui em minha cidade e consequentemente fazer uma migração do Windows para o Linux, claro que poderia ser com o Lazarus, mas acho que o executável que ele gera por padrão é muito grande e creio que o Java esteja mais preparado para isso. Acho que dessa forma iria promover bastante o Linux no comercio de produtos e serviços…
@Rod
Para que o Lazarus gere executáveis de tamanho normal, use o strip. Ele vai desativar o modo debug do compilador e isso vai resolver a questão do tamanho.
@André
Ola André, eu ja sabia disso, porém não sei como por isso automaticamente, pois usei por pouco tempo. Pelo que eu me lembre tinha que digitar o comando do strip no terminal, não tem como habilitar isso na ide para que faça automático?
@Rod
Claro que você está considerando tamanho de executável com tamanho de jar e tamanho de máquina virtual somados né ?
Senão a conta é injusta. Até porque a JVM não vem instalada por padrão.
@Allan Taborda dos Santos
Faz o seguinte: coloque um jTable (com seus outros gritables básicos) em uma jFrame utilizando o seu box layout e abaixo usa uma jTabbedPanel com um novo painel e uma outra jTable dentro aproveita sabendo que a janela precisa ser corrente utiliza um gridpanel para que possa caber outros itens internos.
Só fazendo essa besteirinha você perderá uns três dias para encontrar a solução que resolva parcialmente o problema da table estar consumindo todo o espaço da tela ou da table que estar dentro de gridpanel que estar dentro de outra gridpanel ficar três vezes maior que a janela (detalhe mesmo utilizando o absolut layout).
É interessante notar que o Swing suportar vários tipos de layout, entretanto nenhum deles presta direito, já programei bastante utilizando Swing com java e hoje em dia estou cansado de perder tempo com coisas redundantes como essa que nada mais reflete que uma simples janelinha básica, por isso resolvir usar o griffon para construir minhas próprias interfaces em Java o que é bem mais produtivo que usar o próprio java com Swing fora ter um conceito totalmente MVC, dar até gosto de programar assim.
@Tércio Martins
O Jambi é uma perda de tempo assim como o SWT, pois ficaria dependente demais de uma droga de binário para cada plataforma e nisso é algo dispensável, ainda acho mais vantagem trabalhar no JAVA 2D ou mesmo usar o jMonkey que são mais realistas neste ponto.
Cada vez que leio uma comparação Lazarus x Delphi onde o primeiro sai favorável, tenho a impressão de que quem escreveu faz anos que não programa no segundo ou então não conhece direito. O Delphi além de ter muito mais componentes, tem recursos sofisticados de refatoração, MVC, um ganho absurdo de performance em processadores multi-core, suporte com componentes visuais a dispositivos touch-screen inclusive multi-touch, acesso a muito mais bancos de dados e dezenas de tipos de relatórios.
“O Delphi, em contrapartida, é caro e só tem para Windows. Mas se você quiser criar aplicações fechadas ou comerciais, pode fazer tranquilo, a licença permite.”
Caro é relativo, tem licença de 1500 reais, não é barato pra um usuário doméstico, mas dependendo da empresa é um preço baixo pela produtividade que proporciona.
” É multiplataforma! “Write once, compile anywhere”,
Seu código pode ser compilado sem alteração para todas as plataformas suportadas: Windows de 32 e 64-bit (o Delphi atualmente só compila para 32-bit), Linux (escolha entre GTK ou QT!) e Mac (entre outras, se você não usar alguns recursos gráficos).”
Esqueceu de falar que o executável fica enorme. E o Delphi hoje também compila pra Linux, Mac e .NET, sendo que a próxima versão do RAD Studio vai gerar até código pro iPhone.
“O Delphi já teve versões gratuitas, as edições “Personal” e o TurboDelphi. Mas foram descontinuadas.”
Aí caiu no “di grátis” de novo, já que as versões gratuitas não deixaram de funcionar e as comerciais rodam o que a gratuita faz.
“Esqueceu de falar que o executável fica enorme.”
Esse trauma com tamanho do executável muita gente tem. Embora tenha muito de exagero, como se a cada vinte linhas, crescesse 10 M. E não é assim, o que apavora é que mesmo com poucas linhas, fica grande. Mas depois segue crescendo pouco.
O estranho é que existe ferramenta pronta para resolver isso, mas não integram na IDE.
“E o Delphi hoje também compila pra Linux, Mac e .NET, sendo que a próxima versão do RAD Studio vai gerar até código pro iPhone.”
Compila para Linux ? Acho que não. Eu sabia que só na próxima versão compilaria e seria através de .Net, mas não sei mesmo.
Para iPhone o Freepascal já tem suporte desde o início do ano.
Concordo que falar que o Lazarus é melhor está sendo irresponsável ou ignora o Delphi. O Delphi é muito bom naquilo que faz e faz muito mais que o lazarus.
O que se destaca nesse tipo de comparação é o maniqueismo que aparece. O Delphi é tomado como o máximo, e o Lazarus uma droga. E não é assim. Ou a pessoa não usa a tempos mesmo o Lazarus.
Um dos maiores defeitos que o Lazarus tem é não lançar versões estáveis com maior freqüência. A versão no SVN em nada parece com a que está no site.
Baixar de SVN não é recomendado mesmo para iniciantes. Então fica parecendo quase morto o projeto.
Eu tento instala-lo no Lenny, mas não vai d jeito nem 1. No repositório n existe os pacotes, c eu tento instalar pelos pacotes disponibilizados no Source Forge, falta muita dependência.
O Delphi Prism 2011 (chamado anteriormente de Fulcrum) já está disponível e produz executáveis Windows, Mac e Linux via .NET/Mono.
E quanto custa o Delphi Prism 2011?????
Faz o seguinte: coloque um jTable (com seus outros gritables básicos) em uma jFrame utilizando o seu box layout e abaixo usa uma jTabbedPanel com um novo painel e uma outra jTable dentro aproveita sabendo que a janela precisa ser corrente utiliza um gridpanel para que possa caber outros itens internos.
Só fazendo essa besteirinha você perderá uns três dias para encontrar a solução que resolva parcialmente o problema da table estar consumindo todo o espaço da tela ou da table que estar dentro de gridpanel que estar dentro de outra gridpanel ficar três vezes maior que a janela (detalhe mesmo utilizando o absolut layout).
Eu faço isso que você descreveu em pouco tempo, um 20 minutos ou até menos. E sem GridPanel, porque não é necessário.
E os únicos “gritables básicos” que usaria num caso destes seriam apenas dois ou três: um JScrollPane para a barra de rolagem e para os títulos das colunas (que pode não ser necessário, dependendo do caso), uma classe que extenda AbstractTableModel (que é fácil de fazer, basta implementar uns métodos abstratos e, caso necessário, sobrescrever outros) e, caso necessário (uso em poucas tabelas), um TableCellRenderer, usado caso eu queira adicionar uma formatação ao conteúdo da tabela, como os dados ficarem centralizados, por exemplo.
É interessante notar que o Swing suportar vários tipos de layout, entretanto nenhum deles presta direito [...]
Discordo.
Felizmente, há opções à API Swing para escrever as interfaces gráficas no Java.
Só para lembrar, o assunto do post é o Lazarus, não o Java.
Allan Taborda dos Santos, acho que você não entendeu bem como isso é feito no código, ou já analisou o código dos programas com Delphi/Lazarus?
Ao dar um duplo clique no botão é gerado um procedure assim:
procedimento UnidadedoForm.BotaoClicado-EventoClick(Sender: QuemEnviouOComando);
começo
//codifique aqui o q ocorre ao clicar no botão
fim;
E como característica, esse mesmo procedimento é declarado lá em cima, dentro da instância do Form.
A pessoa pode criar novos procedimentos sem estarem associados a nenhuma janela da mesma forma, e pode associá-lo a algum evento quando quiser, por exemplo:
botao1.onClick = MeuEventoDoBotao1…
É, de certa foram, separado. Quando vc cria componentes em tempo de execução, vê que é separado, e poderia até chamar os códigos a partir de outras unidades, em arquivos separados. Agora… Para que separar tanto? O que o Delphi/Lazarus faz é apenas facilitar.
Na maioria dos programas com interface gráfica o que ocorre ao clicar num botão é único, não vai ocorrer em outro local da aplicação (e se for ocorrer… pode ser compartilhado facilmente entre componentes, aí identifica quem enviou o comando pelo Sender). Então não há tanto sentido em codificar isso separado. Mas é fácil separar se for preciso, e no evento clique do botão você apenas chama (ou relaciona) o procedimento ou função que quiser.
Mas pra que separar? Não é necessário conhecer as instruções dos processadores x86 pra fazer um programa, da mesma forma que não é necessário querer usar um padrão estabelecido por algumas linguagens.
Agora quanto ao comentário do @marcosalex (desculpe não ter juntado, eu tb não gosto de comentários seguidos :P):
“Esqueceu de falar que o executável fica enorme” – Use o strip (que eu nem sabia também, mas enfim, funciona).
“hoje também compila pra Linux” – Nativa? Já no Delphi 2010/11? Tá bom… Se não for nativa esquece, para quem odeia .NET/Mono (como eu) não vale porcaria nenhuma (tente rodar um programinha hello world feito em .NET FW 4 no Windows XP “limpo” pra vc ver o quanto de extras precisa baixar/instalar… além do desempenho, em máquinas antigas as apps que usam o .NET FW geralmente demoram + para iniciar e ficam + lentas). E não adianta falar que é fácil instalar as atualizações, MUITOS lares e empresas usam versões antigas do Windows, nem sempre atualizadas com os últimos SPs. Ou seja, fazer algumas coisas em .NET FW4 hoje é dar um pouco de dor de cabeça para uma boa parte dos seus usuários.
“Aí caiu no “di grátis” de novo, já que as versões gratuitas não deixaram de funcionar e as comerciais rodam o que a gratuita faz.” – Não é apenas questão de ser de graça. É de ser livre. Aplicações open source de sucesso, comunitárias e tal, raramente são desenvolvidas com ferramentas proprietárias. E quanto ao ser pago… A licença é barata se for para trabalho, certamente ele se paga rapidinho vendendo aplicações. Agora para hobby… É cara e pronto, ninguém vai pagar tanto assim para desenvolver um programinha uma única vez na vida.
*****
O Delphi não é “melhor” ou “pior” que o Lazarus, são apenas coisas diferentes, muito parecidas na forma de programar, essa questão de melhor ou pior é bastante pessoal. Para começar, o Lazarus não tenta ser um clone do Delphi (é inspirado nele, mas não foi projetado para “matar” o Delphi). A Embarcadero tem o direito dela de vender o que ela fez, afinal ela ganha com isso.
Os componentes novos do Delphi obviamente o tornam melhor para quem pretende usá-los sem precisar criar tudo do zero – ótimo! O Delphi 2010 e 2011 está muito bom. É verdade, em facilidade com componentes prontos ele ganha do Lazarus de primeira.
Quanto aos problemas para instalar o Lazarus em alguma distro, vai do gerenciamento de pacotes da mesma, por causa das dependências que não são bem calculadas por quem faz o pacote.
Eu dispensei o Lazarus há alguns anos mas voltei com ele, já que amadureceu bastante. Atualmente pego as compilações recentes não estáveis (mas não uso o SVN). As versões do SVN são recomendadas só para aventureiros mesmo, podem funcionar como podem dar pau.
“O Delphi Prism 2011 (chamado anteriormente de Fulcrum) já está disponível e produz executáveis Windows, Mac e Linux via .NET/Mono.”
Obrigado, @adilson, eu não tinha certeza se já havia saído ou não.
Quanto ao “via .Net”, eu também tinha ouvido falar isso, mas como o Marcos Alex falou, tomei como confirmado.
Para mim, via .net / mono, não serve. E mesmo para quem é fã da filosofia do Icaza, MVP da Microsoft, uma coisa é se apoiar no .net, outra é código nativo.
Se for para usar algo sobre uma VM, uso Java, ou até python sobre java.
Eu considero uma vantagem do fpc gerar código nativo. Hoje em dia é tudo interpretado, ótimo ter uma opção.
Essa compatibilidade com Linux é transparente ou é no estilo desde o Delphi6, onde tinhamos que colocar ifdef e algumas units para desviar a diretiva de compilação quando se pretendia gerar um executável mixto rodando no windows e no linux.
@Hamacker
Não entendi se tua pergunta foi sobre o delphi ou lazarus.
No lazarus continuam disponíveis IFDEFs para verificar se trata-se de um sistema Windows, linux, ou outro OS. Se o código vai ser compilado com Freepascal ou Delphi entre outros.
Mas só é necessário para algo bem específico. A imensa maioria das bibliotecas são multiplataforma (acho até que é critério para entrar nos pacotes oficiais).
Essa parte é muito melhor do que era no Delphi (até o 7 onde vi), onde existia versão “normal” (windows) e a versão para Kylix.