Index
> IDE Development > Fresh update: version 1.1.4 added to the web site. |
| Author |
|
|
JohnFound 07 Jul 2004, 22:52
Hi all.
"Fresh1.1.4 work" is uploaded to the Fresh website. There is no new features in the program itself, but there are big changes in the macro library: New stdcallEx (almost compatible with old one, but more powerfull with new options and a little bit "downgraded"  )
Also, added "turbo.inc" for high speed compilation without branch optimization - very useful for developement on slow computers. Read history.txt for details. As always, any opinions and sugesstions are welcome. Regards. Last edited by JohnFound on 16 Jul 2004, 09:58; edited 1 time in total |
|||
07 Jul 2004, 22:52 |
|
|
decard 10 Jul 2004, 16:28
Hi Tommy,
you're using XP, right? On my 98SE I didn't noticed this problem. But 98 seems to be just more "tolerant" system 
Hi John, I like new macros (as almost everything that you had developed  ), but I can't use your window proc routines in ordinary window proc (without Forms library)... 
Do you want to leave it like this or will you try to make winproc macros useful without Forms too? |
|||
|
10 Jul 2004, 16:28 |
|
|
Tommy 10 Jul 2004, 16:36
Yes, that's right decard...
|
|||
|
10 Jul 2004, 16:36 |
|
|
JohnFound 10 Jul 2004, 16:39
decard wrote: Do you want to leave it like this or will you try to make winproc macros useful without Forms too? There is one "mov ebx, [wmsg]" missing before "call JumpTo". (because TForm windows get ebx already loaded with the message). For now I wrote these macroses only to serve the visual code generation of Fresh to let me continue developement, but they can be improved of course. There are several solutions and I simply don't know which ot them to choose.
1. Include this mov regardless of the fact that is is already loaded... 2. Make more complex macroses with some argumetns that to set the type of the macro - normal window/TForm 3. Write one variant for TForm and another for simple windows... What is your opinion? |
|||
|
10 Jul 2004, 16:39 |
|
|
decard 10 Jul 2004, 16:49
Well.. (if I'm not wrong) there's also "push esi edi ebx" (and corresponding pop) missing (macro in variant #1 should include them too, so it would be wasteful).
I think that the best way would be to use variant #3 (eg winproc and formproc), but, OTOH, I don't like that so many code would be repeated... variant #2 would make whole thing more complicatd... so I dont know  ?
[edit] just btw, you should rather use "mov ebx,[ebp+12]" instead of "mov ebx,[wmsg]", just because some people like "wMsg", "uMsg" or so... [/edit] |
|||
|
10 Jul 2004, 16:49 |
|
|
S.T.A.S. 16 Jul 2004, 18:34
Hi, JohnFound
Please take a look at some lines from FASM's STDCALL.INC file Code: macro proc name,[arg] ; define procedure ...... all@args fix arg ....... macro rstargs [arg] { restore arg } macro endp ; end procedure definition ...... macro rstargs#first@args _% %_ rstargs all@args purge rstargs#first@args ...... They are missed in Fresh macro library now, though something like that was used before. In some cases this can give unpredictable results, because names of PROC's arguments are accessible from outside PROC. (They aren't local anymore.) Once I had some bad experience with this situation - that's why IMHO it's good idea to return things back.. Or may be I missed something annd this is done in some different way  |
|||
|
16 Jul 2004, 18:34 |
|
|
JohnFound 16 Jul 2004, 21:09
S.T.A.S. wrote: They are missed in Fresh macro library now, though something like that was used before. There are changes in these macroses, because I wanted to make them more "clear". The arguments are not global in any way, but they are local in the meaning of procedure local variables - as local labels with parent the name of the procedure. (actually both local vars and arguments are the same thing - offsets in the stack frame - why we should define them different ways?) The arguments are defined following way: Code: proc MyProc, arg1, arg2, arg3 but you have to use them as local labels with parent - the name of the procedure: Code: mov eax, [.arg1] mov ebx, [.arg2] add ecx, [.arg3] Actually the definition of these labels inside macroses is: Code: .#arg1 dd ? Maybe this macro library will go through another editions in the future. I am thinking about some common macroses to be used in all FASM generated applications - DOS 16, Linux, arguments with free size - byte, word, dword - even structures - the same way this is possible with the local variables. Regards. |
|||
|
16 Jul 2004, 21:09 |
|
|
S.T.A.S. 17 Jul 2004, 06:08
JohnFound wrote: actually both local vars and arguments are the same thing - offsets in the stack frame - why we should define them different ways? Old (common) way is a bit confising IMHO, so you've eliminated that problem
Of cource, I should see the line with dot
Quote: I am thinking about some common macroses to be used in all FASM generated applications - DOS 16, Linux, arguments with free size - byte, word, dword - even structures - the same way this is possible with the local variables. Yes, indeed! I guess you're thinking about something like this quick example (just to give an idea, may be it won't work) Code: struc u32 { dd ? } ;; a bit of proc macro: .#arg ...... proc MyProc, arg1 u32, arg2 u32, arg3 MyStruct Too bad for me, I like ESP-based stackframes very much, so there are some problems with local structures definitions in my case ;( |
|||
|
17 Jul 2004, 06:08 |
|
< Last Thread | Next Thread > |
Forum Rules:
|