Hi Gunnar:
Great! less duplicated code == better code
I had planning to report this about msvcrt/crtdll the first chance I could get to read my e-mail, but now that you talked then there's no better chance than this I think. I was playing with msvcrt dll a couple of days ago because I was trying to test some apps against it and to maybe find some of the multithreading issues it contains. Well I dropped it because I really had no time but one thing I noticed is that there are some entries in the .def file something like this strlen=ntdll.strlen only strings routines if I remember well. Now after I got the binary file (.dll) I was inspecting it with LordPE, a tool to sniff every detail of PE's and saw that actually those routines are not imported by crtdll (maybe because of the strings.a statically linked) also I saw that msvcrt.dll is importing functions from itself funny that is something I never saw before (Is ROS parsing the exports table before the imports one? Just curious). But worst there are 2 references to msvcrt with different functions that the -O flag when passed to the linker can't fix. I have seen this before in some applications compiled with mingw (freecraft for example. Could be this an unnoticed bug in mingw's linker? If It is, it doesn't harm but it sucks to not have it the better way you can if it is easy to do it). btw I was also looking for string routines exported by ntdll in order to squeeze a bit more both libraries and noticed in XP's ntdll some functions that at the beginning I thought were mistyped (It would not be the first time) but when I took a look at msdn Tada! WindowsCE functions, nothing about XP/2k... but there they ARE. Please do not forget to fix those problems with exports if you can, or anyone with a chance, those libraries stink a lot. I still don't understand every detail on how the whole thing works: build system, linker... so this is a "I don't know how to fix", at least for now.
Best Regards Waldo Alvarez
________________________________
From: ros-dev-bounces@reactos.com on behalf of Gunnar Dalsnes Sent: Wed 1/26/2005 8:19 PM To: ReactOS Development List Subject: [ros-dev] msvcrt/crtdll "merge"
Hi,
I'm currently "merging" msvcrt and crtdll (again). I'll move msvcrt into a library lib\crt and have msvcrt and crtdll link against it. Only dllmain.c will be left in msvcrt/crtdll. Most of (99.9%) crtdll will be dropped. It all seems to work nicely. One problem thou: I ran into some header problems, where i relied on some stuff in include\msvcrt\string.h but no matter what, mingw\include\string.h were included instead (and they both defined _STRING_H_). After looking at the headers in inlcude\msvcrt they all seem to be ripped from mingw. Does anyone know why they were put in include\msvcrt when mingw has headers for all of this stuff? Can i just remove them (include\msvcrt)? I looked at many depends files and saw most files depend on many mingw headers. Is this correct? Should we depend on mingw headers at all?
Gunnar
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Waldo Alvarez Cañizares wrote:
Hi Gunnar:
Great! less duplicated code == better code
I had planning to report this about msvcrt/crtdll the first chance I could get to read my e-mail, but now that you talked then there's no better chance than this I think. I was playing with msvcrt dll a couple of days ago because I was trying to test some apps against it and to maybe find some of the multithreading issues it contains. Well I dropped it because I really had no time but one thing I noticed is that there are some entries in the .def file something like this strlen=ntdll.strlen only strings routines if I remember well. Now after I got the binary file (.dll) I was inspecting it with LordPE, a tool to sniff every detail of PE's and saw that actually those routines are not imported by crtdll (maybe because of the strings.a statically linked) also I saw that msvcrt.dll is importing functions from itself funny that is something I never saw before (Is ROS parsing the exports table before the imports one? Just curious). But worst there are 2 references to msvcrt with
different functions that the -O flag when passed to the linker can't fix. I have seen this before in some applications compiled with mingw (freecraft for example. Could be this an unnoticed bug in mingw's linker? If It is, it doesn't harm but it sucks to not have it the better way you can if it is easy to do it). btw I was also looking for string routines exported by ntdll in order to squeeze a bit more both libraries and noticed in XP's ntdll some functions that at the beginning I thought were mistyped (It would not be the first time) but when I took a look at msdn Tada! WindowsCE functions, nothing about XP/2k... but there they ARE. Please do not forget to fix those problems with exports if you can, or anyone with a chance, those libraries stink a lot. I still don't understand every detail on how the whole thing works: build system, linker... so this is a "I don't know how to fix", at least for now.
I made some changes so neither crtdll/msvcrt import from self anymore. Its strange that the linker is not smart enough to resolve symbols without having to import from self, but it could be "by design".
The linker is crazy, because it does not complain when you export non-existing symbols/functions. Anyone who calls these functions will crash in mysterious ways (been there). The bug might be triggered by the option --enable-stdcall-fixup??? (just guessing)
And about the strlen=ntdll.strlen stuff. Forwarded functions doesnt show up as imported because they arent really imported, so this is normal.
Dont understand what XP's ntdll exporting "WindowsCE" functions has to do with anything?
Gunnar
From: Gunnar Dalsnes
I made some changes so neither crtdll/msvcrt import from self anymore. Its strange that the linker is not smart enough to resolve symbols without having to import from self, but it could be "by design".
The linker is crazy, because it does not complain when you export non-existing symbols/functions. Anyone who calls these functions will crash in mysterious ways (been there). The bug might be triggered by the option --enable-stdcall-fixup??? (just guessing)
I think the problem is that gcc implicitly adds "-lmsvcrt" to its command line. So if you export a non-existing function the linker will just import it from libmsvcrt.a. There probably is a gcc option to turn the implicit addition of "-lmsvcrt" (and other standard libs) off.
Gé van Geldorp.
Hi Guys
Anybody got a working copy of widl.exe from wine they could send to my mail
Thomas
__________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com
-
Ge van Geldorp -
Gunnar Dalsnes -
Thomas Larsen -
Waldo Alvarez Cañizares