"Steven Edwards" Steven_Ed4153@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.