To infinity… and beyond.

Além dos tradicionais lançamentos de sondas espaciais, foguetes, satélites, homens no espaço bem como na lua, a agência espacial mais conhecida do planeta (quiçá em outros planetas), a NASA, tem feito um esforço para tornar conhecidas as suas iniciativas no desenvolvimento de software.

NASA
NASA logo

Apesar de muito conhecida por seus grandes feitos desde a época da corrida espacial nos anos 50, é óbvio que além de todo o conhecimento científico adquirido com esses feitos, principalmente o conhecimento e desenvolvimento matemático e algorítmico devem ter sido algo jamais experimentado na história da humanidade em um curto intervalo de tempo.

Como a NASA foi criada em uma época em que o “segredo” era algo que poderia mudar o rumo da história devido a um momento de “guerra” (psicológica) entre as duas maiores potências da época, é normal que tudo o que fora desenvolvido por essa agência fosse “secreto” até então.

Entretanto os tempos são outros e a quantidade de informação existente hoje não justifica mais nenhum “segredo”, uma vez que é muito mais interessante que a própria agência se beneficie das vantagens do compartilhamento via iniciativas de software open source.

Até mesmo outras agências, como a DARPA, vem utilizando há anos software open source em seus projetos internos.
Eu mesmo já obtive um feedback há uns 15 anos atrás, onde um engenheiro da DARPA me pareceu estar usando a minha biblioteca JMML (Java MSN Messenger Library), já naquela época.

Voltando à NASA, desde o ano passado percebi que a agência tem demonstrado estar bem compromissada em organizar um grande catálogo contendo todas as suas tecnologias em software, já criadas e utilizadas em seus projetos.

NASA Software Category

Na imagem acima podemos ver todas as categorias de software contemplados pela iniciativa.
Particularmente me interessei pela “Data servers processing and handling” e ao abrir essa categoria, percebi que tenho, só ali, um universo a ser explorado que irá me levar “ao infinito e além“.

Segue abaixo o link da iniciativa.

https://www.nasa.gov/directorates/spacetech/techtransfer/Software_Catalog_2019

https://software.nasa.gov/

[]’s
PopolonY2k

Print Friendly, PDF & Email

Featured project – Aleste Gaiden Cartridge (MSX Brasil Oficial)

Depois de um longo período de silêncio, devido a um período de muito trabalho não relacionado a coisas legais, finalmente retorno com novidades, principalmente porque apesar do blog estar um pouco silencioso não significa que trabalhos em background não estão sendo desenvolvidos, muito pelo contrário pois essas horas de silêncio significam que muita coisa legal está sendo feita 🙂

Vamos deixar as outras coisas legais para outros posts pois o objetivo desse post aqui é mostrar um cartucho desenvolvido por uma das maiores comunidades de MSX no Facebook, que é a MSX Brasil Oficial, comunidade essa onde sou um dos fundadores e também um dos moderadores.

O projeto se iniciou nas conversas entre Erwin Brasil, um dos fundadores e também um dos moderadores da MSX Brasil Oficial com o Sergio Augusto Vladisauskis um dos membros mais atuantes da comunidade MSX nacional. Após algum tempo o Sergio entrou em contato comigo perguntando sobre a compatibilidade de uma ROM do jogo para MSX2, Aleste Gaiden, que havia sido gerada pelo software do Vincent Van Dam, o DSK2ROM.

Um problema havia sido detectado no som FM da ROM gerada, quando executada nos MSX TurboR operando em modo R800, causando sons estranhos e modificando completamente a musica para ruídos nada agradáveis de se ouvir. Ao testar essa ROM em um dos meus MSX TurboR, naquele dia, eu não sabia que estaria entrando de maneira intensa no desenvolvimento desse projeto.

Após testar essa ROM e concluir que tínhamos um problema, chegamos a conclusão que estava relacionado ao modo R800 pois eu havia testado a mesma ROM no MSX TurboR mas em modo Z80, bootando a máquina pressionando a tecla 1 e tudo havia funcionado perfeitamente, então para corrigir isso deveríamos inserir uma rotina que chaveasse o funcionamento dessas máquinas para o modo Z80, na inicialização do jogo.

Como as notícias correm rápido demais em um ambiente comunitário forte e principalmente com muita gente boa interagindo entre si, então em poucos minutos um dos membros da comunidade MSX bem conhecido pelo seu alto conhecimento da plataforma MSX, o Julio Lemos, entrou em contato comigo já com uma ROM modificada para esse fim e como era de se esperar, essa ROM funcionou perfeitamente.

Apesar desse contratempo tudo caminhava muito bem e os cartuchos MegaFlashROM começavam a ser produzidos para que enfim a ROM pudesse ser gravada e entregue aos participantes patrocinadores do projeto. Mas o pior estava por vir e nesse momento mais uma vez o Sergio me informou que a ROM do Aleste Gaiden não funcionava nessa MegaFlashROM 512Kb, apesar de rodar muitos jogos MegaROM, incluindo MetalGear2 e Goonies ‘R’ Good Enough, ambos de 512Kb, de mesma capacidade da ROM do Aleste Gaiden.

Marcamos, eu, Sergio e sua noiva, Cristina Simões e também o Rogério Matte (MSX ARM) no Shopping Light no centro de São Paulo, onde o Sergio me levou uma versão dessa MegaFlashROM 512Kb, com todos os chips soquetados afim de que pudéssemos modificá-la, caso fosse necessário, mas olhando a descrição da MegaFlashROM na própria plaquinha, dizia MegaFlashROM Konami4, o que já indicava uma pista do “problemão” que teríamos que resolver.

Não dá apara avançar nas explicações sem antes falar sobre a…

…DSK2ROM

O projeto DSK2ROM apesar de ser excelente e complexo tem um conceito bastante simples, ele simplesmente adiciona uma DISKBIOS modificada para “enxergar” a mapper da MegaFlashROM como se fosse um disco, mas infelizmente a DSK2ROM não suporta mapper Konami4 e para chegar a essa conclusão eu havia iniciado um trabalho de desenvolvimento de um novo gravador de flash para a MegaFlashROM que seria o responsável de patchear o software e DISKBIOS corretamente para a mapper Konami4, desenvolvi então o DSK2FLASH e fiz alguns testes com o jogo Aleste 1, que também não funcionava nessa mesma MegaFlashROM Konami4, entretanto cheguei a conclusão que o trabalho em cima da DISKBIOS seria bem demorado e que se o pessoal concordasse eu começaria os trabalhos em cima disso, mas não seria algo imediato e levaria talvez alguns meses até que tudo estivesse concluído.

O pessoal do projeto concordou em esperar mais um tempo até que eu tivesse tudo concluído mas nesse momento o inesperado aconteceu novamente. Como as notícias correm rápido e até mesmo porque depois que expliquei tecnicamente, exatamente, o que precisaríamos fazer para ter o Aleste Gaiden rodando nessa MegaFlashROM K4, algumas horas após expor esse fato na lista dos participantes do projeto, eu recebi um email do Marcelo Zoffy que eu conheci naquele exato momento em que lia aquele email mas que já de entrada havia ganho minha apreciação, admiração e respeito.

No email ele me dizia que havia feito exatamente o que eu precisava, inclusive já tinha uma ROM do Aleste Gaiden preparada para rodar na MegaFlasgROM Konami4, mas que só havia testado em um OpenMSX e nunca em um MSX real, ROM essa que estava inclusa em anexo no email. Nem precisa dizer que testei essa ROM correndo em vários MSX, desde MSX2 importados, MSX TurboR e também no ZemmixNeo, todos funcionando 100% e de primeira.

Agradeci ao Marcelo Zoffy, prometi que enviaria um cartucho novinho para ele assim que o mesmo estivesse pronto, peguei a ROM enviada por ele reenviei ao Julio Lemos para que ele aplicasse a sua modificação que chaveia o modo de operação para Z80 nos MSX TurboR e em 1 semana já tínhamos tudo pronto para lançar os cartuchos.

Após tudo isso, o Sergio correu para produzir, testar e corrigir eventuais problemas nas plaquinhas de MegaFlashROM já com os cartuchos transparentes, bem como Erwin finalizou a arte dos adesivos que estampam a frente dos cartuchos do Aleste Gaiden, que podem ser apreciadas nas fotos abaixo 🙂

Me lembro que há uns 3 anos atrás eu lancei o concurso Pop!Dev, visando premiar o desenvolvimento de software para MegaRAM, na época, onde o prêmio seria justamente uma MegaRAM 2MB. Infelizmente não houveram participantes nesse concurso e o mesmo foi cancelado alguns meses depois.

Felizmente ao participar de iniciativas como essa, onde membros da comunidade estão realmente focados em fazer algo acontecer, me faz repensar o relançamento do Pop!Dev novamente, sob outros moldes.

Posso afirmar que os vencedores do Pop!Dev do Aleste Gaiden, foram Marcelo Zoffy e Julio Lemos 🙂

Conforme prometido, tanto o Marcelo Zoffy, quanto o Julio Lemos, receberam 1 cartucho do Aleste Gaiden cada um deles pela grandiosa ajuda nesse projeto, pois sem eles talvez a ROM utilizada não fosse a do Aleste Gaiden, conforme pensado originalmente.

Agradeço também ao Sergio, que como um dos pais do projeto demonstrou uma grande capacidade e agilidade de “movimentação”, pois sabemos que em projetos desse tipo é necessário alguém com essa força em fazer a coisa acontecer, bem como ao Erwin pelas ideias e arte do cartucho e também a todos os que patrocinaram o projeto, sem vocês ele não teria acontecido nessa proporção em que aconteceu.

[]’s
PopolonY2k

Print Friendly, PDF & Email

Pop!Dev – Concurso de desenvolvimento de software para MSX (MegaRAM edition) – Cancelado

Há alguns meses atrás fiz um anúncio aqui no blog, sobre o primeiro concurso de desenvolvimento de software para MSX, patrocinado pelo site PopolonY2k Rulezz, o Pop!Dev.

Conforme anunciado em outubro do ano passado, o objetivo era fomentar o desenvolvimento de software para MSX utilizando a MegaRAM, sendo o prêmio uma MegaRAM de 2MB da ACVS (limited edition).

MSX Basic Screen
MSX Basic Screen

A data limite para entrega dos trabalhos foi no 25 de abril e infelizmente não houve inscrições no concurso, o que o cancelou automaticamente.

Infelizmente não consegui notificar o cancelamento do concurso na época, devido a um momento bastante corrido pelo qual eu estava passando (de fato ainda estou, mas em escala menor hoje).

Em breve vou reeditar o concurso, talvez abrindo também para a comunidade internacional, mas no momento não tenho previsão de quando fazê-lo.

[]’s
PopolonY2k

Print Friendly, PDF & Email

10 regras da NASA para desenvolver código seguro.

Recentemente postei nas comunidades GDMSX do FaceBook e do G+ um texto bem interessantante sobre algumas dicas da NASA de como desenvolver código seguro.

Isso é muito interessante principalmente para aqueles que desenvolvem código para sistemas/dispositivos que nunca pode se dar ao luxo de uma exceção não tratada ou um core dump, comuns no mundo UNIX ou os famosos GPF’s bem conhecidos para programadores do mundo Windows.

Alguns membros da comunidade GDMSX me pediram para traduzir, então eu decidi fazer uma tradução livre, com algumas considerações pessoais que estão marcadas no texto como “(*) Notas do tradutor” 🙂 .

Vamos ao texto.

10 regras da NASA para desenvolver código seguro.

NASA Computers
NASA Computers

A NASA tem escrito software de missão crítica para a exploração espacial por décadas e agora a organização está transformando esses guias de programação em um padrão de desenvolvimento de software da indústria.

O laboratório de propulsão a jato da NASA para softwares confiáveis (JPL), recentemente publicou um conjunto de guias de programação (code guidelines), “Potência de 10 – Regras para o desenvolvimento seguro de código crítico“. O autor do texto, o cientista chefe Gerard J. Holzmann, explicou que a quantidade de codificação existente é inconsistente e cheia de regras arbitrarias, raramente permitindo tarefas essenciais como verificação de conformidade de código baseado em ferramentas de checagem de código. Os guias existentes, ele disse, inundam os programadores com regras vagas, diminuindo a qualidade do código da maioria das aplicações críticas.

“Projetos mais sérios de desenvolvimento de software usam guias de codificação,” escreveu Holzmann. “Esses guias destinam-se a firmar as regras básicas para o qual o software está sendo escrito: como ele deveria ser estruturado e quais características da linguagem deveriam e não deveriam ser usadas. Curiosamente, existe um pouco de consenso sobre o que é um bom padrão de codificação.”

 Holzmann definiu 10 regras rígidas para o desenvolvimento de software, tendo em mente a segurança do código. As regras foram especificamente escritas levando em consideração a linguagem C (uma linguagem recomendada pela NASA devido a sua longa história no desenvolvimento de software crítico e seguro e também pelo extensivo suporte de ferramentas a essa linguagem como por exemplo analisadores de código, depuradores, ferramentas de testes, dentre outras), embora essas regras possam ser facilmente generalizadas para codificação em qualquer outra linguagem, principalmente as que tem forte similaridade com C no nível de estruturação, como é o caso de Pascal e suas variantes.

  1.  Restrinja toda a construção de seu código a um fluxo de controle muito simples. Não use declarações GOTO, construções com setjmp ou longjmp, ou recursividade direta ou indireta;

    (*) Nota do tradutor:
    Quanto ao GOTO não é preciso nem escrever muito a seu respeito pois um de seus “males”, que é o de deixar o código confuso através de saltos incondicionais, já são amplamente conhecidos ao longo dos anos. O mesmo acontece com a dupla setjmp/longjmp que causam o mesmo efeito do GOTO, mas infelizmente esse recurso ainda é muito defendido por programadores experientes de C que muitas vezes se recusam a abandoná-los.
    Quanto à recursividade direta ou indireta, realmente essas tornam o código mais complexo entretanto por diversas vezes o seu código pode se tornar mais eficaz do que utilizando métodos tradicionais para resolução de um problema. Um exemplo é o algoritmo de multiplicação reconhecidamente veloz conhecido como algoritmo de Karatsuba e que é recursivo.
    Eu particularmente sugiro que se utilize métodos recursivos pequenos e de baixa complexidade, pois dessa forma pode-se evitar possíveis pontos de falhas que são invisíveis na maioria das vezes em tempo de desenvolvimento, mas que são comuns em uma situação de missão crítica.
    Quando se optar por implementar métodos recursivos, tenha em mente que a cobertura de seus testes unitários deverá ser extremamente abrangente a ponto de se testar as mínimas situações de falha.

  2. Todos os loops devem ter um limite superior fixo. Isso deve ser trivial para uma ferramenta de checagem que prove, estaticamente, que um dado limite no número de iterações não pode ser excedido. Se o limite do loop não puder ser comprovado estaticamente, a regra é considerada violada. Caso os limites sejam violados, o método deverá disparar um assert a ser verificado pelo chamador.

    (*) Nota do tradutor:
    Essa regra pode ser checada através da implementação de testes unitários com os devidos cenários mapeados.

  3. Não use alocação dinâmica de memória após a inicialização.

    (*) Nota do tradutor
    Realmente alocação dinâmica em linguagens que não são gerenciadas por um Garbage Collector é algo crítico e que deve ser utilizado de maneira cuidadosa, principalmente para principiantes no desenvolvimento de software. No artigo original, o autor cita diversos dos problemas conhecidos em se utilizar alocação dinâmica como a não liberação de recursos corretamente, o que causam os famosos vazamentos de memória ou memory leaks, e também cita sobre o cuidado de não ultrapassar os limites da memória alocada, esse último sendo também um problema quando se está usando memória alocada estaticamente em C.
    Entretanto existem casos que a alocação dinâmica é necessária e não há como escapar, nesses casos o mais comum a se fazer é alocar o buffer desejado em um ponto único, fazer toda e qualquer referência a esse buffer através de ponteiros passados para as funções que irão manipulá-lo e por fim liberá-lo nesse mesmo ponto único em que foi alocado, de preferência. Dessa forma você restringe toda a construção de seu código a um fluxo de controle muito simples, que é exatamente o primeiro item sugerido por esse guideline.
    Muitos dos desenvolvedores de softwares novatos sequer tem conhecimento de problemas de fragmentação de memória, decorrentes do abuso excessivo de alocação e liberação dinâmica de memória, principalmente em dispositivos de missão crítica que geralmente são hardwares embarcados dedicados e com recursos limitadíssimos de memória e armazenamento.

  4. Nenhuma função deve ser tão extensa que não possa ser impressa em uma única folha de papel (em uma referência ao formato padrão com uma linha por instrução e uma linha por declaração). Tipicamente isso significa não mais do que 60 linhas de código por função.

    (*) Nota do tradutor
    Manter o código com poucas linhas por função é sempre uma excelente prática pois facilita na manutenção do mesmo, entretanto algumas vezes principalmente em se tratando de código que gerencia máquinas de estado complexas, é melhor que a função fique um pouco maior do que as 60 linhas sugeridas ao invés de quebrá-las em mais funções para que comporte as 60 linhas, pois se ganha em performance, uma vez que se reduz o custo das passagens de parâmetros entre funções, ainda mais em se tratando de passagem de parâmetros de grandes estruturas por valor, que nesse caso é também uma péssima prática e que deveria ser substituída por passagem por referência ou ponteiro. Em linguagens orientadas a objeto, a regra de 60 linhas por método (função) é mais plausível e fácil de se atingir por conta da capacidade de encapsulamento dessas linguagens.

  5. A quantidade de asserts por função deve ser de no mínimo duas por função. Asserts não devem causar nenhum efeito colateral no código e deveriam ser definidos como testes booleanos.

    (*) Nota do tradutor
    Linguagens com um rico pré-processador como são C e C++ são propensas a inserção de asserts que estarão ativos dependendo do modelo de compilação em que o  binário/executável foi gerado, com isso pode-se gerar compilações de software específicas para testes.

  6. Dados devem ser declarados no menor nível de escopo possível.

    (*) Nota do tradutor
    O uso de variáveis globais é algo que vem sendo desestimulado no decorrer dos anos, pois é reconhecido que manter os dados encapsulados em escopos cada vez menores é um grande facilitador na hora de se descobrir bugs ou realizar qualquer tipo de manutenção ou melhorias no código, então declarar variáveis específicas de cada escopo é uma boa prática de programação.

  7. Cada função chamadora deve checar o retorno de funções não void (que retornam valores) e a validade dos parâmetros devem ser checadas dentro de cada função.

    (*) Nota do tradutor
    Isso é algo óbvio……bom, pelo menos deveria ser 🙂 .

  8. Uso de pré-processador deve ser limitado a inclusão de arquivos header e definição simples de macros. Macros complexas como as recursivas e com listas de argumentos variáveis, devem ser evitadas.

    (*) Nota do tradutor No texto original o autor descreve que o uso de macros de compilação condicional é algo dúbio entretanto não pode ser sempre ignorado. Eu concordo plenamente com a ideia de que não pode ser ignorado, uma vez que sempre tivemos diversas plataformas diferentes e dominantes na história da computação moderna, e o uso do pré-processador para se ter suporte a compilação condicional é uma excelente técnica que tem possibilitado manter um código portátil entre as diversas plataformas que vão desde os diversos sistemas operacionais disponíveis em PC’s até aos diversos dispositivos mobile existentes hoje.

  9. O uso de ponteiros deve ser restrito. Especificamente, não mais do que um nível de deferenciação é permitido. Operações de deferenciação de ponteiro não podem estar escondidas em macros ou dentro de declarações typedef. Ponteiros de função não são permitidos.

    (*) Nota do tradutor.
    Talvez esse seja o mais polêmico item do guia. Operações com ponteiros são algumas vezes complexas dependendo do nível de deferenciação. São raros os casos em que é necessário o uso de ponteiros duplos ou triplos, entretanto pode ser evitado e sugiro que seja evitado.
    Quanto ao uso de macros para deixar a deferenciação mais “limpa e clara”, para mim isso tem um nome e se chama “armadilha”. Fuja de quaisquer construções que “escondam” a complexidade de alguma operação, e essa regra não deve ser considerada apenas nas operações de ponteiros.
    Entretanto há ressalvas quanto ao uso de typedefs na declaração de um tipo ponteiro,  como por exemplo as definições de ponteiros para funções amplamente utilizadas nas API’s do Windows e UNIXes em geral, nesse caso não há como escapar uma vez que esses sistemas operacionais fazem uso extensivo de callbacks para proporcionar respostas a eventos requeridos e necessários para a aplicação do usuário.
    Quanto a proibição de ponteiros para função, talvez para a maioria das aplicações comuns de desktop seu uso realmente não seja necessário, entretanto para aplicações de missão crítica embarcadas como as que utilizam algum kernel real-time, como por exemplo o uC de Jean Labrosse e que fazem extenso uso de ponteiros para função para implementar as diversas tasks da aplicação do usuário, o uso de ponteiro de função é algo bem comum.
    A construção de softwares kernel real-time é repleta de ponteiros de função, até mesmo para proporcionar uma abstração de tasks, timers dentre outras estruturas típicas desse tipo de software.

  10. Todo código deve ser compilável desde o primeiro dia de desenvolvimento, com todos warnings do compilador ativados. Todo código deve compilar com essa configuração, sem gerar nenhum warning ou erro. Todo código deve ser checado diariamente com pelo menos um – de preferência mais do que um – excelente analisador de código estático (o que ele cita como analisador estado-da-arte), e a análise deve passar sem warning algum.

    (*) Nota do tradutor
    Quanto ao detalhe dos warnings de compilação, acredito que já seja bem comum em grandes projetos, entretanto a parte do analisador “estado-da-arte”, não creio que sequer mercados corporativos em países avançados a utilizem, exceto empresas de altíssima tecnologia que dependam de que seus softwares funcionem 24×7 ou de forma embarcada em algum dispositivo.

 Holzmann incluiu diversos comentários no documento original para cada uma das regras descritas acima, mas a essência do documento é que quando as regras forem utilizadas em conjunto, garantam um fluxo claro e transparente que tornem fácil a construção, testes e análise de código amplamente aceitos como livres de falhas. A JPL tem desenvolvido softwares automatizados para missões espaciais como a Mars Curiosity and a Voyager, e o laboratório já está usando essas regras em uma base experimental para escrever software de missão crítica.

Holzmann acredita que seguir as regras da NASA minuciosamente, pode diminuir a carga sobre os desenvolvedores e levar a uma melhor segurança e clareza do código.

“Se as regras parecerem draconianas no inicio, tenha em mente que elas foram criadas para que se possa checar códigos onde a sua vida pode depender muito de que haja precisão: código utilizado para controlar o avião em que você voa, a usina nuclear a poucas milhas de onde você vive, as aeronaves que carregam os astronautas em órbita”, escreve ele.

“As regras agem como o cinto de segurança em seu carro: Inicialmente eles parecem ser um pouco desconfortáveis, mas depois de um tempo seu uso se torna natural e não usá-los se torna inimaginável.”

O texto acima foi traduzido do original que pode encontrado no link do site SDTimes abaixo:

http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/

[]’s
PopolonY2k

Print Friendly, PDF & Email

R.I.P MSN !!!

Finalmente a rede MSN está fora do ar. No ultimo dia 31 de outubro a Microsoft iniciou o desligamento dos servidores que ainda mantinham a rede MSN ativa.

Apesar do anúncio feito há quase 2 anos de que o MSN seria desativado em favor do Skype, a Microsoft manteve os servidores MSN ativos graças ao mercado Chinês que obrigava a empresa a manter o serviço, principalmente por conta de contratos com empresas locais de telefonia que contavam com o MSN como parte do pacote de serviços mobile disponíveis em seus planos aos usuários chineses.

Por conta disso, desde o anúncio da “morte” da rede MSN em 2012, ainda era possível acessar essa rede utilizando clientes não oficiais como o PlanetaMessenger.org, Adium, PidginIM e MirandaIM. Um pouco mais de 1 mês após o último anúncio da desativação dos servidores MSN, finalmente chegou o momento em que podemos dizer que a rede está fora do ar e dessa vez foi para talvez nunca mais voltar.

Damned skype
Damned Skype

Digo isso pois essa semana o plugin MSN do projeto Open Source que mantenho há mais de 13 anos, o PlanetaMessenger.org, não consegue mais estabelecer conexão com o Dispatcher Server (*) do serviço MSN, bem como outros clientes mobile para Android, como o IM+.

(*) Dispatch Server é um dos servidores da rede MSN que informam qual o Notification Server (*) está disponível para o cliente se conectar.

(*) Notification Server é um dos servidores da rede MSN que providenciam alguns serviços como login, notificação de presença, lista de contatos, etc…

Isso já havia acontecido no passado, exatamente em outubro de 2003, entretanto naquele mesmo ano, alguns meses antes já era conhecido que a Microsoft bloquearia os clientes não oficiais que usavam a rede MSN com protocolos anteriores ao MSNP8. Por esse motivo eu fiz a engenharia reversa do protocolo MSNP8 do cliente oficial e implementei o novo modelo de autenticação SSL e demais pacotes necessários, na biblioteca do plugin MSN do PlanetaMessenger.org denominada JMML (Java MSN Messenger Library), e voilá, após isso a Microsoft nunca mais conseguiu retirar o PlanetaMessenger.org da rede MSN.

Se passaram mais de 10 anos e nesse intervalo eu vi o PidginIM, Adium e o MirandaIM terem suas implementações do protocolo MSN bloqueadas várias vezes, obrigando-os a fazer patches de correção para manter seus clientes conectados na rede MSN, entretanto a implementação do protocolo MSN do PlanetaMessenger.org (JMML) se manteve firme e forte nesse intervalo de tempo, nunca tendo sido afetada por esses bloqueios, apenas recebendo atualizações pertinentes a correções de bugs e problemas de segurança.

O mesmo aconteceu para os projetos que utilizaram a biblioteca JMML para se conectar na rede MSN, pois até onde sei alguns grandes nomes desse mercado de clientes e servidores de mensagens instantâneas, como o projeto OpenFire da Ignite realtime/JiveSoftware jamais tiveram nenhum problema de acesso à rede MSN, enquanto utilizaram a JMML em seu core.

R.I.P MSN
R.I.P MSN

Agora apenas me resta deixar que a JMML descanse em paz junto com a rede MSN……ou quem sabe fazer um servidor compatível com MSN . 🙂

Enjoy.

[]’s
PopolonY2k

Referência

MSN – Windows Live Messenger (Wikipedia)
http://en.wikipedia.org/wiki/Windows_Live_Messenger

Skype official website
http://www.skype.com/

Microsoft official website
http://www.microsoft.com

PlanetaMessenger.org official website
http://www.planetamessenger.org

Adium official website
https://adium.im/

PidginIM official website
https://pidgin.im/

MirandaIM official website
http://www.miranda-im.org/

IM+ mobile messenger
https://plus.im/

MSNP8 Protocol (Wikipedia)
http://en.wikipedia.org/wiki/Microsoft_Notification_Protocol#MSNP8

PlanetaMessenger.org Libraries (JMML, DJcq2k, ComVC, …)
http://sourceforge.net/projects/pmlibs/

OpenFire (Ignite realtime/Jive Software)
http://www.igniterealtime.org/projects/openfire/

Ignite realtime/Jivesoftware about page
http://www.igniterealtime.org/about/index.jsp

PlanetaMessenger.org’s Sourceforge.net project’s page
http://sourceforge.net/projects/planeta/

News about MSN network ending.
http://www.neowin.net/…/msn-messenger-will-finally-shut-dow…
http://www.windowscentral.com/msn-messenger-shut-down-china…

Print Friendly, PDF & Email