> Why do we need dynamic binding (via GetProcAddress32)?
We need this to be able to use native windows dll's.
> We don't check return
> values. So if any of these functions are not exported, function pointer will
> be set to NULL, and we have a good chance to crush application in the
> middle.
Yes, but these functions has to be there. The native and the wine dll's exporting
these. Can you imagine a case where these functions are not there???
> If we will use static binding (via Import section) we at least will get
> "unresolved external" error at load time.
And we can't use native dll's. The dll-loading mechanism is not jet implemented right.
The GetProcAdress way is a workaround.
In the windows world you would have to link against a *.lib file to import external
dll's.
There is no such mechanism in wine yet.
> Maybe I missed something and "Import" doesn't work in ELF-PE / ELF-ELF
> binding?
Did you get any error messages???
> Anyway, if we stick to current approach I think we must check return value
> of GetProcAddress.
If we like to pick at, yes. But as stated I cant imagine a situation where these
exports
are not in place and I've never seen a crash caused by this.
> Another question / suggestion. Why don't we put all imported function
> pointers into array? This will simplify COMDLG32_DllEntryPoint (especially
> if we gonna check pointers for null).
These array elements would have to be typed like these function pointers. Where
is the gain?
> Something like:
> ---
> const char *func_names[N] = {"func1", "func2", ...}
>
> union {
> FUNCPTR ptr[N];
> struct {
> void (WINAPI *func1)(void);
> void (WINAPI *func2)(void);
> ....
> } u1;
> } extdll;
Whats the difference between StructXY.u1.GetPathXX and COMDLG32_GetPathXX ????
juergen
---
[EMAIL PROTECTED]
... from sunny Berlin
