flat assembler
> Main > All standard library functions and FASM headersGoto page 1, 2 Next |
| Author |
|
|
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 
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. |
|||
31 Jul 2018, 07:50 |
|
|
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. |
|||
|
31 Jul 2018, 10:36 |
|
|
Okay, thanks a lot, I'll check MSDN.
As for Linux, I guess it's not the same thing, is it? |
|||
|
31 Jul 2018, 11:18 |
|
|
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, ... |
|||
|
31 Jul 2018, 11:23 |
|
|
Thank you for the information
I think I can then say that everything in kernel32 (ExitProcess API DLL) are Windows APIs, is that true? |
|||
|
31 Jul 2018, 15:26 |
|
|
Mino wrote: Thank you for the information 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. |
|||
|
31 Jul 2018, 15:28 |
|
|
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… |
|||
|
31 Jul 2018, 18:41 |
|
|
DimonSoft wrote: Is msvcrt.dll actually considered part of Windows API? |
|||
|
31 Jul 2018, 19:15 |
|
|
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. |
|||
|
05 Aug 2018, 10:28 |
|
|
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 |
|||
|
05 Aug 2018, 10:55 |
|
|
That's good to know, thanks
But why should we call printf into hooks [printf] ? Don't the hooks represent the address of the object in memory? |
|||
|
05 Aug 2018, 11:38 |
|
|
_________________ Asm For Wise Humans |
|||
|
05 Aug 2018, 11:43 |
|
|
Mino wrote: That's good to know, thanks 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. |
|||
|
05 Aug 2018, 12:06 |
|
|
Mino wrote: That's good to know, thanks 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. |
|||
|
05 Aug 2018, 20:53 |
|
|
Thanks, I understand better now
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? |
|||
|
05 Aug 2018, 22:02 |
|
|
any call to any module would require [] whether winapi or your dll
unless its a label in your module |
|||
|
05 Aug 2018, 22:06 |
|
|
Okay, thanks
|
|||
|
05 Aug 2018, 22:28 |
|
|
revolution wrote:
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. |
|||
|
11 Aug 2018, 22:39 |
|
|
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.
|
|||
|
11 Aug 2018, 23:44 |
|
|
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. |
|||
|
12 Aug 2018, 09:26 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|