I’ve been working on a library that works in a similar way to our SChannel code and allows the use of the Microsoft “Negotiate” Security Support Provider Interface (SSPI) to provide NTLM and Kerberos support (see SPNEGO for more details). Things are going well and, in general, using Negotiate or NTLM or Kerberos is easier than using SChannel and the structure that was originally born to work with OpenSSL and then adapted for SChannel works well with the new security providers.
As of the next release of The Server Framework use of catch(...) handlers at thread boundaries, in ’no throw’ functions and in destructors will be configurable.
At present, in v6.0 and earlier of The Server Framework, we use catch(...) judiciously at thread boundaries in functions that are either marked as ’no throw’ (with throw()) or which are ‘implicitly no throw’ and in some destructors. Generally these handlers let the user of the framework know about the unexpected exception via a callback.
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.
This is rather nice; Chiara Robot from Carnegie Mellon University’s Tekkotsu lab (via HackedGadgets.com).
Back in October 2007 I briefly looked at, what seemed to be at the time, a simple change to The Server Framework so that you had the option to use buffers that were aligned to page boundaries. This could help you scale better as one of the two problems with scalability at the time was the ‘I/O page lock limit’; there’s a finite limit to the number of memory pages that can be locked at one time and in some circumstances data in transit via sockets is locked in memory whilst it is sent.
I’ve had a couple of requests from clients recently that they be able to handle any structured exceptions in The Server Framework themselves. Up until now all framework threads install a SEH translator and catch the resulting C++ exceptions in their outer catch handlers and report the error to the framework user via various mechanisms. This generally works well and, prevents exceptions going unreported but sometimes users want to integrate the framework with code that deals with uncaught structured exceptions in other ways.
Here’s a nice piece by Rico Mariani about why Visual Studio is unlikely to go 64 bit any time soon. In a nut shell, unless you have very large data sets that need to be kept in memory you might be worse off as a 64 bit process than you are as a 32 bit process on a 64 bit operating system. Food for thought.
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.
Here are some links that may help once I move onto fabricating the various pieces required to build the hexapod’s body.
This is a simple 4 legged walking robot that was machined from an A4 piece of 4mm ply wood.
I’m currently working on a new version of the Windows Services library that ships as part of the licensed I/O Completion Port Server Framework. The Services library allows you to turn your server into a Windows Service very easily and also allows you to run it as a normal executable inside the debugger, etc. It integrates nicely with our Performance Monitoring library for exposing perfmon counters and comes with several example servers that show you how to use it (see here and here).
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.
A collection of links that I’ve been using recently for research.
Servos and robotics Hitec HS-422 Servo. The servos I currently have; likely not suitable for use as actual leg servos due to lack of torque. Useful link as www.
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.
In my opinion there’s a fundamental design flaw in the both the 8 channel and the 64 channel servo controller firmware that I’ve presented. Both allow the serial data handling code to take priority over the PWM generation code.
