Cool.
I have a real tough test in mind - the old PDRP patches which have MSVC-
compiled externs in them, with msvcrt.dll dynamically linked (I believe).
I'll set up a clean W2K system to test them on and see what happens (and
if they don't work without the DLLs in pd/bin/ I can see if my
On 1/23/19, Christof Ressi wrote:
> 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.
This SO thread may clarify why MinGW does depend on msvcrt.dll:
On 1/23/19, Miller Puckette wrote:
> I bet most externs use one or another thing from msvcr*dll. String
> functions, malloc, etc...
I've always naively assumed that MinGW's libgcc and libstdc++ are a
full replacement for MS standard libs (which notably do not include
pthread). Pd-extended
Here's a full dependency-walker analysis of all w32 v00-extended Deken:
http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip
It's one text file per .dll. We can Grep/Findstring to get results that mainly
boils down to:
msvcr90.dll -> no match.
msvcr71.dll -> Gem and friends.
