GNOME Bugzilla – Bug 736458
Windows XP's msvcrt.dll doesn't offer function rand_s
Last modified: 2015-03-15 01:53:22 UTC
http://docs.gstreamer.com/display/GstSDK/Installing+on+Windows says "Furthermore, GStreamer itself is built using a “basic” C runtime which comes in every Windows system since Windows XP, and is named MSVCRT.DLL.", but the libglib-2.0-0.dll that comes with http://gstreamer.freedesktop.org/data/pkg/windows/1.4.1/gstreamer-1.0-x86-1.4.1.msi does depend on non-basic C runtime. The original MSVCRT.DLL that Windows XP offers doesn't have a function named rand_s libglib-2.0-0.dll needs. It would be nice if it's possible to remove this dependency, so the users don't have to download another MSVCRT.DLL. Thanks a lot.
Created attachment 285891 [details] The screenshot of Dependency Walker that shows glib needs function rand_s
The docs on MSDN say it's available since Visual Studio 2005, which is newer than Windows XP (2001).
Does gstreamer still care about Windows XP? I think I'm about to stop caring...
We're going to drop XP support with 1.6.0. Maybe for the current stable GLib branch we can just add an #ifdef checking the Windows target version, and fall back to rand() (*shudder*)... and next stable GLib branch just drops all the XP things? :)
http://en.wikipedia.org/wiki/Usage_share_of_operating_systems XP still has 23.89% desktop operating system market share. I think 23.89% does matter when planning to develop a commercial application. http://www.gtk.org/download/win32.php The official release of pre-built glib doesn't use function rand_s, so it works perfectly on XP. It would be nice if it's possible for gstreamer develop team to consider using that pre-built glib on Windows, instead of wasting your precious time to build a specific glib that may cause some inconvenience. :)
The official binary is rather old and does not use rand_s() yet apparently. The latest stable release series is 2.40, the binaries use 2.34. That's 1.5-2 years old now and for GStreamer we make use of some features and bugfixes of newer GLib... especially on Windows. Anyway, let me prepare a patch for this issue. Also independent of this people should just update their Windows... XP is no longer supported by Microsoft and a security nightmare in any case... and by supporting XP we can't use features of newer Windows versions for all the sane people who already use newer versions. (like rand_s() which has security implications too!).
Created attachment 286131 [details] [review] grand: Only use rand_s() when targetting Visual Studio >= 2005 It did not exist before. Fall back to the current time plus process id on older targets. This makes GLib work again on Windows XP.
(In reply to comment #7) > Created an attachment (id=286131) [details] [review] > grand: Only use rand_s() when targetting Visual Studio >= 2005 > > It did not exist before. Fall back to the current time plus > process id on older targets. This makes GLib work again on > Windows XP. Thanks a lot for the reply and the patch. :) A header file needs to be included, and also, in XP's native msvcrt.dll the function is not named getpid but _getpid. Please see the attached patch below. I've tested it and successfully built glib-2.41.4 on my XP. It works good. After replacing the glib that came with the official GStreamer binary, now it's possible to run my gst application on XP. However, 4 plugins, libgstassrender.dll, libgstcairo.dll, libgstpango.dll and libgstrsvg.dll still complain function _mktemp_s is missing. http://msdn.microsoft.com/en-us/library/t8ex5e91%28v=vs.80%29.aspx Maybe I'll tried to fix it when I have spare time, but it's painfully slow building things with MinGW especially on virtual machine. Thanks a gain. You guys are amazing! I really appreciate the projects. :)
Created attachment 286156 [details] [review] for XP
Can you file a bug against GStreamer about the other issues?
Review of attachment 286156 [details] [review]: ::: glib/grand.c.orig @@ +277,3 @@ + seed[0] = now.tv_sec; + seed[1] = now.tv_usec; + seed[2] = _getpid (); There's other code in glib that directly uses getpid(), so maybe only the process.h include is needed?
Created attachment 286159 [details] [review] grand: Only use rand_s() when targetting Visual Studio >= 2005 It did not exist before. Fall back to the current time plus process id on older targets. This makes GLib work again on Windows XP.
FWIW, we will include that patch in the next binary release of GStreamer (1.4.2, or if you build GStreamer yourself with cerbero from the 1.4 or master branch).
I'm happy to take this patch upstream with one minor tweak: addition of: #warning Using insecure seed for random number generation because of missing rand_s() in Windows XP Thoughts?
Sounds sensible, I'll push it with that change then
commit bb6a77afa328f16568a41b26de75f255dcfc9daf Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Sep 13 16:31:03 2014 +0300 grand: Only use rand_s() when targetting Visual Studio >= 2005 It did not exist before. Fall back to the current time plus process id on older targets. This makes GLib work again on Windows XP. https://bugzilla.gnome.org/show_bug.cgi?id=736458
This does not look correct. A new enough mingw64 supports rand_s and it should be used in that case
mingw supports it, yes... but you'll have to install a newer msvcrt.dll on Windows XP to be able to use the result. That's what the _MSC_VER check is for, you explicitly have to target a newer version if you want to use new APIs.
First, I'm on Win2003 x64 as opposed to WinXP, but should be similar. I have installed MSVS redistributables 2005, 2008, 2010, 2012 and 2013, and I can see no rand_s in msvcrt.dll no matter what I try. There are, however, another dlls like msvcr100.dll from MSVS 2010, msvcr110.dll and msvcr120.dll, and all of them contain rand_s. It looks like a mistake to look for rand_s in msvcrt.dll. One should check for msvcr120.dll, msvcr110.dll or msvcr100.dll existence, dynamically link best of them and use its API; otherwise fallback to rand() in msvcrt.dll. I had solved my problem by nulling out "_s" in rand_s in glib*.dll import table. Copying msvcr120.dll and renaming to msvcrt.dll might probably also work. Have not checked.
just fyi: we plan on ending support for Windows XP, Windows Vista, and Windows Server 2003 with the next release of GLib, so this bug is extremely unlikely to receive any further attention.