No dice. CPls are DLLs that export a function - CPlApplet(). winegcc coughs on dllexport. - not implemented. I've been hacking at it for days on end now. Result: CPl can be compiled under windows and run under wine. CPls compiled with winegcc don't export that function => not treated as control panel applets. software to aid anyone: dllexp.exe. Download and run on any dll/cpl of windows, you get exports in it; run on wine dlls - nada. (hence, No Template in wine's source. Twain DLL exports some methods though.)
MICROSOFT ISSUE: EASY TO DISTINGUISH BETWEEN WINE DLLS AND WINDOWS DLLS.
If dllexp.exe can do it, so can they. Solution: M$ implements a code that *checks for a dll version* (based on what the DLL exports). Doesn't find export => coughs and dies with an "Incompatible DLL version". Happened before with OS2 / Windows. Maybe has happened now with all M$ that cough on wine.
Not enough intimate knowledge => can a soft cough and die based on a call to a DLL export which isn't there, without being designed to do so?
pure_evil@mail.bg wrote:
No dice. CPls are DLLs that export a function - CPlApplet(). winegcc coughs on dllexport. - not implemented.
__declspec(dllexport) is a MSVC-only feature. Hence, when compiling with gcc (even using winegcc) it won't actually export the function. As has been stated before, you need to use a .spec or .def file to export it.
I've been hacking at it for days on end now. Result: CPl can be compiled under windows and run under wine. CPls compiled with winegcc don't export that function => not treated as control panel applets. software to aid anyone: dllexp.exe. Download and run on any dll/cpl of windows, you get exports in it; run on wine dlls - nada. (hence, No Template in wine's source. Twain DLL exports some methods though.)
MICROSOFT ISSUE: EASY TO DISTINGUISH BETWEEN WINE DLLS AND WINDOWS DLLS.
If dllexp.exe can do it, so can they. Solution: M$ implements a code that *checks for a dll version* (based on what the DLL exports). Doesn't find export => coughs and dies with an "Incompatible DLL version". Happened before with OS2 / Windows. Maybe has happened now with all M$ that cough on wine.
Not enough intimate knowledge => can a soft cough and die based on a call to a DLL export which isn't there, without being designed to do so?
A DLL compiled as a winelib DLL won't be parsed by a tool that reads PE DLLs, because winelib DLLs are Elf shared objects. Use winedump instead.
__declspec(dllexport) is a MSVC-only feature. Hence, when compiling with gcc (even using winegcc) it won't actually export the function. As has been stated before, you need to use a .spec or .def file to export it.
Yes.
A DLL compiled as a winelib DLL won't be parsed by a tool that reads PE DLLs, because winelib DLLs are Elf shared objects. Use winedump instead.
Precisely. Easy to distinguish between wine and doze Dlls.
Use winedump instead.
I did. It dumps the CPlApplet() function nicely from all cpls (including one I made in Delphi).
On Thu, Mar 27, 2008 at 4:03 PM, pure_evil@mail.bg wrote:
A DLL compiled as a winelib DLL won't be parsed by a tool that reads PE DLLs, because winelib DLLs are Elf shared objects. Use winedump instead.
Precisely. Easy to distinguish between wine and doze Dlls.
Wine is easily detectable anyway. Just look at the Wine regkeys, or try some Unix-calls. It's impossible to stop childish companies from blocking Wine.
Remco
No dice. CPls are DLLs that export a function - CPlApplet(). winegcc coughs on dllexport. - not implemented. I've been hacking at it for days on end now. Result: CPl can be compiled under windows and run under wine. CPls compiled with winegcc don't export that function => not treated as control panel applets.
I'm sure it must be possible to export routines in Wine .dll.so libraries via .def files or similar - whether GetProcAddress supports Wine "DLLs" is the issue. Even if for some reason it's not possible, I don't see that it would be impossible to detect that the .cpl file is actually a Wine DLL, and to use the appropriate dlopen-type routines to read it.