Re: how do you start learning assembly language


"//\\o//\\annabee" <w@xxxxxxxx> wrote in message
news:op.t54439gpwzh472@xxxxxxxxxxxxxxxxxxx
On Mon, 04 Feb 2008 04:20:15 +0100, Ratch <watchit@xxxxxxxxxxx> wrote:

Hi's dead but he wount lie down ;-D

Nope, still alive and kicking.



"//\\o//\\annabee" <w@xxxxxxxx> wrote in message
news:op.t54qbgp9wzh472@xxxxxxxxxxxxxxxxxxx
On Sun, 03 Feb 2008 21:54:09 +0100, Ratch <watchit@xxxxxxxxxxx> wrote:


"//\\o//\\annabee" <w@xxxxxxxx> wrote in message
news:op.t531p3hbwzh472@xxxxxxxxxxxxxxxxxxx
On Sun, 03 Feb 2008 15:20:47 +0100, Ratch <watchit@xxxxxxxxxxx> wrote:


So what is wrong with an object file? Why do you consider them
"traps". To me, they are language independent entities that support
modularization.

I am not saying obj does not work. They are just not giving you any
advantages either. And in fact they provide a range of disadvantages,
I
am
not trying to prove it. I just argue it because it has been my
experience.

Your position would have credibility if you could prove it.

True. But I _have_ proven it. So did RosAsm itself, before I did.
You just fail to accept the proof. That is because you fail to recognize
problems comming out of a methology that has been inherent in objectfile
compiler technology for decades, and which every compiler author have
accepted and made available workarounds for.

Perceived experience is not proof.

You just misunderstood the points. The problem is sufficently mapped.
And I have refuted your claim that monofiles are bad idea or "design lack"
or whatever.

Yes, you refuted it my claim, and I replied with counter claims.


Workarounds that are not
needed for a monosource. Workarounds that complicate the source writing
process. Monosource is the universial solution to this problem. It solve
even the possibility of the problem existing, and does this on behalfe
of
even users _unable_ to write units without cross referanses. You dont
accept that there is a problem. In this you are definitly wrong. And so
that is why you cannot see how monosource is the ultimate solution to
this
problem.

The monosource method you use covers up bad code organization and
faulty flow of code execution.

:) hum ?

How so?

Faulty flow code is a longer path and harder to debug and understand.


This causes a longer code path that is
necessary,

?? :)))) Whooot?

Please explain why you think this is so. Fast before I die with laughter.

It should be obvious to you. If the code flow can be arranged so that
each module has one entry point and one exit point, then excessive jumping
between modules is eliminated and the path is shorter. Spaghetti code is
usually longer and harder to understand.


thereby causing longer execution times and perhaps drifting
outside the cache boundries more often.

prææææ hæææææ hææææ :))))))))))))

n1, very funny.

Very practical.


The modular method forces the
programmer to plan more carefully what the flow of execution will be.

Uncle Objectfile is keeping an eye out for things you know.

Always.




But writing objs today is no more a fruitful strategy, as
everybody
with
a working pair of eyes can see by inspecting the _complete_
failure
of
modular programming practises in the Window OS. The so well sold
strategy, has failed to an extent allmost unimaginable, and is
only
mactched by the strength of the propaganda that still sell
strongly
despite the awsome amount of evidence that the strategy has
failed.

I have no idea what you are talking about. Linking objects
has
worked
well in the past, and still works today.

How do you define "working"?

Doing what something is designed to do.

They do not do what they where designed todo. Well, yes, they do......
But
they do not do what they wore SOLD todo. They do not give any
advantages
(anymore) on using a monosource approach. They are old technology that
isnt all that good of an idea. (anymore).

Again, your above statement would be credible if you could cite
proof
of what you say. Don't the linkers do what they say they do on the
product
packaging. If yes, that is what they were sold to do.

I have shown in my posts the problem. The problem is real and known to
compiler authors. I have pointed to the solution. I have written 3++
megabytes of code that demonstrate my point. RosAsm itself is another 4
megabyte source demonstration also showing the solution. All that I have
said is simple to understand. So for you to refuse this now is a bad
choise. As it is now evident that this circular referance problem
_stems_
from the use of obj files, and that it never even can exist in a
monosource, you have no choise but to admit that you misunderstood the
topic, or that you are unable to undersstand it.

I do understand your problem and your "solution". I don't think is
a
good solution for the reason I gave above and before.

Thanks for refreshing my memory.

Your welcome, I thought you needed it.







These things are made for more then just "working".

If they were not working, they would be useless and no one would
use
them.

They are not offering any advantages. Versus using a single source
file.
(anymore)

If this was about "working" or not, why have this conversation? Its
_not_
about that.

Because you seem to think linking does not work well. I think
it
does.
That is what this conversation is about.

No, this conversation started out with you claiming monosource was
inferiour (lack) (designflaw) in a modern assembler. Did you not?
Thats
what I am claiming is incorrect.

Yes, I said that if an assembler did not support linking, it
lacked
a
useful feature. For one thing, every assembler is limited by the size
of
the source it can support.

Only in a closed source product.

I would guess that every assembler gives the user a generous limit
of
source code.

And?

So a closed source product is not a problem if linking is available.


If you need to assemble a single gargantuan file, your
methodology is wrong, and you need to split it up.

How is that? Why is that?

See my response below.


This is about how to manage a _large_ project _efficiently_ and
avoiding
the
ZERO_SUM_EFFECT of - and _trap_ that comes with using objs and this
antiquated modular strategy, to free yourself of the burdens of
historical
stupidity and resistance to change.

Can you be a little more specific? Perhaps cite an example
where
modular linking has/is causing a problem.

No need. This is a very old and completly known problem. Also I
allready
gave one example.
Circular dependencies, that defeat the DIVISION part of modular
programming. Why devide when you are unable to keep the division to
the
end anyway? It is redundant, and when this fact is realized it is
stupid
to try to force a paradigm that is proven not to give the benefits it
was
promising to deliver.

It does deliver when done right.

That where you are wrong. You have the burden of proof here.
Not only that, you have to admit that this require to plan out a large
problem in
every detail from the beginning. This shows you are a fool. What you
claim
is impossible.
Nobody,_nobody_ is that smart. Claiming that you are shows you are a
fool.
Not that you are smart.

Yes, planing is great. Planing is good. You should try it
sometime.
Every large project correctly executed does it. No one but a fool goes
off
half cocked, and builds something while designing it at the same time.
Do
you do that?

This is exactly how developments are conducted. Maybe except for the one
that fails because they try
too hard to design by too rigid a prinisple.

Again, I disagree. Things always work out better if planned in
advance.


None of what I say apply to the hobby sizes projects. Of course
obj's
are
"working". But that is irrelevant. They do not work "well".

How so?

Allready mentioned.

Where?

In allmost every single post in this exchange.

But not proven or good reason given.

Explained completly.

Not quite. But you did explain for the first time how to partially
assemble a file below







They lead to the same situation as "DLL hell",

What's that?

Allready mentioned.

Where?

In at least two posts in this exchange.

But not explained.

To the death.






and is only helpful for small projects.

Why does modular linking not apply to larger projects?

Allready mentioned.

Where?

If you have problems with remembering what has been discussed, you could
try reread the parts that you skipped.

You never said why one could not scale up modularity to larger
projects, you only implied difficulties doing that.

I did so at length. Yes difficulties doing that. As oposed to NO
difficulty scaling a monosource.

Modular:
- more work at managing more files, because overhead, forwarding, and
share numbers

The reason for having files is to partion the code. I like partitions.
So do most programmers. That why we have subroutines, loops, condition
blocks, jump tables, etc. Why is there more work having several files open
vs. having several bookmarks in a big monofile? I don't know what you mean
by "forwarding" or what share numbers are.

- slower compilation times, due to more files to process and larger files.

I would think less. Opening and closing is only done once per
assembly. That's insignificant. A bigger file means larger label tables,
jump tables, relocation tables, and anything else the assembler needs. My
feeling is that the time required maintaining and running all those tasks is
increased by more than a linear amount.

And since opening and closing files are very slow.

Not in terms of human perception. And only done once per assembly.

- objs incur a fenomina known as circular referances, that creates more
work, and forces more bloat and overhead. And extra time refactoring.

We talked about it before. That is a warning to reorganize.

- Defeats incapsulation. Thus creating even more overhead to regain
stabile interfaces.

That is a HLL term. I don't worry about that in assembly.

- slower project management times, take longer to search many files for
declarations and info.

My text editor can search multiple files with one command.

- Diskbound compilations that requres abuse of memory im order to be
resolved.

I never heard of a disk bound assemble. What's that?

- Longer documentation due to more files to document.

I don't see how. The same information should be written for sections
of a big file as for several smaller ones.

- More work in finding the right file to put new functionality in order
not to break project,

A good flow chart, which all large projects should have will solve that
problem. There are even programs that can generate them.

- More hardisk space required due to overhead,

Trivial. The O/S already spreads itself across the disk with several
thousands of files that it probably never or seldom uses. What's another
few files for a project.

- More time used by programmers and maintainers who must control both
interfaces parts and
implementations parts.

Time well spent. Getting the implementation and interface right is
important.

- More discurraged programmers due to longer redundant maintaince cycles.

Can't be helped. No one can write a program and expect to walk away
from it. Someone is going have to maintain it or it will become static.

- Less readability, due to more overhead.

Overhead has nothing to do with readability.

- More things to check out when bugs occur due to more overhead.

What overhead? How does it apply to bugs?

- More time to backup project.

Not significantly in term of human perception. Especially if they are
small files.

- More time to verify that all files are propperly located.

What does that mean? Who cares where the file manager puts them on the
disk?

- More time to confirm that each filed backed up is good, due to more
files and more verification.

My backup system verifies automatically.

- Heavy strain on maintainers due to all information is encapsulated and
to learn what each files does, where it is locatied, what it called, and
how it is organized.

Are we talking about assembly here? Why does encapsulation enter into
the picture. I have never knowingly done encapsulation.


= inferiour technology.


Monosource:
- no problems

= superior technology.


To each his own.



Just beeing helpful, Ratch :D

So am I.

What I say is evidently correct. And you just refuse to admit total defeat
and surrender.

No, it is not evident. Not until I know a lot more about how you can
do what you say you do.




For large projects they are more trouble then helpful. I repeat: In
a
large project - which all serious projects become sooner or later -
every
part of an application is somehow dependent on parts of the rest of
the
application, and so putting it all in one file

All parts of non trivial programs depend on each other, both
logically,
and the need to reference code in different parts of the program. I
see
no
advantage in keeping everything in one big glop instead of
separating a
program into smaller logical units, and linking them together.

True, you do not see this. This is why I try to tell you. :)

You need to do more that tell someone, you also have to show them.

I have showned them. You either do not understand the topic, even I
explained it in detail, or you are refusing to accept obvious facts, and
historical evidence available. Or maybe you are Trolling?
From your historical postings in this ng, I would guess you are refusing
facts when staring you in the face. ( This remind me of Hutch ).

You have touted a method, just as I have. We both understand what
each others methods are. I explained why I don't think your method is a
very good solution. You seem to have difficulty with the way I propose.
I
wish someone would chime in and offer a new perspective about our way of
thinking.

Its not needed. I have _shown_ that modular methods introduce more
problems, by themselfes.

No, you have declared, not shown that they do. And I have pointed out
how to correct those problems.

Problems not even conceivable in a monosource.

You mean problems that are covered up in a monosource.

This is a complete rebuttal of your failed claim
that monofiles are inferiour to modular methods.

Only in your own mind. In the minds of others, there is doubt, as
evidenced by the popularity of your method.

No more needs to be said.

The numbers for the usage of your method says it all.







It certainly
is more difficult and takes more resources for an assembler to do
everything
at once instead of assembling several units. And if a change is
made,
having to do everything over again instead of just assembling one
smaller
unit.

No it does not. Please explain why you think so.

Should be obvious. If you really keep a project in one file, then
any
change to that file means a reassembly. Unless you partition that file
into
separate modules. Is that what you are really doing?

Theres nothing that needs to be reassembled that isnt affected by
changes.
Why would you think is would?

Because if it is one large file, then it would have to be
reassembled.

No. This is a wild assumtion. I can see many oportunities for partial
compilations.
Say if you have a large PE, say 600kb. Now if you add one instruction at
the end,
it goes without saying that this can be reduced to near instant
recompilation time.
For changing the middle of the app, maybe you can cut most of the work for
half
of the PE, and just need to offset pointers for the rest of the file.
(that is faster then the entire linking process)

Huge savings may well be possible by looking into things like that.
I find it relativly easy to imagine many other such shortcuts when
compiling a monosource.
Theres no law of nature to process a file blindly from beginning to end
each time, when
theres just been a couple of small changes.

Patching! You are talking about patching a file. Why didn't say so
before? Do you have a patching processor? Interesting concept. I will
have to wrap my mind around it a bit. Does it really keep track of changes
like that? Of course, if the changes occur at or close to the beginning,
you might as well process the whole file. It still does not remedy the need
for organizing the program into logical units without circularity, however.



Maybe a certain implementation would do this, as it would be fast
anyway,
but there is
no reason why the total source _must_ be processed from scratch for
every
compilation, just because it is a monofile. Why would you think such a
thing? For a man able to guarantie that he will never incur
selfreferances
in a _large_ (>400kb) selfcontained sourcecode, because you claim to
allways be able to plan around for this - that seem kind of lame
assumption? I dont really think anyone belives you can do this. You
cannot
even understand the simplest things when handfeed you. How do you think
you be able to do what you claim?

Are you using software switches to turn the assembly on and off?
Or
perhaps a script? If so, I don't see any advantages in having your
source
is a large contiguous file. The self references are structured to be
loops,
jump tables, conditional paths, etc. The spurious jumps are kept to a
minimum.

This is not only about that. Circular referances isnt just about "jumping"
(rarly if ever in fact)
it is about having multiple referances to data and structures,
that is stored in one unit and used in other units. Often changes demand
that data that wore previously consider private to a unit, suddendly needs
to be exposed (exported) to some other unit, FROM a third unit, because of
a new feature demands it.
This is much more common than you think. Yes, in theory it can be designed
away,
but often it cannot, despite any flunking theory. And never at a low
price.
So then there is a problem, and it is a serious one, and the problem exist
_ONLY_
because of using a flaky and buggy design methology. Huge overhead are
also suffered by
the insane way of using rutines to set members in structures, in order to
defeat circular
referance problems while keeping data to their original level of privacy
(encapsulation)

nobody writes software from dictation. They know that the specs will
change when
the customer sees the first implementation, and so rewrites, adjustments
and updates, and
creation of new features, and rewriting of userinterfaces, to improve a
product is
a nessesary part of the development cycle. You wishfull "design it all
beforehand" is
nothing but a joke.

It sounds like you are talking about HLL again when you speak about
"privacy". If a module is not supposed to reference a data module, then
don't code it to do so.

The specs are always presented to the customer for review. Upon
acceptance the coding begins. If not, the specs are modified to the
customer's satisifaction. If changes are requested after coding begins, it
becomes more expensive and delays can occur.





- given a tool that manages to manuver the entire file in clicktime
(Like
RosAsm does) is a very good way to work.

By maneuver, to you mean editing? By clicktime, do you mean
using a
menu?

For having a little part of the project modular - it allows for
sharing
code between two sources, via DLLs, COMPONENT TEHCNLOGIES (com)
and/or
by
_copy and pasting_ key parts. This will (and I have proven this)
give
_less_ waste and redundancies, overall, in the end. And completly
solves
all the problems comming with using units (DELPHI) that compile to
object
files, that are then linked together in the project. ( circular
referances )

Modularization, code sharing, cut and pasting, has been done
since
the
year one using linking technology. As with anything, it is or can
be,
as
efficient as you make it.

Yes, to some extent. But if you manage several files, like it was just
parts of one single file,
then you must agree it is redicoulous and inefficent to not merge the
files into one. One file, means you need to open one file, 100 files
means
you need to open and read (and check) 100 files each time you
compile+link
them.

No, not all the files. Only the one that needs to be changed.

You misunderstand. You still have to open all the 100 objectfiles, in
order to link them.

The linker does that quickly and efficiently.

And with only one file it will be _much_ faster.

I don't know about that. The same number of references have to be
satisified in either case. Opening and closing files are not a big deal
either.


In addition to the changed sourcefiles, And you also have to check
every
referenced module, to the once that are listed from the changed
sourcefiles. This takes considerable time over dealing with only one
file.

Not for me, I own an editor that can search and make changes in a
group
of files.

I am not taking about that, I am talking about the work the compiler needs
to perform in order to check and resolve the new changes that may or may
not affect any other units in that project.
Which turns out to be often time quite many. The overhead of solving all
theese issues completly is HUGE, and complicates the sourcecode immensly.
Non of that bloat (interfaces, header files) is needed in a monosource,
and all of this wastly reduces the complexity both for the assembler and
for the coders.

Do what Hutch has done with MASM32. All the include, header, and
library files handy in organized folders, and selected at the beginning of
the source if needed.






If there are problems, they are caused by program
design or implementation, not by the linking method.

To some extent this is true. But it is also a misunderstanding of what
coding is. It is a process where the process leads to creation of
_new_
code. New constallations of numbers, simply. And this process is
unique
for every unique program. Even when rewriting similar code as you did
before. Only if you know it all before you write a single line can you
succeed at haveing a perfect organization. This has never happend,
ever,
in all og history, for a large project, and it will never happen
_ever_
for any such project. As this is matematically impossible.

Mathematics has nothing to do with it. You run into problems like
you
mention above if you code "on the fly". By planing beforehand, you can
either eliminate those problems completely, or catch them before they
become
intractable.

Wrong on all acounts. Mathematic has _everything_ todo with it.
Obviously
you have no idea of the complexity we are talking about here, and are
unable to do the math. Second, you have no idea of what a coding process
is. Nor what _code_ is. Code _is_ mathematics.

No it isn't. Codes are instructions for a automaton (computer),
usually express in numbers. Coding per se in not mathematical.

Right. And what do you call the boolean matematics then? Which is what the
processor does all the time? Hocus Pocus Logic? :)

That is an application of Boolean math that occurs after the coding is
done, and not of concern to the programmer.


Code is nothing but numbers. A large program is nothing but a _very_
large
number. You claim to be able to calculate this _extremly_ large
number, in
your head, or on paper, to its exact value, before writing a single
line
of code.

Numbers by themselves are not mathematical. I claim to be able plan
the interfaces, and have a general idea what I will be coding for before
I
start. That is not a super human endeavor. Just a methodology.

You claim is bogus. And evry coder knows this.

Not me.



- You are insane.

Then so is everyone who plans ahead.

Right. And theres never something inbetween insanity and a full creamy
vaselina spagetti?
Like planning a little, collecting some intel, some results, and ajusting
after the _real_ terreign?

You start with a goal in mind, plan to reach the goal, then adjust to
achieve the goal.





For even larger projects, like 10-20 programmers working together,
DLLs
will solve the interface to commonly used code, and each programmer
can
work on a section of code, independently - just as easy as with the
object
(OOP) information hiding beautiful lies, by agreeing to the
interfaces
between the code sections parts, which must be done in either case.
(
_MUST BE DONE IN EITHER CASE_ )

Program management is essential when multiple programmers work
on
a
large project. The leading programmer has to specify and approve the
design
of the program, specify the interfaces, and assign the personnel to
code
the
various sections of code. Linking technology does not hinder this
process,
and I don't see how doing everything in one big file helps it.


Dont you see we've been held for fools?

Er.. no, I don't.

Dont worry about it. :)


Just because you use a different method does not make it better.

Duh! (what I said)

The
competence and skill of other "people" is a nebulous quantity to
judge.

Thats out of topic.

Well, you mentioned it first.


Complexity is not. The average IQ is in or around 100-110 or
something.
Therez no law against having an avarage IQ, so theese people will be
programmers as well.
They will run into complexity and maintance problems like all
programmers.
Given that the diffrence in two people intelligence, more often then
not
is completly
irrelevant to their relative performance, does not counter the fact
that
the complexity
stopping the one is not many iterations away from what is stopping the
next guy,
History is filled with examples of stranded IT projects. And this is
for a
reason.

Complexity can me managed. The ability to think well is not
defined so
much by how well someone can understand overall complex things. It is
how
well they can deal with it. Usually by breaking the problem down into
smaller units, which makes the solution easier.

This strategy does not scale. I dont have to show this. YOU have to
update
your brain. This is a very common problem, and I simply doubt you are
the
one to solve it, as you do not even understand the problem. Talk is
cheap.
Let us see an application you created of such complexity then. Lets see
if
you can prove that you are able to solve it?

The strategy I outlined above is call the "divide and conquer
method".

Right. Dive and Confess.

Your strategy appears to be unplanned pursuit.


Ever heard of it? A lot of people use it. If fact, when a problem or
project becomes too big for one person to handle, the first thing that
happens is the project/problem gets broken down into managable pieces.

So the project becomes broken, and then you start breaking it up further?

Not necessarily broken. Just grown too large. If the project itself
breaks, then project management needs to be changed.

:p
ah... but what happend to planned it all beforehand... ?

Nothing, the planning is still good. Only the size of the project
changed.

So you do understand that things changes from the blueprint.
Congratulations.

Always have, always did.







Of
course you know the details of your project better than anyone else,
but
that does not necessarily affect the efficacy of your method.

Thats a good description of the reverse of the actuall situation.

To completly evaluate and prove my point, will take some work on
your
part, cause a lot of this is derived from experience. Its just not
that
easily proven. If it was, then theese strong mythologies wouldn't
have
survived. Anyway. I am done here. Case closed.

That is not the way it works. It is up to you to prove your
point,
not
me. You can do it by argument or example.

Maybe if you promise to take your medication master Ratch.

Don't expect me to prove your arguments for you.

Huh.... I certainly dont. But I expected you to read and at least
understand mine. This problem is now mapped enough that the claims you
made at the beginning is beaten to death. You have lost the debate. You
dont even understand the topic. Or you refuse to. Either way, you lost.

I don't think so.

Thats come as a real fucking surprice!! :))


Note that I am _not_ saying that modular is allways wrong. Rather I
am
saying "allways" is allways wrong. As you correctly notice, once the
code
is cleared, it can be made modular. The problem with objs is that
they
do
this from the very beginning of a project, and follows the entire
evolution of the code.

Yes, as it should be. The project, especially a large one,
should
be
planned at the beginning before one line of code is written.

Allready mentioned

I'm glad you agree.

You are speaking out of ignorance here. The claim is really absurd.
Prove
it.

Hard to do over the Usenet. But I never worked on a project where
they
gathered a bunch of programmers in a room, gave them a performance
specification of a large project, and let them sort it out. That is a
recipe for disaster. Successful large projects are managed and planned.

Sure. And I never said they wore not. But you do _not_ micromanage a team.
You set some goals, you devide the task. You dont plan every single use of
a type class or variable.
CODEING _IS_ THAT JOB..... You dont do this on paper. Only the big lines
and goals are done on paper.
And solving of more complex acute problems underway.

Boguses claimses !

I think we agree that big projects should be managed, but not micro
managed.





And that is, even if it could be made to work, a very stupid thing
todo,

Planing and developing achievement strategies is never a stupid
thing
to do.

yo mama told you that ?

No, experience did.

But you have no experience.

Don't bet on it.

Well. As irrelevant as your arguments are,

Only in your own mind.

I bet you must have found employment somewhere. ;-D

Indeed I did.

Thats the punishment God gave to all the little nauthgy trollings of Adam.

If I did not produce, I would not have been retained.






today, when we have this fast hardware, and such abundances of
memory
as
we now have.

Irrelevant to program design. Helpful for program results.

sigh....

In a new situation, a new strategy must be deviced.

That is a given.

Yes. Just remember who gave it to you.

It is self-evident.

So what do you reply for? This is what I said from the beginning...

To show that your statement about a new strategy was not profound,
and
is self-evident.

:)) right.....






And everybody that codes in asm, can see that the modular strategy
_does
not_ scale, and that allmost any app of some size, written in C,
C++
or
similar, is DOGSLOW to work with, because of this failed strategy.
Java is
imo the ultimate fallure in this regard.

I don't know about the HLL's you mentioned above. But I cannot
see
how
ASM does not scale up in a modular way.

Nobody doubts this.

Did you not say above that modular strategy does not scale up
well?

I ment, you allready shown us that "...I cannot see..."

Yes, I cannot see why modularity does not scale up. I think it does
scale up quite well.

I know you cant see it, so thats why I explained it to you.

Is it too much work for you to go back and look instead of asking if the
topic of this exhchange have changed? Why do you keep repeating things
we
have allready been over, and why to you keep asking questions for which
you can find the answers by going back and look at the allready
exchanged
messages? This seem a bit unneeded. You have posed a claim, I have
debated
you on that claim in several postings. I find it hard to belive you
could
have forgotten the topic allready.

Because when you said that "Nobody doubt this", you appeared to
agree
with what I said and disagreed with what you said before. That is not a
change of topic or forgetfulness, it is a request for clarification about
what you really said or meant

But I allready made the clairfication, many times.

That is not what you wrote down above.





The fact that it has not taken over the assembler world shows
that
it
is not as highly regarded as you think.

It is not regarded because it is not understood.

Others who do understand it don't think it is a revolution in
program
development.

right, :)

As I said, even universities teaches ***, and belive it is good
stuff.
Everyone seem to teach that you shouldnt use asm for real
applications
today. The main argument is that it is too much work, and another
is
that
compilers makes better code. Both arguments are so wrong that it is
sickening.

Perhaps, but HLL's promote a faster development time using less
skilled
programmers, at the expense of quality. And, of course, there is the
portability problem with ASM.

No, there is no portability problem with asm.

Of course there is, the instructions that work for an X386 will
not
work on a Power PC.

That is true. I was assuming x86, and that you ment portability between
OS. Sorry.



And yet the first argument is right, if MASM would be the
"assembler"
used
for the tests. Its understandable so many people are confused, but
it
is
not forgivable that they remain confused after the claim has been
counter
demonstrated ( by RosAsm itself), since 10 years.

I don't think confusion is the problem, nor is MASM. I believe
that a
judgement has been made about the processor you use.

???

Everyone is free to judge, no one is selling anything here.
Opinions
are expressed and argument are made. But in the end, the user
decides.

No. The user can deside nothing. For proprietary works, he is signing
a
Non disclosure agreement, and paying a rather large free, while beeing
offered absolutly no guaranties as to wheather his program even works.

It is up to the user to make his program work. You cannot expect
the
vender of the assembler to write and debug the user's program can you?

?? I was of course talking about the licenced program,

Most venders support what they sell.



For his money he does not even get to be the owner of his copy of the
works, The eula makes him powerless with regards to anything, and the
only
thing he desides is weather to accept the eula or not. Which he
cannot
because in most cases he neither has the prerequisite or even the
ability
to even begin to understand what he is agreeing to. This is what MASM
is.

I don't believe MS restricts a commercial application written by a
owned copy of MASM. I think they only restrict a competitve product.

No, it is restricted to the MS os. But I also do not know. Only a lawyer
could have some real idea what an eula really imply, and only a court
room
could deside for sure. Main point, it is completly disclaiming any
guaranties with regards to the licenced program. And this you have to
pay
for.

They can't guarantee success, but the do support the product. For a
while anyway.



Or
limit what proprietary vender's software can be distributed with the
user's
program. Others know more about this than I do, and they are invited
to
display their knowledge.






Propaganda can only get and hold attention for so long. If
there
is
not some solid benefit to a product or service, it will eventually
wilt
away.

Maybe. I dont really think that is true. Because ppl have built up
their
"empires". Tons of books been written, prinsiples been established,
compilers been written, names have been created, and songs have been
sung.
New findings threatens theese guys territorium. So they are
protecting
their lies. A few sincere voices drowns in the noise.

The proponents would not be able to do the above things unless
they
had
substance to back them up. No matter how they are threatened or wish
change
would not come, if they can not prove their way is better, something
else
will take its place.



What's WinAmp? Ratch

Its the most popular and likly the best audio player on the windows
plattform.
Congratulations for not knowing it. That must have taken some
tremendous
efforts on your part is my guess.

Does it cost money? If so, that is why I don't know about it.
I
do
use the Windows Media Player, however. Ratch

Yes, but whos the guy writing your script. I can hear him, but I
cannot
see him.

That guy is me. You cannot see me because Usenet is not a visual
medium. Ratch

:)) Thats also true. Lets be grateful for every little blessing .






--


--


.

Loading