We have a huge set of useful functions available in msvcrt.dll (which seems to be buggy) and crtdll.dll. However, many people don't use it at all. Instead they are writing their own routines. Plese write here, what are the advantages and disadvantages of using C runtime library, and if you use it or not.

1. Well, as old Pascal (and Delphi) programmer, I simply don't like C calling convention.
2. IMHO, C runtime libraryes are overbloated.
3. Of course core Windows libraries (kernel32, user32 etc.) are also written with C, but we are forced to use them if we want to have standard Windows GUI, but C runtime library is far too much.
4. In most cases using HLL libraryes for GUI (like ComCtrl32) is OK, because GUI is slow in it's nature. (Well, where it works with little data. Try to insert 500 or 1000 items in TreeView control) But using of HLL routines for data processing is not very good idea because:
4. The one of the strongest assembler sides is that we can write small pieces of code optimised for specific task. IMHO, this is the reason why assembly programs are faster than HLL programs, despite of very good optimising compilers. Wide use of big common libraryes, written for HLL together with non optimised (or weak optimised hand written code) will make assembly programs even slower than HLL programs. That is the reason I think that we should use as little as possible HLL libraryes and libraryes written for common use, especially for things that are easy to be implemented in assembler - like moving data here and there and pure numeric data processing.

Regards.

A runtime library would be a great idea, but I don't see why it would have to mimic the C standard library... especially with regards to the string functions, as the C standard library C support is *dangerous*. Besides, zero-terminated strings are slow, it's much more useful to have dynamic strings that include a "length:dword". MMX optimized strlen's might be faster, but they're never going to beat a single DWORD lookup

But a runtime library with standard stuff would be a good idea - as long as code quality is kept high, and code is small and fast. There's not much use in having a standard library if it's slow and/or bugged.

Also, it would be a good idea to keep the standard library coherent - naming convention, calling convention, documentation, grouping by functionality, etc.

Ah yes, and do consider which license to use. GPL is a bad idea

Absolutely not when programming in assembly.
Reasons:
1. I don't trust on it.
2. I don't like it.
3. I want to be free...

Hi, f0dder.
It is interesting, but I also think about this idea again and againg these days. btw: This is exactly the approach Delphi uses for it's strings. They have dword with current length of the string on [strptr-4] and terminating NULL char at the end, so the strings are compatible with ASCIIZ strings.

Regards.

johnfound: hey, that's best way i've ever seen. I thought it handles strings like DOS Pascal, with size word instead of byte

Yea, this approach is really smart. The only problem with this approach (using at the same time string length and zero terminator) is to keep string length in consistent with real string length. It is pretty easy if you use only library functions to manipulate strings, but problems may occur if you want to use both library functions and pure code. Of course you always can call strlen to update the length.
Sometimes when I think about my future ( in the far future ) OS I am sure that it's API will work with Pascal style strings, without zero terminators.

Regards.

Yeah, I was originally introduced to this string type back with Turbo Pascal 6.0 . Add in some *proper* dynamic allocation (and a static buffer for small strings), and you're on a rampage . It's not all that much use if you constantly have to convert from ASCIIZ strings, but for bulk string processing and such, this does speed up your life.

Btw, if I'm not mistaken, the UNICODE strings NT uses internally are length-counted. Too bad most people use the *A APIs, resulting in back-and-forth conversion overhead

Hi Decard,

For practical solutions in asm coding, C run-time libraries provides some usefull functions like __getmainargs,rand etc..

There is no reason to express sharp ideas \ feelings about these libraries because a coder should able to use different methods to solve problems concerning programming.

A special note about the utility of these libs, Lcc-Win32 the free C compiler uses with success the library crtdll.dll

I never missed it, never used it can deal without:)

I use kernel32 functions lstrlen(), lstrcpy(), lstrcat(), lstrcmp() and use no functions from msvcrt*.dll.

Using library functions has some advantages:

1. If the library is widely-used, you may not bother about the stability of imported functions.
2. If the program is not time-critical, you can make it smaller, because some libraries are the part of operating system, therefore their size can be considered zero.

and disadvantages:

1. I still don't know are C run-time libraries the part of the operating system or not. There are also many versions of msvcrt*.dll. What version can I use to be shure my program is compatible with all windows?

2. Interface of some functions is not documented in low-level. Suppose, for example, you decided to use atoi64() function. Where is the result (QWORD) after the call?