Using the more usefull functions of the crt keeping the code small

[TouEnMasm]

A dynamic link on the crt can do that.
Provided is the lib and it's include file with source code.
The sample could work in SUBSYSTEM:CONSOLE or SUBSYSTEM:WINDOWS
The two are in the pack.
The two exe are keeped small (5,5k)
If you change your mind and want to link to the crt,no problem.
Just don't include the lib and it's done.Your code stay unchanged.

[Vortex]

Hi ToutEnMasm,

The classical method is to use msvcrt.dll. Dynamic linking will reduce the size of the final executable. Did you ever consider writing your own CRT with assembly?

[TouEnMasm]

Did you ever consider writing your own CRT with assembly?

Did you mean with the crt source code (made a build with c++)
or made a build with the translated c code with help of /Fa ?
The first soluce can be done if i had the batch who build it ,I don't know if he can be found.
The second is a big work not really usefull,except for the masm32 package.

Other soluce is to made it entirely by dynamic load,but this also will increase the size of the executable.This soluce can be done easily.Perhaps cut it in pieces can reduce the size of the final executable.Can be done also,not to put in it the old functions who are numerous.

[jj2007]

The crt functions don't bloat your executable. 1536 bytes:

include \masm32\include\masm32rt.inc

.code
AppName   db "Masm32:", 0
hw   db "Hello World", 0

start:   MsgBox 0, addr hw, addr AppName, MB_OK
   exit

   call crt_memcpy
   mov eax, ubyte$(al)
   mov eax, sbyte$(cl)
   mov eax, xbyte$(dl)
   mov eax, uword$(ax)
   mov eax, sword$(ax)
   mov eax, xword$(ax)
   mov eax, udword$(eax)
   mov eax, sdword$(eax)
   mov eax, xdword$(eax)
   mov eax, uqword$(edx::eax)
   mov eax, sqword$(edx::eax)
   mov eax, xqword$(edx::eax)
   mov eax, real4$(eax)
   mov eax, real8$(edx::eax)
end start

[Vortex]

Hi ToutEnMasm,

What I mean is that you can build your own CRT with your own source code ( preferably using assembly )

Jochen is right, dynamic linking will not increase the size of your executable.

[dedndave]

yes - that's one advantage of using the CRT - it is already on their machine   :t

other advantages are that it is reasonably fast in many cases and fairly stable code
ms, through many iterations, has found work-arounds and worked out a lot of bugs
that means it can cut down on your development time, signifigantly

[TouEnMasm]

I don't see of what you speak about the size of the code .The title of this post say all.
All is not perfect as say jochen who seem to understand only the yes no answer.
Here is a part of the executable data.
This part grow only with the number of functions in the the dynamic lib.A thousand of functions in this lib increase this part even if they are not in use.
In a static lib the size of the executable grow with the number of functions in use.
It's a notable difference.

  004032C0: 00 00 00 00 00 00 00 00 73 70 72 69 6E 74 66 5F  ........sprintf_
  004032D0: 73 00 00 00 00 00 5F 73 65 74 5F 69 6E 76 61 6C  s....._set_inval
  004032E0: 69 64 5F 70 61 72 61 6D 65 74 65 72 5F 68 61 6E  id_parameter_han
  004032F0: 64 6C 65 72 00 00 00 00 00 5F 73 63 61 6C 62 00  dler....._scalb.
  00403300: 00 00 00 00 5F 6C 6F 67 62 00 00 00 00 00 5F 6E  ...._logb....._n
  00403310: 65 78 74 61 66 74 65 72 00 00 00 00 00 5F 66 69  extafter....._fi
  00403320: 6E 69 74 65 00 00 00 00 00 5F 69 73 6E 61 6E 00  nite....._isnan.
  00403330: 00 00 00 00 5F 66 70 63 6C 61 73 73 00 00 00 00  ...._fpclass....
  00403340: 00 5F 67 65 74 63 68 00 00 00 00 00 6D 61 6C 6C  ._getch.....mall
  00403350: 6F 63 00 00 00 00 00 66 72 65 65 00 00 00 00 00  oc.....free.....
  00403360: 6D 65 6D 73 65 74 00 00 00 00 00 5F 61 6C 69 67  memset....._alig
  00403370: 6E 65 64 5F 66 72 65 65 00 00 00 00 00 5F 61 6C  ned_free....._al
  00403380: 69 67 6E 65 64 5F 6D 61 6C 6C 6F 63 00 00 00 00  igned_malloc....
  00403390: 00 5F 61 6C 69 67 6E 65 64 5F 6F 66 66 73 65 74  ._aligned_offset
  004033A0: 5F 6D 61 6C 6C 6F 63 00 00 00 00 00 5F 61 6C 69  _malloc....._ali
  004033B0: 67 6E 65 64 5F 72 65 61 6C 6C 6F 63 00 00 00 00  gned_realloc....
  004033C0: 00 5F 61 6C 69 67 6E 65 64 5F 72 65 63 61 6C 6C  ._aligned_recall
  004033D0: 6F 63 00 00 00 00 00 5F 61 6C 69 67 6E 65 64 5F  oc....._aligned_
  004033E0: 6F 66 66 73 65 74 5F 72 65 61 6C 6C 6F 63 00 00  offset_realloc..
  004033F0: 00 00 00 5F 61 6C 69 67 6E 65 64 5F 6F 66 66 73  ..._aligned_offs
  00403400: 65 74 5F 72 65 63 61 6C 6C 6F 63 00 00 00 00 00  et_recalloc.....
  00403410: 5F 61 6C 69 67 6E 65 64 5F 6D 73 69 7A 65 00 00  _aligned_msize..
  00403420: 00 00 00 5F 69 74 6F 61 5F 73 00 00 00 00 00 67  ..._itoa_s.....g
  00403430: 65 74 65 6E 76 00 00 00 00 00 5F 6C 74 6F 61 5F  etenv....._ltoa_
  00403440: 73 00 00 00 00 00 61 74 6F 69 00 00 00 00 00 61  s.....atoi.....a
  00403450: 74 6F 6C 00 00 00 00 00 5F 70 75 74 65 6E 76 00  tol....._putenv.
  00403460: 00 00 00 00 5F 6B 62 68 69 74 00 00 00 00 00 73  ...._kbhit.....s
  00403470: 73 63 61 6E 66 00 00 00 00 00 77 70 72 69 6E 74  scanf.....wprint
  00403480: 66 00 00 00 00 00 70 72 69 6E 74 66 00 00 00 00  f.....printf....
  00403490: 00 5F 77 74 6F 6C 00 00 00 00 00 5F 77 74 6F 69  ._wtol....._wtoi
  004034A0: 00 00 00 00 00 5F 69 74 6F 77 5F 73 00 00 00 00  ....._itow_s....
  004034B0: 00 5F 5F 69 6F 62 5F 66 75 6E 63 00 00 00 00 00  .__iob_func.....
  004034C0: 66 70 72 69 6E 74 66 00 00 00 00 00 66 70 72 69  fprintf.....fpri
  004034D0: 6E 74 66 5F 73 00 00 00 00 00 66 77 70 72 69 6E  ntf_s.....fwprin
  004034E0: 74 66 00 00 00 00 00 66 77 70 72 69 6E 74 66 5F  tf.....fwprintf_
  004034F0: 73 00 00 00 00 00 5F 61 74 6F 64 62 6C 00 00 00  s....._atodbl...
  00403500: 00 00 5F 61 74 6F 6C 64 62 6C 00 00 00 00 00 5F  .._atoldbl....._
  00403510: 61 74 6F 66 6C 74 00 00 00 00 00 00 00 00 00     atoflt.........

[TouEnMasm]

What I mean is that you can build your own CRT with your own source code ( preferably using assembly )

That's a big work who need to be justify by a need.
An advantage of the dynamic link is that the code is generated by the tool
http://masm32.com/board/index.php?topic=581.msg4705#msg4705
and add no bug.

[jj2007]

I don't see of what you speak about the size of the code .The title of this post say all.
All is not perfect as say jochen who seem to understand only the yes no answer.
Here is a part of the executable data.
This part grow only with the number of functions in the the dynamic lib.A thousand of functions in this lib increase this part even if they are not in use.
In a static lib the size of the executable grow with the number of functions in use.

I know this is confusing, Yves, so I will try to show a very simple example:

include \masm32\MasmBasic\MasmBasic.inc   ; download
.data
szFormat   db '%s',13,10,0
szTest   db 'Test',0

   Init

   UseDynamic=1

   if UseDynamic
      Dll "msvcrt"
      Declare <printf>, C:?
      void printf(offset szFormat, offset szTest)   ; dynamically linked
      ; needs:
      ; the string "msvcrt"
      ; the string "printf"
      ; linking in LoadLibrary
      ; linking in GetProcAddress
      ; a call to LoadLibrary
      ; a call to GetProcAddress
   else
      ; needs:
      ; two dwords
      printf(offset szFormat, offset szTest)   ; statically linked
   endif
   Inkey
   Exit
end start

[hutch--]

This is the bit I miss in the suggestion, MSVCRT.DLL is effectively an OS component since Win9x days when it was added with a version of IE. Unless you want to duplicate the functions in MSVCRT, you call the existing DLL that has the DLL versions of the C runtime functions. It is not hard to make another DLL that calls MSVCRT but it puts an extra layer of DLL call between the calling app and the function. It also makes the calling app dependent on another DLL.

There is no gain in memory load as a call to MSVCRT loads it in memory anyway. Add another DLL as an intermediate and you increase the memory load, not decrease it. External DLLs have their place, especially if you want to dynamically load it rather than a static DLL but as a runtime, its going backwards to languages that need capacity like this, in assembler you don't.

[Manos]

I agree with Hutch.
It is unnecessary to write a new DLL that does the same work with a system DLL.
DLLs are useful in the follow cases:
1. When two or more applications use the same source.
2. When you have a source written in some language and you want to use the source from another language.
For example, if you have source code written in C++ and you wish to use this code in Assembly.

Manos.

[TouEnMasm]

Here is the much smaller , 1,5K
It use a dynamic link to the msvcrt.dll and call the function.
The use of Polink as linker win 1K.