Does an open-source assembly library exists which can replace C low-level routines ?

I'm asking this, since I use Visual C++ and there are a lot of libraries linked to every program I write, and I'm asking myself if these libraries could be rewritten into assembly.

For example, when I link my code, the following libraries are linked:
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Half of these can be removed safely, but some instructions could be easily (I mean with a few assembly instructions) rewritten.

Has anybody heard about a project to rewrite the minimum core routines into assembly (for example, printf, etc...) ?

JCM
Posted on 2002-05-16 06:15:12 by MCoder
masm32.lib
You found it in hutch's MASM32 package -> www.movsd.com
Posted on 2002-05-16 06:39:06 by bazik
You can rewrite some slow win32api like lstrlen and make your own routine etc... or rewrite a StrDup which is only available in shlwapi.dll to avoid dll dependency... but there's not much use to rewrite *all* the api...

You will still need to link some libs/use some win32 standard APIs in your program... (I don't think it would be really easy to recode CreateWindowEx for example).
Your custom functions, unless they sit on dll will make grow your executables : not a big deal...

VC is smart and only links with the libs your program uses...

About rewriting printf, if you look in your VC directory, you should see the source to the libc VC uses... most of the functions are simple wrappers to API (malloc, printf for exemple) or plain C... (strlen).

PS : can somebody please move it to the main section ? Thanks.
Posted on 2002-05-16 06:57:26 by JCP
Erm, strlen plain C? printf wrapping to a API call? When did you last
look at the MS libc source, if ever?
Posted on 2002-05-16 07:18:20 by f0dder

Erm, strlen plain C?




/***
*strlen.c - contains strlen() routine
*
* Copyright (c) 1985-1997, Microsoft Corporation. All rights reserved.
*
*Purpose:
* strlen returns the length of a null-terminated string,
* not including the null byte itself.
*
*******************************************************************************/

#include <cruntime.h>
#include <string.h>

#ifdef _MSC_VER
#pragma function(strlen)
#endif /* _MSC_VER */

/***
*strlen - return the length of a null-terminated string
*
*Purpose:
* Finds the length in bytes of the given string, not including
* the final null character.
*
*Entry:
* const char * str - string whose length is to be computed
*
*Exit:
* length of the string "str", exclusive of the final null byte
*
*Exceptions:
*
*******************************************************************************/

size_t __cdecl strlen (
const char * str
)
{
const char *eos = str;

while( *eos++ ) ;

return( (int)(eos - str - 1) );
}


I don't know if it is really the code used in the libc but if it is in the crt\src directory of VC6... and has an include named "cruntime.h" it is reasonnable to think it is used somewhere in the libc...

printf wrapping to a API call?


Maybe I wasn't clear enough here... I didn't want to mean that it was *only* simple wrappers (even if sometimes, it is), but that it must finally call APIs somewhere to use/write to the console, ie and it doesn't reimplement all the process by itself...

If you look at most sources of this directory, APIs are omnipresent... and it seems very likely that to use the console (and there is references to GetStdHandle in many source of this directory), it warps to the APIs and doesn't reinvent the wheel...
You will excuse me to not have the time to debug it to check or browse the 700+ files of the directory as a proof.

When did you last
look at the MS libc source, if ever?


No need to try to be harsh...
Posted on 2002-05-16 12:42:00 by JCP

I didn't want to mean that it was simple wrappers

That's what you wrote.

perhaps you should take a look at platform/strlen.asm instead...
and of course, obviously libc will have to call APIs *sometime*...
would you have port I/O for fwrite? No :).
the *printf is a lot more than a wrapper around wsprintf. Also malloc
does a lot more than a heapalloc, it has a lot of nice functionality
for debugging memory errors.
Posted on 2002-05-16 13:05:13 by f0dder


That's what you wrote.


My point was that the API is very frequently used to implement these functions and they don't reimplement all the process.

perhaps you should take a look at platform/strlen.asm instead...

Yep, I have read it too, but I assume the C one is used somewhere... isn't it ?

and of course, obviously libc will have to call APIs *sometime*...
would you have port I/O for fwrite? No :).


That is what I wanted to say : rewriting a win32 libc will involve the API... and then it is useless to rewrite it in an optimized manner...

the *printf is a lot more than a wrapper around wsprintf. Also malloc
does a lot more than a heapalloc, it has a lot of nice functionality
for debugging memory errors.


Of course, it is not pure and hard wrappers like tinylibc but stills malloc doesn't allocate the memory directly : it is HeapAlloc that does it... and as you said, it adds more or less useful fonctionnalities that makes the exe bigger (and not specified in the C standard, but that is another problem).

For me it is more or less simple/complex wrappers with some extras : without the API, the libc is broken... (some might argue that back in the dos days, interrupts were used to implement some things in the libc, but interupts are not exactly functions but system functionnalities).
Posted on 2002-05-16 13:26:50 by JCP

That is what I wanted to say : rewriting a win32 libc will involve
the API... and then it is useless to rewrite it in an optimized manner...

Not really. "putc" writes one byte. Even though we have disk caching in
windows, it's more efficient to cache these writes before doing a WriteFile;
thus we have the FILE streams, which have other advantages as well (formatted
output, etc). As for malloc and friends, it might be possible to do more
efficient allocation strategies than "a HeapAlloc per malloc".


(and not specified in the C standard, but that is another problem)

As long as the standard C functions work as the standard specifies,
what would the problems be? The C standard doesn't really say anything/much
about the internal implementation, it merely states what the function does.
Added integrity checking is just a bonus (the extra checking is not on by
default, you have to do a couple #defines before certain includes... thus
there's no default stuff to slow down your execution).

Without API libc is broken... well duh, without API you couldn't do
anything on win32. It's like saying without interrupts dos is broken.
The "int 21h" is for dos what the API is for win32... it doesn't really
matter that you CALL stuff under win32 while dos you did INTs. Ok, so
there's syscalls, but those aren't really portable across 9x/NT.
Posted on 2002-05-16 13:36:37 by f0dder
The VC libc is compliant to the standard but it does more than what the standard defines (which doesn't make it non-standard, I agree).
But when you are designing a minimalist libc like the one Mcoder wants to use, you try to avoid more or less useful/less code/features and concentrate on making it small, clean and standard compliant...
Posted on 2002-05-16 17:01:40 by JCP
The subject seems to have wandered some from the original question. Dragging through stuff this old is like trying to make a big deal out of 1975 mainframe fortran.

To answer the original post, while there are a lot of different routines that have been written in 32 bit MASM over the last few uears, none that I know have tried to fit into the ANSI C/C++ framework.

If you want to improve on old C runtime function, look around the code that is available and write some improvements yourself. If you can get some of them going, post them in the source code forum and you may get some very good help in making it go faster.

Regards,

hutch@movsd.com
Posted on 2002-05-16 20:33:27 by hutch--
Look at Peter Quiring's QLIB (google for it). It's a mostly-asm implementation
of libc. It's for 32bit extended dos, but a bunch of routines can be used
directly for win32 (string functions and such). Might be smaller than
MS libc, but not faster.
Posted on 2002-05-17 05:18:37 by f0dder
Hi,

ofcourse you can replace some of the functions
of the C standard lib with your own ones, but this is already be done in MASM32 package.

But you'll hardly be able to replace the core functions from dlls like: kernel32.dll user32.dll gdi.dll etc. because this is the core of the operating system.
In other words; check your compiler and linker options to permit linking of these Dlls if possible.
But even a simple application will use most of this Dlls.

Bye Miracle
Posted on 2002-05-17 09:34:21 by miracle