O Mythical 'Vista Application'

Eu amo analistas. Seja prevendo a próxima grande novidade de amanhã ou soando a sentença de morte para o líder da indústria de ontem, os analistas nunca ficam sem novas maneiras de errar.

Exemplo: Windows Vista e o "intervalo do aplicativo". Evans Data Corporation (EDC) , menos de 10% dos desenvolvedores estão escrevendo para o atual estado da arte da Microsoft. A maioria (49%) ainda está escrevendo para XP, enquanto um pequeno, mas crescente, contingente (13%) está se concentrando no Linux. Enquanto isso, a miríade de grandes meios de comunicação continua a criticar a falta de novos aplicativos do Vista. "É o sistema operacional que ninguém quer", dizem eles, e os desenvolvedores estão "reagindo de acordo".

É claro que estão errados. Novamente

[Mais leitura: Nossos melhores truques, dicas e ajustes do Windows 10]

Você vê, não existe um aplicativo Vista. Assim como não existe uma aplicação XP. Ou um aplicativo do Windows 2000. Os desenvolvedores que escrevem para o Windows raramente têm como alvo uma versão específica. Em vez disso, eles selecionam uma estrutura de API específica - por exemplo, MFC / ATL ou.Net - e continuam a partir daí. Se o aplicativo resultante é executado ou não em uma determinada versão do Windows depende de extensões de API específicas da versão, se houver, empregadas no projeto.

Para a maioria dos tipos de aplicativo, isso não é uma questão: eles usam o genérico Funções da API, o que permite que elas sejam executadas em qualquer versão do Windows que suporte essa estrutura. E como a Microsoft faz um bom trabalho de fazer back-port de novas estruturas para suas plataformas OS legadas, os desenvolvedores raramente se deparam com uma opção entre uma rica funcionalidade API ou uma ampla base instalada (a notável exceção é desenvolvedores de jogos de vídeo, para quem alavancar DirectX 10 significa comprometendo-se com o Vista).

Assim, todo o argumento do Vista "app gap" é um pouco difícil. A verdadeira questão deveria ser: Por que os desenvolvedores não estão aproveitando as diversas iterações do framework.Net? Como qualquer um que siga o roteiro de desenvolvimento da Microsoft irá atestar, a maior parte da evolução da API de ponta da empresa está ocorrendo dentro da.Net. Na verdade, quando os "especialistas" falam sobre novos recursos programáticos no Vista - o Windows Presentation Foundation (WPF), o Windows Communication Foundation (WCF) e assim por diante - eles estão realmente falando sobre o.Net Framework 3.0. E como o.Net 3.0 está disponível em plataformas de baixo nível (como o Windows XP), o argumento volta para uma questão de aceitação do.Net entre os desenvolvedores - e por que eles (até agora) o rejeitaram.

A resposta é dupla: primeiro, os desenvolvedores não gostam de segmentar APIs que não estão amplamente disponíveis na base instalada. Apesar do suporte agressivo da Microsoft a versões de baixo nível, ainda há uma grande diferença entre "disponível" e "disponível depois de baixar 20MB-plus de bibliotecas complexas e tê-las instaladas em várias partes do seu sistema". O fato é que o.Net não é fornecido como parte do Windows XP, e isso significa que os desenvolvedores precisam convencer os usuários a instalar primeiro a versão necessária do framework.Net antes que possam instalar um software - não sempre uma venda fácil, especialmente no mundo bloqueado da TI corporativa.

Como o primeiro sistema operacional a ser fornecido com a estrutura.Net instalada por padrão, o Vista deveria incentivar o desenvolvimento de aplicativos.Net 3.0. No entanto, como também oferece suporte aos aplicativos legados Win32, COM, ATL, MFC e de baixo nível.Net, não há falta real de programas do Vista. Na verdade, a menos que você tenha apenas que ter a maior e mais recente funcionalidade de framework WPF / WCF, há pouco para motivá-lo, o desenvolvedor, a fazer o salto para.Net 3.0, ou mesmo 2.0. Supondo que você não topar com o mecanismo UAC (User Account Control - Controle de Conta de Usuário), seu aplicativo Windows "legado" provavelmente parece e funciona muito bem no Vista como está. Eu sei, porque esse era o caso do meu próprio código: alguns ajustes para acomodar o UAC (na maior parte deslocando alguns arquivos temporários das estruturas de diretório recentemente protegidas) e meus aplicativos e serviços estavam rodando como champs sob o Vista - como fazem sob Windows XP, Server 2003 e Windows 2000. Por que consertá-lo quando não está quebrado?

A segunda razão pela qual os desenvolvedores evitam.Net é que é lento. Muitas funções comuns simplesmente demoram mais para o.Net, forçando os desenvolvedores a escolher entre a sofisticação da API e o desempenho bruto. Não surpreendentemente, a maioria dos desenvolvedores escolhe o último, como eu já fui forçado a fazer quando descobri que o equivalente em.Net do Performance Data Helper (PDH) era praticamente inutilizável para amostragem em tempo real dos dados do contador de desempenho do Windows. Como resultado, sou forçado a manter uma base de código do Visual Studio 6 envelhecida (por volta de 1997) enquanto aguardo a Microsoft para finalmente simplificar o.Net a um ponto em que é uma alternativa viável. É uma história antiga e muito comum entre os desenvolvedores do Windows.

Conclusão: Quando analistas (e seus cúmplices de mídia) duvidam da falta de "aplicativos do Vista", eles apenas proclamam sua própria ignorância.

Eu acredito que seja um Coisa do Mac: Muitos de meus contemporâneos foram apanhados no campo da distorção da realidade que a idéia de um link entre a funcionalidade da API e a versão do sistema operacional tornou-se uma parte aceita da sabedoria convencional. É um erro honesto, equiparar o arcaico patchwork de dependências de versões da Apple à imperfeita API da Microsoft, mas muito mais flexível.

Demasiada fruta fará isso com você.