Problem registering on W2K3 64-bit

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   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?

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
Jim Sullivan Members Profile Find Members Posts Team Player Joined: 10 Nov 05 Location: United States Status: Offline Points: 36	Post Options Post Reply Quote Jim Sullivan Report Post Thanks(0) Quote Reply Topic: Problem registering on W2K3 64-bit 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?

Ingo Members Profile Find Members Posts Moderator Group Joined: 29 Oct 05 Status: Offline Points: 3524	Post Options Post Reply Quote Ingo Report Post Thanks(0) Quote Reply 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 Edited by Ingo - 29 May 07 at 3:07PM

Jim Sullivan Members Profile Find Members Posts Team Player Joined: 10 Nov 05 Location: United States Status: Offline Points: 36	Post Options Post Reply Quote Jim Sullivan Report Post Thanks(0) Quote Reply 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.

Ingo Members Profile Find Members Posts Moderator Group Joined: 29 Oct 05 Status: Offline Points: 3524	Post Options Post Reply Quote Ingo Report Post Thanks(0) Quote Reply 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 Edited by Ingo - 29 May 07 at 3:33PM

marian_pascalau Members Profile Find Members Posts Debenu Quick PDF Library Expert Joined: 28 Mar 06 Location: Germany Status: Offline Points: 278	Post Options Post Reply Quote marian_pascalau Report Post Thanks(0) Quote Reply 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 Edited by marian_pascalau - 18 Jul 07 at 9:26AM

bbit Members Profile Find Members Posts Beginner Joined: 16 Jul 07 Status: Offline Points: 1	Post Options Post Reply Quote bbit Report Post Thanks(0) Quote Reply 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

Ingo Members Profile Find Members Posts Moderator Group Joined: 29 Oct 05 Status: Offline Points: 3524	Post Options Post Reply Quote Ingo Report Post Thanks(0) Quote Reply 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

cpagani Members Profile Find Members Posts Beginner Joined: 24 Aug 07 Location: South Africa Status: Offline Points: 1	Post Options Post Reply Quote cpagani Report Post Thanks(0) Quote Reply 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

Michel_K17 Members Profile Find Members Posts Newbie www.exp-systems.com Joined: 25 Jan 03 Status: Offline Points: 297	Post Options Post Reply Quote Michel_K17 Report Post Thanks(0) Quote Reply 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

Jim Sullivan Members Profile Find Members Posts Team Player Joined: 10 Nov 05 Location: United States Status: Offline Points: 36	Post Options Post Reply Quote Jim Sullivan Report Post Thanks(0) Quote Reply 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.

marian_pascalau Members Profile Find Members Posts Debenu Quick PDF Library Expert Joined: 28 Mar 06 Location: Germany Status: Offline Points: 278	Post Options Post Reply Quote marian_pascalau Report Post Thanks(0) Quote Reply 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

Jim Sullivan Members Profile Find Members Posts Team Player Joined: 10 Nov 05 Location: United States Status: Offline Points: 36	Post Options Post Reply Quote Jim Sullivan Report Post Thanks(0) Quote Reply Posted: 31 Aug 07 at 10:56PM
	Thanks. I'll see if I can make that work.