Due to continual spamming, forum registrations are now by Invitation Only. Hopefully this will be only a temporary measure to combat spammers.

If you want an invitation contact forumapplication @ camstudio . org

Sorry for the inconvenience.

side-by-side issue (no other issues please here)

edited July 2010 in Common Tips & Tricks
About Side-by-side issue:

Some people reported that they could not execute Camstudio recorder due to side-by-side configuration conflicts.
This is caused because MS changed dll loading behavior with the introduction of new VS versions but it appears that the different OSes (XP,VISTA, SEVEN) are looking in different locations for dll's to use either.

A fighting dll approach as proposed by Terry can work but it is not a persistent solution. Other users may suffer same problems and will ask for help.

I'm busy to introduce private assemblies for Camstudio release mode (solution advised by MS).
In that case application.manifest file define which dll's will be used.
In our case, the dll's that comes with our distribution and we used for testing before.
I expect that this will solve the side-by-side issues.

Need people who tried to install/use Camstudio but failed due to side-by-side to verify that it works before we release this as a new revision.
@Volunteers , send a message to me.



  • Terry and Yamyam proved that downloading and installing the Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) is a solution.

    Go to Microsoft and download and run the MS C++ Runtime Library installer package:

    English : http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en
    German : http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=de

    (Other language: change xx after displaylang.)
  • Need someone who suffers from side-by-side configuration errors.

    Test, to check if this will make Recorder.exe starts if new releases includes manifest files:
    Please extract file from temp link below.


    Unzip and put manifest file in the same folder as Recorder.exe.
    Try to start recorder.exe
  • Installed 2.6b to a laptop (Windows Vista 32-bit Home Premium) that had been restored to factory defaults and brought up to date via Windows Update.

    Manifest files made no difference.

    Installed the VC++ 2008 runtimes - CamStudio 2.6b worked immediately


    Nick :o)
  • edited August 2010

    Did Microsoft change the default behavior I was used to (from Visual Basic days) where the application executable looked first inside of its own program folder for a sought-after DLL, then, if it did not find it there, it would look to the registry (if I remember correctly) for a pointer to a location, and if that failed (or no reference to a registry pointer existed) then it would finally look in the system32 directory for the DLL?

    First, of course, did I remember all of that correctly?

    Second, is that behavior now different in Vista and Win7?

    It would seem that having the ability to place all of the required DLLs into the same program folder as the executable is key to allowing a "portable" program installation, let alone allowing the scenario where the only steps needed to completely uninstall a program would be to merely delete its program folder (wherever that resided), as I believe is currently the case with programs like VirtualDub (and even Camstudio 2.0 if the "missing" DLLs [msvcp71.dll, msvcr71.dll and mfc71.dll]
    were placed into the program folder ... The new portable 2.6 beta version by supanut, I just noticed, is using msvcp90.dll, msvcr90.dll and mfc90.dll, which I imagine are newer incarnations of these).

    I've placed the *71 and the *90 versions of these three files into http://terrybritton.com/CamstudioMissingDLLs.zip if you need them for experimenting.

  • Hi Terry,

    Supanat only used all the files that are included in the 2.6b install I created.
    *71 files are for cpp exec's compiled with the older compiler.
    With Studio 2008 you get the *90 dll's.
    *90 were include in the current install and put in the same directory as the execs.
    This works on XP but not on Vista and Seven we learned.

    And yes, the behavior how and where Windows looks for DLL's is different on XP compared with Vista and Seven. On Vists/Seven systems it will looks first in the SXS folder.
    With manifest files one should be able to determine which dll's and from which location should be used.
    In the meantime I found a few very valuable documents that will help us to compile our sources again to improve manifest handling and I got additional information that will help us to include the redist packages in our inno install.

  • edited August 2010

    Ahhh - Well, I figured something was up with the way Vista and Seven looked for DLL's.

    I'm still a little confused why USB "portable" apps work at all!! I should study on that a bit to gain some understanding. Camstudio seems like it is a prime candidate for both USB "portable" installs as well as for "one-folder" installs, I would think.

  • edited August 2010
    Jan (and any other programmers out there...),

    I did some exploration at PortableApps.com in their developers' forum ( http://portableapps.com/forums/development/portable_app_development ) and found that the side-by-side issue has wrought havoc with many of the attempts to "make portable" several open-source projects, especially those depending on the C++ libraries.

    Why are we using those libraries?

    It seems most people are using them primarily merely for the windowing and buttons routines! Weren't those written in straight C in the old days? (The "big pain in the butt" that moved me to go into Visual Basic 5!) But I digress...

    Here is a discussion on the portable Blender ( http://portableapps.com/node/16257 ):

    >Can the Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)be included with Blender? (As it's... redistributable)

    >Probably not, as the dynamic runtimes in VC2005 and 2008 require a manifest, therefore the DLLs have to be installed in the Windows side-by-side folder. This is part of the reason I switched to Dev-C++...

    >Ah, I always thought putting the required DLLs in the app folder would be enough because that's where Windows looks for them first. But things might have changed recently.

    >They can be put in the app folder if you use include the correct manifest in the same folder.

    >Yeah, side-by-side (introduced in XP) makes things more complicated.

    >Even worse is that it's entirely unnecessary and only makes DLL Hell (the problem it was designed to solve) worse. Sad

    And another on redistributables (quoted part at the bottom at http://portableapps.com/node/17662 ):

    "It depends on whether they are marked by their authors as "Redistributable". Try searching on the Microsoft website to see if they are.

    e.g. gdiplus.dll (GDI+), msvcp60.dll (Microsoft Visual C something 6.0), msvcp71.dll (MSVCP 7.1), msvcr60.dll (MS Visual C Runtime 6.0), msvcr71.dll (MSVCP 7.1) are all redistributable. [...] It all depends on what you need, and searching around to see when it's needed, and making sure that it's legal to distribute it. Redistributable libraries are allowed to be bundled here. Look at most of the apps..."

    And this notice from John at portableapps.com to a developer as to what defines open-source (and some caveats) http://portableapps.com/node/9720 from 2008 at the bottom of that thread:

    "Closed Source - While it is perfectly within the rights of the author to link his open source code to the closed source DLLs within Visual Basic (he owns the copyright, so he can do that) he's using other closed source DLLs that are not part of the Visual Basic runtime, which still makes the package freeware with partial source available and not open source... it would not fall within the hosting guidelines of SourceForge or Google Code. "

    Makes me respect open-source programmers even more!!! So many hoops to jump through!

  • @Terry,

    Thanks for your understanding.
    Although many open source projects face side by side errors due to the Redistributable Package the issue is not suffered by open source projects alone.
    Even well known big two and three letter companies that are used to make and to distribute software hit the same wall.

    I found a few authors on the web that really understood the issue and who could add real value to the discussion.
    With manifest files and a smarter InnoSetup you are able to tell your application to use your own, non SXS folder, were you put your own copies of DLL's from the Redistributable Package first.

Sign In or Register to comment.