CMake

From Eric Sink's blog:

"One of the toughest parts of cross-platform development is the build system.  No matter how clean and portable your C code is, getting the tree to build on multiple platforms is a whole different problem.

One solution I have used in the past is to do a completely Unix-centric build system with bash and make, using cygwin to run it under Windows.  This works very well, except that it really annoys the folks who prefer Visual Studio project files.

[...]

This week I discovered a nifty tool I had never seen before.  It's called CMake, and it's the build system used for Kitware's Visualization Toolkit.  I've seen lots of alternatives to 'make', but this tool is surprisingly different and deeply neato."

[Eric.Weblog()]

 

mapping Win32API to .NET equivalent

From Chris Sells:

Tim Tabor points out a new find, a mapping from Win32 API functions to the closest equivalent in the .NET Framework class library. This is an amazing resource for folks making the switch.
[Marquee de Sells: Chris's insight outlet]

Sviluppare senza essere Amministratori della macchina

From Marco Russo's blog:

Molti blog (tra cui quello di Paolo) hanno già notificato questo documento su MSDN che riassume gli interventi da fare per sviluppare senza essere amministratori.
Dopo 6 mesi di questa esperienza quello che posso dire è che la cosa più difficile, in realtà, non è sviluppare ma essere utenti "avanzati". Quello che nessuno spiega, infatti, è come far funzionare quelle centinaia di programmi e utility che vogliamo installare sul PC che usiamo tutti i giorni anche per lavorare.
Per venirne a capo, esistono due tool assolutamente indispensabili e di cui non posso più fare a meno: FileMon e RegMon.
Quando un programma non vuol saperne di funzionare senza avere un utente amministratore, in genere i problemi sono:

• apre dei file di configurazione in read/write anche se deve solo leggerli, e questi file sono nella directory di installazione del programma (sotto Programmi/Program Files, che per un utente normale è tutta read-only) - con FileMon si capisce quale file tenta di aprire (fallendo) e quindi, modificando i diritti di accesso su tale file, si risolve il problema
• apre una chiave di registry all'interno di HKEY_LOCAL_MACHINE in read/write, quando deve solo leggere (le scritture, al di fuori dell'installazione, andrebbero fatte sempre e solo su HKEY_CURRENT_USER) - con RegMon si individua il problema e... se si riesce, si modificano gli accessi al registry (usare REGEDT32.EXE su Windows 2000, da Windows XP in poi è tutto integrato in REGEDIT.EXE)
• tenta di aprire in scrittura qualcosa nelle directory di sistema di Windows: qui è meglio sbarazzarsi del software e trovarne uno scritto meglio...
• registrano dei componenti COM/ActiveX a ogni avvio dell'applicazione: anche qui insultate i programmatori... perché questo comportamento non dovrebbe essere ammissibile al di fuori dell'attività di setup - non ci sono grandi soluzioni se non eseguire tali programmi con RunAs...

A parte questi inconvenienti, sviluppare con un utente che non è amministratore è non solo possibile ma addirittura vantaggioso, perché consente di avere coscienza di cosa un programma deve fare e cosa no... prima che ve lo dica qualche utente/amministratore di rete un po' arrabbiato...
[Marco Russo's BLog]