Software, Technology, Business & Life

Symptoms: Windows machine with two network interfaces (NIC), 10.x.x.x and 192.168.x.x. I send a UDP broadcast message (to destination address 255.255.255.255), and see the same message go out on both networks. The problem is, the source address that goes out with each packet is the IP address for my first network interface, so it’s sending an unreachable address out my second network. Responding devices start doing ARP requests to try (in vain) to find that unreachable address instead of responding. (Watch it with WireShark.)

Cause: 255.255.255.255 is too general. TangentSoft has the general solution. I craft the broadcast address more carefully, and it works.

	10.x.x.x (subnet 255.0.0.0) => 10.255.255.255
	192.168.1.x (subnet 255.255.255.0) => 192.168.1.255

It’s not the language or library. It’s seen for C#, C, and C++, etc, on Windows Vista, and here.

The broadcast address 255.255.255.255 is also known as INADDR_BROADCAST or ‘‘ in Python.

You only need one socket, which you can bind to all interfaces.

Enumerating your network interfaces requires some work: find it under Win32_NetworkAdapterConfiguration, fields IPAddress and IPSubnet. Those fields are arrays: you want element zero.

If you’re using python, you need the WMI package, which is built on the PyWin32 package.

import wmi
nicsList = wmi.WMI().Win32_NetworkAdapterConfiguration() # your network adapters

If you’re getting WinSock error 10013, you need to set SO_BROADCAST.

Hope that starts you down the right path.

Also, if your devices aren’t configured for the same subnet, crafting a sub-net-specific broadcast message means you’re not going to find them. For example, if you have a 10.x.x.x device off your 192.168.x.x interface, it’s going to ignore your 192.168.255.255 broadcast. You’ll have to fall back to disabling a network interface and using 255.255.255.255 to get to it.

Tiobe’s 2009 Programming Language Survey is an interesting read. I write in a variety of languages: as it turns out, seven of the top eight.

Very interesting that C seems to be such a constant. And far more constant even than its second place suggests, since six of the top eight languages use a syntax based on it (Java, PHP, C++, C#, and JavaScript), not to mention Objective-C. C is the bedrock.

Objective-C seems to be coming on crazy strong. It has been around forever, but Apple’s interest is giving it a boost. Apple’s interest alone, though, will only get it so far.

Java and C# are here to stay, and for good reason. They’re strongly typed, object oriented, have great libraries and manage some of the hard stuff for you.

C++, my language of choice, seems to be slipping. I’m not concerned. I’m convinced that the C++ compiler is the most powerful software development tool ever. When managing complexity and maximizing performance are crucial, C++ is it.

I’m glad Python is doing well. It’s a great scripting language with a great set of libraries. I think it’s overcoming Perl’s passionate and loyal following. (I admit: one of my career goals is avoiding learning Perl. And I think I just might make it.)

JavaScript is crucial to know, too: every browser runs it. It’s as ubiquitous as the web.

For the record, my proficiencies, in my best-guess order: C++, C, Java, C#, Python, JavaScript, Visual Basic.

PS: The TIOBE Index isn’t to be taken as gospel.

Here’s an interesting read: the Scrum development framework.

Methodology, strategy and work-flow all rolled into one rather informal process. Not specifically for software projects, either.

Here’s a great discussion of data-oriented design from some gamer programmers: Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)

I believe OOP is the very best way to manage complexity, but isn’t the end-all be-all. It must build on structured programming techniques. That’s not a given.

Further, memory organization may make a big difference as well, depending on the application. Even with modern processors and gigabytes of RAM. I recently encountered an application that needed its memory footprint to be reworked. It brought the very-powerful machine on which it ran to its knees by using memory very inefficiently.

Though I don’t have much desire to build games, I appreciate the game-development community. They build incredibly ambitious pieces of software: ambitious in both complexity and performance. That causes them to encounter many issues one might not consider, and think hard about everything they do.

Update: Here’s a very detailed article on memory usage from the bare metal up: What Every Programmer Should Know About Memory, by Ulrich Drepper. Hat-tip Dan DeMaggio. If your performance concerns reach all the way to RAM access and CPU caches, this is one to study. It’s a whole course, and not a light read. One take-away: memory usage patterns can have very non-linear effects on performance.

OpenSSL is a particularly difficult one to build on MinGW, and it’s not clear even what approach will work. But I got it to build.

My MinGW/MSYS configuration is with the full suite of tools, including bash. (Follow these FFmpeg build instructions for setup.)

As well, I’m using GCC 4.3.3, from the TDM recent builds (http://www.tdragon.net/recentgcc/) setup.

I’m building OpenSSL 0.9.8k.

You need ActivePerl. MinGW has a /bin/perl, but it’s not up to the task. See OpenSSL’s INSTALL.WIN32 file for details.

From a Win32 command prompt (not bash), set up the your paths:

• First in the path: ActivePerl’s bin directory.
• Then MinGW’s paths (before Win32 native).

Fix the file e_os2.h, per BUG 1685. Remove the “static” modifier in the OPENSSL_IMPLEMENT_GLOBAL macro. (Note that it’s a 3-line macro.) This gets you by the “crypto/des/set_key.c line 72″ compile error.

Run ms\mingw32.bat. It will fail with “/bin/sh: copy: command not found”.

Now, edit the file ms\mingw32a.mak. This gets generated by every run of the ms\mingw32.bat file. Search for “exist” and you’ll see two DOSish commands:

if exist $(O_CRYPTO) ] $(RM) $(O_CRYPTO)

Change each to its bash equivalent:

if [ -e $(O_CRYPTO) ]; then $(RM) $(O_CRYPTO); fi

Finally, run the make, and specify the MinGW copy command:

make -f ms/mingw32a.mak “CP=cp”

The output files are in the ‘out’ subdirectory. Intermediate files are in ‘tmp’.

Include files are in ‘outinc’: the include/openssl directory has zero-byte place-holders for each file.

Make’s “clean” and “test” targets are broken. To clean, remove tmp and out. To test, run the various test programs in the ‘out’ directory.

All tests pass.

If you get missing symbols like DeleteDC and send when linking against libcrypto, you’ll need to include some win32 libraries. This typically does it:

make LIBS=”-lgdi32 -lws2_32″

If Yogi Berra thought about software and testing, maybe he’d say:

Unless you know it’s right, you don’t know it’s right.

To ponder…

A very interesting question–with very interesting answers–on StackOverflow.com:

What’s your most controversial programming opinion?

(Via Gadgetopia.)

Step away from the computer.

I get some of my best ideas when I step away from the computer for a few hours and carry on with life (letting the problem mull over in the back of my mind). Maybe you’ve experienced this, too.

If software is much more about good ideas than BFI (and I’m convinced that it is), then stepping away from the computer is a wonderful thing all around.

Now that screens are wide, I find vertical space more precious. So I put my XP task bar on the left side of the screen.

It’s interesting how many programs now come up underneath it. Commercial packages with large user bases. I’m sure they mind the task bar when it’s at the bottom of the screen, but not here.

While it’s not a big deal (to me at least–just a tiny annoyance), it shows how we make implicit assumptions about our world. Sometimes those assumptions are fine. Sometimes not.

I’ve made plenty myself.

Also, I’ve not encountered a program that refuses to run or throws itself off the top or bottom of the screen because of this. That’s a possibility. (I need to keep this in mind if I find a program behaving badly with its screen position.)

Twice in the last three weeks I’ve had software I’m developing crash badly before main() even gets control. Though completely separate situations, each had to do with a third-party package.

Fortunately we were able to work through each in reasonably short order, still using the package without the problem.

One was a proprietary package, and the vendor was willing (and able) to work with us. I wound up iterating to the problem’s source: an issue between Microsoft’s managed and non-managed C++. When this package included Microsoft’s ATLComTime.h, my managed C++/CLI app wouldn’t start. Otherwise it would. (Visual Studio’s “Use of ATL” and “Minimize CRT Use in ATL” had no effect.) We worked around it.

The other package was boost’s serialization. Using the same templated serialize() function in two different compilation modules under CygWin would cause a SIGSEGV on startup. Gdb showed the problem to be in

boost::serialization::extended_type_info::extended_type_info ()

The production environment (FreeBSD) worked fine, but the convenience of CygWin drove me to look for a solution. Here it is:

BOOST_CLASS_TYPE_INFO(MyClass, extended_type_info_no_rtti<MyClass>)

This solution should work on all platforms.

Very disconcerting when something crashes even before main() starts, and more so when it’s a third-party package. Common components are necessary and worth this trouble, but I expect more of it as time marches on.