Prev: Mixed code - Crashes in Release Mode
Next: Printing from Console Application
From: Vincent Fatica on 20 Aug 2008 11:54
On Wed, 20 Aug 2008 15:42:17 +0300, "Alex Blekhman" <tkfx.REMOVE(a)yahoo.com>
wrote:

>> /Gs- didn't work, but /Gs200000 got rid of the __chkstk messages
>> but I still have the __memset problem.
>
>Maybe if you implement __memset by yourself, then it will go away.
>
>Is there any reason that you want to avoid CRT? The linker is
>pretty good and will be able to eliminate dead code anyway. It is
>only several KB.

If I make **only** the change from the custom entry MyDllMain to the expected
DLL main, my DLL goes from 17 KB to 53 KB.
--
- Vince
From: Alex Blekhman on 20 Aug 2008 13:33
"Vincent Fatica" wrote:
> If I make **only** the change from the custom entry MyDllMain to
> the expected DLL main, my DLL goes from 17 KB to 53 KB.

So what? These 36 KB of CRT (which is linked statically, I
suppose) are pretty constant value. They won't increase much if
you will use the CRT to the fullest. Also, these 36 KB are
negligible for any practical implication. Can you detect any start
up slowdown or performace decrease due to CRT? On the other hand
you lose a lot. I won't even mention the devlopment time you need
to spend in order to make things work. Without CRT you lose decent
exception support, which is essential if you develop in C++; you
must give up debugging facilities of CRT and develop your own; you
need to reinvent the wheel by constantly implementing all over
again what is already present in the CRT, etc, etc.

Alex


From: Vincent Fatica on 20 Aug 2008 17:03
On Wed, 20 Aug 2008 20:33:54 +0300, "Alex Blekhman" <tkfx.REMOVE(a)yahoo.com>
wrote:

>"Vincent Fatica" wrote:
>> If I make **only** the change from the custom entry MyDllMain to
>> the expected DLL main, my DLL goes from 17 KB to 53 KB.
>
>So what? These 36 KB of CRT (which is linked statically, I
>suppose) are pretty constant value. They won't increase much if
>you will use the CRT to the fullest. Also, these 36 KB are
>negligible for any practical implication. Can you detect any start
>up slowdown or performace decrease due to CRT? On the other hand
>you lose a lot. I won't even mention the devlopment time you need
>to spend in order to make things work. Without CRT you lose decent
>exception support, which is essential if you develop in C++; you
>must give up debugging facilities of CRT and develop your own; you
>need to reinvent the wheel by constantly implementing all over
>again what is already present in the CRT, etc, etc.

Well, I wouldn't mind if my app were bigger or if I wanted to take advantage of
what the CRT offers. In this particular case, the only thing I had to re-invent
was wcspbrk() (three lines).

There are still two questions I'd like to have answers to. What exactly was the
VC7-VC8 change that made what was trivial (the default even) so difficult (maybe
impossible). Are what does the .CRT section do (apparently nothing since I've
zeroed its eight bytes with no ill effect)?
--
- Vince
From: Alex Blekhman on 21 Aug 2008 07:14
"Vincent Fatica" wrote:
> There are still two questions I'd like to have answers to. What
> exactly was the VC7-VC8 change that made what was trivial (the
> default even) so difficult (maybe impossible). Are what does
> the .CRT section do (apparently nothing since I've zeroed its
> eight bytes with no ill effect)?

I have made CRT-less DLL and I cannot see .CRT section. I have 5
sections in this DLL:

..data
..rdata
..reloc
..rsrc
..text

Regarding linking errors.

1. LNK2019 for `_chkstk' can be fixed in two ways:

a) By providing one's own implementation, which may be empty,
BTW:

extern "C" void _chkstk() {}

b) By linking with "chkstk.obj" file, which is found in
%VCINSTALLDIR%\lib folder.

2. LNK2019 for `_memset' can be fixed by providing one's own
implementation. There is an example of `memset' implementation in
"memset.asm" file, which is in the CRT sources directory. Note:
One must put the following pragma in all source files where
`memset' is used:

#pragma function(memset)

Without the above pragma compiler tries to use intrinsic
implementation for `memset', which requires CRT.

The conclusion is that starting with at least VS8 the coupling
between compiler and CRT is unbreakable. Compiler assumes that CRT
facilities are present when generates binary code. Probably there
is true CRT-less solution in DDK suite, but I didn't check this.

HTH
Alex


From: Vincent Fatica on 21 Aug 2008 09:59
On Thu, 21 Aug 2008 14:14:19 +0300, "Alex Blekhman" <tkfx.REMOVE(a)yahoo.com>
wrote:

>2. LNK2019 for `_memset' can be fixed by providing one's own
>implementation. There is an example of `memset' implementation in
>"memset.asm" file, which is in the CRT sources directory. Note:
>One must put the following pragma in all source files where
>`memset' is used:
>
> #pragma function(memset)
>
>Without the above pragma compiler tries to use intrinsic
>implementation for `memset', which requires CRT.

Yes, that works. But it raises another question. When I provide my own
memset() I get

Size: 14848 .text 1B74 .rdata EFC .data 41CC .rsrc 270 .reloc 4FA

When I don't, and let the compiler warn me, I get

Size: 18944 .text 2466 .rdata 104C .data 451C .CRT 8 .rsrc 270 .reloc 5B8

That's an extra section, 2290 bytes of text, 336 bytes of rdata, and 848 bytes
of data. My own memset() (copied from the CRT sources) seems to need only 96
bytes. What do you suppose all that extra code and data is doing?
--
- Vince
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Mixed code - Crashes in Release Mode
Next: Printing from Console Application