<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Here's a full dependency-walker analysis of all w32 v00-extended Deken:<br>
<br>
<a moz-do-not-send="true" href="http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip">http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip</a><br>
<br>
It's one text file per .dll. We can Grep/Findstring to get results that mainly boils down to:<br>
<br>
msvcr90.dll -> no match.<br>
<br>
msvcr71.dll -> Gem and friends.<br>
<br>
pthread ->  splits to:<br>
<br>
PTHREADGC2.DLL --> some objects.<br>
<br>
PTHREADVC.DLL --> Gem and friends. We must consider Oliver's discoveries on this:<a moz-do-not-send="true" href="https://lists.puredata.info/pipermail/pd-list/2018-12/124086.html"> https://lists.puredata.info/pipermail/pd-list/2018-12/124086.html</a> as there's
 something strange with this file.<br>
<br>
As of "msvcrt.dll" I think Christof had explained everything. My tests deleting this file showed no trouble.<br>
<br>
As of "msvcr90.dll" I will randomly search tomorrow on non Pd-extended-era but it could be the case that is not needed, ...<br>
<br>
Here are the Pd patches I used to generate batch files for dependency-walker and also to serialize opening and closing *-help.pd files:<br>
<a moz-do-not-send="true" href="http://lucarda.com.ar/x/w32DekenPKGdepWalkCHECK1.zip"><br>
http://lucarda.com.ar/x/w32DekenPKGdepWalkCHECK1.zip</a><br>
<br>
@Christof<br>
<br>
</p>
<blockquote type="cite">since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL">https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL</a>)</blockquote>
<br>
<br>
I helped Zack Lee's [ofelia] in the early stage a year ago. Basically there's the normal vc_redist.x86.exe but it does not work on machines that don't receive updates (a minority anyway) but theres is work around shipping a lot of dlls. :)
<p></p>
<p><br>
</p>
<pre class="moz-signature" cols="72">Mensaje telepatico asistido por maquinas.</pre>
<div class="moz-cite-prefix">On 1/22/2019 10:56 PM, Christof Ressi wrote:<br>
</div>
<blockquote type="cite" cite="mid:trinity-3495a1da-5467-4bf3-a94b-339d12125cd5-1548208580472@3c-app-gmx-bs74">
<pre class="moz-quote-pre" wrap="">sorry for spamming, but I think this SO question and the given answers shed some more light on the issue:

<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application">https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application</a>

TL;DR: programs built with VS can either link statically against the MSVCRT or they have to install the appropiate redistributable package.
msvcrt.dll is very old and was declared a private system library which applications should not link against (didn't know that!), but MinGW does anyway. 
You should certainly *not* redistribute msvcrt.dll.

Christof

PS: since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and VCRUNTIME140.DLL (<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL">https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL</a>)



</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr
Von: "Christof Ressi" <a class="moz-txt-link-rfc2396E" href="mailto:christof.ressi@gmx.at"><christof.ressi@gmx.at></a>
An: pd-dev <a class="moz-txt-link-rfc2396E" href="mailto:pd-dev@lists.iem.at"><pd-dev@lists.iem.at></a>
Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

to sum it up: msvcrt.dll is always present on the system anyway, so there's no need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I would consider this a bug.


</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr
Von: "Christof Ressi" <a class="moz-txt-link-rfc2396E" href="mailto:christof.ressi@gmx.at"><christof.ressi@gmx.at></a>
An: "Miller Puckette" <a class="moz-txt-link-rfc2396E" href="mailto:msp@ucsd.edu"><msp@ucsd.edu></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:pd-dev@lists.iem.at">pd-dev@lists.iem.at</a>
Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

@Miller: 

neither Pd nor any externals built with MinGW (basically every external using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) included in pd/bin. externals built with pd-lib-builder don't link against the runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder and everything works fine on several machines. 

apart from that, Pd and pure C externals (no matter if compiled with MinGW or VS) only use C functions from the MSVC runtime and this doesn't cause troubles because memory or handles don't cross module boundaries and data structures are well defined. e.g. you must never malloc in one module and free in another because there might be different runtimes involved. 

C++ externals compiled with MinGW usually link statically against libstdc++ (or ship the DLL) so there are no missing symbols. C++ externals compiled with VS would ideally link statically (see below), but they should *not* rely on a runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or recompile and upload to Deken. so I would say let's get rid of the runtime DLLs in pd/bin.

@IOhannes:

</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 1/22/19 11:36 PM, Miller Puckette wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Would this mean that anyone shipping a binary external for Windows would
have to put it in a separate directory with its own msvcrt.dll/msvcr90.dll?
Sounds like a nightmare to me.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
but i think that's really the only sane way.
unless you can guarantee that Pd and all externals are built with the
same compiler.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
or they can link statically. This is what most VST plugins seem to do. Dependency Walker doesn't show any open dependencies on MSVC runtime libraries on the plugins I've checked. They obviously coexist peacefully in DAWs although they might be from different decades and are mostly written in C++.

</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">afaict, Gem really requires to link against msvcrt.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
using Dependency Walker on the recent Gem 0.94 I see that it only uses C symbols from the MSVC, like any other plugin compiled with MinGW, so I don't see a problem here. the C++ symbols come from the libstdc++ which you ship (although you could also link statically). OTOH, the old Gem from Pd extended depended on C++ symbols from msvcr71.dll (I guess because it was compiled with VS) and if that DLL was missing Gem wouldn't load.

Christof


</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Gesendet: Mittwoch, 23. Januar 2019 um 00:51 Uhr
Von: "Miller Puckette" <a class="moz-txt-link-rfc2396E" href="mailto:msp@ucsd.edu"><msp@ucsd.edu></a>
An: "IOhannes m zm??lnig" <a class="moz-txt-link-rfc2396E" href="mailto:zmoelnig@iem.at"><zmoelnig@iem.at></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:pd-dev@lists.iem.at">pd-dev@lists.iem.at</a>
Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Here's an idea, what if I stuck  msvcr*dll in a separate directory and
called SetDllDirectory another time in s_loader.c to allow externs to find it
if they need it?

</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">hmm, but SetDllDirectory() only allows us to specify a single additional
directory (calling it multiple times will just change this single
directory). and we already need it for specifying the plugin-path, so
the external can ship its own dependencies - beyond msvcrt.dll

fgmdars
IOhannes

</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Lame fix would be to try it twice, first the "good" way (looking where the
extern is), then as a backup, in .../pd/bullshit where I could hide the old
DLs.



</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">_______________________________________________
Pd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a>
<a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev">https://lists.puredata.info/listinfo/pd-dev</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">



_______________________________________________
Pd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a>
<a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev">https://lists.puredata.info/listinfo/pd-dev</a>

</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">


_______________________________________________
Pd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a>
<a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev">https://lists.puredata.info/listinfo/pd-dev</a>

</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">


_______________________________________________
Pd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a>
<a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev">https://lists.puredata.info/listinfo/pd-dev</a>

</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">


_______________________________________________
Pd-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a>
<a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-dev">https://lists.puredata.info/listinfo/pd-dev</a>
</pre>
</blockquote>
</body>
</html>