Re: decoding base64 with mmencode often hangs (w32)

I have several emails which have PDF files attached (they are encoded in base64). I've been exploring why "call-process" with "mmencode" doesn't always work (to decode such attachments)--with XEmacs 21.4 (patch 19) "Constant Variable" [Lucid] (i586-pc-win32) of Sat Jan 28 2006 on VSHELTON-PC2 on a box running MS Windows XP Pro. Distilling the problem to its essentials, the following hangs in the case of one particular base64-encoded PDF file: (apply 'call-process "mmencode" "d:\\Temporary\\work\ \base64_coded_07_044" t nil '("-u"))

when evaluated in e.g. the "scratch" buffer ("d:\\Temporary\\work\ \base64_coded_07_044" is the encoded attachment). If the "mmencode" process is terminated with the Windows Task Manager, a partially decoded PDF file is inserted in the "scratch" buffer. In a DOS command window, the following works just fine: mmencode -u -o d:\Temporary\work\trial_07_044_call_process.pdf d: \Temporary\work\base64_coded_07_044 The executable for "mmencode" is the one that came with the XEmacs download. If the same email file is copied to a disk accessible to a Sun computer (running Unix), then using "call-process" and "mmencode" in that case has no difficulty with this same base64-encoded PDF file. On the box running Windows XP Pro, the email folder that contains the email with the problem attachment has other emails with PDF files attached (also base64 encoded), which are successfully decoded with the combination of "call-process" and "mmencode". I'm likely to get a ton of suggestions of how to deal with these email attachments in other ways, but I don't necessarily need such suggestions, since I'm probably familar with most of those other ways of doing things. I'm treating this difficulty as a learning exercise, since I'm likely to learn something if I end up understanding this behaviour. I invite comments.