Hi
Albert Strasheim wrote:
> Looking at the errors again, they are:
> 1. "differs only by return type" is due to the covariant return in
> ActiveMQException. But building the AMQCPP part as DLL probably means
> you don't see this anymore.
>
> 2. Something is going awry with the static constants in DeliveryMode. I
> can't figure out why VS6 doesn't like those. As a quick workaround you
> could just #if 0 them and use the literal values or a #define.
>
> 3. long followed by long is illegal is probably because VS6 doesn't
> support the long long type. Not quite sure what do here. You should be
> able to put an #if 0/#endif around that method so that the compiler
> ignores it. But you won't be able to get long (as in Java long)
> properties from the message.
>
> 4. 'size_t' : is not a member of 'std' might be due to CMS not including
> some standard header that should strictly be there. Try adding
> #include <cstddef> to BytesMessage.h. Alternatively, it might be that
> VS6's C++ implementation doesn't have size_t in std. You might be able
> to fix this with something like:
>
> namespace std { typedef ::size_t size_t; }
>
> at the top of BytesMessage.h or by simply changing std::size_t to
> size_t.
>
> With all these bits fixed, you might still run into problems (I could
> be wrong... and I hope I am). The problem is this (I think). E.g.:
>
> Session* session = connection->createSession(...);
>
> createSession calls code in the VS2005-compiled DLL which is
> dynamically linked to some version 8 of the Microsoft runtime. This
> allocates the Session object on a heap specific to that runtime
> library. Now when you do:
>
> delete session;
>
> in code compiled by VS6, that tries to remove the object from some heap
> that belongs to some version 6 of the runtime. The object isn't on that
> heap, so strange things will happen.
>
> For this to work right, I think the various CMS classes would have to
> get methods like destroySession, etc. so that you can be sure that you
> always new and free on the same heap when running on Windows.
>
> Anyway, I could be wrong. Anyone else? You can at least try to just
> delete the stuff. If it blows up, my theory might explain why.
>
> Cheers,
>
> Albert
>
>
If I recall correctly from my VC6 days in order to get STL working
reliably we had to actually use a third party STL package, STLPort I
think. VC6's standards compliance is atrocious and there are a lot of
things missing from STL, and a lot that just don't work real well. I
think that getting this to work in VC6 is going to be a very time
consuming task, almost as hard as getting it working in gcc v2.9.5 or
some other ancient compiler.
tim
