I just put up a new dll that hopefully does not need the extra runtime lib DLLs. Can someone try it?
hello, according to the only friend i know using gem on windows, this dll work as expected.
do you wish specific test to be done?
Cyrille
chris clepper a écrit :
I just put up a new dll that hopefully does not need the extra runtime lib DLLs. Can someone try it?
http://taproot.dyndns.org/~cgc/downloads/Gem.dll
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 4/24/06, cyrille henry cyrille.henry@la-kitchen.fr wrote:
hello, according to the only friend i know using gem on windows, this dll work as expected.
do you wish specific test to be done?
Thanks for the report. I was mainly wondering if the MS runtime DLL problem was fixed. The other fixes to check are Quicktime movie loading and pix_record. Also, it should have the latest and greatest objects too.
Zitat von chris clepper cgclepper@gmail.com:
I just put up a new dll that hopefully does not need the extra runtime lib DLLs. Can someone try it?
here (w2k) it is still looking for msvcp71.dll and fails to load when it cannot find it. apart from that, most new objects are still missing ([pqtorusknot], [glsl_...],...)
mfg.asd.r IOhannes
On 4/24/06, zmoelnig@iem.at zmoelnig@iem.at wrote:
here (w2k) it is still looking for msvcp71.dll and fails to load when it cannot find it.
That's what I figured. We will have to include those DLL files since that is the MS mandated way to distributed anything built with their tools. The reason building with VC 6 works is because Miller includes the runtime DLLs with Pd. Pain in the ass.
apart from that, most new objects are still missing ([pqtorusknot],
[glsl_...],...)
Hmm, I'm pretty sure glsl is in there. I have to manually check the files since there is no CVS integration in VS.net and my Cygwin is all messed up. Another pain in the ass.
On Apr 25, 2006, at 12:20 AM, chris clepper wrote:
On 4/24/06, zmoelnig@iem.at zmoelnig@iem.at wrote: here (w2k) it is still looking for msvcp71.dll and fails to load when it cannot find it.
That's what I figured. We will have to include those DLL files since that is the MS mandated way to distributed anything built with their tools. The reason building with VC 6 works is because Miller includes the runtime DLLs with Pd. Pain in the ass.
apart from that, most new objects are still missing ([pqtorusknot], [glsl_...],...)
Hmm, I'm pretty sure glsl is in there. I have to manually check the files since there is no CVS integration in VS.net and my Cygwin is all messed up. Another pain in the ass.
Is a MinGW build possible? Or does VS.net provide something needed that MinGW doesn't? It shouldn't be too hard to do.
.hc
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
On 4/25/06, Hans-Christoph Steiner hans@eds.org wrote:
Is a MinGW build possible? Or does VS.net provide something needed that MinGW doesn't? It shouldn't be too hard to do.
Possible or not it doesn't solve the issues at hand in any way.
cgc
On Apr 25, 2006, at 2:47 PM, chris clepper wrote:
On 4/25/06, Hans-Christoph Steiner hans@eds.org wrote: Is a MinGW build possible? Or does VS.net provide something needed that MinGW doesn't? It shouldn't be too hard to do.
Possible or not it doesn't solve the issues at hand in any way.
That DLL would still be required even when its compiled with MinGW?
An easy solution for that DLL is to have it included in the Pd- extended installer. Its already handling a number of DLLs and its quite trivial to add another. packages/win32_inno/Makefile could copy the DLL from %SystemRoom%\system32, if its there, then the installer package will test if its installer a newer version of the that DLL, then install it.
But I would really like to have Pd-extended build Gem from source, rather than using binaries. That means using MinGW on Windows...
.hc
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
On 4/25/06, Hans-Christoph Steiner hans@eds.org wrote:
An easy solution for that DLL is to have it included in the Pd-extended installer. Its already handling a number of DLLs and its quite trivial to add another. packages/win32_inno/Makefile could copy the DLL from %SystemRoom%\system32, if its there, then the installer package will test if its installer a newer version of the that DLL, then install it.
And then you would break all sorts of apps on the user's machine. Welcome to DLL hell. A 'better' solution is to include the C++ runtime for VC6, VS 2003 and VS 2005 with Pd itself. That's the way MS wants it done and that's why you end up with 32 copies of the same DLL on a windows machine. Brilliant!
On Apr 25, 2006, at 7:11 PM, chris clepper wrote:
On 4/25/06, Hans-Christoph Steiner hans@eds.org wrote: An easy solution for that DLL is to have it included in the Pd- extended installer. Its already handling a number of DLLs and its quite trivial to add another. packages/win32_inno/Makefile could copy the DLL from %SystemRoom%\system32, if its there, then the installer package will test if its installer a newer version of the that DLL, then install it.
And then you would break all sorts of apps on the user's machine. Welcome to DLL hell. A 'better' solution is to include the C++ runtime for VC6, VS 2003 and VS 2005 with Pd itself. That's the way MS wants it done and that's why you end up with 32 copies of the same DLL on a windows machine. Brilliant!
Well, that can be easily arranged too. I also shudder when I am being sucked into Windows land... they've made so many arcane, bizarre design decisions.
.hc
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
-
chris clepper -
chris clepper -
cyrille henry -
Hans-Christoph Steiner -
zmoelnig＠iem.at