Andy Polyakov schrieb: >>>> I actually ended up solving it by removing all uses of BIO_new_fp() in >>>> favor of my own custom BIO that I just finished writing earlier this >>>> week. >>> Why not BIO_new_file? >> >> Yeah, I discovered while analyzing the code that using BIO_new_file() >> rather than BIO_new_fp() would disengage applink, however that was not >> an option for me because BIO_new_file() can't open a file whose name >> contains non-ANSI Unicode characters on Windows. I have to open the >> file myself using _wfopen(). > > There was suggestion to fall back to wfopen from a vmware engineer a > while ago, but he couldn't provide patch (not that it would be very > complex) and it was not followed up. Idea must have been something > similar to just committed http://cvs.openssl.org/chngview?cn=19610. why not adding the following to BIO_new_file()?
- BIO interface still uses char * (meaning latin ASCII 0x20..0x7F) - BIO implementation calls UTF8_to_UCS16() on all platforms supporting wfopen or _wfopen - BIO implementation then calls wfopen / _wfopen with this UCS16 value (sometimes known as WCHAR*) - For Win32 and Win32_WinCE the conversion can be done with FormatMessage() API. It's allways available. ... just my 5 cents. The Modem Man ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
