Win32 calls. Register usage?

Index > Windows > Win32 calls. Register usage?

Goto page Previous 1, 2, 3 ... , 9, 10, 11 Next

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 08 Jun 2009, 18:39

Azu wrote:

For the last motherfucking time http://board.flatassembler.net/topic.php?p=95565#95565

So where is the misquote? You keep posting the same stuff over and over but it shows no misquotes from me.

08 Jun 2009, 18:39

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 08 Jun 2009, 18:47

k, you've officially pissed me off now, congrats. Bye.

08 Jun 2009, 18:47

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 09 Jun 2009, 20:33

Wow this thread reached epic proportions in the meantime I was last here Laughing

If you do:

Code:

wsprintf("Some value: %d, something else: %d",just_one_argument);

and you use this as a strong point for cdecl I would say, switch to a fucking language like .NET or some automatic garbage cleaner shit.

A freaking standard that will hurt responsible programmers who pass the correct number of parameters because of a few braindead ones who, instead of admitting they made wrong code and CORRECTING it (we all make mistakes) they prefer to let the junk stink and decay. Hey, at least the garbage collector is doing your job! Rolling Eyes

revolution wrote:

pal: nothing wrong with that, just that it is not a standard HLL calling standard. In asm you can do whatever you like to calling conventions, no discussion necessary. In HLL, you have to follow the standards.

The original discussion point was that the single WinAPI function that is vararg "should be stdcall also". I think it has been well and truly proven by now that it is not sensible for many reasons.

You are repeating the same nonsense over and over again. Yes we got the point that it is a "standard".
Standards are not given by God. What is wrong in saying that the standard is shit and that it shouldn't have existed and it should have been different in the first place?

Seriously, what is so hard to understand? You're using the "it's standard" argument over and over, but really... do you worship them or something that no one can say why they suck and that from day 1 they could have been something else (i.e a different standard, even in HLLs)?

_________________
Previously known as The_Grey_Beast

09 Jun 2009, 20:33

kdownload

Joined: 31 Oct 2008
Posts: 18

kdownload 09 Jun 2009, 20:41

What about pushing EBP? I mean, is that not what EBP is for anyway? For every function call, preserve it. If you really want something that doesn't make sense, the 64bit equivalent standard for linux uses the lower dword for each floating point param... and if that's not enough, you have to store the count in rax... At least you don't have to monitor the number of params on the stack...

09 Jun 2009, 20:41

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 09 Jun 2009, 21:27

considering the only cdecl function you people seem to care about is wsprintf and that is just a wrapper for wvsprintf you'd think people would just make there own instead of complaining about it... its like 7 instructions...

there are a ton of reasons why cdecl is a good calling standard, it allows for the caller to be much more flexible in coding style than stdcall.

09 Jun 2009, 21:27

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 10 Jun 2009, 01:33

I am not blaming just one function I blame the whole standard. I just express why cdecl is the wrong standard to use in HLLs. Yes it may be useful in asm because of flexibility. Not in HLLs though. It should have been replaced long ago.

10 Jun 2009, 01:33

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 10 Jun 2009, 06:09

arigity wrote:

considering the only cdecl function you people seem to care about is wsprintf and that is just a wrapper for wvsprintf you'd think people would just make there own instead of complaining about it... its like 7 instructions...

there are a ton of reasons why cdecl is a good calling standard, it allows for the caller to be much more flexible in coding style than stdcall.

The function it's a wrapper for sucks horribly. It is an even worse standard. Passing args on the heap like that would be HORRIBLE to use directly. So it really only exists for wsprintf.. which is cdecl shit.. so they both suck!

10 Jun 2009, 06:09

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 10 Jun 2009, 13:30

Azu wrote:

The function it's a wrapper for sucks horribly.

this has nothing to do with the standard ESPECIALLY considering the function its a wrapper for is stdcall.... and its a pretty complex function its understanding that it would be confusing to look at.

Borsuc wrote:

I am not blaming just one function I blame the whole standard. I just express why cdecl is the wrong standard to use in HLLs. Yes it may be useful in asm because of flexibility. Not in HLLs though. It should have been replaced long ago.

what you can do with it doesn't change depending on if you use a hll or not, this was shown in loco's example.

also, if either of you can think of a better standard i'd definitely like to see it, what you currently suggest is crap.

10 Jun 2009, 13:30

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 10 Jun 2009, 13:34

arigity wrote:

Azu wrote:
The function it's a wrapper for sucks horribly.

this has nothing to do with the standard ESPECIALLY considering the function its a wrapper for is stdcall.... and its a pretty complex function its understanding that it would be confusing to look at.

Sorry for confusing you. I should have clarified, and will do so now; my post was in response to yours. That is why I quoted your post when I made mine.

arigity wrote:

Borsuc wrote:
I am not blaming just one function I blame the whole standard. I just express why cdecl is the wrong standard to use in HLLs. Yes it may be useful in asm because of flexibility. Not in HLLs though. It should have been replaced long ago.

what you can do with it doesn't change depending on if you use a hll or not, this was shown in loco's example.

also, if either of you can think of a better standard i'd definitely like to see it, what you currently suggest is crap.

stdcall is a much better calling standard.

cdecl is crap, and passing args on the heap is crap. Put those together and you get crappity crap A.K.A. wsprintf!

10 Jun 2009, 13:34

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 10 Jun 2009, 13:53

Azu wrote:

stdcall is a much better calling standard. cdecl is crap.

stdcall is a pretty great standard if all you care about is calling the function and getting on with your life, but it can't always be used and in some cases is a terrible idea to use.

cdecl provides added flexibility to how you interact with functions and arguments and lets the user not the function decide what stays on/off the stack with it your much less limited in code-design then you would be normally and your not limited to what the designer of the function thought was 'right'.

i still do not see a better standard.

10 Jun 2009, 13:53

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 10 Jun 2009, 14:05

arigity wrote:

Azu wrote:
stdcall is a much better calling standard. cdecl is crap.

stdcall is a pretty great standard if all you care about is calling the function and getting on with your life, but it can't always be used and in some cases is a terrible idea to use.

cdecl provides added flexibility to how you interact with functions and arguments and lets the user not the function decide what stays on/off the stack with it your much less limited in code-design then you would be normally and your not limited to what the designer of the function thought was 'right'.

i still do not see a better standard.

If you want versatility in code-design at the expense of code size.. there's a standard just for you.

It's called inline. HLLs and LLLs alike support it extensively. Enjoy.

Or just accept that wanting to preserve args is the exception not the norm, and simply use sub esp,X in these rare cases, rather then a crappy calling standard like cdecl that needs add esp,X in almost all cases..

10 Jun 2009, 14:05

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 10 Jun 2009, 14:21

Azu wrote:

If you want versatility in code-design at the expense of code size.. there's a standard just for you.

we call it progress, hey since 16 bit programs are smaller then 32 bit ones, it definitely makes more sense to code in them right? who cares about a few limitations when you can save some bytes! lets all just head back to dos, screw this gui crap, its too large.

10 Jun 2009, 14:21

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 10 Jun 2009, 14:24

GUIs are created in Windows using the stdcall standard. User-mode programs operate in ring 3 and thus can not make GUIs using inline code, so you are actually arguing against GUIs not for them.

10 Jun 2009, 14:24

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 10 Jun 2009, 14:30

Azu wrote:

GUIs are created in Windows using the stdcall standard. User-mode programs operate in ring 3 and thus can not make GUIs using inline code.

you entirely missed my point. aside from that, the gui still adds to windows size... if it was all just 1 big black box it'd be twice as small!

10 Jun 2009, 14:30

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 10 Jun 2009, 14:32

arigity wrote:

Azu wrote:
GUIs are created in Windows using the stdcall standard. User-mode programs operate in ring 3 and thus can not make GUIs using inline code.

you entirely missed my point.

Your point is that inline code = progress = GUI. I pointed out the contradiction in your point (that GUIs are made in Windows using the stdcall standard, which is almost the farthest thing from inlined code there is) though. Also, this is not an arbitrary restriction. User-mode programs ran in ring 3 and thus are physically unable to perform those types of actions inline. In fact, I'm fairly certain that all modern operating systems behave in this fashion, not even just Windows.

arigity wrote:

aside from that, the gui still adds to windows size... if it was all just 1 big black box it'd be twice as small!

Actually, most windows would have to be a lot bigger to convey the same amount of information in text as they did in graphics or graphics + some text.

Last edited by Azu on 10 Jun 2009, 14:44; edited 1 time in total

10 Jun 2009, 14:32

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 10 Jun 2009, 14:43

Azu wrote:

Your point is that inline code = progress = GUI. I pointed out the contradiction in your point though.

progress = larger size. things get BIGGER as time goes on.
64 bit code > 32 bit code >16 bit code
16 bit code still works even on 64 bit os's, lets all just nix out useful things because it takes up too much space.

Azu wrote:

Actually, most windows would take up a lot more space to display the same amount of information in text as they do in imagery or imagery + text.

no gui system = smaller windows, i do not see how i can make this any plainer. if you do not believe me grab a copy of a dos os sometime.

10 Jun 2009, 14:43

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 10 Jun 2009, 14:49

arigity wrote:

progress = larger size.

No; progress = increase in the sum of efficiency, utility, reliability, versatility, and usability.

Thus; other factors being identical, the smallest thing has progressed most.

arigity wrote:

no gui system = smaller windows, i do not see how i can make this any plainer. if you do not believe me grab a copy of a dos os sometime.

Then let's see you display all of the information conveyed in this, using a CLI window smaller then 480x340 pixels. No lossiness allowed of course, lest you destroy your own argument.

10 Jun 2009, 14:49

arigity

Joined: 22 Dec 2008
Posts: 45

arigity 10 Jun 2009, 15:13

i don't have the patience for this -_- as soon as i prove you wrong at one point you jump to another. I'm not going to bother telling you why your idea is wrong anymore. it doesn't change anything and is a waste of my time.

10 Jun 2009, 15:13

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 10 Jun 2009, 15:15

Uh.. sorry, but you've proven nothing, and I destroyed all of your arguments. Laughing

Cya later.

10 Jun 2009, 15:15

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 11 Jun 2009, 00:16

arigity wrote:

progress = larger size. things get BIGGER as time goes on.

You speak nonsense. If it gets BIGGER and has absolutely nothing more functionality, then it's worse.
Occams' Razor, simplest thing that does a specific job is the best. Simplest for a computer is smallest.

Don't make me laugh, there is no difference in functionality between cdecl and stdcall, if the latter is adapted as I have shown previously. It's just you using the crappy bloated argument, why don't you use it on direct analogy instead?

cdecl is useful, but only for functions inside your program that are hard-coded to bring out the most out of it, and that is, dynamic stack manipulation (this also requires assembly mind you). NOT for a STANDARD API that all apps can use from.

I don't know about you, but if I had to choose between two identical (in functionality) versions of Windows, but one being 50% smaller, I know which one I would call progress, better, and more efficient, and be my choice.

_________________
Previously known as The_Grey_Beast

11 Jun 2009, 00:16

Goto page Previous 1, 2, 3 ... , 9, 10, 11 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum