"....Can be replaced by: bla bla "

No, it can't because this is a NEWBIE version!!!
If you are an optimization "guru" please optimize
my original example...ha..ha;)
Posted on 2002-06-07 16:46:59 by buliaNaza
buliaNaza, I'm a windows NEWBIE, else I'd give it a go. ;)
Is there a way to speed the load time? It is really bad.
Posted on 2002-06-07 16:53:22 by bitRAKE
Where is the true?
here:
"...I'm a windows NEWBIE, else I'd give it a go.."

or here:
"...I'm just trying to help buliaNaza understand the interface - which he is already aware of...."

"Is there a way to speed the load time? It is really bad."
I tested it with WinXP,Win2k Data Center and WinME
and all work fine for me..
My advice is: just check additional software as
firewalls, antivirus programs, some "useless" services on XP, etc.

From other point of view it is just an example not the program to be optimized...;)
Posted on 2002-06-07 17:12:57 by buliaNaza
buliaNaza, that is strange. The only program
that loads slower is VS.Net and maybe M$ Word. ;)
Truth is where you look for it. ;)
Posted on 2002-06-07 17:22:55 by bitRAKE
There is only one problem with this masterpiece, it builds at 3k but does not display at startup and sits dead in memory until you use Ctrl+Alt+Del to close it down.

Built in win95b, PIII 600, 768 meg ram.

At least it did not GP fault. :grin:

Regards,

hutch@movsd.com
Posted on 2002-06-07 21:01:30 by hutch--
Can you post your exe file here?
Posted on 2002-06-07 21:35:02 by buliaNaza
It wouldn't run for me either. At least, not until I changed the line

xor esi,0FFFF0000h

to

and esi,0FFFF0000h

and it ran fine.

Overall, bulianaza, I like the programming style. Very slick.

Of course, the whole dword etc is a little difficult to read. I imagine for common things like wParam, etc you could just use some type of EQU. Not sure if this is too HLL in your books ;)


--Chorus
Posted on 2002-06-07 22:17:29 by chorus
Thanks chorus,
Of course you are right.
The error is mine. :)
Posted on 2002-06-07 22:36:10 by buliaNaza
Here is a 2k replacement that does the stack preservations correctly. :grin:

Regards,

hutch@movsd.com

PS : Build in the standard MASM32 environment.
Posted on 2002-06-07 23:01:53 by hutch--
BuliaNaza,
I do have a couple questions for you:
Why call DefWindowProc for stuff like WM_PAINT when you're handling it? Is it just to balance the stack? couldn't this be replaced by a ret 16?
And why use mov ,r/m instead of push? Doesn't push code smaller?

Finally, I'm surprised by two things (although I understand this is a "newbie" example). One is that you process WM_CREATE to save hWnd when you could handle it on return from CreateWindowEx. And the other is this bit of code from WM_DESTROY:



.if eax == IDNO ;
jmp WinMainExit ; loop again
.endif ;
jmp ExitProcess ; Exit


just because I thought .if and other directives were "bad" ;)

Take it easy

--Chorus
Posted on 2002-06-07 23:04:15 by chorus
Sorry about the bloated excess of the last demo, it was done in a hurry, here is the 1.5k version that does its stack preservations correctly. :)

I question the wisdom of using difficult techniques that do not build smaller, are no faster, are far more difficult to read, are very difficult to develop into a large size app and are so slow to work on that they would be ready for the release of win3k.

Regards,

hutch@movsd.com

PS : Interesting that this post has the same number as the byte size of the posted example. :tongue:
Posted on 2002-06-07 23:46:05 by hutch--
Chorus, the subject here is "TO PRESERVE REGISTERS OR NOT"
rather my programming style...
All your questions are related to my own programming style. Well...;)

"..One is that you process WM_CREATE to save hWnd when you
could handle it on return from CreateWindowEx..."
Of course you can save hWnd after CreateWindowEx but
you can't use it in OnCreate proc; you need to get the right
window handle from the stack again in OnCreate proc, if you
need to create child windows. So you have one operation more..

"...just because I thought .if and other directives were "bad"..."
You are right but this is "an easy reading" for people which
understand INVOKE and other HLA stuff ONLY...More Info: in
smalwin.zip and smalwin2.zip(If you are lazy to download them
just read Generic.asm from your \MASM32\EXAMPLES\GENERIC
directory. Very usefull reading!!! )

"Why call DefWindowProc for stuff like WM_PAINT when you're
handling it? Is it just to balance the stack? couldn't this be
replaced by a ret 16?"
This question is a bit more complicated...

We may have or haven't a calling system procedure to return 0.

We have a calling system procedure when the system fills the
stack with parameters and directly call WinProc (in our program
when cmp esp, dStack is NOT zero; because we have parameters)

We haven't a calling system procedure when
cmp esp, dStack is ZER0; we haven't parameters and we must
use GetMessage to get the next message from the queue.

So, I use safety DefWindowProc because:
from MSDN -> "Your application can call the DefWindowProc
function as part of the processing of a message. In such a case,
the application can modify the message parameters before
passing the message to DefWindowProc, OR IT CAN CONTINUE
WITH THE DEFAULT PROCESSING AFTER PERFORMING ITS OWN
OPERATIONS. "

"And why use mov ,r/m instead of push? Doesn't push
code smaller?" This question was from your homework...
Well, if you use push to call GetMessage what happen:


push 0
push 0
push 0
push offset msg ;msg MSG <>
call GetMessage
Label_1:
or
push 0
push 0
push 0
push offset msg ;msg MSG <>
push offset Label_1 ; return address
jmp GetMessage
Label_1:


Now you have four "important" parameters for WinProc in msg.
But you need these four parameters in the stack rather in msg!!!
Here is the stupidity because you must get these parameters
from msg and push them into the stack. Return addresses too...
A lot of code and one useless structure - msg...In the MS
programs that is a job for DispatchMessage API...Again a lot of
code...So, I know where the next proc (WinProc) will looking for
parameters in the stack and now I'm just loading the stack with
the right numbers...Easy!
From other point of view Intel and particularly Agner Fog prefer
the usage of the mov directly to/from stack rather push/pop for
the new processors!?
;)
Posted on 2002-06-08 03:27:16 by buliaNaza
buliaNaza, I don't know what to say.... This is beyond my imagination of ASM (back to the hard way but even BETTER ) This prove that many things that was thought impossible was always possible.... I knew it all the time but i did not have a clue until now....

I know enough about ASM to take the plunge into this new pit of ASM HELL.... It's not going to be easy but i want to know how to do a few things based on your code...

Boss Style buliaNaza, , it's hard to believe that you BACK UP nearly everything you did.

I would like to see what Maverick have to say about this...In my option he's your match.

Thanks for cluing some of us up...
Posted on 2002-06-08 06:48:53 by cmax
There is one api i would like to put a lock down on B Style and that is SendMessage. Would i use your GetMessage setup to do the same... I think SendMessage eats up a lot of Windows memory when our programs use it extensively as i do in my app. But it could be something else wrong with-in my hook but i would like to tackle SendMessage first for the record.

PS: I forgot to mension acnev to be included in that match of super programmers....I will not included Hutch because he is of SANE mind and we need that to Survive :)

Well amyway, It is very new to me.
Posted on 2002-06-08 11:56:46 by cmax
Hutch, I commend you on your short, sweet, and elegant code.
But there are two things that kind of bother me a little:

1) You seem to call dispatchMessage once without a GetMessage. This seems like a felony to me, how do you get away with it.

2) In your first example the pointer you send to RegisterClassEx was in the stack, and you restored the part it was in right after. Does this mean that RegisterClassEx makes a copy of the WNDCLASSEX structure. If so then couldn't you have one copy of the structure and modify it for each call to RegisterClassEx you need to make?
Posted on 2002-06-08 15:27:04 by Satrukaan

I would like to see what Maverick have to say about this
Hi cmax, sorry.. I came into this thread by "accident", and didn't read most of it. I should say something about which matter? I'll be glad to help.
Posted on 2002-06-08 16:10:40 by Maverick
Hi again.. I quickly checked some of the tons of posts above. If I'm not mistaken, the matter here is "real men optimize also the code around a ExitProcess call".. or something like that.

My (personal) views on this is that assembly is there to be used for a reason, i.e. speed, efficiency, and so on.. but we've to be practical as well, and this means also preserving the registers modified by a Win32 function, if that is more comfortable and less bug-prone, and if that maybe takes millions of cycles to complete anyway (making the advantages much more important of the practically non-existant disadvantage, there).
This is not ideal, but saves you development time for much more serious and important things, so at the end it pays more than you spent on it. Looking for a bug when you're on a deadline, and then discovering it was your super optimization around the call to ReadFile, is really quite stupid.

But e.g. in a important innerloop I'd never want to see performance sacrified for source readability or such. That would be against the sense of assembly programming in this HLL age.

Some coders just can't write full, giant programs, so they tend to concentrate on state of the art useless stuff.. like optimizing where it doesn't matter, but then running out of time for the real things. I'm very perfectionist myself, and I've tons of uselessly optimized stuff, but real life has forced me into being productive as well.. so now I know when it's time to stop with a perfectionism that may not prove useful, and steal too much very-precious time.

I mean, I've no problems to call "wannabe elitish stupidity" if one has to write suboptimal code and not exploit all of the registers where it matters, just to keep some free for a Win32 API call that wastes anyway millions of cycles to complete. Also, often that kind of coders are also lame at the end, and very full of themselves and mean to the nice guys out there, which are here just for friendship and to learn and to share what they can offer to the other dudes.
Posted on 2002-06-08 16:44:20 by Maverick
If there is no point in optimizing everything then what is the point in coding entirely in assembly?
Would it not be better to just code in C and use assembly in critical sections of code that don't rely on calls to window's api.
Posted on 2002-06-08 17:16:11 by Satrukaan
Only if you consider C like God's solution.

Personally, when I've been asked to write something and I was given a C function to be included (and write the rest), I've just compiled the C function to assembly and included that to my assembly program.

So, inline assembly in a C program can be as well replaced to inline C into an assembly program.

Still, even in C it doesn't make sense to waste time optimizing e.g. the code around a call to ReadFile that has to read a 10 MB file.

Time is too precious to be wasted like that, considering all the more important parts that need optimizations.

No, this doesn't translate to it's better to code in C and add some inline asm, that's a whole other matter.
Posted on 2002-06-08 17:40:30 by Maverick
Hi Maverick,;)

"Hi again.. I quickly checked some of the tons of posts above. If I'm not mistaken, the matter here is "real men optimize also the code around a ExitProcess call".. or something like that."

I'm sorry but you are out of class again...
You just don't know what you are talking about..

I'll repeat: the subject here is "TO PRESERVE REGISTERS OR NOT"
rather my programming style...
All your soft nothings are related to my OWN programming style!!!..

I'm wondering now why you hate me for my programming style? It is mine not your!

I saw your style:
"I've just compiled the C function to assembly and included that to my assembly program."
and don't hate you for that because it is YOUR business not mine...

My team and I receive our salaries and shares to write, test and implement fast and as small as possible assembly code, because we have strong competitors in our market, so if my style offends you just forget about it...

I appreciate the people here by their code rather their soft nothings, because often they are very emotional.
I'm just curios how you appreciate unknown people from different cultures...
.;)
Posted on 2002-06-08 19:57:54 by buliaNaza