Iczelion's tutorials revisited.
hutch--
comment from Randall Hyde that indicates the level of confusion he
suffered with my original warning about people trying to cash in on
Iczelion's name.
========================================
I am especially disheartened by his attacks on people who've translated
the Iczelion tutorials to other assemblers. While I can understand that
the Iczelion tutorials have been one of the "Crown Jewels" of the
MASM32 package (in which Hutch has an obvious vested interest in
promoting), his comments concerning these translations pretty much
tells me that he is *not* so much interested in people learning
assembly language as he is in having them support his package and do
things his way. And extremely Betovian attitude that I would never have
expected out of him. Assembler wars aside, anyone learning assembly
using *any* assembler is a *good* thing. Given that MASM is definitely
the king of the hill, and is likely to remain so forever, it is hard to
understand why Hutch would feel threatened by these other translations.
Cheers,
Randy Hyde
========================================
Most people who have been around in the assembler market for ay length
of time know that Iczelion was a personal friend of mine and we worked
together designing the fundamental architecture of the MASM32 Project
and his direct contribution to the project was a subset of his
tutorials which he personally wrote for the project.
I will more than happily defend an old friend who wrote his work and
published it for anyone to USE for any programming requirement they may
have in any language they like and to make the point, his complete
original work is available from his own web site which is maintained by
another old friend of his, it is not under my cotrol and never has
been.
What I have complained about is the notion of ayone cashing in on
Iczelion's name as there has only ever been one set of Iczelion's
tutorials and those are the ones he wrote himself.
Differing from many others, Betov actually did get permission to port
the tutorials to SPASM and while I owe Betov an apology for burning his
ear here, I certainly don't owe one to anyone else who have tried to
cash in on Iczelion's name. Betov should hold his breath waiting
(WaitForSingleObject) for the apology because I more than owe Betov
some noise in response to his own. :)
Iczelion's tutorials are available at his web site for all to use for
any language they like but I will make the same warning, BEWARE OF
PHONIES, Iczelion only ever wrote in MASM and he never ported his work
to any other assembler or compiler. When someone else ports his work to
some other compiler or assembler, the result IS someone elses work and
should not be called Iczelion's tutorials.
Regards,
hutch at movsd dot com
Betov
@z14g2000cwz.googlegroups.com:
> Differing from many others, Betov actually did get permission to port
> the tutorials to SPASM and while I owe Betov an apology for burning his
> ear here, I certainly don't owe one to anyone else who have tried to
> cash in on Iczelion's name. Betov should hold his breath waiting
> (WaitForSingleObject) for the apology because I more than owe Betov
> some noise in response to his own. :)
You are wrong again: I am not a man of resentment, and
i can even accept your "no-apology" as a kind of apology:
Just stop redistributing Your MicroSoft C-Side Tool, convert
to a decent Assembler, learn how to program in Assembly, and
i promiss you that i will go and piss on your grave.
:)
> Iczelion's tutorials are available at his web site for all to use for
> any language they like but I will make the same warning, BEWARE OF
> PHONIES, Iczelion only ever wrote in MASM and he never ported his work
> to any other assembler or compiler. When someone else ports his work to
> some other compiler or assembler, the result IS someone elses work and
> should not be called Iczelion's tutorials.
You are right: Master Pdf has no right to even _mention_ any
of the volunteers who worked at the Assembly Rebirth, as he
never contributed to anything, but at damaging Assembly, when
all of the hard pionner job was done.
:)
Betov.
f0dder
> Iczelion only ever wrote in MASM
If I'm not mistaken he worked professionally in VB as well as ASP...
hutch--
==========================
Just stop redistributing Your MicroSoft C-Side Tool, convert
to a decent Assembler, learn how to program in Assembly, and
i promiss you that i will go and piss on your grave.
==========================
You are in trouble here, I have only ever been allowed to distribute
masm, never redistribute it.
Now you will have to learn how to drink pure malt before you undertake
that very unlikely task, I am fussy about what soaks through. Only pure
malt whisky filtered through your internal organs is acceptable, none
of the soap suds you are normally full of.
> who worked at the Assembly Rebirth
This is a pipe dream, assembler was resurrected from the dead by the
sheer brutal power of MASM and a lot of its friends. :) Just as an
aside, it left the tattered remains of TASM in its wake in less than 6
months.
f0dder,
> If I'm not mistaken he worked professionally in VB as well as ASP...
He was also fluent in Microsoft C, TASM and highly experienced in NT
networking as well as win32ASP and vb but his tutorials were only ever
written in MASM.
rand...@earthlink.net
hutch-- wrote:
>
> Most people who have been around in the assembler market for ay length
> of time know that Iczelion was a personal friend of mine and we worked
> together designing the fundamental architecture of the MASM32 Project
> and his direct contribution to the project was a subset of his
> tutorials which he personally wrote for the project.
No one is questioning that.
>
> I will more than happily defend an old friend
Whether he wants you to or not. I do believe that is the point here.
> who wrote his work and
> published it for anyone to USE for any programming requirement they may
> have in any language they like and to make the point, his complete
> original work is available from his own web site which is maintained by
> another old friend of his, it is not under my cotrol and never has
> been.
So why are you complaining that people have translated it to other
assemblers?
>
> What I have complained about is the notion of ayone cashing in on
> Iczelion's name as there has only ever been one set of Iczelion's
> tutorials and those are the ones he wrote himself.
Everyone I've seen has called their translations "The Iczelion
Tutorials". Granted, they are invoking Iczelion's name here and I guess
you could call that "cashing in on his name." But using the author's
name in this manner is ethically consistent with the way things are
done in this field. Why do you complain about this?
>
> Differing from many others, Betov actually did get permission to port
> the tutorials to SPASM and while I owe Betov an apology for burning his
> ear here, I certainly don't owe one to anyone else who have tried to
> cash in on Iczelion's name.
Iczelion published those tutorials to be used. Do you have a problem
with people using them? And if they do use them, what would you
suggest they do, *not* use Iczelion's name when they distribute the
translated forms? That would imply plagiarism, which was your other
accusation.
> Betov should hold his breath waiting
> (WaitForSingleObject) for the apology because I more than owe Betov
> some noise in response to his own. :)
Well, at least you admit you were wrong. That's a bit better than
you're achieving with the "polling vs. blocking" nonsense.
>
> Iczelion's tutorials are available at his web site for all to use for
> any language they like but I will make the same warning, BEWARE OF
> PHONIES, Iczelion only ever wrote in MASM and he never ported his work
> to any other assembler or compiler. When someone else ports his work to
> some other compiler or assembler, the result IS someone elses work and
> should not be called Iczelion's tutorials.
IOW, you're requesting that people *plagiarize* Iczelion's work and
claim it as their own by *not* listing Izcelion's name? This is
totally inconsistent with your past arguments where you claimed
everyone was plagiarizing his work.
Again, why do you continue to speak for Izcelion? You don't have that
right, friend or no friend. Contact him and have him post a single
message explaining his feelings. The fact that he gave permission to
Rene to translate the things pretty much tells me that he's okay with
this process and he probably appreciates all the credit that has been
given him for his tutorials.
I fail to see why all this upsets you. Are you seeing a huge decline in
MASM32 usage these days and someone feel threatened by the fact that
one of MASM32's "crown jewels" is so widely available for other
assemblers? If this is the case, I'd concentrate on creating a *new*
set of tutorials rather than trying to go into protectionist mode with
respect to an ancient (in CS terms) set of tutorials. Keeping the new
stuff coming is a *much* better way to protect your turf than trying to
prevent people from using material that's been around for better than
half a decade and has already been translated to a half-dozen other
assemblers. That toothpaste is out of the tube, and crying about it
isn't going to change things.
And let me offer you one piece of advice with your new tutorials -- if
you only want them to be used under MASM, you should explicitly state
that in the license agreement.
Cheers,
Randy Hyde
rand...@earthlink.net
hutch-- wrote:
>
> He was also fluent in Microsoft C, TASM and highly experienced in NT
> networking as well as win32ASP and vb but his tutorials were only ever
> written in MASM.
Apparently, they've have been written with other assemblers, else we
wouldn't be having this discussion :-). Perhaps *he* only used MASM
when writing them, but he's clearly given permission to at least one
other party to translate them, so it's also clear that he's not
fundamentally opposed to this process, as you are.
I wonder if Iczelion posted a message here saying that the translations
are okay if you'd turn around and attack him, as you have so many of
your other supporters recently?
Cheers,
Randy Hyde
hutch--
tutorials that were written by Iczelion are available from his web
site.
Now to put the claptrap of dependence by the MASM32 Project on
Iczelions tutorials, here is the direct quotation from www.masm32.com.
====================================
MASM32 assumes that the programmers who will use it already have
experience in 32 bit Windows API programming using compilers and have
done some work in assembler. It is not designed as a beginners package
and it does not have the support for beginners to learn the basic
concepts about assembler. It is recommended that beginners to
programming learns a compiler like C/C++ Pascal/Delphi or PowerBASIC
before they start on an assembler as this will produce the necessary
experience to deal with concepts like registers, data sizes or
registers, data types, assembler mnemonics, system API calls and
different calling conventions. The learner can always come back to
assembler once they are familiar and confortable with a compiler.
====================================
The project was launched without Iczelions tutorials, it has never been
aimed at beginner programmers, its largest source of new users is from
experienced programmers and it had its own body of example code before
the tutorials were included and which Iczelion wrote specifically for
the project.
I will continue to defend an old friend with or without your approval
as he posted his work for everyone to USE on his own site at no cost.
The only person to get permission was Betov but no-one else asked.
You are wrong in your assumption that you have te right to cash in on
someones name without their approval. His work was posted for everyone
to use but there is no follow on that by using his work, anyone has the
right to cash in on his name. Iczelion has retired and the integrity of
his work should be respected.
This is something like "The thoughts of Chairman Mao" ported from
Chinese to street idiom American English. It may in some sense ape
Chairman Mao but by no stretch of the imagination should it be
attributed to him.
===================================
I fail to see why all this upsets you. Are you seeing a huge decline in
MASM32 usage these days and someone feel threatened by the fact that
one of MASM32's "crown jewels" is so widely available for other
assemblers? If this is the case, I'd concentrate on creating a *new*
set of tutorials rather than trying to go into protectionist mode with
respect to an ancient (in CS terms) set of tutorials. Keeping the new
stuff coming is a *much* better way to protect your turf than trying to
prevent people from using material that's been around for better than
half a decade and has already been translated to a half-dozen other
assemblers. That toothpaste is out of the tube, and crying about it
isn't going to change things.
And let me offer you one piece of advice with your new tutorials -- if
you only want them to be used under MASM, you should explicitly state
that in the license agreement.
===================================
I suggest that you are not in a position to make these statements, as
posted above, the project was never pointed at beginners and the web
site makes that clear. Nor is the defence of Iczelion territorial as
there is no real need and to make te point again, his work in its
original form is available from his own web site, not mine.
Whether you undestand it or not, the real strength of the masm32
project was its extendable architecture and it has intentionally been
kept as neutral as possible so that other build formats and other IDEs
can predictable use it.
I don't write many tutorials, there are a few simple ones in the
project but I mainly write example code and also include examples that
other people have written for the project. The entire project is
copyright (c) and while nothing stops anyone from using the example
code in COBOL or PASCAL or whatever else they like, the contents are
protected by copyright.
Frank Kotler
...
> I will continue to defend an old friend with or without your approval
> as he posted his work for everyone to USE on his own site at no cost.
I really wish that you, or someone else who considers Iczelion a friend
(he'd recognize your email address as "not-spam"), would get a statement
as to what he intended by "use". I would *guess* that he intended to
allow translations to another syntax, but I don't know the guy - maybe
that's *not* what he wants...
> The only person to get permission was Betov but no-one else asked.
Do you know this for sure? AFAIK, it was Yeoh who did the "Nasm
translation" (and just the examples, not the text, AFAIK). I think
someone else has updated them to use the "nagoa+.inc" file. I don't kow
if they asked permission or not...
> You are wrong in your assumption that you have te right to cash in on
> someones name without their approval.
So we should just refer to "MASM32", and not "Hutch's MASM32"???
...
> This is something like "The thoughts of Chairman Mao" ported from
> Chinese to street idiom American English.
"So like dude, a journey of like a gazillion miles begins with like a
single step." - the mind boggles!
Best,
Frank
rand...@earthlink.net
hutch-- wrote:
> I make exactly the same warning as I have made before, the only
> tutorials that were written by Iczelion are available from his web
> site.
>
> Now to put the claptrap of dependence by the MASM32 Project on
> Iczelions tutorials, here is the direct quotation from www.masm32.com.
I believe the correct phrase was "crown jewels", not dependence. There
*is* a difference you know. And to claim that Iczelion Tutorials have
*not* been one of the most famous components of MASM32 and one of the
bigger draws to the MASM32 package is ignoring reality and insulting
your friend Iczelion.
>
> ====================================
> MASM32 assumes that the programmers who will use it already have
> experience in 32 bit Windows API programming using compilers and have
> done some work in assembler. It is not designed as a beginners package
> and it does not have the support for beginners to learn the basic
> concepts about assembler. It is recommended that beginners to
> programming learns a compiler like C/C++ Pascal/Delphi or PowerBASIC
> before they start on an assembler as this will produce the necessary
> experience to deal with concepts like registers, data sizes or
> registers, data types, assembler mnemonics, system API calls and
> different calling conventions. The learner can always come back to
> assembler once they are familiar and confortable with a compiler.
> ====================================
>
> The project was launched without Iczelions tutorials, it has never been
> aimed at beginner programmers,
There are different levels of beginners, you know. Iczelion's tuts may
not have been aimed at beginning *assembly* programmers, but they are
clearly aimed at beginning *win32 assembly* programmers.
> its largest source of new users is from
> experienced programmers and it had its own body of example code before
> the tutorials were included and which Iczelion wrote specifically for
> the project.
Experienced programmers who've never done Win32 programming in assembly
before. IOW, they are beginners in that sense.
>
> I will continue to defend an old friend with or without your approval
> as he posted his work for everyone to USE on his own site at no cost.
> The only person to get permission was Betov but no-one else asked.
Re-read the copyright notice. *I* certainly interpret it to mean that
translation to other assembler's syntax is perfect valid. And as *you*
are not the copyright holder, I'll be more than happy to ignore any
statements you make about Iczelion's intent. If people are violating
his intent, *HE* needs to complain about it. He is the only one who can
do this, being the copyright owner. Until he assigns the copyright to
you, you cannot speak for him. When he does, *then* you can defend the
copyright all you want.
>
> You are wrong in your assumption that you have te right to cash in on
> someones name without their approval.
His copyright notice gives explicit rights to USE his code for
non-commercial purposes. It says nothing about leaving the code in MASM
syntax. And the last time I checked, his copyright notice *explicitly*
states that his name is to be left attached to the product. So not only
do we have his approval to use his name, the copyright demands it.
> His work was posted for everyone
> to use but there is no follow on that by using his work, anyone has the
> right to cash in on his name. Iczelion has retired and the integrity of
> his work should be respected.
Yes, by always recognizing the source of his work.
Perhaps you're not familiar with the copyright laws, but the copyright
laws do not allow you to translate code to some other language and
claim it as your own. Hence, in following the copyright notice Iczelion
posted, it's important to leave his name attached to the project.
But all that is irrelvant. *YOU* don't speak for Iczelion. Friend or
otherwise. I'm also quite sure he would be *very* dismayed at your
recent behavior. It is disappointing many people who've long considered
you a reasonable guy.
>
> ===================================
> I fail to see why all this upsets you. Are you seeing a huge decline in
> MASM32 usage these days and someone feel threatened by the fact that
> one of MASM32's "crown jewels" is so widely available for other
> assemblers? If this is the case, I'd concentrate on creating a *new*
> set of tutorials rather than trying to go into protectionist mode with
> respect to an ancient (in CS terms) set of tutorials. Keeping the new
> stuff coming is a *much* better way to protect your turf than trying to
> prevent people from using material that's been around for better than
> half a decade and has already been translated to a half-dozen other
> assemblers. That toothpaste is out of the tube, and crying about it
> isn't going to change things.
>
> And let me offer you one piece of advice with your new tutorials -- if
> you only want them to be used under MASM, you should explicitly state
> that in the license agreement.
> ===================================
>
> I suggest that you are not in a position to make these statements, as
> posted above, the project was never pointed at beginners and the web
> site makes that clear.
Why do you keep coming back to this "beginners" nonsense? First of all,
where did I ever say "beginning assembly programmers?" This is a
complete straw horse. You're learning from Rene quite well -- change
the subject when you've got nothing else to stand on.
> Nor is the defence of Iczelion territorial as
> there is no real need and to make te point again, his work in its
> original form is available from his own web site, not mine.
Well, last time I check the tutorials were part of the MASM32 download.
So you *are* distributing it. And if it's not in it's original form,
then aren't you just as guilty of the transgressions you're accusing
others of?
>
> Whether you undestand it or not, the real strength of the masm32
> project was its extendable architecture and it has intentionally been
> kept as neutral as possible so that other build formats and other IDEs
> can predictable use it.
Maybe. But that doesn't change the fact that the Iczelion Tutorials
have been a popular component of the MASM32 package and a big draw.
>
> I don't write many tutorials, there are a few simple ones in the
> project but I mainly write example code and also include examples that
> other people have written for the project. The entire project is
> copyright (c) and while nothing stops anyone from using the example
> code in COBOL or PASCAL or whatever else they like, the contents are
> protected by copyright.
And do you allow them to translate that example code to other
assemblers? And if so, why do you care if they do the same with
Iczelion's?
Cheers,
Randy Hyde
f0dder
> Why do you keep coming back to this "beginners" nonsense? First of all,
> where did I ever say "beginning assembly programmers?" This is a
> complete straw horse. You're learning from Rene quite well -- change
> the subject when you've got nothing else to stand on.
Don't give Betov credit where it isn't due - hutch has always been
doing this, but he used to be okay at doing it in subtle ways. He should
have been into politics rather than programming. Fortunately, during the
last couple of years, he's been slipping up on a number of occasions,
and more people are starting to realize what he's really like.
hutch--
without his approval. At least Betov did ask permission and was given
it.
===================================
I believe the correct phrase was "crown jewels", not dependence. There
*is* a difference you know. And to claim that Iczelion Tutorials have
*not* been one of the most famous components of MASM32 and one of the
bigger draws to the MASM32 package is ignoring reality and insulting
your friend Iczelion.
===================================
Shame Iczelion did not see it this way, he rewrote a subset of his
tutorials in masm32 format as his contribution to the project that he
helped to design the architecture for. While I am certain that Randall
Hde was around in late 1997, I am also certain that he was not involved
in resurecting assembler from the dead with MASM. If I remember
corectly, AOA was still current and HLA had not been released by then.
===================================
Re-read the copyright notice. *I* certainly interpret it to mean that
translation to other assembler's syntax is perfect valid. And as *you*
are not the copyright holder,
===================================
No I am not but neither are you yet you choose to exercise that right
because Iczelion has retired. Where you have clear examples of someone
like Betov actually bothering to ask permission to port the examples,
what suddenly makes anyone else different ? The answer is simple, they
want to cash in on Iczelion's name because he has retired.
Now if Betov suddenly had a brain transplant and ported/rewrote HLA and
represented it as the work of Randall Hyde, I would make the same
complaint as I make of anyone else using Iczelion's name. In both
instances I would issue the warning, DON'T SETTLE FOR A PHONY, GET THE
ORIGINAL WORK BY THE ORIGINAL AUTHOR.
I only treat you the same way and it would be a fair complaint, just as
it is with anyone trying to cash in on Iczelion's name. On a like it or
lump it basis, I will defend an old friend against anyone trying to
cash in on his name, he as retired and his work should be respected.
Guga
Randall wrote:
"You're learning from Rene quite well -- change the subject when you've
got nothing else to stand on"
Pointing your finger on rené, to try to desviate the attention won´t
help you know :)
Randall, attacking René to desviate the attention is something that
even if you do with some often, won´t help Steve here. Your phrase is
unreasanoble, the next thing you wil claim is that Steve is on the
RosAsm clan just to bring René here to change the subject to him.
Randall, the only thing that is happening is that Steve strongly thinks
that he is defending Iczelion, for a question of friendship as he said.
Do you think that changing the subject to René will make Steve change
his mind ?
Steve is a grown man. Although i don´t agree with his last actitudes
i´ll defend his write to say it.
He may be confused about what Iczelion did concerning the permissions
to port to other assemblers, or for the teaching purposes, but his
reasons are good. I mean, it is reasonable to defend a friend, right ?
He may not speak for Iczelion, but either he like or not, it won´t
change the fact that people who have a different view will continue to
port the iczelion tutorials to their assemblers. And on the same time,
he will have the feelings that he may need to defend Iczelion work to
prevent this "unathorized" portings (As he say).
Randall...let me ask you...Did you ported Iczelion tutorials to HLA ?
I´m asking this because if you are afraid that Steve suddenly forbid
that the Iczelion tutorials released under masm be ported or used to
other programs (Including HLA), and as long as you don´t agree with
him, why don´t you translate Iczelion tutorials to HLA by yourself if
you want that people learning your HLA language from Iczelion tutorials
?
I mean, if you are worried that people don´t use HLA, or if you are
concerned in lost users because it won´t have a certain set of
examples from masm and Steve´s works, why don´t you translate it,
since you don´t agree with him ?
Steve, i think that you may not understood Iczelion purposes and
permissions, read his faq again.
http://spiff.tripnet.se/~iczelion/faq.html
Specially on the item he says "Needed tools". The related tools he
described and also for what says the copyright notice grants permission
for usage, and, by consequence, translated to the related tools, like
TASM, NASM, MASM.
I agree that defending a friend is a honorable thing, but, i just think
that you are a little confused about the goals, purposes and permitions
of Iczelion tutorials.
Take a bottle of beer, relax ;)...you may be overreacting on simple
issues.
Best Regards,
Guga
hutch--
This is the bit I don't get, I have made no secret that I am willing to
defend an old friend who has retired from anyone capitalising on his
name and I don't offer any apology for it.
Betov did ask Iczelion and he had the right to port the tutorials to
SPASM but anyone who did not ask has no right at all. Iczelion posted
his tutorials for anyone to use without any restriction on what
language they could be used for and this allowed anyone to write code
using his tutorials as reference but it did not give them any right to
try and capitalise on his name.
He did not write any other versions in any other language and the only
tutorials written by him are on his web site. When someone ports
Iczelion;s work to another language, they are NOT Iczelion's work and
should not be referred to in that manner.
If someone wants to give credit to Iczelion for his original design
work and tutorial format, fine but no-one has the right to capitalise
on his name, they should put their own name on any code they write and
if they have used his work as reference for the entire app design, they
should publish that note in their work.
Betov
> I thought this one as died a natural death but I just picked up this
> comment from Randall Hyde that indicates the level of confusion he
> suffered with my original warning about people trying to cash in on
> Iczelion's name.
Yes: You shot a bullet on me (the very wrong person,
in that matter), and your good old friend got it into
his rat face. Therefore the "confusion", and your
"not so natural death".
:)
Betov.
hutch--
I would happily do so for a normal human being but I owe you many
injustices in return so it will be a long time coming.
Just open another bottle of "sauce", it will help keep your legs warm.
:)
Guga
restriction on what language they could be used for and this allowed
anyone to write code using his tutorials as reference but it did not
give them any right to try and capitalise on his name. "
I totally agree. If you meant with capitalise is ear money, or have
more publicity or promotion, or whatever one can get´s over
Iczelion´s work, you are right to defend. This is not only because of
the forbidden of using his tutorials for commercials purposes as he
said in his site, but gaining anything over his name is the main
problem.
And this is something that is not easy to be avoided.
"When someone ports Iczelion;s work to another language, they are NOT
Iczelion's work and should not be referred to in that manner. "
Sure. This is correct. It is not anymore the original Iczelion´s work.
It is the work of someone who translated Iczelions tutorials. So he
must reference only where "his tutorial" was biased from.
This is the correct to do, specially because if upon the porting, for
some reason, the translated code is wrong, it will not be Iczelions
work that is wrong, but the trabslator´s work that is incorrect.
But, this is the way it should be, and may not represent the way that
actually happens.
"no-one has the right to capitalise on his name"
Yes, but don´t you agree that worst then this capitalization, is whom
never wrote or ported Iczelion´s work and yet capitalize somehow over
his name ?
This situation can also happens.
And what can you do about that ? Get mad, probably, but...effectively
you cannot do too much to avoid such situations. You can, although,
keep your eyes open to preserve your work, because your work is at your
hands. But Iczelion´s works, unfortunatelly, are not. So there is very
few things that you can do to prevent or to help.
I´m not saying to you drop helping someone you consider as a friend.
Far from that !!!, I´m just saying that you are facing a situation
where there is nothing you can do to help others, except helping
yourself, except preventing your work, and your own reputation.
The only thing that i´m quite don´t understand, is that on all these
years, now you opened your eeys and rased a flag to your friend ? What
happend to just now you decided to do such support ?
What you feel that is happening now, was happening before, maybe was
only you who was not seeing that.
So, now it may not change you try to help. Now, it maybe too late to
you avoid any damages (If you think that this is damaging). This is why
the best you can do is preserve your work, preserve your reputation
while you still have one, while you still want to maintain it.
We have a popular dictate here "Papagaio come milho, periquito leva a
fama"(Parrot eat maize, Lovebird takes the glory), meaning someone do
the hard job to another one takes the fame.
It is sad, but unfortunatelly, such things can happens.
Maybe you are also worried about your own work that are in danger of
this capitalization ? But, if it´s it, you are the one that can
prevent such things. You are still on active.
Best Regards,
Guga
Betov
@z14g2000cwz.googlegroups.com:
> Betov did ask Iczelion and he had the right to port the tutorials to
> SPASM but anyone who did not ask has no right at all. Iczelion posted
> his tutorials for anyone to use without any restriction on what
> language they could be used for and this allowed anyone to write code
> using his tutorials as reference but it did not give them any right to
> try and capitalise on his name.
You are fully right on that point, but the complete story
is that, when you took a run on this subject, you were
targeting _me_. Now, the real facts are that:
On my side, i did a _LOT_ of works, contributed to many
Demos, collaborated with several of the pioneers, (for
example, Test Departement and Ron Thomas), wrote two and
half Megas of Assembly Sources, two megas of _valid_
Documentation, and so on...
On Randall Hyde side, we all perfectly know that he never
contributed to _anything_, but to his personal Self-Selling
activities, and to megas of junk Pdfd, designed to misslead
the beginners, at the only cost of rephrasing the others
works, and of re-using the others Tools.
So, feel free to through your bullets on the accurate target,
that is,... in your own camp.
:)
By the way, given the poor quantity of little things you
did in the whole story (collecting a couple of Win32 Equates
and writing _ONE_ poor little Text Editor, that you would
be ashamed of showing the Source of...), you better begin
by shooting your bullets into your own face, because, after
having done so few, and so pathetic, along so many years,
claiming to be, so to say, the official representant of the
most famous among the Win32 Asm pioneers, is ridiculous:
You are a real _nobody_, Hutch, and you chest bombing
gesticulations cannot replace any done real work. We all
perfectly understand that your absurd defense of the
MicroSoft C-Side-Toy, that you redistribute illegaly,
has no other mean but to give yourself some importance
that you never had, otherwise, by anything really done.
In other words, you are the same nobody as Master Pdf:
* He feels confortable with "capitalizing" on the others
works and names.
* You feel confortable with "capitalizing" on a MicroSoft
Product, and on the work of your "friends".
I am really unable to tell which is worst.
Betov.
hutch--
I have tried to warn you already that all of this flattery may end up
going to my head. After reaching the sublime heights of being the
"fucky one", I did not think I could climb the ladder any higher. :)
==============================
You are fully right on that point, but the complete story
is that, when you took a run on this subject, you were
targeting _me_.
==============================
You flatter yourself, you were included because of your Betov Licencing
System (BLS) subtitled, if you want it, STEAL it. I pointed te
cpmplaint and warning to ANYONE who tried to cash in on Iczelion's name
and I make no apologies for that.
==============================
On my side, i did a _LOT_ of works, contributed to many
Demos, collaborated with several of the pioneers, (for
example, Test Departement and Ron Thomas), wrote two and
half Megas of Assembly Sources, two megas of _valid_
Documentation, and so on...
==============================
TD wrote for MASM32 well after it was released and Ron Thomas was on
the scene later than when MASM32 was released so you should give up
recreating well known history. Your problem was you were not there
either and missed the boat.
==============================
You are a real _nobody_, Hutch, and you chest bombing
gesticulations cannot replace any done real work. We all
perfectly understand that your absurd defense of the
MicroSoft C-Side-Toy, that you redistribute illegaly,
has no other mean but to give yourself some importance
that you never had, otherwise, by anything really done.
==============================
Awe diddums, felling a bit left out of it again, I suggest its time for
you to try another bottle of "open sauce" so that you can nod off again
and keep your legs warm as you discharge your main byproduct. it must
be soul destroying for such a clapped out failure in the face of the
sheer brutal power orf MASM and its near absolute dominance of
assembler programming for Windows.
Paul Dunn
> He did not write any other versions in any other language and the only
> tutorials written by him are on his web site. When someone ports
> Iczelion;s work to another language, they are NOT Iczelion's work and
> should not be referred to in that manner.
Have the Iczelion tutorials been ported to Visual C++ yet? If not, may I do
so? They do look quite useful, and I'm sure the community would benefit.
f0dder
Feel free to do so, as long as you give credit where credit is due.
Pay no notice to hutch, translating the tutorials would be in accordance
with the copyright notice, and in the spirit of Iczelion.
I would suggest Charles Petzold's "programming windows" instead, though.
Paul Dunn
> Paul Dunn wrote:
>> hutch-- wrote:
>>
>>> He did not write any other versions in any other language and the
>>> only tutorials written by him are on his web site. When someone
>>> ports Iczelion;s work to another language, they are NOT Iczelion's
>>> work and should not be referred to in that manner.
>>
>> Have the Iczelion tutorials been ported to Visual C++ yet? If not,
>> may I do so? They do look quite useful, and I'm sure the community
>> would benefit.
>
> Feel free to do so, as long as you give credit where credit is due.
> Pay no notice to hutch, translating the tutorials would be in
> accordance with the copyright notice, and in the spirit of Iczelion.
:-D
> I would suggest Charles Petzold's "programming windows" instead,
> though.
Oh, but Iczelion's are so much more worthy. Nice to know I'll not be
breaking any laws though, thanks.
JGCASEY
f0dder wrote:
>
> I would suggest Charles Petzold's "programming windows" ...
This is perhaps the best book for a Win32 API beginner
who knows how to program in C? As good as Iczelion's
tuts may be they are not aimed at a Win32 API and MASM
novice even if they do know some assembler and would
be complete gibberish to a absolute assembler beginner.
It interests me that those that have the ability to
write an assembler lack the ability to write their
own tutorials, particularly tutorials to get newbies
interested in assembler. I think assembler will die
out with the old guard in any hobbyist sense and
become simply a side tool for systems programmers.
John
f0dder
>> I would suggest Charles Petzold's "programming windows" ...
>
>
> This is perhaps the best book for a Win32 API beginner
> who knows how to program in C?
I haven't seen any better, but haven't been looking for a while.
If you know a decent amount of 32bit assembly, have studied and
understood a few of Iczelion's tutorials, and have a moderate IQ,
using Petzold's stuff for assembly programming is quite easy.
> As good as Iczelion's tuts may be they are not aimed at a Win32
> API and MASM novice even if they do know some assembler and would
> be complete gibberish to a absolute assembler beginner.
I'd say they work pretty well for somebody who knows his way around
assembly but needs to learn win32 programming - but they're
certainly not for people who don't know assembly (I've seen enough
people various places who can barely figure out how to copy/paste
from them). Petzold is a bit more indepth, I guess.
> It interests me that those that have the ability to
> write an assembler lack the ability to write their
> own tutorials, particularly tutorials to get newbies
> interested in assembler.
Probably because they focus all the effort in writing the assembler,
adding features, removing bugs, etc. And while some of them are
excellent programmers, they might not be the best documentation
writers.
> I think assembler will die out with the old guard in any hobbyist
> sense and become simply a side tool for systems programmers.
Not as long as x86 is around :) - but people hoping for an "assembly
rebirth" or writing full-scale applications in assembly are very
few.
JGCASEY
f0dder wrote:
> "JGCASEY" <jgkj...@yahoo.com.au> wrote:
>
> >> I would suggest Charles Petzold's "programming windows" ...
> >
> >
> > This is perhaps the best book for a Win32 API beginner
> > who knows how to program in C?
>
> I haven't seen any better, but haven't been looking for a while.
I found one tutorial that looks promising. Someone advised
me that learning the win32 APIs with C might be a better
way than trying from an Assembler base. As C is a language
I have reasonable skills in I have taken their advice.
http://www.winprog.org/tutorial/
The question is, will I ever be motivated to use assembler
again? I have found there is a lot of C support for the
projects I am interested in but zero support in assembler
or from assembler programmers.
The thing that struck me after my foray into MASM, NASM,
FASM,GoAsm,RosASM and even HLA is that although there are
many C compilers to choose from at least they all use the
same syntax and one beginner tutorial fits them all!
John
f0dder
> I found one tutorial that looks promising. Someone advised
> me that learning the win32 APIs with C might be a better
> way than trying from an Assembler base. As C is a language
> I have reasonable skills in I have taken their advice.
Might be a good idea, considering the WIN32 API was written
for the C language, and since there's so many code snippets
and references available. Besides, once you're familiar with
win32, you can directly use that experience in assembly.
And you can of course always play with win32 stuff in C/C++,
and link in external assembly modules - then you can play
with both worlds at the same time.
> The question is, will I ever be motivated to use assembler
> again? I have found there is a lot of C support for the
> projects I am interested in but zero support in assembler
> or from assembler programmers.
I still use assembly. Never really bothered using it for
full-size projects, but I do use it. Sometimes because it's
fun, sometimes because it's necessary, sometimes because of
the speed, and sometimes "just coz".
As for support, the win32asmcommunity is generally a nice
place, while ALA is one big flamefest. *shrug*.
> The thing that struck me after my foray into MASM, NASM,
> FASM,GoAsm,RosASM and even HLA is that although there are
> many C compilers to choose from at least they all use the
> same syntax and one beginner tutorial fits them all!
As long as you stick with the basics instructions and don't use
any of the more fancy features and macros, the syntax
discrepancies between most of the assemblers aren't that bad...
JGCASEY
f0dder wrote:
> "JGCASEY" <jgkj...@yahoo.com.au> wrote:
[...]
> > The question is, will I ever be motivated to use assembler
> > again? I have found there is a lot of C support for the
> > projects I am interested in but zero support in assembler
> > or from assembler programmers.
[...]
> As for support, the win32asmcommunity is generally a nice
> place, while ALA is one big flamefest. *shrug*.
It is not so much how nice the community is as to how
interested they are in a particular project. There is
a wider range of interests in the HLL community.
> > The thing that struck me after my foray into MASM, NASM,
> > FASM,GoAsm,RosASM and even HLA is that although there are
> > many C compilers to choose from at least they all use the
> > same syntax and one beginner tutorial fits them all!
>
> As long as you stick with the basics instructions and don't use
> any of the more fancy features and macros, the syntax
> discrepancies between most of the assemblers aren't that bad...
But the tutorials use the high level directives and the macros.
Just as it is suggested it is better to learn to use the APIs
before you use the MFCs so too it is better to learn what is
under the hood of a macro or directive rather than learn to
use them by wrote without understanding. And where do you
learn that? With DOS? It isn't in the Iczelion's MASM32 tuts.
John
f0dder
>> As for support, the win32asmcommunity is generally a nice
>> place, while ALA is one big flamefest. *shrug*.
>
> It is not so much how nice the community is as to how
> interested they are in a particular project. There is
> a wider range of interests in the HLL community.
That might be true - I'd still say there's a fair amount of
different interests among assembly programmers, though; just
at the win32asmcommunity board, you'll see IDE and OS design,
game-style programming (evilhomer2k is doing a lot of stuff
there), networking, etc etc etc.
>> As long as you stick with the basics instructions and don't use
>> any of the more fancy features and macros, the syntax
>> discrepancies between most of the assemblers aren't that bad...
>
> But the tutorials use the high level directives and the macros.
Yeah - since they tend to be teaching "assembly programming in
win32" and not "assembly programming". I tend not to use the
high-level control macros (.IF and such) myself, but that's
because I mainly use assembly as a "C++ side tool", to quote Betov.
If I wanted to do full-app assembly, I'd take advantage of the
macros, since they do make life easier. I just don't see any
point in full-app assembly, so I don't :)
> Just as it is suggested it is better to learn to use the APIs
> before you use the MFCs so too it is better to learn what is
> under the hood of a macro or directive rather than learn to
> use them by wrote without understanding. And where do you
> learn that? With DOS? It isn't in the Iczelion's MASM32 tuts.
I learned assembly by other people's snippets, debugging in
assembly mode, and the intel references, mostly, as there
weren't any decent books around. Dunno if there are any now,
as I don't need them. And the "best way" to learn will differ
from person to person, depending on your background et cetera.
For somebody with a C background learning 32bit x86 assembly,
I'd say http://www.madwizard.org/dl.php?file=tutors.win32asm
mixed with assembly source-listing from your compiler (either
without optimizations or with size-optimizations - avoid speed
optimizations as they're pretty hard to read), and the intel´
developer manuals at
http://developer.intel.com/design/pentium4/manuals/index_new.htm
would be a pretty good way to start.
Then there's Randall Hyde's Art Of Assembly, which I'll probably
get flamed to death for mentioning, since the 32bit version
teaches his HLA syntax.
Oh well :)
Betov
@z14g2000cwz.googlegroups.com:
> It interests me that those that have the ability to
> write an assembler lack the ability to write their
> own tutorials, particularly tutorials to get newbies
> interested in assembler. I think assembler will die
> out with the old guard in any hobbyist sense and
> become simply a side tool for systems programmers.
You just reverse the facts: What you think the future
will be, is exactly what the _past_ was, before the
actual rebirth.
As for the beginners tutorials, you have been pointed
to many very good ones, and, if you fail to understand
them, the only thing that would be interresting (not
considering the analyse of your IQ... :) would be to
hear you saying _what_ kind of explanations you had
expect to find out of the zip, instead of the ones we
provide.
Betov.
JGCASEY
Betov wrote:
> "JGCASEY" wrote:
>> It interests me that those that have the ability to
>> write an assembler lack the ability to write their
>> own tutorials, particularly tutorials to get newbies
>> interested in assembler. I think assembler will die
>> out with the old guard in any hobbyist sense and
>> become simply a side tool for systems programmers.
>
>
> You just reverse the facts: What you think the future
> will be, is exactly what the _past_ was, before the
> actual rebirth.
>
> As for the beginners tutorials, you have been pointed
> to many very good ones, and, if you fail to understand
> them, the only thing that would be interresting (not
> considering the analyse of your IQ... :) would be to
> hear you saying _what_ kind of explanations you had
> expect to find out of the zip, instead of the ones we
> provide.
This is a reasonable comment. You've made me realise I
have been ranting away without really giving it a fair
go. Partly I guess I have been expressing my frustration
at getting started and deciding the best way to go about
it while feeling there must be an easier way.
The Iczelion tuts are written for MASM so I figured
that I should use MASM. This means learning how the
high level directives work. I had intended using FASM
but just now comparing the FASM version of tut3 "A
Simple Window" and the MASM version they appear very
different? Now GoAsm had some interesting tutorials
so I thought, start with them, only to find the RadAsm
tutorial was out of date and the information to run
GoAsm wasn't there. All very frustrating.
I am still keen to spend time learning some Windows
assembler as it can only make it easier to understand
how the Win32 APIs are used.
John Casey
Betov
@z14g2000cwz.googlegroups.com:
> This is a reasonable comment. You've made me realise I
> have been ranting away without really giving it a fair
> go. Partly I guess I have been expressing my frustration
> at getting started and deciding the best way to go about
> it while feeling there must be an easier way.
_My_ problem is that i fail to imagine what could be made
easier and how...
> The Iczelion tuts are written for MASM so I figured
> that I should use MASM.
I warned you that MASM was the worst of the available
Assemblers, and that Iczelion Tutorials had been ported
to almost all of the good Assemblers around.
> This means learning how the
> high level directives work. I had intended using FASM
> but just now comparing the FASM version of tut3 "A
> Simple Window" and the MASM version they appear very
> different? Now GoAsm had some interesting tutorials
> so I thought, start with them, only to find the RadAsm
> tutorial was out of date and the information to run
> GoAsm wasn't there. All very frustrating.
>
> I am still keen to spend time learning some Windows
> assembler as it can only make it easier to understand
> how the Win32 APIs are used.
Well, i did not not push RosAsm, when talking to you,
because i do not want to behave like Master Randall
Hyde, working at nothing but Self-Promotion, but,
nevertheless, RosAsm _does_ exist, with Ports of
Test Departement Tutorials and Iczelion Tutorials, the
Interactive Visual Tutorials, that you can directly run
from the Help Menu, Yeoh, Demos, and so on... Plus
2 Megas of regulary updated Integrated Documentation...
And, for a start, it would really _stuck_ me, if you
could say to me that the infos, materials and tools,
that any Win32 beginner could ever wish would be
missing you...
Not considering its impressive Components list, the
main advantage of RosAsm is its complete Integration
of all these components. Taking your above example of
"A simple window", with RosAsm, you click upon [File]
/[New]/[Return], and you have it. Then you hit [F6],
and it is executed through the Debugger. Want a Break-
point somewhere, to see what is going on? Easy: You
hit [F4]/[F4]/[F6], and you have the debugger offering
stepping and all, in its Dialog, and so on... Want to
learn the very first infos about Win32 Asm? Simple: [Help]
/[Visual Tutorials] >>> Click >>> Run and so on... Want
Info on something or anything? Simple: Right-Click and/or
Double-Left-Click upon the thingie...
What else would you want? That the program learn, instead
of you, and store the knowledge directly into your brain,
while you sleep?
;)
Betov.
rand...@earthlink.net
Betov wrote:
> "JGCASEY" <jgkj...@yahoo.com.au> écrivait news:1125313208.846362.289800
> @z14g2000cwz.googlegroups.com:
>
>
> > This is a reasonable comment. You've made me realise I
> > have been ranting away without really giving it a fair
> > go. Partly I guess I have been expressing my frustration
> > at getting started and deciding the best way to go about
> > it while feeling there must be an easier way.
>
> _My_ problem is that i fail to imagine what could be made
> easier and how...
Actually, there are lots of things that could be done to make the whole
learning process easier. First of all, and probably most important, the
Iczelion tutorials are a disconnected bunch of examples that
demonstrate how to make certain Win32API calls. The one thing they
don't particularly do is answer *why* you would want to make these
calls. That is, they are focused on demonstrating particular API calls
rather than on demonstrating how you solve real application problems.
This is *exactly* the same problem one has, for example, when trying to
learn assembly by reading only the Intel Reference manuals (as Wolfgang
suggests) or trying to learn assembly language by reading an
assembler's manual.
>
>
> > The Iczelion tuts are written for MASM so I figured
> > that I should use MASM.
>
> I warned you that MASM was the worst of the available
> Assemblers, and that Iczelion Tutorials had been ported
> to almost all of the good Assemblers around.
I didn't realize John was complaining about the quality of the MASM
code, only that the FASM and MASM versions were different. Indeed, from
what I infered from John's remarks, it was *exactly* using these other
assemblers that caused the problems, not using MASM.
> >
> > I am still keen to spend time learning some Windows
> > assembler as it can only make it easier to understand
> > how the Win32 APIs are used.
>
> Well, i did not not push RosAsm, when talking to you,
> because i do not want to behave like Master Randall
> Hyde, working at nothing but Self-Promotion, but,
> nevertheless, RosAsm _does_ exist, with Ports of
> Test Departement Tutorials and Iczelion Tutorials, the
> Interactive Visual Tutorials, that you can directly run
> from the Help Menu, Yeoh, Demos, and so on... Plus
> 2 Megas of regulary updated Integrated Documentation...
"I do not push RosAsm, but watch me turn around and start pushing
it..." :-)
>
> Not considering its impressive Components list, the
> main advantage of RosAsm is...
"I do not push RosAsm, but watch me turn around and start pushing
it..." :-)
>... its complete Integration
> of all these components. Taking your above example of
> "A simple window", with RosAsm, you click upon [File]
> /[New]/[Return], and you have it. Then you hit [F6],
> and it is executed through the Debugger. Want a Break-
> point somewhere, to see what is going on? Easy: You
> hit [F4]/[F4]/[F6], and you have the debugger offering
> stepping and all, in its Dialog, and so on... Want to
> learn the very first infos about Win32 Asm? Simple: [Help]
> /[Visual Tutorials] >>> Click >>> Run and so on... Want
> Info on something or anything? Simple: Right-Click and/or
> Double-Left-Click upon the thingie...
"I do not push RosAsm, but watch me turn around and start pushing
it..." :-)
>
> What else would you want? That the program learn, instead
> of you, and store the knowledge directly into your brain,
> while you sleep?
How about decent tutorials that teach you how to solve problems rather
than simply teach you what API functions do?
Cheers,
Randy Hyde
Herbert Kleebauer
> I am still keen to spend time learning some Windows
> assembler as it can only make it easier to understand
> how the Win32 APIs are used.
Forget about all the second level documentation. For
the processor use the processor manuals from Intel or
AMD and for the Win32 API use the documentation at msdn.com.
If you really want to know what happens within an exe file,
select a small exe file (I used write.exe which comes with
Windows) and the exe file format specification and try
to identify any byte within the exe. Remove anything which
isn't necessary for a minimal executable. Then step by step
add additional API calls and save the documentation for this
API functions so you get your own API handbook for all the
API calls you used. But I very fast lost interest in Win32
assembly programming, because it mostly is a sequence of
API calls and nothing I would call "assembly programming".
It is much more fun to directly access the hardware in a
DOS program (even if only emulated by Windows in V86 mode).
Here the source of such a miniumal Win32 console program:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; STDINOUT.mac: copy stdin to stdout and convert all upper case ;;
;; letter to lower case ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
UseIdatSection=0 ; 0 if no idat section is used
UseUdatSection=0 ; 0 if no udat section is used
;#==================================================================#
;# Start of Headers #
;#==================================================================#
; +--------------------------------------------+
; | Start of DOS Header |
; +--------------------------------------------+
; DOS .EXE header
dc.b 'MZ' ; Magic number
dc.w dosfilesize\512 ; Bytes on last page of file (0->512)
dc.w (dosfilesize-1)/512+1
; Pages in file (Page=512 byte)
dc.w 0 ; Relocations (nr of entries)
dc.w doshead_end/16 ; Size of header size in paragraphs (16 byte)
dc.w 0 ; Minimum extra paragraphs needed
dc.w $ffff ; Maximum extra paragraphs needed
dc.w 0 ; Initial (relative) SS value (ss=load_adr+nr)
dc.w dosstack ; Initial SP value
dc.w 0 ; Checksum
dc.w dosmain ; Initial IP value
dc.w 0 ; Initial (relative) CS value (cs=load_adr+nr)
dc.w reloc ; File address of relocation table
dc.w 0 ; Overlay number
dc.w 0,0,0,0 ; Reserved words
dc.w 0 ; OEM identifier (for e_oeminfo)
dc.w 0 ; OEM information; e_oemid specific
dc.l 0,0,0,0,0 ; Reserved words
dc.l WinHeader ; File address of new exe header
reloc:
doshead_end:
@=$0
dosmain:move.w s6,-(sp)
move.w (sp)+,s0
move.w #_text,r1
move.b #$09,m0
trap #$21
move.w #$4c01,r0
trap #$21
_text: dc.b 'Nice to meet somebody who is still using DOS,',13,10
dc.b 'but his program requires Win32.',13,10,'$'
even 16
dosstack=@+256 ; 256 Byte stack
dosfilesize=@+256
; +--------------------------------------------+
; | End of DOS Header |
; +--------------------------------------------+
; +--------------------------------------------+
; | Start of Windows Header |
; +--------------------------------------------+
ImageBase== $00400000
SectionAlignment== 4096
FileAlignment== 512
WinHeader=@@
@=ImageBase
; see WINNT.H for information
dc.b 'PE',0,0 ; magic word
; _IMAGE_FILE_HEADER:
dc.w $014c ; Machine ($014c=Intel x86 processor)
dc.w NumberOfSections ; NumberOfSections
dc.l $36a57950 ; TimeDateStamp (seconds since 31.12.69 16:00)
dc.l 0 ; PointerToSymbolTable
dc.l 0 ; NumberOfSymbols
dc.w SizeOfOptionalHeader ; SizeOfOptionalHeader
dc.w $010f ; Charcteristics
; 0x0001 Relocation info stripped from file.
; 0x0002 File is executable (i.e. no unresolved externel references).
; 0x0004 Line nunbers stripped from file.
; 0x0008 Local symbols stripped from file.
; 0x0010 Agressively trim working set
; 0x0080 Bytes of machine word are reversed.
; 0x0100 32 bit word machine.
; 0x0200 Debugging info stripped from file in .DBG file
; 0x0400 If Image is on removable media, copy and run from the swap file.
; 0x0800 If Image is on Net, copy and run from the swap file.
; 0x1000 System File.
; 0x2000 File is a DLL.
; 0x4000 File should only be run on a UP machine
; 0x8000 Bytes of machine word are reversed.
@a=@ ; _IMAGE_OPTIONAL_HEADER
dc.w $010b ; Magic
dc.b 5 ; MajorLinkerVersion
dc.b 12 ; MinorLinkerVersion
dc.l SizeOfCode ; SizeOfCode
dc.l SizeOfInitializedData ; SizeOfInitializedData
dc.l SizeOfUninitializedData ; SizeOfUninitializedData
dc.l winmain-ImageBase ; AddressOfEntryPoint
dc.l BaseOfCode ; BaseOfCode
dc.l BaseOfData ; BaseOfData
dc.l ImageBase ; ImageBase
dc.l SectionAlignment ; SectionAlignment
dc.l FileAlignment ; FileAlignment
dc.w 4 ; MajorOperatingSystemVersion
dc.w 0 ; MinorOperatingSystemVersion
dc.w 0 ; MajorImageVersion
dc.w 0 ; MinorImageVersion
dc.w 4 ; MajorSubsystemVersion
dc.w 0 ; MinorSubsystemVersion
dc.l 0 ; Win32VersionValue
dc.l SizeOfImage ; SizeOfImage
dc.l SizeOfHeaders ; SizeOfHeaders
dc.l 0 ; CheckSum
dc.w 3 ; Subsystem
; 0: Unknown subsystem.
; 1: Image doesn't require a subsystem.
; 2: Image runs in the Windows GUI subsystem.
; 3: Image runs in the Windows character subsystem.
; 5: image runs in the OS/2 character subsystem.
; 7: image run in the Posix character subsystem.
; 8: image run in the 8 subsystem.
dc.w $0000 ; DllCharacteristics
dc.l $00100000 ; SizeOfStackReserve
dc.l $00001000 ; SizeOfStackCommit
dc.l $00100000 ; SizeOfHeapReserve
dc.l $00001000 ; SizeOfHeapCommit
dc.l $00000000 ; LoaderFlags
dc.l NumberOfRvaAndSize ; NumberOfRvaAndSize (entries
; in the data dir)
; ..............................................
; : Start of Image Data Directory :
; ..............................................
; virtual address, size
@b=@
dc.l 0,0 ; Export Directory
dc.l imp_start,imp_size ; Import Directory
dc.l 0,0 ; Resource Directory
dc.l 0,0 ; Exception Directory
dc.l 0,0 ; Security Directory
dc.l 0,0 ; Base Relocation Table
dc.l 0,0 ; Debug Directory
dc.l 0,0 ; Description String
dc.l 0,0 ; Machine Value (MIPS GP)
dc.l 0,0 ; TLS Directory
dc.l 0,0 ; Load Configuration Directory
dc.l 0,0 ; Bound Import Directory in headers
dc.l iat_start,iat_size ; Import Address Table
dc.l 0,0 ; 14
dc.l 0,0 ; 15
dc.l 0,0 ; 16
NumberOfRvaAndSize = (@-@b)/8
SizeOfOptionalHeader = @-@a
; ..............................................
; : End of Image Data Directory :
; ..............................................
; ..............................................
; : Start of Image Sections Header :
; ..............................................
@a=@
dc.b '.text',0,0,0 ; name
dc.l VSizeOf_text ; virtual size
dc.l VBaseOf_text ; virtual address
dc.l FSizeOf_text ; size of raw data
dc.l FBaseOf_text ; pointer to raw data
dc.l 0 ; pointer to relocatins
dc.l 0 ; pointer to line numbers
dc.w 0 ; number of relocations
dc.w 0 ; number of line numbers
dc.l $e0000020 ; characteristics
IF UseIdatSection
dc.b '.idat',0,0,0 ; name
dc.l VSizeOf_idat ; virtual size
dc.l VBaseOf_idat ; virtual address
dc.l FSizeOf_idat ; size of raw data
dc.l FBaseOf_idat ; pointer to raw data
dc.l 0 ; pointer to relocatins
dc.l 0 ; pointer to line numbers
dc.w 0 ; number of relocations
dc.w 0 ; number of line numbers
dc.l $e0000040 ; characteristics
ENDIF
IF UseUdatSection
dc.b '.udat',0,0 ; name
dc.l VSizeOf_udat ; virtual size
dc.l VBaseOf_udat ; virtual address
dc.l FSizeOf_udat ; size of raw data
dc.l FBaseOf_udat ; pointer to raw data
dc.l 0 ; pointer to relocatins
dc.l 0 ; pointer to line numbers
dc.w 0 ; number of relocations
dc.w 0 ; number of line numbers
dc.l $e0000080 ; characteristics
ENDIF
NumberOfSections=(@-@a)/40
; ..............................................
; : End of Image Sections Header :
; ..............................................
; characteristics
; 0x00000020 // Section contains code.
; 0x00000040 // Section contains initialized data.
; 0x00000080 // Section contains uninitialized data.
; 0x00000200 // Section contains comments or some other type of information.
; 0x00000800 // Section contents will not become part of image.
; 0x00001000 // Section contents comdat.
; 0x01000000 // Section contains extended relocations.
; 0x02000000 // Section can be discarded.
; 0x04000000 // Section is not cachable.
; 0x08000000 // Section is not pageable.
; 0x10000000 // Section is shareable.
; 0x20000000 // Section is executable.
; 0x40000000 // Section is readable.
; 0x80000000 // Section is writeable.
; +--------------------------------------------+
; | End of Windows Header |
; +--------------------------------------------+
evencom FileAlignment
SizeOfHeaders==@@
;#==================================================================#
;# End of Headers #
;#==================================================================#
;#==================================================================#
;# Start of Sections #
;#==================================================================#
; +--------------------------------------------+
; | Start of .text Section |
; +--------------------------------------------+
FBaseOf_text==@@
VBaseOf_text==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
BaseOfCode==VBaseOf_text
@=ImageBase+VBaseOf_text
; ..............................................
; : Start of Thunk Table :
; ..............................................
iat_start=@-ImageBase
USER32_thunk:
MessageBoxA:: dc.l USER32_MessageBoxA -ImageBase
dc.l 0
KERNEL32_thunk:
ExitProcess:: dc.l KERNEL32_ExitProcess -ImageBase
GetStdHandle:: dc.l KERNEL32_GetStdHandle -ImageBase
ReadFile:: dc.l KERNEL32_ReadFile -ImageBase
WriteFile:: dc.l KERNEL32_WriteFile -ImageBase
dc.l 0
iat_size=@-ImageBase-iat_start
; ..............................................
; : End of Thunk Table :
; ..............................................
; ..............................................
; : Start of Import Directory :
; ..............................................
imp_start==@-ImageBase
imp:
dc.l USER32_import -ImageBase
dc.l 0
dc.l 0
dc.l USER32_name -ImageBase
dc.l USER32_thunk -ImageBase
dc.l KERNEL32_import -ImageBase
dc.l 0
dc.l 0
dc.l KERNEL32_name -ImageBase
dc.l KERNEL32_thunk -ImageBase
dc.l 0
dc.l 0
dc.l 0
dc.l 0
dc.l 0
imp_size==@-imp
; ..............................................
; : End of Import Directory :
; ..............................................
USER32_name:
dc.b 'USER32.dll',0
even
USER32_import:
dc.l USER32_MessageBoxA -ImageBase
dc.l 0
even
USER32_MessageBoxA:
dc.w 0
dc.b 'MessageBoxA',0
even
KERNEL32_name:
dc.b 'KERNEL32.dll',0
even
KERNEL32_import:
dc.l KERNEL32_ExitProcess -ImageBase
dc.l KERNEL32_GetStdHandle -ImageBase
dc.l KERNEL32_ReadFile -ImageBase
dc.l KERNEL32_WriteFile -ImageBase
dc.l 0
even
KERNEL32_ExitProcess:
dc.w 0
dc.b 'ExitProcess',0
even
KERNEL32_GetStdHandle:
dc.w 0
dc.b 'GetStdHandle',0
even
KERNEL32_ReadFile:
dc.w 0
dc.b 'ReadFile',0
even
KERNEL32_WriteFile:
dc.w 0
dc.b 'WriteFile',0
even
; ..............................................
; : Start of Code :
; ..............................................
label_block
seg32
winmain::
loop: bsr.l getc ; get char from stdin
cmp.l #-1,r0 ; EOF
bne.b _10 ; branch if not
moveq.l #0,-(sp)
jsr.l (ExitProcess) ; exit program
_10: cmp.b #'A',r0
blo.b _20
cmp.b #'Z',r0
bhi.b _20
add.b #'a'-'A',r0
_20: bsr.l putc ; write char to stdout
br.b loop ; go on
putc: move.l r0,-(sp)
move.b r0,_buf
eor.l r0,r0
add.l _handle,r0
bne.b _10
moveq.l #-11,-(sp)
jsr.l (GetStdHandle)
move.l r0,_handle
_10: moveq.l #0,-(sp)
move.l #_count,-(sp)
moveq.l #1,-(sp)
move.l #_buf,-(sp)
move.l r0,-(sp)
jsr.l (WriteFile)
or.l r0,r0
bne.b _20
_30: moveq.l #0,-(sp)
move.l #_text,-(sp)
move.l #_text,-(sp)
moveq.l #0,-(sp)
jsr.l (MessageBoxA)
moveq.l #0,-(sp)
jsr.l (ExitProcess)
_20: cmp.l #1,_count
bne.b _30
move.l (sp)+,r0
rts.l
_buf: dc.b 0
_text: dc.b 'write error',0
even4
_handle:dc.l 0
_count: dc.l 0
getc: eor.l r0,r0
add.l _handle,r0
bne.b _10
moveq.l #-10,-(sp)
jsr.l (GetStdHandle)
move.l r0,_handle
_10: moveq.l #0,-(sp)
move.l #_count,-(sp)
moveq.l #1,-(sp)
move.l #_buf,-(sp)
move.l r0,-(sp)
jsr.l (ReadFile)
or.l r0,r0
bne.b _20
moveq.l #0,-(sp)
move.l #_text,-(sp)
move.l #_text,-(sp)
moveq.l #0,-(sp)
jsr.l (MessageBoxA)
moveq.l #0,-(sp)
jsr.l (ExitProcess)
_20: movu.bl _buf,r0
cmp.l #1,_count
beq.b _30
move.l #-1,r0
_30: rts.l
_buf: dc.b 0
_text: dc.b 'read error',0
even4
_handle:dc.l 0
_count: dc.l 0
; ..............................................
; : End of Code :
; ..............................................
VSizeOf_text==@-Imagebase-VBaseOf_text
@a=@
evencom FileAlignment
@=@a
FSizeOf_text==@@-FBaseOf_text
SizeOfCode==FSizeOf_text
; +--------------------------------------------+
; | End of .text Section |
; +--------------------------------------------+
; +--------------------------------------------+
; | Start of .idat Section |
; +--------------------------------------------+
FBaseOf_idat==@@
VBaseOf_idat==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
BaseOfData==VBaseOf_idat
@=ImageBase+VBaseOf_idat
; Insert initialized variables here (and set UseIdatSection=1
; at the top of this file). Because the code section is set
; r/w-able, you can put initialized variables also into the
; code section.
; var1: dc.l 0
; var2: dc.l $12345678
VSizeOf_idat==@-Imagebase-VBaseOf_idat
@a=@
evencom FileAlignment
@=@a
FSizeOf_idat==@@-FBaseOf_idat
; +--------------------------------------------+
; | End of .idat Section |
; +--------------------------------------------+
SizeOfInitializedData==FSizeOf_idat
; +--------------------------------------------+
; | Start of .udat Section |
; +--------------------------------------------+
FBaseOf_udat==@@
VBaseOf_udat==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
@=ImageBase+VBaseOf_udat
; Insert uninitialized variables here (and set UseUdatSection=1
; at the top of this file). Because the code section is set
; r/w-able, you can put uninitialized variables also at the END
; of the code section.
; buf1: blk.l 10
; buf2: blk.l 200
VSizeOf_udat==@-Imagebase-VBaseOf_udat
@a=@
evencom FileAlignment
@=@a
FSizeOf_udat==@@-FBaseOf_udat
; +--------------------------------------------+
; | End of .udat Section |
; +--------------------------------------------+
SizeOfUninitializedData==VSizeOf_udat
SizeOfImage==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
;#==================================================================#
;# End of Sections #
;#==================================================================#
rand...@earthlink.net
Herbert Kleebauer wrote:
> JGCASEY wrote:
>
>
> > I am still keen to spend time learning some Windows
> > assembler as it can only make it easier to understand
> > how the Win32 APIs are used.
>
> Forget about all the second level documentation. For
> the processor use the processor manuals from Intel or
> AMD and for the Win32 API use the documentation at msdn.com.
Sure. Spend months and months wondering why you would use some
particular API rather than figuring it out in a few minutes from some
"second level documentation."
> If you really want to know what happens within an exe file,
> select a small exe file (I used write.exe which comes with
> Windows) and the exe file format specification and try
> to identify any byte within the exe. Remove anything which
> isn't necessary for a minimal executable. Then step by step
> add additional API calls and save the documentation for this
> API functions so you get your own API handbook for all the
> API calls you used.
Great for learning the binary format of a file. Then what? How does
this help you write Win32 apps in assembly?
> But I very fast lost interest in Win32
> assembly programming,
No wonder. Doing what you were doing would bore just about anyone to
death. Most people aren't really learning the APIs because it sounds
like a good idea. They're learning the APIs because they want to write
actual applications. Much better to have a tutorial that teaching them
how to write applications in a top-down fashion rather than a bottom-up
fashion. Regardless of what a few people around here believe, bottom-up
education is *not* natural for most people.
> because it mostly is a sequence of
> API calls and nothing I would call "assembly programming".
And therein lies the problem with the bottom-up approach. You spend all
your time learning API calls rather than concentrating on using
assembly language to actually *solve* problems.
> It is much more fun to directly access the hardware in a
> DOS program (even if only emulated by Windows in V86 mode).
Perhaps to you. This statement isn't universally true.
>
> Here the source of such a miniumal Win32 console program:
And how does this teach someone how to write assembly applications
under Win32?
Cheers,
Randy Hyde
Betov
news:431344C1...@unibwm.de:
> But I very fast lost interest in Win32
> assembly programming, because it mostly is a sequence of
> API calls and nothing I would call "assembly programming".
Very funny Herbert but if what you say here about Assembly
is true, could you please explain to me why, C Programming,
under Win32, would still be "C Programming"?
Betov.
Betov
news:1125337077.5...@f14g2000cwb.googlegroups.com:
> Regardless of what a few people around here believe, bottom-up
> education is *not* natural for most people.
Not natural for you, of course, as you never wrote
anything real, but for all the existing Asmers who
have written Applications in Assembly, there is no
"top" without a "bottom" first, unless we would be
talking of the usual wind, you blow on young heads
which vanishes by itself at altitude of your smoky
theories and ass-hole pedantisms.
:)
Betov.
wolfgang kern
JGCASEY wrote:
[...]
| I am still keen to spend time learning some Windows
| assembler as it can only make it easier to understand
| how the Win32 APIs are used.
All you need is "Win32.hlp" (~24MB)
Microsoft® Win32® Programmer's Reference
I can't tell where the official source for it is,
looks like it's only available within the whole M$-SDK pack.
I once got my copy from a fellow.
Most of the function usage is explained in C-style,
but translation into pure ASM is easy, ie:
BOOL DrawIconEx(
HDC hdc, // handle to device context
int xLeft, // x-coordinate of upper left corner
int yTop, // y-coordinate of upper left corner
HICON hIcon, // handle to icon to draw
int cxWidth, // width of the icon
int cyWidth, // height of the icon
UINT istepIfAniCur, // index of frame in animated cursor
HBRUSH hbrFlickerFreeDraw, // handle to background brush
UINT diFlags // icon-drawing flags
);
may become in HL-RosAsm:
call 'USER32.DrawIconEx',
HDC hdc, ; handle to device context
int xLeft, ; x-coord of upper left corner
int yTop, ; y-coord of upper left corner
HICON hIcon, ; handle to icon
int cxWidth, ; icon width
int cyWidth, ; icon height
UINT istepIfAniCur, ; frame index, animated cursor
HBRUSH hbrFlickerFreeDraw, ; handle to background brush
UINT diFlags ; icon-drawing flags
or with LL-RosAsm (with the more visible order on stack ):
push 0 ;&DI_...
push eax ;handle to bg-brush
push 1 ;frame index cursor
push 64 ;H
push 64 ;W
push D$ICONhdl2
push 1 ;y
push 620 ;x
push D$WDC |call 'USER32.DrawIconEx'
or will become in FASM/NASM LL-style:
push 0 ;&DI_...
push eax ;handle to bg-brush (from previous..)
push 1 ;frame index cursor
push 64 ;H
push 64 ;W
push dword [ICONhdl]
push 1 ;y
push 620 ;x
push dword [WDC]
call 'USER32.DrawIconEx' ;or any similar syntax there
__
wolfgang
rand...@earthlink.net
wolfgang kern wrote:
>
> may become in HL-RosAsm:
>
> call 'USER32.DrawIconEx',
> HDC hdc, ; handle to device context
> int xLeft, ; x-coord of upper left corner
> int yTop, ; y-coord of upper left corner
> HICON hIcon, ; handle to icon
> int cxWidth, ; icon width
> int cyWidth, ; icon height
> UINT istepIfAniCur, ; frame index, animated cursor
> HBRUSH hbrFlickerFreeDraw, ; handle to background brush
> UINT diFlags ; icon-drawing flags
Wow! Rene must have added a lot of new features recently!
I don't ever remember seeing RosAsm support HDCs, ints, HICONs, UINTs,
and HBRUSHes :-).
Obviously, the above is syntactically incorrect, suffering from a case
of cut&paste.
Of course, the cool thing is that assemblers like MASM and HLA actually
let you specify similar things to this. And, of course, MASM and HLA
also let you work in low-level code, just like RosAsm and FASM.
E.g.,
or will become in MASM LL-style:
pushd 0 ;&DI_...
push eax ;handle to bg-brush (from previous..)
pushd 1 ;frame index cursor
pushd 64 ;H
pushd 64 ;W
push ICONhdl
pushd 1 ;y
pushd 620 ;x
push WDC
call DrawIconEx ;or any similar syntax there
or will become in HLA LL-style:
pushd( 0 ); //&DI_...
push( eax ); //handle to bg-brush (from previous..)
pushd( 1 ); //frame index cursor
pushd( 64 ); //H
pushd( 64 ); //W
push( ICONhdl );
pushd( 1 ); //y
pushd( 620 ); //x
push( WDC );
call w.DrawIconEx
Amazing how similar these instruction sequences are. Yet a few people
around here keep insisting that MASM and HLA are HLLs, not assemblers.
Hmmm...
Cheers,
Randy Hyde
JGCASEY
rand...@earthlink.net wrote:
> Betov wrote:
Betov wrote:
>> "JGCASEY" <jgkjca...@yahoo.com.au> écrivait news:1125313208.846362.289800
>
>
> How about decent tutorials that teach you how to solve
> problems rather than simply teach you what API functions
> do?
You have read me correctly Randy.
While perusing your "Windows Programming in Assembly
Language" I read,
"Petzold estimates this (mastering the Win32 API set)
at six months for an established C programmer" my
heart sank and I thought, oh sh*t, I wonder how many
hours per day that would be. And how long for an
unestablished C programmer.
Of course I may not need to *master* the Win32 API
set only figure out how to use the ones relevant
to my limited needs. I am not out to write large
Window assembler programs. I am happy to use Java.
---------------------------------
At the Win32ASM Community messageboard in Win32ASM Main
a post from Bronty on Multiple Webcams
http://www.scrontsoft.com/win32asm/webcamapp.zip
How easy would that be to convert to a "readable"
HLA source code?
---------------------------------
This is the kind of stuff I would like to be able
to understand and modify (or even write) for my own
projects. I see myself writing some kind of generic
shell in which I can develop a library of modules
tailored to my personal interests.
I am not sure what skill level I must reach to
do this. There are many things you can do in
Windows that don't interest me. I just want to
write small stand alone code, like the example
above, that makes use of things like a webcam
and the GUI image display. The rest of the code
doesn't need any other Window stuff and could
just as easily run in DOS. Indeed if you don't
want the GUI you don't even need Windows. When
a computer is used to run a single application
with text i/o DOS is good enough... until you
need to hook up to hardware, or other software,
that only supports Windows!
I noticed that here, in Australia, that many of
the retail outlets have what appears to me to
be DOS text displays. Of course the supermarkets
have the fancy graphic displays which they use
to advertise products at the checkout.
I call it all dross and gloss :)
Cheers,
John Casey
JGCASEY
Betov wrote:
[...]
> Well, i did not not push RosAsm, when talking to you,
You are welcome to push RosAsm. I have looked at it
and the tutorial material. It is one of the possible
starting points and I will look at it again.
However I am not looking to become a Windows expert
only to learn enough to use DLLs, webcams, and things
like bitmaps. Much of Windows doesn't interest me.
It is a means to an end and I am a selective learner.
I am not planning to become a Windows guru or a
professional programmer. I just want to port the
things I could do with DOS, which are mostly OS
independent, to Windows or better still Linux.
I don't share your aversion to HLLs as I see them
as building a house out of prefabricated components.
But they do limit the kind of house you can build.
I developed a taste for assembler (building my own
bricks) and liked it. However Windows programming
is using Windows prefabricated APIs and you have
no option.
Even if I never get good enough at this Windows API to
achieve some of my goals I see it as an intellectual
passtime, as a break from other things. My wife solves
cross word puzzles when bored, I like to program things
when I am bored. It is a part time hobby.
Cheers,
John Casey
rand...@earthlink.net
JGCASEY wrote:
> >
> >
> > How about decent tutorials that teach you how to solve
> > problems rather than simply teach you what API functions
> > do?
>
>
> You have read me correctly Randy.
>
> While perusing your "Windows Programming in Assembly
> Language" I read,
> "Petzold estimates this (mastering the Win32 API set)
> at six months for an established C programmer" my
> heart sank and I thought, oh sh*t, I wonder how many
> hours per day that would be.
Full-time. Eight hours per day.
> And how long for an
> unestablished C programmer.
But take heart, you do not need to master the entire Win32 API (or even
a large percentage of it) to achieve useful stuff. The Iczelion
tutorials, for example, probably cover less than 1% of the entire Win32
API.
>
> Of course I may not need to *master* the Win32 API
> set only figure out how to use the ones relevant
> to my limited needs. I am not out to write large
> Window assembler programs. I am happy to use Java.
Exactly.
And even if you do want to write an assembly app or two, you'll be able
to get by using a tiny percentage of the total number if API calls.
Once you master some of the basic APIs (creating windows, passing
messages between windows, and stuff like that), then you can post
questions on a board like MASMForum, Win32Asm Community, CLAX, or even
here, when you want to do something but don't know the API to use.
Despite what some people may claim, just reading the MSDN doesn't help
that much (i.e., the "bottom-up" approach). With that approach, you
pretty much have to read the entire API list from start to finish every
time you want to achieve something whose API you don't know about.
That's why a good tutorial, or a book like Petzold's, is a good thing
to use. You can learn what you need to know by the type of
*functionality* you want, rather than in some unnatural (e.g.,
alphabetic by API name) ordering.
>
> ---------------------------------
> At the Win32ASM Community messageboard in Win32ASM Main
> a post from Bronty on Multiple Webcams
>
> http://www.scrontsoft.com/win32asm/webcamapp.zip
>
> How easy would that be to convert to a "readable"
> HLA source code?
I know both MASM and HLA pretty well. I could almost do a line-by-line
translation of the webcamapp from MASM to HLA and the result would be
roughly as readable as the original. YMMV, of course.
With a bit more work, you could make it more readable, of course.
>
> ---------------------------------
>
> This is the kind of stuff I would like to be able
> to understand and modify (or even write) for my own
> projects. I see myself writing some kind of generic
> shell in which I can develop a library of modules
> tailored to my personal interests.
Okay, sounds cool.
>
> I am not sure what skill level I must reach to
> do this. There are many things you can do in
> Windows that don't interest me.
This is true for everyone. I believe there are something like 2,000 to
2,500 API calls (I lost track at 1,500, back in the win2K days).
Clearly, most programmers only use a tiny fraction of these. If you
don't do networking, for example, the networking APIs probably won't be
of interest to you.
> I just want to
> write small stand alone code, like the example
> above, that makes use of things like a webcam
> and the GUI image display. The rest of the code
> doesn't need any other Window stuff and could
> just as easily run in DOS. Indeed if you don't
> want the GUI you don't even need Windows. When
> a computer is used to run a single application
> with text i/o DOS is good enough... until you
> need to hook up to hardware, or other software,
> that only supports Windows!
You *can* write console apps in Windows, you know.
Particularly if you've got a decent library like the HLA stdlib, you
can avoid most of the API stuff. GUI, of course, isn't all the API
calls you'll want, but at least you can eliminate that set. And if
you're not doing GUI apps, a lot of the complex event-oriented
programming paradigm (another big educational block if you've not done
that kind of programming before) goes away.
>
> I noticed that here, in Australia, that many of
> the retail outlets have what appears to me to
> be DOS text displays. Of course the supermarkets
> have the fancy graphic displays which they use
> to advertise products at the checkout.
>
> I call it all dross and gloss :)
:-)
Yes, console apps are *far* easier to write. Though VB and Delphi have
made the development of GUI apps far simpler, for many embedded apps
(like supermarket check-out registers; can you see the cashier saying
"can you wait while Windows reboots?") Windows just isn't a reasonable
choice.
Cheers,
Randy Hyde
rand...@earthlink.net
Betov wrote:
> "rand...@earthlink.net" <rand...@earthlink.net> écrivait
> news:1125337077.5...@f14g2000cwb.googlegroups.com:
>
> > Regardless of what a few people around here believe, bottom-up
> > education is *not* natural for most people.
>
> Not natural for you, of course, as you never wrote
> anything real,
Nor is it natural for most of the students learning assembly out there.
The Wolfgang/Herbert approach of "hand them the Intel manual and that's
all they need" just doesn't cut it.
But until *you've* actually *taught* a bunch of students, you'll only
have your own personal experiences on which to base your comments.
Given that beginners are not flocking to your product or your approach
to learning assembly language, I suggest that you rethink your beliefs
about what's best for beginners.
Cheers,
Randy Hyde
rand...@earthlink.net
So speaks the guy who has never taught a class, about the guy who has
taught thousands of students at the university level. Yep. You *would*
be the expert on how people learn material.
This example demonstrates *exactly* why your product is so poorly
received, Rene. You have this bizarre attitude that the rest of the
world thinks the same way you do; in fact, this is not true at all. At
some point, you should actually *try* teaching people using diffent
methodologies and see which one works the best, rather than assuming
everyone learns best based on your preconceived notions of how the
world ought to operate.
I've spent a *lot* of time trying *lots* of different pedagogical
methods for teaching assembly language over the years. And I can tell
you without hesitation that a bottom-up approach leaves students
feeling lost and uncomfortable. They want to know the "why" before
they want to know the "how". They want to see the big picture before
you overload them with details. They want to see where they are headed,
rather than having tons of stuff thrown at them with the assumption
that they'll figure out how to use all the stuff. They want to know the
*reason* why they're learning the stuff. The top-down approach
(starting general, working towards the specific) is a *much* better
received approach.
That's not to say it works best for everyone. I'm sure the few
Wolfgangs, Herberts, and Renes of the world work much better with a
bottom-up approach. But for the average student (particularly the
disinterested one), bottom-up doesn't work.
And until you've taught several classes both ways, you're not really in
a position to make statements about how the world operates on this
matter. You're just being myopic and viewing the world from your own
experiences. And given the number of people around here who disagree
with you on a continuing basis, I'd suspect that you'd get the
impression that what *you* think is a good idea is *not* what most
people think is a good idea.
Cheers,
Randy Hyde
Frank Kotler
...
> RosAsm _does_ exist,
Yes, it does. And it's a tool you can tell "just assemble the damn
thing". It installs pretty much "automatically" - no screwin' around
with "path to this" and "directory of that". Unzip the thing, and you're
ready to go.
I never used RosAsm much. I *prefer* working from a command prompt. I
*want* to be able to fiddle with the command line to the linker. The
"ease" of using RosAsm hasn't seduced me away from that. But I *did* try
it, and my first impression was "this would be *great* for beginners!"
You'll hear a lot of RosAsm-bashing around here. How it's "not a
professional tool" and how it crashes all the time... I don't recall
that it *ever* crashed on me! (but I didn't use it that much) No doubt
there *are* some glitches - it's an imperfect world - but *mostly* it
works fine.
You'll hear that RosAsm "doesn't have library support". True... but
"library support" is no business of an assembler. It'll either produce a
linkable object file or it won't (RosAsm won't). Beyond that, "library
support" is a function of the linker and/or a "librarian" tool, not the
assembler. An "integrated" tool *might* want to consider including some
"library support" - RosAsm chooses not to. If you want to link against
libraries, this is a problem. If you don't, it isn't.
I honestly think that *most* of the RosAsm-bashing is a reaction to how
unpleasant Betov can be to people he disagrees with. Not to say that
there isn't anything wrong with it, but it isn't *nearly* as bad as it's
made to sound. The folks who like it consider it a "work of genius". The
truth lies somewhere between these extremes, I suspect.
> Test Departement Tutorials and Iczelion Tutorials, the
> Interactive Visual Tutorials,
"Water, water everywhere, nor any drop to drink." I'm trying to guess
what sort of tutorial you'd find useful, John. I recall that you were
pretty competent in dos... I don't recall if you got into calling
subroutines with parameters on the stack, and "local" variables (also on
the stack). Windows tuts tend to "hide away" these details with "invoke"
and "proc" and "local" macros (or some variant). This could be pretty
mystifying, if you don't understand what they're doing. (RosAsm's
"unfolding" functionallity might help a lot here!).
Other than that, the "assembly language part" of a Windows program isn't
very complicated. A lot of it's just "filling up forms". Half of the
"cryptic names" are just a fancy name for zero. Once you've got the form
all filled in, you push its address onto the stack - along with some
more zeros, probably, and maybe some other things - and call the "black
box" which just does its thing "by magic".
I seem to recall that one of the programs you sent me was a "menu" thing
that allowed the user to select a file from a directory listing. To do
this in Windows, you just fill up a form - what directory to start from,
what file "mask" to use... a few other things - and call Windows. You
get a full-featured "browse box" with all the bells and whistles - up
and down directories, make a new directory, all "pointee clickee"
enabled. Just like a "real Windows program" :)
In terms of the "assembly language" required, it's a *lot* easier than
doing the same thing in dos! The difficulty is in discovering the
"cryptic names" for these things (and RosAsm puts help for that at your
mousie little fingertips, too).
Learning the API seems like the "hard part" to me. Yeoh just posted this
link to an API document to the win32-nasm-users list at Yahoo. I haven't
even looked at it, but I'll pass it along:
---------------------
Serge Novik has it here:
http://www.w32api.h15.ru/win32.html
------------------------
High Level Languages may provide some "convenience functions" to ease
access to the API, but sooner or later you're going to have to learn the
API (which is why I'm not much interested in Windows programming :) If
you get as far as "processing" an image from your webcam, you might get
into some "sophisticated" assembly language, but what you need to access
the API is fairly simple stuff...
...
> What else would you want? That the program learn, instead
> of you, and store the knowledge directly into your brain,
> while you sleep?
That would be cool. Got code? :)
> < http://rosasm.org >
Won't cost you a dime to look at it...
Best,
Frank
rand...@earthlink.net
Frank Kotler wrote:
>
> You'll hear that RosAsm "doesn't have library support". True... but
> "library support" is no business of an assembler.
Frank, I think you're confusing the term "library support" to mean that
the assembler includes lots of library routines. This isn't the meaning
of that term. NASM, FASM, even MASM do *not* provide such libraries.
What they provide, and the thing that is lacking in RosAsm, is the
ability to *use* library routines (or other statically linked objects).
And that *is* the business of the assembler to support, as that *vast*
majority of assembly code out there is linked against other code (e.g.,
HLLs).
"Library support" is simply shorthand for saying "it can produce OBJ
files that you can link with other code, and it has the ability to
reference objects appearing in other OBJ files." RosAsm fails on both
of these accounts with the exception of DLL support. And it's one of
those funny dichotomies that RosAsm supports *dynamic* linking, and
that's "compatible with assembly" while it doesn't support *static*
linking, which Rene claims is "incompatible with assembly." What Rene
really seems to be saying is that if he can't implement something in
*his* assembler, then it's "incompatible with assembly." :-)
Cheers,
Randy Hyde
JGCASEY
Frank Kotler wrote:
> Betov wrote:
[...]
>
> > Test Departement Tutorials and Iczelion Tutorials,
> > the Interactive Visual Tutorials,
>
> "Water, water everywhere, nor any drop to drink."
> I'm trying to guess what sort of tutorial you'd find
> useful, John. I recall that you were pretty competent
> in dos... I don't recall if you got into calling
> subroutines with parameters on the stack, and "local"
> variables (also on the stack).
Now I am feeling all nostalgic for the good old day :)
Although I never used MASMs directives or even macros
I do know about passing things via the stack.
Its been six years since I last used assembler so I
am most likely a little bit rusty. By "local" variables
on the stack I assume something like this?
push bp
mov bp,sp
.. then you use [bp + displacement]
to access the variables,
then exit with,
pop bp
ret 4 ;remove 4 or whatever number from stack.
> Windows tuts tend to "hide away" these details
> with "invoke" and "proc" and "local" macros (or
> some variant). This could be pretty mystifying,
> if you don't understand what they're doing.
> (RosAsm's "unfolding" functionality might help
> a lot here!).
Yes I need a clear understanding how to "unfold"
this in my mind and with MASM and FASM "fold"
it up as well?
> Other than that, the "assembly language part"
> of a Windows program isn't very complicated.
> A lot of it's just "filling up forms". Half of
> the "cryptic names" are just a fancy name for
> zero. Once you've got the form all filled in,
> you push its address onto the stack - along
> with some more zeros, probably, and maybe some
> other things - and call the "black box" which
> just does its thing "by magic".
One of the last things I did with DOS was play
with window like interfaces. So I have some idea
how the "magic" is done. I seem to remember
there were programming tools to do this in Dos
but at the time i thought it would be fun to
write my own version.
> I seem to recall that one of the programs you
> sent me was a "menu" thing that allowed the
> user to select a file from a directory listing.
> To do this in Windows, you just fill up a form
> - what directory to start from, what file "mask"
> to use... a few other things - and call Windows.
> You get a full-featured "browse box" with all
> the bells and whistles - up and down directories,
> make a new directory, all "pointee clickee"
> enabled. Just like a "real Windows program" :)
I have some idea of this from playing with VB
and VC++ after reading those "teach yourself in
21 days" type of books. However I couldn't find
the "teach yourself Window Assembler programming
in 21 days" book :)
> In terms of the "assembly language" required, it's a
> *lot* easier than doing the same thing in dos! The
> difficulty is in discovering the "cryptic names" for
> these things (and RosAsm puts help for that at your
> mousie little fingertips, too).
>
> Learning the API seems like the "hard part" to me.
> Yeoh just posted this link to an API document to the
> win32-nasm-users list at Yahoo. I haven't even looked
> at it, but I'll pass it along:
>
> ---------------------
> Serge Novik has it here:
> http://www.w32api.h15.ru/win32.html
> ------------------------
>
> High Level Languages may provide some "convenience
> functions" to ease access to the API, but sooner or
> later you're going to have to learn the API (which is
> why I'm not much interested in Windows programming :)
So what kind of programs do you write these days?
> If you get as far as "processing" an image from your
> webcam, you might get into some "sophisticated"
> assembly language, but what you need to access the
> API is fairly simple stuff...
I have already got as far as "processing" an image
using the QuickCam in dos and in a VC++ shell with
a LogiTech webcam. It is the fairly simple API
stuff I have to get my head around. The VC++ shell
was written using the MFC Wizard by someone else
not willing to show me how it was done.
When I saw the FASM example I thought cool, I
wonder how hard that would be?
Regards,
John Casey
Betov
@z14g2000cwz.googlegroups.com:
> I have some idea of this from playing with VB
> and VC++ after reading those "teach yourself in
> 21 days" type of books. However I couldn't find
> the "teach yourself Window Assembler programming
> in 21 days" book :)
Ah! I think i understand your problem, now...
The Win32 Api are not something that you could
_learn_. This would not mean a thing. NOBODY
knows "the Win32 Api". These are thousands and
thousands of sophisticated Functions, envolving,
often times, complicated Data Structures, and/or
Methods, orders, imbrications, return values,...
Nobody _knows_ this. At best, you will recall that
the "MessageBoxA" Function has 4 Parameters, that
the second one is the Message String, and that the
third one is the Box Title... But this is not, at
all this way, that we all work with the Win32 Api.
The time to learn the Win32 Functions is exactely
equal to zero and anyone who would tell you otherwise
would be a liar, having never written anything real.
For each need, we simply _search_ inside "Win32.hlp",
for the function doing what we need. Then each Param
description says to us what to implement, and how.
Do you expect that, for example, having a ToolBar
with BitMaps and TipTools associated, is something
that we could keep in our poor memory? No. Unless
you would write ToolBars everydays, you do never
memorize any of these details. You just read the
Doc, and/or Copy Paste some Template similar to
what you want.
Now, one another difficulty is with succeeding to
point out the required informations, inside such
a big informations base, as a Win32.hlp. I recall
having already explained this to you. This is the
only real thing you could learn about this subject,
and this capacity at pointing out the info, is,
mostly a matter of experience that you will acquire
in a couple of weeks.
Betov.
JGCASEY
Betov wrote:
> For each need, we simply _search_ inside "Win32.hlp",
> for the function doing what we need. Then each Param
> description says to us what to implement, and how.
Part of the problem here is knowing what to look
for and how to translate it into working code.
For this you need examples starting with the goal,
for example: A Simple Window. Then show how to
find the APIs required and how to use the Param
description to implement the goal. Now this may be
easy but it is not what the Izcelion tutorials do.
What I did today was carefully go through the
Izcelion tutorial "A Simple Window" and I think
I get the gist of what is involved. I then
compared the MASM version with the FASM, GoASM
and RosASM versions. All confusingly different
although making the comparisons did to some
extent separate the required from the quirks
of each assembler syntax.
Anyway I am getting closer to responding to
your previous post:
"As for the beginners tutorials, you have been
pointed to many very good ones, and, if you
fail to understand them, the only thing that
would be interesting (not considering the
analyse of your IQ... :) would be to hear you
saying _what_ kind of explanations you had
expect to find out of the zip, instead of the
ones we provide."
The first is they all assume a working knowledge
of the assembler syntax, and that includes the
high level stuff which is supposed to make them
easy to read but in fact, for me, hides the detail.
They are also long winded. As if talking a lot
will somehow make it easier to understand.
If I stick at this long enough to understand
enough to explain it to someone else I shall
try and write an example of the kind of tutorial
I would have liked to have had as an API beginner.
John.
Betov
@g49g2000cwa.googlegroups.com:
> The first is they all assume a working knowledge
> of the assembler syntax,
Many of them, yes... but you said that you _had_
that knowledge...
> and that includes the
> high level stuff which is supposed to make them
> easy to read but in fact, for me, hides the detail.
Depends which ones. Test Departement Tutorials, for
example, are 100% true low level, do not make use
of any macro, nor of any such "facilities", and
comment _each_ Instruction in an exhaustive manner.
> They are also long winded. As if talking a lot
> will somehow make it easier to understand.
This is a real problem. I could reformulate it in
another way, that is that each beginner has his
private way of thinking and learning, and, as we
are unable to write one type of tutorial, for one
type of beginner, we have no choice but to try to
please "most", by providing a significative amount
of BlaBla, that may, evidently, be of no use for
such and such user...
Considering the various points, we can resume them
in 3 different main categories:
* Using the Tool (the Assembler Syntax, IDE, and such)
* Assembly (Mnemonics, Declarations, and such)
* Api (with introduction examples)
This is what i have tried to do (with poor success, if
i rely on you... :) with my own Beginner's Tutorials,
that are actually the 6 first Interactive Visual Tuts
coming with RosAsm, where you have 4 Buttons saying:
[Description] (of what the Demo does when executed)
[Assembly] (explanation of a couple of Instruction per Tut)
[Api] (same for a couple of Functions)
[RosAsm Features] (just a couple of Tips&Tricks)
When runing these small Tutorials from RosAsm [Help]
Menu, you see 1) the Source of the Tutorial, 2) the
Dialog showing the Source to be Executed ([File] /
[Run], and 3) the Tutorial Dialog with the Informations
to be read.
It seems that, dispiting the impressive time i and
James spent at writing these Tutorials, we have missed
our goal, at least for you, but i still don't know,
exactely, why and how...
> If I stick at this long enough to understand
> enough to explain it to someone else I shall
> try and write an example of the kind of tutorial
> I would have liked to have had as an API beginner.
That would be a _very_ good thing... If you do it
for a _decent_ Assembler (FASM, RosAsm of GoAsm).
Betov.
Herbert Kleebauer
> Herbert Kleebauer <kl...@unibwm.de> écrivait
> > But I very fast lost interest in Win32
> > assembly programming, because it mostly is a sequence of
> > API calls and nothing I would call "assembly programming".
>
> Very funny Herbert but if what you say here about Assembly
> is true, could you please explain to me why, C Programming,
> under Win32, would still be "C Programming"?
Only very small applications are written in assembler. If
you only need a few dozen lines of assembler code for the
core program, then most of the source file is win32 overhead.
But if a real application, written in a HLL, has many thousands
of lines, then the win32 stuff maybe is acceptable.
For example, you want to write a simple text filter program which
reads from stdin and copies any printable ASCII character (0x20-0x7e)
to stdout. The program shall terminate when any key is pressed.
As a 16 bit DOS program, this is done in a few lines of assembler
code. Now show us an equivalent Win32 program.
When ever possible, I also use only standard IO in C programs, so
the program is OS independent and can be compiled with any C compiler
on any system (why do you think does an assembler need a GUI?).
The first time I really needed the Win32 API was, when I wrote a viewer
for encrypted multi-jpeg files (didn't want to leave all this nice
pictures you find on the net unencrypted on my hard disk). But
even this program I developed and debugged with the DOS port of
GCC and direct access to the graphics card to avoid as long as
possible this Win32 horror. But the final version had to be hardware
independent, so I had to port it to Win32. I installed Visual C++
and use the Wizard to generate a simple demo program. What a horrible
C source for a program which nearly did nothing. The first thing I
did, was to write a batch file so I could compile the program from
the command line and didn't have to use the IDE (I also never would
use an assembler like RosAsm which can't be used from the command line).
Then I searched MSDN and tried to identify all this crap in the C source
generated by the wizard. I remove anything not necessary to really
get a minimal Win32 C program for graphics output to the screen.
All Windows specific code of the jpeg viewer is in a separate file
which is included (instead of the DOS specific code use for development)
at the start of the still OS independent main code. This way the
program can easily ported to other OSes (or OSs or OS's what ever
is correct).
After I had done this first step in Win32 programming, I wanted
to know what's exactly in a Win32 executable. I disassembled
a small exe file and removed anything not necessary to get a
minimal Win32 assembler source. Then I wrote this Erde demo
(which is a port of the fascinating mars demo, written by
T.J. Clarke 10 years ago). But Win32 programming is as awful
in assembler as in C. So an advice to all who want to learn
assembly programming: do it in DOS (or in V86 mode of Windows)
but not in Windows. Assembly programming is programming the
CPU (which is completely independent of the used OS) and not
learning an awful OS API. But I don't understand your repeating
mention of the so called "Win32 assembler programming pioneers"
who made Win32 assembly programming possible. All you need to
do Win32 assembly programming is:
you must be a masochist
you need a disassembler
you need a few weeks free time to surf at MSDN.com
But you surely don't need any tutorial of an assembly pioneer.
f0dder
> All you need to do Win32 assembly programming is:
> you must be a masochist
> you need a disassembler
> you need a few weeks free time to surf at MSDN.com
All you need to do is learn 32bit assembly and learn the WIN32 API.
Hardly rocket science. I don't see what's oh-so-difficult about
all this, the only thing that was required was no-brain manual
labour. Disassemblers weren't even needed, not even to infer the
calling convention and register preservation rules (C++ compilers
"assembly listing" switches come to mind).
Pioneers? More like people with too much free time on their hands :)
Betov
news:4314AA09...@unibwm.de:
> Betov wrote:
>> Herbert Kleebauer <kl...@unibwm.de> écrivait
>
>> > But I very fast lost interest in Win32
>> > assembly programming, because it mostly is a sequence of
>> > API calls and nothing I would call "assembly programming".
>>
>> Very funny Herbert but if what you say here about Assembly
>> is true, could you please explain to me why, C Programming,
>> under Win32, would still be "C Programming"?
>
> Only very small applications are written in assembler.
???!!!... And, in what term does this answer to my question?
> If
> you only need a few dozen lines of assembler code for the
> core program, then most of the source file is win32 overhead.
> But if a real application, written in a HLL, has many thousands
> of lines, then the win32 stuff maybe is acceptable.
???!!!... RosAsm Source, that is 3 Megas long calls
for about one hundread of Api Functions.
... And then???!!!...
> For example, you want to write a simple text filter program which
> reads from stdin
I have never heard of any "Standard In" in any actual OS.
> and copies any printable ASCII character (0x20-0x7e)
> to stdout.
I have never heard of any "Standard Out" in any actual OS.
> The program shall terminate when any key is pressed.
> As a 16 bit DOS program, this is done in a few lines of assembler
> code. Now show us an equivalent Win32 program.
DOS is dead since ages.
> When ever possible, I also use only standard IO in C programs, so
> the program is OS independent and can be compiled with any C compiler
> on any system (why do you think does an assembler need a GUI?).
Feel free to believe in things that do not exist, if you
like, but, to me, believing in something that does not exist
is a mental disease.
> The first time I really needed the Win32 API was, when I wrote a viewer
> for encrypted multi-jpeg files (didn't want to leave all this nice
> pictures you find on the net unencrypted on my hard disk). But
> even this program I developed and debugged with the DOS port of
> GCC and direct access to the graphics card to avoid as long as
> possible this Win32 horror. But the final version had to be hardware
> independent, so I had to port it to Win32. I installed Visual C++
> and use the Wizard to generate a simple demo program. What a horrible
> C source for a program which nearly did nothing. The first thing I
> did, was to write a batch file so I could compile the program from
> the command line and didn't have to use the IDE (I also never would
> use an assembler like RosAsm which can't be used from the command
line).
> Then I searched MSDN and tried to identify all this crap in the C
source
> generated by the wizard. I remove anything not necessary to really
> get a minimal Win32 C program for graphics output to the screen.
> All Windows specific code of the jpeg viewer is in a separate file
> which is included (instead of the DOS specific code use for
development)
> at the start of the still OS independent main code. This way the
> program can easily ported to other OSes (or OSs or OS's what ever
> is correct).
I have compassions for your difficulties, but i fail to
understand in what term this could answer to my question.
> After I had done this first step in Win32 programming, I wanted
> to know what's exactly in a Win32 executable. I disassembled
> a small exe file and removed anything not necessary to get a
> minimal Win32 assembler source. Then I wrote this Erde demo
> (which is a port of the fascinating mars demo, written by
> T.J. Clarke 10 years ago). But Win32 programming is as awful
> in assembler as in C.
I have payed to know that PEs are more complicated than
.com, but i fail to see why this would make them "awful".
"More complex" is not "awfull".
> So an advice to all who want to learn
> assembly programming: do it in DOS (or in V86 mode of Windows)
> but not in Windows.
This does not answer to my question, and is utterly faulse:
Assembly Programing is _way_ easier than DOS programming
(i did both, for a significative amount of Sources Megas).
> Assembly programming is programming the
> CPU (which is completely independent of the used OS) and not
> learning an awful OS API.
Try to teach DOS without calling for any Int.
> But I don't understand your repeating
> mention of the so called "Win32 assembler programming pioneers"
> who made Win32 assembly programming possible. All you need to
> do Win32 assembly programming is:
> you must be a masochist
> you need a disassembler
> you need a few weeks free time to surf at MSDN.com
>
> But you surely don't need any tutorial of an assembly pioneer.
???!!!...
I just asked you a simple and clear question:
"could you please explain to me why, C Programming, under
Win32, would still be "C Programming"?".
... by simply _reversing_ a statement of yours, and to show
you at what extend your statement was absurd. Here, you just
make use a Method we are now very used to, thanks to Master
Randall Hyde swindling, that is, that, when locked in your
own contradiction, you just have to write two or three pages
of bullshits about something else.
You deceive me, Herbert.
Betov.
f0dder
>> For example, you want to write a simple text filter program which
>> reads from stdin
>
> I have never heard of any "Standard In" in any actual OS.
>
>> and copies any printable ASCII character (0x20-0x7e)
>> to stdout.
>
> I have never heard of any "Standard Out" in any actual OS.
GetStdHandle(Parameters: nStdHandle)
Specifies the standard device for which to return the handle. This parameter
can be one of the following values. Value Meaning
STD_INPUT_HANDLE Standard input handle
STD_OUTPUT_HANDLE Standard output handle
STD_ERROR_HANDLE Standard error handle
...unix has stdin,stderr,stdout as well.
>> The program shall terminate when any key is pressed.
>> As a 16 bit DOS program, this is done in a few lines of assembler
>> code. Now show us an equivalent Win32 program.
>
> DOS is dead since ages.
Agreed :)
JGCASEY
Betov wrote:
> "JGCASEY"
>> The first is they all assume a working knowledge
>> of the assembler syntax,
>
>
> Many of them, yes... but you said that you _had_
> that knowledge...
Only the old syntax without the .Else_If stuff I
see in your source code. Then there is the strange
looking macros. Very little looks like the DOS
code I used. But anyway the tutorials need to deal
with an absolute beginner so a working knowledge
of the assembler syntax is needed. This is best
done, in my opinion, by introducing them in stages
as needed to understand a particular program.
>> and that includes the
>> high level stuff which is supposed to make them
>> easy to read but in fact, for me, hides the detail.
>
>
> Depends which ones. Test Department Tutorials, for
> example, are 100% true low level, do not make use
> of any macro, nor of any such "facilities", and
> comment _each_ Instruction in an exhaustive manner.
>
>
>> They are also long winded. As if talking a lot
>> will somehow make it easier to understand.
>
>
> This is a real problem. I could reformulate it in
> another way, that is that each beginner has his
> private way of thinking and learning, and, as we
> are unable to write one type of tutorial, for one
> type of beginner, we have no choice but to try to
> please "most", by providing a significative amount
> of BlaBla, that may, evidently, be of no use for
> such and such user...
>
> Considering the various points, we can resume them
> in 3 different main categories:
>
>
> * Using the Tool (the Assembler Syntax, IDE, and such)
>
>
> * Assembly (Mnemonics, Declarations, and such)
>
>
> * Api (with introduction examples)
That appears to cover it. For an absolute beginner
you would have to cover binary numbers perhaps?
> This is what i have tried to do (with poor success, if
> i rely on you... :) with my own Beginner's Tutorials,
> that are actually the 6 first Interactive Visual Tuts
> coming with RosAsm, where you have 4 Buttons saying:
>
>
> [Description] (of what the Demo does when executed)
> [Assembly] (explanation of a couple of Instruction per Tut)
> [Api] (same for a couple of Functions)
> [RosAsm Features] (just a couple of Tips&Tricks)
>
>
> When running these small Tutorials from RosAsm [Help]
> Menu, you see 1) the Source of the Tutorial, 2) the
> Dialog showing the Source to be Executed ([File] /
> [Run], and 3) the Tutorial Dialog with the Informations
> to be read.
Do you mean those funny little pop up window thingies
IVTOOOBeginner_1? It would be nice to be able to
print them out. I do like hardcopy. From your IDE
Help menu I chose IVTOOOBeginner_1.exe to be greeted
with a source file I couldn't read. Nothing like the
DOS code? Except for the occasional move eax &FALSE.
I assume & means address?
> It seems that, dispiting the impressive time i and
> James spent at writing these Tutorials, we have missed
> our goal, at least for you, but i still don't know,
> exactly, why and how...
Maybe it's the IQ thing :)
Perhaps DOS is for dummies so I found it easy to
learn from a couple of assembler books? A low
level OS for a low level brain :)
I have just been looking at your RosAsm. I didn't
realise you had a Wizard there to create a form
template. I assume you than just add in code like
you do for VB? Indeed you seem to have a lot of
useful programming aids but I am not sure how i
would use them.
There are issues like, you have the means to load
resources but I am not sure how you integrate this
into a program. Things like an image, for example,
in DOS the program would load it as a file into
some allocated memory location. I would have my
own display routines.
To test a tutorial I guess you need to sit a
complete beginner down and see where/if they
are not sure what to do next or cannot follow
the explanation.
Thank you for your efforts in trying to work out
my issues. I am not sure what to do about them.
Regards,
John
rand...@earthlink.net
Betov wrote:
>
> > For example, you want to write a simple text filter program which
> > reads from stdin
>
> I have never heard of any "Standard In" in any actual OS.
Demonstrates your ignorance.
>
>
> > and copies any printable ASCII character (0x20-0x7e)
> > to stdout.
>
> I have never heard of any "Standard Out" in any actual OS.
Also demonstrates your ignorance.
>
> > When ever possible, I also use only standard IO in C programs, so
> > the program is OS independent and can be compiled with any C compiler
> > on any system (why do you think does an assembler need a GUI?).
>
> Feel free to believe in things that do not exist, if you
> like, but, to me, believing in something that does not exist
> is a mental disease.
You mean, like the "assembly rebirth?" :-)
> You deceive me, Herbert.
>
Turnabout is fair play, Rene.
Cheers,
Randy Hyde
wolfgang kern
Hi John,
| rand...@earthlink.net wrote:
I'd forget as fast as possible what a weird old man try to sell
as the only truth.
[...]
| I am not sure what skill level I must reach to do this.
You don't need very high abstracted skills to read and understand
the win32.hlp.
But you might need some help (I also needed to become started with),
to get the main clue of how windoze-API shall be used.
Just ask away, all your question are welcome here.
__
wolfgang
Betov
@g43g2000cwa.googlegroups.com:
>> * Using the Tool (the Assembler Syntax, IDE, and such)
>>
>>
>> * Assembly (Mnemonics, Declarations, and such)
>>
>>
>> * Api (with introduction examples)
>
>
> That appears to cover it. For an absolute beginner
> you would have to cover binary numbers perhaps?
Not there... See [F1]/[Beginners' Steps]... and read
a bit of these "can't_do_without" Chapters...
>> When running these small Tutorials from RosAsm [Help]
>> Menu, you see 1) the Source of the Tutorial, 2) the
>> Dialog showing the Source to be Executed ([File] /
>> [Run], and 3) the Tutorial Dialog with the Informations
>> to be read.
>
> Do you mean those funny little pop up window thingies
> IVTOOOBeginner_1?
Yes. Believe it or not, they represent a _LOT_ of
work...
:)
> It would be nice to be able to
> print them out. I do like hardcopy. From your IDE
> Help menu I chose IVTOOOBeginner_1.exe to be greeted
> with a source file I couldn't read. Nothing like the
> DOS code? Except for the occasional move eax &FALSE.
> I assume & means address?
You seem to write more questions, than you read the
answers, don't you?
:)))
This is what you should have seen right in front of
your nose, hafter having clicked upon [Assembly],
in the Tutorial Dialog where this _Win32 Equate_
Notation is explained in the first lines...
???... or did not you even depress [F6] ???...
> Perhaps DOS is for dummies so I found it easy to
> learn from a couple of assembler books? A low
> level OS for a low level brain :)
I have written Megas of Source both for DOS and for
Win32: Win32 Asm is _WAY_ easier.
> I have just been looking at your RosAsm. I didn't
> realise you had a Wizard there to create a form
> template. I assume you than just add in code like
> you do for VB? Indeed you seem to have a lot of
> useful programming aids but I am not sure how i
> would use them.
From RosAsm, you load any File (take Base3.exe...),
and you Run the Wizard from the Menu. After Edition,
when you leave the Wizard, it pastes automatically
the Edited _Source_ into your actual Source, at the
Position of your Cursor. Then you just call for it,
from where-ever you'd like...
> There are issues like, you have the means to load
> resources but I am not sure how you integrate this
> into a program. Things like an image, for example,
> in DOS the program would load it as a file into
> some allocated memory location. I would have my
> own display routines.
When you edit (create) or load a Resource, with RosAsm,
you just have to depress [F5] for having it compiled
into your PE.
Then, you execute it, from your code, by calling for
the appropriated Api, which depends on the Resource
Type... which is explained, in detail, in almost all
and any Win32 Tutorials and Demos sets...
> To test a tutorial I guess you need to sit a
> complete beginner down and see where/if they
> are not sure what to do next or cannot follow
> the explanation.
>
> Thank you for your efforts in trying to work out
> my issues. I am not sure what to do about them.
I would suggest that you ask a bit less questions
at ALA, and that you read a bit more of Tutorials,
Demos and Documentations, and then, that you try to
do something not too complex, for a first hand.
:))
Juts clicking on "IVTOOOBeginner_1", and not even
reading the first lines cannot help a lot, and i
cannot read them for you (i and James had enough
work at writing them...).
;)
Betov.
Betov
$edfa...@dtext01.news.tele.dk:
>> I have never heard of any "Standard Out" in any actual OS.
>
> GetStdHandle(Parameters: nStdHandle)
Don't joke me, please. I am serious when saying
that there is no room, in a modern OS, for any
"Standard" thingie.
Betov.
Alex McDonald
Are you being serious here? Or is _this_ meant as a joke?
--
Regards
Alex McDonald
rand...@earthlink.net
JGCASEY wrote:
> > Many of them, yes... but you said that you _had_
> > that knowledge...
>
> Only the old syntax without the .Else_If stuff I
> see in your source code.
This is the really funny part about RosAsm. Rene constantly gripes
about the HLL-like statements in MASM, TASM, and HLA, and then sticks
all these macros into his source code to simulate them all. He somehow
believes that because he's used macros rather than building them into
the assembler that this somehow means something different to the end
user. I keep telling him that if someone is opposed to "IFs" and
"WHILEs" in assembly language, they'll be opposed to them regardless of
their implementation.
Thank you for demonstrating this point.
> Then there is the strange
> looking macros.
And the syntax in general. For some reason Rene likes to claim that
RosAsm's syntax is "Intel Syntax". It has been pointed out to him over
and over again that his syntax isn't even close. And the way typical
Rosasm source files are written, the code often looks like an explosion
in an alphabet soup factory. Here is some of Wolfgang's code from his
Kesys program, for example (and don't think this is just Wolfgang's
problem, most RosAsm source code is formatted this way):
MainWindowProc: ;esp+00=ret +04=hdl +08=msg +0c=wP +10=lP
pushad
; mov edx D$esp+024 ;hdl
mov eax D$esp+028 ;msg
mov ebx D$esp+02c ;wP
; mov ecx D$esp+030c ;lP
cmp eax &WM_CHAR |jnz L7>>
mov al bl
cmp al 30h |jc L5> |cmp al 3Ah |jc L0>
and al 5fh |cmp al 'X' |jz L4>
cmp al 41h |jc L5> |cmp al 47h |jnc L5>
L0: sub al 30h |cmp al 0ah |db 072 02 |sub al,07 |shl D$INPval 4 |or
B$INPval al |mov b$keyflag+1 al
mov ebx Kname00 |mov eax D$Kindex |mov cl B$KsizeE2 |shl eax cl
|add ebx eax
mov eax D$INPval |mov D$ebx+010 eax
L3: call repaint |cmp D$INPptr 9 |jc L9>>
xor eax eax |mov D$INPptr eax |mov D$INPval eax| jmp L9>>
L4: xor b$keyflag 080h |jmp L9>
Quite honestly, it looks like code written by a BASIC programmer back
in the days when people discovered that BASIC programs ran a little
faster when you crammed as many statements on one line as you could.
There is *one* thing you can say about Wolfgang's (versus Rene's) code,
however. He doesn't use macros (including all the HLL-like statements).
> Very little looks like the DOS
> code I used.
This is why it's good to learn and use a standard set of library
routines. When you move from OS to OS (as you've done from DOS to
Windows), you can port your library routines to the new OS and the code
will look just as it did before. If you're really good about how you
maintain your library, you can even port your code from OS to OS. The
HLA Standard Library, for example, is portable between Linux and
Windows, requiring only a recompile to get an application running under
either OS.
> But anyway the tutorials need to deal
> with an absolute beginner so a working knowledge
> of the assembler syntax is needed. This is best
> done, in my opinion, by introducing them in stages
> as needed to understand a particular program.
Writing a decent set of tutorials that take beginners from point zero
to experienced assembly programmer takes a lot of work and experience.
Some people (like Rene) seem to think that there is no work involved in
this process. Nothing could be farther from the truth. Generally, the
first thing that comes to mind when someone sets off to write a
tutorial really doesn't work for most people who read the tutorial.
Believe me, I've tried a lot of different teaching methods over the
years (and incorporated what I've learned into books like AoA and the
materials I've written for Webster). It takes a lot of "trial and
error" to fine tune pedagogical material so that it works for a lot of
people. And no single tutorial or book is going to work for everyone.
For example, you've alluded to the fact that you like things as concise
as possible. The majority of people, however, don't like curt
tutorials. They want friendly and approachable explainations. You can't
write a tutorial that is going to satisfy both types of people.
>
> That appears to cover it. For an absolute beginner
> you would have to cover binary numbers perhaps?
>
Actually, there is the whole subject of machine organization that needs
to be covered. Indeed, "machine organization" is what people are
*really* expected to learn when they take an assembly language course
at the local college or university. Binary numbers (actually, data
representation) is certain a part of this, but there is quite a bit
more (such as logic, basic computer architecture/organization, basic
I/O, and stuff like that).
>
> Do you mean those funny little pop up window thingies
> IVTOOOBeginner_1? It would be nice to be able to
> print them out. I do like hardcopy. From your IDE
> Help menu I chose IVTOOOBeginner_1.exe to be greeted
> with a source file I couldn't read. Nothing like the
> DOS code? Except for the occasional move eax &FALSE.
> I assume & means address?
As I've said earlier, most RosAsm code looks like an explosion in an
alphabet soup factory to me. And people like Wolfgang constantly
complain that I tend to suggest that beginners concentrate on writing
readable/understandable code rather than the tightest or most efficient
code. Most of the RosAsm sample code I've seen (including Wolfgang's
own Kesys program) amply demonstrate why it's important to write
readable, understandable code. Especially when you're including that
code as part of a "tutorial".
Herein lies a major problem with the RosAsm tutorials I've looked at.
They were written by people who've mastered (?) some subject, for their
peers. The RosAsm team stands around and pats themselves on the backs
because they've written all these "megas of tutorials" but they've
never really tried them out on a large number of people to determine if
they are practical or if they achieve what they are intended to
achieve. To my knowledge, no one on the RosAsm team has any experience
teaching a formal assembly language class. So they really have no idea
what beginning assembly language programmers want or need. They just
crank out this code and assume that it satisfies some need. Oh well,
more power to them I suppose. Somebody *may* benefit from the work, and
that's what really counts. But I suspect that most people are like you.
They view these things and think "Okay, this is a nice demo, but it
doesn't really teach me much."
>
>
> > It seems that, dispiting the impressive time i and
> > James spent at writing these Tutorials, we have missed
> > our goal, at least for you, but i still don't know,
> > exactly, why and how...
>
>
> Maybe it's the IQ thing :)
If you read through Rene's posts here on ALA, you will see him
constantly criticizing my work as being "no work at all" or "simple
rephrasing of others' work", etc., etc., etc. The RosAsm team has yet
to figure out that writing good books, example code, tutorials, and
tools that operate in a synergistic fashion to help beginners learn the
material as rapidly and efficiently as possible isn't simply cranking
out some demo code and some poorly written and organized documentation.
It is a lot of work. Any tutorial that makes someone feel stupid, as
Rene puts it, "misses the goal."
>
> Perhaps DOS is for dummies so I found it easy to
> learn from a couple of assembler books? A low
> level OS for a low level brain :)
There is no reason the same books couldn't be written for Win32. It's
not really "DOS vs. Windows" but rather "console apps vs. GUI apps."
And you can write console apps in true WIN32 all the time. It's really
easy. Particularly if you have a set of library routines like the HLA
Standard Library. You don't have to get lost opening windows and doing
all that GUI stuff when you're first learning Win32 APIs. You can write
good old console apps, that are easy to comprehend. And then when you
get up to speed on assembly, you can look at the Iczelion tutorials and
other Win32 GUI sample code that teaches you how to write GUI apps.
The problem you seem to be having is trying to learn too much at once.
Concentrate on one thing at a time. Start with the x86 instruction set
writing some console apps. *THEN* move on to the more complex Win32
APIs. I think you'll find this a more comfortable approach.
BTW, both HLA and MASM32 provide good support for console applications
in their libraries.
>
> I have just been looking at your RosAsm. I didn't
> realise you had a Wizard there to create a form
> template. I assume you than just add in code like
> you do for VB? Indeed you seem to have a lot of
> useful programming aids but I am not sure how i
> would use them.
The wizard is like the disassembler. More promise than reality at this
point. Rene is promising us that someday RosAsm will be like VB or
Delphi allowing you to create complex apps with just a few mouse
clicks. But we've been hearing this for years now (since about 2000),
so I wouldn't hold my breath if I were you. RadAsm, btw, has similar
capabilities.
>
> There are issues like, you have the means to load
> resources but I am not sure how you integrate this
> into a program. Things like an image, for example,
> in DOS the program would load it as a file into
> some allocated memory location. I would have my
> own display routines.
Well, you can still do it like you've done it in DOS (reading files).
Windows has APIs for embedded resources into the EXE file as well. But
that's some of the more advanced APIs that I'd recommend you put off
learning about until you get a little more comfortable with the basic
x86 assembly stuff. Again, writing console apps will allow you to do
things the way you did it under DOS, without the information overload
of having to learn all these different APIs all at once. Later on, you
can learn about resource compilers and how to link in those resources
with your application files. And, btw, don't forget that RosAsm doesn't
support static linking, a problem when using resources from different
sources, IIRC.
>
> To test a tutorial I guess you need to sit a
> complete beginner down and see where/if they
> are not sure what to do next or cannot follow
> the explanation.
Yes, that's a large part of it. And I'm sure this process never
occurred to the RosAsm team with respect to their tutorials. They have
a long and storied history of ignoring what the marketplace really
wants and taking it upon themselves to dictate what the market *ought*
to want. They seem to be more interested in filling in bullets on a
feature matrix and having as many bullets as possible rather than
ensuring that the quality of those features is as high as possible.
"You wrote a tutorial? Great, mark an "X" in that part of the feature
matrix and let's move on to something else..."
>
> Thank you for your efforts in trying to work out
> my issues. I am not sure what to do about them.
Well, I'd stick with MASM and MASM32 if I were you. That seems to be
the approach best suited for you. On the MASMForum, ask the people
about standard in/out and console routines. I think you'll find that
once you learn a few things, writing console apps will be as easy as
writing DOS programs. Of course, HLA also makes writing console apps
trivial, and best of all, they are portable to Linux should you decide
to mess around with that OS.
Cheers,
Randy Hyde
Herbert Kleebauer
> Herbert Kleebauer <kl...@unibwm.de> écrivait
> >> > But I very fast lost interest in Win32
> >> > assembly programming, because it mostly is a sequence of
> >> > API calls and nothing I would call "assembly programming".
> >>
> >> Very funny Herbert but if what you say here about Assembly
> >> is true, could you please explain to me why, C Programming,
> >> under Win32, would still be "C Programming"?
> >
> > Only very small applications are written in assembler.
>
> ???!!!... And, in what term does this answer to my question?
Ok, I will repeat it in short and simple sentences:
If you write a program (doesn't matter whether you write in
assembler or a HLL), then there is a part which is OS independent
(like a numerical calculation or the conversion of an assembler
source line into the binary opcode) and a part which is OS
dependent (display graphics, get keyboard and mouse input etc.).
Now, the first part I would call (assembly or C) "programming"
whereas the second part doesn't deserve the name "programming",
it is nothing but a sequence of calls to the OS. The complete
thing can be called programming if the first part is at least
of the same magnitude as the second part. If you implement
the below program in DOS, than this can be called programming
because only a few lines of code are necessary to do the OS calls.
But if you implement it as a Windows program (and believe me,
there is a stdin and stdout in Windows) then part 2 gets much
bigger than part 1, so the whole thing doesn't deserve the
name "programming".
> > If
> > you only need a few dozen lines of assembler code for the
> > core program, then most of the source file is win32 overhead.
> > But if a real application, written in a HLL, has many thousands
> > of lines, then the win32 stuff maybe is acceptable.
>
> ???!!!... RosAsm Source, that is 3 Megas long calls
> for about one hundread of Api Functions.
RosAsm is written in assembler because it's author isn't
able to recognize the advantage of HLLs for implementing
larger applications.
> ... And then???!!!...
And then ... the author of RosAsm should do some programming
in a HLL to see the advantage himself. You can't compare two
things if you only have used one of them and always refused
to also try the other.
> > For example, you want to write a simple text filter program which
> > reads from stdin and copies any printable ASCII character (0x20-0x7e)
> > to stdout.
> > The program shall terminate when any key is pressed.
> > As a 16 bit DOS program, this is done in a few lines of assembler
> > code. Now show us an equivalent Win32 program.
>
> DOS is dead since ages.
You don't need DOS6.2 or older, Windows XP will execute this
program without any problem (or is XP also dead since ages?).
> > When ever possible, I also use only standard IO in C programs, so
> > the program is OS independent and can be compiled with any C compiler
> > on any system (why do you think does an assembler need a GUI?).
>
> Feel free to believe in things that do not exist, if you
> like, but, to me, believing in something that does not exist
> is a mental disease.
About which "things that do not exist" are you speaking here?
> I have compassions for your difficulties, but i fail to
> understand in what term this could answer to my question.
Your question was fully answered in the first few sentences of
my posting.
> I have payed to know that PEs are more complicated than
> .com, but i fail to see why this would make them "awful".
> "More complex" is not "awfull".
I'm not speaking about the structure of a PE file compared
to a com file, but about the Win32 API compared to the
int21 interface.
> > So an advice to all who want to learn
> > assembly programming: do it in DOS (or in V86 mode of Windows)
> > but not in Windows.
>
> This does not answer to my question, and is utterly faulse:
>
> Assembly Programing is _way_ easier than DOS programming
????? This sentence is like: "Driving a car is _way_ easier than
driving on the highway". You can do assembly programing in DOS
or Windows or you can do DOS programing in assembler or C, but
how can you compare "assembly programming" with "DOS programing"?
> > Assembly programming is programming the
> > CPU (which is completely independent of the used OS) and not
> > learning an awful OS API.
>
> Try to teach DOS without calling for any Int.
One page is sufficient to explain anything necessary to
start assembly programming in DOS (fopen, fclose, getc, putc,
test and read keyboard, get mouse position, switch to graphics
mode). Try the same with the Win32 API.
> I just asked you a simple and clear question:
>
> "could you please explain to me why, C Programming, under
> Win32, would still be "C Programming"?".
And I gave you a simple and clear answer.
> ... by simply _reversing_ a statement of yours, and to show
> you at what extend your statement was absurd. Here, you just
> make use a Method we are now very used to, thanks to Master
> Randall Hyde swindling, that is, that, when locked in your
> own contradiction, you just have to write two or three pages
> of bullshits about something else.
Please reread my previous posting.
JGCASEY
Betov wrote:
[...]
> I would suggest that you ask a bit less questions
> at ALA, and that you read a bit more of Tutorials,
> Demos and Documentations, and then, that you try to
> do something not too complex, for a first hand.
>
>
> Just clicking on "IVTOOOBeginner_1", and not even
> reading the first lines cannot help a lot, and i
> cannot read them for you (i and James had enough
> work at writing them...).
Ok. Enough of the questions. Just one last thing
about the pop up window tuts. I like a 'module'
of information per page without scrolling. I find
it easier to read if the whole screen of data is
there for the viewing without having to scroll.
John.
Frank Kotler
...
> Its been six years since I last used assembler so I
> am most likely a little bit rusty. By "local" variables
> on the stack I assume something like this?
Pretty much, yeah...
> push bp
> mov bp,sp
This is enough to cover parameters passed on the stack. For
"local"/"automatic" variables, we also need to subtract something from
(e)sp - so we can push/pop without overwriting our variables.
sub (e)sp, number of local variables * size of variable
Normally, "size" would be two (bytes) for 16-bit code, and 4 for 32-bit
code. IOW, the amount to subtract is the number of *bytes* taken up by
local variables, even though they're probably mostly dwords. It's okay
to have byte or word variables on the stack. If you come out with an
"odd" number, you want to realign the stack,,,
and (e)sp, -4
You might want a larger alignment than this - if you're using 64- or
128-bit variables, for example.
> .. then you use [bp + displacement]
> to access the variables,
Yeah. [(e)bp + displacement] for the parameters, [(e)bp - displacement]
for local variables, actually.
> then exit with,
First, we want to restore (e)sp to its original value:
mov (e)sp, (e)bp
This has the effect of "freeing" the local variables (this is why C
calls this "automatic" storage). Needless to say, we don't want to alter
(e)bp in the interim!!! In 16-bit code, [sp] isn't a valid addressing
mode, but in 32-bit code, we *can* do [esp + displacement], so we *can*
access parameters and locals that way. The "displacement" of a
particular variable will change as we push/pop, so it's a PITA to keep
track of, but it frees up ebp to use as a "general purpose" register,
which is sometimes worthwhile.
> pop bp
> ret 4 ;remove 4 or whatever number from stack.
Whether it's "ret number_of_bytes" or just "ret" depends on the calling
convention. The Windows API uses "stdcall" in which "callee cleans up
stack" - the Windows functions end with "ret N". The C calling
convention expects "caller cleans up stack" - the C functions end with
just "ret". We need to know which we're dealing with!
Another issue is the "Intel ABI" (Application Binary Interface).
Personally, I think it's a misleading name, since the hardware doesn't
give a damn, but that's what it's called. Functions are allowed to trash
certain registers, but are expected to return others the same way we
found 'em. Registers that must be saved/restored if they're altered are
ebx, esi, edi, ebp, and of course esp. The return value is normally in
eax, maybe edx:eax - ecx is "scratch". Being an old dos-head, I'm used
to using (e)cx as a "counter", and it annoys me that calling libc or the
Windows API is allowed to trash it, but that's life...
In your *own* routines, you can do it any way you like (more
"maintainable" if you're consistant), but if you're calling Windows you
can expect that behavior, and if Windows is calling you (your WndProc,
for example), then your routine has to obey these rules.
...
> However I couldn't find
> the "teach yourself Window Assembler programming
> in 21 days" book :)
"Windows Assembly for Dummies" is right there on the bookshelf next to
"Military Intelligence" and "Jumbo Shrimp" :)
Betov makes a good point that you don't really "learn" the entire
Windows API. You need to learn how to navigate the documentation and
*find* the API(s) you need. I suppose this gets easier with practice.
I've spent *no* time with Windows documentation, so the clock hasn't
even started ticking for me :)
...
> So what kind of programs do you write these days?
"Hello World" for Linux, mostly - not literally "Hello World", but
nothing too advanced. I suppose I'm "learning" the Linux API, a little
bit at a time.
...
> I have already got as far as "processing" an image
> using the QuickCam in dos and in a VC++ shell with
> a LogiTech webcam.
That should be a good start - at least you'll know what to do with the
camera.
> It is the fairly simple API
> stuff I have to get my head around.
There must be some kind of "Quick Start" document - "The Dozen Most
Frequently Used APIs", or "21 APIs in 21 Days", or something. If there
isn't, perhaps there should be. I *thought* that's more or less what
Iczelion's tuts did...
> The VC++ shell
> was written using the MFC Wizard by someone else
> not willing to show me how it was done.
That'd be "OOP", I guess - where "information hiding" is condidered a
*good* thing (!). Perhaps *not* a good place to start if you want to
learn to do it yourself...
> When I saw the FASM example I thought cool, I
> wonder how hard that would be?
Well, it doesn't look too bad. Can you get it to "work", as far as it goes?
I think I mentioned that I sponged a USB camera, so that I could "follow
along", maybe learn how to do it in Linux... When I went to plug it in,
I find I haven't *got* a USB port on this machine! (thought I did...) So
that's not going to be happening... unless I can figure out what
happened to the parallel-port camera I *used* to have... I still find
the project "interesting".
Best,
Frank
Frank Kotler
...
> I have never heard of any "Standard In" in any actual OS.
...
> I have never heard of any "Standard Out" in any actual OS.
... and Hutch thinks interrupts are a sex act...
I'm depressed!
Best,
Frank
Evenbit
Herbert Kleebauer wrote:
> > DOS is dead since ages.
>
> You don't need DOS6.2 or older, Windows XP will execute this
> program without any problem (or is XP also dead since ages?).
Actually, it depends on which build of XP. I believe I read where they
removed most of the DOS (backwards-compatibility) functionality from
the 64-bit version of XP. So your BAT files and COM proggies prolly
won't work on it.
Nathan.
JGCASEY
Frank Kotler wrote:
> [...]
>
> I've spent *no* time with Windows documentation,
> so the clock hasn't even started ticking for me :)
>
>
>
>
> "Hello World" for Linux, mostly - not literally
> "Hello World", but nothing too advanced. I suppose
> I'm "learning" the Linux API, a little bit at a time.
I gave some serious thought about using Linux.
For practical and time reasons I have decided so
far it will be more productive and practical to
stick to Windows/DOS. Better to do one thing well,
or at least as best I can, than two things badly.
Of course Java works on both machines.
> [...]
>
>
>> When I saw the FASM example I thought cool, I
>> wonder how hard that would be?
>
>
> Well, it doesn't look too bad. Can you get it to
> "work", as far as it goes?
Yes it works fine.
Scronty at the Win32Asm Community message board has
an example connecting three webcams.
There is also a DLL written in C but can apparently
be used by any other language to access a webcam.
http://robinhewitt.com/mavis/index.html
The demo also works on my computer but I don't know
how to actually access it via a DLL as I have only
used C and Assembler with DOS so far. There is the
option of using Java but I haven't got that far yet.
> I think I mentioned that I sponged a USB camera,
> so that I could "follow along", maybe learn how
> to do it in Linux... When I went to plug it in, I
> find I haven't *got* a USB port on this machine!
> (thought I did...) So that's not going to be
> happening... unless I can figure out what happened
> to the parallel-port camera I *used* to have...
> I still find the project "interesting".
If you can find the old ccd monochrome Connectix
QuickCam (taken over by LogiTech) you will find
that easy to interface to the parallel port.
My software however is for DOS not Linux.
Best,
John
Betov
@g44g2000cwa.googlegroups.com:
> Ok. Enough of the questions. Just one last thing
> about the pop up window tuts. I like a 'module'
> of information per page without scrolling. I find
> it easier to read if the whole screen of data is
> there for the viewing without having to scroll.
Not sure what you are talking about, here...
These Tutorial are, so to say, "3 shots":
1) You load the Tut from the Help Menu, and you see
the whole Tutorial materials' Source, in RosAsm
Source Editor, like any other Source.
2) Then you hit [F6], and the Tut is runing with two
windows: The Tutorial Dialog, and...
3) the grayed Edit, with the "final" Source of the
explained Parts, that you can execute from this
window's Menu. [These Tuts can "execute" two ways:
a) Run the Tutorial // b) Run the example].
If you are talking of the inconvenient of having to
scroll in the "Tutorial Dialog" (the one with the
four Buttons), to read the explanations, removing
this ScrollBar would imply having each separated
"explanation" fitting into one window size... What
would be rather... short... Not sure if this is
what you really mean...
Betov.
Betov
news:1125439703.0...@g43g2000cwa.googlegroups.com:
No joke, here, Troll. I am used to know of the Demos
i release at my own pages, mind you.
Betov.
Betov
@unibwm.de:
> Ok, I will repeat it in short and simple sentences:
>
> If you write a program (doesn't matter whether you write in
> assembler or a HLL), then there is a part which is OS independent
> (like a numerical calculation or the conversion of an assembler
> source line into the binary opcode) and a part which is OS
> dependent (display graphics, get keyboard and mouse input etc.).
>
> Now, the first part I would call (assembly or C) "programming"
> whereas the second part doesn't deserve the name "programming",
> it is nothing but a sequence of calls to the OS. The complete
> thing can be called programming if the first part is at least
> of the same magnitude as the second part. If you implement
> the below program in DOS, than this can be called programming
> because only a few lines of code are necessary to do the OS calls.
> But if you implement it as a Windows program (and believe me,
> there is a stdin and stdout in Windows) then part 2 gets much
> bigger than part 1, so the whole thing doesn't deserve the
> name "programming".
Sorry, but i am not yet completely senile:
1) You say that Win32 Asm is not Asm, because it calls
to Api Functions.
2) I ask you in what term Win32 C could be C, and why.
3) You answer BlaBla, without any head not tail.
If Win32 C is C, there is no reason why Win32 Asm could
not be Asm. Period. Your conception of Asm is deprived
of any kind of interrest in the very discussion. You
are a man of logic. A man of _excessive_ logic, i would
say. Well OK to me, but, at least, don't twist the logic
in the Randall Hyde manner when the arguments do no more
please your _taste_.
>> > If
>> > you only need a few dozen lines of assembler code for the
>> > core program, then most of the source file is win32 overhead.
>> > But if a real application, written in a HLL, has many thousands
>> > of lines, then the win32 stuff maybe is acceptable.
>>
>> ???!!!... RosAsm Source, that is 3 Megas long calls
>> for about one hundread of Api Functions.
>
> RosAsm is written in assembler because it's author isn't
> able to recognize the advantage of HLLs for implementing
> larger applications.
Larger than 3 Megas of Asm Code...
:)))))))
>> ... And then???!!!...
>> DOS is dead since ages.
>
> You don't need DOS6.2 or older, Windows XP will execute this
> program without any problem (or is XP also dead since ages?).
Not here. I wrote tons of DOS Applications, and i can
tell you that very few of them still work. Now, you can
answer that i wrote them the wrong way, if you like.
>> > When ever possible, I also use only standard IO in C programs, so
>> > the program is OS independent and can be compiled with any C
compiler
>> > on any system (why do you think does an assembler need a GUI?).
>>
>> Feel free to believe in things that do not exist, if you
>> like, but, to me, believing in something that does not exist
>> is a mental disease.
>
> About which "things that do not exist" are you speaking here?
All of the C mythology:
* Portability: Yes, it exists,.. if you do nothing.
* Modularity: Yes, you can reuse Code if you want bloat.
* Standard thingies: Unfortunately there is no such a
thing in any modern OS. [and don't joke me with the
Console Functions].
>> I have payed to know that PEs are more complicated than
>> .com, but i fail to see why this would make them "awful".
>> "More complex" is not "awfull".
>
> I'm not speaking about the structure of a PE file compared
> to a com file,
_YES_, you were talking about you loading a PE in an
Hexa Editor. Read your own above post. :(
> but about the Win32 API compared to the
> int21 interface.
This one is 100% _normal_. If you want a Mousy Menu,
under DOS, you have, say, at least 10 or twenty
Pages of Source to write. With Win32, it is _WAY_
easier.
So, the fact that Functions offering thousands and
thousands of way more advanced functionalities, be
more sophisticated than a primitive dead OS is nothing
surprising, and the fact that you refuse sternely to
follow-up, has nothing to do in the story.
>> > Assembly programming is programming the
>> > CPU (which is completely independent of the used OS) and not
>> > learning an awful OS API.
>>
>> Try to teach DOS without calling for any Int.
>
> One page is sufficient to explain anything necessary to
> start assembly programming in DOS (fopen, fclose, getc, putc,
> test and read keyboard, get mouse position, switch to graphics
> mode). Try the same with the Win32 API.
Ridicoulous claim, with no base. One line is enough, in
Win32 Asm to output a complex thing like a MessageBox.
Try to do:
call 'USER32.MessageBoxA' &NULL,
{'How are you?', 0},
{'Message', 0},
&MB_OK
... in Dos. And be prepared for around 40 Pages of very
complex Source.
Betov.
Betov
h...@comcast.com:
Don't play the Troll with me, Frank, we have much enough
Trolls around.
Betov.
Alex McDonald
The lack of understanding shown by both Hutch on how an OS works and
his stubborn insistence on ignoring the facts, and now Betov in loudly
pronouncing that he's never heard of stdin, stdout etc is symptomatic
of people who really don't write code except for themselves and a
limited audience, with limited goals.
The remarkable statements of "fact" made by them, and others like The
Sage, amaze and outrage people whose job it is to write apps, study and
work with OS (Windows, Linux, HP/UX or whatever), deliver large scale
projects engineered for RAS -- reliability, availability, scalability.
That's me, amongst others. Their lack of fundamental understanding is
not a problem; experience and some research can fix that. But when
delivered as "This is how it works!" with no research, facts that
demonstrate the opposite, and a willingness to state, loudly and with
repetition, "Follow me, for I can teach you a thing or two. What do
these academics and professionals know with their blah-blah PDFs and
experiments? Nothing! Look, my uncommented spaghetti code using the
wrong technique works! Most of the time..."
As Betov might say; "Well...."
I'm also a hobby programmer, but I bring the same engineering skills I
have in my day job to this too. I'm not as rigourous perhaps; change
control is something I'm not too hot on in my hobby coding, for
instance. But I know one end of an OS from another, have worked on the
internals of one, supported code on several others, been a programmer
for a sizable chunk of my life, written several sizable assembler apps,
studied performance of OS and apps under a variety of conditions, and
know the value of stdin/out/err.
I know these thing well because I've been there, done them, got the
t-shirts and the scars too. Reading some of the recent posts from the
clueless _is_ depressing. They don't even have the insight to realise
how foolish they sound.
--
Regards
Alex McDonald
Betov
news:1125485155.5...@z14g2000cwz.googlegroups.com:
> But I know one end of an OS from another, have worked on the
> internals of one, supported code on several others, been a programmer
> for a sizable chunk of my life, written several sizable assembler apps,
> studied performance of OS and apps under a variety of conditions, and
> know the value of stdin/out/err
You can simulate understanding that i am talking about
the Console Functions, if you find this funny, Troll,
but, as for you having "written several sizable assembler
apps"...
... Which i can see... where, Troll?
Betov.
JGCASEY
I clicked the IVTOOOBeginner rose icon.
I think the scroll text box should be large so
you don't have to scroll it. You can still use
the buttons for each description topic.
No big deal. Just I like to put things in bite
sizes of information that can be viewed all at
once. Like a function. If it doesn't fit on a
page it is too long. Break it into smaller bits.
Forget I mentioned it :) Like you wrote earlier,
less questions, just spend some time actually
reading/using it.
John.
Alex McDonald
> "Alex McDonald" <alex...@btopenworld.com> écrivait
> news:1125485155.5...@z14g2000cwz.googlegroups.com:
>
> > But I know one end of an OS from another, have worked on the
> > internals of one, supported code on several others, been a programmer
> > for a sizable chunk of my life, written several sizable assembler apps,
> > studied performance of OS and apps under a variety of conditions, and
> > know the value of stdin/out/err
>
>
> You can simulate understanding that i am talking about
> the Console Functions, if you find this funny, Troll,
Did someone else have control of your keyboard? I though you wrote
-- I have never heard of any "Standard In" in any actual OS.
This demonstrates to me (and Frank) your incredible narrowness of
understanding. You could only make that statement if you (a) didn't
know the Window's API well (b) had only experienced interacting with
Windows through a GUI (c) don't understand why it might be useful (d)
had never seen, much less used, a *nix OS.
I remeber you once said you were a mainframe programmer in the 60s
(language & OS undisclosed). Have you forgotten SYSIN and SYSOUT?
> but, as for you having "written several sizable assembler
> apps"...
>
> ... Which i can see... where, Troll?
Next time you put your plastic card in a cash machine, for one. We've
been though this before; not everyone writes code for themselves and
whacks it up on the internet under some OSS licence. The majority of
assembler programmers that I've worked with were, like me, paid for
their labour; my code and their code (all IBM BAL) doesn't belong to
us. Take it or leave it.
For me, you pointing to your 3 megas of code (which you'll no doubt do)
doesn't float my boat. It's not a sizable app, it's a monolithic
monster.
--
Regards
Alex McDonald
Betov
news:1125487675.9...@o13g2000cwo.googlegroups.com:
>> but, as for you having "written several sizable assembler
>> apps"...
>>
>> ... Which i can see... where, Troll?
>
> Next time you put your plastic card in a cash machine, for one. We've
> been though this before; not everyone writes code for themselves and
> whacks it up on the internet under some OSS licence. The majority of
> assembler programmers that I've worked with were, like me, paid for
> their labour; my code and their code (all IBM BAL) doesn't belong to
> us. Take it or leave it.
I leave it very easily, Troll, when facing unsignificant
guys, able to write:
> I'm also a hobby programmer,
> ...
> written several sizable assembler apps
... and who have nothing to show, in a News Group, but their
chest bombing. If you never did anything real, shut up, and
do not come and play with me. Period.
Mind you, the real Asmers, having done something real, are
_ALL_ hobbyist, and they have _ALL_ something to show. I
well know that words like "Book", "Professional", "Teacher",
and so on.. seem to have some magic power, around here, and
could eventualy impress some idiots. But do not hope it could
ever work with me.
The "Professional" area is well known, for being a particular
area, where the reality has no access, and where ass-holes
wearing, talking and behaving, in a social-conformed manner
are the kings. We also have all payed to know where this may
go to, all along the SoftWare history.
Betov.
Alex McDonald
>
> I leave it very easily, Troll, when facing unsignificant
> guys, able to write:
>
> > I'm also a hobby programmer,
> > ...
> > written several sizable assembler apps
I wrote that, but not in that order. Here's what happens when someone
rearranges your posts;
> Mind you, the real Asmers, having done something real, are _ALL_ hobbyist,
> ... and could eventualy impress some idiots.
> Betov
Regards
Alex McDonald
f0dder
It's not that they removed DOS functionality - the 64bit processors
simply don't support 16bit legacy apps when working in "long mode",
so Microsoft would have to include a full CPU emulator in XP64 to
enable you to run 16bit apps...
Herbert Kleebauer
> Herbert Kleebauer <kl...@unibwm.de> écrivait news:4314E886.9D85E836
I think you are only joking, but as long as there are no smilies,
I will take you seriously and will not let you escape so easily.
> Sorry, but i am not yet completely senile:
Did you read a single sentence of what I wrote?
> 1) You say that Win32 Asm is not Asm, because it calls
> to Api Functions.
No, I said that I don't call it assembly "programming"
if you write an assembler source file where most of the code
fills in some data structures for OS calls or do the OS calls
whereas only a few lines are there which does the actual
computing. Please show us for example the Win32 source code
for the described filter program so we can compare it with
a 16 bit DOS solution. Then you will see what I mean.
> 2) I ask you in what term Win32 C could be C, and why.
And I already twice gave you the answer.
> 3) You answer BlaBla, without any head not tail.
>
> If Win32 C is C, there is no reason why Win32 Asm could
> not be Asm. Period.
Sure, if you not only write trivial programs. But show me
the applications written in assembler. And for all this
simple programs which are written to experiment with the
instruction set of the CPU (= learning assembly programming),
the overhead for Windows programming is much larger than
for DOS programming.
> Well OK to me, but, at least, don't twist the logic
> in the Randall Hyde manner when the arguments do no more
> please your _taste_.
Where exactly did I "twist the logic".
> > RosAsm is written in assembler because it's author isn't
> > able to recognize the advantage of HLLs for implementing
> > larger applications.
>
> Larger than 3 Megas of Asm Code...
No, larger than 3 kbyte.
> >> DOS is dead since ages.
> >
> > You don't need DOS6.2 or older, Windows XP will execute this
> > program without any problem (or is XP also dead since ages?).
>
> Not here. I wrote tons of DOS Applications, and i can
> tell you that very few of them still work. Now, you can
> answer that i wrote them the wrong way, if you like.
Can you please give us a link to such programs (or post them
here). I really would like to see, why they can't be executed
in XP.
> >> Feel free to believe in things that do not exist, if you
> >> like, but, to me, believing in something that does not exist
> >> is a mental disease.
> >
> > About which "things that do not exist" are you speaking here?
>
> All of the C mythology:
>
> * Portability: Yes, it exists,.. if you do nothing.
My 486 assembler should compile on any system with an C
compiler (I even wrote it on an ATARI ST). Eight years
ago I wrote a program to generate pdf files (I always
want to know what's in a file I use, not only PE exe
files but also data files like pdf). I compiled it
without any modification in DOS (Windows), Linux, and SUN OS.
> * Modularity: Yes, you can reuse Code if you want bloat.
????? Please give more details.
> * Standard thingies: Unfortunately there is no such a
> thing in any modern OS. [and don't joke me with the
> Console Functions].
????? Please give more details.
>
> >> I have payed to know that PEs are more complicated than
> >> .com, but i fail to see why this would make them "awful".
> >> "More complex" is not "awfull".
> >
> > I'm not speaking about the structure of a PE file compared
> > to a com file,
>
> _YES_, you were talking about you loading a PE in an
> Hexa Editor. Read your own above post. :(
I made a hex dump and disassembled a PE file to understand
how to generate my own Win32 executables. I never said, this
was awful. I even suggested to others to do it the same way
instead of reading the tutorials of the assembly pioneers.
Read my posts.
> > but about the Win32 API compared to the
> > int21 interface.
>
> This one is 100% _normal_.
>
> So, the fact that Functions offering thousands and
> thousands of way more advanced functionalities, be
> more sophisticated than a primitive dead OS is nothing
> surprising,
Now you only have to explain, why this "thousands of way
more advanced functionalities" are necessary for learning
assembly programming?
> >> > Assembly programming is programming the
> >> > CPU (which is completely independent of the used OS) and not
> >> > learning an awful OS API.
> >>
> >> Try to teach DOS without calling for any Int.
> >
> > One page is sufficient to explain anything necessary to
> > start assembly programming in DOS (fopen, fclose, getc, putc,
> > test and read keyboard, get mouse position, switch to graphics
> > mode). Try the same with the Win32 API.
>
> Ridicoulous claim, with no base. One line is enough, in
> Win32 Asm to output a complex thing like a MessageBox.
I said: "anything necessary to start assembly programming in DOS"
To be able to display a message box on the screen surely isn't
sufficient for learning assembly programming.
> Try to do:
>
> call 'USER32.MessageBoxA' &NULL,
> {'How are you?', 0},
> {'Message', 0},
> &MB_OK
>
> ... in Dos. And be prepared for around 40 Pages of very
> complex Source.
Now you are really joking ?!? The DOS version is:
move eax,pointer_to_text
call MessageBox
There is absolutely no difference for Win32 or DOS. All you
have to do is, to push the parameters onto the stack or store
them into registers and then call the subroutine. Your
"USER32.MessageBoxA" is nothing but a subroutine within the
address space of your program and executed in user mode
(and isn't an OS call at all). Now you can argue, that
you don't had to write the function, Microsoft has done
this for you. But maybe I also hadn't to write the DOS
MessageBox function, a friend could have done this for me.
You are arguing exactly like Randy: all you need is
a powerful library, then assembly programing is trivial.
If any function you ever need, is already written and
available in a library, then learning assembly programming
can be reduced to just learn the call instruction. The
only difference is, that Randy has written his HLA library
himself, whereas you have paid Microsoft to write kernel32.dll,
user32.dll, etc. for you.
I must admit, that I only know very few Win32 functions,
but as far as I know, MessageBox is the only graphical
output which doesn't require a RegisterClass, so your
example isn't typical.
Let's make a simple graphics program: Draw a red, blue and
green square on the screen with a black background. If the
mouse pointer is moved within one of this squares, the
background should change to the color of this square. Show
us the Win32 assembler program and I will write the DOS
version. Then we can compare both programs and decide
which looks more like an assembler program and which has less
OS overhead.
Evenbit
What exactly does "16bit legacy app" mean? Does this mean that any
piece of code that contains a "MOV AX, 123" will cause the machine to
emit a puff of smoke? If so, then it really isn't an x86 CPU then, is
it?
Nathan.
JGCASEY
Betov wrote:
>> Try to do:
>
>> call 'USER32.MessageBoxA' &NULL,
>> {'How are you?', 0},
>> {'Message', 0},
>> &MB_OK
>
>
>> ... in Dos. And be prepared for around 40 Pages of very
>> complex Source.
>
>
Herbert Kleebauer wrote:
> Now you are really joking ?!? The DOS version is:
>
> move eax,pointer_to_text
> call MessageBox
There is a little bit more functionality in the
Window's MessageBox. You would need a structure
to hold its properties. Maybe push the details
onto the stack, or copy vales into the structure
and than call MessageBox.
create structure then,
mov eax,pointer_to_MessageBoxStruct
call MessageBox
> There is absolutely no difference for Win32 or DOS.
There is of course a major difference in functionality
in the sense that Win32 is a multitasking environment.
> All you have to do is, to push the parameters onto
> the stack or store them into registers and then
> call the subroutine. Your "USER32.MessageBoxA" is
> nothing but a subroutine within the address space
> of your program and executed in user mode (and
> isn't an OS call at all). Now you can argue, that
> you don't had to write the function, Microsoft has
> done this for you. But maybe I also hadn't to write
> the DOS MessageBox function, a friend could have
> done this for me.
Exactly. And a program full of invokes is almost HLL.
> You are arguing exactly like Randy: all you need
> is a powerful library, then assembly programming is
> trivial. If any function you ever need, is already
> written and available in a library, then learning
> assembly programming can be reduced to just learn
> the call instruction.
Agreed. HLL.
> The only difference is, that Randy has written his
> HLA library himself, whereas you have paid Microsoft
> to write kernel32.dll, user32.dll, etc. for you.
>
>
> I must admit, that I only know very few Win32
> functions, but as far as I know, MessageBox is
> the only graphical output which doesn't require
> a RegisterClass, so your example isn't typical.
>
>
> Let's make a simple graphics program: Draw a red,
> blue and green square on the screen with a black
> background. If the mouse pointer is moved within
> one of this squares, the background should change
> to the color of this square. Show us the Win32
> assembler program and I will write the DOS
> version. Then we can compare both programs and
> decide which looks more like an assembler program
> and which has less OS overhead.
Easy in DOS :) What screen mode do you want?
Is it to also include a rectangular window
in which the squares reside? One we can move
around and resize perhaps?
Some things can be done with DOS and developed with
DOS because their functionality is not dependent
on a multitasking OS.
Windows is made much easier in the sense someone
has written lots of neat APIs to do much of the
standard stuff programmers use and of course
provide a standard environment to share code and
provide a standard user interface.
A HLL is really a means to call and pass parameters
to a library of useful functions. They are programs
written by writing a list of subroutines to call
or maybe macros to insert. Some to set up control
structures and so on...
John.
f0dder
> What exactly does "16bit legacy app" mean? Does this mean that any
> piece of code that contains a "MOV AX, 123" will cause the machine to
> emit a puff of smoke? If so, then it really isn't an x86 CPU then, is
> it?
16bit legacy app would be an application running in realmode (and 16bit
protected mode as well, I suppose). At least v86 isn't supported while
the processor is in "long mode".
32bit applications will continue to run, and "MOV AX, 123" is a valid
32bit instruction, with a 66h prefix.
Somebody with a better knowledge of "long mode" should kick in, though,
my knowledge is currently pretty brief :)
Betov
@g43g2000cwa.googlegroups.com:
> A HLL is really a means to call and pass parameters
> to a library of useful functions. They are programs
> written by writing a list of subroutines to call
> or maybe macros to insert. Some to set up control
> structures and so on...
Evident. The OS calls are the OS calls, and there is nothing
(or very poor things...) we can change to this.
But, would you OS call be a DOS Int or a Win32 Api, the only
thing that matters, for an Assembly Programmer, is that it
is "Black Box" calls, and there is no difference, at this
point of view, but one:
The DOS Ints are way primitive than the Win32 Api, and do
way less.
This does not change an inch to the fact that Assembly
programming is Assembly Programming, under whatever OS,
as long as only a very high percentage of the Source are
_NOT_ OS calls, neither in DOS nor in Win32 Programming.
Betov.
Betov
@unibwm.de:
> Did you read a single sentence of what I wrote?
Yes.
>> 1) You say that Win32 Asm is not Asm, because it calls
>> to Api Functions.
>
> No, I said that I don't call it assembly "programming"
This is your problem: What you "call assembly programming"
is _your_ vision of Asm Programming, and your opinion, on
this point has no interrest, at all, as it is irrational,
> if you write an assembler source file where most of the code
> fills in some data structures for OS calls or do the OS calls
This does not exist in real Life Applications. I suppose
that you base your comment on the Win32 Asm Demos, that,
exactely, are about how to call for the Api.
In real life Applications witten in Assembly, the percentage
of Api calls is low.
> whereas only a few lines are there which does the actual
> computing.
Read RosAsm Source, and go and search for the Api calls...
Tip: There is a Menu Option for showing them to you, with
counts, jumps to the instance, and all...
> Now you only have to explain, why this "thousands of way
> more advanced functionalities" are necessary for learning
> assembly programming?
I rarely talk about "learning assembly programming".
Assembly is not a language for learning Assembly, mind you.
>> Ridicoulous claim, with no base. One line is enough, in
>> Win32 Asm to output a complex thing like a MessageBox.
>
> I said: "anything necessary to start assembly programming in DOS"
> To be able to display a message box on the screen surely isn't
> sufficient for learning assembly programming.
There is no reason for learning Assembly with a dead OS,
whereas it is way easier to learn with the actual one.
>> Try to do:
>>
>> call 'USER32.MessageBoxA' &NULL,
>> {'How are you?', 0},
>> {'Message', 0},
>> &MB_OK
>>
>> ... in Dos. And be prepared for around 40 Pages of very
>> complex Source.
>
>
> Now you are really joking ?!? The DOS version is:
>
> move eax,pointer_to_text
> call MessageBox
In case you did not notice, the most trivial and simpliest
Api function implies having a complete Mouse and KeyBoard
Management, default processing, priorities in Multi-Task,
Graphism, and so on.
Mind you, when i was writting my DOS-times Applications,
i was used to have them working in Graphical Mode, with
Mouse, Menus, and all... So, i have payed to know something
about the simple overhead of having a decent Mouse Manager,
in a DOS App.
Betov.
rand...@earthlink.net
Herbert Kleebauer wrote:
> Betov wrote:
> > Herbert Kleebauer <kl...@unibwm.de> écrivait news:4314E886.9D85E836
>
> I think you are only joking, but as long as there are no smilies,
> I will take you seriously and will not let you escape so easily.
>
>
> > Sorry, but i am not yet completely senile:
>
> Did you read a single sentence of what I wrote?
Often, he does not. Have you noticed this too?
> > * Modularity: Yes, you can reuse Code if you want bloat.
>
> ????? Please give more details.
What he is saying is that RosAsm doesn't support this kind of
modularity, so he has to make it sound negative to define his own turf.
>
>
> > * Standard thingies: Unfortunately there is no such a
> > thing in any modern OS. [and don't joke me with the
> > Console Functions].
>
> ????? Please give more details.
Rene has never figured out how to use standard I/O under Windows.
> Now you are really joking ?!? The DOS version is:
>
> move eax,pointer_to_text
> call MessageBox
>
> There is absolutely no difference for Win32 or DOS. All you
> have to do is, to push the parameters onto the stack or store
> them into registers and then call the subroutine. Your
> "USER32.MessageBoxA" is nothing but a subroutine within the
> address space of your program and executed in user mode
> (and isn't an OS call at all). Now you can argue, that
> you don't had to write the function, Microsoft has done
> this for you. But maybe I also hadn't to write the DOS
> MessageBox function, a friend could have done this for me.
Such as the UCR Standard Library for 80x86 programmers.
>
> You are arguing exactly like Randy: all you need is
> a powerful library, then assembly programing is trivial.
Yeah, such as the UCR Standard Library for 80x86 assembly language
programmers (it's written for DOS, btw).
>
> I must admit, that I only know very few Win32 functions,
> but as far as I know, MessageBox is the only graphical
> output which doesn't require a RegisterClass, so your
> example isn't typical.
Nothing, however, requires you to write code for a GUI. Win32 supports
the creation of console apps. They are simple and easy to use
(especially when backed up by a few library routines, such as those in
the HLA Standard Library). You can concentrate on learning assembly
with these guys, rather than trying to figure out how to write GUI apps
under Win32 (which is a completely different process altogether).
Cheers,
Randy Hyde
rand...@earthlink.net
Betov wrote:
> Herbert Kleebauer <kl...@unibwm.de> écrivait news:4316005D.167ECC72
> @unibwm.de:
>
> > Did you read a single sentence of what I wrote?
>
> Yes.
>
>
> >> 1) You say that Win32 Asm is not Asm, because it calls
> >> to Api Functions.
> >
> > No, I said that I don't call it assembly "programming"
>
> This is your problem: What you "call assembly programming"
> is _your_ vision of Asm Programming, and your opinion, on
> this point has no interrest, at all, as it is irrational,
HaHaHaHaHa!
This is the *funniest* thing I have read in a long time. Talk about the
pot calling the kettle black!
It's okay for *Rene* to insist that people believe in *his* vision of
what assembly language ought to be like, but other people's visions are
of no interest. Too bad Rene hasn't figured out that almost no one
shows the slightest interest in his own vision.
>
>
> I rarely talk about "learning assembly programming".
Unless, of course, you're busy trashing someone who develops
pedagogical material to help people learn assembly language (witness
the response to this post you're about to write :-) ).
>
> Assembly is not a language for learning Assembly, mind you.
????
I suppose you'd rather they learned assembly using C?
Cheers,
Randy Hyde
Betov
news:1125586273.8...@g14g2000cwa.googlegroups.com:
> Too bad Rene hasn't figured out that almost no one
> shows the slightest interest in his own vision.
Ass-hole, at least, Herbert and me have one, whereas
you never had any.
:)
Betov.
anonymous
fire fighters (?) in the bushfight ;)
I shall come with these statements:
first of all to my understanding portability is merely illusion!
second, show me the Win32 C program that isn't Win32Asm!
third, Assembly is universal, it doesn't change from OS to OS (only from
hardware to hardware)!
Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!
Fifth, programming resides in taking advantage of the functions one has in
order to do useful things!
1. Portability is illution, because portability is based on library calls,
with different libraries for different OSes.
2. If the programmer creates a program in Win32 C (which is also in
Win32Asm) and that can be referred to as "programming" then why can win32Asm
programmer not write the same program and that be called "programming" as
well?
3. The true assembly are the same regardless of os, only address and method
varies when addressing OS calls.
4. StdIn/etc. are just numbers/ constants from 0 through 2. The calls to use
them are different in every OS. In C however this is hidden under standard
library calls.
5. This means using or not using OS calls or library calls is equivalently
programming, the assembly mnemonics are merely the programming library of
the processor.
Now for a bit about myself, I'm a beginner, the biggest program I ever
finished is probably not more than 2kB. I found it is extremely easy
learning assembly language (!) however, the syntax of assemblers was
semi-hard to learn, and learning how to output stuff was hard.
The syntax was semi-hard to learn because everyone uses a different syntax,
and most available source code available (at least at that time) is/was
16bit which has many variables in syntax.
Learning how to output stuff was hard because most assembly tutorials deal
merely with the language and not with OS calls, besides understanding the
Win32.hlp can be a pain in the *** for a beginner, because one tries to
comprehend it instead of just "porting and pasting" the thing, and filling
in the holes. Besides all the constants replaced with names were really
difficult for me to absorb because the Win32.hlp doesn't display the
numerical equivalent.
I never properly understood programs until I learned assembly for my
calculator.
In my oppinion tutorials should never use predefined constants or predefined
macros in the first couple of tutorials and then if they wish to use them,
the tutorial should describe and explain them, so the reader is included in
the making of these predefined things. How would a beginner ever understand
something predefined, when "pre" is "pre" as in before the first
tutorial/lesson?
anonymous
tutorial/lesson? ;-)
Smileys to all!!!
let's reinvent the happy face!!
Greetz, :-D
Jakob Wrigley
JGCASEY
anonymous wrote:
[...]
> In my opinion tutorials should never
> use predefined constants or predefined
> macros in the first couple of tutorials
> and then if they wish to use them, the
> tutorial should describe and explain
> them, so the reader is included in the
> making of these predefined things. How
> would a beginner ever understand some
> thing predefined, when "pre" is "pre"
> as in before the first tutorial/lesson?
I agree. Don't use unexplained things in
a beginners tutorial.
Alex McDonald
> Hi all, been watching the last couple of days, decided to join in with the
> fire fighters (?) in the bushfight ;)
>
> I shall come with these statements:
> first of all to my understanding portability is merely illusion!
> second, show me the Win32 C program that isn't Win32Asm!
> third, Assembly is universal, it doesn't change from OS to OS (only from
> hardware to hardware)!
> Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!
> Fifth, programming resides in taking advantage of the functions one has in
> order to do useful things!
>
>
> 1. Portability is illution, because portability is based on library calls,
> with different libraries for different OSes.
The best illusions are those that make you believe that they're not
illusions. Like portability; it's an illusion that works.
> 2. If the programmer creates a program in Win32 C (which is also in
> Win32Asm) and that can be referred to as "programming" then why can win32Asm
> programmer not write the same program and that be called "programming" as
> well?
I think you're confused here. Who said otherwise?
> 3. The true assembly are the same regardless of os, only address and method
> varies when addressing OS calls.
Again, I think you'll find it very different from OS to OS. Solaris on
x86 is different from Linux is different from MINIX is different from
Windows.
> 4. StdIn/etc. are just numbers/ constants from 0 through 2. The calls to use
> them are different in every OS. In C however this is hidden under standard
> library calls.
Funny, on my copy of WinXP, GetStdHandle calls for STD_ERROR_HANDLE
STD_INPUT_HANDLE and STD_OUTPUT_HANDLE return 11, 7 and 3.
> 5. This means using or not using OS calls or library calls is equivalently
> programming, the assembly mnemonics are merely the programming library of
> the processor.
Unclear what you mean here.
>
> Now for a bit about myself, I'm a beginner,
You're best doing a bit more study and research; stating as fact
something that's demonstrably untrue, as with handles, isn't very
productive.
--
Regards
Alex McDonald
Betov
$24...@news.arrownet.dk:
> In my oppinion tutorials should never use predefined constants
If you are talking about Win32Asm, making use of
the Win32 is a real advantage. Depends, of course
on what Assembler you use, but FASM comes with its
Files to include, and RosAsm comes with more than
62,000 integrated Equates, that you do not even have
to care of.
Using the Numbers would be a real pain...
Betov.
rand...@earthlink.net
anonymous wrote:
>
> In my oppinion tutorials should never use predefined constants or predefined
> macros in the first couple of tutorials and then if they wish to use them,
> the tutorial should describe and explain them, so the reader is included in
> the making of these predefined things. How would a beginner ever understand
> something predefined, when "pre" is "pre" as in before the first
> tutorial/lesson?
It depends on the "pre" as in "prerequisites". Every tutorial has to
assume a certain amount of prerequisite knowledge on the part of the
reader. For example, the Izcelion tutorials, for beginning Win32 API
programmers working in assembly language assumes that you're already
familiar with MASM, etc.
Some "beginning assembly language tutorials" (e.g., Art of Assembly)
assume that you're proficient in a high-level language before starting
the lesson plan.
Those books and schemes that *do* start at ground zero, often fail to
progress very far. But if you want a good example of a book that does a
reasonable job, take a look at Jeff Duntemann's "Assembly
Step-By-Step". It's intended for people with *no* programming
experience whatsoever; although most people who read the book have some
programming experience, they like the fact that it makes no assumptions
about prerequisite material, so even though they wind up reviewing a
lot of material, they don't miss anything either. Sounds like just the
ticket for you.
Cheers,
Randy Hyde
wolfgang kern
Rene against Herbert ???
I can't believe in.
This two worlds of ASM may have got more in common than being apart.
The difference is the used/preferred syntax, but the common things
I'd see are how to avoid all the useless detours from 'great books'.
__
wolfgang
wolfgang kern
f0dder answered Evenbit:
I support it with my disassembler to be aware of what's available),
long modes:
either the true 64-bit-bit mode (that's the one which
let you access extended registers and RIP addressingh),
or the other long mode (which got extented paging and
allow almost all well known 32-bit stuff).
But we all should read the AMD64/EMT64 manuals one more time,
there are restrictions in both, adressing modes and operand sizes
while running in 64-bit mode.
16/32-bit operands ???, 16/32-bit adressing ???
Please check my Hextutor (google), and tell me where it may be wrong.
__
wolfgang
wolfgang kern
"anonymous" <wri...@tuknet.dk> wrote:
| Hi all, been watching the last couple of days, decided to join in with the
| fire fighters (?) in the bushfight ;)
Welcome to the arena,
select count and type of desired enemies yet. :)
| I shall come with these statements:
| first of all to my understanding portability is merely illusion!
| second, show me the Win32 C program that isn't Win32Asm!
| third, Assembly is universal, it doesn't change from OS to OS (only from
| hardware to hardware)!
| Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!
| Fifth, programming resides in taking advantage of the functions one has in
| order to do useful things!
You cannot fight against me with this, because I agree.
| 1. Portability is illution, because portability is based on library calls,
| with different libraries for different OSes.
You cannot fight against me with this, because I agree.
| 2. If the programmer creates a program in Win32 C (which is also in
| Win32Asm) and that can be referred to as "programming" then why can
| win32Asm programmer not write the same program and that be called
| "programming" as well?
debug the resulting code and watch the difference...
granted not too many ASM-coders will beat a C-compiler's output,
but a few can beat it by more than 50% in size 'and' speed anytime.
| 3. The true assembly are the same regardless of os,
| only address and method varies when addressing OS calls.
this depends what the OS offers,...
| 4. StdIn/etc. are just numbers/ constants from 0 through
| 2. The calls to use them are different in every OS.
| In C however this is hidden under standard library calls.
Yes, But I never heard of or would allow any standard library for my OS.
| 5. This means using or not using OS calls or library calls is equivalently
| programming, the assembly mnemonics are merely the programming library of
| the processor.
Libraries are OS dependent, prepared for an expected standard which
accomadates the rules in the great books, and/but nothing else.
| Now for a bit about myself, I'm a beginner, the biggest program I ever
| finished is probably not more than 2kB. I found it is extremely easy
| learning assembly language (!) however, the syntax of assemblers was
| semi-hard to learn, and learning how to output stuff was hard.
|
| The syntax was semi-hard to learn because everyone uses a different syntax,
The syntax you chose is what you like.
| and most available source code available (at least at that time) is/was
| 16bit which has many variables in syntax.
|
| Learning how to output stuff was hard because most assembly tutorials deal
| merely with the language and not with OS calls, besides understanding the
| Win32.hlp can be a pain in the *** for a beginner, because one tries to
| comprehend it instead of just "porting and pasting" the thing, and filling
| in the holes. Besides all the constants replaced with names were really
| difficult for me to absorb because the Win32.hlp doesn't display the
| numerical equivalent.
| I never properly understood programs until I learned assembly for my
| calculator.
| In my oppinion tutorials should never use predefined constants or
| predefined
| macros in the first couple of tutorials and then if they wish to use them,
| the tutorial should describe and explain them, so the reader is included in |
the making of these predefined things. How would a beginner ever understand |
something predefined, when "pre" is "pre" as in before the first
| tutorial/lesson?
Fully agree,
and I think you already got beyond the 'pre' :)
And if still some anwers missing:
just ask away ... and avoid falling into the traps of book-sellers spam.
__
wolfgang
Betov
@newsreader1.utanet.at:
Oh, this is old news, Wolfgang. Herbert and me have always
had a completely different view on the _usage_ of Assembly.
Nevertheless, you will never see me flaming Herbert, even
if the discussion may go hard, because i have some respect
for Herbert. We simply disagrea. Nothing else. Nothing more.
:)
Betov.
anonymous
"Alex McDonald" <alex...@btopenworld.com> skrev i en meddelelse
news:1125608344.8...@g49g2000cwa.googlegroups.com...
> anonymous wrote:
>> 3. The true assembly are the same regardless of os, only address and
>> method
>> varies when addressing OS calls.
>
> Again, I think you'll find it very different from OS to OS. Solaris on
> x86 is different from Linux is different from MINIX is different from
> Windows.
Coding in assembly in Linux or Windows (or any other OS) on a x86 machine
will be exactly the same "call" is still "call", "push" is still "push",
"mov" is still "move", etc. What changes when you change OS is the
environment, meaning how you interface the operating system (which call's or
int's will have surtain functions) and how you interface the operating
system to again interface the hardware.
Therefore Assembly instructions don't change. The only time when assembly
changes is when you the hardware, when foreinstance you replace your pentium
IV chip with a z80 or motorola chip.
>> 4. StdIn/etc. are just numbers/ constants from 0 through 2. The calls to
>> use
>> them are different in every OS. In C however this is hidden under
>> standard
>> library calls.
>
> Funny, on my copy of WinXP, GetStdHandle calls for STD_ERROR_HANDLE
> STD_INPUT_HANDLE and STD_OUTPUT_HANDLE return 11, 7 and 3.
This was supposed to be read as an explanation to the fourth statement:
"Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!"
STD_INPUT_HANDLE, etc. are indeed constants, I was not referring to the
handle
you receive from GetStdHandle, but the constant you supply it.
But actually the constants StdIn/etc. are not always from 0 through 2, as
you state.
I didn't bother to check their actual values, merely assumed they were the
same as in linux, but apparently not.
they have values from 0F4h through 0F6h.
>> 5. This means using or not using OS calls or library calls is
>> equivalently
>> programming, the assembly mnemonics are merely the programming library of
>> the processor.
>
> Unclear what you mean here.
Again this was supposed to be read as explanation of statement five:
"Fifth, programming resides in taking advantage of the functions one has in
order to do useful things!"
The last part: "the assembly mnemonics [...] processor." was merely to state
that no matter
how lowlevel you get you will always be using a library of some sort.
>> Now for a bit about myself, I'm a beginner,
>
> You're best doing a bit more study and research; stating as fact
> something that's demonstrably untrue, as with handles, isn't very
> productive.
They were merely statements, though I believe them all to be true, they
could be true or false. :)
It _has_ been productive :), people have commented on my views, agreing and
disagreing as they saw fit.
anonymous
"Betov" <be...@free.fr> skrev i en meddelelse
news:XnF96C4EDB3FF...@212.27.42.74...
concept of assembly language, it is (has been for me anyhow) a great help to
know the numbers and the fact that they are numbers, because otherwise the
concept becomes to abstract to comprehend.
I think tutorials should teach how to define constants and how to use them,
they could than mention the great work that has already been done including
the constants of the Win32.hlp in assemblers and include files.
On this topic I think your RosAsm assembler is infact a great tool, and it
has helped me loads with understanding, because a simple rightclick on a
predefined constant will display the number it represents.
greetz :-D
Jakob Wrigley
anonymous
<rand...@earthlink.net> skrev i en meddelelse
news:1125610833....@g14g2000cwa.googlegroups.com...
>
> anonymous wrote:
>>
>> In my oppinion tutorials should never use predefined constants or
>> predefined
>> macros in the first couple of tutorials and then if they wish to use
>> them,
>> the tutorial should describe and explain them, so the reader is included
>> in
>> the making of these predefined things. How would a beginner ever
>> understand
>> something predefined, when "pre" is "pre" as in before the first
>> tutorial/lesson?
>
> reader.
> Those books and schemes that *do* start at ground zero, often fail to
> progress very far.
Yes, the trouble is that fairly seldom, the tutorials that start at ground
zero will ever teach you the necessary prerequisites. (not counting C and
your book(s))
> But if you want a good example of a book that does a
> reasonable job, take a look at Jeff Duntemann's "Assembly
> Step-By-Step". It's intended for people with *no* programming
> experience whatsoever; although most people who read the book have some
> programming experience, they like the fact that it makes no assumptions
> about prerequisite material, so even though they wind up reviewing a
> lot of material, they don't miss anything either. Sounds like just the
> ticket for you.
Thank you very much! :) Though I have finally gained (I feel) the necessary
prerequisites for the tutorials, I will look into it none the less. I always
like reading about things from more than one source to better understand the
concepts in question.
greetz :-D
Jakob Wrigley
Alex McDonald
> "Alex McDonald" <alex...@btopenworld.com> skrev i en meddelelse
> news:1125608344.8...@g49g2000cwa.googlegroups.com...
>
>>anonymous wrote:
>
>
>>>3. The true assembly are the same regardless of os, only address and
>>>method
>>>varies when addressing OS calls.
>>
>>Again, I think you'll find it very different from OS to OS. Solaris on
>>x86 is different from Linux is different from MINIX is different from
>>Windows.
>
> Coding in assembly in Linux or Windows (or any other OS) on a x86 machine
> will be exactly the same "call" is still "call", "push" is still "push",
> "mov" is still "move", etc. What changes when you change OS is the
> environment, meaning how you interface the operating system (which call's or
> int's will have surtain functions) and how you interface the operating
> system to again interface the hardware.
> Therefore Assembly instructions don't change. The only time when assembly
> changes is when you the hardware, when foreinstance you replace your pentium
> IV chip with a z80 or motorola chip.
In most applications written for large, complex OSes the amount of code
that doesn't inetract with the OS is relatively small. I agree that a
call is a call, but drawing a window under X or Windows is more than
just a different set of calling parameters; the techniques are
fundamentally quite different.
>
>
>>>4. StdIn/etc. are just numbers/ constants from 0 through 2. The calls to
>>>use
>>>them are different in every OS. In C however this is hidden under
>>>standard
>>>library calls.
>>
>>Funny, on my copy of WinXP, GetStdHandle calls for STD_ERROR_HANDLE
>>STD_INPUT_HANDLE and STD_OUTPUT_HANDLE return 11, 7 and 3.
>
> This was supposed to be read as an explanation to the fourth statement:
> "Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!"
But here the techniques are the same (as opposed to the example above).
Windows and Unices all have a handle that writes to a standard output,
for example -- the difference is getting the handle under Windows
requires some extra work.
> STD_INPUT_HANDLE, etc. are indeed constants, I was not referring to the
> handle
> you receive from GetStdHandle, but the constant you supply it.
>
> But actually the constants StdIn/etc. are not always from 0 through 2, as
> you state.
> I didn't bother to check their actual values, merely assumed they were the
> same as in linux, but apparently not.
> they have values from 0F4h through 0F6h.
They have values 0xFFFFFFF6 through 0xFFFFFFF4; signed -10 through -12.
>>
>>You're best doing a bit more study and research; stating as fact
>>something that's demonstrably untrue, as with handles, isn't very
>>productive.
>
>
> They were merely statements, though I believe them all to be true, they
> could be true or false. :)
But the factual ones are easily checked; are you too lazy look it up and
get it right?
--
Regards
Alex McDonald
anonymous
[1.] first of all to my understanding portability is merely illusion!
[2.] second, show me the Win32 C program that isn't Win32Asm!
[3.] third, Assembly [instructions] is universal, it doesn't change from OS
hardware to hardware)!
[5.] Fifth, programming resides in taking advantage of the functions one has
original statement.)
Number 2 should probably have been: "A win32 C program is a win32asm
program" or something to qualify as a statement, but the meaning of the old
one should be clear enough anyhow.
Alex McDonald wrote:
> In most applications written for large, complex OSes the amount of code
> that doesn't inetract with the OS is relatively small. I agree that a call
> is a call, but drawing a window under X or Windows is more than just a
> different set of calling parameters; the techniques are fundamentally
> quite different.
Which is one of the reasons why portability is an illution. [1.]
>>>>4. StdIn/etc. are just numbers/ constants from 0 through 2. The calls to
>>>>use
>>>>them are different in every OS. In C however this is hidden under
>>>> >>>>standard
>>>>library calls.
>>>
>>>Funny, on my copy of WinXP, GetStdHandle calls for STD_ERROR_HANDLE
>>>STD_INPUT_HANDLE and STD_OUTPUT_HANDLE return 11, 7 and 3.
>>
>> This was supposed to be read as an explanation to the fourth statement:
>> "Fourth, there are no _standard_ StdIn/StdOut/StdErr calls between OSes!"
>
> But here the techniques are the same (as opposed to the example above).
> Windows and Unices all have a handle that writes to a standard output, for
> example -- the difference is getting the handle under Windows requires
> some extra work.
wouldn't the fact that you 'push & call' the windows function and the fact
that you 'mov reg, val & int 80' apply for difference in both
technique/method and the call itself?
>> STD_INPUT_HANDLE, etc. are indeed constants, I was not referring to the
>> handle
>> you receive from GetStdHandle, but the constant you supply it.
>>
>> But actually the constants StdIn/etc. are not always from 0 through 2, as
>> you state.
>> I didn't bother to check their actual values, merely assumed they were
>> the same as in linux, but apparently not.
>> they have values from 0F4h through 0F6h.
>
> They have values 0xFFFFFFF6 through 0xFFFFFFF4; signed -10
>through -12.
Sorry, my bad, I expected those to read the same, afterall, 0F4h =
signed -12, and 0F5h = signed -10, just not dwords.
>>>
>>>You're best doing a bit more study and research; stating as fact
>>>something that's demonstrably untrue, as with handles, isn't very
>>>productive.
>>
>>
>> They were merely statements, though I believe them all to be true, they
>> could be true or false. :)
>
> But the factual ones are easily checked; are you too lazy look it up and
> get it right?
I thought I had already done that, which factual statements were wrong?
greetz, :?)
Jakob Wrigley