Apr 24, 2014 at 7:03 AM
Edited Apr 24, 2014 at 7:05 AM
To clear out the confusion...
There are 2 dll's involved here. The native one ( gsdll32.dll / gsdll64.dll ) and the managed one ( Ghostscript.NET.dll ). The managed one is just a wrapper around the native one (which means, the managed dll calls exposed functions from the native dll). That
makes a clue that both dll's are required on the system.
You will get a native Ghostscript dll ( gsdll32.dll / gsdll64.dll ) by downloading and installing Ghostscript library from
. Based on native Ghostscript library you downloaded and installed ( 32bit / 64bit ) (you can have both installed) this is what happen:
Native Ghostscript library installer writes some installation information values into the registry. Those values can be found at: "HKEY_LOCAL_MACHINE\SOFTWARE\GPL Ghostscript". One of this values is a GS_DLL which points to the native Ghostscript
dll on the disk. Usually, it points to the: "C:\Program Files\gs\gsv.vv\bin\gsdllxx.dll" where v.vv stands for native Ghostscript library version and xx stands for platform target (32 or 64).
Managed Ghostscript.NET.dll (that can be downloaded from CodePlex) is compiled as AnyCPU. That means when you use this library in a 32 bit process it will run as 32 bit dll and if you run it in a 64 bit process it will run as 64 bit dll. If you are compiling
Ghostscript.NET source code to a specific platform target (x86 or x64) one of the reasons for the different file size is that for x64 dll pointer size has doubled, so if there are a lot of pointers in the code, the dll size grows. So, to make Ghostscript.NET
compatible for all platforms, I decided to go with the AnyCPU platform target. Dll's compiled for AnyCPU are loaded in a way that operating system loader checks for managed modules by examining the COM Descriptor Directory bit in the common object file format
(COFF) header. A set bit indicates a managed module. If the loader detects a managed module, it loads MsCorEE.dll and calls _CorValidateImage, which for 64-bit versions of Windows, modifies the image that is in memory by transforming it from PE32 to PE32+
dumpbin.exe is not a good way to check if dll is compiled for x86 or x64.
Yes, the IMAGE_FILE_HEADER.Machine value is set to 0x14c, the value of IMAGE_FILE_MACHINE_I386 (aka x86). This is of no consequence, perhaps the strongest hint that it is not relevant is the target name: AnyCPU. It runs as well on an x86 as on an x64 operating
What you really want to use is corflags.exe, it shows you the COR header in the file:
The 32BIT flag is the important one, 0 indicates that AnyCPU was used. ILONLY = 1 indicates that the assembly contains IL only, no machine code.
You can create an image file with the machine set to x64. I think that was introduced in .NET 3.0 (aka .NET 2.0 SP1). If you set the platform target to x64 then the machine type field will be set to IMAGE_FILE_MACHINE_AMD64 (aka x64). That doesn't make much
difference, other than that the program will never run on a 32-bit operating system and that the main thread will get started with a 4 megabyte stack instead of a 1 MB stack.
Anyway, the Ghostscript.NET works in a way that it loads a native Ghostscript library dynamically based on the process it's running in. So, if it runs in the 64 bit process, it will load gsdll64.dll, if it runs in the 32 bit process it will load gsdll32.dll.
Ghostscript.NET know where to find those dll's by looking into the registry (mentioned at the beginning of the text).
So, if you want everything to run as 64bit process, simply compile Ghostscript.NET.dll to AnyCPU or x64, compile your application as x64 and that will make Ghostscript.NET to use gsdll64.dll. Make sure you know that this configuration will not work on a 32
bit machine. To make everything compatibile for both platforms, compile everything to AnyCPU and let the os / loader take care doing platform based module loading in the memory.... (something like that) :)
I hope this helps.