By an interesting coincidence I happened to be searching for a few new C++ blogs to follow and I also happened to have just updated this entry about Stan Lippman’s VC6 rant (since I found a link to the original posting which had been deleted before I could comment on it back in 2005…). Anyway, back to the point, The Lone Coder asks “Why oh why do people insist on using compilers that are way out of date?

The Server Framework uses reference counted data buffers and socket objects. These are passed around as part of the asynchronous I/O system in the framework and as they’re placed in queues or passed from one thread to another their reference counts are adjusted so that they are automatically cleaned up when they’re finished with; but not before. If you’re writing a server or client using The Server Framework then you may need to manipulate these reference counts yourself; as with all reference counted objects, there are two simple rules: If you need to hold on to a reference to an object than call AddRef() on it; when you’re done with your reference call Release().

I’m currently looking at the Excel 2010 XLL SDK which is part of the Office 2010 Technical Preview. I’ve already built and tested my managed XLL system with Excel 2010 on x86 but I needed the new XLL SDK to be able to build for the x64 version of Excel. The SDK doesn’t ship as part of the main Office 2010 installation, you have to ask for it. So far things look reasonably good in x86 mode.

A customer of mine has been having some problems with communication between a UDP server and their load test client. The UDP server implements the ENet protocol which provides for reliable data transfer over UDP. Their problem was manifesting as the client not getting some ENet level ACKs for some reliable data. The Wireshark log from the client machine showed the client resending the data when the ENet retransmission timeout expired and also showed that the ACKs for these packets never arrived.

Back in October 2005 some of my clients started to complain that the latest version of the Platform SDK (the April 2005 version) broke their builds. The culprit was uuid.lib which had been built with debugging information that the VC6 linker didn’t understand and which caused a link failure. The end result was that the last version of the Platform SDK that worked with VC6 was the February 2003 version. This all seemed quite unnecessary to me at the time; as if the latest Platform SDK was deliberately unusable for VC6 which had (in September 2005) just become unsupported.

Previously published This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here. As I mentioned back in April after I’d put together my first prototype leg, “the prototype leg has some fairly major failings from a mechanical point of view”. Ideally the real legs will be designed and cut from sheet material, either plastic or metal.

Since I complained about how the Microsoft File Transfer Manager sucked when I was downloading the Windows 7 Beta back in March I thought I should be balanced and point out that last night I kicked off a download of Windows 7 and the x86 and x64 SDKs and this morning they were all present and correct and that I had none of the problems that had plagued me last time.

Previously published This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here. The new functionality in my servo control takes more memory to implement due to the more complex state that we need to maintain for each servo. The simple controller could support up to 64 PWM channels on the ATTiny2313, the more advanced controller can, at the present stage of the design, support around 15.

I’m developing the simple client server protocol code that I’m harvesting in a test driven manner. Although the code exists, as such, and I’m harvesting it rather than inventing it from scratch the harvesting is taking the “best” ideas from several similar implementations to create the version that will form part of the framework’s example code. As such I’m treating this just like a new development and, mostly, writing my tests first.

The simple client/server request/response protocol that I’m currently harvesting uses the concept of an ‘invocation’ to tie a request to a response. An id is generated on the client and placed in the request header. The server simply copies the id from the request header to the response header and the client can then match responses to requests. This works nicely but the implementation has evolved with the protocol. The first version used a 4 byte invocation id, allocated an instance of an invocation data class and stored the allocation address of the object as the invocation id.