Posts

Build libexif for Windows and Visual Studio

/in /by

This is a record of how to build / compile libexif (v0.6.21) binaries for windows. It is another entry in a Software Engineer’s daily ‘trial log’, however this time thanks to the excellent MinGW32 and the well written libexif things went rather well!

This readme says that you have 2 options, either hack together a project in Visual Studio to build the library or use MinGW32 to build it.

I tried the first option, but the main problem is that poor old Visual Studio can’t handle some of the more modern standard C (C99) constructs that libexif uses (e.g. the inline keyword).

So that left the MinGW route which is detailed here:

1.) Install MinGW32 onto your windows machine if you don’t already have it. Florian Wolters has a good description of how to do this here (thanks!).

I found it vital to put the path to WinGW32’s bin directory at the beginning of my system PATH variable, not at the end! Check that MinGW32 is working ok by trying Florian’s little test program.

2.) Get the libexif source here. Extract it to somewhere.

3.) Open a windows console window (CMD), don’t use GitBash or anything, just cmd.exe, cd into the extracted libexif folder. I used GitBash at the begining but was getting make errors, it turned out that some of GitBash’s tools were conflicting with MinGW’s tools.

4.) Make libexif by issuing the following commands:

#
sh ./configure --prefix=/tmp/install_libexif
make
make install
#

Now during make, you may get an error like this:

libtool: link: cannot find the library `/home/keith/staged/mingw32/lib/libiconv.’

If this happens, go to your MinGW lib directory (e.g. C:\MinGW\lib) and delete this file:

libintl.la

And try running make again, if you continue to get the above error, then the advice out there us to delete any files with ‘keith’ in them, but luckily I didn’t have to.

If make & make install succeed, you should then see the install directories in /tmp, which you can access using MS explorer in your MinGW\msys directory:

e.g. maybe in C:\MinGW\msys\1.0\tmp

Thankfully that all worked for me, I was then able to link to the libexif libraries from a Visual Studio 2012 C++ project. The only gotcha I found is that when freeing the char* buffer allocated during a call to exif_data_save_data(), I found it important not to use free() but to use libexif’s own memory deallacator like this:

// 
   unsigned char *exif_data;
    
    /* Get a pointer to the EXIF data block we just created */
    exif_data_save_data(exif, &exif_data, &exif_data_len);
    // Use exif_data here, save it to file etc..
    // Now we want to free this memory
    // don't  do this, we will get a heap error:
    // free(exif_data) 
    // instead can do this (as long as you used
    // the default mem allocator earlier in your
    // code):
    ExifMem *mem = exif_mem_new_default();
    exif_mem_free(mem, exif_data);
//

This is probably due to my test application using a different malloc() to the lib.

To link to libEXIF from visual studio you can directly add libexif.dll.a to Properties / Linker / Input / Additional Dependencies and then just make sure that libexif-12.dll is somewhere on the execution path.

If you don’t fancy all of this hassle the library binaries can be downloaded from here.

.NET – How to tell if a DLL is 32bit or 64bit

/in /by

So in the world of MS Windows software development, the bitness of DLLs (64bit vs 32bit) is the new DLL Hell!! It is slightly annoying that Microsoft eventually dug itself out of decades of DLL hell just to create a new hellish DLL vista – anyway there’s nothing to be done.

 

API vendors will often have 2 versions of their API, a 32bit one and a 64bit one, sometimes if you are really unlucky they will name their assemblies and DLLs using the same names for both platforms so there will be no way to easily tell if a DLL is 32bit or 64bit just by looking at the file name.

 

So how do you figure out the bitness of a DLL when you are trying to debug and fix .NET ‘Incorrect Format’ errors?

 

Annoyingly it turns out that there is no easy way to do this through windows. There is, however, a nice little tool by Silurian Software that integrates into windows explorer’s file properties pages called InspectEye, it gives you loads of info about an EXE or DLL including whether it’s 32 or 64 bit! It worked nicely for us anyway although I haven’t looked at the rest of the software’s features yet…

 

The tool can be downloaded from here:

 

http://www.silurian.com/win32/inspect.htm

 

Unblock multiple files using SysInternals Streams

/in /by

Sometimes you may find that you need to unblock a file in wondows if you have downloaded it from the internet from moved it from a network drive – in this case you may encounter a message like this:

 

“This file came from another computer and might be blocked to help protect this computer”

 

To do this you right click on the file in explorer, choose ‘properties’ and on the general tab click the ‘Unblock’ button.

 

This is all very well but what if you need to unblock a folder of 27 files, the above method would take an age?!

 

Well SysInternals have a utility called Streams which helps with this. Download Streams and extract streams.exe into a directory that’s on your path. Now, to unblock a folder full of files, open a command window and run something like this:

 


streams -s -d {directory}

 

This should unblock all the files in the specified directory!