I’m currently porting a Linux C++ pricing library and agent to Win32 – the goal is to grid enable it and deploy it on a DataSynapse. Now this is a very large project with many hundreds of headers and libs. Understanding the make dependencies and seeing how it would be possible to decompose the code to be grid friendly is complex to say the least.

Simply trying to build the project on Visual Studio, MinGW or CygWin is not enough to see what is missing. The build only shows you what the next few headers and libs are missing and you need to look deep into the dependancy graph and not worry about what builds and what doesn’t.

 IncludeManager from Profactor is a saviour when you need to do this. It’s targeted more at the ‘what will rebuild if I change this file’ use, but I find it very useful for gaining a clearer picture of complex dependancies. It’s easy to collapse the graph to reduce dependancy noise.

And it’s very cheap!

Advertisements

Sometimes you just have no choice. You have resort to some hack in order to make your code work. I recently had to write a GUI client to provide some specialist admin tasks on DataSynapse GridServer v2.6. For various reasons this had to be a C# .NET GUI and DataSynapse thoughtfully provide a .NET API which made the coding tasks pretty straightforward. Everything worked beautifully except when the GUI closes and the App Domain doesn’t unload. Consequently the .exe and vshost.exe just hang around like ghostly processes.

Some investigation revealed that whenever any of the DataSynapse admin .NET API methods are called there’s a sleep, wait or join that never exits.

[In a sleep, wait, or join]
mscorlib.dll!System.Threading.Monitor.Wait(object obj, int millisecondsTimeout, bool exitContext) + 0x14 bytes

It turns out this is a known bug that I’m sure will be fixed at some stage. However, that didn’t really help me. Despite some failed attempts to terminate the thread, I resorted to some rug pulling. The code now uses my old Suppuku class to make sure everything terminates.

static void Main()
{
      Application.SetCompatibleTextRenderingDefault(false);
      new ShellApplication().Run();
      Suppuku.Sword.Commit(0);
}

And here’s the brutal implementation.

namespace Suppuku
{
      public class Sword
      {
            [DllImport("Kernel32.dll")]
            private static extern bool TerminateProcess(int handle, int exitCode);
            public static void Commit(int exitCode)
            {
                  TerminateProcess(-1, exitCode);
            }
      }
}

Sometimes needs must and Win32 comes to the rescue.  Any other solutions gratefully excepted.