For someone who avoids Microsoft whenever possible, it must be an indication of the pervasiveness of stupid stuff in MS code that I usually run into _something_ whenever I look at it.

Today's victim: DHCP.

There's a DHCP manager that runs anywhere, I guess, and talks to the DHCP server over SNMP. I start it, and the fields are all empty. Which server is it talking to? None. It wants me to tell it the address (not name, it's one of those pre-dotted fields) of the server I want to talk to. Well. Everyone else who ever wants anything from a DHCP server finds its address by broadcasting for it. Why on _earth_ doesn't the manager do that too? I mean, which server am I most likely to want to manage??? (It should at least preload a selection of servers obtained in this way. However, the very reason I'm trying to do something to this server is the same reason that you should not find more than one DHCP server in a broadcast domain (well, as long as only one gives out dynamic leases, you could be OK with more than one.))

I eventually give it an address it believes and I want to add a global option, the one for the timezone offset. PST is eight hours behind UTC, and this offset is in seconds. Let's see, 8*60*60, thats 28800, and it's negative since we're behind UTC, so I put that number in the field. The field has a type reminder to the left of it. It says "Long". I stuff the number in there, and it complains that it must be an integer between 0 and 4294967295. Now, where I come from, a Long is signed. I'm handed some MS manual or other where it says among other things that DHCP is RFC-compliant or -adhering or some such language. OK, I'll go to the RFC. RFC1541 details the server but not the options--they're in another one, which I go see. Lo and behold it says right there that the value for that option is a 32-bit signed integer. Looks like a BUG to me.

How do they get away with this stuff? This is NT 4.0 running in vmware on Linux.