Re: win32 or native NT windows API
- From: Herbert Kleebauer <klee@xxxxxxxxx>
- Date: Wed, 14 Jun 2006 23:11:17 +0200
Julienne Walker wrote:
Herbert Kleebauer wrote:
That's BS.
What is BS?
Bull***.
That was a good one! I know what BS is, but I don't know which
part of my posting was BS.
There's a huge difference
difference between what?
Difference between calling the stub and copying the code inside the
stub.
Sorry, but I don't get it. About which "stub" are you speaking
and which code do you copy into the stub?
And once you know what really happens, why bother when you can have a
convenient interface that's more portable?
Exactly my words. Once you know how to multiply numbers, there is
nothing wrong to use a pocket calculator. But somebody who just
starts to learn how to multiply numbers shouldn't be told: use
a pocket calculator, enter a number by pressing the keys "0"-"9",
press "*", enter a second number and press "=", this is all you
need to know about multiplying. And we are speaking about learning
assembly programming and not about writing applications in assembler.
And learning assembly programming doesn't only mean to understand
the effect of CPU instruction but to get a feeling for the low
level working of the whole system.
I'm having trouble
understanding what your point is.
I surely have the same trouble with your point.
First you advocate hardcoding crap
that will likely break on any other Windows version, now, after being
called on it, you seem to be changing your perspective.
I never change my perspective. But you are mixing up two completely
different things: learning assembly programming and writing
applications in assembler (btw. the second is completely obsolete).
int 21h is completely different from a system call because it's an
emulation feature. The functionality is handled through the ntvdm
subsystem, which employs DLL function calls. Using int 21h to justify a
dangerous and unnecessary practice of trying to call the kernel
directly in Windows is just plain stupid.
Don't understand what you want to say. DOS (I mean the real DOS)
is not much more than a collection of interrupt routines and a simple
file system. If you are speaking of "DOS in Windows", than this is
nothing than an emulation of the real DOS, so you only call the emulated
DOS OS (emulated by the real OS Windows) and this has nothing to do
with a call to the hosting Windows OS (which only indirectly is called
to emulate DOS).
That's exactly my point. You were using a DOS emulation feature to
justify something completely different.
I don't understand anything. What "emulation feature" is used
to "justify" which "completely different thing"?
And yes, I'm speaking of "DOS
in Windows" because this thread is about Windows, not DOS.
The word "DOS" came into this thread by the sentence:
And this is the reason why the old DOS
int21 (or the Linux int80) interface is much more appropriate for
learning assembly programming than the DLL calls in Windows.
If this sentence means "DOS programming in Windows", then it also
means "Linux programming in Windows". And I hope even you agree
that this doesn't make any sense.
.
- Follow-Ups:
- Re: win32 or native NT windows API
- From: Betov
- Re: win32 or native NT windows API
- References:
- win32 or native NT windows API
- From: Vikas Kumar
- Re: win32 or native NT windows API
- From: Julienne Walker
- Re: win32 or native NT windows API
- From: Herbert Kleebauer
- Re: win32 or native NT windows API
- From: Julienne Walker
- Re: win32 or native NT windows API
- From: Herbert Kleebauer
- Re: win32 or native NT windows API
- From: Julienne Walker
- win32 or native NT windows API
- Prev by Date: Re: Book on Assembly
- Next by Date: Re: win32 or native NT windows API
- Previous by thread: Re: win32 or native NT windows API
- Next by thread: Re: win32 or native NT windows API
- Index(es):