On 2017-10-11 23:00, Pure Data Computer Music System SVN repository wrote:
Don't use sys_fopen with MSVC as its FILE struct is not compatible.
hmm, i'm pretty sure this is the wrong approach. the sole purpose of sys_fopen() is to help Windows users (as it wraps the use of non-ascii filenames!). on non-windows platforms sys_fopen() is basically identical to fopen().
i guess the problem you are having is hat the FILE handle returned by _fopen() depends on the libC implementation, and if Pd has been linked against a different libc implementation than midifile, they might be "incompatible". e.g. this is the reason why Pd provides a sys_fclose() (since running flose() on a sys_fopen()ed file would leak ressources).
since there's a number of externals that are successfully using sys_fopen()/sys_fclose(), wonder what goes wrong in midifile. what exactly is meant by "incompatibility"?
since when does the problem exist? (e.g. did something change in the Pd build process that triggered that error?)
is there some bug-report against Pd about sys_fclose() being unusable on W32?
fgasmr IOhannes
On Thu, Oct 12, 2017 at 4:38 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-10-11 23:00, Pure Data Computer Music System SVN repository wrote:
Don't use sys_fopen with MSVC as its FILE struct is not compatible.
hmm, i'm pretty sure this is the wrong approach. the sole purpose of sys_fopen() is to help Windows users (as it wraps the use of non-ascii filenames!). on non-windows platforms sys_fopen() is basically identical to fopen().
i guess the problem you are having is hat the FILE handle returned by _fopen() depends on the libC implementation, and if Pd has been linked against a different libc implementation than midifile, they might be "incompatible".
Precisely. I have been bitten by that before.
e.g. this is the reason why Pd provides a sys_fclose() (since running
flose() on a sys_fopen()ed file would leak ressources).
since there's a number of externals that are successfully using sys_fopen()/sys_fclose(), wonder what goes wrong in midifile. what exactly is meant by "incompatibility"?
It's only sys_fclose() (and things that use FILE) that doesn't work, calling Pd functions like post() cause no trouble.
since when does the problem exist? (e.g. did something change in the Pd
build process that triggered that error?)
Since yesterday I've been trying to build midifile.c for Windows7 using Visual Studio 2017. When I run the resulting dll using midifile-help.pd it crashes Pd (0.48.0 installed from Miller's site) whenever sys_fopen() is called. Doing the same thing using fopen() from stdio.h works fine.
The makefile in Miller's distribution has VCSDK = "C:\Program Files\Microsoft SDKs\Windows\v6.0A" VC9 = "C:\Program Files\Microsoft Visual Studio 9.0\VC" MSCC = cl MSLN = link
I'm using a different version of the same MS tools and building from the IDE. Possibly the c runtime is not the same? I would have expected a conflict if using MinGW.
Here is some info relevant to the situation, bur I'm not sure what to do with it: https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-pass...
is there some bug-report against Pd about sys_fclose() being unusable on
W32?
fgasmr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 10/12/2017 08:03 PM, Martin Peach wrote:
Since yesterday I've been trying to build midifile.c for Windows7 using Visual Studio 2017. When I run the resulting dll using midifile-help.pd it crashes Pd (0.48.0 installed from Miller's site) whenever sys_fopen() is called. Doing the same thing using fopen() from stdio.h works fine.
you mean, that sys_fopen() is crashing and never returning (rather than using the FILE returned by it)?cd can you open other files with Pd? e.g. can you *save* a Pd file?
On Thu, Oct 12, 2017 at 3:24 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 10/12/2017 08:03 PM, Martin Peach wrote:
Since yesterday I've been trying to build midifile.c for Windows7 using Visual Studio 2017. When I run the resulting dll using midifile-help.pd
it
crashes Pd (0.48.0 installed from Miller's site) whenever sys_fopen() is called. Doing the same thing using fopen() from stdio.h works fine.
you mean, that sys_fopen() is crashing and never returning (rather than using the FILE returned by it)?cd can you open other files with Pd? e.g. can you *save* a Pd file?
Yes, when my midifile dll calls sys_fopen in the running instance of Pd, Pd disappears from the screen. I was getting a crash report dialog, but not any more. The Pd program runs fine, I can open and save patches. Also the version of [midifile] from deken works fine, but I don't know how that was built.
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach