"Steven Edwards" Steven_Ed4153@yahoo.com wrote:
Changelog: Fix for commdlg. Mingw stdlib.h defines wcstol so we check for it and use it else we use the normal wine one.
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.
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?
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
"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.
On Mon, May 13, 2002 at 07:01:56PM +0900, Dmitry Timoshkov wrote:
"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.
Last time I asked Alexandre this, he suggested ntddk.h . So that's where I put wcstol().
Huw.
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.
So once ported, will the higher level dlls from wine function on a Windows/ReactOS system? Ole*, Commdlg, Comctrl, shfolder, shlwapi, mapi, twain and others Are the target of my port.
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.
I guess I should have been a little clearer. Wines Gdi32, user32 and kernel32 are not to much of a concern for me. ReactOS has its own implentation of Gdi32 and Kernel32 and most of the user32 functions are just Forwards to Win32K.sys anyway. I understand that they are not going to Just a recompile + minor patch or two. The core ReactOS developers have adapted large parts of wines user32 functions in to our Win32k.sys However we are still lacking the default window proc and messaging.
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.
Sounds like fun. If I ever get done with the mingw side I will have another Project to beat my head over.
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
"Steven Edwards" Steven_Ed4153@yahoo.com wrote:
So once ported, will the higher level dlls from wine function on a Windows/ReactOS system? Ole*, Commdlg, Comctrl, shfolder, shlwapi, mapi, twain and others Are the target of my port.
Sure, all Wine dlls which use only win32 APIs for their needs should work on ReactOS. Besides dll separation there are other issues: direct use of fork, getpid and similar "unixisms", direct access to unix file system (DOSFS_GetFullName/open/mmap/etc), direct access for unix devices.
Sure, all Wine dlls which use only win32 APIs for their needs should work on ReactOS. Besides dll separation there are other issues: direct use of fork, getpid and similar "unixisms", direct access to unix file system (DOSFS_GetFullName/open/mmap/etc), direct access for unix devices.
I know you guys like to avoid "unixisms" so when we do encounter them. We might not be have option but for ReactOS to have those files forked. We will burn that bridge when we get to it =)
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
And the very next question arises how to resolve conflicts with prototypes provided by an underlying system?
I will ask this of the reactos developers.
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
"Dmitry Timoshkov" dmitry@baikal.ru writes:
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?
I think the right way would be to put that functionality in libwine_unicode, and follow the naming convention that we are using there (for instance wcstol would be strtolW). This way we are sure the prototypes won't conflict.
-
Alexandre Julliard -
Dmitry Timoshkov -
Huw D M Davies -
Steven Edwards