If MuPdfWrapper.dll can work in 32-bit windows

[arklumpus]

If MuPdfWrapper.dll can work in 32-bit windows

[esonhon]

Oh, I've missed some important message in the first comment.
Actually, I've followed “Building libmupdf” and "Tips for compiling MuPDF 1.18.0" section in Readme.md, same error.
Both libmupdf.lib and MuPdfWrapper are compiled for x86 arch, double checked by dumpbin.exe /headers tool.
So I think if libmupdf and the wrapper combination can really run in x86 windows.

[esonhon]

Current progress,
Found the key of above exception,
int CreateContext(long store_size, const fz_context** out_ctx) in wrapper declared the store_size parameter as long, which in x86 arch is actually 4 bytes integer, but in MuPdfCore, it is declared as Ulong, which is 8 bytes long.
After modify the declaration, CreateContext return success, but CreateDocumentFromStream return ERR_CANNOT_OPEN_FILE. Yes, it's the error I used to get yesterday in another issue. Should do more investigation.

[arklumpus]

Hi again! Yes, I'm afraid you will encounter similar issues throughout the whole library: the problem is that in C++ data types can have different sizes depending on the architecture (as you noticed), while in C# they always have the same size.

Making the library work with both x86 and x64 without having two separate code branches might be achievable (see here for ideas for an initial approach), but it will require a non-insignificant amount of work... Which is why I didn't do it in the first place, considering that most machines now should be x64-capable 😅

I may have to think back about this when Microsoft release .NET 6 with native support for Apple silicon Macs (because I need native support for another project), but I'm hoping that since that is still an Arm64 architecture it won't be much work.

Anyways, are you sure you need to do this? Even if your application is compiled with AnyCPU (and you get a warning because this is not compatible with MuPDFCore's x64 architecture), if the program is running on an x64 machine it should work without issues (and I expect that nowadays there are only very few computers actually running 32-bit Windows...)

If you're sure you want to do this, you will likely have to debug the whole MuPDFWrapper native code for issues like this. I would suggest adding lines that print something to the console in multiple places within the C++ code, so that you can figure out where the errors are occurring. I would also recommend, as far as possible, not to touch the C++ code, but rather implement the fixes in the C# code (I think it's easier for the C++ code to fail "silently", while .NET will usually give some sort of "complaint" when something is wrong).

Let me know if you succeed!

[esonhon]

Thanks again, Giorgio. ^_^
Your suggestion is quite right. Actually, the application must work with a thirdparty hardware, they can not supply a x64 native driver dll, So I have to implement the x86 version for the full project.
I'll try to debug and fix the native interface in MuPdfCore, if no success, the last way is wrap the third party native dll with a 32 bit .net class and use RPC to communicate with.

[esonhon]

Finally, the library worked in my usecase. Not tested completely.
To avoid maintain two versions of MuPDFCore and follow your future updates, I decided to keep MuPDFCore original, modify the wrapper source.
Actually it's easy than I think, just modify the interface function declaration from size_t to uint64_t, long to uint64_t, it's working in both x86 and x64 arch with same source.
Thanks.

[arklumpus]

That's good news!

The only thing to look out for is that the where I was using size_t, this was because the MuPDF library calls that the wrapper performs also have size_t parameters... So what you did might work in most cases, but it wouldn't surprise me if some weird things^TM happen in edge cases 😅

In any case, I think we can close this, right?

[esonhon]

Yes, I've not test it by large PDF file, because my PDF file to render is code generated report, less than 100k in size.

[arklumpus]

Hi! I think you have already solved your issue, but I just wanted to mention that in version 1.4.0 I have finally added native support for 32-bit Windows (and a few more architectures)!