flat assembler
Message board for the users of flat assembler.
Index
> Windows > "library" directive is an invalid instruction |
Author |
|
revolution 07 Dec 2017, 01:35
library is a macro. An easy way to define it is to include one of the base header files (eg. win32a.inc).
Code: format PE GUI 4.0 entry start include 'win32a.inc' section '.text' code readable executable start: invoke SetLastError,0 invoke ShowLastError,HWND_DESKTOP invoke ExitProcess,0 section '.idata' import data readable writeable library kernel,'KERNEL32.DLL',\ errormsg,'ERRORMSG.DLL' import kernel,\ SetLastError,'SetLastError',\ ExitProcess,'ExitProcess' import errormsg,\ ShowLastError,'ShowLastError' |
|||
07 Dec 2017, 01:35 |
|
Ben321 07 Dec 2017, 03:39
revolution wrote: library is a macro. An easy way to define it is to include one of the base header files (eg. win32a.inc). But doesn't including win32a.inc automatically import all of the Windows API dll files, thus removing the need to ever call the library macro? |
|||
07 Dec 2017, 03:39 |
|
revolution 07 Dec 2017, 03:55
Ben321 wrote: But doesn't including win32a.inc automatically import all of the Windows API dll files, thus removing the need to ever call the library macro? |
|||
07 Dec 2017, 03:55 |
|
Ben321 07 Dec 2017, 08:11
revolution wrote:
I just opened win32a.inc in a text editor, and found it also loaded a bunch of other stuff than just macros. It also loaded definitions of Windows API structures (like BitmapInfoHeader, and other similar things). That's a bunch of unnecacary overhead, so I found a work around. I can directly Include the required file by doing: Code: include "macro\import32.inc" This includes the 2 macros required for importing DLL functions, which are "library" and "import". Really though, these 2 statements ("library" and "import") should be built-in compiler directives, not macros defined in a .inc file, so that you don't need to add them in every program you write. Having to use the same "include" statement in every single program you write, just so you can import DLL functions in your program (which is very basic functionality in a compiler) seems like unnecessary extra lines of code. |
|||
07 Dec 2017, 08:11 |
|
Tomasz Grysztar 07 Dec 2017, 12:01
Ben321 wrote: Really though, these 2 statements ("library" and "import") should be built-in compiler directives, not macros defined in a .inc file, so that you don't need to add them in every program you write. Having to use the same "include" statement in every single program you write, just so you can import DLL functions in your program (which is very basic functionality in a compiler) seems like unnecessary extra lines of code. Even the "basic functionality" of constructing import table that you mentioned is something that may be done in different ways depending on the requirements of an environment. Note that PE format is used by different systems and for various purposes (and anyone playing with OS development may also add new ones to the growing list). What is a good way to construct an import section in most of the regular Win32 programming, may not be enough in other cases. Some PE loaders may expect the structures to be set up differently (the PE specification leaves a lot of room for variation) and some people may prefer to simply set up an import generation in an entirely different way (the syntax that is used by the "library" and "import" macros is a legacy from the times when fasm's macro abilities were less developed). I tried to provide a set of robust building blocks that can be used to construct supplementary layers of the language with a high degree of control (it is something I once called "complex solutions with simple features") and I have seen people using it with very interesting results. This lead to the development of fasm even further in this direction, and fasmg is the ultimate manifestation of that. |
|||
07 Dec 2017, 12:01 |
|
revolution 07 Dec 2017, 14:59
Ben321 wrote: Really though, these 2 statements ("library" and "import") should be built-in compiler directives, not macros defined in a .inc file, so that you don't need to add them in every program you write. Having to use the same "include" statement in every single program you write, just so you can import DLL functions in your program (which is very basic functionality in a compiler) seems like unnecessary extra lines of code. For most uses it is only one extra line in the source. But compare that to some other assembler that requires you to make ancillary files for "make" and/or "link", plus all that extra typing on the command line with all sorts of switches and things every time you want to assemble something. All-in-all I think the amount of work and cognitive load is less when dealing with fasm. But your usage may vary. |
|||
07 Dec 2017, 14:59 |
|
Ben321 07 Dec 2017, 21:47
revolution wrote:
Those 2 things though are common to every EXE file ever. You need a library and import statement, just to get to the ExitProcess function, which is the correct way to terminate a Windows program (not a RET opcode, as that only terminates the current thread, and if your process has more than one thread the rest of them will keep running in the background). |
|||
07 Dec 2017, 21:47 |
|
revolution 08 Dec 2017, 00:15
If you use 'win32ax.inc' (note the extra 'x') then you can use the .end macro instead of library and import.
Code: ; example of simplified Windows programming using complex macro features include 'win32ax.inc' ; you can simply switch between win32ax, win32wx, win64ax and win64wx here .code start: invoke MessageBox,HWND_DESKTOP,"Hi! I'm the example program!",invoke GetCommandLine,MB_OK invoke ExitProcess,0 .end start |
|||
08 Dec 2017, 00:15 |
|
Tomasz Grysztar 08 Dec 2017, 07:19
Ben321 wrote: Those 2 things though are common to every EXE file ever. |
|||
08 Dec 2017, 07:19 |
|
Furs 08 Dec 2017, 13:06
Ben321 wrote: Really though, these 2 statements ("library" and "import") should be built-in compiler directives, not macros defined in a .inc file, so that you don't need to add them in every program you write. Having to use the same "include" statement in every single program you write, just so you can import DLL functions in your program (which is very basic functionality in a compiler) seems like unnecessary extra lines of code. Or do you want to make kernel32's API also "builtin" into the assembler because it's "common" to any exe file? |
|||
08 Dec 2017, 13:06 |
|
Ben321 08 Dec 2017, 19:41
Furs wrote:
Actually they don't. To enable imports, all you need to to have this one include line: Code: include "macro\import32.inc" Unlike most code examples shown for FASM, there's no need to include anything related to the Windows API. |
|||
08 Dec 2017, 19:41 |
|
Furs 09 Dec 2017, 00:02
Yes, but I was replying to what you said. No Windows program can function without kernel32 API (at the very least) if it uses any imports at all, so using that logic, we should also include it in the compiler.
|
|||
09 Dec 2017, 00:02 |
|
Ben321 09 Dec 2017, 01:40
Nope. It's even more basic than this. Import and Library should both be internal commands in fasm. With those 2 commands, you can then import any dll functions that you need.
|
|||
09 Dec 2017, 01:40 |
|
Tomasz Grysztar 09 Dec 2017, 09:28
Ben321 wrote: Import and Library should both be internal commands in fasm. It would be possible to allow both alternatives - to use an internal command or construct the structures manually. But an effort dedicated to implementing this would feel like a waste of time when the macros are so simple and easy to maintain (they also serve an additional educational purpose by showing how simple it is to generate these structures). The general direction of the development of fasm was always in the direction of more control, and after I made a PE formatter for fasmg, entirely a macro, I no longer feel a need to look back. If I ever come to make a fasm 2 based on fasmg engine, I'm pretty sure that I would want to preserve the formatters in the macro form that are already made for fasmg (this would require making instruction handlers call a user-defined macros to generate the immediate/displacement fields in cases when relocations are needed, but fasmg engine already has tools for this), They allow for all the control one might ever need, and maintaining them is a pleasure. |
|||
09 Dec 2017, 09:28 |
|
Ben321 10 Dec 2017, 16:50
Tomasz Grysztar wrote:
What if the import and library macros were built into fasm, and then by default they were included automatically (prepended to the source code) when you hit the compile button? You don't have to use them if you don't want but they should always be available without having to manually include an external file containing these 2 macros. As for more flexibility, maybe just allow one to declare a special named section like .peheader, and anything put there automatically starts at the beginning of the file, instead of the code section. |
|||
10 Dec 2017, 16:50 |
|
Tomasz Grysztar 10 Dec 2017, 17:02
Ben321 wrote: What if the import and library macros were built into fasm, and then by default they were included automatically (prepended to the source code) when you hit the compile button? You don't have to use them if you don't want but they should always be available without having to manually include an external file containing these 2 macros. However, avoiding an INCLUDE directive in the source could be possible with something like fasmg's "-i" command line switch (this is a feature that I actually considered for backporting). Ben321 wrote: As for more flexibility, maybe just allow one to declare a special named section like .peheader, and anything put there automatically starts at the beginning of the file, instead of the code section. |
|||
10 Dec 2017, 17:02 |
|
Ben321 11 Dec 2017, 04:19
Tomasz Grysztar wrote:
Would it really require a rewrite of fasm's formatter? It would seem to only require adding a few lines of code to add the new features. You wouldn't need to change any existing features. As for different versions, the Linux version should have linux-specific features, and the windows version should have windows-specific features. |
|||
11 Dec 2017, 04:19 |
|
revolution 11 Dec 2017, 05:47
Ben321 wrote: As for different versions, the Linux version should have linux-specific features, and the windows version should have windows-specific features. |
|||
11 Dec 2017, 05:47 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.