Ug. Got the dynamic load to work, but the function call still isn't
working, and I suspect it might be an issue with the interaction with
the standard cpp library (which I may not be able to work around).
Basically, I have this call (using my previous macro):
std::string newKey; // pre-populated to encoded key value
std::string decodedKey;
CryptoPP::StringSource(newKey, true, CPPNew( CryptoPP::HexDecoder )
( CPPNew( CryptoPP::StringSinkTemplate<std::string> )(decodedKey)));
This is failing with a memory error, but I think it's related to
std::string, because I can use my CPPNew macro to allocate an
arbitrary class now, and it's working. I'm starting to think the
wrapping the whole thing behind a DLL boundary (which is dynamically
loaded and dynamically linked) might be the only tenable solution. =/
On Aug 23, 5:21 pm, Nick42 <[EMAIL PROTECTED]> wrote:
> Hard to construct a snippet by stripping out enough stuff, but I'll
> post the basics of what I have. I'm using VS 8.0, Win32 app with MFC
> (static link).
>
> Basically, I have this class (modify macro for your favorite singleton
> type, or convert to static members as appropriate):
>
> DECLARE_SINGLETON_CLASS( CCryptoppMemoryManagement )
> {
> public:
> CCryptoppMemoryManagement(void);
> virtual ~CCryptoppMemoryManagement(void);
>
> CryptoPP::PNew m_pNew;
> CryptoPP::PDelete m_pDelete;
> CryptoPP::PSetNewHandler m_pSetNewHandler;
>
> };
>
> I'm trying to define the global function SetNewAndDeleteFromCryptoPP
> such that I can populate the member variables of this class, and then
> I can use them when doing any allocations which cross the DLL
> boundary, probably using placement new (which I did get working after
> my last post), along the lines of:
>
> #define CPPNew( CClassType ) new
> ( CCryptoppMemoryManagement::GetInstance().m_pNew( sizeof( CClassType ) ) )
> CClassType
>
> With usage as:
>
> CClassType* pInstance = CPPNew( CClassType )( constructor_arguments );
>
> I think this should work, given the global function sets the pointers
> in the singleton correctly.
>
> This is my global function definition:
>
> void SetNewAndDeleteFromCryptoPP( CryptoPP::PNew pNew,
> CryptoPP::PDelete pDelete, CryptoPP::PSetNewHandler pSetNewHandler )
> {
> TRACE( _T("SetNewAndDeleteFromCryptoPP called\n") );
>
> CCryptoppMemoryManagement::GetInstance().m_pNew = pNew;
> CCryptoppMemoryManagement::GetInstance().m_pDelete = pDelete;
> CCryptoppMemoryManagement::GetInstance().m_pSetNewHandler =
> pSetNewHandler;
>
> }
>
> As far as I can tell, the function is never called (symbols are not
> even loaded for it if it's in a library; I tried defining the function
> both on the wrapper static library and in the main exe code, neither
> worked).
>
> Is this enough to see what I'm doing? It would take a lot of work to
> strip it down to a skeleton project, just due to common macros and
> such, so hopefully this is understandable.
>
> Thanks for looking into it. :)
>
> PS: I have another idea I'm going to try (I don't like to give up,
> despite frustration)... if I can manually extract the pointers for the
> cryptopp.dll 's memory management functions using the same methods in
> dll.cpp, I can probably alleviate the need to have a callback function
> in the global space which isn't being called, and just populate on
> first hit of my singleton code (at which point the DLL will be
> loaded). I'll let you know if it works.
>
> - Nick
>
> On Aug 23, 4:15 pm, "Jeffrey Walton" <[EMAIL PROTECTED]> wrote:
>
> > Hi Nick,
>
> > > So after fighting with this for a few days, I think I'm going to give
> > > up, and tell our customers we can't give them a version of our apps
> > > which uses the FIPS certified version of cryptopp.
>
> > Perhaps, but perhaps not.
>
> > Send over a minimum project skeleton which exhibits the behavior. I
> > will get it working for you this weekend. It is time to try out my
> > past speculations.
>
> > What Development Environment? My test lab (at the house) has the
> > following available:
>
> > VC++ 6.0 Enterprise
> > Visual Studio 7.0 (no 7.1)
> > Visual Studio 8.0
>
> > Keep in mind I am a System Administrator and Security Engineer. I
> > program for fun (and the challenge). Money is not in the picture yet
> > :)
>
> > With that said, I should be able to make headway on it. And I have
> > others who are programming resources I can call on when I hit a brick
> > wall.
>
> > It is something that needs to be added to 'Compiling and Integrating
> > Crypto++ into the Microsoft Visual C++ Environment'
> > (http://www.codeproject.com/tips/CryptoPPIntegration.asp). I just
> > haven't had the time to set up test cases to find the work around.
>
> > Jeff
> > noloader, gmail account
>
> > On 8/23/07, Nick42 <[EMAIL PROTECTED]> wrote:
>
> > > So after fighting with this for a few days, I think I'm going to give
> > > up, and tell our customers we can't give them a version of our apps
> > > which uses the FIPS certified version of cryptopp.
>
> > > The option 2 solution doesn't work, because the function never gets
> > > called. I have no idea if this is a loading order issue, or a naming/
> > > calling convention issue, or something else; there is no working
> > > example I can find of this method (the dll.cpp shows the calling usage
> > > from within the DLL, but not how to define it within an application).
>
> > > Even if I could get that working, I can't explicitly define new/delete
> > > without dynamically linking MFC, because of conflicts. I also can't
> > > figure out the syntax to use placement new to use the allocator from
> > > cryptopp to create object to pass to the DLL. Basically, it appears to
> > > be unusable without static linking everything, or dynamic linking
> > > everything.
>
> > > On Aug 23, 11:17 am, "Jeffrey Walton" <[EMAIL PROTECTED]> wrote:
> > > > Hi Nick,
>
> > > > > (unless I'm missing something).
>
> > > > I believe you have not found the correct hoop to jump through. Perhaps
> > > > create a second project which uses Crypto++ as a static Dll that
> > > > imports the missing functions. Create this project as a DLL, and place
> > > > the header in it's own namespace. I've never tried it myself at this
> > > > point, but I've pondered the solution in the past.
>
> > > > > There doesn't seem to be a way to make this
> > > > > work without dynamically linking
>
> > > > I beleive you are correct... Mixing and matching (though required) is
> > > > diffcult to do.
>
> > > > In the past I had a Document/View architecture. The Doc/View
> > > > architecture used an iterator to to enumerate docs. However, becuse
> > > > STL/Crypto++ had the same named iterators, all hell broke loose.
>
> > > > In the end, I used a linker switch (NODEFAULTLIB) to ease the pain.
> > > > However, I would get obscure errors every now and again. For example,
> > > > If the EXE were copied to a Network drive and run from the location, a
> > > > Date/Time control would not initialize properly and crash the
> > > > application.
> > > > Seehttp://groups.google.com/group/microsoft.public.vc.mfc/browse_thread/...
>
> > > > Sorry I could not be of more help.
>
> > > > Jeff
>
> > > > On 8/23/07, Nick42 <[EMAIL PROTECTED]> wrote:
>
> > > > > This doesn't appear to work if I'm linking to the MFC library
> > > > > statically also, as I get conflicts with the new and delete symbols
> > > > > already defined (in this case, within the MFC library). There doesn't
> > > > > seem to be a way to make this work without dynamically linking
> > > > > everything (unless I'm missing something).
>
> > > > > - Nick
>
> > > > > On Aug 22, 7:05 pm, "Wei Dai" <[EMAIL PROTECTED]> wrote:
> > > > > > If you're using a static C++ runtime library, then you have to use
> > > > > > "method
> > > > > > 2" as the Readme.txt says:
>
> > > > > > 2. Crypto++ can tell the calling application what heap to use.
> > > > > > This method
> > > > > > is required when the calling application uses a statically
> > > > > > linked C++
> > > > > > Run
> > > > > > Time Library. (Method 1 does not work in this case because the
> > > > > > Crypto++
> > > > > > DLL
> > > > > > is initialized before the calling application's heap is
> > > > > > initialized.)
>
> > > > > > This means you need to use "SetNewAndDeleteFromCryptoPP", which has
> > > > > > an
> > > > > > example in dlltest.cpp.
>
> > > > > > ----- Original Message -----
> > > > > > From: "Nick42" <[EMAIL PROTECTED]>
> > > > > > To: "Crypto++ Users" <[EMAIL PROTECTED]>
> > > > > > Sent: Wednesday, August 22, 2007 4:30 PM
> > > > > > Subject: Re: Question about FIPS dll usage and util functions
>
> > > > > > > Thanks for the response... I saw this after I posted, and got it
> > > > > > > working (well, linking at least), but I have a followup question:
>
> > > > > > > I have not been able to get the memory management working. I am
> > > > > > > statically linking the C runtime, and have tried defining
> > > > > > > GetNewAndDeleteForCryptoPP, but I'm not sure how it needs to be
> > > > > > > defined such that cryptopp can pick it up, and I can't find any
> > > > > > > example of how to define it in the cryptest project. I would
> > > > > > > prefer to
> > > > > > > tell cryptopp the new/delete functions to use, in case in the
> > > > > > > future I
> > > > > > > have other libraries linking this way, to prevent conflicts.
>
> > > > > > > Is there example code on how to implement this function
> > > > > > > somewhere, or
> > > > > > > any magic, or something which will not work with how I'm trying
> > > > > > > to use
> > > > > > > it?
>
> > > > > > > Also, as a side note, I get the following error compiling the
> > > > > > > cryptdll
> > > > > > > project from the 5.3 FIPS code with VS2005:
> > > > > > > 2>.\integer.cpp(88) : error C2244:
> > > > > > > 'CryptoPP::AlignedAllocator<T>::allocate' : unable to match
> > > > > > > function
> > > > > > > definition to an existing declaration
> > > > > > > 2> [...]\cryptopp_5_3_fips\include\integer.h(44) : see
> > > > > > > declaration of 'CryptoPP::AlignedAllocator<T>::allocate'
> > > > > > > 2> definition
> > > > > > > 2> 'AllocatorBase<T>::pointer
> > > > > > > CryptoPP::AlignedAllocator<T>::allocate(CryptoPP::AlignedAllocator<T>::size_type,const
> > > > > > > void *)'
> > > > > > > 2> existing declarations
> > > > > > > 2> 'T
> > > > > > > *CryptoPP::AlignedAllocator<T>::allocate(CryptoPP::AlignedAllocator<T>::size_type,const
> > > > > > > void *)'
>
> > > > > > > Not a big deal since I want to use the FIPS certified
> > > > > > > pre-compiled DLL
> > > > > > > anyway, but thought I'd post it in case it's not a known issue.
>
> > > > > > > - Nick
>
> > > > > > > On Aug 20, 5:07 pm, "Wei Dai" <[EMAIL PROTECTED]> wrote:
> > > > > > >> You can build a static library that contains only code that are
> > > > > > >> not in
> > > > > > >> the
> > > > > > >> DLL, by building the "DLL-Import Debug" or "DLL-Import Release"
> > > > > > >> configuration instead of the "Debug" or "Release" configuration.
> > > > > > >> Then you
> > > > > > >> can link your application with both the DLL and the static
> > > > > > >> library.
>
> > > > > > >> ----- Original Message -----
> > > > > > >> From: "Nick42" <[EMAIL PROTECTED]>
> > > > > > >> To: "Crypto++ Users" <[EMAIL PROTECTED]>
> > > > > > >> Sent: Monday, August 20, 2007 4:28 PM
> > > > > > >> Subject:
>
> ...
>
> read more >>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
