[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: win32 Visual Studio 2005 project for gsasl
From: |
Simon Josefsson |
Subject: |
Re: win32 Visual Studio 2005 project for gsasl |
Date: |
Fri, 11 Apr 2008 09:31:10 +0200 |
User-agent: |
Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) |
Adam Strzelecki <address@hidden> writes:
> Hello,
Hi Adam! I'm now slowly catching up on this. I'm starting by cc'ing
the list with an answer to your message which ended up in my private
inbox..
>> Thanks, Adam! I'm forwarding this to the gsasl list so that others
>> can
>> see it. I think we'll eventually end up with a number of win32
>> packages:
>
> Well I found many of them simply not working (unless using libgcrypt)
> due /dev/random that didn't exist on Windows.
>
> Also native MSVC projects that link against Microsoft CL (C++
> compiler) not GCC enable Windows developers using MSVC debugger also
> debug LIBIDN or GSASL side-libraries. GDB format and MCVC PDB formats
> are not compatible.
Ok.
>>> Yeah, that wasn't the cutest thing I've done ;) Attached patches use
>>> CryptGenRandom now, thanks for the tip.
>>> Patches were tested on Windows XP and Windows 2003.
>> Thanks, this is better. I think we should note in the documentation
>> that the Windows PRNG is known to have some known flaws.
>
> On one hand all of Win 2xxx versions went successful trough EAL4+ but
> indeed I've read about some reports that Windows 2000 version has some
> flaws. This may be noted somewhere in the documentation of gsasl, that
> using it on Windows 2000 with no libgcrypt may cause some security
> risk.
Yup. I've added a note in the GNU SASL manual.
>> There is a *.def file in your patch, isn't it possible to generate it?
>> I didn't see one in your libidn patch. When I build the mingw
>> build, it
>> will generate a *.def file too. I'm worried I have to manually have
>> to
>> maintain the file.
>
> Well, I tried to be as minimal with the changes as possible. If you
> really want to say bye bye to *.def you need to use Windows way of
> exporting functions & variables to DLL. In libidn's win32 Perl script
> I exactly replace all exports with LIBIDN_API, and for gsasl we would
> need to do the same:
>
> /* GSASL Windows DLL */
> #ifndef GSASL_API
> # if defined(_WIN32) && !defined(GSASL_STATIC)
> # ifdef GSASL_EXPORTS
> # define GSASL_API __declspec(dllexport)
> # else /* GSASL_EXPORTS */
> # define GSASL_API __declspec(dllimport)
> # endif /* GSASL_EXPORTS */
> # else /* _WIN32 && !GSASL_STATIC */
> # define GSASL_API extern
> # endif /* _WIN32 && !GSASL_STATIC */
> #endif /* GSASL_API */
>
> And then use "GSASL_API" in all official headers instead of "export"
> for functions and variables. This is only related to those that should
> be exported to DLL. On GCC ELF (Linux, Mac, etc.) all "export" are
> exported, on Windows you need to explicitly mark it with
> __declspec(dllexport) or use *.def files, or you won't get anything
> into DLL.
> Also when you will be using the DLL you need to use
> __declspec(dllimport).
>
> So if you want I can prepare LIBIDN and GSASL patches that define this
> inside the sources, not with external tricks.
Thanks for explaining. Maintaining the *.def file manually will be a
problem, so I'd appreciate if you could prepare a patch that adds a
GSASL_API symbol. I'd prefer to keep the 'extern' markers in the code
though, so on non-Windows systems I would want that GSASL_API evaluates
to the empty string. That isn't a problem for Windows, right?
Note that I've applied parts of your patches to git, so it is easiest if
you make the patch apply to the current git head.
/Simon
- Re: win32 Visual Studio 2005 project for gsasl,
Simon Josefsson <=