A triste história da compatibilidade das versões do ObjectARX do AutoCAD.

Como já se sabe todas as vezes que muda de versão o AutoCAD vem outra vez o transtorno de se modificar a versão da suas API's. Quando você tem poucas API's isso é até fácil mas a questão é: porque o AutoCAD já não faz-se sempre compatível?

Na verdade são duas compatibilidades: (1) com a versão do ObjectARX e a (2) do ObjectARX com a versão do .NET Framework!

Os aplicativos desenvolvidos usando API's do AutoCAD precisam ser testados (e muitas vezes adaptadas) para se certificar de que eles funcionam com uma nova versão da plataforma AutoCAD, já tive aplicativos bem sucessíveis migrando do 2009 para o 2010, por exemplo. Para várias gerações de AutoCAD eles "quebram" compatibilidade de aplicativos binário uma vez a cada três versões (historicamente isso aconteceu para o AutoCAD 2000, 2004 e agora 2007). Para fazer com que as aplicações funcionam em versões intermédias eles podem precisar de trabalho portabilidade menor para migrar o uso de configurações de registro de estar sob o local certo (por exemplo), segundo o pessoal da Autodesk eles fazem alguns testes para minimizar a nossa dor.

Além disso, aplicativos implementados utilizando diferentes APIs normalmente exigem diferentes esforços para portar de uma versão para outra. Geralmente os aplicativos LISP são bastante portátil entre os lançamentos (embora os nomes e localizações de arquivos de suporte podem mudar de tempos em tempos), assim como os clientes COM (como VBA e VB externo). Os aplicativos que usam a API gerenciado (C # ou VB.NET clientes) são um pouco mais portátil do que ObjectARX (C ++) aplicações, mas como a API gerenciada vem evoluindo rapidamente que até agora não cumpre essa compatibilidade (sendo a exceção entre AutoCAD 2005 e de 2006, que era de outra maneira um release compatível aplicação binário), para a frente eu esperaria ver mais estabilidade e solte-a versão de compatibilidade das API's com a versão do AutoCAD.

Arquitetonicamente aplicações ObjectARX estão mais próximos do núcleo do AutoCAD (em termos de sua aplicação), por isso é realmente para estes módulos que os desenvolvedores - seja interna ou externa para Autodesk - precisa gastar mais esforços de desenvolvimento quando a compatibilidade de aplicativos.

GANHAMOS EM VELOCIDADE MAS PERDEMOS EM COMPATIBILIDADE

Então, por que a Autodesk quebra a compatibilidade em tudo? Bem, existem algumas razões ...

1. Às vezes, simplesmente desejo maquiavélico de atualizar classes de API, para adicionar novos métodos etc... Enquanto nós podemos adicionar métodos não-virtuais durante um lançamento API compatível, acrescentando métodos virtuais muda v-table e quebra a compatibilidade de um módulo.
   Isso é uma estratégia de mercado, se tem alguém montando em cima do AutoCAD muito comercialmente se quebra quando muda a versão do AutoCAD.
2. Também é necessário arquitetura interna ou uso da tecnologia. Um exemplo disso é nossa grande uso de Unicode em AutoCAD 2007 Este é um profundo - e de grande alcance - alteração na forma como lida com AutoCAD sequências internamente e, portanto, tem impactado muitas assinaturas de função ObjectARX.
3. Finalmente, também por aproveitar a tecnologia mais recente do compilador para construir AutoCAD. AutoCAD 2000-2002 foram construídas com Visual Studio 6, AutoCAD 2004-2006 foram construídos com o Visual Studio 2002 e AutoCAD 2007 foi construído com o Visual Studio 2005, é importante para nós para permanecer em uma versão do compilador com suporte, a fim de ser capaz para obter as questões críticas abordadas pela Microsoft, mas para além de que também nos fornece novas capacidades de desenvolvimento, tais como a possibilidade de fazer uso de WinForms em AutoCAD e expor a API gerenciada.

O terceiro ponto tem algumas sutilezas: a API C++ puro pode (em teoria) ser a versão independente, mas sempre que as classes C em tempo de execução ou MFC são usadas em assinaturas de função então você tornar-se mais intimamente ligada à versão específica do compilador usado para construir o provedor API (ou seja, AutoCAD). Então, enquanto os clientes de C ++ API's não precisam automaticamente usar a mesma versão do compilador como o provedor de API, as aplicações que utilizam ObjectARX têm essa exigência.... Isso é quase um tapa na cara de quem desenvolve usando o ObjectARX!!! Mas é verdade!

Então, por que ainda quebrar a compatibilidade cada lançamento? Por causa da dor sentida pelos nossos clientes, e por desenvolvedores. Não disponibilidade de aplicações para a liberação particular tem o potencial de impactar adoção desse lançamento, já que muitos clientes são dependentes uma aplicação independente para realizar seu trabalho. A manutenção de um-release 3 (que agora significa a 3 anos) janela dá aos desenvolvedores mais tempo para se concentrar na condução do valor do cliente através da implementação de melhorias graves aos seus aplicativos quando eles não estão se concentrando esforço de desenvolvimento em matéria de migração para suportar os requisitos básicos do novo plataforma.

Lembre-se que esses desenvolvedores são os "parceiros" oficiais da Autodesk não você que desenvolve independentemente que deve sempre correr atrás do prejuízo toda vez que uma versão nova do AutoCAD sem compatibilidade nenhuma é lançada.... Se não me engando, só para participar da ADN o "parceiro" deve desembolsar a bagatela de 12 mil dólares por ano para um suporte limitado. Aqui tem a tabela de preços.

Mas sabe como é... segundo o Kean Walmsley esse é o trabalho da DevTech, ajudar a minimizar a dor dos desenvolvedores em ambas as frentes, seja ao lidar com questões de migração ou ajudando a explicar as características adicionais e APIs disponíveis em uma nova versão de um dos produtos da Autodesk. Lembre-se por sem uma aplicvação muito grande em cima da plataforma do AutoCAD não só nós aqui fora e os parceiros sofrem como também as frentes de trabalho dos desenvolvedores de aplicação interna deles que tem que adaptar tudo em tempo de lançar o Release novo.

Esse artigo foi baseado na série de artigos do ThroughThe Interface.