Compiling FilmBox SDK Under VC6

Hi,

I am trying to compile Filmbox's SDK using VC6. I can compile under VC7, but I only have a temp version, and do not want to port over to VC7.

The problem I am getting is on the following section of code:

/***********************************************************************
CLASS KStaticArray
************************************************************************/

template< class Type > class KBaseStaticArray
{
    protected:
    kInt mCount;
    Type *mArrayBuf;

public:
inline kInt GetCount() { return mCount; }

    // Access pointer at given index.
inline Type &operator[](int pIndex)
{
    #ifndef K_PLUGIN
  K_ASSERT_MSG( pIndex >= 0 , "Buffer underflow, appelle ton plombier.");
  K_ASSERT_MSG( pIndex < mCount,"Buffer overflow, appelle ton plombier.");
    #endif
  return mArrayBuf[pIndex];
}
};

// Static Array
template< class Type, int Count > class KStaticArray : public KBaseStaticArray<Type>
{
public:
Type mArray[Count];
inline KStaticArray(){ mArrayBuf = mArray; mCount = Count;}
};

template< class Type, int Count1, int Count2 > class KStaticArray2d
{
public:
KStaticArray<Type,Count2> mArray[Count1];

// Access pointer at given index.
inline KStaticArray< Type, Count2 > &operator[](int pIndex)
{
    #ifndef K_PLUGIN
  K_ASSERT_MSG( pIndex >= 0 , "Buffer underflow, appelle ton plombier.");
  K_ASSERT_MSG( pIndex < Count1,"Buffer overflow, appelle ton plombier.");
    #endif
  return mArray[pIndex];
}
};

on the 11th to last line:

>> KStaticArray<Type,Count2> mArray[Count1];

I get:
c:\program files\alias\fbxsdk60\include\klib\karrayul.h(81) : error C2233: '<Unknown>' : arrays of objects containing zero-size arrays are illegal

Is this something I can sort out in VC6 or am I doomed to upgrade. There are some good features in VC7, but it seems so slow and does not respond well to code changes during debugging.

Thanks,

Simon

Answer this question

Compiling FilmBox SDK Under VC6

Mieux
Yes: Visual C++ 8.0 (AKA Visual C++ 2005) is very different to Visual C++ 6.0 - and if you make the leap striaght from 6.0 to 8.0 it must seem a lot slower (grumble, grumble).

Whether you can build the library with Visual C++ 8.0 and then link it with a Visual C++ 6.0 application really depends on what the binding is like.

If the binding uses just straight C or COM then there shouldn't be a problem: if it uses C++then you might run into some problems as the algorithm we use for generating those lovely mangled names we give functions in C++ has changed several times between 6.0 and 8.0 (mostly due to requirements of the C++ Standard).
zjs
Are you planning on linking in the code you compile with Visual C++ 8.0 as a static library or as DLL. If you are planning on using static linking then you don't need to do anything special - just provide your Visual C++ 6.0 code with a header file that declares the methods that you can call.

If you are planning on using a DLL the the process is pretty much the same except you will also have to provide an import-library.
prasannadotnet
Just a side question:

Would it be possible to go the other way I'd like to use VC++ 8.0 as compiler but I need to compile static libraries and I have clients who still wants to use VC6. For now I've been using VC++ 6.0 but regually made sure my code also compiles with VC8 for future use. However it seems lots of the libc functions are now redefined to the new secure functions. These naturally doesn't exist so if I remember right I got some missing symbols during linking. If my memory serves me right I remember having some linking problems because the internal libc functions would call some of the newer secure versions and thus create a missing dependency. Does this sound correct

For now this does not scare me, but it would scare me if those new secure functions also started coming into the Platform SDK releases sometime in future. This would mean I would have to make multiple builds for those clients who would use the plain Visual Studio (no matter version) and those who would use it with the PSDK.

Can you tell me about what I should be aware of if I would try to go from VC8 static libs into VC6 linking
Il-Sung
Based on what you said I tried it. My static library uses C interface to hide the C++ used inside. So I switched to VC8 Beta2 and compiled the library and then back to VC6 to link.

Here is the commandline used for compiling the library:

cl -c -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONS
TDC_NO_DEPRECATE /Fotemp/Win32/ /W3 /EHsc /O2 /nologo

Here are the errors I got:

client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __fstat64i32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __security_cookie
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __localtime64
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __time64
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __findnext64i32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __stat64i32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __findfirst64i32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol _strcpy_s

There are a number of 64 bit functions, security cookie (which relates to /GS flag I think) and strcpy_s.

I can understand the security cookie and I guess it should be possible to disable. So the question is what about the 64 bit functions, can they be disabled to use the old ones The most mysterious one is strcpy_s. It doesn't seem to fit into any category but might be a dependency of one of the newer functions used

Thanks in advance.
George Bolsch

Henrick: while we added the secure functions to the C runtime and made it "difficult" to call the old functions we actually didn't remove them: they are still there and you shouldn't get any link errors. Again if you need to mix Visual C++ 6.0 and Visual C++ 8.0 I would stick to a C interface (or a COM interface) - if you do this then it should work.
jsmans
Unfortunately Visual C++ 6.0 is on its last legs (I believe that even extended support ends on Firday).

If you are working with templates then I would really encourage you to upgrade to the (very) soon to be released Visual C++ 2005 or at a pinch Visual C++ 2003. Before Visual C++ 2003 heavy use of templates could cause the Microsoft compiler "problems"

If you really, really must stick with Visual C++ 6.0 then I would suggest that you dig around on the Boost site (www.boost.org) I know that some of those guys bent over backwards trying to find ways to get their heavily templated code to work with Visual C++ 6.0.
Alexander Khimich
I 100% agree to everything Jonathan sayed.
Leave VC6 behind. The compiler of VC.NET2003+2005 has so many advantages and compiles much better programs that I would not hesitate.
Julien Lavigne du Cadet
Thanks. I am actually using the Pre-release Visual Studio 2005. It does seem slower and so different from VC6 which is why I would like to be able to stay with VC6 for the moment.

Am I going to be able to compile the Filmbox code as a library from Studio5 and link it into VC6, or am I barking up a red herring Is there data about how to do this as it did not easily work when I tried.

Simon

PS: I really appreciate your help wit this!
Sebastien Donche
At some point you are going to have to link in the Visual C++ 2005 C runtime. So I am starting to suspect that maybe statically linking in your Visual C++ 2005 component into your Visual C++ 6.0 application may not be possible as you will end-up needing two different versions of the C runtime. You might need to turn your Visual C++ 2005 component into a DLL and then use that with your Visual C++ 6.0 application.
Eric Kim
One thing you should be aware of is that Visual C++ 7.0 (AKA Visual C++ .NET) is not really much better at handling template code than Visual C++ 6.0 (we did some work but not a lot). If you really want to use templates (and not always be worried that your code might cause the compiler to crash) I would really suggest using the almost shipping Visual C++ 2005 or the previous release Visual C++ 2003.
Kevin Xiao
Thanks to both Jonathan and Martin for your answers

I will not try to make VC6 work with this. While I probably will upgrade fully to VC7, I would like to keep my main project on VC6 and compile this addtion under VC7. What is my best plan. To compile and link it in as an Obj from VC7 into 6 To build it as a lib and link it in or as a DLL. I have tried the 2 former with numerous errors etc - is there a document that goes into this sort of thing

Thanks again
forummember
Ok now I added the following switches:

/GS- and /D_USE_32BIT_TIME_T

This gave me a few less missing symbols:

client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __fstat32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __localtime32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __time32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __findnext32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __stat32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol __findfirst32
client_mt.lib(w.obj) : error LNK2001: unresolved external symbol _strcpy_s

Ok so I went into io.h and found that the original functions has been postfixed with "32" which basicly means the old functions are gone.

_CRTIMP intptr_t __cdecl _findfirst32(const char *, struct _finddata32_t *);
_CRTIMP int __cdecl _findnext32(intptr_t, struct _finddata32_t *);

Another problem is the reference to strcpy_s which I am not sure where comes from.

Looking in string.h we see that both strcpy() and strcpy_s() exist:

_CRT_INSECURE_DEPRECATE char * __cdecl strcpy(char *, const char *);
_CRTIMP errcode __cdecl strcpy_s(char *, size_t, const char *);

Thus this dependency comes from a macro which redefines a function into strcpy_s or a libc function calling strcpy_s internally.

This is really too bad then. I guess the chances are slim to get it working. The same problem would also arise when going from VC8 to VC7.1 (I did not test it though).
Michael Brooks
Hi,

Thanks! Is there any documentation on doing this. The calls can be straight C as far as I am concerned. Is there a tech write up on doing this that you know of

Yes, VC8 does seem a lot slower than 6 though I can see some good features have been added. It seems to be the way of all software - it gets more complex faster than processors speed up so the overall result is everything is slower though better.
Sedigh
I was planning on using it as a lib, not a DLL. I tried this and got a lot of errors with multiple definitions of library functions, but I guess I must have linked in something with the .lib file. I'll try it again and see. It's good to know that it is possible :-)

Simon
Compiling FilmBox SDK Under VC6

Answer this question