https://issues.apache.org/bugzilla/show_bug.cgi?id=44386
--- Comment #11 from David Bennion <[EMAIL PROTECTED]> 2008-08-22 06:54:26 PST --- >However, it is not like we can't represent all the currently active event >>sources in 32-bits. What we could do is return the HANDLE in the 32-bit >>implementation and maintain a small (maybe 256 entry) array of HANDLEs in the >>64-bit versions and return the index into the array instead of the direct >>handle. That would allow pre-1.2.16's log4j's to work on 64-bit JDK's as >long >as the NTEventLogAppender.dll on the path was a 64-bit DLL. If you >installed >the 32-bit NTEventLogAppender.dll in \Windows\SysWOW64 and the >64-bit in >\Windows\System32 (where 64 bit DLL's live despite the name), things might >>just magically work for older versions of log4j. log4j 1.2.16 would be >needed >if you wanted to have a 32-bit dll and a 64-bit dll >(NTEventLogAppender+ >os.arch + >.dll) both on the path. I'll give that a shot tomorrow. I could see maintaining an array of HANDLEs. Then the new dll returns an offset into the array instead of a pointer and the java side is none the wiser. That would work and you'd likely never have a problem. Now I can see why you are so concerned about the signature of the Dll's! It is because you are putting the DLL's in Windows\System32. That's not something that I ever do. I just leave them in the application path (with jars) and set java.library.path to load them. I would keep the different names for different arches though and based on the arch try to load the appropriate one. That way people like me can simply stick all the .dll's in the same directory as their application. Then their single application installation can switched JVM's in place. For instance, the user can come and choose a different JVM for my application and could go to a 64 bit from right where it is installed. My feeling is that my java based installation should be able to just chuck all the .dll's on there and it should just "work" regardless of which JVM they are using. I as a java application developer shouldn't have to put any energy into tracking whether I am set up for the 64 bit one or not. Just slap them all on at once and go. I think this model describes what at least a high percentage of other users will do as well. It is generally considered distasteful to make dll additions to the system directory. Microsoft wanted everyone to get away from that after so many applications experienced "dll hell" (which is what your signature changing concern is based on). I realize that not everyone plays by those rules. >I can build and test an AMD64 DLL and should be able to build an IA64, but I >>won't be able to test it. If someone is willing to test the IA64 build, I'd >>be willing to include it in the release, but I would not feel good about >>including it untested. I agree. I know there was a customer of ours that asked about Windows on Itanium, but by and large I think this is basically a dead platform. I don't feel terribly bad about just leaving the code in a state where it builds on this platform. I think there are a few people out there who have Windows on Itanium. Maybe you could keep the IA64 .dll in an "already built" state and put a notation in the doc that if you are a developer and you wanted to support that platform you can download the IA64 .dll from such and such a link and try it to see if it works. All the best. David. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
