From: JGCASEY on

Betov wrote:
> "JGCASEY" <jgkjcasey(a)> écrivait news:1125444014.546353.194190
> > 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...

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.


From: Alex McDonald on
Betov wrote:
> "Alex McDonald" <alex_mcd(a)> écrivait
> news:1125485155.593326.211830(a)
> > 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

Alex McDonald

From: Alex McDonald on
Betov wrote:

> 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

Alex McDonald

From: f0dder on
Evenbit wrote:
> 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.

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...

From: Herbert Kleebauer on
Betov wrote:
> Herbert Kleebauer <klee(a)> ý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.