64 bit driver is failing in StartDoc

If you are a C/C++/C# developer and have any questions about using our products from your application here is the place to post them.
Post Reply
Andy Bantly
Posts: 7
Joined: Fri Aug 05 2005
Contact:

64 bit driver is failing in StartDoc

Post by Andy Bantly »

Has anyone else used the PDF programmatically from a 64 bit system? I have been developing support code for the PDF printer driver for a number of years and so I consider myself an expert in the API. Recently I wrote a sample program for the 32 bit system and submitted it to AMYUni to demonstrate a bug in printing a GDI object with a texturized region. This same program fails miserably on a 64bit Windows XP 2003 in the StartDoc Win32 API. Actually, it never returns from StartDoc and the printer job has to be cancelled. Even then the output file name is locked at some low level in the system.
Joan
Amyuni Team
Posts: 2799
Joined: Wed Sep 11 2002
Contact:

Post by Joan »

As you are an expert in the API this might sound a silly question but just for the sake of double checking:
Are you using the 64-bits dll under 64-bits or your are using the same dlls you use for 32-bits?
Andy Bantly
Posts: 7
Joined: Fri Aug 05 2005
Contact:

64 bit driver problem

Post by Andy Bantly »

Joan, In my original post I said it was a 32 program running on a 64 bit system. I should have added that on the 64 bit system I was using the 64 bit drivers. I assumed it was using the 64 bit drivers because I am relying on the AMYUni install software to automatically register the proper DLL for use.

I talked to David Dube on the telephone and we discovered two problems with the driver. Problem number 1 is that you have to configure the printer to print to COM1 instead of LPT1. I feel like that is a bad solution to the problem and one that is not communicatable to the end user. There should be an installation switch that can configure the printer to use COM1.

I submitted a program to AMYUni that demonstrates the problem. One of my main complaints about AMYUni technical support is that they always think the enduser uses the PDF printer as a normal printer. We struggled for over 6 months to get AMYUni to take ownership of a serious flaw in the driver because they kept on with the ruse that if it worked from the file->print menu then it must work from the developers code. Finally we resorted to sending source code to demonstrate the problem. It is not fair for AMYUni to put 100% of the burden on its end users to proove bugs. AMYUni really needs to step up and be more proactive about bugs discovered by end users.

Secondly, changing to COM1 doesn't work in the recently patched 2.51d-Build3 release. It does work in version 3.0. Version 3.0 fails miserably when GDI operations that use texturized fills are executed. These GDI operations cause access violations deep enough in the PDF sub-system that the PDF driver is not useable again until it is unloaded from memory and reinitialized.
Post Reply