SimpleCV install and "You need the python image library to save by filehandle"

You'll maybe complain that this site is degenerating into a mingle-mangle of bug descriptions, but if you've ever had a pesky problem and couldn't find anything about it on the web, you'll understand my urge to document such things for the fellow hackers.

Here the story goes: SimpleCV is a Python framework trying to provide a simple interface to both OpenCV* an PIL**. There's even a small book about it. I first  installed version 1.2 on my computer, but then wanted to upgrade to 1.3 as there were some segmentation algorithms added (graph-cut etc.) which I wanted to use. Unfortunately, as I installed the new SimpleCV 1.3 and then tried to run my script written for version 1.2 I got:

WARNING: You need the python image library to save by filehandle

when I tried to display any image. Deinstallation of both versions an clean install followed, but nothing changed. Googling for solution didn't help either. What should we do? Just fix it by yourself! The solution is simple. Well, just open this file:

C:\Python27\Lib\site-packages\SimpleCV\base.py

and change the following line***:

  from Image.GifImagePlugin import getheader, getdata

into:

  from GifImagePlugin import getheader, getdata

So, that's it! And happy OpenCV hacking!


PS: PIL seems to be generally a difficult library to use on Windows. If you follow their own docs an write something like

  from PIL import Image

it won't work! You have to use the little bit confusing:

  import Image

--
* OpenCV: a C++ library containing image processing algorithms. For Python there are wrappers exposing direct calls to it, but they aren't that easy to be used directly.

** PIL: the "python image library " from the warning message - the best know imaging library for Python, however it isn't self-contained. You'll need several other libraries like sciPy etc.

*** somehow for Windows distribution the GifImagePlugin isn't a subpackage of Image, and the PIL package just isn't there to be used as prefix! Despite the warning, the problem isn't lack of the PIL installation, but failure to find one of it's subpackages.

Disclaimer

I just had a cursory look on a couple of my latest posts and I was horrified! So many spelling and grammatical errors in there! But then again, I remembered that I've already spotted some of them before but didn't have the courage to correct them.

Courage? Did you really mean courage? Well yes. I'm sorry to say that, but Blogger is rather a difficult platform to be working with (to put it very mildly) and I didn't want to risk losing of all my formatting just because I'd like to correct some spelling.

So let's make an agreement: I won't touch the old posts (sorry...) but the new ones will be seriously proofread and not just jotted down and published in the spur of the moment. Promised!

GetWindowText() and IsEmpty() doesn't work on Windows 7 ?!?!

Normally, when someone comes to you and blames some bugs on compiler, or even worse, on the computer, you'd only smile mildly and give him some of the age-old programming wisdom. I said normally. Because today I tried to debug some Windows code ported from VisualStudio 2005 to VisualStudio 2010, and stumbled upon two impossible-to-think-of bugs.  And as googling didn't bring ther right results immediatelly, I will document it here for myself an others. Let's pray Google indexes it* for the sake of all the poor programmers forced to work on Windows!

As a matter of fact, I've seen a similiar problem when initially porting the code, but it was only one reptitive  bug, so I forgot about it. Here a code snippet as illustration:

  // bug VisStudio 2010: "LPCSTR comparison not working in 64 bit OS"
  // - workaround: use CString
  //int iSelSysPath = LBCBFindStringExact(*this, IDC_CB_SYSTEMPATH, 0, TRUE, m_ActSubrange.cSystemPath);
  CString sysPath(m_ActSubrange.cSystemPath);
  int iSelSysPath = LBCBFindStringExact(*this, IDC_CB_SYSTEMPATH, 0, TRUE, sysPath);

Ok, that may happen, I'm not particuralry picky on such errors. But today, there were two more bugs I didn't catch initially. One ratehr simple, so I only cite it here for reference reasons:

  // bug Windows 7!!!
  //m_cbSysPath.GetWindowText(m_pBMMSett->Station[m_iStation].Subrange.cSystemPath, 
  // ARRAY_SIZE (m_pBMMSett->Station[m_iStation].Subrange.cSystemPath));
  //m_strPath = m_pBMMSett->Station[m_iStation].Subrange.cSystemPath; 
  CString tmp;
  ::LB_CB_GetLBText(m_cbSysPath.m_hWnd, LB_CB_GetCurSel(m_cbSysPath.m_hWnd, true), tmp.GetBuffer(), true);
  m_strPath = tmp;

As you can see, you cannot read the contents of a combo box! Its filled, but you continue to get an empty striong over and over again! Fortunately, like the bug above, this is a known issue, and my collague told me that that GetWindowsText() fails when the addres of the target isn't even-valued. Well, somehow creepy, but if that's a known issue, then what the fuss...

The next bug however wasn't that simple to fix. In fact we stared some 15 minutes at a piece of code where the IsEmpty() method of the MFC's (notorious) CString class reported true for an obviously non empty string! How can things get that wrong? The reason was found after some googling (though some deeper and harder debgging would solve it too), here's the relevant post:

I wonder if your getting a referencing problem.  CString attempts to not create new values if it thinks it can use the same one for multiple occurrences.  I've been caught by this before.  I usually force the issue by using the LPCTSTR operator like:

CString cs = (LPCTSTR) csValue;

Might be worth a try anyway.
Tom  

And he (i.e. Tom) was right, because the following change forced a copy and in result fixed the problem:

 
  //bool empty = m_aStrSettPath.IsEmpty(); <-- not working! internal CString cache issues
  CString p = (LPCTSTR)m_aStrSettPath[i];  
  bool empty = p.IsEmpty()  

But now hold on! The basic operation on strings is broken? Can it get any worse? If you can -stay away from MFC, if you cannot - wel,l I hope you'll be abble to google this post.

---
* an that's the reason for the grammatical error in the title of this post

Coding Styles Again, or Getting LISPy?

Although in my previous post I argued that coding styles and formatting are only smoke and mirrors, latetly I found myself increasingly entangled in a dilemma concerning just that question. Namely, I suddenly found pleasure in writing my C++ statements using expressions rather than direct flow control constructs.
Want an expample? Here it is:

  // housekeeping
  (type == QAmmMeasModel::MeasChannelNode) 
    ? removeItemRef(m_measDefEntries, m_measDefFilesSz, defFileName, defFileIndex)
    : removeItemRef(m_rangeDefEntries, m_rangeDefFilesSz, defFileName, defFileIndex);

instead of the more mundane (or, if you want, normal):

  if(type == QAmmMeasModel::MeasChannelNode) 
  {
    //........
  }
  else
  {
    //........
  }

As such, it is rather to be seen as an innocent idiosyncracy of mine, but it didn't stopped there, culminating in the following substituton. Instead of the rather boring:

 // houskeeping
 if(type == QAmmMeasModel::MeasChannelNode) 
 {
   assert(m_measDefEntries.contains(key));
   assert(m_measDefFiles.contains(defFileName));

   m_measDefEntries.remove(key);
   
   if(m_measDefFiles[defFileName] == 1)
     m_measDefFiles.remove(defFileName);
   else 
     m_measDefFiles[defFileName]--;
 }
 else
 {
   assert(m_rangeDefEntries.contains(key));
   assert(m_rangeDefFiles.contains(defFileName));

   m_rangeDefEntries.remove(key);
  
   if(m_rangeDefFiles[defFileName] == 1)
     m_rangeDefFiles.remove(defFileName);
   else 
    m_rangeDefFiles[defFileName]--;
 }

I came to consider using something more funky, like:

 // lispy?
 (type == QAmmMeasModel::MeasChannelNode) ?
  (m_measDefEntries.remove(key),   
     ((m_measDefFiles[defFileName] == 1) ? 
      m_measDefFiles.remove(defFileName) : m_measDefFiles[defFileName]--)) :
  (m_rangeDefEntries.remove(key),   
     ((m_rangeDefFiles[defFileName] == 1) ? 
      m_rangeDefFiles.remove(defFileName) : m_rangeDefFiles[defFileName]--));

You must admit that the second version is more succint, looks better and transmits some indefinite "guru" feeling. Unfortunately I had to let the asserts go, but it didn't occur to me as a great loss. So why did I delete the second version in the end? Simple. It was written for my client, and should be readable to all C++ programmers. In that way coolness was sacrificed on the altar of mediocrity ;) for the filthy lucre's sake ;).

Later in the day I chose the simpler solution and just wrote the removeItemRef() function hiding the ugly if() clause, but if I didn't do it, what do you think, which of the two versions should I had included in the code?

Static vs Dynamic - the LISP experiences

Maybe you happen to remember my recent post about static and dynamic languages with the main assertion that the type information is maybe superfluous but helpful for documentation and refactoring. You might be tempted to retort: docs & refactoring are for sissies, you wimp! But wait a moment, who are the most notorious hackers out there? You are right, the LISP hackers. From them you'd expect the most ruthless hacks and also despising of the programming aids mere mortals are using. At least as far as the programming folklore is concerned.

But if you a little bit look closer... Heres the answer* given to a simple question "What you dislike the most about Lisp?":

I must say that the lack of static typing really gets in the way on larger projects. Being able to confidently change datatypes and function signatures, knowing that the compiler will point out most inconsistencies that you introduce, is something that I've really come to appreciate after working with Rust and Haskell. Test coverage helps, of course, but I'm not a very diligent test writer, and tend to feel that type signatures are easier to maintain than an exhaustive test suite.

Surprise, surprise, basically he's reiterating my simple argument: why should we give up something that can help us, i.e. automatic checking if all the interfaces are used correctly?

And for the seconds, some  "opinion as a result of ... programming in Lisp in a production environment on non-trivial code"**:

Right off, I can say that the biggest, most glaring thing that causes problems is the lack of static typing. It happens that when the compiler is unable to detect these issues, the end user is left to find them. This can be very potentially damaging to companies. And it is more prominent when you have 100k lines of code, not all of which one can be familiar with.

Lisp takes some steps to help solve these issues. SBCL has very good type inference capabilities, and can warn or error at compile time with type issues. Additionally, Common Lisp allows one to declare and assert argument types, but there’s no guarantee this information can be used. 

And what's SBCL? Let's cite from it's homepage: "Steel Bank Common Lisp (SBCL) is a high performance Common Lisp compiler". What? Even more surprises! Compilers, type inference, assertions? Ok, looks like (at least some of) the LISP hackers came to appreciate the static typing. Who would have thought it?

---
* Lisp Hackers: Marijn Haverbeke - http://lisp-univ-etc.blogspot.de/2012/04/lisp-hackers-marijn-haverbeke.html
** The Perils of Lisp in Production - http://symbo1ics.com/blog/?p=1321

C++ Annotations not so pointless? Plus some UMTS history.

Let me start this post with a retrospection: long long time ago I promised to write a blogpost about multithreaded testing, temporal logic and (even) the boundaries of knowledge. Pretty high claims, you'd say, and you'll be of course right, as I didn't write it despite of a few false starts. So though the wholesale treatment of this theme isn't possible now because I plain and simply forgotten much of the details, I'll try to catch the opportunity to pay off my "blogging debt" and use that stuff in a condensed form as intro for this post.

1. Past struggles

So then, long long ago I was writing an multithreading application (or rather a framework* for other programmers to use) under Linux/pthreads against an underspecified multithreading interface of a "General Telco Systems Programming Platform" ;) - let call it GTSPP;). It was underspecified because it was still being developed while we were writing production code to be deployed on backplane UMTS switches.

Well, what can I say, the regular multinational project's madness, alleged synergy, and all that stuff... But, perhaps surprisingly to you, I wanted to have that thing thoroughly tested! And I mean tested! After I found some unexpected behaviour of GTSPP;) and resulting deadlocks, I didn't want to allow it to happen again.

As at that time I was interested in logic, automatic theorem proving and generally in foundational speculations, I had that brilliant (or at least I thought that...) idea - why don't we just describe a multithrerading system in terms of modal logic, like that:

• []T (read: box T) meaning: T alway happens
• <>T (read: diamond T) meaning: T sometimes happens

 and then use automatic derivation do derive some theorems of thatt system? Like "Theorem 1: there will never be a deadlock here".  [In the originally planned post a lot of explanantions about Kripke, possible worlds, Buchi automata... and model checking would follow here... BUT this isn't the planned post, sorry!]

At last some sensible use of maths! Can't believe it, so these whole math classes weren't a total waste of time?

Well, yes and no. As I tried several open source products, none of them was able to read C++ code, annotate it with modal logic, and infer the needed theorems. You call me naive? But that's exactly what SPIN is doing! The only problem was that SPIN doesn't accept C or C++ code, but only it's own description language: Promela. So I had to recode my system in Promela. That was out of the question, as I didn't have so much time. Writing a general translator C++ to Promela translator was beyond question as well - Clang wasn't there yet!

SPIN's author did some interesting work for AT&T on translating C code to SPIN format and even open-sourced it, but as I tried to install it on my Linux machine I failed. Some package dependency was missing, and our sysadmin asserted that there's no no such package for the RedHat distribution... At that point I gave up** thinking: the real boundaries of knowledge are that of human laziness...

2. New hope?

You may remember that I wrote a post "Two C++ curiosities..." where I expressed my inability to grasp the reason for the introduction of attributes in C++ (apart from Microsoft's influence). Recently, the same Microsoft organized a C++ conference  with quite a good video coverage. As I happened to listen to the Clang presentation i noticed some interesting usage of that language feature. It looked roughly like that:

or in gcc's syntax:

Do you see that? Now you can add an attribute to multithreaded code and let the compiler check if it's deadlock and starvation free!

That's what I call a sensible vendor specific extension! Well, it could be, as at the present all this isn't available yet (it's a research project at Microsoft's) but at least now I learned one case where the attributes could do quite a good job!

PS: More information on that topic: the boost::thread and thread safety annotations post or LLVM docs.

--

* I know, programmers hate frameworks, we were hating GTSPP;) too, but we were merging an another telco framework used in the previous project with the hapless GTSPP;) as not to expose the application programmers to too much madness - you know, brains melting, people screaming, teams disintegrating... So it was a Good Thing in the end!

** You don't really think I gave up on this, do you? So what was my solution? Right! I wrote a Python test driver repeating testcases by 1000s and grepping the output for specified error messages. The classic and proven multithreading testing strategy. Maybe a little brute-force and old-fashioned, but you know what? It did the job!

Coding styles.

As I was looking at my mate's C++ code I spotted the following curious lines:

  TreeDataCIterator it  ( m_treeDataList.begin() ), 
                    end ( m_treeDataList.end() );

Don't you think it's rather unusual for C++? Myself would rather writhe something more mundane like:

  TreeDataCIterator it = m_treeDataList.begin(); 
  TreeDataCIterator end = m_treeDataList.end();

complying with some old coding guidelines of the dark ages (aka 90-ties) which were imposed on the unhappy programmers in some big, iternational, waterfall project. But, you know, habit is the second nature... So I was somehow perplexed by the originality of the code, as I'd rather expected more dull style (like mine) considered C++'s strong C-legacy. But then I rememebred that my mate was originally a LISP programmer (but then his LISP-based company didn't really take off) and everything became clear! Look at this snippet uf LISP code from the SICP book:

  (define (count-leaves x)
      (cond ((null? x) 0)
            ((not (pair? x)) 1)
            (else (+ (count-leaves (car x))
                     (count-leaves (cdr x))))))

isn't it similiar? The love of parenthesis cannot be cured of easily ;-).

On the other hand, this could be as well an exmple if the C++ initalization syntax, and in C++11 we could write as well:

  TreeDataCIterator it  { m_treeDataList.begin() }, 
                    end { m_treeDataList.end() };

Not that LISPy at all (instead maybe a little confusing)! But seriously, don't you think arguing about this is a loss of time? Well, not really, good code should be readable, and if we care about our code, it's does matter. But then I find myself increasingly obsessed with code formatting and visual appeal of my code. It's certainly not wrong, but it robs my brain of its preciuos ressources. Remember? Your brain can hold in memory only 6-7 items at the same time, so decreasing mental load is a blessing for it. Not mentioning that formatting and reformatting your code takes time.

And the worst is, that your favourite formatting style at the moment won't be that in the next year. Myself, I was in projects where the coding styles looken at first insane to me! And I arguend and ranted but complied to them for the greater (i.e. project's) good. An guess what, now I'm using elements of these coding styles in my own code! Ok, not everything, but some parts weren't so nutty at all. What does that mean? Yes, you guessed it: coding styles doen't matter at all. But switching between them does!

So why we just don't stop doing this? Why don't let wo the computer do this and concertrate on more important aspects oif code? There are so many of them! As I first read about Go's policy about code formatting I wasn't too enthusiastic about it. But meanwhile I find it a good idea: only one prescribed layout style automatically imposed on your source code! Let's forget about coding standards and concentrate on problem solving!

Static vs Dynamic Debate Decided

As I said, it's decided (at least for me) now!

A couple of years ago it became fashionable to be ecstatic about dynamic (i.e. dynamically typed*, aka scripting) languages, this sentiment is maybe best exposed by Steve Yegge here. People started to talk about "freedom languages", and it all started getting rather emotional. Like in this tweet:

"Strong types are the hobnailed boot of the Enterprise Man on the neck of the Agile Code Poet"  http://goo.gl/aeEcn

It is understandable as an aftershock of the J2EE meltdown by Ruby and Rails, but I was always rather suspicious with that. I was always rather suspicious because of the following gut feeling - why should I throw away things which can possibly help me? If you are skiing, you know that: you were falling and you'll fall, the question is only when (hope not in an icy couloire or over a cliff...). It's the same in programming - you will fall.

1. Theory 

A proof written as a functional program (Wikimedia)

As at that time I was interested in mathematical logic and automatic theorem proving, I happened to know about the Curry-Howard isomorphism. It roughly states that a proof in intuitionistic logic has its equivalent type expression and vice versa - a type is equivalent to some proof.

So if a type system is equivalent to a (constructive!) proof of correctness, that's cannot be bad. We are getting some limited guarantees from the compiler - limited because the type system doesn't describe all of the program's behaviour - and that's one thing less we have to worry about!

Well, OK, maybe that's all theoretical babbling -  who knows if all that logic/foundational thing in mathematics isn't contradiction-free? And even if it's not, it could be not that relevant in practice?

Because when confronted with such a question (i.e. about the correctness guarantees), the standard answer was: "You gotta write more tests!" or "Strong Testing not Strong Typing"** or  "I only proved the correctness of this program, I didn't test it yet" ;). And because tests are a good thing, you cannot deny that this maybe could be true in practice...

2. Own Experiences

So let me share some of my own experiences with dynamic typing.


A couple of years ago, as I read the excellent "Higher Order Perl" book , I got through the first and middle chapters and the code was understandable and clear.

At this point it's maybe appropriate to give the book some praise, as it's well written, and shows an unknown side of Perl - it's functional self. As the title reveals, the book is about functional programming in... Perl! Yes, that's possible, it even seems to match the language rather well. Of course the language wasn't designed for that, and you will miss all the compiler support and type inference of OCaml but then, Perl isn't statically typed, OK? The only fly in the ointment is that Perl has't been fashionable for quite a couple of years yet...

But I'm digressing here, so back to the main theme: at first it wasn't a problem that you don't know the types of the parameters in Perl. It's all convention, you have to retrieve the parameters from the argv and use them according to their type like that:

   my($top, $code) = @_;  # @_ is Perl's argv! 

So all the type information is so to say in the code that uses it later on. But in the last chapter, when the author is developing a linear equation DSL-based drawing system, I sometimes got lost in code. I simply didn't know what the inputs are, and what the function will be doing with it. How I wished I could see the parameter types in the function declarations!

Another example: if you are writing Python code using a library you aren't that accustomed to, and you don't want first to read the documentation for an hour or so, but just quickly code something small you need just now, you'll very likely just to get a bunch of runtime exceptions and have to guess what is exactly going on now. What is the exact type the library is expecting here? I did everything right, didn't I? Nope, you didn't. Please look up the docs.

So AFAIK, the types are for human understanding, even if you don't need the type checking guarantees of the compiler. So common sense dictates using it - you know 80% (my wild guess here) of programming is maintenance, the code is written once and read 1000 times, and so on. We all know these old programming adages, and they don't just apply to telling variable names and insightful comments. Type information is in my eyes another part of writing understandable (as opposed to "genius"-) code.

3. Other people's experiences

 OK, I'm not that much experienced in dynamic languages, so maybe I've got the wrong impression, or didn't understand something correctly, or maybe I'm just not clever enough?

But then, when I started reading the "Beginning Scala" book (well, I didn't finish reading it in the end because I got bored, but that's another story...) the following lines struck me:

As my Ruby and Rails projects grew beyond a few thousand lines of code and as I added team members to my projects, the challenges of dynamic languages became apparent. We were spending more than half our coding time writing tests, and much of the productivity gains we saw were lost in test writing. Most of the tests would have been unnecessary in Java because most of them were geared toward making sure that we’d updated the callers when we refactored code by changing method names or parameter counts.

As you see, that practical experiences are rather confirming my assertions about static typing: a) why write test which can be (kind of) automatically generated by compiler, and: b) why not let automatically document and check the interfaces?

But there's another angle on that problem which I didn't think of:

Also, I found that working on teams where there were mind melds between two to four team members, things went well in Ruby, but as we tried to bring new members onto the team, the mental connections were hard to transmit to new team members.

This goes more into the psychology of programming on the first sight, and maybe it's a cultural thing altogether, but it relates a little with: c) why not document the interfaces as you are writing code to make obvious things obvious? I mean, if the interfaces are better described then maybe the new team members will absorb the knowledge better?

Another Ruby guy tried the Go language and wrote an interesting post about his experiences with static (although implicit) typing he encountered in GoLang:

I guarantee that no matter how much I look at the Ruby code, if it runs for any length of time I'll eventually encounter a typing error because of a bug in the code…

OK, the same old story about interface documentation and checking as above. But read on, there's more to come:

I've learned that I vastly prefer the cost of slower development time to gain reliability and safety, as long as the cost isn't too high. Haskell is even safer, but it pushes the boundaries of how much pain I'm willing to endure trying to get code to pass through the type checker

Here he's making a good point, kind of reiterating my main argument: there's a trade-off between the developer time needed to type a piece of code and it's reliability. In the past we opted for ease of construction, but if we can have the reliability for very small additional cost? With type inference we hit a sweet spot here!****

So it's decided, there are real problems with dynamic typing in real-world projects, and static typing can help out here. Why would anyone want to use a dynamic language (beside for scripting some small pieces of code) then?

But wait, what about Clojure? I like this language... and I'm somehow in 2 minds here - the reason says ML but the heart says Lisp. So is this an emotional thing in the end? But in business you have to follow the path of reason, not coolness, to deliver results to your clients. And there aren't that much Lisp projects out there... So the decision isn't difficult: I'll opt for statically typed languages in general, but when offered a Clojure project (which will happen very seldom I guess) I'll jump to it! Don't you think it's a good tradeoff?

Goodie:

PS: do you remember pre-ANSI C? Probably not, but it wasn't type safe:

Within the function, the declaration of a is visible, so the compiler knows it's a char*. For a call, the compiler doesn't know what type of argument the function expects, so it's up to the caller to pass the right type. It's similar to what happens with printf-like functions.*** 

Here an example for those not remembering the "stone-age":

int 

ParseGLFunc (interp, argc, argv, nArg)

    Tcl_Interp *interp;

    int argc;

    char *argv [];

    int *nArg;

{

    ....
}

--

* I'm sure you know it already, but statically typed means for a programming language to check the types at compile time whereas dynamically typed means checking of type correctness at runtime.
** An article by Bruce Eckel: "Strong Typing vs. Strong Testing"

*** found it here: "pre-ansi declarations"
**** here I  must admit that I'm just impressed with the ML family of languages (i.e. OCaml, F# and well, Haskell too) and the automatic type deduction the compiler is doing! The code is just flowing from your fingers as in Python or Ruby, but it's type checked!

ASSERT(AfxGetThread() == NULL) with VisualStudio 2010, or the DLL-hell, revamped

Everybody thinks DLL-hell is a thing of the past. Me included: #WTF, just start the Dependency Walker, look what libraries got loaded, correct it and be happy*. Not so, with the advent of Visual Studio 2010 everything got a bit more complicated!

Let me describe the problem which I encountered working in a project for one of my customers. Let's start with a...

Disclaimer:

This is only a short technical note - for those who (like me) first check the Internet for solution to weird programming questions!

The Problem:

is maybe best described by this desperate post:

Hi all,

I have a question to solve, the situation is I use a exe to load a dll(MFC regular dll),but when I use LoadLibrary() to load the dll and in the constructor of the object whose base class is CWinApp in the dll, It have a assert error, and the code line is ASSERT (AfxGetThread() == NULL).Is there anyone have the similar situation with me and have thoughts about it can tell me ,we can talk about it.

thanks in advance.

Well, the same happened to me when I was porting a C++ application from Visual Studio 2008 to VS 2010. To be honest, the situation was a little more complicated: a mixed mode C++/C# program using C++/CLI as a glue. But back to the problem: the standard explanation for that ASSERT is that you have forgotten to include the AFX_MANAGE_STATE macro (Reason 1) in exported DLL functions as described here.

Sadly, this wasn't my problem. It applies to non-MFC DLLs only**, which mine wasn't, so the whole module state management business should be cared automatically in DLL initalization code the linker is generating. This again is controlled by #define macros used whith the compiler (like _USRDLL, _AFXDLL and their hellish likes). So maybe this could be the reason? Nope, everything was correct :-(.

After more web-searching and finding only tons of happless cries for help I stumbled upon the 2nd useful link

Sounds like you have two or more CWinApp objects, and they're using the same AfxGetThread data. I suppose this could happen if your libraries are linking to different versions of MFC, including mixing of debug and release versions. You might use Dependency Walker (depends.exe) to determine the DLLs you link to implicitly, or the Sysinternals Process Explorer to determine the DLLs you're using at runtime

Well, that sounds interesting, mybe I've mixed debug and release DLLs? Nope (although I made that error later on, so it's defintely a good point to keep in mind (Reason 2)). What could it possibly be then???

The Solution:

The solution is more complicated, but somehow both typical and symptomatic for real-life nontrivial system using Microsoft technology... As my client had a really old codebase growing steadily with the years, all possible Microsoft technologies could be found there; beginning with plain old DLL, through MFC-based ones, further using C++/CLI and at last arriving at C# and .NET. This last one was burdened with a constraint: we had to use .NET v.2.0. The problem is, that Visual Studio 2010 doesn't suppport .NET 2.0! Because of time shortage they decided that only .NET 4.0 will be supported out of the box, and that the 2008 VS-compiler will be inegrated in Visual Studio 2010 to be used for older .NET versions.

Well, in itself it wouldn't pose any problems, if there wouldn't be the C++/CLI code which we used as glue between pure C++ MFC and the newer C# parts. It has to be compiled for the .NET 2.0 as well, thus should use the 2008 VS-compiler. But it is put in a DLL which int turn is loaded by a traditional C++/MFC one (created with  2010 VS-compiler!). See it? Two different compilers, 2 diffrent runtimes, 2 CWinApp objects as in (Reason 2) (or maybe the loader gets misleaded, I'm not sure about it). In any case, Visual Studio 2010 is forcing us to use 2 compilers in one application here (Reason 3).
 

The Mores:

I'm not sure about that one. How about this: stay away from MFC and use Qt? Or: don't migrate your code to VisualStudio 2010 (as it's rather slow to boot)? You're damned if you have to be backwards compatible? 

--

* see here  for author's previous letter from DLL-hell

** more hellish details: 3 kinds of DLLs you can use on Windows: ... TODO: link (but that's just plain boring!)