<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>


<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.hmmessage P
{margin:0px;padding:0px;}
body.hmmessage
{font-size:10pt;font-family:Verdana;}
</style>

zmoelnig wrote:<br>&gt; Damien Henry wrote:<br>&gt; &gt; Hello !<br>&gt; &gt; <br>&gt; &gt; Where can I find documentation about pd.lib ?<br>&gt; &gt; Does anyone on the list turn pd into a library ? for creating a DSP<br>&gt; &gt; engine for instance ?<br>&gt; <br>&gt; <br>&gt; no.<br>&gt; this is how Pd has always been built by miller on w32.<br>&gt; pd.exe/pd.com is just a tiny wrapper that calls the main-loop within pd.lib<br>&gt; nothing like a libpd<br>&gt; <br><br>Well pd.lib is actually a kind of list of function entry points in pd.dll, which is the real shared library.<br><br>pd.exe and pd.com jump to a function sys_main() in pd.dll.<br><br>sys_main then starts up the whole gui, unless it was called with the -nogui argument. <br><br>pd.lib only exists for the linker to find the code and isn't required at run-time. With the M$ linker it's needed to associate the symbols (function names in Pd) with entry points (pointers to Pd code), when building externals.<br><br>Nothing stops you using code within pd.dll as library code. It's just like a libpd except for the requirement to know ahead of time where the functions are located, which is why pd.lib is there. Practically it's nearly useless as a lib because everything is interrelated, but you could probably fake a call to the perform routine of osc~ without otherwise using the dsp graph; or use some utility function.<br><br>Martin<br><br></body>
</html>