64 bit driver is failing in StartDoc
-
- Posts: 7
- Joined: Fri Aug 05 2005
- Contact:
64 bit driver is failing in StartDoc
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.
-
- Posts: 7
- Joined: Fri Aug 05 2005
- Contact:
64 bit driver problem
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.
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.