crypt32.dll MIPS

Hello All,

I was curious if anyone ran into a crypt32.dll? I am trying to get nPOP to work on my PenCentra and it has the following in the DllMain:

if ((crypt32_lib = LoadLibrary(TEXT("crypt32.dll")) != NULL) {
...

My Pencentra HPC 2000 does not have a crypt32.dll in \Windows. A quick web search also didn't give me much to go on. Anyone know of these certificate stores in MIPS Windows CE land?

Best Wishes,

smb_gaiden

ask npopUK developer

- who is a member here (gjcoram).

Are you sure you need crypt32.dll? I know on my HPC, I un-check "verify server certificates" which may be what the crypt32 routines are used for.

I assume you have npopssl.dll and the OpenSSL DLLs (libeay32.dll ssleay32.dll) for MIPS.

Thanks, it looks like it works well. Thank you again everyone for the help!

Sir,

If I can bother once more, may I know how you successfully built the SSL libraries? I downloaded from here:
www.it.uc3m.es/pervasive/wce_lite_compat

If that link doesn't show through it is the wce_lite_compat area. I downloaded the SSL modified zip from there, following the instructions, and building for MIPS on CE and it is giving trivial errors such as abort undefined. I thought his package already did the mods for Windows CE, but I guess there's additional legwork. Curious if you had an alternate source for the SSL build for WCE211 MIPS? Appreciate any leads or advice you may offer!

Regards,
smb_gaiden

Slight update and more info in case anyone is having similar issues ^^

I was able to compile openssl-0.9.8a and openssl-0.9.8b in WCE300 and WCE211 MIPS. However, unfortunately they did not work. My test case was, replacement of the working binaries (ssleay32 and libeay32) that I got off the website referenced above.

I had to modify cedll.mak in both cases, so the wcecompat would be listed first. Also I had to modify some stuff in wcecompat according to someone's message about missing strtol and such. I had to modify the perl running script to prevent build of idea and some other such and so forth which wasn't told in the readme. The mods to the makefile were to point the path to the wcecompat stuff correctly in the link commands, since they didn't use the symbol defined early on in the makefile. Also, I had ot modify the include path for the headers to be listed first, so it would not mishmash the windows headers with the wcecompat ones. Lastly, I had to add the environment variable $(INCLUDE) in the includes for the C Flags.

I was happy to compile in all these configurations, but when I put it onto the device for testing an otherwise known configuration they did not work and hung at the first SSL Phase. This was notifced under nPOP 1.09 MIPS after replacing DLLs that could get into my gmail and unchecking the verify certs bawx. So basically, I can build DLL that will not do SSL exchange properly.

The goal of this exercise is that I am trying to incorporate SSL into an app I am writing(and would release details as I progress). At first I tried to use the known working libraries (ssleay and libeay) and then wrap my code for SSL around them, but noticed a strange event on my pencentra. I would loadlibrary and init astructure with fn pointers and call the SSL_connect function. It would not return, however it also did not freeze blocking. Some exception must occur within the library and the pencentra must recover from it and start the stack from the beginning. I know this because I have a print before the call and in the verifycb that are shown. The verifycb is the last to be shown even though there are prints in the call frame later than this. I have a menu which also issues a print, so I am still able to click that after seeing the verifycb and then see the text change and the app being otherwise responsive. Strange!

I am resorted to prints, because my environment somehow does not let me attach to pencentra for debug with embedded vc. I was hoping to build working SSL libraries, so I could extend my prints into the library to see where it was blowing up and figure out if it is related to a stack overflow, misaligned data, or some strange longjmp or other abort.

Anyone who can successfully build the wcecompat or wcecompatlite with nPOP into a MIPS functioning version, I'd appreciate a same version working build that I can do binary diff on or having your guidance on the clmips and link commands for comparisons. Strongly appreciate it!

I used the source from http://openssl.org/source/ Note that openssl-0.9.8g.tar.gz is available. I also got the wcecompat stuff from essemer.au (?), rather than any wce_lite

Your comments on the modifications necessary sound very familiar. I think the "npopssl" directory of the nPOP or nPOPuk source code has some notes on -no-idea and -no-rc5 and perhaps some other flags that remove protocols not necessary for SSL e-mail.

Update:

I spent way too many hours on this and probably popped out a few more grey hairs in doing so, but I have found out the main issue.

Either the Storage Card I am using is broken, the PCMCIA<->CF adapter is broken, or the IR link doesn't have good checksums and/or error correction.


Basically, I was able to get to debugger by adding some registry entries. Thank god for deja news, or google I guess who bought them. I was able to find the registry entries needing to be present in order for eVC to allow on target debug.

Once in the debugger I continued to see impossible things, things such as: jal 0x1070aace turn up invalid instruction. Whereas jal is a valid mips instruction and the address was valid and the instruction at that address was valid as well (in case of prefetch activity).

Then suddenly npop stopped working, which made me suspicious.

I took the storage card to my Hitachi ePlate and it complained about some bad data. I took the storage card to a card reader attached to this laptop, but no complaints. However, when I used hex workshop to binary diff the files (the DLL and my EXE), they had many differences. In binary a difference is pretty harsh and severe. That's where the invalid instruction lived! The invalid instruction didn't show up under debugger since it uses local data.

Next step was copying the files over to the CF card with the PC card reader/writer and then verifying the binary diff was the same. After putting back into the PCMCIA/USB harness I was successful to run my program which was using the SSL Libraries.

This does put a little snag on my debug turnaround time though. I now have to eject the card & PCMCIA adapter, remove CF from adapter, insert to card reader, connect card reader to laptop, removedrive h: on command prompt, insert into PCMCIA adapter, insert PCMCIA adapter to pencentra, establish IR link, then debug. With that limitation I will be writing my parsing code on the PC with small stack in mind and port it over in one event.

Anyone happen to have some advice about figuring out how to solve the badly written files when sent from Active Sync to pencentra on the CF attached to a PCMCIA adapter? Since the CF is read/written flawlessly in Windows it seems it is not the card as a problem.

Activesync doesn't corrupt files - so probably user error, perhaps you accidentally copied an older version.

also I do wonder if you saw gjcoram's post