C and C++ - duplicate dllmain

[Guest zip]

Hi,I'm working with Visual C++ (VS2003) and have a gauge in three modules, two are in C++ (cpp) using DirectX, and the main gauge file in straight C. No problem compiling but I have a conflict between the CPP libraries and the C libraries, in that I have two _DLLMain entries (one for the CPP libraries, one for the C library) and a linker 2005 error (duplicate symbol). The gauge compiles just fine as long as I don't use any of the libraries (.lib) written in CPP.The culprit is no doubt the GAUGE.H file that declares the DLL main entry point, but MS also says you can't combine some libraries.My choices are (I think):1) write the gauge code in CPP so the libraries are used throughout2) split the C and CPP code as two DLLs and link to the external DLL from the C gauge code.I think 1) is far better, given that most all the code I've seen in DirectX is in C++ or C#, but alas, the SDK example, and Dai Griffith's excellent tutorial haven't shed any light on the subject. Anyone can share a config or tips on how to resolve this? I can't seem to locate an example Gauge in C++. Is there a header file (gauge.h) modified to work with C++ and classes?Thanks,

[Guest bartels]

All gauges.h, including the current fs9gauges.h, from Dais tutorials are C++ compatible. In my experience there is no need to add the DirectX part as a DLL, this will always lead to the DLLMain conflict. Just use the parts that you need, e.g. from application examples or suchlike. I'm currently working on a tracffic radar gauge example, completetly in C++ which might find it's way to Dais tutorial in future.Arne Bartels

[Guest zip]

Thanks Arne,after playing with it some more, it looks like that short of eliminating MFC and ATL from the equation, I'm not going to get the linker to cooperate.Looking at doing just that, or using separate DLLs. This is so far the type of project where 25% of the time is spent on the "meat" and bug fixing, the rest losing hair on playing a sleuth detective.But, that's part of the fun isn't it?

[Guest bartels]

25%! Wow that's good. I'm usually around 10% and 90% is doctoring! As you said that's the fun actually.Which DirectX components do you want to insert in the gauge? I doodled around with DirectInput some time ago. It was relatively easy to adapt the example code to my needs without any need of MFC or suchlike. It is even possible to mix C coded gauges together with C++ DirectX code.Arne Bartels

[jcboliveira 1]

What I did was to declare all DirectX function that interact with C code as extern "C". Only tried with DirectSound and directInput. Directplay I use in external program. You don't need MFC just plain Win32 API.Here:http://www.jcboliveira.flysplash.org/you can find DirectSound and DirectPlay, for DirectInput I have the code but no comments on it :(Jos

[Guest zip]

I believe you're both right - it's 5% meat, 20% debugging, and the rest a sordid mixture (in no particular order) of fermented grape juice (keeps spirits up), tylenol (fixes the de-facto grape juice overdose), choice (but nice) words to describe "what were they thinking!" (the FS team) and "ok, this has gotta work, someone else when through this and survived". Did I mention the fishing expedition? :DOk, I finally got it to link in VS2003 with no errors and in CPP mode by yanking the AFX stuff from the code (eg, eliminate stdafx.h from the equation). Took all day (most of it is my learning curve). Part of my problem is that nearly all the examples in the DirectX SDK are in C++ or C# using AFX or .NET, a far cry from being usable as is with straight C. It is evident that the moment ATL or MFC is involved, it becomes impossible to link as a normal FS9 DLL. If you change the priority of the linking (library wise), even though supposedly MFS has "weak" definitions for DLLMain, the rest of AFX blows up with missing symbols (at least in my case).Conclusion: don't mix MFC/ATL framework with this, or use separate DLLs.