Computer made music

Chiptune is a music category that has grown over the last few years and it is composed often by musicians, users and fans of old computers. This new music category is growing thanks to a generation whose childhood was affected in some way by computers.

Those who were born in the 70‚Äės and 80’s know exactly what about I’m writing, because in those days anyone who could get any kind of computer now was able to remember the magic behind it’s sounds and songs created for those machines.

If you lived those magic days, brands like Commodore, Apple, Texas, Philips are familiar to you and some systems and computers standards like C64, AppleII, Amiga, Spectrum, Amstrad CPC and MSX in some way have had some importance and maybe influenced you in your career or hobby.

Today several mainstream artists have been submitting their songs to be produced by producers that were influenced by C64 game made songs and by Amiga demosceners artists. The most famous example of this influence is a recent scandal involving the well known producer Timbaland that has been accused of plagiarism by Amiga computer fans, when he worked for Nelly Furtado’s album, Loose, released in 2006.


Comparing both songs

This is a well known story and in fact Timbaland revealed to have plagiarized some elements of several Amiga’s composers including the demoscener artist Janne Suni (a.k.a Tempest). One of the songs plagiarized by Timbaland was composed by Tempest for the Oldskool Music competition (Assembly 2000) which occurred in 2000 in Helsinki, Finland and reached the first place in the competition.


Nice try Timbaland ūüôĀ
.

To be continued...

[]’s
PopolonY2k

Reference

ChipTune (Wikipedia)
http://en.wikipedia.org/wiki/Chiptune

Timbaland (Wikipedia)
http://en.wikipedia.org/wiki/Timbaland

Nelly Furtado (Wikipedia)
http://en.wikipedia.org/wiki/Nelly_Furtado

Timbaland Plagiarism controversy (Wikipedia)
http://en.wikipedia.org/wiki/Timbaland_plagiarism_controversy

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

Game review – Mr.Bree+

No final de 2012, participei de uma pequena palestra do pessoal da Taw Studio, um pequeno est√ļdio localizado na cidade de Pindamonhangaba no interior de S√£o Paulo, promovida nas instala√ß√Ķes do Acr√≥polis estudio de Arte e escola de mang√°, a respeito de seu principal game na √©poca, o Mr. Bree+.

Mr.Bree+ Wallpaper

Mr.Bree+ Wallpaper

Desde ent√£o, fiquei bastante interessado em adquirir o game, uma vez que os autores disseram que em breve o mesmo estaria dispon√≠vel em algumas game stores nacionais. Pouco tempo depois me tornei parceiro para reviews de jogos da SplitPlay desde o inicio de suas opera√ß√Ķes, mas naquela √©poca a SplitPlay ainda estava se organizando e fechando parcerias com diversos est√ļdios indies nacionais e o Mr. Bree+ ainda n√£o estava em sua loja, entretanto em menos de 2 meses, felizmente o mesmo foi adicionado √† sua lista de jogos. Lembrando que hoje a SplitPlay lan√ßa jogos indies nacionais instantaneamente a seu lan√ßamento no mercado, tendo alguns lan√ßados primeiramente l√°.

O Jogo

O jogo come√ßa com uma excelente apresenta√ß√£o do porquinho (Mr.Bree) caindo ferido na floresta, visivelmente perdido e sem mem√≥ria. Ap√≥s a apresenta√ß√£o o jogo inicia em um pequeno labirinto, onde Mr. Bree deve avan√ßar, passando por obst√°culos que v√£o dificultando a cada novo est√°gio. Al√©m de passar pelos obst√°culos, Mr.Bree deve coletar umas pe√ßas vermelhas no formato de um quebra-cabe√ßas, que de fato s√£o as “suas mem√≥rias”.

Ao coletar uma “mem√≥ria”, Mr. Bree vai relembrando as suas habilidades, que lhe ser√£o essenciais para a finaliza√ß√£o do jogo.

Mr.Bree+ Promo

Mr.Bree+ Promo

Foi impossível não comparar o Mr.Bree+ com alguns jogos de MSX, como o The Goonies e principalmente o jogo onde Popolon (e Aphrodite) são protagonistas da saga Knightmare, The Maze Of Galious, pois em minha opinião esses jogos estão na mesma categoria (platform puzzle games).

The Goonies.

The Goonies (MSX)

Kinghtmare - The Maze of Galious

Kinghtmare – The Maze of Galious (MSX)

O porquinho Mr.Bree, de fato é um porquinho fazendeiro que repentinamente é aprisionado e separado de sua família. A partir daí a sua saga se inicia em busca de suas lembranças e de seus familiares.

Análise técnica

A arte do jogo √© excepcional, sendo cada detalhe gr√°fico muito bem desenhado e cuidadosamente detalhado. As anima√ß√Ķes que ocorrem no decorrer do jogo tamb√©m s√£o muito bem feitas, seguindo o mesmo padr√£o gr√°fico do jogo.

A partir da segunda fase é possível perceber que os desenvolvedores utilizaram pelo menos 3 layers de fundo, o que proporcionou um ótimo efeito no scroll parallax a medida que o Mr.Bree se movimenta.

Apesar de todas as 45 fases e das 15 secretas que o jogo possui, o diferencial do Mr.Bree+, em minha opini√£o, ficou por conta da excelente m√ļsica e como todo bom jogo, Mr.Bree+ tem em suas m√ļsicas o¬† essencial para manter o interesse dos fans no jogo durante todas as fases.

Infelizmente o jogo não está disponível para todos os principais sistemas operacionais e só é compatível com Windows e MacOSX.

Notas finais

  1. Gráficos  10
  2. Efeitos sonoros 10
  3. Trilha sonora 10
  4. Jogabilidade 10
  5. Portabilidade 6.5
  6. Nota final 9.3

Um ótimo jogo nacional, e ainda por um ótimo preço na SplitPlay.

[]’s
PopolonY2k

Referência na internet

Taw Studio
http://tawstudio.com/

SplitPlay (PopolonY2k rulezz)
http://www.popolony2k.com.br/?p=2331

The Goonies (Wikipedia – MSX)
http://en.wikipedia.org/wiki/The_Goonies_%28MSX%29

Maze of Galious (Wikipedia)
http://en.wikipedia.org/wiki/The_Maze_of_Galious

Platform games (Wikipedia)
http://en.wikipedia.org/wiki/Platform_game

Parallax Scrolling (Wikipedia)
http://en.wikipedia.org/wiki/Parallax_scrolling

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

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…