Reintroduce Win-x86 support about questpdf HOT 10 CLOSED

I have already attempted to compile the library with the x86 architecture. It requires a special toolchain and is not straightforward. Therefore, some research may be necessary to make it work. I will do one more try next week.

If anyone decides to share the feedback in this thread, please explain why you need the x86 support and why the x64 is insufficient. It would also be great to learn how you use the library.

Thank you for your patience and collaboration! 😄

from questpdf.

I have already attempted to compile the library with the x86 architecture. It requires a special toolchain and is not straightforward. Therefore, some research may be necessary to make it work. I will do one more try next week.

If anyone decides to share the feedback in this thread, please explain why you need the x86 support and why the x64 is insufficient. It would also be great to learn how you use the library.

Thank you for your patience and collaboration! 😄

Regarding Feedback: Our software e.g. relies on some external devices which only work with x86. Allthough the architecture is outdated it would be a pain to replace the devices, therefore we still run on x86 and would require it's support for QuestPDF.

from questpdf.

Hello,
Thanks a lot for this status.
My daugther run a very small company (3 people) and I have written a tool to be able to create pdf estimates and invoices for their business.
Before finding your package, I was using a package to create excel file and a print to pdf, it was very painfull.

They have 3 computers , and one is only x86 !! It is why I always publish the tool in X86 (.NET Core 8).
The problem with 2024 versions was not easy to find, because it shows a dll loading problem, and it tooks time to find the X86/X64 solution.
But don't worry and don't loose too much time about this problem, your package is fantastic and my daughter will have to buy a new computer if no solution!

Thanks a lot, sorry for my english, I am french!

from questpdf.

Hi @MarcinZiabek -Are we working on this ? My company is considering buying your library but I found it doesn't support x86.

from questpdf.

It will be nice to keep x86 support, some old computers exist !!

Thanks

from questpdf.

I have already attempted to compile the library with the x86 architecture. It requires a special toolchain and is not straightforward. Therefore, some research may be necessary to make it work. I will do one more try next week.
If anyone decides to share the feedback in this thread, please explain why you need the x86 support and why the x64 is insufficient. It would also be great to learn how you use the library.
Thank you for your patience and collaboration! 😄

Regarding Feedback: Our software e.g. relies on some external devices which only work with x86. Allthough the architecture is outdated it would be a pain to replace the devices, therefore we still run on x86 and would require it's support for QuestPDF.

We have same issue, we are using third party libraries which only works with x86.

from questpdf.

The 2024.3.6 release introduces support for the win-x86 platform. Could you please test if it works for you as expected?

from questpdf.

It worked great on Windows 10 x86.
@MarcinZiabek Thank you very much for the fantastic work.
I love this library!

from questpdf.

from questpdf.

@MarcinZiabek
We have some troubles with the x86 support. It does not seem to be a issue of the library itself but maybe you have some ideas why it fails.
We only have this issue when Debugging in Visual Studio. In Rider everything works.
The error Message is the following:
"A call to the PInvoke function 'QuestPDF!QuestPDF.Skia.SkNativeDependencyCompatibilityChecker+API::check_compatibility_by_calculating_sum' has disturbed the stack balance. The managed PInvoke signature probably does not match the unmanaged target signature. Check whether the calling convention and the parameters of the PInvoke signature match the unmanaged target signature."
Our Configuration is on AnyCPU but the Project specifically Targets Platform x86. For whatever reasons, if i start the .exe directly without debugging in Visual Studio it works fine. Also Debugging works in Rider.
Do you have any idea about this?

Edit: Not sure about it but this problems might be caused by the Calling Convention. There are differences between x86 and x64. It might be necessary to specify the CallingConventionAttribute on the DllImport

from questpdf.