I often find tons of source code written in sh**y C. But none of it contains a library which I can statically include in an asm project. I am absolutely not interested in installing an ugly C compiler devouring thousands of millions of bytes which is giving me lots of error messages even if I would compile a simple "Hello world" to compile such a library by myself.
So I would rather prefer to download a .LIB file and - if nothing other is available - a C-header file which I can easily translate into ASM.
Recently I am searching for a library for the audio compressor "wavpack" and the data compressor "7zip".

Are there any dedicated people out there who make such libraries available?

Thanks in advance.
Posted on 2008-05-25 15:43:51 by TasmDev
You can find lots of .lib files on the web, however I suggest you don't use them unless you:
A) have a good look at the code in a debugger
B) are absolutely convinced that the source is clean.

Theres a LOT of malware getting about inside LIB files - think about it, they're a choice target because the malware ends up in some innocent author's application, who gets the blame?
Posted on 2008-05-25 22:59:05 by Homer
this website http://fasmlib.x86asm.net/ has some libraries. doesn't look like it has the specific ones your looking for though. the libraries support masm, fasm, nasm and vasm.
Posted on 2008-05-28 02:05:30 by smurf

You can find lots of .lib files on the web


OK, tell me where.
Almost all of the "libraries" are C/C++ source code files, which have to be compiled first with the respective C compiler.


however I suggest you don't use them unless...


I am not a layman.


this website http://fasmlib.x86asm.net/ has some libraries.


Thanks for your help, but this is not what I am looking for. I prefer to utilize the sophisticated standard-C-libraries/DLLs from M$ which are shipped in every OS.
Posted on 2008-06-01 13:04:37 by TasmDev
In regards to 7-zip, this product is not released in DLL form, so thats why you won't find a lib for it - however I looked at the sourcecode in the SDK download, and it does contain a DLL build, but yes, you'll have to compile the sourcecode yourself - doing so will produce both a DLL AND a LIB file.
In regards to WAVPACK - the 'Windows DLL' download pack does indeed contain the LIB as well.

Anything else?

Posted on 2008-06-02 02:13:13 by Homer
As an ASM-programmer I don't want separate DLLs.

First reason:
If the worst comes to the worst this would have the user of my program to store them into the Win-Sys-directory - just only for the purpose of running this one program. I don't want to annoy users with unnecessary installation processes.

Second reason:
The program becomes OS-specific. I would have to adapt the ASM-source for different calling conventions. Only those ugly GNU-programmers do that and harass poor users with strange "tarball-gz-mingw"-installations, if they don't run on the UNOX-rail.

If I had static libraries I would be able to insert all the code into the one and only binary and could compile it with Watcom-Link for every OS or every purpose I like.

Not having appropriate libraries at disposal is one of the greatest drawbacks an ASM-programmer can have. This is one reason that makes programming in ASM intricately.
Posted on 2008-06-02 20:53:40 by TasmDev
TasmDev: no reason to dump the DLL files in %SystemRoot%, just dump them in the your application's folder... Sure, you'll have to distribute a .zip instead of a single .exe, but just how bad is that? The only real issue is that you'll bloat up size a bit unless you link dynamically against libc, but that's a relatively low hit with most compilers.

The source doesn't become any more OS-specific by linking dynamically, just like it doesn't become any less OS-specific by linking statically (and you mean toolset-specific anyway, not os-specific). Either the C library source doesn't specify a calling convention, and will be CDECL (except for x64 builds, but that would require different assembly code anyway), or it specifies a calling convention, which you'll then have to use - simple as that.

Yes, I can understand that it's a bother for you that static libraries might not be readily available, but I'm afraid that's just the way the world is. It's a good idea having a (decent) C/C++ toolchain installed anyway, so you won't have to wait for other people to recompile a library for you, in case a critical bug is found in a library you use.
Posted on 2008-06-03 06:40:51 by f0dder
lol - ouch @ libC exploits
Posted on 2008-06-03 07:27:24 by Homer

lol - ouch @ libC exploits

What do you mean by this?

If you're talking about the various unsafe libc string functions, I wouldn't recommend anybody to use them... existing libraries tend to use libc functions, though, and thus you can't really do away with it, if you wan't to use other people's code.
Posted on 2008-06-03 07:36:39 by f0dder
Actually my current project is completely in assembly and uses several DLLs, the advantages of DLLs do not magically disappear just because we are using assembly language. They provide a very modular way to distribute your package and allow for updates and enhancements to be small and manageable. For instance in RMS (my project) there are 7 DLLs that handle many of the end user specific tasks and optimiztaions while the main program is largely static and uniform for all users. Since each customer has very specific needs and formulae the idea of lumping them into an unmanageable behemoth of code would be counter-productive. There are places for static linking, for example zlibstat is one I use quite often as well as my own libraries that contain alot of the standard code snippets I use but outside of those I generally use dynamically linked files. iExpress does an adequate job of packaging the application and using DLLs allows me to target specific scenarios without rewriting alot of code or including a spaghetti of execution paths in order to optimize the program for different Windows versions, processors and instruction sets.

Donkey
Posted on 2008-06-03 22:14:02 by donkey

If you're talking about the various unsafe libc string functions, I wouldn't recommend anybody to use them... existing libraries tend to use libc functions, though, and thus you can't really do away with it, if you wan't to use other people's code


Indeed - I was referring to the issue of exploits in public libraries being inherited and distributed through precompiled binary libraries built on such public libraries... the libc string functions are just a great example.

Posted on 2008-06-03 23:56:59 by Homer


If you're talking about the various unsafe libc string functions, I wouldn't recommend anybody to use them... existing libraries tend to use libc functions, though, and thus you can't really do away with it, if you wan't to use other people's code


Indeed - I was referring to the issue of exploits in public libraries being inherited and distributed through precompiled binary libraries built on such public libraries... the libc string functions are just a great example.

They are... horrid++ :) - designed back in the dawn of time, when people didn't think about exploits etc.
Posted on 2008-06-04 08:30:17 by f0dder
The further the topic goes the further the subject changes.

I didn't ask about security exploits of .LIB-files - I asked if they are available for download somewhere.
Posted on 2008-06-08 20:38:43 by TasmDev
By the way, another reason that getting precompiled .lib files is a bad idea: you will be dependent on the libc version (and possibly also compiler) used to compile the .lib. Now, obviously libc doesn't get linked into a static library, but a thing like fgetc(), for instance, might be implemented as a macro that depends on internal data structures...

Calling convention shouldn't be a problem, and name mangling usually isn't either, as long as you stick with C and not C++ (since you plan on using with assembly, you're probably sticking with C :)). But you could face problems wrt. padding and alignment of data structures.

These are real-world issues, that tend to show up as pretty subtle bugs...
Posted on 2008-06-14 07:21:44 by f0dder
After a long time of experimenting I have found a convenient solution to compile and use different compiled C source codes in assembler programs. This extends programming possibilities immense.

I want to describe how it can be accomplished this for 32bit-libraries with the WATCOM-C-compiler.

Download WATCOM-C here:
ftp://ftp.openwatcom.org/open-watcom-c-dos-1.8.exe
or
ftp://ftp.openwatcom.org/open-watcom-c-win32-1.8.exe
(77MB, both files have the same content)

Extract the self-extracting ZIP-file to a path of your choice (I don't recommend to start the self-extracting EXE).

Create a BAT-file similar to this (name it COMPIL32.BAT, for example):

@echo off
set dos4g=quiet
set wcgmemory=?
set watcom=<!!!SET_THIS_TO_YOUR_MAIN_WATCOM_FOLDER!!!>
set include=%watcom%\h;%watcom%\h\nt;.
set wcc386=%wcc386%/q/5r/ai/aq/d0/ecd/fpi87/fp5/oaehnps/s/zm/zp#1/zz
%watcom%\binnt\wcc386 %1 %2 %3 %4 %5 %6 %7 %8 %9
set watcom=
set wcc386=
set include=

Description:
Line 4: Path to the main-WATCOM-folder
Line 6: Change this line to your preferred compiler options (invoke WCC386.EXE for a description)

To make sure that all functions can be called from assembler with "__stdcall" conventions and without name-mangling I do the following:

Edit the file %WATCOM%\H\_comdef.h, line 50:
Replace:

#define _WRTLFCONV __declspec(__watcall)
#define _WRTLDCONV __declspec(__watcall)

with:

#pragma aux default "*" \
                parm routine [] \
                value struct struct caller [] \
                modify
#pragma aux __cdecl "*" \
                parm routine [] \
                value struct struct caller [] \
                modify
#define _WRTLFCONV __declspec(__cdecl)
#define _WRTLDCONV __declspec(__cdecl)


Now it is necessary to analyze the source code for additional switches required to make. This depends on the complexity of the source and might be very difficult.
After managing this compile a file "source.c" using COMPIL32.BAT with the required switches:

COMPIL32.BAT /fi<REQUIRED_ADDITIONAL_INCLUDE_FILES> /i<REQUIRED_ADDITIONAL_INCLUDE_FOLDER> /d<REQUIRED_DEFINITIONS> source.c


Now all C-functions can be accessed by assembler like this (TASM-syntax):
Declaration:

c_lib_function proto stdcall param1:type1, param2:type2, var_params:type_var:?

Or:

.686p
.model flat,stdcall
.code
c_lib_function proto param1:type1, param2:type2, var_params:type_var:?

Calling the function (TASM-syntax):

call c_lib_function, param_1, param_2, param_var_1, param_var_2


Now the .OBJ-files can be linked together (if you use WLINK, see its documentation).
Posted on 2009-04-12 13:20:29 by TasmDev
Hi TASMDev, I assume you are working exclusively with TASM, but I have searched before for something similar using MASM.  I was looking for use a DLL without having to LoadLibrary, GetProcAddress, FreeLibrary method and stumbled across this:
http://win32assembly.online.fr/importlib.html
This may or may not help you since you have a procedure already and this does use the MASM package.
Posted on 2009-04-13 00:10:50 by GoldStar611
To create import libraries from DLLs is easer to do for TASM than for MASM. MASM has the bad habit to decorate all _stdcall-functions with pre- and suffixes. They have to be removed later with some waste of effort. Your link is proving this.
With WLIB only one step is necessary to create a ready-to-use import library:

WLIB /q /pa /c imp_mydll +mydll.dll


Given that the declaration for a function is known it can be used immediatly in the ASM-source:

includelib imp_mydll.lib
my_imp_func proto stdcall p1:type1, p2:type2
...
call my_imp_func, parm1, parm2


But my problem didn't consist in creating import libraries from DLLs - my problem is: I often can't find appropriate pre-compiled libraries for my purposes. I thought I had expressed this a long time ago. In most cases algorithms exist in C-source code only (e.g. TAR-BZ files) which must be compiled first to use it. So I thought I could communicate this idea here.
Posted on 2009-04-13 07:48:21 by TasmDev