Assembly Programming Journals: Previous — 1 — 2 — 3 — 4 — 5 — 6 — 7 — 8 — 9 — Next
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::. July-Sep 99
:::\_____\::::::::::. Issue 5
::::::::::::::::::::::.........................................................
A S S E M B L Y P R O G R A M M I N G J O U R N A L
http://asmjournal.freeservers.com
asmjournal@mailcity.com
T A B L E O F C O N T E N T S
----------------------------------------------------------------------
Introduction...................................................mammon_
"COM in Assembly Part II"...................................Bill.Tyler
"How to use DirectDraw in ASM"...............................X-Calibre
"Writing Boot Sectors To Disk"...........................Jan.Verhoeven
"Dumping Memory to Disk".................................Jan.Verhoeven
"Formatted Numeric Output"..............................Laura.Fairhead
"Linked Lists in ASM"..........................................mammon_
Column: Win32 Assembly Programming
"Structured Exception Handling under Win32"...........Chris.Dragan
"Child Window Controls"...................................Iczelion
"Dialog Box as Main Window"...............................Iczelion
"Standardizing Win32 Callback Procedures"............Jeremy.Gordon
Column: The Unix World
"Fire Demo ported to Linux SVGAlib".................Jan.Wagemakers
Column: Assembly Language Snippets
"Abs".................................................Chris.Dragan
"Min".................................................Chris.Dragan
"Max".................................................Chris.Dragan
"OBJECT"...................................................mammon_
Column: Issue Solution
"Binary to ASCII"....................................Jan.Verhoeven
----------------------------------------------------------------------
++++++++++++++++++Issue Challenge+++++++++++++++++
Convert a bit value to ACIII less than 10 bytes
----------------------------------------------------------------------
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::..............................................INTRODUCTION
by mammon_
I suppose I should start with the good news. A week or so ago Hiroshimator
emailed me for the nth time asking if I needed help with the journal as I have
yet to get one out on time. I relented and asked if he knew any listservers;
one hour later he had an account for APJ set up at e-groups, specifically:
http://www.egroups.com/group/apj-announce
One of the greatest obstacles to putting out these issues -- processing the
300 or so subscription requests that rack up between issues -- is now out of
the way for good.
The articles this month have somewhat of a high-level focus; with the COM and
Direct Draw by Bill Tyler and X-Caliber, respectively, as well as Chris
Dragan's classic work on exception handling and Jeremy Gordon's treatment of
windows callbacks, this issue is heavily weighed towards high-level win32
coding. Add to this Iczelion's two tutorials and my own win32-biased
linked list example, and it appears the DOS/Unix camp is losing ground.
To shore up the Unix front line, Jan Wagemakers has provided a port of last
month's fire demo to linux [GAS]. In addition, there are A86 articles by Jan
Verhoeven and a general assembly routine by Laura Fairhead to prove that not
all assembly has to be 32-bit.
And, finally, I am looking for a good 'challenge' columnist: someone to write
the monthly APJ challenges [and their solutions] so that I can start
announcing next month's challenge sooner than next month...
Now at last I can sleep ;)
_m
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
COM in Assembly Part II
by Bill Tyler
My previous atricle described how to use COM objects in your assembly
language programs. It described only how to call COM methods, but not how to
create your own COM objects. This article will describe how to do that.
This article will describe implementing COM Objects, using MASM syntax. TASM
or NASM assemblers will not be considered, however the methods can be easily
applied to any assembler.
This article will also not describe some of the more advanced features of COM
such as reuse, threading, servers/clients, and so on. These will presented
in future articles.
COM Interfaces Review
------------------------------------------------------------------------------
An interface definition specifies the interface's methods, their return types,
the number and types of their parameters, and what the methods must do. Here
is a sample interface definition:
IInterface struct
lpVtbl dd ?
IInterface ends
IInterfaceVtbl struct
; IUnknown methods
STDMETHOD QueryInterface, :DWORD, :DWORD, :DWORD
STDMETHOD AddRef, :DWORD
STDMETHOD Release, :DWORD
; IInterface methods
STDMETHOD Method1, :DWORD
STDMETHOD Method2, :DWORD
IInterfaceVtbl ends
STDMETHOD is used to simplify the interface declaration, and is defined as:
STDMETHOD MACRO name, argl :VARARG
LOCAL @tmp_a
LOCAL @tmp_b
@tmp_a TYPEDEF PROTO argl
@tmp_b TYPEDEF PTR @tmp_a
name @tmp_b ?
ENDM
This macro is used to greatly simplify interface declarations, and so that the
MASM invoke syntax can be used. (Macro originally by Ewald :)
Access to the interface's methods occurs through a pointer. This pointer
points to a table of function pointers, called a vtable. Here is a sample
method call:
mov eax, [lpif] ; lpif is the interface pointer
mov eax, [eax] ; get the address of the vtable
invoke (IInterfaceVtbl [eax]).Method1, [lpif] ; indirect call to the function
- or -
invoke [eax][IInterfaceVtbl.Method2], [lpif] ; alternate notation
Two different styles of addressing the members are shown. Both notations
produce equivalent code, so the method used is a matter of personal
preference.
All interfaces must inherit from the IUnknown interface. This means that the
first 3 methods of the vtable must be QueryInterface, AddRef, and Release.
The purpose and implementation of these methods will be discussed later.
GUIDS
------------------------------------------------------------------------------
A GUID is a Globally Unique ID. A GUID is a 16-byte number, that is unique
to an interface. COM uses GUID's to identify different interfaces from one
another. Using this method prevents name clashing as well as version
clashing. To get a GUID, you use a generator utility that is included with
most win32 development packages.
A GUID is represented by the following structure:
GUID STRUCT
Data1 dd ?
Data2 dw ?
Data3 dw ?
Data4 db 8 dup(?)
GUID ENDS
A GUID is then defined in the data section:
MyGUID GUID <3F2504E0h, 4f89h, 11D3h, <9Ah, 0C3h, 0h, 0h, 0E8h, 2Ch, 3h, 1h>>
Once a GUID is assigned to an interface and published, no furthur changes to
the interface definition are allowed. Note, that this does mean that the
interface implementation may not change, only the definition. For changes
to the interface definition, a new GUID must be assigned.
COM Objects
------------------------------------------------------------------------------
A COM object is simply an implementation of an interface. Implementation
details are not covered by the COM standard, so we are free to implement our
objects as we choose, so long as they satisfy all the requirements of the
interface definition.
A typical object will contain pointers to the various interfaces it supports,
a reference count, and any other data that the object needs. Here is a sample
object definition, implemented as a structure:
Object struct
interface IInterface <?> ; pointer to an IInterface
nRefCount dd ? ; reference count
nValue dd ? ; private object data
Object ends
We also have to define the vtable's we are going to be using. These tables
must be static, and cannot change during run-time. Each member of the vtable
is a pointer to a method. Following is a method for defining the vtable.
@@IInterface segment dword
vtblIInterface:
dd offset IInterface@QueryInterface
dd offset IInterface@AddRef
dd offset IInterface@Release
dd offset IInterface@GetValue
dd offset IInterface@SetValue
@@IInterface ends
Reference Counting
------------------------------------------------------------------------------
COM object manage their lifetimes through reference counting. Each object
maintains a reference count that keeps track of how many instances of the
interface pointer have been created. The object is required to keep a
counter that supports 2^32 instances, meaning the reference count must be a
DWORD.
When the reference count drops to zero, the object is no longer in use, and
it destroys itself. The 2 IUnknown methods AddRef and Release handle the
reference counting for a COM object.
QueryInterface
------------------------------------------------------------------------------
The QueryInterface method is used by a COM object to determine if the object
supports a given interface, and then if supported, to get the interface
pointer. There are 3 rules to implementing the QueryInterface method:
1. Objects must have an identity - a call to QueryInterface must always
return the same pointer value.
2. The set of interfaces of an object must never change - for example, if
a call to QueryInterface with on IID succeeds once, it must succeed
always. Likewise, if it fails once, it must fail always.
3. It must be possible to successfully query an interface of an object
from any other interface.
QueryInterface returns a pointer to a specified interface on an object to
which a client currently holds an interface pointer. This function must call
the AddRef method on the pointer it returns.
Following are the QueryInterface parameters:
pif : [in] a pointer to the calling interface
riid : [in] pointer to the IID of the interface being queried
ppv : [out] pointer to the pointer of the interface that is to be set.
If the interface is not supported, the pointed to value is set to 0
QueryInterface returns the following:
S_OK if the interface is supported
E_NOINTERFACE if not supported
Here is a simple assembly implementation of QueryInterface:
IInterface@QueryInterface proc uses ebx pif:DWORD, riid:DWORD, ppv:DWORD
; The following compares the requested IID with the available ones.
; In this case, because IInterface inherits from IUnknown, the IInterface
; interface is prefixed with the IUnknown methods, and these 2 interfaces
; share the same interface pointer.
invoke IsEqualGUID, [riid], addr IID_IInterface
or eax,eax
jnz @1
invoke IsEqualGUID, [riid], addr IID_IUnknown
or eax,eax
jnz @1
jmp @NoInterface
@1:
; GETOBJECTPOINTER is a macro that will put the object pointer into eax,
; when given the name of the object, the name of the interface, and the
; interface pointer.
GETOBJECTPOINTER Object, interface, pif
; now get the pointer to the requested interface
lea eax, (Object ptr [eax]).interface
; set *ppv with this interface pointer
mov ebx, [ppv]
mov dword ptr [ebx], eax
; increment the reference count by calling AddRef
GETOBJECTPOINTER Object, interface, pif
mov eax, (Object ptr [eax]).interface
invoke (IInterfaceVtbl ptr [eax]).AddRef, pif
; return S_OK
mov eax, S_OK
jmp return
@NoInterface:
; interface not supported, so set *ppv to zero
mov eax, [ppv]
mov dword ptr [eax], 0
; return E_NOINTERFACE
mov eax, E_NOINTERFACE
return:
ret
IInterface@QueryInterface endp
AddRef
------------------------------------------------------------------------------
The AddRef method is used to increment the reference count for an interface
of an object. It should be called for every new copy of an interface pointer
to an object.
AddRef takes no parameters, other than the interface pointer required for all
methods. AddRef should return the new reference count. However, this value
is to be used by callers only for testing purposes, as it may be unstable in
certain situations.
Following is a simple implementation of the AddRef method:
IInterface@AddRef proc pif:DWORD
GETOBJECTPOINTER Object, interface, pif
; increment the reference count
inc [(Object ptr [eax]).nRefCount]
; now return the count
mov eax, [(Object ptr [eax]).nRefCount]
ret
IInterface@AddRef endp
Release
------------------------------------------------------------------------------
Release decrements the reference count for the calling interface on a object.
If the reference count on the object is decrememnted to 0, then the object is
freed from memory. This function should be called when you no longer need to
use an interface pointer
Like AddRef, Release takes only one parameter - the interface pointer. It
also returns the current value of the reference count, which, similarly, is to
be used for testing purposess only
Here is a simple implementation of Release:
IInterface@Release proc pif:DWORD
GETOBJECTPOINTER Object, interface, pif
; decrement the reference count
dec [(Object ptr [eax]).nRefCount]
; check to see if the reference count is zero. If it is, then destroy
; the object.
mov eax, [(Object ptr [eax]).nRefCount]
or eax, eax
jnz @1
; free the object: here we have assumed the object was allocated with
; LocalAlloc and with LMEM_FIXED option
GETOBJECTPOINTER Object, interface, pif
invoke LocalFree, eax
@1:
ret
IInterface@Release endp
Creating a COM object
------------------------------------------------------------------------------
Creating an object consists basically of allocating the memory for the
object, and then initializing its data members. Typically, the vtable
pointer is initialized and the reference count is zeroed. QueryInterface
could then be called to get the interface pointer.
Other methods exist for creating objects, such as using CoCreateInstance, and
using class factories. These methods will not be discussed, and may be a
topic for a future article.
COM implementatiion sample application
------------------------------------------------------------------------------
Here follows a sample implementation and usage of a COM object. It shows how
to create the object, call its methods, then free it. It would probably be
very educational to assemble this and run it through a debugger. This and
other examples can be found at http://asm.tsx.org.
.386
.model flat,stdcall
include windows.inc
include kernel32.inc
include user32.inc
includelib kernel32.lib
includelib user32.lib
includelib uuid.lib
;-----------------------------------------------------------------------------
; Macro to simply interface declarations
; Borrowed from Ewald, http://here.is/diamond/
STDMETHOD MACRO name, argl :VARARG
LOCAL @tmp_a
LOCAL @tmp_b
@tmp_a TYPEDEF PROTO argl
@tmp_b TYPEDEF PTR @tmp_a
name @tmp_b ?
ENDM
; Macro that takes an interface pointer and returns the implementation
; pointer in eax
GETOBJECTPOINTER MACRO Object, Interface, pif
mov eax, pif
IF (Object.Interface)
sub eax, Object.Interface
ENDIF
ENDM
;-----------------------------------------------------------------------------
IInterface@QueryInterface proto :DWORD, :DWORD, :DWORD
IInterface@AddRef proto :DWORD
IInterface@Release proto :DWORD
IInterface@Get proto :DWORD
IInterface@Set proto :DWORD, :DWORD
CreateObject proto :DWORD
IsEqualGUID proto :DWORD, :DWORD
externdef IID_IUnknown:GUID
;-----------------------------------------------------------------------------
; declare the interface prototype
IInterface struct
lpVtbl dd ?
IInterface ends
IInterfaceVtbl struct
; IUnknown methods
STDMETHOD QueryInterface, pif:DWORD, riid:DWORD, ppv:DWORD
STDMETHOD AddRef, pif:DWORD
STDMETHOD Release, pif:DWORD
; IInterface methods
STDMETHOD GetValue, pif:DWORD
STDMETHOD SetValue, pif:DWORD, val:DWORD
IInterfaceVtbl ends
; declare the object structure
Object struct
; interface object
interface IInterface <?>
; object data
nRefCount dd ?
nValue dd ?
Object ends
;-----------------------------------------------------------------------------
.data
; define the vtable
@@IInterface segment dword
vtblIInterface:
dd offset IInterface@QueryInterface
dd offset IInterface@AddRef
dd offset IInterface@Release
dd offset IInterface@GetValue
dd offset IInterface@SetValue
@@IInterface ends
; define the interface's IID
; {CF2504E0-4F89-11d3-9AC3-0000E82C0301}
IID_IInterface GUID <0cf2504e0h, 04f89h, 011d3h, <09ah, 0c3h, 00h, 00h,
0e8h, 02ch, 03h, 01h>>
;-----------------------------------------------------------------------------
.code
start:
StartProc proc
LOCAL pif:DWORD ; interface pointer
; create the object
invoke CreateObject, addr [pif]
or eax,eax
js exit
; call the SetValue method
mov eax, [pif]
mov eax, [eax]
invoke (IInterfaceVtbl ptr [eax]).SetValue, [pif], 12345h
; call the GetValue method
mov eax, [pif]
mov eax, [eax]
invoke (IInterfaceVtbl ptr [eax]).GetValue, [pif]
; release the object
mov eax, [pif]
mov eax, [eax]
invoke (IInterfaceVtbl ptr [eax]).Release, [pif]
exit:
ret
StartProc endp
;-----------------------------------------------------------------------------
IInterface@QueryInterface proc uses ebx pif:DWORD, riid:DWORD, ppv:DWORD
invoke IsEqualGUID, [riid], addr IID_IInterface
test eax,eax
jnz @F
invoke IsEqualGUID, [riid], addr IID_IUnknown
test eax,eax
jnz @F
jmp @Error
@@:
GETOBJECTPOINTER Object, interface, pif
lea eax, (Object ptr [eax]).interface
; set *ppv
mov ebx, [ppv]
mov dword ptr [ebx], eax
; increment the reference count
GETOBJECTPOINTER Object, interface, pif
mov eax, (Object ptr [eax]).interface
invoke (IInterfaceVtbl ptr [eax]).AddRef, [pif]
; return S_OK
mov eax, S_OK
jmp return
@Error:
; error, interface not supported
mov eax, [ppv]
mov dword ptr [eax], 0
mov eax, E_NOINTERFACE
return:
ret
IInterface@QueryInterface endp
IInterface@AddRef proc pif:DWORD
GETOBJECTPOINTER Object, interface, pif
inc [(Object ptr [eax]).nRefCount]
mov eax, [(Object ptr [eax]).nRefCount]
ret
IInterface@AddRef endp
IInterface@Release proc pif:DWORD
GETOBJECTPOINTER Object, interface, pif
dec [(Object ptr [eax]).nRefCount]
mov eax, [(Object ptr [eax]).nRefCount]
or eax, eax
jnz @1
; free object
mov eax, [pif]
mov eax, [eax]
invoke LocalFree, eax
@1:
ret
IInterface@Release endp
IInterface@GetValue proc pif:DWORD
GETOBJECTPOINTER Object, interface, pif
mov eax, (Object ptr [eax]).nValue
ret
IInterface@GetValue endp
IInterface@SetValue proc uses ebx pif:DWORD, val:DWORD
GETOBJECTPOINTER Object, interface, pif
mov ebx, eax
mov eax, [val]
mov (Object ptr [ebx]).nValue, eax
ret
IInterface@SetValue endp
;-----------------------------------------------------------------------------
CreateObject proc uses ebx ecx pobj:DWORD
; set *ppv to 0
mov eax, pobj
mov dword ptr [eax], 0
; allocate object
invoke LocalAlloc, LMEM_FIXED, sizeof Object
or eax, eax
jnz @1
; alloc failed, so return
mov eax, E_OUTOFMEMORY
jmp return
@1:
mov ebx, eax
mov (Object ptr [ebx]).interface.lpVtbl, offset vtblIInterface
mov (Object ptr [ebx]).nRefCount, 0
mov (Object ptr [ebx]).nValue, 0
; Query the interface
lea ecx, (Object ptr [ebx]).interface
mov eax, (Object ptr [ebx]).interface.lpVtbl
invoke (IInterfaceVtbl ptr [eax]).QueryInterface,
ecx,
addr IID_IInterface,
[pobj]
cmp eax, S_OK
je return
; error in QueryInterface, so free memory
push eax
invoke LocalFree, ebx
pop eax
return:
ret
CreateObject endp
;-----------------------------------------------------------------------------
IsEqualGUID proc rguid1:DWORD, rguid2:DWORD
cld
mov esi, [rguid1]
mov edi, [rguid2]
mov ecx, sizeof GUID / 4
repe cmpsd
xor eax, eax
or ecx, ecx
setz al
ret
IsEqualGUID endp
end start
Conclusion
------------------------------------------------------------------------------
We have (hopefully) seen how to implement a COM object. We can see that it
is a bit messy to do, and adds quite some overhead to our programs. However,
it can also add great flexibility and power to our programs.
Remember that COM defines only interfaces, and implementation is left to the
programmer. This article presents only one possible implementation. This is
not the only method, nor is it the best one. The reader should feel free to
experiment with other methods.
Copyright (C) 1999 Bill Tyler (billasm@usa.net)
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::..........................................FEATURE.ARTICLE
How to use DirectDraw in ASM
by X-Calibre [Diamond]
Well, there has been quite a large demand for this essay, so I finally started
writing it. This essay will show you how to use C++ objects and COM interface
in Win32ASM, using DirectDraw as an example.
Well, in this part of the Win32 API, you will soon find out how important it
is to know C and C++ when you want to use an API written in these languages.
Judging from the demand for this essay, I think it will be necessary to
explain a bit of how objects work in C++. I will not go too deep, but only
show the things you need to know in Win32ASM.
What are objects really?
Actually a structure is an object of which all fields are public. We will look
at it the other way around. So the public fields in an object make up a
structure. The other fields in an object are private and are not reachable
from the outside. So they are not interesting to us.
A special thing about objects is that they can contain pointers to functions.
Normally, when using C or ASM, this would be possible, but a bit error-prone.
It can be seen as 'dirty' programming. That's why you probably haven't seen it
before.
When using C++ with a compiler, there will be no errors, as long as the
compiler does its job. So here you can use this technique with no chance of
errors, and it gives you some nice new programming options.
C++ goes even further with this 'structure of functions' idea. With
inheritance, you can also overwrite functions of the base class in the
inherited class. You can also create 'virtual' functions, which are defined in
the base class, but the actual code is only in inherited classes.
This is of course interesting for DirectX, where you want to have standard
functions, but with different code, depending on the hardware on which it is
running. So in DirectX, all functions are defined as virtual, and the base
class is inherited by hardware-specific drivers which supply hardware-specific
code. And the beauty of this is, that it's all transparent to the programmer.
The function pointers can change at runtime because of this system, so the C++
designers had to think of a way to keep the pointers to the functions
available to the program at all time.
What this all boils down to is that there is a table with pointers to the
functions. It's called the Virtual Function Table. I will call this the
vtable from now on.
So we need to get this table, in order to call functions from our object.
Lucky for you, Z-Nith has already made a C program to 'capture' the table,
and converted the resulting header file to an include file for use with MASM.
So I'll just explain how you should use this table, and you can get going
soon.
Well, actually it's quite simple. The DirectX objects are defined like this:
IDirectDraw STRUC
lpVtbl DWORD ?
IDirectDraw ENDS
IDirectDrawPalette STRUC
lpVtbl DWORD ?
IDirectDrawPalette ENDS
IDirectDrawClipper STRUC
lpVtbl DWORD ?
IDirectDrawClipper ENDS
IDirectDrawSurface STRUC
lpVtbl DWORD ?
IDirectDrawSurface ENDS
So these structs are actually just a pointer to the vtables, and don't contain
any other values. Well, this makes it all very easy for us then.
I'll give you a small example:
Say we have an IDirectDraw object called lpDD. And we want to call the
RestoreDisplayMode function.
Then we need to do 2 things:
1. Get the vtable.
2. Get the address of the function, using the vtable.
The first part is simple. All the struct contains, is the pointer to the
vtable. So we can just do this:
mov eax, [lpDD]
mov eax, [eax]
Simple, isn't it? And the next part isn't really much harder. The vtable is
put into a structure called IDirectDrawVtbl in DDRAW.INC. We now have the
address of the structure in eax. All we have to do now, is get the correct
member of that structure, to get the address of the function we want to call.
You would have guessed by now, that this will do the trick:
call [IDirectDrawVtbl.RestoreDisplayMode][eax]
That is not a bad guess...
But there's one more thing, which is very important: this function needs to be
invoked on the IDirectDraw object. We may only see the vtable in the structure,
but there are also private members inside the object. So there's more than
meets the eye here. What it comes down to is that the call needs the object
as an argument. And this will be done by stack as always. So we just need to
push lpDD before we call. The complete call will look like this:
push [lpDD]
call [IDirectDrawVtbl.RestoreDisplayMode][eax]
Simple, was it not? And calls with arguments are not much harder.
Let's set the displaymode to 320x200 in 32 bits next.
This call requires 3 arguments:
SetDisplayMode( width, height, bpp );
Well, the extra arguments work just like normal API calls: just push them onto
the stack in backward order.
So it will look like this:
push 32
push 200
push 320
mov eax, [lpDD]
push eax
mov eax, [eax]
call [IDirectDrawVtbl.SetDisplayMode][eax]
And that's all there is to it.
To make life easier, we have included some MASM macros in DDRAW.INC, for use
with the IDirectDraw and IDirectDrawSurface objects:
DDINVOKE MACRO func, this, arglist :VARARG
mov eax, [this]
mov eax, [eax]
IFB <arglist>
INVOKE [IDirectDrawVtbl. func][eax], this
ELSE
INVOKE [IDirectDrawVtbl. func][eax], this, arglist
ENDIF
ENDM
DDSINVOKE MACRO func, this, arglist :VARARG
mov eax, [this]
mov eax, [eax]
IFB <arglist>
INVOKE [IDirectDrawSurfaceVtbl. func][eax], this
ELSE
INVOKE [IDirectDrawSurfaceVtbl. func][eax], this, arglist
ENDIF
ENDM
With these macros, our 2 example calls will look as simple as this:
DDINVOKE RestoreDisplayMode, lpDD
DDINVOKE SetDisplayMode, lpDD, 320, 200, 32
Well, that's basically all there is to know about using objects, COM and
DirectX in Win32ASM. Have fun with it!
And remember:
C and C++ knowledge is power!
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Writing Boot Sectors To Disk
by Jan Verhoeven
Introduction.
-------------
In my previous article I showed how to make a private non-bootable
bootsector for 1.44 Mb floppy disks. Unfortunately, there was no way yet to
write that non-bootsector to a floppy disk....
Enter this code. It is the accompanying bootsector writer for floppy disks.
It assumes that your A: drive is the 1.44 Mb floppy disk drive and I dare
say that this will be true in the majority of cases.
The assembler used
------------------
As usual, I have written this code in A86 format. Until now, not many
aspects of the A86 extensions have been used, but, believe me, in future
articles this will be done.
A86 is particularly useful for people that make syntax errors. It will
insert the errormessages into the sourcefile so that you can easily find
them back. In the next assembler run the error messages are removed again.
To fully use this aspect of A86 programming, I made a small batchfile that
will let me choose between several options while writing the code. Below
you can see the file. After an error, I choose to go back into the editor.
When there are no errors, I might decided to do a trial run. Or to quit to
DOS.
This is all done by means of the WACHT command which waits for a keypress.
It returns (in errorlevel) the indexed position in the command tail table
of th key which was pressed.
Rapid assembly prototyping.
---------------------------
For easy processing and running sourcefiles I use a small batchfile, which
looks like:
----------- Run.Bat --------------------------------------- Start ---------
@echo off
if "%1" == "" goto leave
:start
ed %1.a86
a86 %1.a86 %2 %3 %4 %5 %6
:menu
Echo *
Echo Options:
Echo *Escape = stop
Echo * L = LIST
echo * ;-() = back to the editor
echo * space = test-run of %1.com
echo *Period = debugger-run with %1.com/sym
wacht ≥ .\=-[]';-()/":?><{}|+_LCE
if errorlevel 27 goto start
if errorlevel 26 goto screen
if errorlevel 25 goto list
if errorlevel 4 goto start
if errorlevel 3 goto debugger
if errorlevel 2 goto execute
if errorlevel 1 exit
goto menu
:execute
%1
if errorlevel 9 echo Errorlevel = 9+
if errorlevel 8 echo Errorlevel = 8
if errorlevel 7 echo Errorlevel = 7
if errorlevel 6 echo Errorlevel = 6
if errorlevel 5 echo Errorlevel = 5
if errorlevel 4 echo Errorlevel = 4
if errorlevel 3 echo Errorlevel = 3
if errorlevel 2 echo Errorlevel = 2
if errorlevel 1 echo Errorlevel = 1
goto menu
:debugger
vgamode 3
d86 %1
goto menu
:list
list
goto menu
:screen
vgamode 3
goto menu
:leave
echo No file specified
----------- Run.Bat ---------------------------------------- End ----------
This BAT file relies heavily on my computer system. For one, I use DR-DOS 6
which means that I can use the EXIT word to get out of a Batchfile.
Also, I switch videomodes back to Mode 3 with "Vgamode 3" and you will have
to use another command for that, like "Mode co80" or using the utillity
that came with your videocard.
The program "List" is Vernon Buerg's file lister which I use to track down
errors in all kinds of files.
How to write a sector to disk.
------------------------------
Globally there are three methods. The first would be to program the floppy
disk controller, but that is just downright difficult. A second approach
would be to use INT 026, the way DOS does things.
I chose for the BIOS method. For non-partitioned diskstructures this is the
easiest way. Just select track, head and side and write data to the sectors
on that disk.
The bootsector is the very first sector on a disk. For a floppy disk this
boils down to track 0, head 0 and sector 1 (sectors are counted from 1, not
from 0!).
The code is very straightforward. What it does is:
- reset disk drive controller
- open the file to transfer to the bootsector
- read file into internal buffer
- close the file
- repeat 5 times:
- try to tranfer buffer to bootsector of drive A:
- shut down and return to DOS.
- if an error occurs, the user is informed about it.
That's all there's to it.
The Source.
-----------
Below is the sourcecode for this short utillity. I have commented just
about any line I thought fit for it.
----------- Wrs.A86 --------------------------------------- Start ---------
name wrs
title WRite Sector
page 80, 120
stdout = 1 ; the "standard" equates
lf = 10
cr = 13
DATA segment ; define the volatile data area
buffer db 512 dup (?) ; this is enough for one sector
EVEN ; make sure WORD starts at an even address
Handle dw ? ; handle number of file to write
; ----------------------
CODE segment ; start of the actualk code
; no ORG, so we start at offset 0100
jmp main ; jump forward to entry point
db 'VeRsIoN=0.2', 0
db 'CoPyRiGhT=CopyLeft 1999, Jan Verhoeven, '
db 'jverhoeven@bigfoot.com', 0
; ----------------------
filename db 'BootLoad.bin', 0 ; name of file to send to disk
Mess001 db 'Cannot open file BootLoad.bin. '
db 'Operation aborted.', cr, lf
Len001 = $ - Mess001
Mess002 db 'Something went wrong while writing to disk.', cr, lf
Len002 = $ - Mess002
Mess003 db 'The floppy disk subsytem reported an error. '
db 'Trying once more.', cr, lf
Len003 = $ - Mess003
Mess004 db cr, lf, 'Bootsector written. '
db 'Thank you for using this software.'
db cr, lf, 'This program is GNU GPL free software and you use '
db 'it at your won risk.'
db cr, lf, 'Please study the GNU '
db 'General Public License for more details.', cr, lf
Len004 = $ - Mess004
; ----------------------
Error1: mov dx, offset mess001 ; process "cannot open file"
mov cx, len001
mov bx, stdout
mov ah, 040
int 021 ; print via DOS
mov ax, 04C01 ; exit with errorcode = 1
int 021
; ----------------------
Error2: mov dx, offset mess002 ; process "disk error"
mov cx, len002
mov bx, stdout
mov ah, 040
int 021 ; via DOS
mov ax, 04C02 ; exit with errorcode = 2
int 021
; ----------------------
Error2a: push ax, bx, cx, dx ; process "Disk not ready"
mov dx, offset mess003 ; point to message
mov cx, len003 ; this many bytes
mov bx, stdout ; to the console
mov ah, 040 ; do a write
int 021 ; via DOS
pop dx, cx, bx, ax ; restore state of machine
ret ; and return to caller
; ----------------------
main: mov dl, 0 ; choose drive A:
mov ah, 0 ; select funtion 0 ...
int 013 ; ... reset diskdrives
mov dx, offset filename ; point to name of file
mov ax, 03D00 ; to open
int 021 ; via DOS
jc Error1 ; if error, take action
mov [Handle], ax ; no error, => ax = handle
mov dx, offset buffer ; setup pointer, ...
mov cx, 512 ; ... byte count, ...
mov bx, ax ; ... and handle
mov ah, 03F ; to read data from file
int 021 ; via DOS
mov bx, [Handle]
mov ah, 03E
int 021 ; close this file
mov cx, 5 ; prepare for a five times LOOP
L0: push cx
mov bx, offset buffer
mov es, ds ; es:bx = buffer to read from
mov dx, 0000 ; drive A:, head 0
mov cx, 0001 ; Track 0, Sector 1
mov ax, 0301 ; Write sectors, 1 sector
int 013 ; via BIOS
jnc >L1 ; if no error, jump forward
pop cx ; Houston, we have an error!
call error2a ; inform the user
loop L0 ; and try again
jc error2 ; after five times still no go....
L1: mov dx, offset Mess004 ; Signal that we're successful
mov cx, Len004
mov bx, stdout ; to the console
mov ah, 040
int 021 ; via DOS (so it can be redirected)
mov ax, 04C00 ; mention that there were no errors
int 021 ; and return to DOS
----------- Wrs.A86 ---------------------------------------- End ----------
Have fun experimenting with bootsectors. But take care that this will NOT
work on a hard disk.
Hard disk structure.
--------------------
A hard disk uses another layout for it's structure. The very first sector
of a HDD is the MBR (Master BootRecord). It is the only sensible sector in
the first track of a normal HDD. The rest is just empty.
Each partition starts at a cylinder boundary, so the first one starts at
cylinder 1 (track 1, side 0, sector 1). The very first sector of a bootable
partition is the bootsector.
The MBR contains the partition table, indicating where partitions start and
end and whether they are bootable or not. Plus some code to interpret that
table and to find the bootsector that was selected.
If you write a floppy disk bootsector to the very first sector of a HDD,
you wipe out the MBR and hence make inaccesable all data on that disk. The
data will still be there, but the system will not be able anymore to find
or use it.
So please take care that this software is NOT used for drive (DL=) 080.
jverhoeven@bigfoot.com
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Dumping Memory To Disk
by Jan Verhoeven
This piece of code allows you to make a memory dump of any region of
conventional memory (i.e. below 1 Mb) to a diskfile.
The program itself.
-------------------
The source is documented so it speaks for itself. At points of
interest I have insterted "break" and "restart" lines with space for
additional remarks.
So just read the source and read the remarks. This way, the text is
where the code is, and you don't need to go back and forth in the
text. I think this will easier to read than explanation afterwards.
--- Mem2File ------------------------------------------------- Start ---
name mem2file
title Send an area of memory to a diskfile.
page 80, 120
; version 1.0 : Had to be compiled for each area/filename OK: 01-01-1991
; version 1.1 : Same as above, for A86 format OK: 01-01-1999
; version 1.2 : Make it commandline driven OK: 01-02-1999
; version 1.3 : Make it reliable OK: 02-02-1999
; ----------------------
stdout = 1
tab = 9
lf = 10
cr = 13
clr MACRO ; macro called CLeaR
mov #1, 0 ; move it with zero
#EM ; and get outa here
Dum1 STRUC ; a structure definition
OffVal dw ?
SegVal dw ?
ENDS
; ----------------------
DATA segment ; this is where the volatile data lives
ByteF = $
dummy db ? ; just to fool D86....
; if this dummy variable is not here, D86 will
; reference variable "Start" as "ByteF".
even
Start dw ?, ? ; segment:address to start
Stop dw ?, ? ; segment:address to stop
Blocks dw ? ; number of 16K chucks to save
Rest dw ? ; remaining part to save
ArgNum dw ? ; nr of bytes in this argument
OldClp dw ? ; current pointer into command line
Handle dw ?
Length dw ?, ?
FileName: ; this storage is used twice....
Argument db 80 dup (?) ; storage for next argument from command-line
Output db 16K dup (?) ; buffered output
--- Mem2File ------------------------------------------------- Break ---
An A86 enhancement: if you need 16K elements of data, just ask for it.
No need to remember that 16 Kb is 16.384 bytes. The "K" will do.
No big deal, just a nice feature.
Also, if you need to process large binary numbers you may group them
into sub-units separated by underscores. So the number:
1000100100111101
is hard to read back. But if we insert "_" markers like:
1000_1001_0011_1101
the grouping of bits makes them easier to understand. Not that it is a
matter of life and death, but it can come in handy once in a while.
--- Mem2File ------------------------------------------------ Restart --
Bytes = $ - ByteF ; number of volatile databytes
; ----------------------
CODE segment ; no ORG, so we start at 0100
jmp main
HexTable db '0123456789ABCDEF', 0
db 'VeRsIoN=Mem2File 1.3', 0
db 'CoPyRiGhT=CopyLeft Jan Verhoeven, jverhoeven@bigfoot.com', 0
Mess001 db 'Mem2File collects a part of conventional memory and '
db 'sends it to a file.', cr, lf, lf
db 'The syntax is:', cr, lf, lf
db tab, 'Mem2File segm1:offs1 [-] segm2:offs2 '
db '<path>file.ext.', cr, lf, lf
db 'Mem2File is GNU GPL style FREE software. ', cr, lf
db 'Please read the GNU GPL if you are in doubt.', cr, lf, lf
Mess002 db 'Mem2File was made by Jan Verhoeven, NL-5012 GH 272, '
db 'The Netherlands', cr, lf
db 'E-mail address : jverhoeven@bigfoot.com', cr, lf, lf
Len001 = $ - Mess001
Len002 = $ - Mess002
Mess004 db 7, 'Error! All numbers are expected to be hexadecimal.'
db cr, lf
Len004 = $ - Mess004
;------------------------
InitMem: mov di, ByteF ; Init volatile memory with zero's.
mov cx, Bytes ; saves a lot of strange problems.
mov al, 0
rep stosb
ret
;------------------------
--- Mem2File ------------------------------------------------- Break ---
I use volatile data to store data that does not need initialising. This
saves a lot of diskspace and it loads a lot faster. Drawback of volatile
data can be that any rubbish left there by other programs can make your
software go berzerk if you yourself forget to initialise the data.
Therefore I -always- prime the volatile data memory with zero's. Just to
have a well defined starting position.
It should not be necessary, but, on the other hand, how much overhead
and extra execution time is such an initialisation routine?
--- Mem2File ------------------------------------------------ Restart --
L0: mov b [di], 0 ; terminate argument string
mov [OldClp], si ; done, => clean up.
clc ; indicate "No Error"
L3: pop di, si, ax ; restore registers, ...
ret ; ... and leave.
GetArg: push ax, si, di ; get next argument from command-line in ASCIIZ
format
mov si, [OldClp] ; now, where did we leave last time?
cmp si, 0 ; Have we ever used this routine?
IF E mov si, 081 ; if not, prime SI, ...
mov di, offset Argument ; ... DI and ...
mov [ArgNum], 0 ; ... nr of chars in argument.
L1: lodsb ; get byte
cmp al, ' ' ; skip over spaces, ...
je L1
cmp al, tab ; ... and tabs.
je L1
cmp al, 1 ; ONLY if AL is 0, we get a carry
jc L3 ; if CARRY, we're done
--- Mem2File ------------------------------------------------- Break ---
This construction is what I particularly like. I want to check if AL is
Zero. Normally you can code
cmp al, 0
jz L3
but L3 is the error-exit and needs the carrybit to be set as an error
flag. Normally you would enter a
stc
instruction to fullfill the specification. But that is poor programming.
It is better to let the software do this for us.
AL can have any value between 020 and 0FF, plus 00, tab, lf and cr. 01
is not an option. So the sequence
cmp al, 1 ; ONLY if AL is 0, we get a carry
jc L3 ; if CARRY, we're done
will send us to the errorexit WITH the carryflag set, all in one,
without explicitly having to set the carry flag.
--- Mem2File ------------------------------------------------ Restart --
L2: stosb ; else store char in Arguments array
inc [ArgNum] ; adjust counter
lodsb ; and get next char
cmp al, ' ' ; is it a delimiting space?
je L0
cmp al, tab ; or a tab?
je L0
cmp al, ':' ; or a colon?
je L0
cmp al, 0 ; or an end-of-line?
jne L2 ; if not, loop back,
mov si, 0FFFF ; else make SI ridiculously high, ...
stc ; ... set carry flag, ...
jmp L0 ; and get out.
--- Mem2File ------------------------------------------------- Break ---
Ok, ok, ok. I was influenced to make this function by a compiler. No, it
wasn't C. It was Modula-2.
GetArg (if necessary A86 can operate in a case sensitive mode!) extracts
the next argument from the command tail. It puts it in a seperate buffer
at address "Arument" which can hold 80 bytes. Shoyuld be more than
enough for one word or expression.
--- Mem2File ------------------------------------------------ Restart --
;------------------------
L1: stc ; byte not in table!
pop dx ; we came here with carry set!
ret ; exit
L2: sub bx, dx ; calculate position in table
pop dx
clc ; make sure carry is cleared
ret
--- Mem2File ------------------------------------------------- Break ---
This is a typical A86 construction. The subroutine is called TableFind
and it starts in the next line and ends in the previous one!
This is done to have the local labels declared for when they are needed
in the main functionbody. All jumps are "backward". For the CPU there's
no big influence, but for the assembler there is. No guessing about
labels.
--- Mem2File ------------------------------------------------ Restart --
TableFind: ; find AL in ASCIIZ table [BX] ...
push dx ; ... and report position
mov dx, bx ; keep value of SI
L0: cmp b [bx], 0 ; is it end of table?
je L1 ; if so, jump out
cmp al, [bx] ; compare byte with table
je L2 ; if same, jump out
inc bx ; else increment pointer
jmp L0 ; and loop back
;------------------------
MakeUpper:
cmp al, 'a' ; too low?
jb ret
--- Mem2File ------------------------------------------------- Break ---
An A86 enhancement: a conditional return instruction. All sensible CPU's
have conditional CALL and RET instructions. Not the 80x86 line. This CPU
was meant to be structured.
So you have to put a conditional jump before the call, and introduce yet
another silly labelname for the next instruction.
The "Jcc ret" is a good way to circumvent this ommission. What it
does is the same as what, on a Z-80, would be done with a "RET cc"
instruction.
There is one catch, however: there must be a RET instruction within
reach PRIOR to the "Jcc Ret" (internal) macro.
If that is a problem, you could also use the line:
IF cc Ret
So either way you, the programmer, win.
--- Mem2File ------------------------------------------------ Restart --
cmp al, 'z' ; if in range, ...
ja ret
and al, not bit 5 ; ... make uppercase
--- Mem2File ------------------------------------------------- Break ---
A86 is very programmer-oriented and allows us to write down what and how
we think. So if I need to set bit 0 of register Ax, I will simply write
or ax, bit 0
Any value between 0 and 15 is valid in A86 (0 - 31 for A386) to refer to
the respective bit in the respective source.
--- Mem2File ------------------------------------------------ Restart --
ret
;------------------------
BadNumber: ; hey typo, you made a dumbo!
mov dx, offset Mess004
mov cx, Len004
mov bx, StdOut
mov ah, 040
int 021
mov ax, 04C02 ; and exit with errorcode 2
int 021
;------------------------
SyntErr: mov dx, offset Mess001
mov cx, Len001
mov bx, StdOut
mov ah, 040 ; print out "help" screen and ...
int 021
mov ax, 04C01 ; ... exit with errorcode 1
int 021
;------------------------
L8: mov ax, dx ; Convert has result in DX, that's why.
pop dx, bx
ret
Convert: push bx, dx ; convert ASCII to Hex.
mov si, offset Argument
clr dx ; dx will contain result
--- Mem2File ------------------------------------------------- Break ---
Here the macro is invoked. It is used to load the DX register with
zero. If later you decide to change the way in which you want to clear
registers, just change the macro.
In LST files (the assembler listings) the expansions are controlled by
means of the +L switch. If you issue the option "+L35" macro's will not
be expanded in the listings file.
--- Mem2File ------------------------------------------------ Restart --
L1: lodsb ; get first character
cmp al, 0 ; end of string?
je L8
call MakeUpper ; if not, make uppercase
mov bx, offset HexTable
call TableFind ; and lookup in table
jc BadNumber
shl dx, 4 ; multiply DX by 16
--- Mem2File ------------------------------------------------- Break ---
This is another A86 goody. I coded a "SHL DX, 4" instruction, although
I do not know what the target processor will be.
No problem with A86. It will find out with which CPU you are assembling
and use that. If your CPU supports this function, it is implemented as
such. If it doesn't this instruction is expanded as a macro into the
following:
shl dx, 1
shl dx, 1
shl dx, 1
shl dx, 1
More code in the executable, but it makes programming easier.
If on a modern CPU, you can force A86 to act as if the CPU were a
vintage 88 with the commandline switch +P65.
--- Mem2File ------------------------------------------------ Restart --
or dl, bl ; bx = index into table
jmp L1 ; repeat until done
;------------------------
Credits: mov dx, offset Mess002
mov cx, Len002
mov bx, stdout
mov ah, 040
int 021 ; print some egotripping data
ret
;------------------------
main: call InitMem ; prime volatile data
mov al, [080] ; get tail length
cbw ; make 16 bits long
mov si, 081 ; point to start of tail
add si, ax ; point to end of tail
mov [si], ah ; make commandtail ASCIIZ
call GetArg ; get argument from command tail
jc SyntErr ; if error, get out
call Convert ; convert text to hex
mov [Start.SegVal], ax ; store it
call GetArg ; etcetera
jc SyntErr
call Convert
mov [Start.OffVal], ax
L0: call GetArg
jc SyntErr
cmp b [Argument], '-' ; single '-' character?
je L0 ; if so, ignore it
call Convert
mov [Stop.SegVal], ax
call GetArg
jc SyntErr
call Convert
mov [Stop.OffVal], ax
call GetArg
IF C jmp SyntErr
--- Mem2File ------------------------------------------------- Break ---
This is one of the A86 enhancements. This IF construct prevents that you
have to make up all kinds of ridiculous labelnames like jmp_001F in a
construct as follows:
call GetArg
jnc jmp_01F
jmp SyntErr
jmp_01F: ...
The IF construct (not to be confused with the "#IF" construct which is
for conditional assemblies) enables you to just make a fast jump by
stating the reverse condition in the IF statement and acting further
like a high level language:
IF C jmp SyntErr
Neat, isn't it?
--- Mem2File ------------------------------------------------ Restart --
mov si, offset Argument
add si, [ArgNum]
mov b [si], 0 ; make it ASCIIZ
mov dx, offset FileName ; same as Argument buffer....
mov cx, 0
mov ah, 03C
int 021 ; create the file
IF C jmp SyntErr
--- Mem2File ------------------------------------------------- Break ---
See how powerful the IF construct can be? It is a very convenient way to
circumvent the foolish conditional instructions of the x86 architecture.
--- Mem2File ------------------------------------------------ Restart --
mov [Handle], ax
mov ax, [Stop.SegVal]
mov dx, 0 ; prime DX
mov cx, 4
L0: shl ax, 1
rcl dx, 1
loop L0 ; shift upper 4 bits of address into DX
add ax, [Stop.OffVal]
adc dx, 0 ; now, dx:ax = linear address to stop at
mov [Stop.SegVal], dx
mov [Stop.OffVal], ax ; store linear address STOP
mov ax, [Start.SegVal]
mov dx, 0 ; prime DX
mov cx, 4
L0: shl ax, 1
rcl dx, 1
loop L0 ; shift upper 4 bits of address into DX
add ax, [Start.OffVal]
adc dx, 0 ; now, dx:ax = linear address to start
from
mov [Start.SegVal], dx
mov [Start.OffVal], ax ; store linear address START
cmp dx, [Stop.SegVal] ; start > stop?
ja >L1 ; fix it!
jb >L2
--- Mem2File ------------------------------------------------- Break ---
A86 likes to have as much as possible labels declared before they are
referenced. That's why many times there is code "before" the subroutine
name is declared.
For local labels (i.e. labels that consist of 1 letter and the rest
decimal digits) it is a MUST that they are defined before being
referenced.
If, for some reason, you do not want to put a label backwards in memory,
you can forward reference a local label by prefixing it with a ">" sign.
A86 now knows that the local label still has to come. Not a luxury since
many A86 programmers can do with 4 or 5 local labels in over 2000 lines
of code.... Especially L0 is always very well available.
--- Mem2File ------------------------------------------------ Restart --
cmp ax, [Stop.OffVal] ; start > stop?
jbe >L2 ; if not, OK
L1: push [Stop.SegVal]
push [Stop.OffVal] ; swap start and stop addresses
mov [Stop.SegVal], dx
mov [Stop.OffVal], ax
pop [Start.OffVal]
pop [Start.SegVal]
L2: mov dx, [Stop.SegVal]
mov ax, [Stop.OffVal]
add ax, 1
adc dx, 0 ; limits are INCLUSIVE
sub ax, [Start.OffVal]
sbb dx, [Start.SegVal] ; dx:ax = bytes to move
shl ax, 1
rcl dx, 1
shl ax, 1
rcl dx, 1 ; dx = nr of 16 Kb blocks to move
mov [Blocks], dx ; store it
shr ax, 2 ; ax = remainder to move
mov [Rest], ax ; save it
mov ax, [Start.SegVal] ; end of linear addressing, we're going
to DOS!
mov cl, 12
shl ax, cl
mov [Start.SegVal], ax
mov es, ds ; use es to refer to data
mov bx, [Handle]
lds dx, d [Start]
--- Mem2File ------------------------------------------------- Break ---
Normally this instruction would require a secretary with 100 letters per
minute typing rate:
lds dx, dword ptr [Start]
But the "ptr" argument is always the same, so it is only there to please
the assembler and humiliate the programmer: entering data that nobody
needs.
Therefore A86 only needs the first letter of such prose. In our case:
the "dword ptr" is abbreviated to a "d". "Byte ptr" is a "b". "Word Ptr"
is a "w". Simple as that.
So if your coding skills outweigh your typing speed, you should consider
switching to the superior assembler. :)
--- Mem2File ------------------------------------------------ Restart --
es cmp [Blocks], 0 ; if less than 16 Kb, skip this one.
--- Mem2File ------------------------------------------------- Break ---
For people who still remember that "Seg ES" is a legal instruction
(used for a segment override) this might bring back memories.
A86 allows the user to put the segmentation override before the actual
instruction. This way, the operand field looks neater. And it is also
the way in which D86 shows segmentation overrides.
--- Mem2File ------------------------------------------------ Restart --
je >S0
mov cx, 16K
L0: mov ah, 040
int 021
mov ax, ds ; store ds into ax
add dx, 04000 ; next buffer to load data from
IF C add ax, 01000 ; if carry, inc ds
mov ds, ax ; ds:dx now ready for next bufferfull of data
es dec [Blocks]
jnz L0
S0: es cmp [Rest], 0
je >L1
mov ah, 040
es mov cx, [Rest]
int 021
L1: mov ds, es
mov bx, [Handle]
mov ah, 03E
int 021 ; close file
call Credits ; show my ego
mov ax, 04C00
int 021 ; exit to DOS
--- Mem2File -------------------------------------------------- End ----
That's it.
jverhoeven@bigfoot.com
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Formatted Numeric Output
by Laura Fairhead
Here I am going to present you with a very useful routine for numeric
output. I have been using it myself for sometime and now I think it is
almost perfect.
It consists of 2 basic API's. The first (nuconvs), you call when you
want to change the parameters of the main routine (nuconv). You simply call
it with one DWORD in EAX, this specifies the following:
EAX = SSFFPPRR (hexadecimal value of course)
SS size size of the datum you will be calling the main routine with,
only 3 values are valid:
0=byte
1=word
2=dword
FF field size of a field in which to right-justify the number,
if this is = 0 then there is no right-justification you
only get the number
PP pad the ASCII value of the character to use to right-justify
the number in the field of output
RR radix the radix to output the number in
Once you've set the control parameters you can call the main routine
(nuconv) freely to do the work. You call the main routine with ES:DI set
to where the output is to be stored, and the value to be output in AL or
AX or EAX (depending on what data size you set).
I use the word 'output' here which might conjure up images of the screen,
but in fact what we are doing here is writing all the ASCII to memory.
This is much more powerful than incorporating all that OS/application
specific nonsense, and it really doesn't cost much overhead at all (in
fact this is the way C does it and even though I **HATE** C, here it is
right on the mark;)
Here is the code:
================START OF CODE==============================================
;
;nuconvs- set control parameters for 'nuconv'
;
; !! this must be called at least once before calling nuconv
;
;entry: EAX=SSFFPPRR (hex digits)
;
; where: SS=data size (0=byte,1=word,2=dword)
; FF=field size (0=none)
; PP=pad char
; RR=radix (2-16)
;
; !! these parameters must be set correctly by the application
; !! they are not validated in anyway and invalid parameters
; !! will cause undefined operation
;
;exit: (all registers preserved)
;
nuconvs PROC NEAR
MOV DWORD PTR CS:[nuradix],EAX
RET
nuconvs ENDP
;
;control parameters
;
; !! these absolutely must be in the below order due to the way the above
; routine works
;
nuradix DB ? ;output radix
nupad DB ? ;pad character
nufld DB ? ;field size
nudsiz DB ? ;data size
;
;nuconv- output value in accumalator -> ES:DI
;
; !! see 'nuconvs' header for more information
;
;entry: AL|AX|EAX=value to output
; ES:DI=address to write output data
;
; size of accumulator that is used depends on what the current data
; size is ( as specified by a previous call to 'nuconvs' )
;
;
;exit: DI=updated to offset of last character + 1
;
; (all other registers preserved)
;
nuconv PROC NEAR
;
;all registers are going to be preserved
;
PUSH DS
PUSH EAX
PUSH EBX
PUSH CX
PUSH EDX
;
;save some CS: overrides
;
PUSH CS
POP DS
;
;initialise
;
; set EBX =radix
; CX =fieldsize
;
; also we zero pad out the datum passed so it fills EAX
;
XOR EBX,EBX
CMP BL,BYTE PTR DS:[nudsiz]
JNP SHORT ko1
JS SHORT ko0
MOV AH,0
ko0: DEC BX
AND EAX,EBX
INC BX
ko1:
MOV BL,BYTE PTR DS:[nuradix]
MOV CH,0
MOV CL,BYTE PTR DS:[nufld]
;
;calculate digits and push to stack
;
; EAX is divided and modulus taken which is the standard way,
; loop exits when it reaches 0 or the field size is hit
; notice that if CX=0 on entry to this then the field size
; will be effectively unbounded
;
nulop0: XOR EDX,EDX
DIV EBX
PUSH DX
AND EAX,EAX
LOOPNZ nulop0
;
;'output' the field padding
;
; the number of padding characters is normally the value
; now in CX (ie: fieldsize - digits ). however no pad chars
; should be output if field size = 0. i think the check here
; for this is nice and tight (read the code...)
;
MOV BX,CX
NEG BX
JNS SHORT ko
MOV AL,BYTE PTR DS:[nupad]
REP STOSB
ko:
;
;'output' all the digits
;
; CX is set to the number of digits on the stack we have to output
; ie: fieldsize - ( fieldsize - digits )
;
MOV CH,0
MOV CL,BYTE PTR DS:[nufld]
ADD CX,BX
;
; now we pop off those #CX digits translating into ASCII using a nice
; variation of the traditional speed method
;
MOV BX,OFFSET nudat
nulop1: POP AX
XLAT
STOSB
LOOP nulop1
;
; restore all registers and exit (in case it wasn't obvious!)
;
POP EDX
POP CX
POP EBX
POP EAX
POP DS
RET
;
nudat DB "0123456789ABCDEF"
;
nuconv ENDP
==================END OF CODE==============================================
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................FEATURE.ARTICLE
Linked Lists in ASM
by mammon_
Assembly language is notorious for being low-level; to wit, it lacks many of
the features in higher-level languages which make programming easier. In the
course of my work in the visasm project I have put quite a bit of time into
working on exactly which higher language features are important and which, in a
nutshell, are swill.
One of the areas in which assembly language is lacking is the use of dynamic
structures. Pointer manipulation in asm is simple and clear for up to one
level of redirection; further redirection causes the code to quickly become a
confusion of register juggling and indirect addressing. As a result,
implementing even a simple linked list in assembly language can be tedious
enough to make one rewrite the project in C.
In this article I have undertaken an implementation of a linked list in NASM;
the implementation is generic enough to support more complex data structures,
and should port to other assemblers with few changes.
To begin with, one must define the memory allocation routines for use in the
application; I have chosen Win32 for convenience. The routines defined below
are for local heap allocation and for the Win32 console interface to allow the
use of STDOUT on the console.
;=========================================================Win32 API Definitions
STD_INPUT_HANDLE EQU -10 ;nStdHandle types
STD_OUTPUT_HANDLE EQU -11
STD_ERROR_HANDLE EQU -12
EXTERN AllocConsole ;BOOL AllocConsole()
EXTERN GetStdHandle ;HANDLE GetStdHandle( nStdHandle )
EXTERN WriteConsoleA ;HANDLE hConsole, lpBuffer, Num2Write, lpWritten,NULL
EXTERN ExitProcess ;UINT ExitCode
EXTERN GetProcessHeap ;
EXTERN HeapAlloc ;HANDLE hHeap,DWORD dwFlags, DWORD dwBytes:ret ptr
EXTERN HeapFree ;HANDLE hHeap,DWORD dwFlags, LPVOID lpMem
EXTERN HeapReAlloc ;HANDLE hHeap,DWORD dwFlags,LPVOID lpMem,DWORD dwBytes
EXTERN HeapDestroy ;HANDLE hHeap
%define HEAP_NO_SERIALIZE 0x00000001
%define HEAP_GROWABLE 0x00000002
%define HEAP_GENERATE_EXCEPTIONS 0x00000004
%define HEAP_ZERO_MEMORY 0x00000008
%define HEAP_REALLOC_IN_PLACE_ONLY 0x00000010
%define HEAP_TAIL_CHECKING_ENABLED 0x00000020
%define HEAP_FREE_CHECKING_ENABLED 0x00000040
%define HEAP_DISABLE_COALESCE_ON_FREE 0x00000080
%define HEAP_CREATE_ALIGN_16 0x00010000
%define HEAP_CREATE_ENABLE_TRACING 0x00020000
%define HEAP_MAXIMUM_TAG 0x0FFF
%define HEAP_PSEUDO_TAG_FLAG 0x8000
%define HEAP_TAG_SHIFT 16
;===========================================================End API Definitions
In addition, it is useful to define a few common routines for use later:
;==============================================================Utility Routines
[section data class=DATA use32] ;set up the segments early
%macro STRING 2+
%1: db %2
.end:
%define %1.length %1.end - %1
%endmacro
[section code class=CODE use32]
GetConsole:
;GetConsole()
[section data]
hConsole DD 0
[section code]
call AllocConsole
push dword STD_OUTPUT_HANDLE
call GetStdHandle
mov [hConsole], eax
xor eax, eax
ret
puts:
;puts( ptrString, NumBytes )
[section data]
NumWrote DD 0
[section code]
%define _ptrString ebp + 8
%define _strlen ebp + 12
push ebp
mov ebp,esp
push eax
push dword 0
push dword NumWrote
mov eax, [ _strlen ]
push dword eax
mov eax, [ _ptrString ]
push dword eax
push dword [hConsole]
call WriteConsoleA
pop eax
mov esp, ebp
pop ebp
ret 8
;==========================================================End Utility Routines
The STRING macro is particular interesting; it allows one to define a string
in the data segment as
STRING label, 'contents of string',0Dh,0Ah
while defining the constant label.length as the total length of the string.
This will come in handy during the many calls to puts, which is used to write
to the Win32 console. Puts has the syntax
puts( lpString, strLength )
and returns the result of WriteConsole, a BOOL value. GetConsole is a routine
provided to move the Win32 console allocation code out of the main program; it
takes no parameters and defines the hConsole handle.
The linked list implementation has been designed to be extendable; the routine
names are prefaced with underscores to avoid filling up the namespace of the
linked list application, and the routines themselves are generic enough to be
called from higher-level Stack, Queue, and List implementations. The Linked
List interface is as follows:
ptrHead _create_list( hHeap, NodeSize )
void _delete_list( hHeap, ptrHead)
ptrNode _add_node( hHeap, ptrPrev, NodeSize )
void _delete_node( hHeap, ptrPrev, ptrNode )
void _set_node_data( ptrNode, NodeOffset, data )
DWORD data _get_node_data( ptrNode, NodeOffset )
The names of the routines should make their intent apparent; note however that
NodeSize is assumed to be the size of a LISTSTRUCT structure.
;====================================================Linked List Implementation
[section data]
;Define .next as offset Zero for use in generic functions
struc _llist
.next: resd 1 ;this is basically a constant
endstruc
;Macro to ensure that .next is always at offset zero in user-defined lists
%macro LISTSTRUCT 1
struc %1
.next: resd 1
%endmacro
%macro END_LISTSTRUCT 0
endstruc
%endmacro
[section code]
;Note that these assume an LISTSTRUCT base type
_create_list:
; ptrHead_create_list( hHeap, NodeSize )
%define _hHeap ebp + 8
%define _ListSize ebp + 12
ENTER 0 , 0
push dword [_ListSize] ;size of LISTSTRUCT
push dword HEAP_ZERO_MEMORY ;FLAG for HeapAlloc
push dword [_hHeap] ;Heap being used
call HeapAlloc
test eax, eax
jz .Error ;Alloc failed!
mov [eax + _llist.next], dword 0 ;.next pointer = NULL
.Exit: LEAVE ;eax = ptrHead
ret 8
.Error: xor eax, eax ;error = return NULL
jmp .Exit
_delete_list:
; _delete_list( hHeap, ptrHead)
%define _hHeap ebp + 8
%define _ptrHead ebp + 12
ENTER 0, 0
push eax
push ebx ;save registers
mov eax, [_ptrHead] ;eax = addr of list head node
.DelNode:
mov ebx, [eax + _llist.next] ;ebx = [eax].next
push eax ;free addr in eax
push dword 0 ;FLAG
push dword [_hHeap] ;local heap
call HeapFree
test ebx, ebx ;is [eax].next == NULL?
jz .Exit ;if yes then done
mov eax, ebx ;loop until done
jmp .DelNode
.Exit: pop ebx
pop eax
LEAVE
ret 8
_add_node:
; ptrNode _add_node( hHeap, ptrPrev, NodeSize )
%define _hHeap ebp + 8
%define _ptrPrev ebp + 12
%define _ListSize ebp + 16
ENTER 0, 0
push edx ;HeapAlloc kills edx!!
push ebx
push ecx ;save registers
mov ebx, [_ptrPrev] ;ebx = node to add after
push dword [_ListSize] ;size of node
push dword HEAP_ZERO_MEMORY ;FLAG
push dword [_hHeap] ;local heap
call HeapAlloc
test eax, eax
jz .Error ;alloc failed!
mov ecx, eax ;note -- eax = ptrNew
add ecx, _llist.next ;ecx = ptrNew.next
mov [ecx], ebx ;ptrNew.next = ptrPrev.next
add ebx, _llist.next ;note -- ebx = ptrPrev
mov [ebx], eax ;ptrPrev.next = ptrNew
.Exit: pop ecx
pop ebx
pop edx
LEAVE
ret 12
.Error: xor eax, eax ;return NULL on failure
jmp .Exit
_delete_node:
; _delete_node( hHeap, ptrPrev, ptrNode )
%define _hHeap ebp + 8
%define _ptrPrev ebp + 12
%define _ptrNode ebp + 16
ENTER 0, 0
push ebx
mov eax, [_ptrNode + _llist.next] ;eax = ptrNode.next
mov ebx, [_ptrPrev] ;
mov [ebx + _llist.next], eax ;ptrPrev.next = ptrNode.next
push dword [_ptrNode] ;free ptrNode
push dword 0 ;FLAG
push dword [_hHeap] ;local heap
call HeapFree
pop ebx
LEAVE
ret 12
_set_node_data:
; _set_node_data( ptrNode, NodeOffset, data )
%define _ptrNode ebp + 8
%define _off ebp + 12
%define _data ebp + 16
ENTER 0, 0
push eax
push ebx
mov eax, [_ptrNode] ;eax = ptrNode
add eax, [ _off ] ;eax = ptrNode.offset
mov ebx, [_data] ;ebd = data
mov [eax], ebx ;ptrNode.offset = data
pop ebx
pop eax
LEAVE
ret 12
_get_node_data:
; DWORD data _get_node_data( ptrNode, NodeOffset )
%define _ptrNode ebp + 8
%define _off ebp + 12
ENTER 0, 0
mov eax, [_ptrNode] ;eax = ptrNode
add eax, [_off] ;eax = ptrNode.offset
mov eax, [eax] ;return [ptrNode.offset]
LEAVE
ret 8
;===============================================================End Linked List
The LISTSTRUCT structure is perhaps the most crucial part of this implemen-
tation. In NASM, a structure is simply a starting address with local labels
defined as constants which equal the offset of the local label from the start
of the structure. Thus, in the structure
struc MyStruc
.MyVar resd 1
.MyVar2 resd 1
.MyVar3 resd 1
.MyByte resb 1
endstruc
the constant MyStruc.MyVar has a value of 0 [0 bytes from the start of the
structure], MyStruc.MyVar2 has a value of 4, MyStruc.MyVar3 has a value of 8,
MyStruc.MyByte has a value of 12, and MyStruc_size [defined as the offset of
the "endstruc" directive] has a value of 13. Note that in NASM, the name of a
structure instance determines the address in memory of the instance [i.e., it
is a simple code label], while the constants defined in the structure
definition allow access to offsets from that address.
What this means is that structures in NASM can be defined and never instant-
iated, allowing the convenient use of the structure constants for dynamic
memory structures such as classes and linked list nodes. The above code uses
the LISTSTRUCT macro to force all linked list nodes to have a ".next" member;
this also allows the use of the constant "_llist.next" in the linked list
routines to avoid having to pass the offset of the ".next" member for a node.
The implementation routines should be pretty straight forward. _create_list
allocates memory from the local heap of the size of one list node [determined
by the parameter NodeSize passed to _create_list] and returns the address of
the allocated memory; since this node is assumed to be the list "head", the
.next member is set to NULL. _delete_list is passed the address of the head
node of the list; it saves the address in the .next member of the node and
then frees the memory allocated to the node, repeating this with each .next
link until the .next member is NULL [indicating an end of list].
_add_node is used to insert a node into an existing list; it is passed the
address of the node after which the new node is to be inserted. The .next
member of this node is moved into the .next member of the new node, and
replaced with the address of the new node. Thus, if before insertion the list
had the structure
.next [Node1] --> .next [Node2] --> .next [NULL]
.data NULL .data Node1 .data Node2
then it would have the following structure after insertion following Node1:
.next [Node1] --> .next [NewNode] --> .next [Node2] --> .next [NULL]
.data NULL .data Node1 .data NewNode .data Node2
_del_node does the opposite of _add_node; it moves the .next member of the
node to be deleted into the .next member of the preceding node, then frees the
specified node.
Note that both _del_node and _add_node are designed to be as generic as
possible and make no assumptions regarding the linked list structure; thus in
a double linked list of the format
struc DLLIST
.next
.prev
.data
endstruc
one could front-end the Delete function as follows:
DelNode:
push dword eax ;eax = Node to delete
push dword [eax + DLLIST.prev]
push hHeap
call _del_node
ret 8
The other linked list routines can be provided with similar front-ends to take
care of common heap handles, list sizes, and member assignments.
Both the _set_node_data and the _get_node_data routines are basic pointer
manipulations added for code clarity. Each could be rewritten inline; for
example, the _get_node_data routine can be implemented as
add ebx, offset
mov eax, [ebx]
assuming ebx holds the node to be accessed and "offset" is the offset [or
constant] of the node member to be accessed.
Below is a simple program which makes a four-node linked list of the format
.next Node1 --> .next Node2 --> .next Node3 --> .next NULL
.prev NULL <-- .prev Head <-- .prev Node1 <-- .prev Node2
.data NULL .data 'node1' .data 'node2' .data 'node3'
Note the use of the NewNode routine, which provides a front-end to _add_node
which sets the .prev member for the new node. One brief caveat, the example
does not delete the list, as the Win32 heap is deallocated on program
termination; neither is there any substantial error checking in the sample.
;=======================================================Linked List Application
[section data]
hHeap dd 0
ptrHead dd 0
STRING strData1, 'node 1',0Dh,0Ah
STRING strData2, 'node 2',0Dh,0Ah
STRING strData3, 'node 3',0Dh,0Ah
STRING strStart, 'Creating List',0Dh,0Ah
STRING strDone, 'Finished!',0Dh,0AH,'Printing Data...',0Dh,0Ah
STRING strErr, 'Error!',0Dh, 0AH
LISTSTRUCT llist
.prev resd 0
.data resd 0
END_LISTSTRUCT
[section code]
Error:
push dword strErr.length
push dword strErr
call puts
jmp Exit
..start:
call GetProcessHeap
mov [hHeap], eax
call GetConsole
push dword strStart.length
push dword strStart
call puts
CreateList:
push dword llist_size
push dword [hHeap]
call _create_list
test eax, eax
jz Error
mov [ptrHead], eax
push dword 0
push dword llist.data
push eax
call _set_node_data ;set ptrHead.data to NULL
push dword 0
push dword llist.prev
push eax
call _set_node_data ;set ptrHead.prev to NULL
call NewNode ;create Node1
test eax, eax
jz ListDone
push dword strData1
push dword llist.data
push eax
call _set_node_data ;set Node1.data to 'node1'
call NewNode ;create Node2
test eax, eax
jz ListDone
push dword strData2
push dword llist.data
push eax
call _set_node_data ;set Node2.data to 'node2'
call NewNode ;create Node3
test eax, eax
jz ListDone
push dword strData3
push dword llist.data
push eax
call _set_node_data ;set Node3.data to 'node3'
ListDone:
push dword strDone.length
push dword strDone
call puts
mov ebx, [ptrHead]
PrintList:
push dword _llist.next
push ebx
call _get_node_data ;could have been mov eax,[ebx]
test eax, eax ;if ptrCurrent.next == NULL exit
jz Exit ; [end of list]
mov ebx, eax ;save ptrNode
push dword strData1.length ;push length for call to puts
push dword llist.data
push ebx
call _get_node_data ;get ptrNode.data
push dword eax ;push string for call to puts
call puts
jmp PrintList ;loop
Exit:
push dword 0
call ExitProcess
NewNode:
ENTER 0, 0
push edx
mov edx, eax ;save previous node
push dword llist_size
push dword eax
push dword [hHeap]
call _add_node
test eax, eax
jz .Done
push dword eax
push dword llist.next
push dword edx
call _set_node_data ;set ptrPrev.next to ptrNew
push edx
push dword llist.prev
push eax
call _set_node_data ;set ptrNew.prev to ptrPrev
push dword 0
push dword llist.next
push eax
call _set_node_data ;set PtrNew.next to NULL
.Done pop edx
LEAVE ;eax is still set to ptrNew
ret
;==========================================================================EOF
As mentioned earlier, this is a generic implementation of dynamic structures
designed with linked lists in mind. The macros and routines may be included in
a header file such as llist.h and used to automate the creation of dynamic
memory structures in future projects. In addition, further macros and routines
can be added to provide specific implementations of Single Linked Lists,
Double Linked Lists, Circular Lists, Stacks, Queues, and Deques.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
Structured Exception Handling under Win32
by Chris Dragan
Structured Exception Handling is a powerful feature of all Win32 platforms
that allows a program to recover from any critical errors like BOUND, divide
overflow, page missing or general protection fault. It is documented only for
C-level usage (try-except/finally syntax), and no documentation for low level
languages exists. Therefore I will try to show how to use it.
The starting point for Structured Exception Handling, SEH, is the Thread
Info Block. TIB, as almost all the other structures, is described in winnt.h
file that comes with PlatformSDK.
struc NT_TIB
ExceptionList dd ? ; Used by SEH
StackBase dd ? ; Used by functions to check for
StackLimit dd ? ; stack overflow
SubSystemTib dd ? ; ?
FiberDataOrVersion dd ? ; ?
ArbitraryUserPointer dd ? ; ?
Self dd ? ; Linear address of the TIB
ends
TIB is accessible at address fs:0. NT_TIB.Self contains linear address of TIB,
base of FS segment.
When an exception occurs, the system uses (dword)fs:0, NT_TIB.ExceptionList
to find an exception handler and execute it. The exception list entry is very
simple:
struc E_L_ENTRY
Next dd ? ; Points to next entry in the list
ExceptionHandler dd ? ; User callback - exception hook
Optional db X dup (?) ; Exception Handler data
EntryTerminator dd -1 ; Optional
ends
C compilers usually keep some additional information in E_L_ENTRY.Optional
field of varying size and usually terminated with (dword)-1. Both .Optional
and .EntryTerminator fields are not required.
Before calling an exception handler, the exception manager pushes
ExceptionRecord and ContextRecord onto the stack. These structures identify an
exception and processor state before it. The exception manager adds also its
own entry to the exception list.
Exception handler is in fact a typical callback. It is not however
installed by any API function, but appended in E_L_ENTRY into the exception
list.
EXCEPTION_DISPOSITION __cdecl _except_handler (
struct _EXCEPTION_RECORD *ExceptionRecord,
void * EstablisherFrame,
struct _CONTEXT *ContextRecord,
void * DispatcherContext
);
The exception handler uses C-style calling convention, it does not release
arguments while returning. The most important parameters are ExceptionRecord
and ContextRecord, described at the end of this text, that point to the pushed
corresponding structures. I do not have yet any idea what is the purpose of
EstablisherFrame and DispatcherContext.
struc EXCEPTION_RECORD
ExceptionCode dd ? ; See at the end of this text
ExceptionFlags dd ?
ExceptionRecord dd ? ; ?
ExceptionAddress dd ? ; Linear address of faulty instruction
NumberParameters dd ? ; Corresponds to the field below
ExceptionInformation dd 15 dup (?) ; ?
ends
Exception flags are:
EXCEPTION_NONCONTINUABLE = 1
EXCEPTION_UNWINDING = 2
EXCEPTION_UNWINDING_FOR_EXIT = 4
The exception handler has two possible ways of proceeding. It can return to
the exception manager, or it can unwind the stack and continue the program. In
the first case it has to return one of the following values:
enum EXCEPTION_DISPOSITION \
ExceptionContinueExecution = 0,\
ExceptionContinueSearch = 1,\
ExceptionNestedException = 2,\
ExceptionCollidedUnwind = 3
The value of zero forces the exception manager to continue the program
at saved in context cs:eip, which may be altered by the exception handler. The
value of 1 causes the exception manager to call another exception handler in
the exception list. Values 2 and 3 inform the exception manager that an error
occured - an exception-in-exception happened, or the handler wanted to unwind
the stack during another handler of higher instance was doing this already.
The other case can be determined if one of .ExceptionFlags is
EXCEPTION_UNWINDING or EXCEPTION_UNWINDING_FOR_EXIT.
While appending a new exception handler to the exception list, a common
practice is to push new E_L_ENTRY onto the stack. This way unwinding the stack
can be done simply by skipping the exception manager's entry and restoring the
stack pointer.
Here is an example of exception handling.
----Start-of-file-------------------------------------------------------------
ideal
p686n
model flat, stdcall
O equ <offset>
struc EXCEPTION_RECORD
ExceptionCode dd ?
ExceptionFlags dd ?
ExceptionRecord dd ?
ExceptionAddress dd ?
NumberParameters dd ?
ExceptionInformation dd 15 dup (?)
ends
procdesc wsprintfA c :dword, :dword, :dword:?
procdesc MessageBoxA :dword, :dword, :dword, :dword
procdesc ExitProcess :dword
udataseg
ExCode dd ?
szCode db 12 dup (?)
dataseg
szWindowTitle db 'Exception code', 0
szFormat db '%0X', 0
codeseg
proc main
; Install exception handler
push O ExceptionHandler
push [dword fs:0] ; E_L_ENTRY.Next
mov [fs:0], esp ; Append new E_L_ENTRY
; Cause Invalid Opcode exception
ud2
; Display exception code and quit
_Continue: call wsprintfA, O szCode, O szFormat, [ExCode]
call MessageBoxA, 0, O szCode, O szWindowTitle, 0
call ExitProcess, 0
endp
proc ExceptionHandler c ExceptionRecord, EF, ContextRecord, DC
; Save exception code
mov eax, [ExceptionRecord]
mov ecx, [(EXCEPTION_RECORD eax).ExceptionCode]
mov [ExCode], ecx
; Unwind the stack
mov eax, [fs:0] ; Exception Manager's entry
mov esp, [eax] ; Our entry
pop [dword fs:0] ; Restore fs:0
add esp, 4 ; Skip ExHandler address
jmp _Continue
endp
end main
----End-of-file---------------------------------------------------------------
The above source should be compiled with TASM 5.0r or later like this:
tasm32 /ml except.asm
tlink32 /x /Tpe /aa /c /V4.0 except.obj,,, LIBPATH\import32.lib
And here are other important constants and structures, all defined in
winnt.h PlatformSDK file.
Exception codes:
----------------
STATUS_SEGMENT_NOTIFICATION = 040000005h
STATUS_GUARD_PAGE_VIOLATION = 080000001h
STATUS_DATATYPE_MISALIGNMENT = 080000002h
STATUS_BREAKPOINT = 080000003h
STATUS_SINGLE_STEP = 080000004h
STATUS_ACCESS_VIOLATION = 0C0000005h
STATUS_IN_PAGE_ERROR = 0C0000006h
STATUS_INVALID_HANDLE = 0C0000008h
STATUS_NO_MEMORY = 0C0000017h
STATUS_ILLEGAL_INSTRUCTION = 0C000001Dh
STATUS_NONCONTINUABLE_EXCEPTION = 0C0000025h
STATUS_INVALID_DISPOSITION = 0C0000026h
STATUS_ARRAY_BOUNDS_EXCEEDED = 0C000008Ch
STATUS_FLOAT_DENORMAL_OPERAND = 0C000008Dh
STATUS_FLOAT_DIVIDE_BY_ZERO = 0C000008Eh
STATUS_FLOAT_INEXACT_RESULT = 0C000008Fh
STATUS_FLOAT_INVALID_OPERATION = 0C0000090h
STATUS_FLOAT_OVERFLOW = 0C0000091h
STATUS_FLOAT_STACK_CHECK = 0C0000092h
STATUS_FLOAT_UNDERFLOW = 0C0000093h
STATUS_INTEGER_DIVIDE_BY_ZERO = 0C0000094h
STATUS_INTEGER_OVERFLOW = 0C0000095h
STATUS_PRIVILEGED_INSTRUCTION = 0C0000096h
STATUS_STACK_OVERFLOW = 0C00000FDh
STATUS_CONTROL_C_EXIT = 0C000013Ah
STATUS_FLOAT_MULTIPLE_FAULTS = 0C00002B4h
STATUS_FLOAT_MULTIPLE_TRAPS = 0C00002B5h
STATUS_ILLEGAL_VLM_REFERENCE = 0C00002C0h
Context flags:
--------------
CONTEXT_i386 = 000010000h
CONTEXT_i486 = 000010000h
CONTEXT_CONTROL = (CONTEXT_i386 or 1) ; SS:ESP, CS:EIP, EFLAGS, EBP
CONTEXT_INTEGER = (CONTEXT_i386 or 2) ; EAX, EBX,..., ESI, EDI
CONTEXT_SEGMENTS = (CONTEXT_i386 or 4) ; DS, ES, FS, GS
CONTEXT_FLOATING_POINT = (CONTEXT_i386 or 8) ; 387 state
CONTEXT_DEBUG_REGISTERS = (CONTEXT_i386 or 16); DB 0-3,6,7
CONTEXT_EXTENDED_REGISTERS = (CONTEXT_i386 or 32); cpu specific extensions
CONTEXT_FULL = (CONTEXT_CONTROL or CONTEXT_INTEGER or\
CONTEXT_SEGMENTS)
Context structure:
------------------
struc CONTEXT
ContextFlags dd ? ; CONTEXT_??? flags
Dr0 dd ? ; Debug registers
Dr1 dd ?
Dr2 dd ?
Dr3 dd ?
Dr6 dd ?
Dr7 dd ?
ControlWord dd ? ; FPU context
StatusWord dd ?
TagWord dd ?
ErrorOffset dd ?
ErrorSelector dd ?
DataOffset dd ?
DataSelector dd ?
RegisterArea dt 8 dup (?)
Cr0NpxState dd ?
SegGs dd ? ; Segment registers
SegFs dd ?
SegEs dd ?
SegDs dd ?
Edi dd ? ; Integer registers
Esi dd ?
Ebx dd ?
Edx dd ?
Ecx dd ?
Eax dd ?
Ebp dd ? ; Control registers
Eip dd ?
SegCs dd ?
EFlags dd ?
Esp dd ?
SegSs dd ?
ExtendedRegisters db 512 dup (?)
ends
Additional word
---------------
This article was posted on comp.lang.asm.x86.
Especially thanks to Michael Tippach for pointing out some exception flags.
My web page is at http://ams.ampr.org/cdragan/
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
Child Window Controls
by Iczelion
In this tutorial, we will explore child window controls which are very
important input and output devices of our programs.
Theory
------
Windows provides several predefined window classes which we can readily use
in our own programs. Most of the time we use them as components of a dialog
box so they're usually called child window controls. The child window
controls process their own mouse and keyboard messages and notify the
parent window when their states have changed. They relieve the burden from
programmers enormously so you should use them as much as possible. In this
tutorial, I put them on a normal window just to demonstrate how you can
create and use them but in reality you should put them in a dialog box.
Examples of predefined window classes are button, listbox, checkbox, radio
button,edit etc.
In order to use a child window control, you must create it with
CreateWindow or CreateWindowEx. Note that you don't have to register the
window class since it's registered for you by Windows. The class name
parameter MUST be the predefined class name. Say, if you want to create a
button, you must specify "button" as the class name in CreateWindowEx. The
other parameters you must fill in are the parent window handle and the
control ID. The control ID must be unique among the controls. The control
ID is the ID of that control. You use it to differentiate between the
controls.
After the control was created, it will send messages notifying the parent
window when its state has changed. Normally, you create the child windows
during WM_CREATE message of the parent window. The child window sends
WM_COMMAND messages to the parent window with its control ID in the low
word of wParam, the notification code in the high word of wParam, and its
window handle in lParam. Each child window control has different
notification codes, refer to your Win32 API reference for more information.
The parent window can send commands to the child windows too, by calling
SendMessage function. SendMessage function sends the specified message with
accompanying values in wParam and lParam to the window specified by the
window handle. It's an extremely useful function since it can send messages
to any window provided you know its window handle.
So, after creating the child windows, the parent window must process
WM_COMMAND messages to be able to receive notification codes from the child
windows.
Application
-----------
We will create a window which contains an edit control and a pushbutton.
When you click the button, a message box will appear showing the text you
typed in the edit box. There is also a menu with 4 menu items:
1. Say Hello -- Put a text string into the edit box
2. Clear Edit Box -- Clear the content of the edit box
3. Get Text -- Display a message box with the text in the edit box
4. Exit -- Close the program.
.386
.model flat,stdcall
option casemap:none
WinMain proto :DWORD,:DWORD,:DWORD,:DWORD
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
.data
ClassName db "SimpleWinClass",0
AppName db "Our First Window",0
MenuName db "FirstMenu",0
ButtonClassName db "button",0
ButtonText db "My First Button",0
EditClassName db "edit",0
TestString db "Wow! I'm in an edit box now",0
.data?
hInstance HINSTANCE ?
CommandLine LPSTR ?
hwndButton HWND ?
hwndEdit HWND ?
buffer db 512 dup(?) ; buffer to store the text
retrieved from the edit box
.const
ButtonID equ 1 ; The control ID of the
button control
EditID equ 2 ; The control ID of the
edit control
IDM_HELLO equ 1
IDM_CLEAR equ 2
IDM_GETTEXT equ 3
IDM_EXIT equ 4
.code
start:
invoke GetModuleHandle, NULL
mov hInstance,eax
invoke GetCommandLine
invoke WinMain, hInstance,NULL,CommandLine, SW_SHOWDEFAULT
invoke ExitProcess,eax
WinMain proc
hInst:HINSTANCE,hPrevInst:HINSTANCE,CmdLine:LPSTR,CmdShow:DWORD
LOCAL wc:WNDCLASSEX
LOCAL msg:MSG
LOCAL hwnd:HWND
mov wc.cbSize,SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov wc.lpfnWndProc, OFFSET WndProc
mov wc.cbClsExtra,NULL
mov wc.cbWndExtra,NULL
push hInst
pop wc.hInstance
mov wc.hbrBackground,COLOR_BTNFACE+1
mov wc.lpszMenuName,OFFSET MenuName
mov wc.lpszClassName,OFFSET ClassName
invoke LoadIcon,NULL,IDI_APPLICATION
mov wc.hIcon,eax
mov wc.hIconSm,eax
invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor,eax
invoke RegisterClassEx, addr wc
invoke CreateWindowEx,WS_EX_CLIENTEDGE,ADDR ClassName, \
ADDR AppName, WS_OVERLAPPEDWINDOW,\
CW_USEDEFAULT, CW_USEDEFAULT,\
300,200,NULL,NULL, hInst,NULL
mov hwnd,eax
invoke ShowWindow, hwnd,SW_SHOWNORMAL
invoke UpdateWindow, hwnd
.WHILE TRUE
invoke GetMessage, ADDR msg,NULL,0,0
.BREAK .IF (!eax)
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.ENDW
mov eax,msg.wParam
ret
WinMain endp
WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.IF uMsg==WM_DESTROY
invoke PostQuitMessage,NULL
.ELSEIF uMsg==WM_CREATE
invoke CreateWindowEx,WS_EX_CLIENTEDGE, ADDR EditClassName,NULL,\
WS_CHILD or WS_VISIBLE or WS_BORDER or ES_LEFT or\
ES_AUTOHSCROLL,\
50,35,200,25,hWnd,8,hInstance,NULL
mov hwndEdit,eax
invoke SetFocus, hwndEdit
invoke CreateWindowEx,NULL, ADDR ButtonClassName,ADDR ButtonText,\
WS_CHILD or WS_VISIBLE or BS_DEFPUSHBUTTON,\
75,70,140,25,hWnd,ButtonID,hInstance,NULL
mov hwndButton,eax
.ELSEIF uMsg==WM_COMMAND
mov eax,wParam
.IF lParam==0
.IF ax==IDM_HELLO
invoke SetWindowText,hwndEdit,ADDR TestString
.ELSEIF ax==IDM_CLEAR
invoke SetWindowText,hwndEdit,NULL
.ELSEIF ax==IDM_GETTEXT
invoke GetWindowText,hwndEdit,ADDR buffer,512
invoke MessageBox,NULL,ADDR buffer,ADDR AppName,MB_OK
.ELSE
invoke DestroyWindow,hWnd
.ENDIF
.ELSE
.IF ax==ButtonID
shr eax,16
.IF ax==BN_CLICKED
invoke SendMessage,hWnd,WM_COMMAND,IDM_GETTEXT,0
.ENDIF
.ENDIF
.ENDIF
.ELSE
invoke DefWindowProc,hWnd,uMsg,wParam,lParam
ret
.ENDIF
xor eax,eax
ret
WndProc endp
end start
Analysis:
Let's analyze the program.
.ELSEIF uMsg==WM_CREATE
invoke CreateWindowEx,WS_EX_CLIENTEDGE, \
ADDR EditClassName,NULL,\
WS_CHILD or WS_VISIBLE or WS_BORDER or
ES_LEFT\
or ES_AUTOHSCROLL,\
50,35,200,25,hWnd,EditID,hInstance,NULL
mov hwndEdit,eax
invoke SetFocus, hwndEdit
invoke CreateWindowEx,NULL, ADDR ButtonClassName,\
ADDR ButtonText,\
WS_CHILD or WS_VISIBLE or BS_DEFPUSHBUTTON,\
75,70,140,25,hWnd,ButtonID,hInstance,NULL
mov hwndButton,eax
We create the controls during processing of WM_CREATE message. We call
CreateWindowEx with an extra window style, WS_EX_CLIENTEDGE, which makes
the client area look sunken. The name of each control is a predefined one,
"edit" for edit control, "button" for button control. Next we specify the
child window's styles. Each control has extra styles in addition to the
normal window styles. For example, the button styles are prefixed with
"BS_" for "button style", edit styles are prefixed with "ES_" for "edit
style". You have to look these styles up in a Win32 API reference. Note
that you put a control ID in place of the menu handle. This doesn't cause
any harm since a child window control cannot have a menu.
After creating each control, we keep its handle in a variable for future
use.
SetFocus is called to give input focus to the edit box so the user can type
the text into it immediately.
Now comes the really exciting part. Every child window control sends
notification to its parent window with WM_COMMAND.
.ELSEIF uMsg==WM_COMMAND
mov eax,wParam
.IF lParam==0
Recall that a menu also sends WM_COMMAND messages to notify the window
about its state too. How can you differentiate between WM_COMMAND messages
originated from a menu or a control? Below is the answer
Low word of wParam High word of wParam lParam
Menu Menu ID 0 0
Control Control ID Notification code Child Window Handle
You can see that you should check lParam. If it's zero, the current
WM_COMMAND message is from a menu. You cannot use wParam to differentiate
between a menu and a control since the menu ID and control ID may be
identical and the notification code may be zero.
.IF ax==IDM_HELLO
invoke SetWindowText,hwndEdit,ADDR TestString
.ELSEIF ax==IDM_CLEAR
invoke SetWindowText,hwndEdit,NULL
.ELSEIF ax==IDM_GETTEXT
invoke GetWindowText,hwndEdit,ADDR buffer,512
invoke MessageBox,NULL,ADDR buffer,ADDR AppName,MB_OK
You can put a text string into an edit box by calling SetWindowText. You
clear the content of an edit box by calling SetWindowText with NULL.
SetWindowText is a general purpose API function. You can use SetWindowText
to change the caption of a window or the text on a button.
To get the text in an edit box, you use GetWindowText.
.IF ax==ButtonID
shr eax,16
.IF ax==BN_CLICKED
invoke SendMessage,hWnd,WM_COMMAND,IDM_GETTEXT,0
.ENDIF
.ENDIF
The above code snippet deals with the condition when the user presses the
button. First, it checks the low word of wParam to see if the control ID
matches that of the button. If it is, it checks the high word of wParam to
see if it is the notification code BN_CLICKED which is sent when the button
is clicked.
The interesting part is after it's certain that the notification code is
BN_CLICKED. We want to get the text from the edit box and display it in a
message box. We can duplicate the code in the IDM_GETTEXT section above but
it doesn't make sense. If we can somehow send a WM_COMMAND message with the
low word of wParam containing the value IDM_GETTEXT to our own window
procedure, we can avoid code duplication and simplify our program.
SendMessage function is the answer. This function sends any message to any
window with any wParam and lParam we want. So instead of duplicating the
code, we call SendMessage with the parent window handle, WM_COMMAND,
IDM_GETTEXT, and 0. This has identical effect to selecting "Get Text" menu
item from the menu. The window procedure doesn't perceive any difference
between the two.
You should use this technique as much as possible to make your code more
organized.
Last but not least, do not forget the TranslateMessage function in the
message loop. Since you must type in some text into the edit box, your
program must translate raw keyboard input into readable text. If you omit
this function, you will not be able to type anything into your edit box.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
Dialog Box as Main Window
by Iczelion
Now comes the really interesting part about GUI, the dialog box. In this
tutorial (and the next), we will learn how to use a dialog box as our main
window.
Theory
------
If you play with the examples in the previous tutorial long enough, you 'll
find out that you cannot change input focus from one child window control
to another with Tab key. The only way you can do that is by clicking the
control you want it to gain input focus. This situation is rather
cumbersome. Another thing you might notice is that I changed the background
color of the parent window to gray instead of normal white as in previous
examples. This is done so that the color of the child window controls can
blend seamlessly with the color of the client area of the parent window.
There is a way to get around this problem but it's not easy. You have to
subclass all child window controls in your parent window.
The reason why such inconvenience exists is that child window controls are
originally designed to work with a dialog box, not a normal window. The
default color of child window controls such as a button is gray because the
client area of a dialog box is normally gray so they blend into each other
without any sweat on the programmer's part.
Before we get deep into the detail, we should know first what a dialog box
is. A dialog box is nothing more than a normal window which is designed to
work with child window controls. Windows also provides internal "dialog box
manager" which is responsible for most of the keyboard logic such as
shifting input focus when the user presses Tab, pressing the default
pushbutton if Enter key is pressed, etc so programmers can deal with higher
level tasks. Dialog boxes are primarily used as input/output devices. As
such a dialog box can be considered as an input/output "black box" meaning
that you don't have to know how a dialog box works internally in order to
be able to use it, you only have to know how to interact with it. That's a
principle of object oriented programming (OOP) called information hiding.
If the black box is *perfectly* designed, the user can make use of it
without any knowledge on how it operates. The catch is that the black box
must be perfect, that's hard to achieve in the real world. Win32 API is
also designed as a black box too.
Well, it seems we stray from our path. Let's get back to our subject.
Dialog boxes are designed to reduce workload of a programmer. Normally if
you put child window controls on a normal window, you have to subclass them
and write keyboard logic yourself. But if you put them on a dialog box, it
will handle the logic for you. You only have to know how to get the user
input from the dialog box or how to send commands to it.
A dialog box is defined as a resource much the same way as a menu. You
write a dialog box template describing the characteristics of the dialog
box and its controls and then compile the resource script with a resource
editor.
Note that all resources are put together in the same resource script file.
You can use any text editor to write a dialog box template but I don't
recommend it. You should use a resource editor to do the job visually since
arranging child window controls on a dialog box is hard to do manually.
Several excellent resource editors are available. Most of the major
compiler suites include their own resource editors. You can use them to
create a resource script for your program and then cut out irrelevant lines
such as those related to MFC.
There are two main types of dialog box: modal and modeless. A modeless
dialog box lets you change input focus to other window. The example is the
Find dialog of MS Word. There are two subtypes of modal dialog box:
application modal and system modal. An application modal dialog box doesn't
let you change input focus to other window in the same application but you
can change the input focus to the window of OTHER application. A system
modal dialog box doesn't allow you to change input focus to any other
window until you respond to it first.
A modeless dialog box is created by calling CreateDialogParam API function.
A modal dialog box is created by calling DialogBoxParam. The only
distinction between an application modal dialog box and a system modal one
is the DS_SYSMODAL style. If you include DS_SYSMODAL style in a dialog box
template, that dialog box will be a system modal one.
You can communicate with any child window control on a dialog box by using
SendDlgItemMessage function. Its syntax is like this:
SendDlgItemMessage proto hwndDlg:DWORD,\
idControl:DWORD,\
uMsg:DWORD,\
wParam:DWORD,\
lParam:DWORD
This API call is immensely useful for interacting with a child window
control. For example, if you want to get the text from an edit control, you
can do this:
call SendDlgItemMessage, hDlg, ID_EDITBOX, WM_GETTEXT, 256, ADDR
text_buffer
In order to know which message to send, you should consult your Win32 API
reference.
Windows also provides several control-specific API functions to get and set
data quickly, for example, GetDlgItemText, CheckDlgButton etc. These
control-specific functions are provided for programmer's convenience so he
doesn't have to look up the meanings of wParam and lParam for each message.
Normally, you should use control-specific API calls when they're available
since they make source code maintenance easier. Resort to
SendDlgItemMessage only if no control-specific API calls are available.
The Windows dialog box manager sends some messages to a specialized
callback function called a dialog box procedure which has the following
format:
DlgProc proto hDlg:DWORD ,\
iMsg:DWORD ,\
wParam:DWORD ,\
lParam:DWORD
The dialog box procedure is very similar to a window procedure except for
the type of return value which is TRUE/FALSE instead of LRESULT. The
internal dialog box manager inside Windows IS the true window procedure for
the dialog box. It calls our dialog box procedure with some messages that
it received. So the general rule of thumb is that: if our dialog box
procedure processes a message,it MUST return TRUE in eax and if it does not
process the message, it must return FALSE in eax. Note that a dialog box
procedure doesn't pass the messages it does not process to the
DefWindowProc call since it's not a real window procedure.
There are two distinct uses of a dialog box. You can use it as the main
window of your application or use it as an input device. We 'll examine the
first approach in this tutorial.
"Using a dialog box as main window" can be interpreted in two different
senses.
1. You can use the dialog box template as a class template which you
register with RegisterClassEx call. In this case, the dialog box
behaves like a "normal" window: it receives messages via a window
procedure referred to by lpfnWndProc member of the window class, not
via a dialog box procedure. The benefit of this approach is that you
don't have to create child window controls yourself, Windows creates
them for you when the dialog box is created. Also Windows handles the
keyboard logic for you such as Tab order etc. Plus you can specify the
cursor and icon of your window in the window class structure.
Your program just creates the dialog box without creating any parent
window. This approach makes a message loop unnecessary since the
messages are sent directly to the dialog box procedure. You don't even
have to register a window class!
This tutorial is going to be a long one. I'll present the first approach
followed by the second.
Application
-----------
------------------------------------------------------------------------
dialog.asm
------------------------------------------------------------------------
.386
.model flat,stdcall
option casemap:none
WinMain proto :DWORD,:DWORD,:DWORD,:DWORD
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
.data
ClassName db "DLGCLASS",0
MenuName db "MyMenu",0
DlgName db "MyDialog",0
AppName db "Our First Dialog Box",0
TestString db "Wow! I'm in an edit box now",0
.data?
hInstance HINSTANCE ?
CommandLine LPSTR ?
buffer db 512 dup(?)
.const
IDC_EDIT equ 3000
IDC_BUTTON equ 3001
IDC_EXIT equ 3002
IDM_GETTEXT equ 32000
IDM_CLEAR equ 32001
IDM_EXIT equ 32002
.code
start:
invoke GetModuleHandle, NULL
mov hInstance,eax
invoke GetCommandLine
invoke WinMain, hInstance,NULL,CommandLine, SW_SHOWDEFAULT
invoke ExitProcess,eax
WinMain proc
hInst:HINSTANCE,hPrevInst:HINSTANCE,CmdLine:LPSTR,CmdShow:DWORD
LOCAL wc:WNDCLASSEX
LOCAL msg:MSG
LOCAL hDlg:HWND
mov wc.cbSize,SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov wc.lpfnWndProc, OFFSET WndProc
mov wc.cbClsExtra,NULL
mov wc.cbWndExtra,DLGWINDOWEXTRA
push hInst
pop wc.hInstance
mov wc.hbrBackground,COLOR_BTNFACE+1
mov wc.lpszMenuName,OFFSET MenuName
mov wc.lpszClassName,OFFSET ClassName
invoke LoadIcon,NULL,IDI_APPLICATION
mov wc.hIcon,eax
mov wc.hIconSm,eax
invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor,eax
invoke RegisterClassEx, addr wc
invoke CreateDialogParam,hInstance,ADDR DlgName,NULL,NULL,NULL
mov hDlg,eax
invoke ShowWindow, hDlg,SW_SHOWNORMAL
invoke UpdateWindow, hDlg
invoke GetDlgItem,hDlg,IDC_EDIT
invoke SetFocus,eax
.WHILE TRUE
invoke GetMessage, ADDR msg,NULL,0,0
.BREAK .IF (!eax)
invoke IsDialogMessage, hDlg, ADDR msg
.IF eax ==FALSE
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.ENDIF
.ENDW
mov eax,msg.wParam
ret
WinMain endp
WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.IF uMsg==WM_DESTROY
invoke PostQuitMessage,NULL
.ELSEIF uMsg==WM_COMMAND
mov eax,wParam
.IF lParam==0
.IF ax==IDM_GETTEXT
invoke GetDlgItemText,hWnd,IDC_EDIT,ADDR buffer,512
invoke MessageBox,NULL,ADDR buffer,ADDR AppName,MB_OK
.ELSEIF ax==IDM_CLEAR
invoke SetDlgItemText,hWnd,IDC_EDIT,NULL
.ELSE
invoke DestroyWindow,hWnd
.ENDIF
.ELSE
mov edx,wParam
shr edx,16
.IF dx==BN_CLICKED
.IF ax==IDC_BUTTON
invoke SetDlgItemText,hWnd,IDC_EDIT,ADDR TestString
.ELSEIF ax==IDC_EXIT
invoke SendMessage,hWnd,WM_COMMAND,IDM_EXIT,0
.ENDIF
.ENDIF
.ENDIF
.ELSE
invoke DefWindowProc,hWnd,uMsg,wParam,lParam
ret
.ENDIF
xor eax,eax
ret
WndProc endp
end start
------------------------------------------------------------------------
Dialog.rc
------------------------------------------------------------------------
#include "resource.h"
#define IDC_EDIT 3000
#define IDC_BUTTON 3001
#define IDC_EXIT 3002
#define IDM_GETTEXT 32000
#define IDM_CLEAR 32001
#define IDM_EXIT 32003
MyDialog DIALOG 10, 10, 205, 60
STYLE 0x0004 | DS_CENTER | WS_CAPTION | WS_MINIMIZEBOX |
WS_SYSMENU | WS_VISIBLE | WS_OVERLAPPED | DS_MODALFRAME | DS_3DLOOK
CAPTION "Our First Dialog Box"
CLASS "DLGCLASS"
BEGIN
EDITTEXT IDC_EDIT, 15,17,111,13, ES_AUTOHSCROLL | ES_LEFT
DEFPUSHBUTTON "Say Hello", IDC_BUTTON, 141,10,52,13
PUSHBUTTON "E&xit", IDC_EXIT, 141,26,52,13, WS_GROUP
END
MyMenu MENU
BEGIN
POPUP "Test Controls"
BEGIN
MENUITEM "Get Text", IDM_GETTEXT
MENUITEM "Clear Text", IDM_CLEAR
MENUITEM "", , 0x0800 /*MFT_SEPARATOR*/
MENUITEM "E&xit", IDM_EXIT
END
END
Analysis
--------
Let's analyze this first example.
This example shows how to register a dialog template as a window class and
create a "window" from that class. It simplifies your program since you
don't have to create the child window controls yourself.
Let's first analyze the dialog template.
MyDialog DIALOG 10, 10, 205, 60
Declare the name of a dialog, in this case, "MyDialog" followed by the
keyword "DIALOG". The following four numbers are: x, y , width, and height
of the dialog box in dialog box units (not the same as pixels).
STYLE 0x0004 | DS_CENTER | WS_CAPTION | WS_MINIMIZEBOX |
WS_SYSMENU | WS_VISIBLE | WS_OVERLAPPED | DS_MODALFRAME | DS_3DLOOK
Declare the styles of the dialog box.
CAPTION "Our First Dialog Box"
This is the text that will appear in the dialog box's title bar.
CLASS "DLGCLASS"
This line is crucial. It's this CLASS keyword that allows us to use the
dialog box template as a window class. Following the keyword is the name of
the "window class"
BEGIN
EDITTEXT IDC_EDIT, 15,17,111,13, ES_AUTOHSCROLL | ES_LEFT
DEFPUSHBUTTON "Say Hello", IDC_BUTTON, 141,10,52,13
PUSHBUTTON "E&xit", IDC_EXIT, 141,26,52,13
END
The above block defines the child window controls in the dialog box.
They're defined between BEGIN and END keywords. Generally the syntax is as
follows:
control-type "text" ,controlID, x, y, width, height [,styles]
control-types are resource compiler's constants so you have to consult the
manual.
Now we go to the assembly source code. The interesting part is in the
window class structure:
mov wc.cbWndExtra,DLGWINDOWEXTRA
mov wc.lpszClassName,OFFSET ClassName
Normally, this member is left NULL, but if we want to register a dialog box
template as a window class, we must set this member to the value
DLGWINDOWEXTRA. Note that the name of the class must be identical to the
one following the CLASS keyword in the dialog box template. The remaining
members are initialized as usual. After you fill the window class
structure, register it with RegisterClassEx. Seems familiar? This is the
same routine you have to do in order to register a normal window class.
invoke CreateDialogParam,hInstance,ADDR DlgName,NULL,NULL,NULL
After registering the "window class", we create our dialog box. In this
example, I create it as a modeless dialog box with CreateDialogParam
function. This function takes 5 parameters but you only have to fill in the
first two: the instance handle and the pointer to the name of the dialog
box template. Note that the 2nd parameter is not a pointer to the class
name.
At this point, the dialog box and its child window controls are created by
Windows. Your window procedure will receive WM_CREATE message as usual.
invoke GetDlgItem,hDlg,IDC_EDIT
invoke SetFocus,eax
After the dialog box is created, I want to set the input focus to the edit
control. If I put these codes in WM_CREATE section, GetDlgItem call will
fail since at that time, the child window controls are not created yet. The
only way you can do this is to call it after the dialog box and all its
child window controls are created. So I put these two lines after the
UpdateWindow call. GetDlgItem function gets the control ID and returns the
associated control's window handle. This is how you can get a window handle
if you know its control ID.
invoke IsDialogMessage, hDlg, ADDR msg
.IF eax ==FALSE
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.ENDIF
The program enters the message loop and before we translate and dispatch
messages, we call IsDialogMessage function to let the dialog box manager
handles the keyboard logic of our dialog box for us. If this function
returns TRUE , it means the message is intended for the dialog box and is
processed by the dialog box manager. Note another difference from the
previous tutorial. When the window procedure wants to get the text from the
edit control, it calls GetDlgItemText function instead of GetWindowText.
GetDlgItemText accepts a control ID instead of a window handle. That makes
the call easier in the case you use a dialog box.
------------------------------------------------------------------------
Now let's go to the second approach to using a dialog box as a main window.
In the next example, I 'll create an application modal dialog box. You'll
not find a message loop or a window procedure because they're not
necessary!
------------------------------------------------------------------------
dialog.asm (part 2)
------------------------------------------------------------------------
.386
.model flat,stdcall
option casemap:none
DlgProc proto :DWORD,:DWORD,:DWORD,:DWORD
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
.data
DlgName db "MyDialog",0
AppName db "Our Second Dialog Box",0
TestString db "Wow! I'm in an edit box now",0
.data?
hInstance HINSTANCE ?
CommandLine LPSTR ?
buffer db 512 dup(?)
.const
IDC_EDIT equ 3000
IDC_BUTTON equ 3001
IDC_EXIT equ 3002
IDM_GETTEXT equ 32000
IDM_CLEAR equ 32001
IDM_EXIT equ 32002
.code
start:
invoke GetModuleHandle, NULL
mov hInstance,eax
invoke DialogBoxParam, hInstance, ADDR DlgName,NULL, addr DlgProc, NULL
invoke ExitProcess,eax
DlgProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.IF uMsg==WM_INITDIALOG
invoke GetDlgItem, hWnd,IDC_EDIT
invoke SetFocus,eax
.ELSEIF uMsg==WM_CLOSE
invoke SendMessage,hWnd,WM_COMMAND,IDM_EXIT,0
.ELSEIF uMsg==WM_COMMAND
mov eax,wParam
.IF lParam==0
.IF ax==IDM_GETTEXT
invoke GetDlgItemText,hWnd,IDC_EDIT,ADDR buffer,512
invoke MessageBox,NULL,ADDR buffer,ADDR AppName,MB_OK
.ELSEIF ax==IDM_CLEAR
invoke SetDlgItemText,hWnd,IDC_EDIT,NULL
.ELSEIF ax==IDM_EXIT
invoke EndDialog, hWnd,NULL
.ENDIF
.ELSE
mov edx,wParam
shr edx,16
.if dx==BN_CLICKED
.IF ax==IDC_BUTTON
invoke SetDlgItemText,hWnd,IDC_EDIT,ADDR TestString
.ELSEIF ax==IDC_EXIT
invoke SendMessage,hWnd,WM_COMMAND,IDM_EXIT,0
.ENDIF
.ENDIF
.ENDIF
.ELSE
mov eax,FALSE
ret
.ENDIF
mov eax,TRUE
ret
DlgProc endp
end start
------------------------------------------------------------------------
dialog.rc (part 2)
------------------------------------------------------------------------
#include "resource.h"
#define IDC_EDIT 3000
#define IDC_BUTTON 3001
#define IDC_EXIT 3002
#define IDR_MENU1 3003
#define IDM_GETTEXT 32000
#define IDM_CLEAR 32001
#define IDM_EXIT 32003
MyDialog DIALOG 10, 10, 205, 60
STYLE 0x0004 | DS_CENTER | WS_CAPTION | WS_MINIMIZEBOX |
WS_SYSMENU | WS_VISIBLE | WS_OVERLAPPED | DS_MODALFRAME | DS_3DLOOK
CAPTION "Our Second Dialog Box"
MENU IDR_MENU1
BEGIN
EDITTEXT IDC_EDIT, 15,17,111,13, ES_AUTOHSCROLL | ES_LEFT
DEFPUSHBUTTON "Say Hello", IDC_BUTTON, 141,10,52,13
PUSHBUTTON "E&xit", IDC_EXIT, 141,26,52,13
END
IDR_MENU1 MENU
BEGIN
POPUP "Test Controls"
BEGIN
MENUITEM "Get Text", IDM_GETTEXT
MENUITEM "Clear Text", IDM_CLEAR
MENUITEM "", , 0x0800 /*MFT_SEPARATOR*/
MENUITEM "E&xit", IDM_EXIT
END
END
------------------------------------------------------------------------
The analysis follows:
DlgProc proto :DWORD,:DWORD,:DWORD,:DWORD
We declare the function prototype for DlgProc so we can refer to it with
addr operator in the line below:
invoke DialogBoxParam, hInstance, ADDR DlgName,NULL, addr DlgProc, NULL
The above line calls DialogBoxParam function which takes 5 parameters: the
instance handle, the name of the dialog box template, the parent window
handle, the address of the dialog box procedure, and the dialog-specific
data. DialogBoxParam creates a modal dialog box. It will not return until
the dialog box is destroyed.
.IF uMsg==WM_INITDIALOG
invoke GetDlgItem, hWnd,IDC_EDIT
invoke SetFocus,eax
.ELSEIF uMsg==WM_CLOSE
invoke SendMessage,hWnd,WM_COMMAND,IDM_EXIT,0
The dialog box procedure looks like a window procedure except that it
doesn't receive WM_CREATE message. The first message it receives is
WM_INITDIALOG. Normally you can put the initialization code here. Note that
you must return the value TRUE in eax if you process the message.
The internal dialog box manager doesn't send our dialog box procedure the
WM_DESTROY message by default when WM_CLOSE is sent to our dialog box. So
if we want to react when the user presses the close button on our dialog
box, we must process WM_CLOSE message. In our example, we send WM_COMMAND
message with the value IDM_EXIT in wParam. This has the same effect as when
the user selects Exit menu item. EndDialog is called in response to
IDM_EXIT.
The processing of WM_COMMAND messages remains the same.
When you want to destroy the dialog box, the only way is to call EndDialog
function. Do not try DestroyWindow! EndDialog doesn't destroy the dialog
box immediately. It only sets a flag for the internal dialog box manager
and continues to execute the next instructions.
Now let's examine the resource file. The notable change is that instead of
using a text string as menu name we use a value, IDR_MENU1. This is
necessary if you want to attach a menu to a dialog box created with
DialogBoxParam. Note that in the dialog box template, you have to add the
keyword MENU followed by the menu resource ID.
A difference between the two examples in this tutorial that you can readily
observe is the lack of an icon in the latter example. However, you can set
the icon by sending the message WM_SETICON to the dialog box during
WM_INITDIALOG.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................WIN32.ASSEMBLY.PROGRAMMING
Standardizing Win32 Callback Procedures
by Jeremy Gordon
This short article describes my preferred method for coding CALLBACK procedures
in a large assembler program for Windows 32. First I describe what Win32
callback procedures are, and then get down to some code.
At run time the Win32 system will call your program on a regular and frequent
basis. The procedures you supply for the system to call are called CALLBACK
procedures. Here are examples of when these are used:-
1. To manage a window you created. In this case the system will send many
messages to the Window Procedure for the window. The Window Procedure is
the code label you provide when you register your window class (by calling
RegisterClass). For example the message WM_SIZE is sent by the system
when the window is resized.
2. To inform the owner of a child window of events in the child window. For
example WM_PARENTNOTIFY (with a notify code) is sent to the Window
Procedure of the owner of a window when the child window is being created
or destroyed, or if the user clicks a mouse button while the cursor is
over the child window.
3. To inform the owner of a common control of events in the control. For
example if you create a button owned by your window the Window Procedure
for that window receives BN_CLICKED messages if the button is clicked.
4. Messages sent to a dialog you have created. These are messages relating
to the creation of the dialog and of the various controls. The dialog
procedure is informed of events in the controls.
5. If you "Superclass" or "Subclass" a common control, you receive messages
for that common control like a hook procedure but your window procedure
has the responsibility of passing them on to the control.
6. If you create "Hook" procedures you can intercept messages about to be sent
to other windows. The system will call your hook procedure and will pass
the message on only when your hook procedure returns.
7. You can ask the system to provide your program with information to be sent
to a CALLBACK procedure. Examples are EnumWindows (enumerate all top-level
windows) or EnumFonts (enumerate all available fonts).
In cases 1 to 5 above, just before the system calls the CALLBACK procedure,
it PUSHES 4 dwords on the stack (ie. 4 "parameters"). Traditionally the
names given to these parameters are:-
hWnd = handle of window being called
uMsg = message number
wParam = a parameter sent with the message
lParam = another parameter sent with the message.
The number of parameters sent to hook procedures and emumeration
callbacks varies - see the Window SDK.
Since your Window (or Dialog) procedure will need to react in a certain
way depending on the message being sent, your code will need to divert
execution to the correct place for a particular message.
"C" programmers have the advantage of being able to code this simply,
using "switch" and "case".
Assembler programmers use various techniques. Perhaps the worst if there are
a lot of messages to handle is the chain of compares, eg. (in A386 format):-
MOV EAX,[EBP+0Ch] ;get message number
CMP EAX,1h ;see if WM_CREATE
JNZ >L2 ;no
XOR EAX,EAX ;ensure eax is zero on exit
JMP >L32 ;finish
L2:
CMP EAX,116h ;see if WM_INITMENU
JNZ >L4 ;no
CALL INITIALISE_MENU
JMP >L30 ;correct exit code
L4:
CMP EAX,47h ;see if WM_WINDOWPOSCHANGED
JNZ >L8
and so on ........
To avoid these long chains, assembler programmers have developed various
techniques. You will have seen many of these in sample code around Win32
assembler web sites and in the asm journal, using conditional jumps, macros
or table scans. I do not wish to compare these various methods, merely to put
forward my own current favourite, which I believe has these advantages:-
1. It works on all assemblers
2. It is modular, ie. the code for each window can be concentrated in a
particular part of your source code
3. It is easy to follow from the source code what message causes what result
4. The same function can easily be called from within different window
procedures
My method results in a very simple Window Procedure as follows (A386 format):-
WndProc:
MOV EDX,OFFSET MAINMESSAGES
CALL GENERAL_WNDPROC
RET 10h
where the messages and functions (specific to this particular window
procedure) are set out in a table such as this:-
;----------------------------------------------------------
DATA SEGMENT FLAT ;assembler to put following in data section
;--------------------------- WNDPROC message functions
MAINMESSAGES DD ENDOF_MAINMESSAGES-$ ;=number to be done
DD 312h,HOTKEY,116h,INITMENU,117h,INITMENUPOPUP,11Fh,MENUSELECT
DD 1h,CREATE,2h,DESTROY, 410h,OWN410,411h,OWN411
DD 231h,ENTERSIZEMOVE,47h,WINDOWPOSCHANGED,24h,GETMINMAXINFO
DD 1Ah,SETTINGCHANGE,214h,SIZING,46h,WINDOWPOSCHANGING
DD 2Bh,DRAWITEM,0Fh,PAINT,113h,TIMER,111h,COMMAND
DD 104h,SYSKEYDOWN,100h,KEYDOWN,112h,SYSCOMMAND
DD 201h,LBUTTONDOWN,202h,LBUTTONUP,115h,SCROLLMESS
DD 204h,RBUTTONDOWNUP,205h,RBUTTONDOWNUP
DD 200h,MOUSEMOVE,0A0h,NCMOUSEMOVE,20h,SETCURSORM
DD 4Eh,NOTIFY,210h,PARENTNOTIFY,86h,NCACTIVATE,6h,ACTIVATE
DD 1Ch,ACTIVATEAPP
ENDOF_MAINMESSAGES: ;label used to work out how many messages
;----------------------------------------------------------
_TEXT SEGMENT FLAT ;assembler to put following in code section
;----------------------------------------------------------
and where each of the functions here are procedures, for example:-
CREATE:
XOR EAX,EAX ;ensure zero and nc return
RET
and where GENERAL_WINDPROC is as follows:-
GENERAL_WNDPROC:
PUSH EBP
MOV EBP,[ESP+10h] ;get uMsg in ebp
MOV ECX,[EDX] ;get number of messages to do * 8 (+4)
SHR ECX,3 ;get number of messages to do
ADD EDX,4 ;jump over size dword
L33:
DEC ECX
JS >L46 ;s=message not found
CMP [EDX+ECX*8],EBP ;see if its the correct message
JNZ L33 ;no
MOV EBP,ESP
PUSH ESP,EBX,EDI,ESI ;save registers as required by Windows
ADD EBP,4 ;allow for the extra call to here
;now [EBP+8]=hWnd,[EBP+0Ch]=uMsg,[EBP+10h]=wParam,[EBP+14h]=lParam
CALL [EDX+ECX*8+4] ;call correct procedure for the message
POP ESI,EDI,EBX,ESP
JNC >L48 ;nc=don't call DefWindowProc eax=exit code
L46:
PUSH [ESP+18h],[ESP+18h],[ESP+18h],[ESP+18h] ;ESP changes on push
CALL DefWindowProcA
L48:
POP EBP
RET
NOTES:
-------------------------------------------------------------------------------
1. Instead of giving the actual message value, you can, of course, give
the name of an EQUATE. For example
WM_CREATE EQU 1h
enables you to use WM_CREATE,CREATE instead of 1h,CREATE if you wish.
2. It is tempting to keep the message table in the CODE SECTION. This is
perfectly possible because the only difference to the Win32 system between
the code section and the data section is that the code section area of
memory is marked read only, whereas the data section is read/write.
However, you may well get some loss of performance if you do this because
most processors will read data more quickly from the data section.
I performed some tests on this and found that having the table in the code
section rather than the data section could slow the code considerably:-
486 processor - 22% to 36% slower
Pentium processor - 94% to 161% slower
AMD-K6-3D processor - 78% to 193% slower
(but Pentium Pro - from 7% faster to 9% slower)
(and Pentium II - from 29% faster to 5% slower)
These tests were carried out on a table of 60 messages and the range of
results is because tests were carried out varying the number of scans
required before a find and also testing a no-find.
3. The procedure names must not be the names of API imports to avoid
confusion! For example change SETCURSOR slightly to avoid confusion
with the API SetCursor.
4. If a function returns c (carry flag set) the window procedure will call
DefWindowProc. An nc return (carry flag not set) will merely return to
the system with the return code in eax. (Some messages must be dealt with
in this way).
5. You can send a parameter of your own to GENERAL_WNDPROC using EAX.
This is useful if you wish to identify a particular window.
For example:-
SpecialWndProc:
MOV EAX,OFFSET hSpecialWnd
MOV EDX,OFFSET SPECIALWND_MESSAGES
CALL GENERAL_WNDPROC
RET 10h
6. The ADD EBP,4 just before the call to the function is to ensure that
EBP points to the parameters the stack in the same way as if the window
procedure had been entered normally. This is intended to ensure that
the function will be compatible if called by an ordinary window procedure
written in assembler, for example:-
WndProc:
PUSH EBP
MOV EBP,ESP
;now [EBP+8]=hWnd,[EBP+0Ch]=uMsg,[EBP+10h]=wParam,[EBP+14h]=lParam
7. A standardized procedure for dealing with messages to a dialog procedure
can also be created in the same way, except that it should return TRUE
(eax=1) if the message is processed and FALSE (eax=0) if it is not, without
calling DefWindowProc. The same coding method can be applied to hooks and
to enumerator CALLBACKS although these will vary.
jorgon@compuserve.com
http://ourworld.compuserve.com/homepages/jorgon
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::............................................THE.UNIX.WORLD
Fire Demo ported to Linux SVGAlib
by Jan Wagemakers
In APJ4 there was a little nice fire demo written in DOS assembly language.
I have ported this program to Linux assembly language. It is written in the
AT&T-syntax (GNU assembler) and makes use of SVGAlib.
My main goal of porting this program to Linux was to show that it can be
done. So, I have not optimized this program. For example, things like 'call
ioperm' can also be done by making use of int 0x80; quite possibly making use
of int 0x80 will make the program smaller. More information about int 0x80 is
available at Konstantin Boldyshev's webpage [http://lightning.voshod.com/asm].
With SVGALib you can access the screen memory directly, just like you
would write to A000:0000 in a DOS asm-program.
I like to thank 'paranoya' for his explanation about how to make use of
SVGAlib. Anyway, enough blablabla, here is the source ;-)
# fire.s : fire.asm of apj 4 ported to Linux/SVGAlib ==========================
# gcc -o fire fire.s -lvga
.globl main
.type main,@function
main:
pushl %ebp
movl %esp,%ebp
call vga_init # Init vga
pushl $5
call vga_setmode # set mode to 5 = 320x200x256
addl $4,%esp
pushl $0
call vga_setpage # Point to page 0 (There is only 1 page)
addl $4,%esp
pushl $0x3c8 # Get IOpermission, starting from 3c8h
pushl $2 # to 3c9h
pushl $1 # Turn On value
call ioperm
addl $12,%esp
pushl $0x60 # Get IOpermission, for 60h : keyboard
pushl $1
Pushl $1
call ioperm
addl $12,%esp
inb $0x60,%al # Read current value of keyboard
movb %al,key
movw $0x3c8,%dx
movw $0,%ax
outb %al,%dx
incw %dx
lus:
outb %al,%dx
outb %al,%dx
outb %al,%dx
incw %ax
jnz lus
movl graph_mem,%ebx
Mainloop:
movl $1280,%esi # mov si,1280 ;
movl $0x5d00,%ecx # mov ch,5dh ; y-pos, the less the faster demo
pushl %esi # push si
pushl %ecx # push cx
Sloop:
movb (%ebx,%esi),%al # lodsb
incl %esi #
addb (%ebx,%esi),%al # al,[si] ; pick color and
addb 320(%ebx,%esi),%al # add al,[si+320] ; pick one more and
shrb $2,%al # shr al,2
movb %al,-960(%ebx,%esi) # mov [si-960],al ; put color
loop Sloop
popl %edi # pop di
popl %ecx # pop cx
Randoml:
mulw 1(%ebx,%edi) # mul word ptr [di+1] ; 'random' routine.
incw %ax
movw %ax,(%ebx,%edi) #stosw
incl %edi
incl %edi
loop Randoml
inb $0x60,%al
cmpb key,%al
jz Mainloop
pushl $0
call exit
addl $4,%esp
movl %ebp,%esp
popl %ebp
ret
.data
key:
.byte 0
# =============================================================================
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::................................ASSEMBLY.LANGUAGE.SNIPPETS
Abs
by Chris Dragan
;Summary: Calculates absolute value of a signed integer in eax.
;Compatibility: 386+
;Notes: 9 bytes, 4 clocks (P5), destroys ecx
mov ecx, eax ; Duplicate value
shr ecx, 31 ; Fill ecx with its sign
xor eax, ecx ; Do 'not eax' if negative
sub eax, ecx ; Do 'inc eax' if negative
; For comparison, the standard way (2-8 clocks on P5 and 1-17 on P6):
; or eax, eax
; js @@1
; neg eax
;@@1:
Min
by Chris Dragan
;Summary: eax = min (eax, ecx) (both eax and ecx unsigned)
;Compatibility: 386+
;Notes: 8 bytes, 4 clocks (P5), destroys ecx and edx
sub ecx, eax ; ecx = n2 - n1
sbb edx, edx ; edx = (n1 > n2) ? -1 : 0
and ecx, edx ; ecx = (n1 > n2) ? (n2 - n1) : 0
add eax, ecx ; eax += (n1 > n2) ? (n2 - n1) : 0
; Standard cmp/jbe/mov takes 2-8 clocks on P5 and 1-17 on P6
Max
by Chris Dragan
;Summary: eax = max (eax, ecx) (both eax and ecx unsigned)
;Compatibility: 386+
;Notes: 9 bytes, 5 clocks (P5), destroys ecx and edx
sub ecx, eax ; ecx = n2 - n1
cmc ; cf = n1 <= n2
sbb edx, edx ; edx = (n1 > n2) ? 0 : -1
and ecx, edx ; ecx = (n1 > n2) ? 0 : (n2 - n1)
add eax, ecx ; eax += (n1 > n2) ? 0 : (n2 - n1)
; Standard cmp/jae/mov takes 2-8 clocks on P5 and 1-17 on P6
OBJECT
by mammon_
;Summary: Primitive for defining dynamic objects
;Compatibility: NASM
;Notes: The basic building block for classes in NASM; part of
; an ongoing project of mine. Note that .this can be
; filled with the instance pointer, and additional
; routines such as .%1 [constructor] and .~ can be added.
%macro OBJECT 1
struc %1
.this: resd 1
%endmacro
%macro END_OBJECT 0
endstruc
%endmacro
;_Sample:________________________________________________________________
;OBJECT MSGBOX
; .hWnd: resd 1
; .lpText: resd 1
; .lpCapt: resd 1
; .uInt: resd 1
; .show: resd 1
;END_OBJECT
;;MyMBox is a pointer to a location in memory or in an istruc; its members
;;are filled in an init routine ['new'] with "show" being "DD _show"
;_show: ;MSGBOX class display routine
; push dword [MyMbox + MSGBOX.uInt]
; push dword [MyMbox + MSGBOX.lpCapt]
; push dword [MyMbox + MSGBOX.lpText]
; push dword [MyMbox + MSGBOX.hWnd]
; call MessageBoxA
; ret
;..start:
; call [MyMbox + MSGBOX.show]
; ret
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::...........................................ISSUE.CHALLENGE
Binary-to-ASCII
by Jan Verhoeven
The Challenge
-------------
Write a routine to convert the value of a bit to ASCII in under 10 bytes, with
no conditional jumps.
The Solution
------------
Load the number into the AX register and shift through the bits. If a bit is
cleared [0], you want to print a "0" character; if a bit is set [1], you want
to print a "1".
Prime the BL register with the ASCII character "0"; if the next bit in AX is
set, carry will be set after the SHL and BL will thus be incremented to an
ASCII "1". The key, as you will see, is the ADC [AddWithCarry] instruction:
L0: B330 MOV BL,30 ; try with al = ZERO
D1E0 SHL AX,1 ; ... but if bit = set, ...
80D300 ADC BL,00 ; ... make it a ONE,
7 bytes all told; with a loop and mov instruction for storing each value in
BL to the location of your choice, you will have a full-fledged binary-to-
ascii converter in a handful of bytes.
::/ \::::::.
:/___\:::::::.
/| \::::::::.
:| _/\:::::::::.
:| _|\ \::::::::::.
:::\_____\:::::::::::.......................................................FIN
Assembly Programming Journals: Previous — 1 — 2 — 3 — 4 — 5 — 6 — 7 — 8 — 9 — Next