> Hello Rolf
> I know your focus is on DLL separation but with all of the work you have been doing 
>of late on
> shell32 I was wondering if you could take a look at the unixisms and win9xism's in 
>shell32 and see
> if there is a way to fix it so it can build/link on mingw. ATM shell32 imports fork 
>and waitpid in
> shellexec and of course this wont work for our port to windows. Also there are a few 
>places where
> some win32 functions are still importing  MapSL and MapLS both of which I dont think 
>are exported
> under WindowsNT/2K.

Well that was the next thing I was thinking about tackling. My problem here is that I 
know more
about Win32 than Unix, so I was putting that on the wait list for the moment. One of 
my intents
is in fact to get one DLL after the other to cleanly compile AND link under MSVC and 
as far as
I see I think this will also make things quite easy for working under MingW.

As far as the MapSL and MapLS are concerned I think they can rather easily be removed 
at least
from shell32. They are only sparsly used such as in Drag and Drop windows messaging 
and should
most probably be replaced with the newer Drag and Drop mechanisme. The in this case 
used Drag
and Drop messages are not (anymore?) documented at all and seem to use 16:16 bit 
pointers.
I have at the moment no idea if they could be changed to use 32:0 pointers instead or 
if they
have no meaning at all in Win32 but tend to believe the latter.

> I was going to try to submit a patch to work around waitpid because that seems easy 
>but to emulate
> fork under windows is going to involve a nasty CreateProcess hack that I have not 
>been able to get
> to work right. If you have the time and are interested let me know and I can help 
>you debug/test
> shell32 via mingw on Win2k.

I haven't really looked at fork yet nor at waitpid or the other unix calls but think 
there
should be a clean Win32 way to get things working.

I would be happy to work with you on these issues. As it is I do not know enough Unix 
details to
do all that work alone.

Rolf Kalbermatter


Reply via email to