Mercurial 1.7, cacerts, and FreeBSD

So with recent Mercurial 1.7 releases HTTPS support was tightened, so you are bound to encounter a warning in the form of: warning: bitbucket.org certificate not verified (check web.cacerts config setting).

Now, on http://mercurial.selenic.com/wiki/CACertificates there are details on what to configure for certain operating systems. Given I use FreeBSD, I altered my $HOME/.hgrc as follows:

[code]
[web]
cacerts = /etc/ssl/cert.pem
[/code]

For OpenBSD this should be in the same place since release 3.8. But apparently NetBSD does not have such a file in base.

Predefined macros

So with the GNU compiler you can use the preprocessor to get a list of the predefined macros:

[code lang="bash"]
$ cpp -dM /dev/null
[/code]

or if you prefer to invoke the preprocessor via gcc itself:

[code lang="bash"]
$ gcc -dM -E - < /dev/null
[/code]

This should give you a list similar like:

[code lang="c"]
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
[/code]

For Microsoft’s Visual C++ compiler I have only found pages like:

For Intel’s C++ compiler I found the following page with predefined macros.

And I find this interesting page with a lot of different compilers and their predefined macros to identify them and their versions, if any.

Edit: I also found how to do this with Clang:

[code lang="bash"]
$ clang -dD -E - < /dev/null
[/code]

Finally a stable connection

As I previously recorded in the posts here and here, my network interface card under Windows 7 started to drop the complete traffic whenever it got stressed out with network traffic. Heck, sometimes not even when stressing it out. Digging through various fora I came to the Nvidia forum again and found a thread that mentioned a Microsoft Knowledge Base article that instructs in turning off receive-side scaling.

After turning said option off and stress testing the link for a few hours I did not experience any drops. So this might actually finally be the stable connection I am looking for.

Upgrading dd-wrt for Windows 7, problems and a possible fix?

As noted in my earlier post I had issues with my network interface card (NIC) dropping my connection whimsically.

So finding some posts about possible firmware issues with Linksys routers and disconnects I proceeded to update my router’s firmware from dd-wrt v23 to v24 pre-sp2. This actually caused me some problems. I followed the information presented in the stickies on the dd-wrt forum, which means that prior to updating the firmware I did the 30/30/30 reset to get the factory defaults going again, then proceeded with uploading the new firmware (v24 pre-sp2 build 13064) and once that was done do the 30/30/30 reset again.

And that’s where 2-2,5 hours of frustrating would kick in. After the router had rebooted I couldn’t ping the default 192.168.1.1 address. I was getting a destination unreachable message. So alarm bells started to ring in my head, thinking I had bricked my router in some way. But the strange thing was that it looked like it rebooted correctly, no strange flashing LEDs, or not being responsive to cables being plugged in and taken out. Of course, with the router down I had no Internet connectivity to do some troubleshooting browsing. But thankfully I could use my Android mobile phone for that. I retried various reset routines but to no avail. Of course I started to despair a bit more, thinking I would have to buy a new router. I then noticed that the WLAN LED was lit up. Since my Android phone supports WiFi I figured I should see if it shows up. ‘Lo and behold, it had a network with the SSID ‘dd-wrt’ and sure enough, I could connect to it. Next was trying to router’s web interface and that worked too! Of course that enthusiasm was quickly dampened when I discovered that you cannot do a firmware upgrade over the wireless link. I also couldn’t find any way online on how to override this precautionary lockout, so it was back to square one.

And then I stumbled over a post which mentioned that Linksys routers with the original firmware sometimes have their wired LAN ports revert to 10 Mbit/half-duplex settings. After picking up my jaw from the floor I wondered if it could be so easy. Sure enough, after changing the settings for my NIC in the configuration window, I could ping 192.168.1.1 and load up the administration interface in my browser.

Then I tried my World of Warcraft (WoW) patch download again (which is essentially a BitTorrent client) and stream Bohemian Rhapsody by the Muppets at HD quality from YouTube only to have my NIC go silent on me again. So, after the few hours of futzing with the router and its upgrade I was no closer to a proper solution. Although I did conclude it was, in fact, the Windows 7 box acting up since my WiFi connection as well as the Unix box on another LAN port could still use the network as it should.

Then the morning after I was looking around several Google results again and came to a post on the Windows7Forums.com website where someone had troubles with a wireless connection from Windows 7. I use a wired connection, so aside from the symptoms it’s not quite similar. It then documents the ‘roll back driver’ solution, which I had previously tried. But it became interesting when I found Sage’s post at the bottom which reads:

“I think I’ve found the solution to this problem. It was revealed recently (A week or two ago) that there is a bug in the NVIDIA chipsets when using 64-bit addressing. This ends up affecting a whole host of things on machines, including this nefarious “Random internet disconnect” problem. I posted this solution over at a couple other W7 forums and others with NVIDIA chipsets and 64-bit machines have all found it to succeed in fixing this frustrating issue.

What it more or less comes down to is applying this hotfix: You encounter problems when you move data over USB from a Windows 7 or Windows Server 2008 R2-based computer that has an NVIDIA USB EHCI chipset and at least 4GB of RAM

Ignore the fact that it mentions this fix to be solely for USB hardware issues. It is a fix for the NVIDIA chipset on 64-bit Windows 7 and has been practically a miracle fix for people with the USB harddrive disconnect problem, the random internet drop problem, and the internet-disconnect-on-wake-from-sleep problems that have all been plaguing Windows 7 64-Bit users since the RC.”

Funnily enough my Windows 7 is 64-bits and I also have an NVIDIA nForce chipset. Looking at the hotfix page shows it really is only updated USB driver files. Figuring it cannot possibly be worse than my situation now I installed the hotfix are being emailed the location to download it from. A reboot later I was downloading my WoW patch with the downloader while streaming the Muppets again and haven’t seen it drop dead yet. So initial tests show it might very well be the solution, but I need to stress test it some more.

Windows 7 and the case of the dropped network traffic

So the good news of Windows 7 is that they removed the TCP half-open limits.

The bad news is that quite a fair number of people have problems with their network interface card (NIC) dropping dead on them as soon as they push their system to sustained high throughput, think of leeching newsgroups, using torrents, but also downloading ISOs (BSD or Linux releases) or even watching YouTube clips and downloading a driver.

The suggested ‘fixes’ have been ranging from absurd to interesting.

Things I have done so far:

  • rolled back the driver from NVIDIA to Microsoft’s stock driver, did NOT help
  • disabled power management features, did NOT help
  • disabled autotuninglevel (netsh int tcp set global autotuninglevel=disabled), still in testing

Things to try still:

  • disable all Quality of Service (QoS) stuff
  • disable all offloading (netsh int ip set global taskoffload=disabled)
  • disable Gigabit related features

Windows 7 and the Windows Audio Service

Strange thing, after logging in my Windows 7 task tray suddenly showed my volume icon as a red cross and hovering over it said that the “Audio Service is not running”. Looking at the services by means of services.msc shows that my Creative Audio Service and Windows Audio Service are both running. Restarting the Windows Audio Service and Creative Audio Service fixed the display issue. Apparently just changing the volume ought to fix the display of the icon as well.

Office 2010 Chinese language pack font list

It looks like the Chinese Office 2010 font list is the following (Changzhou SinoType, Founder, Microsoft, Stone):

  • FZShuTi
  • FZYaoTi
  • LiSu
  • Microsoft YaHei
  • Microsoft YaHei Bold
  • STCaiyun
  • STFangsong
  • STHupo
  • STKaiti
  • STLiti
  • STSong
  • STXihei
  • STXingkai
  • STXinwei
  • STZhongsong
  • YouYuan

From the language pack make sure to select 国际字体 (international fonts) and 校对工具 (proofing tools). Under 国际字体 we have 典型字体 (typical fonts) and under 校对工具 we have 简体中文校对工具 (Simplified Chinese proofing tools) and 英语校对工具 (English proofing tools).

Office 2010 Japanese language pack font list

It looks like the Japanese Office 2010 font list is the following (all by RICOH):

  • HGGothicE
  • HGGothicM Medium
  • HGGyoshotai Medium
  • HGKyokashotai Medium
  • HGMaruGothicMPRO
  • HGMinchoB Bold
  • HGMinchoE
  • HGPGothicE
  • HGPGothicM Medium
  • HGPGyoshotai Medium
  • HGPKyokashotai Medium
  • HGPMinchoB Bold
  • HGPMinchoE
  • HGPSoeiKakugothicUB
  • HGPSoeiKakupoptai
  • HGPSoeiPresence EB Extra-Bold
  • HGSeikaishotaiPRO
  • HGSGothicE
  • HGSGothicM Medium
  • HGSGyoshotai Medium
  • HGSKyokashotai Medium
  • HGSMinchoB Bold
  • HGSMinchoE
  • HGSoeiKakugothicUB
  • HGSoeiKakupoptai
  • HGSoeiPresenceE Extra-Bold
  • HGSSoeiKakugothicUB
  • HGSSoeiKakupoptai
  • HGSSoeiPresence EB Extra-Bold