Fix for commdlg on Mingw

[Dmitry Timoshkov]

"Steven Edwards" <Steven_Ed4153 at yahoo.com> wrote:

> And they say ignorance is bliss. I didn't really think about that and
> I was just looking at ntdll and msvcrt differences today. What would be
> proper
> Way to fix this? Once I have the idea, I can do the patches for the
> rest.

I believe that ntdll should be used as a C run-time replacement as much
as possible, especially in the light of a more and more wide use of unicode
in Wine and necessity to have a direct way to manipulate unicode strings
and data.

The only question I have: in what header file all those ntdll C run-time
functions should be prototyped? It seems that NT DDK does not have an answer
on that question.

> Mingw include stdlib.h be default and there are at least two other 
> functions like this that are in msvcrt and as such mingw.

And the very next question arises how to resolve conflicts with prototypes
provided by an underlying system?

> > By the way, do you have a plan for using low level 
> > functionality provided by an underlying system such as 
> > selector management, process and thread creation and similar things?
> 
> Not really =). At least not a good one.
> 
> My first goal has been to get the wine tree ready to be ported 
> then start working my way down. With the latest patches to the build
> system 
> Alexandre did we can now build wine/programs with almost no problems.
> Now I am starting to move in the higher dlls like sh* ole* and com*. 
> 
> It was my assumption (I know assumption is the mother of all fuckups)
> that 
> if dll seperation is done properly, I should just be able to drop them 
> in as replacements on NT/2K and see what breaks. Wineserver emulates 
> Windows NT/2K be default right?

No, wineserver does not emulate anything.

> I thought it handled threading and 
> such in the same way?

Wineserver does not handle threading and such, it provides interprocess
handle management and synchronization mechanisms for Wine processes.

> From what I gathered at wineconf and what I have 
> followed here, There really shouldn't be much work outside of the
> already 
> planned dll seperation. (Of course we already covered assumption)

Not from the point of view of the ReactOS. Just look for imports of gdi32,
user32 and kernel32 on the real nt/w2k system.

> At some point I plan on fixing wineserver on cygwin but that is a whole
> other project for down the road. At the rate things are going it will be
> Another year before I am ready and understand things enough to try.

Cygwin currently lacks a mechanism to transfer file handles between
processes (implementations of sendmsg and recvmsg are incomplete), and
therefore either they should be completed or some other way around should
be invented.

-- 
Dmitry.