Pude constatar as diferenças no Windows:
1) A segurança é diferente para um EXE no disco local ou no disco da rede
Se gravar o EXE em C: a segurança pega mais leve
Se o EXE está na rede, é onde tem verificação de certificado e tudo mais.
Se o EXE vai pra Microsoft, pra checagem, o certificado local não terá validade pra Microsoft
2) DBFs na rede
Se tem um EXE na pasta dos DBFs da rede, ao acessar a pasta ele é verificado
Isso explica porque o cliente sem certificado consegue trocar o EXE na hora que quiser.
Quando eu passei o EXE para o servidor, aí a segurança foi mais "pesada".
ESSE cliente pode fazer alterações no próprio EXE.
Vou usar algo mais ou menos assim no fonte:
Código: Selecionar todos
IF ! Lower( hbcwd() ) == "\\servidor\empresa\arqs"
ShellExecuteOpen( "nomeexe", ,"\\servidor\empresa\arqs" )
QUIT
ENDIF
Qual o resultado:
EXE carregado sempre local, segurança do windows não enche o saco
EXE detectando PATH local, recarrega definindo path da rede
Path da rede não tem EXE, segurança também não enche o saco
E tudo roda tranquilo, com path default sendo o path da rede.
Talvez nem precise certificado.
E o que mudou:
Não tem mais EXE na rede, pra segurança não meter o nariz.
Conclusão:
Pra segurança da Microsoft não existe rede local.
O mesmo tratamento de segurança dado a programas da internet, também é dado pra programas da rede local.
E pra segurança da internet.... coisa "mundial"... só certificado digital oficial.
Muito doido isso.
Não precisa ser nenhum expert pra perceber.
É só prestar atenção no comportamento.
Só executar um EXE em C:, e comparar com ele sendo executado na pasta da rede.
A diferença: economizar alguns milhares de reais com certificado, e encheções de saco da segurança.
Download da internet: não gravar o arquivo diretamente da internet, senão o windows marca como vindo da internet.
