Pin deprecates nmake on windows

The latest release of Pin (versionĀ 2.12-56759) removed support for nmake (and the nmake.bat that came with it) šŸ˜¦ Instead, make is now the recommended way of compiling pintools. There are several ways to get GNU make: via Cygwin, MinGW, or download the setup forĀ Make for windows manually. I chose the latter because I have no love for cygwin, which also explains why there is no link for it šŸ˜› Also, getting the entire cygwin just for make is a total overkill. I am already running MinGW from Git for Windows, so the setup alone will suffice.

There we go! Go ahead and make (or make TARGET=ia32, for those who are compiling 32-bit pintools on 64-bit OS). However, make clean still breaks (see link at bottom of post for possible explanation, however the proposed solution is still quirky for Pin), but we shall “make” do for now.

Below are the recent changes, for completeness:

Changes added _After_ Pin 2.12 / 54730
o The PinTools makefile infrastructure has been changed. It is now simpler to use and to modify.
For detailed information, read the documentation in source/tools/Config/makefile.config.
o Nmake is no longer supported on windows. Either use make or the example vcproj file in the
MyPinTool directory.
o Android support has been added. An Android tutorial is avaliable at: <android-kit-root>/AndroidTutorial.
o The directory tree under <pinkit>/source/include has been changed, the include files are now located at:
<pinkit>/source/include/pin and <pinkit>/source/include/pin/gen.

windows – make: Interrupt/Exception caught – Super User


Static routing on windows network using consumer router

I never really understood the presence of static routing on consumer grade routers. But recently, I got the opportunity to try out that functionality in office and tearing out my hair at the same time (read: networking n00b). Documenting the steps here to prevent furtherĀ hair-loss.


ISP <—> Router A [] <—> Router BĀ []

Router A
WAN IP: DHCP-assigned by ISP
Gateway:Ā DHCP-assigned by ISP
Static route: (Destination)Ā, (Netmask), (Gateway), (Interface) LAN

Router B

Basically that is all for configuration on both routers for the illustrated setup. For windows machines that are directly connected to Router A [], an incoming rule has to be added to the hosts’ firewall to allow incoming ICMP redirect packets from the Router A, assuming the firewall is enabled.

On Windows Vista and above, the following command (run as administrator) will add the rule:

netsh advfirewall firewall add rule name="enable static routing" dir=in action=allow enable=yes profile=private remoteip=defaultgateway protocol=icmpv4:5,any

In English, the command “adds a rule with name ‘enable static routing’, for theĀ incoming direction,Ā that allows traffic to pass, at the same time enabling the rule, for the private profile, only from the default gateway, with ICMP v4 redirect packets”. Tweak as needed.

Yes, it potentially requires configuration on the clients. A more transparent alternative is to dish out static routes to clients via DHCP server and eliminating the need to configure the firewall, but that is out of the scope of this post. Which brings me back to my original thought: if a user need to configure so many items, on both routers and clients, will it be better to provide an option to serve routes via DHCP? Without which, is this whole static routing even suitable for a home user on a home router?

Netsh Commands for Windows Firewall

DHCP option 121