Re: GSOC proposal - control panel

<off-topic>Sorry bout that, went a lil' /too/ paranoid. Thing is, I've spent 
so many days obsessing with the cpls, trying to get anything resembling a 
somewhat stable dev environment to produce anything resembling a *compilable* 
code, reverse-engineering Makefiles, and Makefile.ins, and defs and specs and 
C and gcc and ReactOS cpls and so forth /and being handed a code whose dev 
jumped on me for trying to cross-compile it, though that was what I asked for 
in the first place btw/ and when finally, SOMETHING compiled (a sample cpl 
included in Reactos 3.0. source code), I suddenly discovered that

A.) They can't be done the normal way /e.g. compiled against wine's 
source-tree by winegcc/
B.) If they could, they would've been done long ago (Reactos has 'em; Someone 
would've ported them by now, if not do 'em from scratch)

It was just too much for two weeks, sorry again.
</off-topic>

On-topic: CPls the normal way -> no-go. Binary CPls compiled on 'doze or with 
a 'doze compiler under wine -> yes.

Sorry again.

GSOC proposal - control panel

[Rolf Kalbermatter]

[e-mail] [mailto:[e-mail]]
> On-topic: CPls the normal way -> no-go. Binary CPls compiled 
> on 'doze or with a 'doze compiler under wine -> yes.

I may be very off here but isn't Wine's LoadLibrary/GetProcAddress
able to deal with wine shared library modules, even if they are not
really PE files?

Of course Windows can't deal with them. For a Windows compatible DLL
you do need a cross compiler like MingW or compile the sources in MSVC.
It should be the same here as what is actually the situation for the
test framework.

Rolf Kalbermatter