Index
> Main > FASMLIB (FASM Standard Library Project)Goto page 1, 2, 3, 4, 5 Next |
| Author |
|
|
vid 14 Nov 2005, 18:08
here is latest development version.
<removed description, something is in the archive and things tend to change too often> anyone able and willing to contribute is highly welcomed. please post here and sign in for developing some part. see files in archive. Current assignment: vid - console module (console.inc) Reverend - conversion routines (conv.inc)
Last edited by vid on 15 Dec 2005, 11:32; edited 10 times in total |
|||||||||||
14 Nov 2005, 18:08 |
|
|
BXM 15 Nov 2005, 05:46
Hi vid. Is it an attempt to rewrite cygwin in assembly language?
|
|||
|
15 Nov 2005, 05:46 |
|
|
revolution 15 Nov 2005, 05:55
Are the numbers in the file name a date? If so then it is an old version
 |
|||
|
15 Nov 2005, 05:55 |
|
|
decard 15 Nov 2005, 19:02
Hi vid,
Why don't you use invoke macro, and Windows constants (insetad of direct values)? I also don't like that you indent code with spaces, not "<TAB>instruction<TAB>arguments"; it is only my personal preference, but now your code looks messy in my eyes. I know that discussion about it can be endless, but look at fasm source, it is very elegant and clear. |
|||
|
15 Nov 2005, 19:02 |
|
|
vid 16 Nov 2005, 10:22
i don't use those because i want to have fasmlib max. possibly reusuable. So user, instead of including all those files he may not want to include, has just to define API procedure pointers, any way he likes. One purpose of this lib is to remove accessing OS from application, so he doesn't need to include some more constants, which he wouldn't use.
about indenting - it's just about what you are used to. I'll think about rewriting it this way, shouldn't be much problems with VIM. |
|||
|
16 Nov 2005, 10:22 |
|
|
decard 16 Nov 2005, 11:08
OK, I understand, but this way you can easily make a mistake.
What about this solution: library includes windows headers, so user don't have to care about it. |
|||
|
16 Nov 2005, 11:08 |
|
|
vid 16 Nov 2005, 11:53
such mistakes would be found quite easily... when i find out API doesn't do what it shoudl. and it is IMO quite hard to make mistake with copy-pasting value from includes
 .
I just dislike having declared more than required. My reason is this: user doesn't need these equates, i can do fine without them, so why include them then? Such solution will require some double-include check, if user wants to include it too. Also the includes are there only for some DLLs, for other i would have to define my own, causing two "equate-file" styles, harder for user to learn / use. Such includes would only slow down everything, I don't think a little shorter coding time is worth of it... Maybe i could list those somewhere by the beginning of file. But problem with double-defintion will stay, and enclosing each one in "ifndef"/"endif" isn't better readable than way i use. |
|||
|
16 Nov 2005, 11:53 |
|
|
decard 16 Nov 2005, 13:31
OK then.
Check out this file. It is a small library from Fresh sources, functions for dealing with file names (eg extract extenstion from file name) and directories (create nested directory, check if dir exists...). Today I added 4 functions. You may find this file useful in the library.
|
|||||||||||
|
16 Nov 2005, 13:31 |
|
|
vid 16 Nov 2005, 19:09
it will be nice addition to fileio module, thanks. And there will be more to code for DOS and other OSes
.
I could really use some Linux FASM coder here ... |
|||
|
16 Nov 2005, 19:09 |
|
|
comrade 17 Nov 2005, 00:22
I have function here for wildcard matching:
Code: match: ;mask, string push ebx esi edi mov esi,[esp+10h] ; mask mov edi,[esp+14h] ; string xor ebx,ebx jmp .chkz .next: movzx eax,byte [esi] cmp eax,"*" jne .cmp1 inc ebx inc esi jmp .chkz .cmp1: test ebx,ebx jz .nowc mov edx,esi mov ecx,edi .cmp2: movzx eax,byte [edx] cmp eax,"*" je .cmp3 test eax,eax jz .cmp3 cmp eax,"?" je .sc lcase al mov ah,[ecx] lcase ah cmp al,ah jne .cmp3 .sc: inc edx inc ecx jmp .cmp2 .cmp3: je .cmp4 inc edi cmp byte [edi],0 jnz .next xor eax,eax jmp .quit .cmp4: xor ebx,ebx jmp .mtch .nowc: cmp al,"?" je .mtch lcase al mov ah,[edi] lcase ah cmp al,ah je .mtch xor eax,eax jmp .quit .mtch: xor ebx,ebx inc esi inc edi .chkz: cmp byte [esi],0 jne .next xor eax,eax inc eax cmp byte [edi],0 je .quit mov eax,ebx .quit: pop edi esi ebx retn 08h lcase is just a macro: Code: macro lcase expr { local .over cmp expr,"Z" ja .over cmp expr,"A" jb .over add expr,32 .over: } i think very useful |
|||
|
17 Nov 2005, 00:22 |
|
|
Reverend 20 Nov 2005, 20:57
vid: I see you assigned yourself for strlib. That's ok, but I have already started to code conversion procs even before this thread was started. I posted some time ago first version of itoa, but now nearly finished atoi, atof, ftoa, and also thought of sprintf to link all these possibilities in one proc. So what procs exactly are you willing to code for strlib?
|
|||
|
20 Nov 2005, 20:57 |
|
|
vid 21 Nov 2005, 12:57
i am now rewriting strlib from Fresh. If you want I can "assign" you to some OS-independent conversion module (let's say conv.inc). Then I (or you) should convert it to FASMLib style (error in CF, stdcall, preserve all regs except EAX etc., it's in guide.txt) and it can be there. Conversion routines are of course needed for a std library.
Later these could be linked with string library (for example itoa will create new string and return handle etc.). So if it is okay to include you conversion routines in FASMLIB let me know. Also try to convert them to FASMLIB style (well, things like proc-commenting style isn't that important, that can be adjusted anytime), otherwise i can convert them when i have time (it's exam-time in school right now  ) |
|||
|
21 Nov 2005, 12:57 |
|
|
decard 21 Nov 2005, 13:48
Do you want every function to report error in CF?
|
|||
|
21 Nov 2005, 13:48 |
|
|
Reverend 21 Nov 2005, 14:51
vid: Yes, I know I have to stick to the rules from guide.txt. In fact these procs that I am writing were from the beginning aimed at FASMLIB. So when I finish them, I will post them.
|
|||
|
21 Nov 2005, 14:51 |
|
|
vid 21 Nov 2005, 20:20
ok, i'm officially assigning you to list :]
Please post some pre-versions so we can look at it and maybe advice or discuss something. Of course you are still developer but fresh ideas may improve something |
|||
|
21 Nov 2005, 20:20 |
|
|
decard 22 Nov 2005, 11:48
You may want to take a look at my LZSS compression library. You may find it interesting. Compression isn't very impresive, but it is quite fast and easy to use.
You could "implant" it into fileio routines, something like it is done in Allegro library: when user opens or creates a file, he can decide if he want to work in compression mode. He uses normal file routines, and all compression/decompression is done transparently. He only have to pass some additional flag to file.open routine. The package also contains one more library: BitStreams. They are useful if you have to operate directly on bits. cmdline.asm contains my command line parser, proably you will write your own for the library, but you may want to take a look too. regards |
|||
|
22 Nov 2005, 11:48 |
|
|
vid 22 Nov 2005, 12:40
thx, hopefully i will take a look at it somewhat later
|
|||
|
22 Nov 2005, 12:40 |
|
|
Madis731 23 Nov 2005, 08:02
I was reading decard's post here and wondered how is it useful to have LZSS compression in everything you do. Doesn't it mean decompressing and compressin all over again every time.
I know that you might compile the final executable with packed binary inside, but why would you want to for example take a user string and pack it. I hope I got it right and if I didn't, please explain. |
|||
|
23 Nov 2005, 08:02 |
|
|
decard 23 Nov 2005, 08:43
My idea isn't to pack everything that is possible
You can pack only data file for your program (for example sprites in a game). You compress it once when making data file, and decompress it when loading the program (only once, at startup, when you read data files). In Allegro this was perfect, because a typical game required bitmaps in unpacked format, so you prepared a compressed data file, then you could open it by specifing additional flag to 'fopen' routine, and you could work with it as with any usual file. Game data was small on disk, and user actually didn't have to do anything special to unpack it. |
|||
|
23 Nov 2005, 08:43 |
|
| Goto page 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|