> In compiling openssl head (tarball from 18 November 2010) for mingw
> under cygwin on a Windows98 machine,
I.e. it's linked with msvcrt.dll, right? It also means that non-vendor
linker is involved...
> I came across a problem in
> crypto/bss_file.c. The code compiles fine on Windows98 and the
> openssl.exe executable works fine on WindowsXP, but fails to work on
> Windows98. The problem shows up during make test when testenc calls the
> executable from the apps directory. It looks like even when linked with
> libunicows, Windows98 can't handle the unicode functions.
I.e. you had to add -lunicows yourself, is it correctly understood? Did
you add it as './Configure mingw -lunicows' or in some other way? If
latter how exactly? Ultimately one wants to examine the actual ld
command line. To do that you can remove apps/openssl.exe, add -v to
CFLAG in Makefile and re-run make. You should find the actual ld command
line somewhere there...
> I can't figure
> out how to make this work on Win98, so I would propose for now adding a
> check of the verion of Windows. Unicode should be supported starting at
> NT4, so this patch should exclude the code on prior systems. If anyone
> has a fix to make the code work on Win98, that would be better.
>
> Error messages when running the compiled openssl.exe on Win98 look like:
>
> 4294277479:error:020013EC:system
> library:fopen:reason(1004):bss_file.c:163:fopen('../apps/openssl.cnf','rb')
> 4294277479:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:168:
> 4294277479:error:0E078002:configuration file routines:DEF_LOAD:system
> lib:conf_def.c:199:
Note fopen:reason(1004). 1004 stands for "invalid flags" and that is
something that MultiByteToWideChar could have returned... Note that the
only recognized error from MultiByteToWideChar is "no unicode
translation". What happens if you "relax" the 'else' condition, e.g. as
following
else /*if (GetLastError()==ERROR_NO_UNICODE_TRANSLATION)*/
I'm not suggesting this a fix, just trying to understand what happens
exactly.
There is a chance that unicows.lib is linked wrong, order in which it's
linked in essential. MSDN even says that one should
/nodefault:user32.dll /nodefault:advapi32.dll /nodefault:kernel32, etc.,
then supply unicows.lib and *then* re-add user32.dll advapi32.dll
kernel32.dll, etc. Non-vendor liker has no notion of /nodefault and
question is how essential is it? It should also be noted that wfopen
resides in msvcrt.dll and the question is if unicows can override the
interface between msvcrt.dll and kernel32.dll? A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
