Hi guys!

I've noticed that foobar2000 uses MSVCRT.DLL (the VC6 stuff). Now since I'd like to use VC71 (-> MSVCR71.DLL) I'm just wondering if mixing runtimes is ok. I've found an article in the MSDN concerning that topic, and as I understand it it says that it's not wise, since ... well :-)
I think one of the problems will be the different heaps. Or does the MS runtime manage to make MSVCRT.DLL and MSVCR71.DLL use the same heap? If not things will get ugly as soon as e.g. some memory is (re-)allocated inside the component that was originally allocated inside the main application.

Since I didn't find any information regarding this topic on the fb2k homepage as well as here I thought I'd just ask if proper steps have been taken to assure that mixing VC71 (VC80, ...) components with a VC6 foobar2000.exe. If not - I have VC6 installed as well - I'd just like to avoid it since it's a crappy compiler IMHO (at least compared to VC71).

If this is a dumb question please answer it first and only start hitting me afterwards :-)

bye,
hustbaer

p.S.: normally I wouldn't even think about mixing VC6/VC71, but since I there's a statement like "VC6 and VC71 should work ok, intel 7.1 does too but..." and no single recommended compiler ... well so I thought somebody must be thinking it's ok, and if somebody think so somebody might have it's reasons ;-)

p.p.S.: the MSDN article I was referring to: http://msdn.microsoft.com/library/default....e_libraries.asp

Don't have a technical reply for you, but I'm using VC++ 7.1 and have built a foobar DLL without ever needing to think about it. I don't think it matters as long as you don't statically link the CRT anywhere. No sure if it matters -- but I'm using managed code. Not sure of unmanaged code, but I can't see why it wouldn't work.

I haven't tried the 8.0 beta yet, need to free up some disk space before that.

This is a non-issue. Most of the objects you will pass to or receive from other components (including the core) use reference counting, and thus free themselves using the same runtime used to allocate them. Other objects that are not referenced-counted are implied to be freed by the component that allocated them. If you find yourself deleting a pointer of unknown origin, you are probably doing something wrong - unless the object in question has virtual destructor, in which case it may be ok, if you know for sure that nobody else still uses the object.

well thx to you both.

but foosion, what happens if i - say - add an audio chunk to the list passed to dsp::run()?
or alter the size (e.g. grow) of one of the chunks...

surely that means reallocation, and it does not matter that the c++ code ist the same - because the component will call the version from the SDK I compiled, and that SDK will use VC71 runtime because I compiled it with VC71 (versus the same code compiled with VC6 in the foobar2000.exe that will call the VC6 runtime)... so I'm not writing about calling new/delete myself, but calling functions from the SDK that will call new/delete which is just the same problem. got my point?

bye,
hustbaer

Both of these actions (and others as well) work through the use of virtual functions, which means those functions will consistently use the runtime the component implementing the object was linked with.

I see. So I think I'll develop the component using VC71 and make 2 different builds for release - one VC71 and one VC60 for paranoid people like me :-)

Thanks for the info!

bye,
hustbaer