RE: [ros-dev] msvcrt/crtdll "merge"

[Waldo Alvarez Cañizares]

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(a)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(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev

[Gunnar Dalsnes]

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

[Ge van Geldorp]

>   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.

[Thomas Larsen]

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