cURL / Mailing Lists / curl-library / Single Mail

curl-library

Question about some platform updates to Windows

From: Myria <myriachan_at_cox.net>
Date: Thu, 24 Oct 2013 03:00:03 -0700

Hi =) I'd like to make some platform updates to the Windows side of things,
and was wondering what the best way to proceed would be.

October 17 had the release of Visual Studio 12, or 2013; it is _MSC_VER
1800. I'd like to make some patches to update curl to support some of the
newer stuff, but there are a few questions I have as to how to do this. The
build scripts are rather confusing and redundant, so I might mess something
up.

I noticed that Windows does not define HAVE_GMTIME_R or HAVE_LOCALTIME_R.
It is true that Visual Studio's C runtime library doesn't have gmtime_r, but
it has a somewhat-equivalent API, gmtime_s. gmtime_s's prototype is
different, reversing the order of the two parameters and returning an errno
error code instead of the tm* parameter. (gmtime_s took its reentrancy more
seriously than gmtime_r, and doesn't modify the thread-local variable
errno.) The same applies to localtime_r existing in Visual Studio as
localtime_s.

The problem is that this is specific to Visual Studio. It was added in
Visual Studio 2005's runtime library, so I don't think mingw can support
it...? I don't have much mingw experience. Should separate a HAVE_GMTIME_S
macro be added, or should HAVE_GMTIME_R be defined, with a static __inline
thunk added to implement gmtime_r in terms of gmtime_s, and likewise
localtime_r as localtime_s? Either way, how does this affect config-win32.h
and WindowsCache.cmake?

I'd like to fix up the curl library to support building curl/libcurl for
jailbroken Windows RT systems. It's really as simple as fixing any
assumptions about being x86, then compiling targeting ARM. A jailbroken
Windows RT system is effectively the same as an ARM port of Windows 8.0 or
8.1 – the APIs all work the same way. This sounds like it'd mostly be
changes to config-win32.h and some makefiles, but again I'm not sure how I'd
end up affecting the build process because it's rather redundant and
convoluted. I can't really figure out the difference between
lib/Makefile.vc* and winbuild/Makefile.vc*, for example.

Finally, I'd like to add support for the security linker flags when building
with Visual Studio. When building in 2005 and higher, add /NXCOMPAT. In
2008 and later, add /DYNAMICBASE. In 2012 or later, on x86-64 (more
accurately, Win64, of which x86-64 is the only in 2012+), add
/HIGHENTROPYVA. /SAFESEH would be nice, but that actually only is a
validation flag, and depends on whether the other libraries (zlib, openssl,
libssh2) were compiled with sufficiently-new compilers and assemblers.

To be a good Windows citizen, curl should use /LARGEADDRESSAWARE (setting it
on libcurl also is OK but has no effect), and libcurl should use /MANIFEST
and run the manifest tool with ;2 instead of ;1 like curl uses.

I'm just thinking of the ways the Windows support could be modernized. =^-^=

Melissa

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-10-24