FASMLIB is multiplatform library for x86 (32 bit) ASM programmers. It is designed to be easy to and powerful (you often have simple and powerful versions of same function). It's purpose is to get programmer rid of annoying routine coding, and to allow to write multiplatform programs easily in assembler. Also it is designed to catch many bugs in code.
There is version for win32 and linux platforms. It has support for FASM and MASM. Support for other platforms and assemblers can be added, just contact me.
Current official release is version 0.4 . Start with unpacking archive and reading file "doc/fasmlib.txt". It will point you further on how to use FASMLIB.
You can find latest version here:
- complete package (http://fasmlib.flatassembler.net/fasmlib-0.4.zip) (170KB)
- without binaries (http://fasmlib.flatassembler.net/fasmlib-0.4-src.zip) (133KB)
Post any ideas, opinions and questions here
Compliments vid,
I had a quick look and this package is very well done. :U
quote from the readme
"MASM32LIB
---------
I wouldn't list this one, if it wasn't so popular. This not-even-library is just
pure shit. It is extremelly buggy set of random small routines, without any design.
It doesn't even ALLOW you to do things properly... really, hands off this one."
Pretty contradictory wouldn't you say?
:bg
cube,
I excuse people for their inexperience of not knowing the difference between component and object design. The masm32 library is a component library, it leaves object design to people who are better tuned to what they need in their application, not the whims of some library designer.
nothing personal hutch, but the version of masm32lib i saw was really bad as library. And i was in funny mood when i was writing that, you see :bdg
I admit i have no idea what terms "object library" and "component library" mean. Maybe you could explain deeper what is masm32lib (if not the thing i understand as "library") and i change my opinion.
Anyway, functions you provide in masm32lib doesn't appear "complete" to me, whether they are part of consistent system or separate component. For example, many many error cases are not taken into account.
Hm, just curious, why calling something FASMlib which apparently supports FASM *and* MASM.
Flat Assembly Library
has nothing to do with Flat Assembler... in theory ;)
originally it was meant to be library for FASM, and later I realized it is neatly usable in other assemblers, with linking. I plan support or other assemblers (YASM should be first) too.
vid,
I am just about in front of building 2 boxes so i have had the time to have a better look at your library design. I think your idea looks good but you have a common problem in the examples you provided and that is of library granularity which is very easy to solve. Instead of bundling so many procedures together, you get a far better library by doing the extra work of putting every procedure into a seperate module.
It is normal with any language that can use a linker to do this as the linker resolves dependencies between modules and you only ever get the code your application calls and the dependencies, nothing else. Now just as an example, I had a look at the masm example DEC2HEX which builds at 13824 bytes. The following code in MASM builds at 2048 bytes.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
comment * -----------------------------------------------------
Build this template with
"CONSOLE ASSEMBLE AND LINK"
----------------------------------------------------- *
.code
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
call main
inkey
exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
main proc
LOCAL pbuf :DWORD
LOCAL buffer[64]:BYTE
mov pbuf, ptr$(buffer)
mov pbuf, input("Enter number here ",62," ")
invoke dw2hex,rv(atodw,pbuf),pbuf
print "Your result is "
print pbuf,13,10
ret
main endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start
The size difference is nothing to do with your code but rather that you have bundled all of the procedures together instead of allowing the linker to resolve any dependencies from the code that you call. FASM is perfectly capable of producing absolute minimum sized object modules and you could easily duplicate this size with your own library.
I will answer the library object versus component question when I am a bit more awake.
generally, i don't consider 13kb to be that much so it is worth of effort.
Yes, i agree such binary form would be better for users of binary form. But there is problem with portability you may not have realized. If I want to compile every file to separate .obj file, i must have format settings in every file. Format settings are not portable. So to split platform-independent part from format settings, i would in fact need TWO files for every procedure. When i will add this possibility for ELF, it's three...
I may be able to overcome this somehow, but i don't have sufficent experiences with this. As I understand it, you compile each file to .obj, and then link these .objs to one .lib. When you link with .lib, only files you actually use are defined. This would also get me rid of kernel32.lib dependency. So could someone please provide some info on creating .lib files?
PS: i think "minimal" libc code (input/output) is about 10kb and no one seemed to have problem with that.
PS2: could you please provide me compiled version of that example? I would love to test it's behavior in specific cases
I think I understand what you are doing with multi-OS code so it will depend on how much conditional assembly support you have in FASM that can be used on both Linux and Windows platforms. The idea would be to have one file for each procedure but use conditional assembly depending on the target for the code before and after the procedure. In pseudo masm notation, something like this.
IF _win_
include winstartup.asm
ELSEIF _linux_
include linuxstart.asm
ENDIF
YourProc proc args etc ....
; assembler code here
YourProc endp
IF _win_
include winend.asm
ELSEIF _linux_
include linuxend.asm
ENDIF
The idea would be to make a text template and put eaxh procedure into the middle of the template so that the common code was easy to edit while keeping the platform specific code subject to conditional assembly.
Here is a slightly tweaked version of the dec2hex example that demonstrates in a very simple format what the difference between components and objects are in basic library design, the general idea is to have a range of primatives or low level components available that you can construct higher level easier to use objects from. By then being components they are free of much of the higher level protection mechanisms like SEH and other forms of error trapping as it allows the programmer more freedom in design and how and where they place their protection methods.
The problem with the alternatives if the lowest level procedures all have protection mechanisms built into them is that when a more complex object is constructed from such low level components, there is a lot more overhead and the code is larger and slower than without it. It is almost exclusively the case that the programmer constructing the higher level object is better tuned to were an application needs to be protected than at the library construction area.
I have included the binary so it can be disassembled, it has 5 procedures in it, the two conversions, two API based console procedures and one MSVCRT function for halting the console until a key is pressed.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
include \masm32\include\masm32rt.inc
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
comment * -----------------------------------------------------
Build this template with
"CONSOLE ASSEMBLE AND LINK"
----------------------------------------------------- *
dec2hex PROTO :DWORD
.code
start:
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
call main
inkey
exit
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
main proc
LOCAL pbuf :DWORD ; buffer pointer
LOCAL buffer[64]:BYTE ; 64 byte buffer
mov pbuf, ptr$(buffer) ; write buffer address to pointer
; -----------------------------------
; get the text input from the console
; -----------------------------------
mov pbuf, input("Enter number here ",62," ")
; ---------------------------------
; display the result at the console
; ---------------------------------
print "Your result is "
print rv(dec2hex,pbuf),13,10
ret
main endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE
align 4
; ----------------------------------------------
; make a higher level object from two components
; ----------------------------------------------
dec2hex proc pstr:DWORD
push [esp+4] ; buffer address as arg for atodw
call atodw ; convert decimal string to a DWORD
push [esp+4] ; reuse string address for result
push eax ; return value from atodw
call dw2hex ; write result to original string address
mov eax, [esp+4] ; return the original string address
; so it can be used in a macro
ret 4 ; balance stack on exit
dec2hex endp
OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end start
[attachment deleted by admin]
conditional assembly would work, but i don't like i t from design point. I want completely platform-independent sources, and setup format just in one place.
But i might be able to overcome this problem with very nasty FASM trick, i have in my mind :). It's just that i don't know how to create my own .lib file. Don't you happen to have some link about creating (non-import) .lib file?
thanks for your example. here are problems i spotted:
- you completely don't check for case, when user inputs something other than number. You should check this case and warn user.
- reading 80h is not enough. user can prefix number with 100 zeroes, and still it is valid number you should be able to handle
- std input handle is NOT nescessary a console. It can be file aswell (dec2hex.exe <abc.txt).
- you can happen to have no input, in case of EOF (when input is redirected from file, or when typer hits CTRL+Z)
- entered number can be too big to fit in dword
proc text.read.dec2d stream
===========================
desc: reads adecimal number to dword (32 bit). it reads decimal digits (0-9)
and converts them to number, until it reaches non-dec character, or
until number overflows.
args: stream - handle of stream from which to read
ret: CF set on error, otherwise
EAX = value
note: - before reading, all blank characters are skipped
error: ERR_HANDLE_EOF - file pointer is on EOF
ERR_OUT_OF_RANGE - value > 4294967295
in this case nothing is read from stream.
ERR_NOT_DECIMAL - first char isn't 0-9
in this case, nothing is read from stream.
Building the static library is the easy part as long as you produce a collection of compatible object modules that a linker is designed to link into a static library. In the Windows platform Pelle's linker is an excellent tool, any Microsoft linker will link COFF format obj files. From memory the GNU linker LD works fine but I have not used it enough to be familiar with it but for Linux you should have no problems finding an ELF format linker that will do the job.
There was a redundant allocation in the example as the "print" macro allocates a fixed 128 byte buffer with the length being passed to the StdIn procedure so it cannot be broken by user input or text redirection.
The example made no special efort to protect the input from incorrect input data but this is of course the task of the programmer as the bare console input procedure and macro is the wrong place to put any specific test. It is application specific code that should specify what is tested and with an assumed DWORD signed range as is required with the conversion algo there are a number of tests that can be done. Length, then specific characters, 1st must be no greater than ascii "2" etc ... until you determine that the entered number does not exceed the range. Alternatively you could convert the input to QWORD and test if its not out of range that way.
I added a simple length check and this is the result.
............
.if len(pbuf) > 9
print "ERROR: Input too long",13,10
ret
.endif
............
H:\vidlib\dec2hex>dec2hex < \masm32\include\windows.inc
Enter number here > ERROR: Input too long
Press any key to continue ...
The windows.inc file is over 1 meg but the procedure using ReadFile will only read to the maximum number of characters specified which prevents any buffer overruns.
The slightly tweaked proc looks like this.
main proc
LOCAL pbuf :DWORD ; buffer pointer
; -----------------------------------
; get the text input from the console
; -----------------------------------
mov pbuf, input("Enter number here ",62," ")
; -----------------------------------------------------------
; make sure the user does not enter a string that is too long
; -----------------------------------------------------------
.if len(pbuf) > 9
print "ERROR: Input too long",13,10
ret
.endif
; ---------------------------------
; display the result at the console
; ---------------------------------
print "Your result is "
print rv(dec2hex,pbuf),13,10
ret
main endp
i believe it's task of conversion procedure to check validity of arguemnt it converts. That is purpose of library, otherwise you would have to check too many things before calling the conversion proc. The checking would be more complicated than conversion itself.
Limiting size of input to 9 is not enough. you are forgetting about leading zeroes. For example "00004294967295" is valid input, but "04294967296" is not. Even if you don't allow leading zeroes in your proc design (pretty weird), then checking number of characters of input is not enough ("4294967295" and "4294967295").
I wonder how did you get the "9" constant. Considering that the readen text also contains 13,10 characters, you limited input to 7 digits... ?
Also your second code contains bug - you are finding size of input with strlen function. But procedure "input" which fills buffers doesn't zero-terminate it. Also, the buffer is stored in stack, eg. it has unpredictable contents. Even if it was initialized to zeroes, using input on same buffer twice could easily produce error. You should use EAX returned from "input"
PS: I wasn't saying there will be buffer overrun when input is redirected from file. I meant to say that you are using Console*** procs, which fail silently in such case, and that you are not prepared for getting EOF on stdin. In fact, you completely ignore the size of readen text (you throw away value of eax after calling "input").
We probably differ on what is required but i do it on the basis that the programmer always knows more about what he is writing than I do so i don't impose my views on them.
If you look at the "print" macro, it already trims the trailing 13,10 from the input from the console so if you type 9 characters, thats what you get.
I gather you are not familiar with the macros in masm32, the line of code,
mov pbuf, input("Enter number here ",62," ")
use the masm macro capacity EXITM <eax> so the line is equal to,
mov pbuf, eax
The value in EAX returned from the macro is the offset of the buffer allocated in the "input" macro.
The stack is as predictable as the scope you create the variable within. If you don't need global scope, you allocate a local on the stack like normal, where you put the variable is purely where you need it. If your local procedure storage is unreliable, you have other problems that leave that stack unbalanced.
I don't know where you get the idea of what is returned by the API used in StdIn, for any text typed it always returns,
your_typed_text,13,10,0
The "print" macro calls another proc that trime the tail of the result so it ends up like,
your_typed_text,0
You are right about the tested length, it must be #,###,###,### not including the ",".
The problem with building in such a test for a console input is another user may require a different input, uper case text only, limited ranges of normal ascii characters, mixed case HEX input etc ....
A generic console procedure can be used by any of them where a dedicated one is useless anywhere else. It is very easy to filter input in a text box in GUI mode using the WM_CHAR message but generally with a console you get what is typed and must test it later.
Where we differ is in what target we are pointing code at. If the only market was the low to medium level of C programming, the type of design that encapsulates idiot proof procedures would be appropriate but with assembler programmers who are generally after performance and size of code, slow idiot proof procedures are little use to them. I have only ever catered for assembler rogrammers who will use something if its useful, modify it if its close to useful or simply write their own if they can do it better to suit what they need.
This is why I only ever write components that can be used by low level programmers as I long ago gave up on idiot proof code as there will always be a better idiot.
first of all - i still have binaries only first version of dec2hex. But i suppose (in this answer) that the masm32lib procedures are same in both. If I am wrong, you could provide me binaries of second version of dec2hex.
QuoteIf you look at the "print" macro, it already trims the trailing 13,10 from the input from the console so if you type 9 characters, thats what you get.
your_typed_text,13,10,0
but print macro is used AFTER you check length. so when you are checking length, you check it with two EOL bytes included
QuoteI don't know where you get the idea of what is returned by the API used in StdIn, for any text typed it always returns,
no it doesn't, at least in first binary. The "input" procedure looks like this:
00401108 /$ 55 PUSH EBP
00401109 |. 8BEC MOV EBP,ESP
0040110B |. 83C4 F8 ADD ESP,-8
0040110E |. 6A F6 PUSH -0A ; /DevType = STD_INPUT_HANDLE
00401110 |. E8 F7000000 CALL <JMP.&kernel32.GetStdHandle> ; \GetStdHandle
00401115 |. 8945 FC MOV DWORD PTR SS:[EBP-4],EAX
00401118 |. 6A 07 PUSH 7 ; /Mode = ENABLE_PROCESSED_INPUT/OUTPUT|ENABLE_LINE_INPUT/WRAP_AT_EOL|ENABLE_ECHO_INPUT
0040111A |. FF75 FC PUSH DWORD PTR SS:[EBP-4] ; |hConsole
0040111D |. E8 02010000 CALL <JMP.&kernel32.SetConsoleMode> ; \SetConsoleMode
00401122 |. 6A 00 PUSH 0 ; /pOverlapped = NULL
00401124 |. 8D45 F8 LEA EAX,DWORD PTR SS:[EBP-8] ; |
00401127 |. 50 PUSH EAX ; |pBytesRead
00401128 |. FF75 0C PUSH DWORD PTR SS:[EBP+C] ; |BytesToRead
0040112B |. FF75 08 PUSH DWORD PTR SS:[EBP+8] ; |Buffer
0040112E |. FF75 FC PUSH DWORD PTR SS:[EBP-4] ; |hFile
00401131 |. E8 F4000000 CALL <JMP.&kernel32.ReadFile> ; \ReadFile
00401136 |. 8B45 F8 MOV EAX,DWORD PTR SS:[EBP-8]
00401139 |. C9 LEAVE
0040113A \. C2 0800 RETN 8
and ReadFile doesn't zero-terminate. Also, the returned size is size of readen data
QuoteWhere we differ is in what target we are pointing code at. If the only market was the low to medium level of C programming, the type of design that encapsulates idiot proof procedures would be appropriate but with assembler programmers who are generally after performance and size of code, slow idiot proof procedures are little use to them. I have only ever catered for assembler rogrammers who will use something if its useful, modify it if its close to useful or simply write their own if they can do it better to suit what they need.
But this is not about being idiotproof to programmers. This is about being idiotproof to users, which is IMO always required in maximal possible range. If programmers want to use your routines to create user-idiotproof app, they must code, for every routine, twice it's size of checks.
I believe most coders want to create tools which ARE idiotproof to users. Could you show me example how to write such user-idiotproof dec2hex with masm32lib? (binary included please - i don't have working masm32 installed)
It is evident that you don't know enough about masm and the masm32 project to analyse its capacity. I have attached the test piece for the "input" macro that shows that it always returns the correct character count. This is the result.
H:\asm3\input>input
Enter characters to count input length > 1234
You have entered 4 characters
Press any key to continue ...
H:\asm3\input>input
Enter characters to count input length > 1234567890
You have entered 10 characters
Press any key to continue ...
H:\asm3\input>input
Enter characters to count input length > abcdefghijklmnopqrstuvwxyz
You have entered 26 characters
Press any key to continue ...
H:\asm3\input>input
Enter characters to count input length >
You have entered 0 characters
Press any key to continue ...
H:\asm3\input>input
Enter characters to count input length > qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
You have entered 128 charactersPress any key to continue ...
Put simply you cannot break it because it properly controls its input buffer length. It handles no input at all, 0 length to input in excess of its 128 character limit from the console.
I have actually bothered to download your library and had a look at it, for you to try and make comparisons to the masm32 library, you would need to know something about it and all of this stuff builds with the current masm32 project.
With the attached zip file, I have included the DumpPE disassembly so that you can find the bits you have missed. The StdIn procedure always returns 13,10,0 at the end of it. It is then tail end trimmed by a procedure as follows from the dump.
00401130 fn_00401130: ; Xref 00401049
00401130 55 push ebp
00401131 8BEC mov ebp,esp
00401133 8B5508 mov edx,[ebp+8]
00401136 loc_00401136: ; Xref 0040113B
00401136 8A02 mov al,[edx]
00401138 42 inc edx
00401139 3C0D cmp al,0Dh
0040113B 75F9 jnz loc_00401136
0040113D B000 mov al,0
0040113F 8842FF mov [edx-1],al
00401142 C9 leave
00401143 C20400 ret 4
Now rather than try and make comparisons to a library that is very well accepted over years of reliable use, it is probably better that you concentrate on improving your own library as it is a fundamentally good idea with FASM being portable across Windows and Linux. If you can find a way around the multiple builds you can beat the granularity problem and produce minimum sized executables which FASM is easily capable of doing.
Using C libraries as reference is off the pace for pure assembler libraries, if you don't care about the bloat and speed issues, you would be better off writing the libraries in C but I can assure you that a properly written set of library procedures in FASM will eat a C compiler alive.
LATER: Sorry about that. I have attached the file.
[attachment deleted by admin]
seems you forgot the attachment :(
so i forced myself to install masm32 (even tough to root directory). I already had the sources, but i want to be able to build binaries to demonstrate what i want to say.
I am sorry for saying input is not zero-terminated. It is done by StripLF, but not properly. Read further please.
QuoteThe StdIn procedure always returns 13,10,0 at the end of it.
No, it doesn't. It reads up to 80 characters from input. If there is CRLF on input (not nescessary), it stops on it. Stdin then returns size of readen data in EAX, which is then trashed by input macro. No zero termination is done by ReadFile in StdIn, try to initialize buffer with nonzero value and see it for yourself.
Zero termination is done by StripLF, which doesn't have any buffer overrun checking. This means that if input doesn't contain 13,10, it fails.
BUT, none of your procedures is ready for typed input size (without end-of-line) equal to 128 (80h) characters. In such case, buffer overflow occurs. Such input is valid on win32, so i consider this a bug that cannot be avoided using masm32lib. I can provide binary example if you wish, but it should be enough to see it from code:
input MACRO prompt:VARARG
LOCAL txt
LOCAL buffer
IFNB <prompt>
.data
txt db prompt, 0
buffer db 128 dup (0)
align 4
.code
invoke StdOut,ADDR txt
invoke StdIn,ADDR buffer,LENGTHOF buffer ;calls stdin with 80h size
invoke StripLF,ADDR buffer
mov eax, offset buffer
EXITM <eax>
ELSE
.data
buffer db 128 dup (0)
align 4
.code
invoke StdIn,ADDR buffer,LENGTHOF buffer
invoke StripLF,ADDR buffer
mov eax, offset buffer
EXITM <eax>
ENDIF
ENDMStdIn proc lpszBuffer:DWORD,bLen:DWORD
LOCAL hInput :DWORD
LOCAL bRead :DWORD
invoke GetStdHandle,STD_INPUT_HANDLE
mov hInput, eax
invoke SetConsoleMode,hInput,ENABLE_LINE_INPUT or \
ENABLE_ECHO_INPUT or \
ENABLE_PROCESSED_INPUT
;reads up to 128 characters, which doesn't nescessary contain CRLF.
invoke ReadFile,hInput,lpszBuffer,bLen,ADDR bRead,NULL
;size of readen data (up to 128) is stored in EAX and trashed by input macro
mov eax, bRead
ret
StdIn endp
;replaces first character 13 with 0. If there was no eol in 128 typed characters, overflows and
;destroys first byte 13 following the buffer
;also, in case when stdin is redirected from file, this trashes all data that was read, up to 128 bytes.
StripLF proc strng:DWORD
mov edx, strng
@@:
mov al, [edx]
inc edx
cmp al, 13 ;this is CR character, LF is 10, but anyway...
jne @B
mov al, 0
mov [edx-1], al
ret
StripLF endpMy suggested solution is to change code in "input" macro.
From:
buffer db 128 dup (0)
...
invoke StdIn,ADDR buffer,LENGTHOF buffer ;calls stdin with 80h size
invoke StripLF,ADDR bufferTo:
buffer db 129 dup(0) ;make space for endining zero
invoke StdIn,ADDR buffer,LENGTHOF buffer-1 ;calls stdin with 80h size
dec eax
cmp byte ptr [eax], 0Dh ;typed 79h chars + enter
je found
dec eax
cmp byte ptr [eax], 0Dh ;typed 78h chars or less + enter
jne no_eol ;jumps when user typed 80h chars, no enter
found:
mov byte ptr [eax], 0
no_eol:
stripLF causes bug here and is competely not needed. This way you can safely read input with size equal to 80h bytes. But still it doesn't work good enough for input redirected from file
also one more note about wasting space with fasmlib .obj (not .lib):
you are right about this, and i will try to find a solution. But look at yourself - define buffer for data EVERY TIME caller uses input macro??? This is not much better
One of the virtues of writing a library is to document the results and that is what the help files are for. StdIn returns the written byte length to the buffer supplied and if you need to truncate the string, it is very simple to do. Likewise the "input" macro is documented in the high level help file and it does what it is supposed to do, provide simplified console text input.
Part of what you are assuming is that of unintentional consequences from using the macro in a manner it is not documented to do. If you want far larger redirected input, you use the StdIn procedure with a large enough input buffer to hold what you point at it.
Now with this following example, I have added a bin2hex algo that drags in a 512 byte hex table yet the exe still builds at 2.5k, the virtue of proper library design with granularity issues is you never get more code than you need.
Below is an example which I will endeavour to attach this time.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
comment * -----------------------------------------------------
Build this template with
"CONSOLE ASSEMBLE AND LINK"
This test piece is designed to test redirection
on the windows.inc include file
----------------------------------------------------- *
megabyte equ <1024*1024>
.code
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
call main
exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
main proc
LOCAL pbuf :DWORD
LOCAL phex :DWORD
LOCAL blen :DWORD
mov pbuf, alloc(megabyte*2) ; allocate a 2 meg buffer
mov phex, alloc(megabyte*8) ; 4 times larger for hex buffer
invoke StdIn,pbuf,megabyte*2 ; get standard input
mov blen, eax ; store the written length
mov ecx, pbuf
mov BYTE PTR [ecx+eax], 0 ; truncate output to written length
add blen, 1 ; display the terminator as well
print "Input length of redirected file = "
print str$(blen),13,10
invoke bin2hex,pbuf,blen,phex ; convert the file to hex notation
print "Output length of written file = "
print str$(len(phex)),13,10
test OutputFile("yourfile.txt",phex,len(phex)), eax
free phex
free pbuf
ret
main endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start
If I bother to tweak the "input" macro it will be to place the buffer in the uninitialised data section so it does not increase the exe file size as truncating the text with a trailing zero is one instruction.
Lastly, while it does not effect the macros operation, the StripLF algo should test for zero. One of the young members found this a few years ago but I forgot about it. Here is its replacement.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE
StripLF proc src:DWORD
mov eax, [esp+4]
sub eax, 1
@@:
add eax, 1
cmp BYTE PTR [eax], 0
je tlfout
cmp BYTE PTR [eax], 13
jne @B
mov BYTE PTR [eax], 0
ret 4
tlfout:
ret 4
StripLF endp
OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
[attachment deleted by admin]
not really
QuoteDescription
The input macro receives text input from the console and returns the address of that text. The text cursor or the prompt and text cursor is set at the current location on the console.
Parameters
1. Optional quoted text and character notation.
Return Value
The return value is the address of the text typed at the console.
Comments
By convention, STDIN appends a carriage return / line feed pair of characters to the end of the text typed at the console. The input macro calls a seperate function that removes the CRLF pair so that the input text can be directly converted to numeric data without any problems.
you see your mistake again:
QuoteBy convention, STDIN appends a carriage return / line feed pair of characters to the end of the text typed at the console
No, it doesn't. There is no such convention, and this is not true in every case. That is why you have bug in stdin macro.
QuoteThe current version has a 128 character limit.
No, it has 127 character limit. If you type 128 characters then StripLF overflows and overwrites following data.
QuoteIf I bother to tweak the "input" macro it will be to place the buffer in the uninitialised data section so it does not increase the exe file size as truncating the text with a trailing zero is one instruction.
still it wastes size of memory required by program, which wouldn't be needed.
QuoteLastly, while it does not effect the macros operation, the StripLF algo should test for zero. One of the young members found this a few years ago but I forgot about it. Here is its replacement.
Still it is not enough. In case user types 128 'a' characters, then your 128 byte buffer will be filled. If following align doesn't produce any 0 bytes, then it still overflows. One solution would be to also declare your buffer this way:
buffer db 128 dup(?)
db 0 ;prevent overflowBut this is still not right. Only thing that "convention" assures you about size of input, is the value returned in eax from StdIn.
one more note to wasting precious 6 kilobytes with my obj: Why the hell size of hex output is 4 times size of binary??? I always thought hex representation is 2 times bigger than binary ::)
In your example, it's 4 MB of wasted space!
I am not all together sure what you wish to acheive with nitpicking at examples when the problem you have with your library design is un-necessary code that is not called by the application but gets included anyway. You need to solve the granularity problem by seperating the procedures into seperate modules. FASM is easily capable of producing minimum sized objct modules so its not a technical limit of FASM, its your bundling so many procedures together.
> one more note to wasting precious 6 kilobytes with my obj: Why the hell size of hex output is 4 times size of binary??? I always thought hex representation is 2 times bigger than binary
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
Lack of attention to detail is what causes crashes. The hex format which the algo produces is 49 bytes long for each line plus 2 bytes CRLF for each 16 bytes of binary data, 51 being 3 bytes over 48 bytes which is 3 times 16. Allocate 3 times the buffer size and watch you code go BANG when it writes past the end of the buffer.
You have kept labouring on a number of misconceptions about how much of this code works, zero terminated strings have been with us for a very long time and everyone knows how they work. What you can get with the examples you have been nitpicking is if you enter more text than the allocated buffer, it will get truncated to the length of the buffer so there is no CRLF to strip off the end of the buffer.
This is in fact what you would expect it to do if you choose to enter the full buffer length possible from the console. This was the point of posting the following output.
H:\asm3\input>input
Enter characters to count input length > qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
You have entered 128 charactersPress any key to continue ...
Contrary to your opinion, the macro and the procedures behind it cannot be broken from the command line with either maximum length console input or pressing enter with no other text entered. It is irrelevant what may happen in a Unix based OS when this code is designed to work in a Windows console and nothing else and the API code behind it will not run on anything else. This stuff was very rigorously tested when it was written and has been working reliably ever since.
Now you are simply mistaken with Windows console input,not only does it accept the characters you type at the console but it writes the 13,10 to the buffer as well when you press the enter key so when you test the bytes written count, you get the typed text AND the CRLF. The reason why you normally trim the 13,10 off the end is so it does not effect passing the number to various conversions. It is a matter of some indifference as to what happens in a Unix console or a mac or mips or whatever else when the convention for a Windows console since the introduction of 32 bit Windows does it by including the CRLF into the buffer.
QuoteI am not all together sure what you wish to acheive with nitpicking at examples when the problem you have with your library design is un-necessary code that is not called by the application but gets included anyway. You need to solve the granularity problem by seperating the procedures into seperate modules. FASM is easily capable of producing minimum sized objct modules so its not a technical limit of FASM, its your bundling so many procedures together.
the problem arises only when using MSCOFF version of library. FASM code can use FASMLIB directly by sources, so no unneeded code gets defined. But, as i told you two or three times, i agree this should be solved, and i will try to solve it.
QuoteThe hex format which the algo produces is 49 bytes long for each line plus 2 bytes CRLF for each 16 bytes of binary data, 51 being 3 bytes over 48 bytes which is 3 times 16. Allocate 3 times the buffer size and watch you code go BANG when it writes past the end of the buffer.
You are right, sorry. I had misconception about your bin2hex
about the bug: seems there is no other way to exaplain that to you, but to provide example. Attached is example of bug, with source code. If you feel i altered attached masm32 files, just replace them with original ones from masm32 package.
here is the source:
; #########################################################################
.586
.model flat, stdcall
option casemap:none ; case sensitive
; #########################################################################
include kernel32.inc
include masm32.inc
include macros.asm
; #########################################################################
.data
db 0,0
.code
start:
mov check, 13
mov eax, input("Enter 128 chars: ")
cmp check, 13
je okay
print "MASM32LIB is buggy"
okay:
exit
; #########################################################################
.data
check dd 0
end startquess what happens when you type 128 characters
[attachment deleted by admin]
When I build your source using the proper masm32.lib, and run it, I get nothing. Entering anywhere from 125 to 130 characters, check is not overwritten.
I just pasted your code into the editor, slightly modified it so it would build in masm32 and here is the source and result.
; #########################################################################
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
; .586
; .model flat, stdcall
; option casemap:none ; case sensitive
; #########################################################################
; include kernel32.inc
; include masm32.inc
; include macros.asm
; #########################################################################
.data
db 0,0
.code
start:
mov check, 13
mov eax, input("Enter 128 chars: ")
cmp check, 13
je okay
print "MASM32LIB is buggy"
jmp not_ok
okay:
print "Seasons Greetings from the MASM32 Library",13,10
exit
not_ok:
exit
; #########################################################################
.data
check dd 0
end start
The result.
F:\posted_demo>pd
Enter 128 chars: qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Seasons Greetings from the MASM32 Library
F:\posted_demo>
The input from the console is well over 128 bytes yet it runs correctly as it in fact always has done. It is truncated to 128 characters if this excessive input is entered from the console.
Both the "input" and "print" macros in part emulate a very old basic format from early ROM basic and it is done so for ease of use, Console IO is trailing edge technology and there is little to acheive apart from making it easy o use and reliable.
Note that this code was built using the old "StripLF" that exists in the current masm32 distribution, even though it only checks for ascii 13 and not zero.
QuoteI just pasted your code into the editor, slightly modified it so it would build in masm32 and here is the source and result.
so you say, you found case in which it works? Well, i found case in which it doesn't work. Quess what this means.
If you find one case where it doesn't work when it should - it's a bug. If you find case where it works when it should - means nothing.
And even in your "working" example, character 13 of "Seasons Greetings..." string is overwritten by StripLF. You can check by redirecting output to file and looking at it's contents - no 13 or 10 will be there.
Man, you really deserve your own article on DailyWTF.
Now to put this nonsense properly to rest, here is formal proof that the "input" macro does what it is published to do.
The source.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
comment * -----------------------------------------------------
Build this template with
"CONSOLE ASSEMBLE AND LINK"
----------------------------------------------------- *
.code
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
call main
exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
main proc
LOCAL pbuf :DWORD
LOCAL phex :DWORD
LOCAL lsrc :DWORD
mov pbuf, input("Enter Text ",62," ")
mov lsrc, len(pbuf) ; get the source length
add eax, eax
add eax, eax ; mul by 4 to get hex buffer length
mov phex, alloc(eax) ; allocate length * 4
invoke bin2hex,pbuf,lsrc,phex ; convert source to hex notation
print phex,13,10 ; display hex output
free phex ; deallocate hex buffer
ret
main endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start
The result. Exact input up to the specified length in the documentation then truncation to the 128 character input. Test on Win2000 sp4 CMD.EXE.
F:\posted_demo\tst>tst
Enter Text > Seasons greetings from the MASM32 Library :)
53 65 61 73 6F 6E 73 20 - 67 72 65 65 74 69 6E 67
73 20 66 72 6F 6D 20 74 - 68 65 20 4D 41 53 4D 33
32 20 4C 69 62 72 61 72 - 79 20 3A 29
F:\posted_demo\tst>tst
Enter Text > ^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
1A 1A 1A 1A 1A 1A 1A 1A - 1A 1A 1A 1A 1A 1A 1A 1A
F:\posted_demo\tst>tst
Enter Text > qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqqqqqqqqqqqqqqq
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
71 71 71 71 71 71 71 71 - 71 71 71 71 71 71 71 71
F:\posted_demo\tst>
Seems we cross posted, you are missing something with the macro, it is supposed to trim the trailing CRLF off the input string and it does this by writing a zero in the place of the first occurrence of ascii 13. Enter input in excess of 128 characters and it gets truncated to 128 bytes as the last posting proves.
Thank you again for verifying the exact output of the macro as per its specification. :bg
Yes, input does what it should. Plus, it does some extra unwanted stuff in some cases. The binary i posted (m32lib_bug) is proof it really does. It overwrites the value 13 to value 0. Is input macro intended to do this? This is major question, please reply to it:
Is input macro intended to overwrite data behind the read buffer?. I provided clear example, that under certain circumstances, it does this.
Quoteyou are missing something with the macro, it is supposed to trim the trailing CRLF off the input string and it does this by writing a zero in the place of the first occurrence of ascii 13. Enter input in excess of 128 characters and it gets truncated to 128 bytes as the last posting proves.
and exactly here is the error. Input is truncated to 128 bytes, and these bytes doesn't contain any character 13. This means "nearest character 13" is outside the buffer. Just like in my example. Even adding check for byte 0 to StripLF is not enough. After input is truncated to 128 bytes, it is not zero-terminated. There is 1:4 chance that zero is generated by following "align", but 25% is still not 0%
I have worked out how to duplicate the problem you mentioned. You just need to know a bit more about masm to display the problem as the examples you posted did not
Do it like this.
mov pbuf, input("Enter Text ",62," ")
.data
txt db "Trailing text AFTER the input macro",13,10
db "If you can read these lines then the ascii 13 preceding it has not been overwritten",13,10,0
.code
print OFFSET txt
MASM write data sequentially so the test data "txt" is directly after the text buffer for the "input" macro and this is able to demonstrate the problem you mentioned if you enter > 127 characters at the console.
The basics of doing a bug report is to post a reproducable problem where none of your examples did this.
I will post the fix for it reasonably soon now that the problem is identified. Just helps to make the masm32 macro system a little smaller. :bg
:dazzled: :dazzled: :dazzled:
i tried to explain that to you at least three times!!! And I gave you sources and binary of example which reproduced the problem.
So, another thing: The real length of input cannot be determined from buffer contents. You *must* use returned size. (hope i won't need another 10 posts to prove)
Here is the fixup. What I needed was a lot less errors in what the problem was and a report of what happened.
Quote
Is input macro intended to overwrite data behind the read buffer?.
This is what I needed to know.
Macro allocates 132 bytes in the uninitialised data section but only passes 128 bytes to the StdIn procedure. Code writes zero terminator at the end of the written buffer then the StripLF algo truncates the line on any ascii13 to a zero and exits on zero if it finds it first.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
include \masm32\include\masm32rt.inc
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
comment * -----------------------------------------------------
Build this template with
"CONSOLE ASSEMBLE AND LINK"
----------------------------------------------------- *
inputx MACRO prompt:VARARG
LOCAL txt
LOCAL buffer
IFNB <prompt>
.data
txt db prompt, 0
align 4
.data?
buffer db 132 dup (?)
align 4
.code
invoke StdOut,ADDR txt
invoke StdIn,ADDR buffer,128
mov BYTE PTR [buffer+eax], 0
invoke StripLFx,ADDR buffer
EXITM <OFFSET buffer>
ELSE
.data?
buffer db 132 dup (?)
align 4
.code
invoke StdIn,ADDR buffer,128
mov BYTE PTR [buffer+eax], 0
invoke StripLFx,ADDR buffer
EXITM <OFFSET buffer>
ENDIF
ENDM
.code
start:
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
call main
inkey
exit
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
main proc
LOCAL pbuf :DWORD
LOCAL blen :DWORD
LOCAL phex :DWORD
mov pbuf, input("Enter text ",62," ")
mov blen, len(pbuf)
add eax, eax
add eax, eax
mov phex, alloc(eax)
.data
txt db "Howdy",13,10,"If you can you see me, it works. :)",13,10,0
.code
print OFFSET txt
invoke bin2hex,pbuf,blen,phex
print phex,13,10
free phex
ret
main endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE
StripLFx proc src:DWORD
mov eax, [esp+4]
sub eax, 1
@@:
add eax, 1
cmp BYTE PTR [eax], 0
je tlfout
cmp BYTE PTR [eax], 13
jne @B
mov BYTE PTR [eax], 0
ret 4
tlfout:
ret 4
StripLFx endp
OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end start
[attachment deleted by admin]
Here is your Christmas present. :bg
I played with fasm some months ago to build a library that could be used by POASM or MASM. This has a couple of test modules, a batch file and Pelle's library manager from the MASM32 Project. The MAKEIT.BAT file has the build method and as usual you will need to set the path to fasm.
These two test modules use C calling convention as I don't know enough about fasm to set them to STDCALL but I am sure its an easy task.
[attachment deleted by admin]
I believe 129 bytes would be enough.
For your purpose (read and handle entire line at once) this solution should be enough.
But this is pretty unstandard and IMO worser than typical way of reading console - where you only read as much as you are interested in. For example, when user wants to read number, and on input you have "123abc", then "123" is readen and returned, and "abc" is left to read. Of course this needs some buffering. I believe those are functions like this, which people await from library.
Thanks for your present. I understand how to create .lib with FASM now. I am just solving issue how to do it without breaking my sources into dozen files.
nice xmas to everyone