flat assembler
Message board for the users of flat assembler.

flat assembler > Main > All standard library functions and FASM headers

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Mino



Joined: 14 Jan 2018
Posts: 160
Hello,
Are all C functions accessible under FASM, or are they not all available? I looked a little in the FASM files, but I can't find features such as printf, gets, ExitProcess, ... I guess, in this case, they're somewhere else. But where? And how would I know what functions there are? If there was somewhere a documentation on the subject, or a list of C functions, it would be useful to me Smile

Maybe it's in a DLL that's already in the OS... I don't know...

I would also like to know if most of the functions usable under Windows under FASM are also usable under Linux?

Thank you in advance!

_________________
The best way to predict the future is to invent it.
Post 31 Jul 2018, 07:50
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 453
Location: Belarus
MSDN gives insight on functions provided by Windows. Nearly every function description there contains a note about the DLL the function resides in.

С functions are part of C library. If the library is available as a DLL (say, msvcrt is an MS implementation), the functions become available. Also, equivalents of basic functions like strlen, strcpy, etc. are available from Windows itself without the need to tie your assembly program to a runtime for particular HLL.
Post 31 Jul 2018, 10:36
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 160
Okay, thanks a lot, I'll check MSDN.
As for Linux, I guess it's not the same thing, is it?
Post 31 Jul 2018, 11:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16133
Location: Hyperborea
Mino wrote:
Are all C functions accessible under FASM, or are they not all available? I looked a little in the FASM files, but I can't find features such as printf, gets, ExitProcess, ...
Note that ExitProcess is an API provided by Windows OS, it is not a C function. But the other two, printf & gets, are C functions provided by some HLL interface layer.
Post 31 Jul 2018, 11:23
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 160
Thank you for the information Smile I think I can then say that everything in kernel32 (ExitProcess API DLL) are Windows APIs, is that true?
Post 31 Jul 2018, 15:26
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1318
Mino wrote:
Thank you for the information Smile I think I can then say that everything in kernel32 (ExitProcess API DLL) are Windows APIs, is that true?
Yeah.

For C functions look at importing msvcrt.dll

Note that msvcrt uses cdecl calling convention, not like the rest of the Windows APIs which are stdcall.
Post 31 Jul 2018, 15:28
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 453
Location: Belarus
Furs wrote:
Note that msvcrt uses cdecl calling convention, not like the rest of the Windows APIs which are stdcall.

Is msvcrt.dll actually considered part of Windows API? I really doubt so. Just nitpicking…
Post 31 Jul 2018, 18:41
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16133
Location: Hyperborea
DimonSoft wrote:
Is msvcrt.dll actually considered part of Windows API?
No it isn't part of Windows. It is part of the C redistributable. MS like to include it with Windows because they can.
Post 31 Jul 2018, 19:15
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 160
Furs wrote:
Note that msvcrt uses cdecl calling convention, not like the rest of the Windows APIs which are stdcall.


Does that mean you have to use a macro to use a procedure? Can't we call, for example'printf' without cinvoke, stdcall, ...? Like this for example:

Code:
mov word edi, [msg]
call printf
    

_________________
The best way to predict the future is to invent it.
Post 05 Aug 2018, 10:28
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16133
Location: Hyperborea
You don't have to use any macros. They are only there to help you. If you want to call a ccall function manually you can do this:
Code:
push text
call [printf]
add esp,4 ;ccall requires the caller to adjust the stack    
Post 05 Aug 2018, 10:55
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 160
That's good to know, thanks Wink
But why should we call printf into hooks [printf] ? Don't the hooks represent the address of the object in memory?
Post 05 Aug 2018, 11:38
View user's profile Send private message Reply with quote
Ali.A



Joined: 08 Jan 2018
Posts: 133

_________________
Asm For Wise Humans
Post 05 Aug 2018, 11:43
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 453
Location: Belarus
Mino wrote:
That's good to know, thanks Wink
But why should we call printf into hooks [printf] ? Don't the hooks represent the address of the object in memory?

printf is actually a label to a dword in import data that gets replaced with actual function address by Windows executable loader. So, when calling imported functions we actually have to take the value stored in import data and use it as target address.
Post 05 Aug 2018, 12:06
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1318
Mino wrote:
That's good to know, thanks Wink
But why should we call printf into hooks [printf] ? Don't the hooks represent the address of the object in memory?
Except for the lea instruction, the hooks "dereference" what's inside the brackets. So [ebx] is like *ebx in C if ebx was a pointer. lea is the only special instruction here that is like writing &*ebx (i.e. no dereference).

printf, as DimonSoft mentions, is a label that has the address of a pointer in the IAT (Import Address Table). Basically, printf is a fixed address (relative to the base of your executable/dll) that points to a pointer which gets set on load by the application loader, to point to the imported printf. Since you don't know where printf will be loaded, this way you just refer to that pointer that the loader will substitute with its address on load.

So yes, it's an "indirect" call.
Post 05 Aug 2018, 20:53
View user's profile Send private message Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 160
Thanks, I understand better now Smile
Is it exceptionally because these are functions that come from Windows APIs, or does it often happen in other APIs? How do I know if I should use the hooks or not?
Post 05 Aug 2018, 22:02
View user's profile Send private message Reply with quote
Ali.A



Joined: 08 Jan 2018
Posts: 133
any call to any module would require [] whether winapi or your dll
unless its a label in your module
Post 05 Aug 2018, 22:06
View user's profile Send private message Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 160
Okay, thanks Smile
Post 05 Aug 2018, 22:28
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2311
Location: Usono (aka, USA)
revolution wrote:
DimonSoft wrote:
Is msvcrt.dll actually considered part of Windows API?
No it isn't part of Windows. It is part of the C redistributable. MS like to include it with Windows because they can.


rev, you know tons about Windows development, apparently, while I don't even pretend to grok any of it. But ....

Are you absolutely sure? I'm pretty sure that MSVCRT.DLL has been an integral part of the Windows default install since a long time (Win95 OSR 2??). At least, since 2k/XP, it has been included by default. That doesn't mean all (or many?) bundled Windows apps relied upon it. I honestly don't know what required it.

But it's considered a "known .DLL" since 2k/XP, so you can't override it on a local level with a replacement (AFAIK). And of course .EXE outputs from several compilers (e.g. MinGW, TinyC) rely on it always being there. And yes, newer MSVC redistributables exist (too many, in fact, ugh: try typing "where msvc*.dll").

So I would definitely say "yes, it's part of the OS", but feel free to correct me as I don't really program for Windows.
Post 11 Aug 2018, 22:39
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16133
Location: Hyperborea
Yes, MSVCRT.DLL has been included with Windows since forever. But it isn't part of the Windows system. It is just an interface DLL for programs written in C to be able to use the C standard library functions when running in Windows. If you want to read the documentation for MSVCRT you have to go to the C related pages to see how to use it. The normal Windows documentation doesn't address it.
Post 11 Aug 2018, 23:44
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 453
Location: Belarus
rugxulo wrote:
And of course .EXE outputs from several compilers (e.g. MinGW, TinyC) rely on it always being there. And yes, newer MSVC redistributables exist (too many, in fact, ugh: try typing "where msvc*.dll").

And this makes it a headache to write in C/C++: you should always remember to either turn on the static linking option for the standard library or to ship the DLLs along with your program. Some developers don’t bother which makes them as bad as .NET developers: .NET developers also think .NET is a part of Windows that is also there which is also wrong.
Post 12 Aug 2018, 09:26
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:  
Goto page 1, 2  Next

< 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-2018, Tomasz Grysztar.

Powered by rwasa.