flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2 Next |
Author |
|
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. |
|||
![]() |
|
Okay, thanks a lot, I'll check MSDN.
As for Linux, I guess it's not the same thing, is it? |
|||
![]() |
|
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, ... |
|||
![]() |
|
Thank you for the information
![]() |
|||
![]() |
|
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. |
|||
![]() |
|
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… |
|||
![]() |
|
DimonSoft wrote: Is msvcrt.dll actually considered part of Windows API? |
|||
![]() |
|
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. |
|||
![]() |
|
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 |
|||
![]() |
|
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? |
|||
![]() |
|
_________________ Asm For Wise Humans |
|||
![]() |
|
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. |
|||
![]() |
|
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. |
|||
![]() |
|
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? |
|||
![]() |
|
any call to any module would require [] whether winapi or your dll
unless its a label in your module |
|||
![]() |
|
Okay, thanks
![]() |
|||
![]() |
|
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. |
|||
![]() |
|
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.
|
|||
![]() |
|
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. |
|||
![]() |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2019, Tomasz Grysztar.
Powered by rwasa.