flat assembler
Message board for the users of flat assembler.

Index > Windows > C runtime library


do you use C runtime library?
yes
31%
 31%  [ 6 ]
no
68%
 68%  [ 13 ]
Total Votes : 19

Author
Thread Post new topic Reply to topic
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
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.
Post 18 Apr 2004, 21:19
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
1. Well, as old Pascal (and Delphi) programmer, I simply don't like C calling convention. Smile
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. Smile
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.
Post 18 Apr 2004, 22:42
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Wink

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 Wink
Post 19 Apr 2004, 00:50
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
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...
Post 19 Apr 2004, 03:23
View user's profile Send private message Yahoo Messenger Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
f0dder wrote:
...never going to beat a single DWORD lookup Wink


Hi, f0dder.
It is interesting, but I also think about this idea again and againg these days. Smile 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.
Post 19 Apr 2004, 04:36
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
johnfound: hey, that's best way i've ever seen. I thought it handles strings like DOS Pascal, with size word instead of byte
Post 19 Apr 2004, 04:49
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
vid wrote:
johnfound: hey, that's best way i've ever seen.


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 Wink ) OS I am sure that it's API will work with Pascal style strings, without zero terminators.

Regards.
Post 19 Apr 2004, 07:23
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Yeah, I was originally introduced to this string type back with Turbo Pascal 6.0 Smile. Add in some *proper* dynamic allocation (and a static buffer for small strings), and you're on a rampage Wink. 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 Smile
Post 19 Apr 2004, 23:00
View user's profile Send private message Visit poster's website Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 318
Vortex
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

_________________
Code it... That's all...
Post 20 Apr 2004, 10:30
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
I never missed it, never used it can deal without:)
Post 25 Apr 2004, 20:28
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Foamplast



Joined: 07 May 2004
Posts: 36
Location: Saratov, Russia
Foamplast
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?
Post 07 May 2004, 21:30
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.