I don't think that it's a good idea. Apparently Mingw uses msvcrt.dll as its C run-time library and wcstol is imported from there.
It would be much better to use functions provided by Wine dlls as much as possible. Especially in the cases when wcstol is imported by kernel, user or gdi, which certainly could not import msvcrt.dll, but must rely on the functionality provided by ntdll instead.
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. Mingw include stdlib.h be default and there are at least two other functions like this that are in msvcrt and as such mingw.
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? I thought it handled threading and such in the same way? 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)
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.
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson