Csak emlékeztből irtam a keresési sorrendre vonatkozó megjegyzésemet. A pontos info itt található:
http://msdn2.microsoft.com/en-us/library/ms682586.aspx
Látható, hogy elég szofisztikált, és sok paramétertől függ.
Egyébként sok dll valójában com objektumot implementál, és a rendszer egy IUnknown-ból származtatott interface-en keresztül használja a funkciókat.
Ezek speciális dll-ek, és com objektumként regisztrálni kell őket a regsvr32-vel, mert a com objektumok hívása esetén a dll betöltését a com végzi el
a registry bejegyzések alapján. Konkrét tapasztalataim vannak, hogy milyen stochasztikus hibákhoz vezet ha nem regisztrálok le egy ilyen dll-t.
Időnként betölti, időnként nem, és egy csapásra megszűnik minden anomalia a regsvr32 után....
Nem állítom, hogy a winsock.dll ilyen. Mindazonáltal nálam szerepel mind a windows, mind a windows\system32 a path -ban, továbbá mind a két helyen
megvan ugyanaz a winsock.dll (nem én raktam mind két helyre , ugye mondanom sem kell...). Nos a tények makacs dolgok, és ezek a következők:
1. kiveszem a child folyamat environtmentjéből a systemroot-t, és berakom a path változót: gethostname jól működik, gethostbyname elhasal
2. visszarakom a systemroot-t , mindkettő jól műkodik .
De szerintem nem ez a lényeg. A lényeg az, hogy a socket-ek kezelése a unix-on kernel szinten történik, mig a windowson "shared libbel", amit dll-nek
hivnak.