Re: Iczelion's tutorials revisited.


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

.

Relevant Pages

  • Re: the ms monopoly is over. gonna kick some ms butt. are you with me?
    ... IP-DOS is only a plain vanilla Windows service. ... his app for their api rather than for win32 and its derivatives (e.g. ... visions for the future of software. ... with a programming abstraction, with an api, that i liked. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Windows API calls in .NET application
    ... can use managed extensions to get the benefits of managed code, ... Voodoo Programming: Things programmers do that they know shouldn't work but ... > program windows applications using C++ and native API. ...
    (microsoft.public.dotnet.general)
  • Re: May I introduce myself to cobol?...
    ... a clarification on what the win32 API ... meaning "Application Programming Interface", ... in the context of the OS Windows ...
    (comp.lang.cobol)
  • Re: C compiler for Windows
    ... I ignore how far the Windows API is implemented. ... MFC is a C++ API so you won't be able to stick with straight C ... No, really, read Petzold's Programming Windows. ...
    (comp.programming)
  • Re: C examples and codes
    ... try to see the tutorials that aren't crap... ... that it's not entirely a tutorial of standard C because it advertises "Windows C Programming". ... Standard C runs anywhere there is a standard C implementation. ...
    (comp.lang.c)
Loading