Problem registering on W2K3 64-bit
Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=735
Printed Date: 06 May 25 at 7:22AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com
Topic: Problem registering on W2K3 64-bit
Posted By: Jim Sullivan
Subject: Problem registering on W2K3 64-bit
Date Posted: 29 May 07 at 2:49PM
|
I'm using the library in my asp.net application and I've installed on several of my customers servers using:
regsvr32 ised.dll
I have a customer that has Windows 2003 server 64-bit, and the library won't register. I get:
LoadLibrary("ised.dll") failed - The specified module could not be found
Is this a problem with 64-bit, with permission, path, anything?
|
Replies:
Posted By: Ingo
Date Posted: 29 May 07 at 3:00PM
|
Hi Jim! A 64-bit-machine doesn't work with 32-bit-dlls. That's it :-( The other way round it's the same 32-bit-machines doesn't work with 64-bit-dlls ;-) You should use again the dcu-versions (5.21) to compile your own dll. This is the point where all users here can see that a single dll without source can be a dead-end street. The msdn-library offers less hope in this case: On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Additionally, a 32-bit process cannot load a 64-bit DLL. However, 64-bit Windows supports remote procedure calls (RPC) between 64-bit and 32-bit processes (both on the same computer and across computers). On 64-bit Windows, an out-of-process 32-bit COM server can communicate with a 64-bit client, and an out-of-process 64-bit COM server can communicate with a 32-bit client. Therefore, if you have a 32-bit DLL that is not COM-aware, you can wrap it in an out-of-process COM server and use COM to marshal calls to and from a 64-bit process. When winxp jumped on the market there were similar problems with old win95-apps ... in this case there was a compatibilty mode. I don't know if a 64-bit-win offers something like that... Best regards, Ingo |
Posted By: Jim Sullivan
Date Posted: 29 May 07 at 3:12PM
|
Oh. I searched and found some posts that said that it worked, so I figured I was doing something wrong.
I have no idea how to compile my own dll, I've just been using the library as-is.
|
Posted By: Ingo
Date Posted: 29 May 07 at 3:24PM
|
... so you should go back to the 5.21-source or perhaps Marian can upload a 64-bit-version of his library here. Ooooh... i see my information is from august 2005 ... perhaps there's a solution now for this behavior. Like it's in my msdn-note: With visual studio 2005 it's very easy building an external com-server (with the ATL). Additionally you'll need a proxy-dll (that's easy, too). The created com-object offers an easy interface from which you can call your (old) dll. I don't have any practices in this case - i've googled this informations ;-) Best regards, Ingo |
Posted By: marian_pascalau
Date Posted: 29 May 07 at 5:03PM
|
Hi there,
If someone wants to use QuickPDF and com it is enough to register the library and add reference with application Wizard (in C++ with Smart Pointers I believe (never done that before)).
To use it as COM+ server (out of proc server) it should be enough to create a new COM+ Application set the application to run as OutOfProc server and add the QuickPDF library inside (but I cannot test cause I have no 64Bit Windows OS). I believe that this is the only way possible to make a clear marshaling between 64 and 32 bits DLL.
To compile this library as 64bit dll is not possible. As far I remember there is no 64bit compiler for Delphi available.
Best regards, Marian
|
Posted By: bbit
Date Posted: 16 Jul 07 at 4:26PM
|
Hi there, I have the same Problem with the 64 Windows. Are there any solutions right now?? Greets bbits |
Posted By: Ingo
Date Posted: 17 Jul 07 at 1:29AM
|
Hi! The posting from Marian is still the last "solution" in this case. Your solution can be buying the source license from iSED, getting the 5.21-sources here and compiling your own dll. Best regards, Ingo |
Posted By: cpagani
Date Posted: 24 Aug 07 at 3:54PM
|
I am using the 32bit DLL version quite happily on Server 2003 x64. I think as long as the calling program is 32 bits there should be no problem executing on 64 bit OS. However, I suspect 64 bit EXE will not be able to call 32 bit DLL.
Regards - Carlo
|
Posted By: Michel_K17
Date Posted: 25 Aug 07 at 10:06AM
|
Carlo, You are absolutely correct. For example, with my program (PDF reDirect), I had to re-compile it into a 64 bit library because it was being called from Windows's Print Spooler which is now 64 bit. Since an in-process DLL is loaded into the calling program's memory space, it must be in the same format. However, PDF reDirect (which also uses QuickPDF) is started as a separate EXE, it can stay and work as a 32 bit app, and therefore, using QuickPDF as a 32 bit DLL is perfectly acceptable. This is where the transition from 32 to 64 bit is such a happier one than the 16 to 32 bit path: the "old" 32 bit apps run fine (and fast) on the 64 bit CPUs and OSs. Codegear recently released an update to Delphi, and I was disappointed to see that it did not include a 64 bit compiler which is long overdue. In fact, they called it: Delphi 2007 for Win32 . According to their roadmap, 64 bit support will become available for another 1.5 years (Winter 2008).  Back to the original question: I have had no problem using regsvr32 on 64 bit versions of Windows. I would have him check the obvious like missing quotes in the command line for example. Cheers! Michel ------------- Michel |
Posted By: Jim Sullivan
Date Posted: 28 Aug 07 at 10:29AM
| My application is ASP.NET, so it runs under IIS. I found out that IIS can run in 32-bit mode so I switched over to that, but I'm not happy about that as a permanent solution. It seems to be the only thing I can do, though. |
Posted By: marian_pascalau
Date Posted: 31 Aug 07 at 6:52AM
|
Hi Jim,
I have mentioned previosly that in Win64 there should be possible to use COM+ applications together with QuickPDF. I am sorry cause I don't own a copy of Win64 Version of Windows to test this king of application myself.
The idea is to create a new COM+ Application and add QuickPDF inside of it. Then set this application to run as OutOfProcess Server and try using QuickPDF trough COM+Interop.
From what I know this should be the solution for you.
Best regards, Marian
|
Posted By: Jim Sullivan
Date Posted: 31 Aug 07 at 10:56PM
| Thanks. I'll see if I can make that work. |