flat assembler
Message board for the users of flat assembler.
Index
> Windows > about fasm and windows |
Author |
|
DimonSoft 11 Jan 2018, 13:47
Tomasz will find better words to answer. I’d say it is just because FASM doesn’t try to be anything more than assembler with macros, which actually makes it even more powerful.
Ali.A wrote: why fasm dont accept .386, .486, .586? This stuff is pretty much useless. If you absolutely need to support this or that CPU generation, you can find out whether the instruction you want to use is available there yourself. You might also want to write code with different paths for different processors, but then if you choose the newest one you have no hints about incompatibilities with older processors, if you choose the oldest you can’t use newer instructions. Besides, this ties an assembler to a specific platform and makes it do stuff it shouldn’t. Ali.A wrote: same thing for model flat, stdcall, for the fact we know we have 1 memory model under 32-bit platform which is flat. Let me also say memory models are stupid for low-level programming. In real mode we have memory divided into segments. If a programmer chooses assembler as a development tool, he/she shouldn’t be limited to a small set of widely used “models”. Conventions tend to change, no need to hardcode them into language. The fact that there’s only “flat model” in 32-bit world makes .model directive useless as well. As for calling conventions, they are, again, conventions. You can invent a whole set of your own calling conventions, so there’s no need to treat some of them different from others. If you want to avoid writing the same prologues and epilogues manually, just use macros shipped with FASM. Code: include 'macro\proc32.inc' ; Or even better: ; include 'win32w.inc' ; or win32a.inc, or win32ax.inc, or... proc MyCoolProc stdcall uses ebx esi edi,\ param1:DWORD, param2:DWORD, param3:WORD locals localVar1 dd ? localVar2 dw 8 endl ... ret endp Find more in FASM help. Note also that stdcall is the default one. Ali.A wrote: as for the stack i wanted to reserve 100 (256-bit) for pushes and calls, and it gives me errors too. I guess, this is a limitation of Windows, not FASM. Stack reserve must at least be a multiple of page size, I guess. Ali.A wrote: im still not quite sure if fasm treat plain numbers as decimal and 0x64 as hex, i dont know so correct me. Plain numbers are decimal. Hexadecimals are in one of these notations: 0x5C, $5C, 5Ch. You can find more about binary and octal numbers in FASM help. Ali.A wrote: im running win7 x64, and cant specify the minimum gui version. format PE GUI x.x directive specifies GUI subsystem version, not Windows version. This is related to the internals of PE EXE format. |
|||
11 Jan 2018, 13:47 |
|
Ali.Z 11 Jan 2018, 14:35
yeah true what you said about calling conventions, and thanks for the info. (stdcall is the default)
im not sure why its related to windows (stack) seriously, who need 4KB of stack reservation? 0x and $ works perfectly for hex, with exception for 'H' if its not a number then it will be treated as text .. thanks for this one '$' ah i see, i thought windows version is same as gui version .. then how to find the gui subsystem. (even tho its not totally important to me, i do console more than gui .. its just a personal thing i dont like gui much) another question, is there any special directives for console applications in fasm? |
|||
11 Jan 2018, 14:35 |
|
revolution 11 Jan 2018, 14:41
Ali.A wrote: another question, is there any special directives for console applications in fasm? Code: format pe console |
|||
11 Jan 2018, 14:41 |
|
Ali.Z 11 Jan 2018, 14:55
yeah i know format pe console, i meant like any extra ones?
|
|||
11 Jan 2018, 14:55 |
|
DimonSoft 11 Jan 2018, 19:27
Ali.A wrote: im not sure why its related to windows (stack) seriously, who need 4KB of stack reservation? Nearly every modern OS works in protected mode (or possibly 64-bit sub-mode) with paging enabled. Paging allows OS to setup memory access rights on a per-page basis (instead of per-segment or one set of rights for the whole address space). Besides, paging makes it easier to implement virtual memory, i.e. to pretend that every application has 4 GB (in 32-bit; or whatever is currently the size of virtual address space for a 64-bit application). With paging an OS typically allocates memory for an application in page-sized chunks. Pages are either 4 KB or 2/4 MB (I may be wrong about large page sizes, need to refresh this info in my memory). But I’m not familiar enough with PE loader-related stuff, so the explanation that stack size must be a multiple of 4 KB is just my “educated guess”. Ali.A wrote: 0x and $ works perfectly for hex, with exception for 'H' if its not a number then it will be treated as text .. thanks for this one '$' 0B5CDh works fine (note the leading zero). It might also be useful to know about (still undocumented) feature: you can split numbers with underscores or apostrophes into chunks: 1001_1110b, 1010'110'1b, etc. Ali.A wrote: ah i see, i thought windows version is same as gui version .. then how to find the gui subsystem. (even tho its not totally important to me, i do console more than gui .. its just a personal thing i dont like gui much) I hope someone else can give a more detailed answer. I’ve been using 4.0 for ages and it works with every Windows starting from at least '98SE. I found out a few months ago on this forum that there’s version 5.0 already. AFAIR, I couldn’t find any decent documentation on these versions and how they are related to Windows versions so I still play on the safe side using 4.0. |
|||
11 Jan 2018, 19:27 |
|
yeohhs 11 Jan 2018, 23:12
DimonSoft wrote:
There is a list of Windows release versions. See https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions For GUI and console programs, I use 4.0 for 32-bit Windows and 5.0 for 64-bit Windows. From fasm.pdf, section 2.4.2 and fasm's example source codes, I guess 4.0 means 4.0 or later and 5.0 means 5.0 or later, so there is no need to specify the exact Windows version number for your target Windows platform. |
|||
11 Jan 2018, 23:12 |
|
yeohhs 11 Jan 2018, 23:37
Ali.A wrote:
From fasm.pdf, section 1.2.4 Quote:
|
|||
11 Jan 2018, 23:37 |
|
rugxulo 12 Jan 2018, 02:08
Ali.A wrote:
With fasmg, you can choose what includes to use (e.g. 80386.inc or avx.inc , etc), so that's almost the same, right? revolution did make some macros, back in the day, to help with this (e.g. ".086", ".386", etc), called "compatibility.inc". See Macroinstructions -> Macros to choose target CPU. Honestly, I think Tomasz said there are too many corner cases to supporting this properly, without major hassle. I think the rationale is that you'll be testing on your target hardware anyways, so you'll catch any obvious errors. More or less, you're just expected to know exactly what you're doing. |
|||
12 Jan 2018, 02:08 |
|
Ali.Z 12 Jan 2018, 07:08
DimonSoft wrote: 0B5CDh works fine (note the leading zero). It might also be useful to know about (still undocumented) feature: you can split numbers with underscores or apostrophes into chunks: 1001_1110b, 1010'110'1b, etc. yeohhs wrote: The numbers in the expression are by default treated as a decimal, binary numbers should have the b letter attached at the end, octal number should end with o letter, hexadecimal numbers should begin with 0x characters (like in C language) or with the $ character (like in Pascal language) or they should end with h letter. thank you so much both. yeohhs wrote: There is a list of Windows release versions. then ill stick wth 4.0, according to wiki link 4.0 support win95 which is great thing so thanks again. rugxulo wrote: With fasmg, you can choose what includes to use (e.g. 80386.inc or avx.inc , etc), so that's almost the same, right? first what is fasmg? i have fasm 172 well, i think i wont need this anymore cuz im not programming for dos (DimonSoft: This stuff is pretty much useless.) he is right, why would i need it .. unless i want to run some experimentation thats another story. but thanks for the post link. |
|||
12 Jan 2018, 07:08 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.