Compiling JPEG.DLL

[Phil Steinmeyer]

Has anybody here had any luck compiling JPEG.DLL (from the Independent Jpeg Group) under MSVC? It has no MSVC makefiles/projects and when I tried to create an MSVC project, I can compile it, but the resulting DLL doesn't work for me (Calls against it, through SDL_Image, fail)

[soniCron]

You can grab precompiled binaries from the DevIL homepage (http://openil.sourceforge.net/download.php) (at the bottom). Direct download: precompiled libraries (http://openil.sourceforge.net/libs/LibCompiled.zip).

[patrox]

Has anybody here had any luck compiling JPEG.DLL (from the Independent Jpeg Group) under MSVC? It has no MSVC makefiles/projects and when I tried to create an MSVC project, I can compile it, but the resulting DLL doesn't work for me (Calls against it, through SDL_Image, fail)

OleLoadPicture will decompress BMP, Gif and JPEG ( maybe even png ) just fine ( it's built into windows since W95 )

pat.

[Dominique Biesmans]

Has anybody here had any luck compiling JPEG.DLL (from the Independent Jpeg Group) under MSVC? It has no MSVC makefiles/projects and when I tried to create an MSVC project, I can compile it, but the resulting DLL doesn't work for me (Calls against it, through SDL_Image, fail)

Maybe, this has to do with exporting symbols? You can export symbols (like functions) from a dll with a .DEF file or the __declspec(dllexport) keywords.


__declspec(dllexport) void __cdecl YourFunction(void);


will do the trick
normally, you probably want to do something like


// DLLEXPORTS is defined in the project settings of the dll
#ifdef _DLLEXPORTS
#define FUNCTIONSPEC __declspec(dllexport)
#else
#define FUNCTIONSPEC __declspec(dllimport)
#endif


and then


FUNCTIONSPEC void __cdecl YourFunction(void);


for each function you want to export in your header file. If you start a new DLL, MSVC will generate these defines for you, so you just need to insert them in front of all exported functions.

[PeterM]

I usually put the __declspec(dllexport) macro after the type, not before. I'm not sure if this is the 'right' way to do it though, but it seems to work.

A good way to check your DLL for exports is to use the "Depends" Dependency Viewer tool that comes with MSVC6. You can associate it with .dll and double click them to check their exports and dependencies.

Pete

[PeterM]

If you don't have it, you can get Depends here:

http://www.dependencywalker.com/

I also use it to check which DLLs my app uses so I know what to bundle with it.

[Phil Steinmeyer]

It seemed to be exporting functions correctly when I compiled it, and if I dig deep enough, I can probably debug the 'real' problem, but I was hoping that there might be existing project files out there for it in some way. I already had the compiled binaries, but I wanted to make some tweaks (target MSVCR71.DLL instead of MSVCRT.DLL, and probably remove some unneeded functionality to trim it down, size-wise).

But it's not that critical to me - not worth spending more than a couple hours of my time pursuing...

Phil

[Donavon Keithley]

A good way to check your DLL for exports is to use the "Depends" Dependency Viewer tool that comes with MSVC6.
And from the command line:

dumpbin /exports foo.dll

[PeterM]

You can grab precompiled binaries from the DevIL homepage (http://openil.sourceforge.net/download.php) (at the bottom). Direct download: precompiled libraries (http://openil.sourceforge.net/libs/LibCompiled.zip).

As far as I can tell, these binaries aren't DLLs, they're static libraries.

[PeterM]

I spent a few minutes compiling up a DLL version of jpeglib, complete with a vc7 project file. I made minimal changes to the library, basically copying the jconfig.vc to jconfig.h as usual, and adding the following to jmorecfg.h:
#ifdef _MSC_VER
# ifdef JPEG_EXPORTS
# define EXTERN(type) __declspec(dllexport) type
# else
# define EXTERN(type) __declspec(dllimport) type
# endif
#else
# define EXTERN(type) extern type
#endif
Nothing else codewise was changed, so it should be binary compatible with every other decent Win32 DLL version. I've set up the directory structure like this:

include/j*.h
src/j*.c
projects/vc7/jpeg.vcproj
unused/* (all the extra files which are not required to build the DLL)

And building will produce these:

obj/release/j*.obj
lib/release/jpeg.lib, jpeg.dll, jpeg.exp

Similar for debug builds.

If anyone would like a copy of the archive, just ask. It's available as a 585 K RAR, or a 735 K ZIP.

I'm not keen on uploading it on my site because I don't want to be seen as a quasi-official jpeg.dll source. But if anyone else wants to host it themselves, that's obviously ok.

Pete

[PeterM]

Sorry for hogging this thread, but I just found the reason why jpeglib isn't normally distributed as a DLL under Windows.

If you find that your DLL is crashing in an fread() call inside ntdll.dll, this may help. From install.doc:
2. Microsoft C cannot pass file pointers between applications and DLLs. (See Microsoft Knowledge Base, PSS ID Number Q50336.) So jdatasrc.c and jdatadst.c don't work if you open a file in your application and then pass the pointer to the DLL. One workaround is to make jdatasrc.c/jdatadst.c part of your main application rather than part of the DLL.
Another workaround is to write your own read and write functions, and supply them to jpeglib, or just link statically.

Pete