Ok, you admit to your self, I did press the cancel button. But this function clearly says that it will return code different than S_OK. It never says anything about any exceptions. And can COM even raise exception in my code? Aha! Real culprit must sit in COM interop layer.

Precise dose of googling (or binging) gives source of misery. Some helpful soul in .NET design team decided that COMException will be thrown whenever HRESULT returns anything that is not success. And thus, something that ought to handled by simple conditional statement (formerly known as if) is now trashing our carefully woven code. Fortunately, smart guy from same team gave us antidote in form of PreserveSig attribute. Small dose of said attribute at function call alleviates all issues.

P.S. Normal person would just say to apply PreserveSig attribute to any function whose result code is handled within your code.

P.P.S. Even smarter person would give you the code:

[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
[PreserveSig()]
uint Show([In, Optional] IntPtr hwndOwner);

Upgrade to DD-WRT went without a hitch. However, as soon as it booted I noticed that I was getting DHCP address from my hotel’s server instead from router. Quick investigation revealed that there was no WAN port configured. Single port was in my LAN segment and thus it was leaking everything. Solution for that ought to be simple – I just went to Setup -> Networking and changed WAN assignment there. It seemed to work but, as soon as I rebooted router, everything went back to original state. Quite annoying.

Quick googling revealed something that looked quite close to solution but it didn’t work for me. I could get it to work sometime but every time after restart it would put my WAN port into default bridge. Not quite what I wanted.

In order to debug this I executed nvram show after clean install and then I executed it again after everything got working. That gave me delta that I had to apply. And, as far as bridges go, I decided to manually remove eth0 (WAN port) from default bridge.

Final result was this start-up script (Administration > Commands):

brctl delif br0 eth0
nvram set lan_ifnames="eth1"
nvram set wan_ifname="eth0"
nvram set wan_ifname2="eth0"
nvram set wan_ifnames="eth0"
nvram set wanup=0
nvram unset dhcpc_done
nvram commit
udhcpc -i eth0 -p /var/run/udhcpc.pid -s /tmp/udhcpc &

First line just ensures that WAN port is thrown out of bridge. All those nvram lines sort out minor differences. Last line enables DHCP renewal on WAN interface. After startup that should produce bridge state as displayed on picture. Just what I wanted. :)

Only thing that might look funny afterward is that both WLAN and LAN interface have same MAC address. To solve this we need to telnet (or ssh) to machine and execute following commands:

nvram get lan_hwaddr
nvram get wan_hwaddr
nvram get wl0_hwaddr

Each command will give you MAC address of each interface. In my case this was:
lan_hwaddr = F4:6D:06:94:02:39
wan_hwaddr = F4:6D:06:94:02:39
wl0_hwaddr = F4:6D:06:94:02:3B
From that we can interpolate that wan_hwaddr should be F4:6D:06:94:02:3A (just before wireless and just after LAN). Only thing to do now is to enhance our startup script (somewhere BEFORE nvram commit) with:

nvram set wan_hwaddr=F4:6D:06:94:02:3A
nvram set et0macaddr=F4:6D:06:94:02:3A

This game with MAC is not strictly necessary but I like to set it anyhow.

I tested this on build 14896 (recommended for Asus WL-330GE in router database) and on special build 15962 (recommended on forums as stable).

P.S. Next time remember not to take router advice from Windows programmer.

Most noticeable change here is having everything accessible over toolbar. In past some options were in hidden menu but that menu is gone now.

Other feature that is long overdue is upgrade functionality within application.

There was also some bug-fixing involved but that stuff is too boring.

Enjoy new version.

Initial diagnosis was easy – there was no .NET Framework installed. While there is no way to install .NET Framework 3.5 on Windows Thin PC, .NET Framework 4.0 installs just fine.

Next run gave us another clue with System.IO.FileNotFoundException: Could not load file or assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.

While .NET 4 is backward compatible, Microsoft made intentional decision that it will not run applications made with earlier runtimes. This is not a big issue in Windows 7. There you have 2.0, 3.5 and 4.0 installed side-by-side and each application can pick whatever it needs. However, in Windows Thin PC there is only 2.0 and 4.0. Notice that one version is missing and it was the one I needed.

To make long story short, there is solution that does not involve recompiling. Just add Application Configuration Files (App.config) and put following text into it:

<?xml version="1.0"?>
<configuration>
    <startup>
        <supportedRuntime version="v4.0" />
        <supportedRuntime version="v2.0.50727" />
    </startup>
</configuration>

This will tell application to run on .NET 4 if possible and to fallback to 3.5, 3.0 and 2.0 as a backup solution. This might not be most beautiful solution but it is a solution that works.

P.S. Yes, supportedRuntime cannot distinguish between .NET 2.0, 3.0 and 3.5.

I haven’t moved because Windows were unstable (haven’t had any issues). I haven’t moved because of bugs (PHP is buggy on any platform). I haven’t got tired of .NET (C# rules!).

I moved because of SSH. I grew tired of plain-text FTP where any kid with Wireshark could get my password.

My hosting company made sure that server change went smoothly. They just switched DNS records and, poof, my website on new server started. It is true that, for a while, there was no CSS or JavaScript but culprit was found in W3 Total Cache plugin. It just didn’t like being copied around and quick uninstall sorted that out. :)

There were few other minor issues with upgrade service for VHD Attach and QText but they had more to do with subtle differences between Windows and Linux hosting than with any real error.

Now let’s just hope that I don’t break everything. :)

I do plan to sort things out in later version.

As a router I will use my trusty DD-WRT. Exact version used in this example is DD-WRT v24-sp2 (12/08/11) std-nokaid (SVN revision 17990M NEWD-2 Eko). Your mileage may vary depending on version of your choosing.

Obvious first step is to enable IPv6. It is easy enough to do. Under Administration -> Management find IPv6 support and enable IPv6 and Radvd. Radvd is configured as simple as it can be:

interface br0
{
   AdvSendAdvert on;
   prefix 2001:db8:9:10ee::/64
   {
   };
};

Notice that prefix is same text “Routed /64″ under your tunnel details.

Unfortunately this will not do. There is need for small script:

insmod ipv6

SERVER_IPV4_ADDRESS="216.66.22.2"
SERVER_IPV6_ADDRESS="2001:db8:8:10ee::1"
CLIENT_IPV4_ADDRESS=$(ip -4 addr show dev eth0 | awk '/inet / {print $2}' | cut -d/ -f1)
CLIENT_IPV6_ADDRESS="2001:db8:8:10ee::2"
ROUTED_IPV6_ADDRESS="2001:db8:9:10ee::1"

if [ -n $CLIENT_IPV4_ADDRESS ]
then
    ip tunnel add he-ipv6 mode sit remote $SERVER_IPV4_ADDRESS local $CLIENT_IPV4_ADDRESS ttl 255
    ip link set he-ipv6 up
    ip addr add $CLIENT_IPV6_ADDRESS/64 dev he-ipv6
    ip route add ::/0 dev he-ipv6
    ip -6 addr add $ROUTED_IPV6_ADDRESS/64 dev br0
    kill $(ps | awk '/radvd / { print $1}')
    radvd -C /tmp/radvd.conf
    wget "http://ipv4.tunnelbroker.net/ipv4_end.php?ip=AUTO&pass=9fc4d3d26b6ba921226c53e6c664c1ab0&apikey=tb4f139f1c342fgbd4.44123289860&tid=5511235463"
fi

Script sets some variables, brings interface up, adds some routes and restarts radvd daemon in order to pickup latest settings. Last line is needed only for users with dynamic IP (full explanation can be got once you load page in browser). This script needs to be saved with Save Firewall (under Administration -> Commands).

Once router gets restarted you will notice that all clients get IPv6 address alongside IPv4 (they have to support IPv6, of course). Easiest way to check it to run ping -6 ipv6.google.com. Or load it or one of many IPv6 test pages.

Windows 7 works just beautifully with IPv6.

P.S. In case you are wondering where I pulled those IPv6 addresses from, here is what Hurricane Electric gave me:

IPv6 Tunnel Endpoints
    Server IPv4 Address: 216.66.22.2
    Server IPv6 Address: 2001:db8:8:10ee::1/64
    Client IPv4 Address: 174.78.144.123
    Client IPv6 Address: 2001:db8:8:10ee::2/64

Routed IPv6 Prefixes
    Routed /64:          2001:db8:9:10ee::/64

Well, since my Internet provider does not give a **** about IPv6 first step is to get a tunnel. And there are quite a few IPv6 tunnel providers. In my case I decided to go with SixXS since they have support for both Windows 7 and (via black magic) my DD-WRT router. For Windows 7 you do need to have their AICCU client installed (and probably OpenVPN). Slight nuisance but bearable.

Once my account was ready (it took them less than a day) I created an Dynamic NAT-traversing IPv4 Endpoint using AYIYA (now repeat this really fast). All eager I awaited for confirmation. Instead of it I got “SixXS has discussed your request regarding a tunnel but have decided not to approve this request”. Nothing in mail pointed to what I did wrong. My guess was that they noticed I am trying to use Ashburn, VA (where I currently live) with my Croatian address (where I usually live). I elaborated my situation and waited for response. And waited. And waited. No response (10 days and counting).

Thus I decided to see what other brokers are out there and I found one that would work for me – Hurricane Electric. They give you up to five /64 tunnels and upon that you can additionally request /48 prefix. Their tunnel endpoints are not that numerous but I think that they offer satisfactory range.

But that is not the best thing. After reading guides for setting up SixXS I was pleasantly surprised that my configuration consisted of 4 lines:

netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel 192.168.1.2  10.20.30.40
netsh interface ipv6 add address    IP6Tunnel 2001:db8::1:0:0:2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:db8::1:0:0:1

And you do not need to remember those 4 lines since they will be generated automatically for you and available on Tunnel Details page. Just take care to fill first IP correctly (192.168.1.2 in this example) No additional software, no new drivers – Simplicity at it’s best.

So far I think I am convert. While SixSX has a little bit better support for dynamic IPs, things are not too bleak for Hurricane. And keep in mind that Hurricane does tunneling over protocol 41 so there is need for your network to support this (almost each one does).

In short, I would say that Hurricane Electric is much better choice if you have normal provider who does not block any traffic. In any case, I am IPv6 (and so can you). :)

For upcoming Windows 8 beta we shall get Resilient File System (ReFS for friends). Features are making my head spin:

• Compatible with NTFS application layer.
• Data is verified and auto-corrected.
• Live data recovery (bye, bye offline mode).
• Transactional model.

From design point of view it looks more like unholy combination of relational database and version control than a file system (that sounds familiar). As I read I decided that it will be my new system to install Windows 8 on. And then I noticed two deal breakers: It will be available only on Windows Server 8 and you will not be able to boot of it.

At first this file system is intended for Windows Server 8 volumes only. You will boot good old NTFS and then store all your data on ReFS. And forget per-file encryption since EFS is not supported. Well, at least there is BitLocker.

My developer life is more aligned with Windows client OS than server so I will skip it for now. I just hope that ReFS will not stay limited to server but that it will find it’s way into consumer’s life also. And, Microsoft, don’t forget booting…

If you happen to use Windows Thin PC than just remember to install .NET Framework 4.0 before VHD Attach and you should be just fine.