Structures in Assembly Language
Randall Hyde
I've read several posts concerning structures and their
implementation in assembly language. Given some
misconceptions about structures in assembly language,
I pieced together the following article about structures
in assembly.
Cheers,
Randy Hyde
Structures in Assembly Language Programs
Structures, or records, are an abstract data type
that allows a programmer to collect different
objects together into a single, com- posite,
object. Structures can help make programs easier
to read, write, modify, and maintain. Used
appropriately, they can also help your programs
run faster. Despite the advantages that structures
offer, their appearance in assembly language is a
relatively recent phenomenon (in the past two
decades, or so), and many assemblers still do not
support this facility. Furthermore, many
"old-timer" assembly language programmers attempt
to argue that the appear- ance of records violates
the whole principle of "assembly language
programming." This article will certain refute
such arguments and describe the benefits of using
structures in an assembly language program.
Despite the fact that records have been available
in various assembly languages for years (e.g.,
Microsoft's MASM assembler introduced structures
in 80x86 assembly language in the 1980s), the
"lack of support for structures" is a common
argument against assembly language by HLL
programmers who don't know much about assembly.
In some respects, their ignorance is justified --
many assemblers don't support structures or
records. A second goal of this article is to
educate assembly language programmers to counter
claims like "assembly language doesn't support
struc- tures." Hopefully, that same education will
convince those assem- bly language programmers
who've never bothered to use structures, to
consider their use.
This article will use the term "record" to denote
a struc- ture/record to avoid confusion with the
more general term "data structure". Note,
however, that the terms "record" and "structure"
are synonymous in this article.
What is a Record (Structure)?
The whole purpose of a record is to let you
encapsulate differ- ent, but logically related,
data into a single package. Here is a typi- cal
record declaration, in HLA using the RECORD /
ENDRECORD declaration:
type
student:
record
Name: string;
Major: int16;
SSN: char[12];
Midterm1: int16;
Midterm2: int16;
Final: int16;
Homework: int16;
Projects: int16;
endrecord;
The field names within the record must be unique.
That is, the same name may not appear two or more
times in the same record. However, in reasonable
assemblers (like HLA) that support true
structures, all the field names are local to that
record. With such assemblers, you may reuse those
field names elsewhere in the pro- gram.
The RECORD/ENDRECORD type declaration may appear
in a variable declaration section (e.g., an HLA
STATIC or VAR section) or in a TYPE declaration
section. In the previous example the Stu- dent
declaration appears in an HLA TYPE section, so
this does not actually allocate any storage for a
Student variable. Instead, you have to
explicitly declare a variable of type Student.
The following example demonstrates how to do
this:
var
John: Student;
This allocates 28 bytes of storage: four bytes for
the Name field (HLA strings are four-byte
pointers to character data found else- where in
memory), 12 bytes for the SSN field, and two bytes
for each of the other six fields.
If the label John corresponds to the base address
of this record, then the Name field is at offset
John+0, the Major field is at offset John+4, the
SSN field is at offset John+6, etc.
To access an element of a structure you need to
know the offset from the beginning of the
structure to the desired field. For exam- ple, the
Major field in the variable John is at offset 4
from the base address of John. Therefore, you
could store the value in AX into this field using
the instruction
mov( ax, (type word John[4]) );
Unfortunately, memorizing all the offsets to
fields in a record defeats the whole purpose of
using them in the first place. After all, if
you've got to deal with these numeric offsets why
not just use an array of bytes instead of a
record?
Well, as it turns out, assemblers like HLA that
support true records commonly let you refer to
field names in a record using the same mechanism
C/C++ and Pascal use: the dot operator. To store
AX into the Major field, you could use "mov( ax,
John.Major );" instead of the previous
instruction. This is much more readable and
certainly easier to use.
Record Constants
HLA lets you define record constants. In fact,
HLA is probably unique among x86 assemblers
insofar as it supports both symbolic record
constants and literal record constants. Record
constants are useful as initializers for static
record variables. They are also quite useful as
compile-time data structures when using the HLA
com- pile-time language (that is, the macro
processor language). This section discusses how
to create record constants.
A record literal constant takes the following form:
RecordTypeName:[ List_of_comma_separated_constants ]
The RecordTypeName is the name of a record data
type you've defined in an HLA TYPE section prior
to this point. To create a record constant you
must have previously defined the record type in a
TYPE section of your program.
The constant list appearing between the brackets
are the data items for each of the fields in the
specified record. The first item in the list
corresponds to the first field of the record, the
second item in the list corresponds to the second
field, etc. The data types of each of the
constants appearing in this list must match their
respective field types. The following example
demonstrates how to use a lit- eral record
constant to initialize a record variable:
type
point:
record
x:int32;
y:int32;
z:int32;
endrecord;
static
Vector: point := point:[ 1, -2, 3 ];
This declaration initializes Vector.x with 1,
Vector.y with -2, and Vector.z with 3.
You can also create symbolic record constants by
declaring record objects in the CONST or VAL
sections of an HLA program. You access fields of
these symbolic record constants just as you would
access the field of a record variable, using the
dot operator. Since the object is a constant,
you can specify the field of a record constant
anywhere a constant of that field's type is legal.
You can also employ symbolic record constants as
record variable initializ- ers. The following
example demonstrates this:
type
point:
record
x:int32;
y:int32;
z:int32;
endrecord;
const
PointInSpace: point := point:[ 1, 2, 3 ];
static
Vector: point := PointInSpace;
XCoord: int32 := PointInSpace.x;
Arrays of Records
It is a perfectly reasonable operation to create
an array of records. To do so, you simply create
a record type and then use the standard array
declaration syntax when declaring an array of that
record type. The following example demonstrates
how you could do this:
type
recElement:
record
<< fields for this record >>
endrecord;
.
.
.
static
recArray: recElement[4];
Naturally, you can create multidimensional arrays
of records as well. You would use the standard
row or column major order func- tions to compute
the address of an element within such records.
The only thing that really changes (from the
discussion of arrays) is that the size of each
element is the size of the record object.
static
rec2D: recElement[ 4, 6 ];
Arrays and Records as Record Fields
Records may contain other records or arrays as
fields. Consider the following definition:
type
Pixel:
record
Pt: point;
color: dword;
endrecord;
The definition above defines a single point with a
32 bit color component. When initializing an
object of type Pixel, the first ini- tializer
corresponds to the Pt field, not the x-coordinate
field. The following definition is incorrect:
static
ThisPt: Pixel := Pixel:[ 5, 10 ]; // Syntactically incorrect!
The value of the first field ('5') is not an
object of type point. Therefore, the assembler
generates an error when encountering this
statement. HLA will allow you to initialize the
fields of Pixel using declarations like the
following:
static
ThisPt: Pixel := Pixel:[ point:[ 1, 2, 3 ], 10 ];
ThatPt: Pixel := Pixel:[ point:[ 0, 0, 0 ], 5 ];
Accessing Pixel fields is very easy. Like a high
level language you use a single period to
reference the Pt field and a second period to
access the x, y, and z fields of point:
stdout.put( "ThisPt.Pt.x = ", ThisPt.Pt.x,
nl );
stdout.put( "ThisPt.Pt.y = ", ThisPt.Pt.y,
nl );
stdout.put( "ThisPt.Pt.z = ", ThisPt.Pt.z,
nl );
.
.
.
mov( eax, ThisPt.Color );
You can also declare arrays as record fields. The
following record creates a data type capable of
representing an object with eight points (e.g., a
cube):
type
Object8:
record
Pts: point[8];
Color: dword;
endrecord;
There are two common ways to nest record
definitions. As noted earlier in this section,
you can create a record type in a TYPE section
and then use that type name as the data type of
some field within a record (e.g., the Pt:point
field in the Pixel data type above). It is also
possible to declare a record directly within
another record without creating a separate data
type for that record; the following example
demonstrates this:
type
NestedRecs:
record
iField: int32;
sField: string;
rField:
record
i:int32;
u:uns32;
endrecord;
cField:char;
endrecord;
Generally, it's a better idea to create a separate
type rather than embed records directly in other
records, but nesting them is per- fectly legal and
a reasonable thing to do on occasion.
Controlling Field Offsets Within a Record
By default, whenever you create a record, most
assemblers automatically assign the offset zero
to the first field of that record. This
corresponds to records in a high level language
and is the intu- itive default condition. In some
instances, however, you may want to assign a
different starting offset to the first field of
the record. The HLA assembler provides a
mechanism that lets you set the starting offset
of the first field in the record.
The syntax to set the first offset is
name:
record := startingOffset;
<< Record Field Declarations >>
endrecord;
Using the syntax above, the first field will have
the starting off- set specified by the
startingOffset int32 constant expression. Since
this is an int32 value, the starting offset value
can be positive, zero, or negative.
One circumstance where this feature is invaluable
is when you have a record whose base address is
actually somewhere within the data structure.
The classic example is an HLA string. An HLA
string uses a record declaration similar to the
following:
record
MaxStrLen: dword;
length: dword;
charData: char[xxxx];
endrecord;
However, HLA string pointers do not contain the
address of the MaxStrLen field; they point at
the charData field. The str.strRec record type
found in the HLA Standard Library Strings module
uses a record declaration similar to the
following:
type
strRec:
record := -8;
MaxStrLen: dword;
length: dword;
charData: char;
endrecord;
The starting offset for the MaxStrLen field is -8.
Therefore, the offset for the length field is -4
(four bytes later) and the offset for the
charData field is zero. Therefore, if EBX points
at some string data, then "(type str.strRec
[ebx]).length" is equivalent to "[ebx-4]" since
the length field has an offset of -4.
Aligning Fields Within a Record
To achieve maximum performance in your programs,
or to ensure that your records properly map to
records or structures in some high level
language, you will often need to be able to
control the alignment of fields within a record.
For example, you might want to ensure that a
dword field's offset is an even multiple of four.
You use the ALIGN directive in a record
declaration to do this. The following example
shows how to align some fields on important
boundaries:
type
PaddedRecord:
record
c: char;
align(4);
d: dword;
b: boolean;
align(2);
w: word;
endrecord;
Whenever HLA encounters the ALIGN directive within
a record declaration, it automatically adjusts
the following field's off- set so that it is an
even multiple of the value the ALIGN directive
specifies. It accomplishes this by increasing the
offset of that field, if necessary. In the
example above, the fields would have the fol-
lowing offsets: c:0, d:4, b:8, w:10.
If you want to ensure that the record's size is a
multiple of some value, then simply stick an ALIGN
directive as the last item in the record
declaration. HLA will emit an appropriate number
of bytes of padding at the end of the record to
fill it in to the appropriate size. The
following example demonstrates how to ensure that
the record's size is a multiple of four bytes:
type
PaddedRec:
record
<< some field declarations >>
align(4);
endrecord;
Be aware of the fact that the ALIGN directive in a
RECORD only aligns fields in memory if the record
object itself is aligned on an appropriate
boundary. Therefore, you must ensure appropriate
alignment of any record variable whose fields
you're assuming are aligned.
If you want to ensure that all fields are
appropriately aligned on some boundary within a
record, but you don't want to have to man- ually
insert ALIGN directives throughout the record, HLA
provides a second alignment option to solve your
problem. Consider the fol- lowing syntax:
type
alignedRecord3 :
record[4]
<< Set of fields >>
endrecord;
The "[4]" immediately following the RECORD
reserved word tells HLA to start all fields in
the record at offsets that are multiples of four,
regardless of the object's size (and the size of
the objects preceeding the field). HLA allows any
integer expression that pro- duces a value in the
range 1..4096 inside these parenthesis. If you
specify the value one (which is the default), then
all fields are packed (aligned on a byte
boundary). For values greater than one, HLA will
align each field of the record on the specified
boundary. For arrays, HLA will align the field
on a boundary that is a multiple of the array
element's size. The maximum boundary HLA will
round any field to is a multiple of 4096 bytes.
Note that if you set the record alignment using
this syntactical form, any ALIGN directive you
supply in the record may not pro- duce the desired
results. When HLA sees an ALIGN directive in a
record that is using field alignment, HLA will
first align the current offset to the value
specified by ALIGN and then align the next
field's offset to the global record align value.
Nested record declarations may specify a different
alignment value than the enclosing record, e.g.,
type
alignedRecord4 : record[4]
a:byte;
b:byte;
c:record[8]
d:byte;
e:byte;
endrecord;
f:byte;
g:byte;
endrecord;
In this example, HLA aligns fields a, b, f, and g
on dword bound- aries, it aligns d and e (within
c) on eight-byte boundaries. Note that the
alignment of the fields in the nested record is
true only within that nested record. That is, if
c turns out to be aligned on some boundary other
than an eight-byte boundary, then d and e will
not actually be on eight-byte boundaries; they
will, however be on eight-byte boundaries
relative to the start of c.
In addition to letting you specify a fixed
alignment value, HLA also lets you specify a
minimum and maximum alignment value for a record.
The syntax for this is the following:
type
recordname : record[maximum : minimum]
<< fields >>
endrecord;
Whenever you specify a maximum and minimum value
as above, HLA will align all fields on a boundary
that is at least the minimum alignment value.
However, if the object's size is greater than the
minimum value but less than or equal to the
maximum value, then HLA will align that
particular field on a boundary that is a multiple
of the object's size. If the object's size is
greater than the maximum size, then HLA will align
the object on a boundary that is a multiple of
the maximum size. As an example, consider the
fol- lowing record:
type
r: record[ 4:1 ];
a:byte; // offset 0
b:word; // offset 2
c:byte; // offset 4
d:dword[2]; // offset 8
e:byte; // offset 16
f:byte; // offset 17
g:qword; // offset 20
endrecord;
Note that HLA aligns g on a dword boundary (not
qword, which would be offset 24) since the
maximum alignment size is four. Note that since
the minimum size is one, HLA allows the f field to
be aligned on an odd boundary (since it's a
byte).
If an array, record, or union field appears within
a record, then HLA uses the size of an array
element or the largest field of the record or
union to determine the alignment size. That is,
HLA will align the field without the outermost
record on a boundary that is compatible with the
size of the largest element of the nested array,
union, or record.
HLA sophisticated record alignment facilities let
you specify record field alignments that match
that used by most major high level language
compilers. This lets you easily access data types
used in those HLLs without resorting to inserting
lots of ALIGN directives inside the record.
Using Records/Structures in an Assembly
Language Program
In the "good old days" assembly language
programmers typi- cally ignored records. Records
and structures were treated as unwanted
stepchildren from high-level languages, that
weren't nec- essary in "real" assembly language
programs. Manually counting offsets and
hand-coding literal constant offsets from a base
address was the way "real" programmers wrote code
in early PC applica- tions. Unfortunately for
those "real programmers", the advent of
sophisticated operating systems like Windows and
Linux put an end to that nonsense. Today, it is
very difficult to avoid using records in modern
applications because too many API functions
require their use. If you look at typical Windows
and Linux include files for C or assembly
language, you'll find hundreds of different
structure dec- larations, many of which have
dozens of different members. Attempting to keep
track of all the field offsets in all of these
struc- tures is out of the question. Worse,
between various releases of an operating system
(e.g., Linux), some structures have been known to
change, thus exacerbating the problem. Today, it's
unreasonable to expect an assembly language
programmer to manually track such offsets - most
programmers have the reasonable expectation that
the assembler will provide this facility for
them.
Implementing Structures in an Assembler
Unfortunately, properly implementing structures in
an assem- bler takes considerable effort. A large
number of the "hobby" (i.e., non-commercial)
assemblers were not designed from the start to
support sophisticated features such as
records/structures. The sym- bol table management
routines in most assemblers use a "flat" lay- out,
with all of the symbols appearing at the same
level in the symbol table database. To properly
support structures or records, you need a
hierarchical structure in your symbol table
database. The bad news is that it's quite
difficult to retrofit a hierarchical structure
over the top of a flat database (i.e., the symbol
"hobby assembler" symbol table). Therefore,
unless the assembler was originally designed to
handle structures properly, the result is usu-
ally a major hacked-up kludge.
Four assemblers I'm aware of, MASM, TASM, OPTASM,
and HLA, handle structures well. Most other
assemblers are still trying to simulate
structures using a flat symbol table database,
with vary- ing results.
Probably the first attempt people make at records,
when their assembler doesn't support them
properly, is to create a list of con- stant
symbols that specify the offsets into the record.
Returning to our first example (in HLA):
type
student:
record
Name: string;
Major: int16;
SSN: char[12];
Midterm1: int16;
Midterm2: int16;
Final: int16;
Homework: int16;
Projects: int16;
endrecord;
One attempt might be the following:
const
Name := 0;
Major := 4;
SSN := 6;
Midterm1 := 18;
Midterm2 := 20;
Final := 22;
Homework := 24;
Projects := 26;
size_student := 28;
With such a set of declarations, you could reserve
space for a student "record" by reserving
"size_student" bytes of storage (which almost all
assemblers handle okay) and then you can access
fields of the record by adding the constant offset
to your base address, e.g.,
static
John : byte[ size_student ];
.
.
.
mov( John[Midterm1], ax );
There are several problems with this approach.
First of all, the field names are global and must
be globally unique. That is, you cannot have two
record types that have the same fieldname (as is
possible with the assembler supports true
records). The second problem, which is
fundamentally more problematic, is the fact that
you can attach these constant offsets to any
object, not just a "stu- dent record" type object.
For example, suppose "ClassAverage" is an array
of words, there is nothing stopping you from
writing the following when using constant equate
values to simulate record off- sets:
mov( ClassAverage[ Midterm1 ], ax );
Finally, and probably the most damning criticism
of this approach, is that it is very difficult to
maintain code that accesses structures in this
manner. Inserting fields into the middle of a
record, changing data types, and coming up with
globally unique names can create all sorts of
problems. Many high-level language programmers
who've tried to learn assembly language have given
up after discovering that they had to maintain
records in this fashion in an assembly language
program (too bad they didn't start off with a
reasonable assembler that properly supports
structures).
Manually maintaining all the constant offsets is a
maintenance nightmare. So somewhere along the
way, some assembly language programmers figured
out that they could write macros to handle the
declaration of constant offsets for them. For
example, here's how you could do this in an HLA
program:
program t;
#macro struct( _structName_, _dcls_[] ):
_dcl_, _id_, _type_, _colon_, _offset_;
?_offset_ := 0;
?_dcl_:string;
#for( _dcl_ in _dcls_ )
?_colon_ := @index( _dcl_ , 0, ":" );
#if( _colon_ = -1 )
#error
(
"Expected <id>:<type> in struct "
"definition, encountered: ",
_dcl_
)
#else
?_id_ := @substr( _dcl_, 0, _colon_ );
?_type_ :=
@substr
(
_dcl_,
@length( _dcl_ ) - _colon_
);
?@text( _id_ ) := _offset_;
?_offset_ :=
_offset_ + @size( @text( _type_ ));
#endif;
#endfor
?_structName_:text :=
"byte[" + @string( _offset_ ) + "]";
#endmacro
struct( threeItems, i:byte, j:word, k:dword )
static
aStruct: threeItems;
begin t;
mov( (type byte aStruct[i]), al );
mov( (type word aStruct[j]), ax );
mov( (type dword aStruct[k]), eax );
end t;
The "struct" macro expects a set of valid HLA
variable declara- tions supplied as macro
arguments. It generates a set of constants using
the supplied variable names whose offsets are
adjusted according to the size of the objects
previously appearing in the list. In this
example, HLA creates the following equates:
i = 0
j = 1
k = 3
This declaration also creates a "data type" named
"threeItems" which is equivalent to "byte[7]"
(since there are seven bytes in this record) that
you may use to create variables of type
"threeItems", as is done in this example.
Creating structures with macros solves one of the
three major problems: it makes it easier to
maintain the constant equates list, as you do not
have to manually adjust all the constants when
inserting and removing fields in a record. This
does not, however, solve the other problems
(particularly, the global identifier problem).
While fancier macros could be written, macros that
generate identifiers like "objectname_fieldName"
that help solve the globally unique problem, the
bottom line is that these hacks begin to fail
when you attempt to declare nested records, arrays
within records, and arrays of records (possibly
containing nested records and arrays of records).
The bottom line is this: assemblers that don't
properly support structures are going to have
problems when you've got to work with data
structures from high-level languages (e.g., OS API
calls, where the OS is written in C, such as
Windows and Linux). You're much better off using
an assembler that fully supports struc- tures
(and other advanced data types) if you need to
use structures in your programs.
Betov
@newsread2.news.pas.earthlink.net:
> Hi All,
>
> [... Tons of insane bullshits, as usual...]
To beginners:
* Take care of such Posts: They are not at all designed
to help you in any manner, at understanding anything
about Assembly. Their only purpose is to misslead you,
and to sell you a pure horror, called HLA.
* There is no concept similar to C-Like Structures in
Assembler and there will never be any, for the very simple
reason, that, an Assembler offering C-Like Structures is
no longuer an Assembler, but, an Assembly Compiler.
* The implementation of C-like Structures in an Assembly
Compiler have only inconvenients and no advantage.
- What is a C-Like Structure:
A C-Like Structure is the Abstration of a Data Chunk, that
is nothing but a group of hidden Equates. The reason why
you cannot have hidden Equates, with an Assembler, is that
an Assembler is not a Tool that _hides_ anything, but a Tool
that _shows_ everything possible to show.
- How to implement Structures in an "Asm Compatible" way:
Though C-Like Structures are nothing but hidden Equates,
and though you can perfectely, of course, declare these
Equates, the Assembly Structures may come under 3 forms:
* Equates set (universal usage)
* Stack Displacements (For Structures on the Stack)
* Simple Data Sets.
Here is one example of the inaccurate things the wrong
choice of C-Like Structures would push you to do. This
one comes from a MASM32 Demo, called "RichEdit":
____________________________________________________
WinMain proc hInst :DWORD,
hPrevInst :DWORD,
CmdLine :DWORD,
CmdShow :DWORD
;====================
; Put LOCALs on stack
;====================
LOCAL Wwd :DWORD
LOCAL Wht :DWORD
LOCAL Wtx :DWORD
LOCAL Wty :DWORD
LOCAL lpArg:DWORD
LOCAL sWid :DWORD
LOCAL sHgt :DWORD
LOCAL wc :WNDCLASSEX
LOCAL msg :MSG
; --------------------------------------------------
; Fill WNDCLASSEX structure with required variables
; --------------------------------------------------
invoke LoadIcon,hInst,500 ; icon ID
mov hIcon, eax
szText szClassName,"Rich_Edit_Class"
mov wc.cbSize, sizeof WNDCLASSEX
mov wc.style, CS_BYTEALIGNWINDOW
mov wc.lpfnWndProc, offset WndProc
mov wc.cbClsExtra, NULL
mov wc.cbWndExtra, NULL
m2m wc.hInstance, hInst
mov wc.hbrBackground, NULL
m2m wc.lpszMenuName, NULL
mov wc.lpszClassName, offset szClassName
m2m wc.hIcon, hIcon
invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor, eax
m2m wc.hIconSm, hIcon
invoke RegisterClassEx, ADDR wc
________________________________________________________
Notice that all of the Initializations of the Structure
are done, on the Stack, AT RUN-TIME. Such Methods, and,
most of all, their _generalizations_ (in some cases, this
is accurate to do something similar to this...), would
completely defeate any reason for programming Assembly:
Such a Structure should, evidently, be declared in Data,
as simple Data, and it should be initialized, for all the
known Members, AT WRITE-TIME.
The fact that the "Assemblers" (...) pushed by Master Pdf
do not have any integrated feature to support the various
way of doing Structures the proper way, in Assembly, is
one another story.
Betov.
Randall Hyde
"Betov" <be...@free.fr> wrote in message
news:XnF9549B874CF...@212.27.42.67...
> "Randall Hyde" <rand...@earthlink.net> écrivait news:RwKUc.6023$3O3.5451
> @newsread2.news.pas.earthlink.net:
>
> > Hi All,
> >
> > [... Tons of insane bullshits, as usual...]
>
>
> To beginners:
>
> * Take care of such Posts: They are not at all designed
> to help you in any manner, at understanding anything
> about Assembly. Their only purpose is to misslead you,
> and to sell you a pure horror, called HLA.
To beginners:
You might want to read some of Rene's (Betov's) other
posts and come to your own conclusions whether you
want to trust a single word he says on such matters.
Cheers,
Randy Hyde
Percival
Wonders what Betov will say about Fasm's "virtual" feature, in which
it's main purpose is to be able to treat runtime registers and other
stuff as structures.
For example:
virtual at ebx
abc_blah dw ?
abc_blah2 dw ?
end virtual
And then
mov eax, [abc_blah]
will be translated into
mov eax, [ebx]
Similarly, we can use virtual with esp and pretend that certain
variables that, in actuallity are on the stack, is data.
virtual at esp
return_addr dd ?
i dd ?
x dd ?
end virtual
mov eax, [i] ; same as mov eax, [esp+4]
Percival
arargh4...@now.at.arargh.com
<rand...@earthlink.net> wrote:
>Hi All,
>
>I've read several posts concerning structures and their
>implementation in assembly language. Given some
>misconceptions about structures in assembly language,
>I pieced together the following article about structures
>in assembly.
IBM 1401 autocoder (a macro assembler) from the 60's had record
definition abilities.
IBM 360 assembler had records, in a manner of speaking. (60 & 70's)
I have a copy of MASM ver 2.04 from 1982. It has records.
Not a new concept.
<snip>
--
Arargh407 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Randall Hyde
<arargh4...@NOW.AT.arargh.com> wrote in message
news:4gl7i0d26b8lq5vka...@4ax.com...
> On Wed, 18 Aug 2004 15:24:33 GMT, "Randall Hyde"
> <rand...@earthlink.net> wrote:
>
> >Hi All,
> >
> >I've read several posts concerning structures and their
> >implementation in assembly language. Given some
> >misconceptions about structures in assembly language,
> >I pieced together the following article about structures
> >in assembly.
>
> IBM 1401 autocoder (a macro assembler) from the 60's had record
> definition abilities.
>
> IBM 360 assembler had records, in a manner of speaking. (60 & 70's)
>
> I have a copy of MASM ver 2.04 from 1982. It has records.
>
> Not a new concept.
Precisely. That's why it's somewhat amazing that people are arguing
today that "structures don't belong in assembly language."
That attitude is completely absurd, particularly given the fact that
interfaces to OS API's (like Windows and Linux) pretty much require
the things.
As for the general assembly crowd, you would be amazed how many
people don't understand what structures are all about. Lots of people
learning assembly after knowing only BASIC, I suppose.
Cheers,
Randy Hyde
hutch--
This is claptrap, assemblers have had the capacity to write and
manipulate structures since before 1990 and structures (C), UDTs
(basic), records (pascal) are a normal part of programming. The
difference is some assembler CAN handle structures and some CANNOT.
When you have to write code for an operating system that commonly uses
structures, you either use an assembler powerful enough to do it
easily or get stuck with some dirty fudge to try and emulate something
that is very simple.
It may suit peddlers or toys that are not powerful enough to write
Windows code properly to boast of what their toys cannot do but if you
need to write successful Windows code, you will do it with an
assembler that is powerful enough to handle the layout of the
operating system API functions as native assembler code.
A structure is in fact an ARRAY but with the difference that all
members do not have to be the same size. The great advantage of using
structures is that you can address each member by name and you ALWAYS
get the correct address by doing so. There is nothing clever about
manually coding array offsets through multiple levels of indirection,
just highly unreliable code that is nearly impossible to debug and
fix.
When Betov quotes a piece of the example code from MASM32, he fails to
address WHY a CreateWindowEx() API uses a WNDCLASSEX structure.
Windows code can be complicated if you do it wrong and to create a
Window, you first must register a class for the Window. You use the
WNDCLASSEX structure like a parameter list to set up the Window class
and then you create the Window using the CreateWindowEx().
Its one of th worst kept secrets that Microsoft had technical problems
with the design of early 32 bit Windows so they hired a pile of VAX
mainframe programmers to design the PE file format used in 32 bit
Windows. This is where the nested structures came from and without
that capacity, coding Windows assembler is an unreliable unfixable pig
that does not work properly.
This much I will say to programmers who are learning both Windows and
assembler coding, don't be mislead by bullsh*t coming out of Betov
when he does not have the experience coding Windows software. Without
normal capacity like structures, you are left with simplistic capacity
that cannot do the complicated stuff that Windows is made with.
Regards,
hutch at movsd dot com
f0dder
*snip*
>
> Notice that all of the Initializations of the Structure
> are done, on the Stack, AT RUN-TIME. Such Methods, and,
> most of all, their _generalizations_ (in some cases, this
> is accurate to do something similar to this...), would
> completely defeate any reason for programming Assembly:
> Such a Structure should, evidently, be declared in Data,
> as simple Data, and it should be initialized, for all the
> known Members, AT WRITE-TIME.
>
Nothing stops you from using a pre-initalized structure in
masm, whether in data, code, const or elsewhere. The runtime-
filling is just an example of typical bad code... don't judge
a tool by the people that (mis)use it :). The annoying thing,
though, is that you need the line-continuation character ('\'),
otherwise masm will bitch.
wcMain WNDCLASSEX < \
sizeof WNDCLASSEX, \ ; cbSize
0, \ ; style
ofs wndProc, \ ; lpfnWndProc
0, \ ; cbClsExtra
0, \ ; cbWndExtra
0, \ ; hInstance - fixed up later
NULL, \ ; hIcon
NULL, \ ; hCursor
NULL, \ ; hbrBackground - not needed
NULL, \ ; lpszMenuName
ofs szClassName,\ ; lpszClassName
NULL \ ; hIconSm
>
NoDot
>> [snip Betov's blah]
>> Jerk.
>> < http://jerk.forced-to-be-free.fr/JunkAsm.html >
I can agree with Betov on the fact that structure support like HLA or
MASM's makes to a high level assembler, but high level assemblers are
not that bad.
> Wonders what Betov will say about Fasm's "virtual" feature, in which it's main
> purpose is to be able to treat runtime registers and otherstuff as structures.
I can agree with you there.
> For example:
> virtual at ebx
> abc_blah dw ?
> abc_blah2 dw ?
> end virtual
>
> And then
> mov eax, [abc_blah]
>
> will be translated into
> mov eax, [ebx]
Interesting...
> Similarly, we can use virtual with esp and pretend that certain
> variables that, in actuallity are on the stack, is data.
>
> virtual at esp
> return_addr dd ?
> i dd ?
> x dd ?
> end virtual
>
> mov eax, [i] ; same as mov eax, [esp+4]
THAT, I find cool. I didn't know you could do that.
> Percival
NoDot
<www.not-in-existance.com>
Randall Hyde
"NoDot" <no_...@msn.com> wrote in message
news:dfed44a6.04081...@posting.google.com...
> Percival <dragont...@yahoo.com> wrote
> >> [snip Betov's blah]
> >> Jerk.
> >> < http://jerk.forced-to-be-free.fr/JunkAsm.html >
>
> I can agree with Betov on the fact that structure support like HLA or
> MASM's makes to a high level assembler, but high level assemblers are
> not that bad.
Quote from a later post in this thread:
>>>>>>arargh4...@NOW.AT.arargh.com>>>>>
IBM 1401 autocoder (a macro assembler) from the 60's had record
definition abilities.
IBM 360 assembler had records, in a manner of speaking. (60 & 70's)
I have a copy of MASM ver 2.04 from 1982. It has records.
Not a new concept.
<snip>
>>>>>>>>>>>>>>>>>>>>>
Structures have been around since the days *macros* were first introduced.
Few people would consider the IBM 1401 autocoder system a
"high-level assembler" :-)
Rene is just making noise because his assembler doesn't support
structures like most normal assemblers. Saying that structures don't
belong in an assembly language is simply saying that we should return
to the say coding was done in the 1950's. While I cannot imagine
a high-level assembler *not* supporting structures, the inclusion of
structures alone hardly makes an assembler a high-level assembler
or a "compiler" (as in, "not an assembler"). Anyone who claims
that an assembler is a "compiler" (and "not an assembler") because
it supports structures is simply making lame excuses for their own
product :-)
Cheers,
Randy Hyde
Betov
$edfa...@dtext01.news.tele.dk:
> Nothing stops you from using a pre-initalized structure in
> masm, whether in data, code, const or elsewhere. The runtime-
> filling is just an example of typical bad code... don't judge
> a tool by the people that (mis)use it :).
The problem, with wrong features, in wrong Tools, is
not to know wether or not you can or not make use of
the wrong features.
The fact _is_ that they _all_ do it. By the way, one
of the 3 main Authors of the Assembly, Rebirth, Iczelion,
_always_ does it.
The problem is that, when using wrong Tools, the programmers
are pushed to make use of the wrong features. You will notice
that the "Wrong Tools Defenders" will never admitt that this
is bad programming practice.
Writting like this, in Assembly, produces the same results
as a typical C writting. Way better: Let's all use C and
forget all of Asm. :))
Betov.
The Wannabee
<rand...@earthlink.net>:
>
> <arargh4...@NOW.AT.arargh.com> wrote in message
> news:4gl7i0d26b8lq5vka...@4ax.com...
>> On Wed, 18 Aug 2004 15:24:33 GMT, "Randall Hyde"
>> <rand...@earthlink.net> wrote:
>>
>> >Hi All,
>> >
>> >I've read several posts concerning structures and their
>> >implementation in assembly language. Given some
>> >misconceptions about structures in assembly language,
>> >I pieced together the following article about structures
>> >in assembly.
>>
>> IBM 1401 autocoder (a macro assembler) from the 60's had record
>> definition abilities.
>>
>> IBM 360 assembler had records, in a manner of speaking. (60 & 70's)
>>
>> I have a copy of MASM ver 2.04 from 1982. It has records.
>>
>> Not a new concept.
>
> Precisely. That's why it's somewhat amazing that people are arguing
> today that "structures don't belong in assembly language."
Structures, as a functionality is unavoidable. The only diffrence between
you structures and mine, is that mine are very much easier to understand,
easier to use, and give me more control.
You misunderstand "structure" to mean _a_ implementation. Structure is a
_method_ There are several ways to implement structures. You point about
resusing the member names is debatable. The inconvinience of writing
(RosAsm):
[Student.Major 0
Student.SSN 2
Student.Midterm1 18
Student.Midterm2 20
Student.Final 22
Student.Homework 24
Student.Projects 26
_______________________
SizeOF_Student 28]
and then
[John: B$ 0 #SizeOf_Student]
mov eax D$John + Student.Major
is not that killing.
To have an array :
[StudentList : B$ 0 (#SizeOf_Student*4)]
To have a "two dimentional array" (another confusion of Randy)
[StudentList2D : B$ + (#SizeOf_Student*4*3)]
[StudentList3D : B$ + (#SizeOf_Student*4*3*5)]
This code performs the equvivalent that your record does. Alignment, if
needed I can do manually easy, and to insert a structure, is also quite
easy to do manually. Also, this way reveals everything, and is much easier
to write, in most cases. And there is no naming conflicts. And its very
easy to maintain. Stuctures also rarly need to be maintained. So its in
any case just very simple to do so.
Most of you points in the previous article can be expained, easier. There
is absolutely no way that HLA is an assembler, you said so 3 times in the
article, rephrasing and old joke. Nomatter who many times you say it, its
still lies. HLA is a text converter. And record, the way you present them
are HLL. Because they hide the true nature of structures to the eyes of
the programmer.
The only thing your stuctures perform is to make programming more
complicated.
> That attitude is completely absurd, particularly given the fact that
> interfaces to OS API's (like Windows and Linux) pretty much require
> the things.
No this is wrong. The OS requires a FORMATED data chunck. Thats all. It
does not require _Stuctures_ in the strict way you mean. However, all
programs must use some kind of stucture. You have just misunderstood what
a stucture is. Your claim it can speed up code, is TOTALLY wrong. A
structure fails the definition you give. The structure of data do not
exists, only the data do exist. A structure is a method of organiazing
that data, call it writing conventions, and they are available since ages
inside a hex editor.
> As for the general assembly crowd, you would be amazed how many
> people don't understand what structures are all about. Lots of people
> learning assembly after knowing only BASIC, I suppose.
YOU do not understand what a structure is. Its a set of rules how to
access data. You have confused your own method of doing this with the
nature of stucture. This is wrong. The above written code handles
structure as well, only in a manner more true to the nature of asm.
I write my OOP structures using offsets as well. In this case I use the
offset to help when developing the code, to offset structure "members"
automatically :
[TSkinButton.OnExecute SizeOf_TSkinSection
TSkinButton.OnPostExecute TSkinButton.OnExecute
+ SizeOf_Pointer
_____________________________________________________________________________
SizeOf_TSkinButton TSkinButton.OnPostExecute
+ SizeOf_Pointer]
The first member is an offset, and is auto offset to the size of the
ancestor size.
Then the second member is auto offset to the previous member + the size of
the previous member.
and the calculation of the size of the new structure becomes the offset of
the second member + the size of the seconf member. Just as readble and
clear as HLL, and just as easy to maintain.
But anyway, in most cases I use the offset directly. They are much clearer
when you need to know the true offsets. Anyway, the offset also reveal the
sizes of members. Just right click on SizeOf_Pointer in RosAsm to see that
it is equated to SizeOf_DWord, and that is declared right above it, to be
4.
Any structure you can write in HLA, I can write in less time, and much
more clear in RosAsm.
> Cheers,
> Randy Hyde
--
RosAsm now auto assembles on ReactOS.
http://www.reactos.com/
What is RosAsm ?
http://betov.free.fr/RosAsm.html
"HLA.EXE is not an assembler. Indeed, it's not even a compiler,
pre-processor (or "preparser", whatever that is), though it
*might* qualify as [a] 'text converter.'"
- Randy Hyde, author of 'HLA,'
in ALT.LANG.ASM newsgroup
August 11, 2004
The Wannabee
>> To beginners:
>
> This is claptrap, assemblers have had the capacity to write and
> manipulate structures since before 1990 and structures (C), UDTs
> (basic), records (pascal) are a normal part of programming. The
> difference is some assembler CAN handle structures and some CANNOT.
Completly wrong. All assembler can handle structures. You confuse what
structures are.
> When you have to write code for an operating system that commonly uses
> structures, you either use an assembler powerful enough to do it
> easily or get stuck with some dirty fudge to try and emulate something
> that is very simple.
RosAsm is times more powerful than you will ever understand then.
> A structure is in fact an ARRAY but with the difference that all
> members do not have to be the same size.
Correct.
> The great advantage of using
> structures is that you can address each member by name and you ALWAYS
> get the correct address by doing so.
LOL . Theres no advantage of using structures. ALL programm must use
stuctures. Its unavoidable. But you and Randy doesnt understand the nature
of structure, so you mis out on what they really are. They are nothing but
writing conventions, rules of how to interpret (FORMAT) a chunck of data.
> There is nothing clever about
> manually coding array offsets through multiple levels of indirection,
> just highly unreliable code that is nearly impossible to debug and
> fix.
Wrong. There are nothing clever about it thats true, but that they lead to
unreliable code, is untrue. Only writing unreliable leads to that.
> Its one of th worst kept secrets that Microsoft had technical problems
> with the design of early 32 bit Windows so they hired a pile of VAX
> mainframe programmers to design the PE file format used in 32 bit
> Windows. This is where the nested structures came from and without
> that capacity, coding Windows assembler is an unreliable unfixable pig
> that does not work properly.
Utterly wrong. Windows expects data, give it the correct data, using any
method of structure, and it will be fully possible to use it. And WAY
easier without the silly Record keyword that randy uses. And also using
RosAsm methods, much easier to learn.
> This much I will say to programmers who are learning both Windows and
> assembler coding, don't be mislead by bullsh*t coming out of Betov
> when he does not have the experience coding Windows software.
This is so funny. Betov understand way more then you do. When it comes to
the nature of stuctures, even _I_ understand more than you do.
> Without
> normal capacity like structures, you are left with simplistic capacity
> that cannot do the complicated stuff that Windows is made with.
LOL LOL LOL. Let me hear your powerscream !! :-))) You mistake structure
to mean an implementation, just like Randy. Programming without some kind
of structure is impossible.
>
> Regards,
>
> hutch at movsd dot com
--
Percival
> På 18 Aug 2004 18:07:58 -0700, skrev hutch-- <hu...@movsd.com>:
>
>>> To beginners:
>>
>>
>> This is claptrap, assemblers have had the capacity to write and
>> manipulate structures since before 1990 and structures (C), UDTs
>> (basic), records (pascal) are a normal part of programming. The
>> difference is some assembler CAN handle structures and some CANNOT.
>
>
> Completly wrong. All assembler can handle structures. You confuse what
> structures are.
You are confusing structures vs records i think. Thats how i see it.
Records are basically defines, structures actually support a full
structure, abstracting away from defines. Weather or not its a good
thing, thats sorta the point, to abstract away from seeing ebx+2 and
instead see something like mystruct.x
>> When you have to write code for an operating system that commonly uses
>> structures, you either use an assembler powerful enough to do it
>> easily or get stuck with some dirty fudge to try and emulate something
>> that is very simple.
>
>
> RosAsm is times more powerful than you will ever understand then.
Well, decimal points are "times" :)
J/k. Anyway, true structures with dot notation is something i personally
like. Id have to say RosAsm is different, but that doesn't necessarily
mean its more powerful.
>> The great advantage of using
>> structures is that you can address each member by name and you ALWAYS
>> get the correct address by doing so.
>
>
> LOL . Theres no advantage of using structures. ALL programm must use
> stuctures. Its unavoidable. But you and Randy doesnt understand the
> nature of structure, so you mis out on what they really are. They are
> nothing but writing conventions, rules of how to interpret (FORMAT) a
> chunck of data.
Please, where did they post something wrong in their post? It doesn't
seem to be wrong. And i think your statements are like a contradiction.
No advantage of using structures, all programs must use them?
>> There is nothing clever about
>> manually coding array offsets through multiple levels of indirection,
>> just highly unreliable code that is nearly impossible to debug and
>> fix.
>
>
> Wrong. There are nothing clever about it thats true, but that they lead
> to unreliable code, is untrue. Only writing unreliable leads to that.
Preventing someone from writting unreliably helps a bit too.
>> Its one of th worst kept secrets that Microsoft had technical problems
>> with the design of early 32 bit Windows so they hired a pile of VAX
>> mainframe programmers to design the PE file format used in 32 bit
>> Windows. This is where the nested structures came from and without
>> that capacity, coding Windows assembler is an unreliable unfixable pig
>> that does not work properly.
>
>
> Utterly wrong. Windows expects data, give it the correct data, using any
> method of structure, and it will be fully possible to use it. And WAY
> easier without the silly Record keyword that randy uses. And also using
> RosAsm methods, much easier to learn.
I am utterly confused of what this has anything to do with the subject.
>> This much I will say to programmers who are learning both Windows and
>> assembler coding, don't be mislead by bullsh*t coming out of Betov
>> when he does not have the experience coding Windows software.
>
>
> This is so funny. Betov understand way more then you do. When it comes
> to the nature of stuctures, even _I_ understand more than you do.
Can't argue here. I don't know how much you know, or how much hutch
knows. But it seems as if you both believe that you all have a good
understanding of it.
Percival
Alex McDonald
> "f0dder" <f0dder_s...@flork.dk> écrivait news:4123feb8$0$177
> $edfa...@dtext01.news.tele.dk:
>
> > Nothing stops you from using a pre-initalized structure in
> > masm, whether in data, code, const or elsewhere. The runtime-
> > filling is just an example of typical bad code... don't judge
> > a tool by the people that (mis)use it :).
>
>
> The problem, with wrong features, in wrong Tools, is
> not to know wether or not you can or not make use of
> the wrong features.
>
> The fact _is_ that they _all_ do it. By the way, one
> of the 3 main Authors of the Assembly, Rebirth, Iczelion,
> _always_ does it.
Which doesn't make it "a good thing". For instance, one of the 3 main
authors of Assembly Rebirth has written an assembler that uses a provably
imperfect "perfect hash" for managing the symbol table; that's definitely
not the way to do it.
>
> The problem is that, when using wrong Tools, the programmers
> are pushed to make use of the wrong features. You will notice
> that the "Wrong Tools Defenders" will never admitt that this
> is bad programming practice.
You're windbagging. It's good programming practice. Building structures at
run-time costs execution time and code space every time it's run; a good
tool lets you do this kind of stuff at assembly time, once, with no run-time
overheads. You don't do it for classical character strings; why insist that
it's a "good thing" to do it differently for what are just strings of bytes?
--
Regards
Alex McDonald
f0dder
> "f0dder" <f0dder_s...@flork.dk> écrivait news:4123feb8$0$177
> The fact _is_ that they _all_ do it. By the way, one
> of the 3 main Authors of the Assembly, Rebirth, Iczelion,
> _always_ does it.
>
I think iczelion did it because he wanted easy-to-understand
code - or possibly because some of the stuff was directly
translated from C code. I think you will agree that if the
WNDCLASSEX definition was rewritten as
wcMain WNDCLASSEX <sizeof WNDCLASSEX, 0, ofs wndProc, 0, 0,
0, NULL, NULL, NULL, NULL, ofs szClassName, NULL>
it would be somewhat harder to read :)
> The problem is that, when using wrong Tools, the programmers
> are pushed to make use of the wrong features. You will notice
> that the "Wrong Tools Defenders" will never admitt that this
> is bad programming practice.
>
Yup
> Writting like this, in Assembly, produces the same results
> as a typical C writting. Way better: Let's all use C and
> forget all of Asm. :))
>
Sad thing is that the "typical" way of writing full-asm apps
will often give worse results than chugging code through a C
compiler... I mean, many of the win32asm examples look like
they were translated line-by-line from C code - C compilers
generate "somewhat" more efficient code than that :-)
Nothing wrong with the style of assembly coding, if that's
what you like... but people doing that kind of assembly coding
and at the same time bashing HLLs... well, I roll my eyes.
Betov
news:cg2iuq$jmp$1...@sparta.btinternet.com:
> "Betov" <be...@free.fr> wrote in message
> news:XnF954A6A4205...@212.27.42.67...
>> "f0dder" <f0dder_s...@flork.dk> écrivait news:4123feb8$0$177
>> $edfa...@dtext01.news.tele.dk:
>>
>> [...]
>>
>> The problem, with wrong features, in wrong Tools, is
>> not to know wether or not you can or not make use of
>> the wrong features.
>>
>> The fact _is_ that they _all_ do it. By the way, one
>> of the 3 main Authors of the Assembly, Rebirth, Iczelion,
>> _always_ does it.
>
> Which doesn't make it "a good thing".
? I don't know at what point my "english" is readable or
not, but i think you should learn to read:
_____I am saying that this is a bad thing_____
> For instance, one of the 3 main
> authors of Assembly Rebirth has written an assembler that uses a
> provably imperfect "perfect hash" for managing the symbol table;
> that's definitely not the way to do it.
Talking of... _me_???!!!... Mind you, i am _NOT_ "one of
the 3 main authors of the Assembly Rebirth". These 3 are:
Iczelion, Test Departement and Ron Thomas.
Now, about "imperfect "perfect hash"", i will let you
propose any argument against mine, and eventually to
propose a better "hash" of yours... :)) :)) :))
>> The problem is that, when using wrong Tools, the programmers
>> are pushed to make use of the wrong features. You will notice
>> that the "Wrong Tools Defenders" will never admitt that this
>> is bad programming practice.
>
> You're windbagging.
Yes. I love doing this, for cases when guys like you
do not give me a breath.
> It's good programming practice.
As you seem to not understand a word at anything, i would
have a kind of question, saying... "What?" :)) :)) :))
> Building
> structures at run-time costs execution time and code space every time
> it's run;
This is exactly what i am saying.
> a good tool lets you do this kind of stuff at assembly time,
> once, with no run-time overheads.
This is exactly what i am saying.
> You don't do it for classical character strings;
???!!!... Do "What?" ???!!!...
> why insist that it's a "good thing" to do it
> differently for what are just strings of bytes?
???!!!... Do "What?" ???!!!... Are you drunk?...
If you are not drunk, you should stop smoking the
curtains, this is very bad for the breath.
Betov.
Alex McDonald
> "Alex McDonald" <alex...@btopenworld.com> écrivait
> news:cg2iuq$jmp$1...@sparta.btinternet.com:
>
> > "Betov" <be...@free.fr> wrote in message
> > news:XnF954A6A4205...@212.27.42.67...
> >> "f0dder" <f0dder_s...@flork.dk> écrivait news:4123feb8$0$177
> >> $edfa...@dtext01.news.tele.dk:
> >>
> >> [...]
> >>
> >> The problem, with wrong features, in wrong Tools, is
> >> not to know wether or not you can or not make use of
> >> the wrong features.
> >>
> >> The fact _is_ that they _all_ do it. By the way, one
> >> of the 3 main Authors of the Assembly, Rebirth, Iczelion,
> >> _always_ does it.
> >
> > Which doesn't make it "a good thing".
>
> ? I don't know at what point my "english" is readable or
> not, but i think you should learn to read:
>
> _____I am saying that this is a bad thing_____
My apologies; I got confused with the 3 nots in the one sentence.
===snipped
>
> ???!!!... Do "What?" ???!!!... Are you drunk?...
>
> If you are not drunk, you should stop smoking the
> curtains, this is very bad for the breath.
I prefer kippers.
--
Regards
Alex McDonald
Betov
$edfa...@dtext01.news.tele.dk:
>> Writting like this, in Assembly, produces the same results
>> as a typical C writting. Way better: Let's all use C and
>> forget all of Asm. :))
>>
> Sad thing is that the "typical" way of writing full-asm apps
> will often give worse results than chugging code through a C
> compiler... I mean, many of the win32asm examples look like
> they were translated line-by-line from C code - C compilers
> generate "somewhat" more efficient code than that :-)
Agrea, but for simple 'Demos", this is not that much
significative of what the advantages of Asm on C, are.
> Nothing wrong with the style of assembly coding, if that's
> what you like... but people doing that kind of assembly coding
> and at the same time bashing HLLs... well, I roll my eyes.
As i know your opinion about this, i am not sure if you
are, here, targetting Hutch--, --, --, or me. For the
accuracy of my own Programming Style, i have it easier
to show facts that to discuss in abstract terms:
For example, RosAsm is the fastest of the Actual Assembler,
the first, ever seen, PEs Disassembler-ReAssembler, and so
on. Plus, at a size point of view, RosAsm Assembler / IDE /
Debugger / Disassembler / Sources Editor / and so on, and
so on... is... 607 Ko, today - without the Sources inside,
of course -. Plus, to make it hang, you need a real great
expert in hanging, like Master Pdf, in his best performances
day. This seems to me to be a valid demonstration of a valid
Programming Style. :)
Betov.
luvr
> Here is one example of the inaccurate things the wrong
> choice of C-Like Structures would push you to do. This
> one comes from a MASM32 Demo, called "RichEdit":
> [...]
Well, you're right about one thing here: That demo is lousy code.
But I'm not too sure if it's any harder to write equally bad code in RosAsm.
--Luc.
Randall Hyde
"Percival" <dragont...@yahoo.com> wrote in message
news:2ojtdaF...@uni-berlin.de...
>
> You are confusing structures vs records i think. Thats how i see it.
> Records are basically defines, structures actually support a full
> structure, abstracting away from defines. Weather or not its a good
> thing, thats sorta the point, to abstract away from seeing ebx+2 and
> instead see something like mystruct.x
STRUCT is the "C" terminology.
RECORD is the "Pascal" terminology.
At least for the purposes of this discussion.
MASM actually *does* differentiate the two names,
records are "bit records" producing bit masks within a 32-bit bit string.
STRUCTs are the traditional records/structures.
In the context of this discussion, however, the terms "structure"
(as in C STRUCT or MASM STRUCT) and RECORD
(as in Pascal RECORD) are synonyms.
> >
> >
> > LOL . Theres no advantage of using structures.
Hmmm....
Wannabe is willing to say this after claiming to have
used Delphi for 10 years? Obviously he didn't learn
much during those 10 years. No doubt, after using
RosAsm for 10 years he still won't know very much
if history is any indication.
>> ALL programm must use
> > stuctures. Its unavoidable. But you and Randy doesnt understand the
> > nature of structure, so you mis out on what they really are. They are
> > nothing but writing conventions, rules of how to interpret (FORMAT) a
> > chunck of data.
>
> Please, where did they post something wrong in their post? It doesn't
> seem to be wrong. And i think your statements are like a contradiction.
> No advantage of using structures, all programs must use them?
Ignore Wannabe. He *never* has a clue what he's talking about.
> >
> > Wrong. There are nothing clever about it thats true, but that they lead
> > to unreliable code, is untrue. Only writing unreliable leads to that.
>
> Preventing someone from writting unreliably helps a bit too.
Anyone who claims to have used Delphi for 10 years would know
better. Of course, they would also have been using Delphi since it
was in beta before v1.0 :-) That claim is about as credible as
everything else he says, I guess.
> > Utterly wrong. Windows expects data, give it the correct data, using any
> > method of structure, and it will be fully possible to use it. And WAY
> > easier without the silly Record keyword that randy uses. And also using
> > RosAsm methods, much easier to learn.
>
> I am utterly confused of what this has anything to do with the subject.
He seems to be suggesting that it's better to place a bunch of adjacent
variables into memory rather than use structures to collect them together.
He obviously has no idea about program maintenance. But as an
admitted beginner (though a beginner who has been using Delphi for
10 years), he'll probably figure out the error of his ways after
another decade or so. Then again, maybe not.
> > This is so funny. Betov understand way more then you do. When it comes
> > to the nature of stuctures, even _I_ understand more than you do.
>
> Can't argue here. I don't know how much you know, or how much hutch
> knows. But it seems as if you both believe that you all have a good
> understanding of it.
I one time I would have guessed Rene's age to be about 18. He certainly
talks like an 18-year-old know-it-all. Wannabe talks the same way, though
I'd probably peg him at 19. Never can tell though. Some people never
grow up. (Was wannabe using Delphi at age 9?)
I wish I was Wannabe's age again. I remember the good old days when
I, too, knew everthing :-)
Cheers,
Randy Hyde
The Wannabee
<rand...@earthlink.net>:
> In the context of this discussion, however, the terms "structure"
> (as in C STRUCT or MASM STRUCT) and RECORD
> (as in Pascal RECORD) are synonyms.
Agree. For once.
>> > LOL . Theres no advantage of using structures.
>
> Hmmm....
> Wannabe is willing to say this after claiming to have
> used Delphi for 10 years? Obviously he didn't learn
> much during those 10 years. No doubt, after using
> RosAsm for 10 years he still won't know very much
> if history is any indication.
:-) Randy. Dont you know theres allways a method to the strange things I
say ? The reason that structures (in your narrow view/definition of them)
has no advantage on asm, is that asm support every single thing that HLL
supports. So then, wheres the advantage ? All programmers MUST use
structures of some kind, and thus all programming tools support them, and
asm support everything !
> Ignore Wannabe. He *never* has a clue what he's talking about.
Hehe. Poor Randy. Asm was too hard for him. Had to use C, and Bison,
Couldnt see that a byte is also a stucture, doesnt understand the topic of
stuctures. Doesnt see that stuctures are a common term that include
anything we use to structure our data. Thats why they are called
structures. Doesnt understand that RosAsm structures are easier to read,
write and learn, than HLAs Pascal like records. Poor man.
> Anyone who claims to have used Delphi for 10 years would know
> better. Of course, they would also have been using Delphi since it
> was in beta before v1.0 :-) That claim is about as credible as
> everything else he says, I guess.
???
That writing unreliable is the only reason a program becomes unreliable ?
Are you actually for REAL? Do you suggest that structures do anything in
your application, and not the programmer ? Like you said they speed up
programs ?
> He seems to be suggesting that it's better to place a bunch of adjacent
> variables into memory rather than use structures to collect them
> together.
What a FUD master !!! I have NEVER said that. You dont see it Randy....you
dont see that data is just a sequence of bytes :
[TAeroPlane.Destination.x sizeof_TComposite3DObject
TAeroPlane.Destination.y TAeroPlane.Destination.x + SizeOf_Double
TAeroPlane.Destination.z TAeroPlane.Destination.y + SizeOf_Double
TAeroPlane.Speed.x TAeroPlane.Destination.z + SizeOf_Double
TAeroPlane.Speed.y TAeroPlane.Speed.x + SizeOf_Double
TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
___________________________________________________________________________________
SizeOf_TAeroPlane TAeroPlane.Speed.z + SizeOf_Double ]
(Will be tabbed correctly in RosAsm, in 3 neat rows)
Array of 10 AeroPlanes :
[AeroPlanes : B$ 0 (#SizeOf_TAeroPlane*10)]
"Multidimentional" array : (remember that there are only one dimention to
data, anyway)
[AeroplaneSkvadron : B$ (#SizeOf_TAeroPlane*10*4)]
[AeroplaneArmada : B$ (#SizeOf_TAeroPlane*10*4*3)]
Dont you see that this will turn into the exact same thing (run time) as
(Delphi) :
Type
Float = Double;
T3DPoint = Record
x : float;
y : float;
z : float
end;
TAeroPlane = Object( TComposite3DObject )
private
fLocation : T3DPoint;
fSpeed : T3DPoint;
public
Property Location : T3DPoint read fLocation write fLocation;
Property Speed : T3DPoint read fSpeed write fSpeed
end;
var
Aeroplanes : Array [0..9] of TAeroPlane;
AeroPlaneSkvadron : array[0..9, 0..3] of TAeroPlane;
AeroPlaneArmada : array[0..9, 0..3, 0..2] of TAeroPlane;
Theese two RosAsm/Delphi declarations are, in terms of functionality, and
bytes image, IDENTICAL
(Actually, I am talking about the stucture bytes, not the OOP
implementation, those will differ, although _not_ in functionality)
hmm.. Lets see the HLA equivalent ?
> He obviously has no idea about program maintenance. But as an
> admitted beginner (though a beginner who has been using Delphi for
> 10 years), he'll probably figure out the error of his ways after
> another decade or so. Then again, maybe not.
LOLOLOLOLOLOLOLOLOLOLOL. I have 15-20 delphi apps, that all builds on the
same codebase. I can asure you, I know nothing about maintanance. :-)))
:-)))) :-))))
....for examle...
Today I found some bugs, crashstates in my RosAsm demo. Surpriced to see
it, since this code worked before, I loaded RosAsm and those demos, and
pressed run. RosAsm halted on the following
TMenuSectionManager.TabToParentMenu:
mov ecx D$edi + TSkinSection.Parent
call TSZApplication.IsParentAWindow D$edi + TSkinSection.Parent
if eax = &FALSE
mov eax D$ecx + TSkinPopupMenu.SpawnSection <*********** RosAsm
outlined this line
ifAssigned eax
mov edi eax
mov D$LastClickedSection edi
TSkinSection.SetFocus
call TSkinMenuSectionManager.IsSectionMenuItem
if eax = &TRUE
SetVar D$LastPopupMenu D$edi + TSkinSection.Parent
end_if
EndIfAssigned
end_if
ret
Hmmm. Ah yes, I remembered, I had rewritten TSZApplication.IsParentAWindow
so that it would test for more then one window, when I did the first
implementation of multiple windows. What to do?
Yes. Right-Click on TSZApplication.IsParentAWindow, RosAsm responds
instantly :
Proc TSZApplication.IsParentAWindow:
Argument @ParentPointer
mov ebx SizeOf_TSZSkinWindow
mov eax MaximumWindows
mul ebx
mov ecx D$SZApplication.MainWindow
add eax ecx
mov ebx D@ParentPointer
IsBetween ecx ebx eax
mov eax ecx
EndP
Ahhh , ecx gets a beating.....so ....
TMenuSectionManager.TabToParentMenu:
call TSZApplication.IsParentAWindow D$edi + TSkinSection.Parent
mov ecx D$edi + TSkinSection.Parent <*********** moved line past call,
problem fixed. 2 seconds.
if eax = &FALSE
mov eax D$ecx + TSkinPopupMenu.SpawnSection <**** RosAsm outlined this
line
ifAssigned eax
mov edi eax
mov D$LastClickedSection edi
TSkinSection.SetFocus
call TSkinMenuSectionManager.IsSectionMenuItem
if eax = &TRUE
SetVar D$LastPopupMenu D$edi + TSkinSection.Parent
end_if
EndIfAssigned
end_if
ret
But I see now, better to remove the ECX usage. But anyway.
RosAsm is GREAT for maintainance. HLA wouldnt be able to do this in less
then 10 minutes. Because HLA would take 5 minutes to compile, and for 2
full compiles, this would require 10 minutes + 2 seconds. Also HLA wouldnt
be able to point out the bug, as it is a runtime error.
> I one time I would have guessed Rene's age to be about 18. He certainly
> talks like an 18-year-old know-it-all. Wannabe talks the same way, though
> I'd probably peg him at 19. Never can tell though. Some people never
> grow up. (Was wannabe using Delphi at age 9?)
Hehe. Lol. Not sure I am glad to see you say I am older then Betov.
Maybe we can fix it like this :
FUCK OFF TO ALT.LANG.PREPARSERS.
> I wish I was Wannabe's age again. I remember the good old days when
> I, too, knew everthing :-)
Those days are DEFINITLY gone. I NEVER said I knew _everything_, we are
talking about _Structures_ and you have no idea of how easy it is to
format data in asm, and how silly asmers think the HLL constructs are.
They hide meaning, and add work, and doesnt have one single advantage over
asm code. They are totally uneeded, and they make for less readable code,
takes longer to learn, and the knowledge is useless next door. What you
learn from RosAsm can be used in all assemblers.
> Cheers,
> Randy Hyde
f0dder
*snip*
> What a FUD master !!! I have NEVER said that. You dont see it
> Randy....you dont see that data is just a sequence of bytes :
>
> [TAeroPlane.Destination.x sizeof_TComposite3DObject
> TAeroPlane.Destination.y TAeroPlane.Destination.x + SizeOf_Double
> TAeroPlane.Destination.z TAeroPlane.Destination.y + SizeOf_Double
> TAeroPlane.Speed.x TAeroPlane.Destination.z + SizeOf_Double
> TAeroPlane.Speed.y TAeroPlane.Speed.x + SizeOf_Double
> TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
> SizeOf_TAeroPlane TAeroPlane.Speed.z + SizeOf_Double ]
>
*snip* (hm, tabbing is probably botched).
How do you read that? normal left-to-right, or in column mode?
This declaration looks very strange to me... does it define a
structure, or declare the data? Looks like a very queer way of
doing anything.
The Wannabee
<f0dder_s...@flork.dk>:
queer way? urk.. No Thanks :-) I prefer women. Ask someone else. I agrea,
this is only one example, of RosAsm usage. It doesnt reflect on RosAsm,
but on me.
How do you read it ? Right-click. Right-click on white space to get back.
Those are just offsets. They are long, again showing that RosAsm easily
handles long identifyers. And they are not recommended _RosAsm_ way. They
are the way _I_ write currently. (RosAsm offers MANY diffrent styles). But
because of CTRL-C + CTRL+V they are just as fast to write, if not faster
then the Delphi structures. However. Any man saying that the writing of
stuctures is a pain in the ass, needs to locate his testicles real fast,
as this is the part of a program that requires the LESS time than just
about anything. Nomatter how long the structures.
For each such structure, 10K or more of code is written. Actually the
queer way is that of C, where you use both long AND unreadable
identifiers. Like fwd_PlFdFast_PID_U Like if it was written by a moronic
multiple personality which brain still belived that a long label will make
for larger code.
Anyway, maybe you have a point, that it is not easy to understand. Well,
they are equates, using equates to offset themselfes, so that in a large
Object Tree, I dont have to reoffset every single member while the code
still evolves.
Someone like yourself, used to see small things only, would probably say
[P.d.x 0
P.d.y 2
p.d.z 4
......
_____
P.size 8]
Each to its own dick be true. :-)))
f0dder
>
> queer way? urk.. No Thanks :-) I prefer women. Ask someone else. I
> agrea, this is only one example, of RosAsm usage. It doesnt reflect
> on RosAsm, but on me.
>
strange, ...
> How do you read it ? Right-click. Right-click on white space to get
> back.
I'm in a text editor, not in RosASM :)
But I think I get it now... the leftmost part is the "label", "equate
name", or call it what you want. And then you keep adding and adding...
What is the advantage of doing it this way? It's a lot longer than
necessary (and easy to get lost in it, if you need large structs),
the lack of any symbols (':' or '=') makes it look weird, and...
What's the advantage of using this way, instead of a 'normal' kind of
struct declaration? There's no code size/speed difference, and
struct TAeroplane {
double Destination_X, Destination_Y, Destination_Z;
double Speed_X, Speed_Y, Speed_Z;
};
certainly looks a lot more readable to me...
> For each such structure, 10K or more of code is written. Actually the
> queer way is that of C, where you use both long AND unreadable
> identifiers. Like fwd_PlFdFast_PID_U Like if it was written by a
> moronic multiple personality which brain still belived that a long
> label will make for larger code.
>
Heh, what does an identifier name like that have to do with C?
> Anyway, maybe you have a point, that it is not easy to understand.
> Well, they are equates, using equates to offset themselfes, so that
> in a large Object Tree, I dont have to reoffset every single member
> while the code still evolves.
>
Neither would you with a struct... that kind of re-offsetting would
only be necessary if you used equates... and didn't base the equate
positions on the previous ones. Btw, what happens if you need to
shuffle the order of a bunch of members? :-)
The Wannabee
<f0dder_s...@flork.dk>:
> The Wannabee wrote:
> I used 'queer' in the original meaning of the word. You know: Odd,
> strange, ...
Oh...okey then I am strange then. I like that better. Sorry then for the
silly jokes.
>> How do you read it ? Right-click. Right-click on white space to get
>> back.
> I'm in a text editor, not in RosASM :)
See what trouble you get for not using it ?
> But I think I get it now... the leftmost part is the "label", "equate
> name", or call it what you want. And then you keep adding and adding...
:-) Yes. Its an structure used with OOP, or SOOAP, as I call mine. Its all
a bit of fun, too. But mostly I did all this to see how close to Delphi
syntax I could create my RosAsm code. Its is an experiment. A pascal
programmer would be able to read my code, mostly, I think. And this is on
purpose.
> What is the advantage of doing it this way?
Theres mainly only ONE thing to remember when writing structures like that.
> It's a lot longer than
> necessary (and easy to get lost in it, if you need large structs),
If you need larger structs they will allways be large. But beeing very
homogenious (pun not intended), they need to be understood only once. They
are offsets plain and simple. Beeing long can be a problem, but consider
that they make for writing :
HLA
fld Q$ebx + TAeroPlane.Direction.y ;and now you maybe see why they are
easier to read.
HLA ?
fld (AeroPlane.Direction.y) ;if at all possible in HLA, doesnt
add much to clearity.
RosAsm is monofile. While it is fully possible (proven by RosAsm itself)
to write much shorter and create large applications, I didnt know this at
the outset. I was blank mostly then, and still have a lot to understand,
for instance, I dont fully comprehend lea yet. I intend to use RosAsm to
the day I die, and intend writing large applications with it, so I choose
to go for verbose, since I allready got used to that with Delphi. So far,
it has proven RosAsm to be equally productive to me as Delphi was.
Actually more. And RosAsm runs faster, it loads faster, it has ALL source
code embedded, it if Free, it has disassebler, run-time debugger, OS
equates embedded, its created by a cool person, and by some of the finest
programmers. I can have fun for the rest of my life with this one. And so
far its been faster to write anything with, faster to find bugs, there are
only ups here. Wheres the drawbacks ? RosAsm is even ethical. You cant do
better then all this, can you ?
> the lack of any symbols (':' or '=') makes it look weird, and...
> What's the advantage of using this way, instead of a 'normal' kind of
> struct declaration? There's no code size/speed difference, and
[AeroPlane : @Destination_X : 0 0 @Destionation_Y : 0 0 #2 @Destination_Z
0 0
@Speed_X : 0 0 @Speed_Y : 0 0 @Speed_Z : 0 0]
RosAsm has more then one way.
>
> struct TAeroplane {
> double Destination_X, Destination_Y, Destination_Z;
> double Speed_X, Speed_Y, Speed_Z;
> };
>
> certainly looks a lot more readable to me...
Yes. But the example was for an Object, a fully OOP, inherited object. And
when using the offsets, the code will show a full qualifier, useful in asm
code. Very useful there. We cannot compare C and asm, C is a language made
to abstract asm away, made to be readable (???) while RosAsm is made to
SHOW asm, and to learn the benefits of asm.
> Heh, what does an identifier name like that have to do with C?
A bit exagerated :-) but there are _worse_, in some C code, belive me.
But there are better as well. I know this of course. But actually C is
traditionally known to be cryptic.
> Neither would you with a struct... that kind of re-offsetting would
> only be necessary if you used equates...
True.
> and didn't base the equate
> positions on the previous ones. Btw, what happens if you need to
> shuffle the order of a bunch of members? :-)
I have my methods. It requires only moving the line, and correcting the
intersections. Not much work, out of the total. I dont do that often.
The big diffrence is that this is ONE way of doing it, that reads : asm
can do what Structs can do, but structs don't show what asm shows, they
hide meaning, and they have also many rules that make them harder to
learn. C has forexample a MULTITUDE of spesial rules that are not
applicable to Pascal, and visaversa. Most asm knowledge are useful between
the majority of assemblers. If not, then the assemblers make things too
complex. (note: I know I tend to do this too :-( )
Sorry for thinking you called me a queer, in the meaning of gay. That I am
strange, is just an honor.
Beyond2000!
There is different ways to define a structure in RosAsm.
Personally i prefer the simple way that is displaying them as what
they really are, i mean...a chunck of data.
So, for me i prefer to use this style (For example, the WNDCLASSEX
structure):
[wc:
wc.cbSize: D$ 0
wc.style: D$ 0
wc.lpfnWndProc: D$ 0
wc.cbClsExtra: D$ 0
wc.cbWndExtra: D$ 0
wc.hInstance: D$ 0
wc.hIcon: D$ 0
wc.hCursor: D$ 0
wc.hbrBackground: D$ 0
wc.lpszMenuName: D$ 0
wc.lpszClassName: D$ 0
wc.hIconSm: D$ 0]
On this way i know exactly what member is...either data (D$), word
(W$), Byte (B$) etc etc....and then only define them on the proper
place, instead the 0.
If i have to define the style on the style member in this structure
(wc.style), all i have to do is insert he equates in there like:
[wc:
wc.cbSize: D$ 0
wc.style: D$ &CS_HREDRAW
wc.lpfnWndProc: D$ 0
wc.cbClsExtra: D$ 0
wc.cbWndExtra: D$ 0
wc.hInstance: D$ 0
wc.hIcon: D$ 0
wc.hCursor: D$ 0
wc.hbrBackground: D$ 0
wc.lpszMenuName: D$ 0
wc.lpszClassName: D$ 0
wc.hIconSm: D$ 0]
Btw, every Equate in RosAsm is used with an pre-defined "&" sign
followed byt the name of the equate.
It愀 simple, and readable.
Best regards,
Guga
f0dder
>> I'm in a text editor, not in RosASM :)
>
> See what trouble you get for not using it ?
>
view it in the intended IDE or in plain text. If it needs an
IDE to be read easily, it's not too suitable if you want to
show other people a piece of your code (assuming we live in
the current world, where people use a multitude of different
development tools.)
> :-) Yes. Its an structure used with OOP, or SOOAP, as I call mine.
> Its all a bit of fun, too. But mostly I did all this to see how close
> to Delphi syntax I could create my RosAsm code. Its is an experiment.
> A pascal programmer would be able to read my code, mostly, I think.
>
Certainly not the structure definition! Yes, the TStrucName notation
is pascal-style, but the way you declare the structure... *shudder*.
It would have helped a lot if you had done the lines in form of
"TAeroPlane.Destination.y: TAeroPlane.Destination.x + SizeOf_Double"
or
"TAeroPlane.Destination.y = TAeroPlane.Destination.x + SizeOf_Double"
That way it would have been more appearant how to read it, and I
wouldn't have been wondering whether I shoudl read it horizontally,
or vertically in columns.
*snip*
> Beeing long can be a problem, but consider that they make for writing:
*snip*
See end of post for some MASM code... I think the syntax is nice
and clear and easy to read and understand... while of course not
having any detrimental qualities. (MASM struct support has a few
quirks though, I think, when it comes to initializing complex
multiply nested strucs).
> [AeroPlane : @Destination_X : 0 0 @Destionation_Y : 0 0 #2
> @Destination_Z 0 0
> @Speed_X : 0 0 @Speed_Y : 0 0 @Speed_Z : 0 0]
>
That's even worse :-)
>> Heh, what does an identifier name like that have to do with C?
>
> A bit exagerated :-) but there are _worse_, in some C code, belive
> me. But there are better as well. I know this of course. But actually
> C is traditionally known to be cryptic.
>
I'm not too much a fan of the hungarian notation used by Microsoft,
and I'm not a fan of ultra-short identifiers either. The C language
doesn't enforce either (nor does assembly, C++, Python, ...)
>> and didn't base the equate
>> positions on the previous ones. Btw, what happens if you need to
>> shuffle the order of a bunch of members? :-)
>
> I have my methods. It requires only moving the line, and correcting
> the intersections. Not much work, out of the total. I dont do that
> often.
And with "real struct support", you'd just need to move the line.
The only disadvantage I can think of by implementing struc support
directly in the assembler, is that it might slow it down by a few
miliseconds, and grow the code a bit. I can live with that, though.
Here's the MASM code for struc stuff... notice the advantage of
having a TYPED assembler, you don't need a "real4 ptr" or
"real8 ptr" to denote the size of member when doing FLD.
TPoint3D STRUCT
x REAL4 ?
y REAL4 ?
z REAL4 ?
TPoint3D ENDS
TAeroplane STRUCT
Destination TPoint3D <?>
Speed TPoint3D <?>
TAeroplane ENDS
.data
my_plane TAeroplane < <0.3, 10.6, 7.0>, <1.0, 1000.0, 3.0> >
.code
mov ebx, [my_plane.Destination.x]
fld [my_plane.Speed.z]
xor eax, eax
mov ecx, (sizeof my_plane) / 4
rep stosd
hutch--
Betov's own assembler is not powerful enough to write structures and
unions where MASM has had the capacity for many years.
When you write code for an operating system that assumes the capacity
of structures and unions, you use them or you get an assebler than can
use them as you end up jumping through hoops otherwise to write
dangerous unreliable code the hard way.
Re-inventing the history of win32asm is another of Betov's fantasies,
like it or lump it, win32asm was invented by MICROSOFT and the example
code is in the 1993 version of MASM 611. Now if Betov knew just a
little more about C from the middle 90s for Windows, he would know
that the standard examples used different structures for different
windows versions based on the build models and it did not translate to
MASM very well at all.
I am guilty of rewriting operating system format Windows code to a
simplified model that did not have multiple code formats for multiple
build models and it has been published in MASM32 for over 6 years.
Another area that Betov is clearly ignorant of is the differece
between initialised and uninitialised data and why you use either.
MASM has long had the capacity to write initialised structures but
every time you do so you fill the initialised data section with static
data that makes the file larger for no purpose. Its not as if the
speed of registering a windows class is a critical aspect of loading a
window but there are values that can only be determined at run time
like the instance handle so you cannot fully load a WNDCLASSEX
structure at assembly time anyway.
With a big professional tool like MASM you have the choice of how you
do these things where with toys like Betov's assembler, you don't and
with MASM its simpler, cleaner and more efficient code. There are no
fashion dictates about what constitutes assembler code and there is
nothing PURE about doing tasks the wrong way with toothless inadequate
tools when you have powerful tools like MASM available for years as a
free download.
Percival
> RosAsm is GREAT for maintainance. HLA wouldnt be able to do this in less
> then 10 minutes. Because HLA would take 5 minutes to compile, and for 2
> full compiles, this would require 10 minutes + 2 seconds. Also HLA
> wouldnt be able to point out the bug, as it is a runtime error.
Try ollydbg. It does support HLA syntax, and it does do instant
"recompiles" in memory. Sort of... But it doesn't recompile, it just
replaces that current byte. Anyway, i seriously doubt it would take any
more than 20 seconds for HLA to compile something, and that is talking
about HUGE programs.
>> I one time I would have guessed Rene's age to be about 18. He certainly
>> talks like an 18-year-old know-it-all. Wannabe talks the same way, though
>> I'd probably peg him at 19. Never can tell though. Some people never
>> grow up. (Was wannabe using Delphi at age 9?)
>
>
> Hehe. Lol. Not sure I am glad to see you say I am older then Betov.
>
> Maybe we can fix it like this :
>
> FUCK OFF TO ALT.LANG.PREPARSERS.
???? Interesting.
>> I wish I was Wannabe's age again. I remember the good old days when
>> I, too, knew everthing :-)
>
>
> Those days are DEFINITLY gone. I NEVER said I knew _everything_, we are
> talking about _Structures_ and you have no idea of how easy it is to
> format data in asm, and how silly asmers think the HLL constructs are.
> They hide meaning, and add work, and doesnt have one single advantage
> over asm code. They are totally uneeded, and they make for less readable
> code, takes longer to learn, and the knowledge is useless next door.
> What you learn from RosAsm can be used in all assemblers.
>
Maybe its just me, but are we arguing about:
mov eax, [addr + point.x]
vs
mov eax, [addr.x]
???
Cause if thats all that this argument is about then WTF? Thats all i can
say. It doesn't make any sense arguing.
Percival
Percival
> For each such structure, 10K or more of code is written. Actually the
> queer way is that of C, where you use both long AND unreadable
> identifiers. Like fwd_PlFdFast_PID_U Like if it was written by a moronic
> multiple personality which brain still belived that a long label will
> make for larger code.
Erm... say what?
struct point{
int x;
int y;
} p1, p2;
p1.x = 10;
p1.y = 15;
C like structures look clean to me.
Percival
Betov
@posting.google.com:
> [...insane bulshits...]
Still for beginners who would have read Hutch--, --, --
post, you have to know _who_ is Hutch--, --, --, -- to
understand a word of his rants:
Hutch-- is a Power Basic Programmer who redistributes
illegally a MicroSoft Product: MASM. He never wrote
anything significative, in Assembly, and he is openly
and publicly a member of the "Anti-GPL Mouvement".
Betov.
The Wannabee
<f0dder_s...@flork.dk>:
> The Wannabee wrote:
>>> I'm in a text editor, not in RosASM :)
>> See what trouble you get for not using it ?
>>
> My point is that source should be easy to read, whether you
> view it in the intended IDE or in plain text. If it needs an
> IDE to be read easily, it's not too suitable if you want to
> show other people a piece of your code (assuming we live in
> the current world, where people use a multitude of different
> development tools.)
Hmm. Well, in the case of not having the editor, we will be back to the
normal way, and thus will have to live with usual limitations. However,
reading C or Pascal, not knowing C or pascal will be much more trouble.
Once one knows how the rules for equates is in RosAsm, confusion dissapear.
The rules are :
1) [ThisIsAnEquate 4]
[SizeOf_Double 8] ; this too
2 [Duplicate.Equate ThisIsAnEquate] ; this too
3 [Calculated_Equate (ThisIsAnEquate + Duplicate.Equate * 2) ] ; this
is an equate too set to 16
They are all equates, e.g Constants. Once you get into the feel of not
seeing the "missing" : it will in fact be no problkem to read. Rene also
removed , from memonics (Its optional) so that you can write
Mov eax ebx ; No comma
but you can still write
mov eax, ebx ;if you insist
and even alternatives.
This turned out to be increadibly easy to get used to.
> Certainly not the structure definition! Yes, the TStrucName notation
> is pascal-style, but the way you declare the structure... *shudder*.
:-)) As you know, there are other ways.
[ AeroPlane:
@Destination.x : F$ 0
@Destination.y : F$ 0
@Destination.z : F$ 0]
Why is this worse than your C ?
This does 3 things at once :
Its declares a stucture, and creates a variable, and initialize it all at
the same time. And the initialization happens at compiletime, not cutting
into loading/runtime times.
> It would have helped a lot if you had done the lines in form of
> "TAeroPlane.Destination.y: TAeroPlane.Destination.x + SizeOf_Double"
> or
> "TAeroPlane.Destination.y = TAeroPlane.Destination.x + SizeOf_Double"
I see what you mean. One peek into BU_ASM expains it. But theese are
simply equates, and thoose do not need more signs than a space, to hold
them apart. Most sources are not self explainatory, and if we talk about
read C, for someone without a C book close, ojajamama, this would be close
to impossible.
Anyway, alternatively we could write :
TAeroPlane.Destination.y (TAeroPlane.Destination.x + SizeOf_Double)
but all this is very easy to understand, once equates is grasped.
> That way it would have been more appearant how to read it, and I
> wouldn't have been wondering whether I shoudl read it horizontally,
> or vertically in columns.
Oki. Well. It should be read both ways. Vertical for ordinary usage, in
day to day, and only the first column, and if you suspect and error, then
read horizontally, to verify, that the eqautes are correctly written.
:-))) Its no joke, its true. And it is 0.0002 % of my time.
> *snip*
>> Beeing long can be a problem, but consider that they make for writing:
> *snip*
>
> See end of post for some MASM code... I think the syntax is nice
> and clear and easy to read and understand... while of course not
> having any detrimental qualities. (MASM struct support has a few
> quirks though, I think, when it comes to initializing complex
> multiply nested strucs).
>
>> [AeroPlane : @Destination_X : 0 0 @Destionation_Y : 0 0 #2
>> @Destination_Z 0 0
>> @Speed_X : 0 0 @Speed_Y : 0 0 @Speed_Z : 0 0]
>>
> That's even worse :-)
How is this then :
[ AeroPlane:
@Destination.x : R$ 0
@Destination.y : R$ 0
@Destination.z : R$ 0]
Its exactly the same. One of the nice/bad features of RosAsm is the very
rich room for custom declarations. I think its nice.
> I'm not too much a fan of the hungarian notation used by Microsoft,
> and I'm not a fan of ultra-short identifiers either. The C language
> doesn't enforce either (nor does assembly, C++, Python, ...)
Then you sound like Betov, and you would probably like to read RosAsm
source. It uses simple readable equates, no funny diversions, like I use,
just plain simple labels :
; 'Main', 'AsmMain' 'CreateToolBar', 'PrintColorText',
'PrintCaretAndUnderline'
; 'EnableHelpMenutems', 'SetPosOnF12', 'MarginAction', 'SortDialogs',
'AdjustBpTable'
; 'BpMenu', 'CharMessage', 'InsertSource', 'ControlZ', 'SetMRUmenu'
; 'WriteChecker', 'BuildTitleTable','RegistryData' 'SetTreeDialogPos'
; 'DirectSourcePointing'
; 'ReplaceMacros' 'SearchSortedRegularLabel'
; 'SetQwordCheckSum'
; 'StoreVirtualData' 'OutOnError'
; 'ControlV' 'ControlZ' 'TextPos'
; 'InternSearch' 'RightClick' 'BpMenu' 'RightClickOnBlock' 'StatusBar'
; 'EncodeDecode'
This is btw from the main section in RosAsm. Its just comments. But
right-click on one to jump to that routine. What other languages allows
you to list the important routines you work on, as commments inside the
starting point, or elsewhere, to be rightclicked like that. Or to be
looked at for interest ? RosAsm has so many rare and nice features, you
would be very powerless for not having those in other languages. Its
impossible to list them all. They are multitudes, and they are all useful
in some way, and they grow naturally into your work as it expands. And
Betov keeps adding features I want, before I get around to ask. Last time
it was the SAVE ALL TITLES. I had been hoping he would, but then I didnt
get around to ask. 10 weeks or something later, there it was :-))
You see RosAsm is LOGICAL. Its is intuitive, and thus, theres no surprice
that the features that turns up are what you wanted. Features are added on
pragmatic need-to-have / Useful basis. This means, if it is a very useful
feature, it will be there. If you think its useful, and its not there. You
are simply wrong :-))) :-))) :-))) :-))))
> And with "real struct support", you'd just need to move the line.
True. big deal, it happens only after new design dessision, and only when
you need to insert them, not when adding. Depends on designtechnich as
well. I use to insert stuff as needed, (bad way, better to think it all
through at the start), but this insignificant out of the time it takes to
crack out a solution, implement the code, test it, rewrite it, and test it
again. Repeat until good.
> The only disadvantage I can think of by implementing struc support
> directly in the assembler, is that it might slow it down by a few
> miliseconds, and grow the code a bit. I can live with that, though.
Fact is, you can live without it too. And that _IS_ my point. This is my
_main_ point.
> Here's the MASM code for struc stuff... notice the advantage of
> having a TYPED assembler, you don't need a "real4 ptr" or
> "real8 ptr" to denote the size of member when doing FLD.
>
> TPoint3D STRUCT
> x REAL4 ?
> y REAL4 ?
> z REAL4 ?
> TPoint3D ENDS
It turns to questions?. What is REAL4 ? Is it a native real type ? Whats
its size? 4 bytes ?
No, a real is at least 6, 8 or 10 right ? Errr..theres single, that is 4
bytes..
I do not see the big diffrence /advantage between what you just wrote and
this (assuming 4 bytes, while I do not know what real4 is) :
[TPoint.x 0
TPoint.y 4
TPoint.z 8
___________________
SizeOf_TPoint3D 12]
In fact I see two native uneeded KeyWords, designed to keep you tied into
the language. How does they really make things easier. By automatically
calculating the offsets ? Why is that such a big deal ? An asmer will
learn the sizes of most datatypes, while a HLL man, who is an expert, will
sometimes not know the sizes of a type. How many bytes in Extended ? 8 or
10. int64 is easy. See, even HLL people add numbers to types to remember
their true size sometimes, just messing up the language.
In C the langage is a full pigstye :
ULONG
USHORT
LONGLONG
STILONGS
LONG
SHORTINT
UBYTE
UCHAR
etc....
next they going to add
WIDEWIDE
INT6464
LONGLONGLONG
EXTRALARGE
LARGELONGS
LONGLARGES
REALLONGLONGS
........anyway...move on........
Here are _some_ alternative RosAsm syntax
[TPoint3D:
@x : F$ 0.0
@y : F$ 0.0
@z : F$ 0.0]
Or this :
[REAL4 F$]
[TPoint3D:
@x : REAL4 0.0
@y : REAL4 0.0
@z : REAL4 0.0]
>
> TAeroplane STRUCT
> Destination TPoint3D <?>
> Speed TPoint3D <?>
> TAeroplane ENDS
[TAeroPlane.Destination 0
TAeroPlane.Speed 12
_______________________________________________
SizeOf_TAeroPlane 2*Sizeof_TPoint3D]
> .data
> my_plane TAeroplane < <0.3, 10.6, 7.0>, <1.0, 1000.0, 3.0> >
[My_Plane:
Destination : F$ 0.3 10.6 7.0
Speed : F$ 1.0 1000.0 3.0]
>
> .code
> mov ebx, [my_plane.Destination.x]
> fld [my_plane.Speed.z]
> xor eax, eax
> mov ecx, (sizeof my_plane) / 4
> rep stosd
RosAsm :
mov ebx D$my_plane@Destination + TPoint3D.x
fld w$my_plane@z
xor eax eax
mov ecx ( SizeOf_TAeroPlane / 4 )
rep stosd
--
What is RosAsm ?
http://betov.free.fr/RosAsm.html
RosAsm is the assembler that makes you feel like a Formel 1 programmer.
The Wannabee
> This is still the same nonsense of misleading beginners because
> Betov's own assembler is not powerful enough to write structures and
> unions where MASM has had the capacity for many years.
>
> When you write code for an operating system that assumes the capacity
> of structures and unions, you use them or you get an assebler than can
> use them as you end up jumping through hoops otherwise to write
> dangerous unreliable code the hard way.
That happens only when you dont know what you are doing. Less chance of
that in asm.
>
> Re-inventing the history of win32asm is another of Betov's fantasies,
RosAsm is reinvented to include new hardware consideration. Monofiles are
perfect example. We now have insane amounts of memory available. Delphi
uses mulitple files, this is a REAL MESS in large applications, you end up
with 8-20 open windows, to have access to the implementations of you
definitions, RosAsm is clicktime.
> like it or lump it, win32asm was invented by MICROSOFT and the example
> code is in the 1993 version of MASM 611. Now if Betov knew just a
> little more about C from the middle 90s for Windows, he would know
> that the standard examples used different structures for different
> windows versions based on the build models and it did not translate to
> MASM very well at all.
Point beeing ?
> I am guilty of rewriting operating system format Windows code to a
> simplified model that did not have multiple code formats for multiple
> build models and it has been published in MASM32 for over 6 years.
> Another area that Betov is clearly ignorant of is the differece
> between initialised and uninitialised data and why you use either.
Wrong.
[IntialziedData : B$ 'Hutch the beer pimping programmer at upside down
town sydney ' 0 ':-))' 0
Major : &DickHead
Minor : &Inteligence
Features : F$ 0.0000000000
LinksTo : &RANDALL_HYDE]
> MASM has long had the capacity to write initialised structures but
> every time you do so you fill the initialised data section with static
> data that makes the file larger for no purpose. Its not as if the
> speed of registering a windows class is a critical aspect of loading a
> window
True. Why the fuss then ?
> but there are values that can only be determined at run time
> like the instance handle so you cannot fully load a WNDCLASSEX
> structure at assembly time anyway.
No, true. What your point ?
> With a big professional tool like MASM you have the choice of how you
> do these things where with toys like Betov's assembler, you don't and
> with MASM its simpler, cleaner and more efficient code.
Wrong.
> There are no
> fashion dictates about what constitutes assembler code and there is
> nothing PURE about doing tasks the wrong way with toothless inadequate
> tools when you have powerful tools like MASM available for years as a
> free download.
There are good solution, RosAsm, and less good, Masm.
>
> Regards,
>
> hutch at movsd dot com
--
What is RosAsm ?
http://betov.free.fr/RosAsm.html
RosAsm is the assembler that makes Randy and Hutch bleed with envy.
The Wannabee
> The Wannabee wrote:
>> RosAsm is GREAT for maintainance. HLA wouldnt be able to do this in
>> less then 10 minutes. Because HLA would take 5 minutes to compile, and
>> for 2 full compiles, this would require 10 minutes + 2 seconds. Also
>> HLA wouldnt be able to point out the bug, as it is a runtime error.
>
> Try ollydbg. It does support HLA syntax, and it does do instant
> "recompiles" in memory. Sort of... But it doesn't recompile, it just
> replaces that current byte. Anyway, i seriously doubt it would take any
> more than 20 seconds for HLA to compile something, and that is talking
> about HUGE programs.
Try then to do a full compile of a 700KB source. about 440ms in RosAsm.
>
>>> I one time I would have guessed Rene's age to be about 18. He certainly
>>> talks like an 18-year-old know-it-all. Wannabe talks the same way,
>>> though
>>> I'd probably peg him at 19. Never can tell though. Some people never
>>> grow up. (Was wannabe using Delphi at age 9?)
>>
>>
>> Hehe. Lol. Not sure I am glad to see you say I am older then Betov.
>>
>> Maybe we can fix it like this :
>>
>> FUCK OFF TO ALT.LANG.PREPARSERS.
>
> ???? Interesting.
Yes......... now Randy cut 2 years of my age, so I must be 17. Randy knows
his math.
>>> I wish I was Wannabe's age again. I remember the good old days when
>>> I, too, knew everthing :-)
>>
>>
>> Those days are DEFINITLY gone. I NEVER said I knew _everything_, we are
> Maybe its just me, but are we arguing about:
> mov eax, [addr + point.x]
>
> vs
>
> mov eax, [addr.x]
> ???
No. We are arguing over Randall's assumtion that RosAsm doesnt support
structures. This is as close to total ignorance as you can possibly get.
Not to mention Randys job is to know asm. Does he even know any form of
it? Even hex coders must use structures. All data must be stuctured, else
it becomes meaningless. This is one of my points. Randy things his _form_
of stuctures are great revelations over normal asm methods. This is not
only wrong, but they are also making things worse. Not to mention the job
of creating them as inherent part of his HLA preparser. When all it takes
is to the "added" work I have allready listed so many times now, what is
the huge benefit of them ?
To an asmer : NONE
to a HLL man : NONE, just keeps him ignorant.
> Cause if thats all that this argument is about then WTF? Thats all i can
> say. It doesn't make any sense arguing.
>
> Percival
--
What is RosAsm ?
http://betov.free.fr/RosAsm.html
RosAsm is the fastest assembler for Win32 / ReactOS
The Wannabee
Talking about identifiers : look here :
AEP_boot_done typedef struct AEP_boot_done { struct AEPHDR AEP_b_d_hdr;
// AEP_BOOT_COMPLETE } AEP_boot_done, *PAEP_boot_done
AEP_dcb_config typedef struct AEP_dcb_config { struct AEPHDR
AEP_d_c_hdr; // Standard Header ULONG AEP_d_c_dcb; // 32-bit ptr to DCB
} AEP_dcb_config, *PAEP_dcb_config
AEP_dcb_unconfig typedef struct AEP_dcb_unconfig { struct AEPHDR
AEP_d_u_hdr; // Standard Header ULONG AEP_d_u_dcb; // 32-bit offset of
DCB } AEP_dcb_unconfig, *PAEP_dcb_unconfig
AEP_dcb_unconfig_pend typedef struct AEP_dcb_unconfig_pend { /* */
struct AEPHDR AEP_d_u_p_hdr; // AEP_PEND_UNCONFIG_DCB ULONG
AEP_d_u_p_dcb; // 32-bit offset of DCB } AEP_dcb_unconfig_pend,
*PAEP_dcb_unconfig_pend
AEP_dot_command typedef struct AEP_dot_command { /* */ struct
AEPHDR AEP_i_t_o_hdr; // Standard Header UCHAR AEP_d_c_flags;
// flags; see below PVOID AEP_d_c_pkeyword; // address of keyword
string; see below UCHAR AEP_d_c_key_len; // length of keyword; see
below ULONG AEP_d_c_num_1; // first numeric parameter ULONG
AEP_d_c_num_2; // second numeric parameter ULONG
AEP_d_c_num_3; // third numeric parameter } AEP_dot_command,
*PAEP_dot_command
AEP_drive_refresh typedef struct AEP_drive_refresh { struct AEPHDR
AEP_d_r_hdr; // AEP_REFRESH_DRIVE ULONG AEP_d_r_drive; //
drive number } AEP_drive_refresh, *PAEP_drive_refresh
AEP_inquiry_device typedef struct AEP_inquiry_device { struct AEPHDR
AEP_i_d_hdr; // Standard Header ULONG AEP_i_d_dcb; //
address of DCB } AEP_inquiry_device, *PAEP_inquiry_device
AEP_iop_timeout_occurred typedef struct AEP_iop_timeout_occurred {
struct AEPHDR AEP_i_t_o_hdr; // Standard Header ULONG
AEP_i_t_o_iop; // address of IOP that timed out }
AEP_iop_timeout_occurred, *PAEP_iop_timeout_occurred
AEP_lock_dcb typedef struct AEP_lock_dcb { struct AEPHDR
AEP_d_l_hdr; // AEP_DCB_LOCK PVOID AEP_d_l_pdcb; // address
of logical DCB ULONG AEP_d_l_drives; // bitmap of logical
drives UCHAR AEP_d_l_designtr; // designator UCHAR
AEP_d_l_align[3]; // reserved; don't use } AEP_lock_dcb, *PAEP_lock_dcb
AEP_mnt_notify typedef struct AEP_mnt_notify { struct AEPHDR
AEP_m_n_hdr; // AEP_MOUNT_NOTIFY PVOID AEP_m_n_pvrp; // VRP
of drive ULONG AEP_m_n_drivemap; // bitmap of child volumes
ULONG AEP_m_n_drive; // drive number of drive just mounted
ULONG AEP_m_n_effective_drive; // effective drive number ULONG
AEP_m_n_actual_drive; // actual drive number } AEP_mnt_notify,
*PAEP_mnt_notify
AEP_rm_handoff typedef struct AEP_rm_handoff { struct AEPHDR
AEP_r_m_h_hdr; // AEP_REAL_MODE_HANDOFF } AEP_rm_handoff,
*PAEP_rm_handoff
AEP_sys_crit_shutdown typedef struct AEP_sys_crit_shutdown { struct
AEPHDR AEP_s_c_s_hdr; // AEP_SYSTEM_CRIT_SHUTDOWN }
AEP_sys_crit_shutdown, *PAEP_sys_crit_shutdown
AEP_sys_shutdown typedef struct AEP_sys_shutdown { struct AEPHDR
AEP_s_s_hdr; // AEP_SYSTEM_SHUTDOWN } AEP_sys_shutdown,
*PAEP_sys_shutdown
AEP_vrp_create_destroy
How about this one :
"AEP_d_l_pdcb "
Looks "unclean" to me :-)))
> Percival
--
What is RosAsm ?
http://betov.free.fr/RosAsm.html
RosAsm is the assembler that makes you feel like a Formel 1 programmer.
The Wannabee
> The Wannabee wrote:
>> På Fri, 20 Aug 2004 02:11:22 +0200, skrev f0dder
>> <f0dder_s...@flork.dk>:
>>>
>>> struct TAeroplane {
>>> double Destination_X, Destination_Y, Destination_Z;
>>> double Speed_X, Speed_Y, Speed_Z;
>>> };
>>>
>>> certainly looks a lot more readable to me...
>>
>>
>> Yes. But the example was for an Object, a fully OOP, inherited object.
>> And when using the offsets, the code will show a full qualifier, useful
>> in asm code. Very useful there. We cannot compare C and asm, C is a
>> language made to abstract asm away, made to be readable (???) while
>> RosAsm is made to SHOW asm, and to learn the benefits of asm.
>
> C doesn't support objects. C was made for work. Asm is starting to be
> made for C.
I don know C, I ment C++, but this includes C, no ?
> And a fully OOP should support virtual functions and stuff so you only
> should have one or two decimal points at most.
Yes, but those are not needed at every level of inheritance. the methods
are inherited from the
TComposite3DObject. It contains all methods to load, and save, and edit
and render the object.
The only thing needed here (just an example anyway) was a destination for
the plane + a speed vector.
We could add methods to set the speed, but unless much code must run too
at that time, I prefer to change it directly.
>>> Heh, what does an identifier name like that have to do with C?
>>
>>
>> A bit exagerated :-) but there are _worse_, in some C code, belive me.
>> But there are better as well. I know this of course. But actually C is
>> traditionally known to be cryptic.
>>
>
> And asm is generally known to be unreadable. Doesn't stop me from using
> it.
Nor me.
>
> Percival
--
What is RosAsm ?
http://betov.free.fr/RosAsm.html
RosAsm is the assembler that makes you feel like a Formel 1 programmer.
The Wannabee
<Faq@.@.@.@szmyggenpv.com>:
:-))))
Correction:
>
> [HLA_Plane:
> Destination : F$ 0.0 0.0 0.0
> Speed : F$ 0.0 -1000.0 0.0]
f0dder
> Hmm. Well, in the case of not having the editor, we will be back to
> the normal way, and thus will have to live with usual limitations.
>
limitations on you - you are locked to the Win32/PE file format, and
cannot link with static libraries. This might not be a problem for
the RosASM audience, and the integrated nature does make for a good
tool (if you like the RosASM mindset). I don't see how traditional
tools are "limited", though.
> However, reading C or Pascal, not knowing C or pascal will be much
> more trouble. Once one knows how the rules for equates is in RosAsm,
> confusion dissapear.
Pascal was the first language I learned, and I had no problem reading
pascal source while learning. C wasn't hard either, except for a few
of the more funky pointer magic tricks. I couldn't read C++ before I
actually read a book on the subjec, though.
> The rules are :
>
*snip*
Yup, got that already :)
> They are all equates, e.g Constants. Once you get into the feel of not
> seeing the "missing" : it will in fact be no problkem to read. Rene
> also removed , from memonics (Its optional) so that you can write
>
I think it's good to keep those symbols - they allow for greater
readability. The additional writing speed you gain not using these
symbols is almost non-existant, but the decrease in read speed is bad.
Of course this is subject to personal opinion.
> [ AeroPlane:
> @Destination.x : F$ 0
> @Destination.y : F$ 0
> @Destination.z : F$ 0]
>
> Why is this worse than your C ?
>
It seems okay, actually - as long as the symbol table isn't polluted.
Ie, if @Destination.{x,y,z} become global symbols it would be bad.
But I guess '@' means local symbol, so the names in the symbol table
would be AeroPlane@Destination.{x,y,z} - this isn't too bad.
It's still an example of a very simple structure, though. Can you
easily declare & initialize nested structures in RosASM?
> I see what you mean. One peek into BU_ASM expains it. But theese are
> simply equates, and thoose do not need more signs than a space, to
> hold them apart.
>
An equals sign helps readability, though :)
> Most sources are not self explainatory, and if we talk about read C,
> for someone without a C book close, ojajamama, this would be close to
> impossible.
>
Humm... C is pretty simple, most of the things supported by the core
language only takes one assembly instruction on x86. If you know
nothing about C to start with, I can see a few things that are not
obvious - like use of |&^~! for or, and, xor, binary not, logical not.
Other than that, C code is usually pretty straightforward, unless
written by a moron :)
> How is this then :
> [ AeroPlane:
> @Destination.x : R$ 0
> @Destination.y : R$ 0
> @Destination.z : R$ 0]
>
> Its exactly the same. One of the nice/bad features of RosAsm is the
> very rich room for custom declarations. I think its nice.
>
This declaration is okay, easy enough to read - R$ might not be that
appearant though. I guess it's a "real" data type, but which of the
REAL data types the x86 supports? real4, real8, or real10?
> This is btw from the main section in RosAsm. Its just comments. But
> right-click on one to jump to that routine. What other languages
> allows you to list the important routines you work on, as commments
> inside the starting point, or elsewhere, to be rightclicked like
> that. Or to be looked at for interest ?
>
I don't know any *languages* that support it, but there's multiple
*IDE's* that support similar features. Visual Studio/C++ has some
very powerful tools if you create a Browse Information Database.
The "Class Browser" which works even without Browse Information is
pretty nice too, and (despite the name) doesn't just show C++
classes, but functions, data, macros and constants too.
> RosAsm has so many rare and nice features, you would be very
> powerless for not having those in other languages.
>
It does seem to have some nice features that's been missing for
assembly language development, yes. I don't like the monofile and
save-source-in-exe approach though...
>> And with "real struct support", you'd just need to move the line.
>
> True. big deal, it happens only after new design dessision, and only
> when you need to insert them, not when adding. Depends on
> designtechnich as well. I use to insert stuff as needed, (bad way,
> better to think it all through at the start), but this insignificant
> out of the time it takes to crack out a solution, implement the code,
> test it, rewrite it, and test it again. Repeat until good.
>
I tend to plan before writing code when I need larger projects. But
sometimes it's nice being able to change three lines in a struct to
go from float->double, to see the memory and speed hit in a large
project... without changing possibly hundred of lines of code.
>> The only disadvantage I can think of by implementing struc support
>> directly in the assembler, is that it might slow it down by a few
>> miliseconds, and grow the code a bit. I can live with that, though.
>
> Fact is, you can live without it too. And that _IS_ my point. This is
> my _main_ point.
>
Can live without, sure. I like things that make my work easier, though.
I could probably live without macros and equates, and probably even
labels, but then we'd be back to dos/debug.com functionality...
> It turns to questions?. What is REAL4 ? Is it a native real type ?
> Whats its size? 4 bytes ?
>
REAL = floating point data type (a 'real' is the math name), 4 bytes
indeed. x86 has native REAL4, REAL8 and REAL10 (float, double, (not
very widely supported anymore) long double). Iirc the pascal names
are be single, real, extended? And traditional masm naming would be
dd, dq, dt.
> No, a real is at least 6, 8 or 10 right ? Errr..theres single, that
> is 4 bytes..
> I do not see the big diffrence /advantage between what you just wrote
> and this (assuming 4 bytes, while I do not know what real4 is) :
>
> [TPoint.x 0
> TPoint.y 4
> TPoint.z 8
> SizeOf_TPoint3D 12]
>
You can look up REAL4 rather quickly if you have some documentation,
and it certainly "associates a data type with the name". In your
example the only information you get is that the data items are four
bytes big each (or they could be 1 or 2 bytes, with labels being
four-byte aligned).
It's all about readability and making your intensions clear.
> In fact I see two native uneeded KeyWords, designed to keep you tied
> into the language.
>
I believe they were designed for readability rather than lock-in...
remember that MASM is a *very* old product, way before all the MS
extensions to sun java etc.
> How does they really make things easier. By automatically calculating
> the offsets ? Why is that such a big deal ?
>
Automatically calculating offsets saves you time... and having a tool
do it is more robust than depending on a puny human. Let a machine do
a machine's job. Then there's the points of knowing data type, so you
can "FLD" without speciying size, or "mov [mystructure.member], 42"
without specifying size.
> In C the langage is a full pigstye :
>
> ULONG
> USHORT
> LONGLONG
> STILONGS
> LONG
> SHORTINT
> UBYTE
> UCHAR
> etc....
>
That's not C, that's win32...
Btw, how do you re-use a structure definition in rosasm, if you want
to declare multiple variables of the same structure type?
>> TAeroplane STRUCT
>> Destination TPoint3D <?>
>> Speed TPoint3D <?>
>> TAeroplane ENDS
>
> [TAeroPlane.Destination 0
> TAeroPlane.Speed 12
> SizeOf_TAeroPlane 2*Sizeof_TPoint3D]
>
Ooops - loss of information! And having to manually declare the
sizeof equate.
>
>> .data
>> my_plane TAeroplane < <0.3, 10.6, 7.0>, <1.0, 1000.0, 3.0> >
>
> [My_Plane:
> Destination : F$ 0.3 10.6 7.0
> Speed : F$ 1.0 1000.0 3.0]
>
Oops, having to re-type "Destination" and "Speed", and having to
re-specify data-type (what if you changed the structure to have
REAL8 instead of REAL4?)
>> .code
>> mov ebx, [my_plane.Destination.x]
>> fld [my_plane.Speed.z]
>> xor eax, eax
>> mov ecx, (sizeof my_plane) / 4
>> rep stosd
>
> RosAsm :
>
> mov ebx D$my_plane@Destination + TPoint3D.x
> fld w$my_plane@z
> xor eax eax
> mov ecx ( SizeOf_TAeroPlane / 4 )
> rep stosd
>
Again, you need a couple of size overrides. I could live with
having to do "my_plane@Destination + TPoint3D.x", but I think
the masm syntax is cleaner there. Too bad masm is bad with
regards to [indirection] and OFFSET.
f0dder
> MASM has long had the capacity to write initialised structures but
> every time you do so you fill the initialised data section with static
> data that makes the file larger for no purpose. Its not as if the
> speed of registering a windows class is a critical aspect of loading a
> window but there are values that can only be determined at run time
> like the instance handle so you cannot fully load a WNDCLASSEX
> structure at assembly time anyway.
>
"almost fully defined" in .data and fixing up the required runtime fields,
than filling every field at runtime (not surprising - you still need
the same amount of data, plus of course the instructions that fill the
struct). Looks cleaner, too :)
Betov
> This is still the same nonsense of misleading beginners because
> Betov's own assembler is not powerful enough to write structures and
> unions where MASM has had the capacity for many years.
RosAsm include a "Tool" that offer 3 Main forms of
Structures, for all Win32 Structures + others, with
Click&Go Customizations, and all. [Menu] / [Tools] /
[Structures].
> When you write code for an operating system that assumes the capacity
> of structures and unions, you use them or you get an assebler than can
> use them
for the "ass-ebler" yes, MASM could do. For an "Assembler",
i would recommand RosAsm, or FASM, depending on what you
plan to develop. For PEs production, the evident choice
is RosAsm. Simply the more advanced Environement, the
fastest Assembler, the easier IDE, the more secure Files
Management, and so on, and so on...
> as you end up jumping through hoops otherwise to write
> dangerous unreliable code the hard way.
??? For example ???
> Re-inventing the history of win32asm is another of Betov's fantasies,
Something wrong in B_U_Asm [The Rebirth] / [Rebirth_History] ???
> like it or lump it, win32asm was invented by MICROSOFT and the example
> code is in the 1993 version of MASM 611. Now if Betov knew just a
> little more about C from the middle 90s for Windows, he would know
> that the standard examples used different structures for different
> windows versions based on the build models and it did not translate to
> MASM very well at all.
:)) :)) :)) :)) :))
Oh, yes, sorry!!! I forgot that, if we are able to write
Assembly programs, nowadays, this is "thanks to MicroSoft"!!!
:)) :)) :)) :)) :))
There is no limit to insanity! Isn't it, ass-hole?
> I am guilty of rewriting operating system format Windows code to a
> simplified model that did not have multiple code formats for multiple
> build models and it has been published in MASM32 for over 6 years.
> Another area that Betov is clearly ignorant of is the differece
> between initialised and uninitialised data and why you use either.
If you say so... :)
> MASM has long had the capacity to write initialised structures but
> every time you do so you fill the initialised data section with static
> data that makes the file larger for no purpose.
True, IN SOME CASES. In 95% cases, the Code Initializations
of Structures are, anyway, longer, in Bytes, than what their
equivalent declarations, in Data, would be. Plus they consume
run-time.
> Its not as if the
> speed of registering a windows class is a critical aspect of loading a
> window but there are values that can only be determined at run time
> like the instance handle so you cannot fully load a WNDCLASSEX
> structure at assembly time anyway.
This was an EXAMPLE, and i am sure that 99% of the readers
perfectely understand what i mean, and agrea with what i
say, about this.
> With a big professional tool like MASM
:)) :)) :)) :)) :))
You probably mean, with a small unsignificant shit like
MASM, that is, nowadays, utterly overpassed by quality
Assemblers like FASM, RosAsm, GoAsm, ...
:)) :)) :)) :)) :))
> you have the choice of how you
> do these things where with toys like Betov's assembler, you don't and
> with MASM its simpler, cleaner and more efficient code. There are no
> fashion dictates about what constitutes assembler code and there is
> nothing PURE about doing tasks the wrong way with toothless inadequate
> tools when you have powerful tools like MASM available for years as a
> free download.
:)
If MASM is so great, it is an amaizing thing, that, when
debating about the various Assemblers "Speed Contest"s,
you are all unable to provide any link to any significative
Application, any App around, or above, say 500Kb, so that
we could give it a compilation test shot. And that is where
Master Pdf, the dancing Master, comes in the game, with his
insane "BenchMarking"s, and tries patheticaly to "prove"
the reverse of evidences. Well...
Mind you, for the actual Assemblers, and particulary for
RosAsm, there are already several sigificative Applications
written, plus of course the 2.5 megas of RosAsm itself for
the Auto-Compilation. Considering the number of real RosAsm
users (close to zero), this is a bright demonstration of the
RosAsm capacity, as a serious production Tool.
As opposed, for your pathetic and unsignificant MicroSoft
shit, all you could show, would be very poor and small
"Demos" and, of course, Asm Templates, written to be
nested into HLLs developements. By the way, exactely what
MASM has been written for: A C-Side-Tool, nothing more,
nothing else, nothing better. :))
Betov.
C
> På Fri, 20 Aug 2004 01:17:33 +0200, skrev f0dder
> <f0dder_s...@flork.dk>:
>
> > The Wannabee wrote:
> >
> > *snip*
> >> What a FUD master !!! I have NEVER said that. You dont see it
> >> Randy....you dont see that data is just a sequence of bytes :
> >>
> >> [TAeroPlane.Destination.x sizeof_TComposite3DObject
> >> TAeroPlane.Destination.y TAeroPlane.Destination.x + SizeOf_Double
> >> TAeroPlane.Destination.z TAeroPlane.Destination.y + SizeOf_Double
> >> TAeroPlane.Speed.x TAeroPlane.Destination.z + SizeOf_Double
> >> TAeroPlane.Speed.y TAeroPlane.Speed.x + SizeOf_Double
> >> TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
> >> SizeOf_TAeroPlane TAeroPlane.Speed.z + SizeOf_Double ]
In NASM (which you acknowledge is a 'real' assembler), I would
write (using my macro library)...
type TAeroPlane
variable co, TComposite3DObject
variable Destination.x, double
variable Destination.y, double
variable Destination.z, double
variable Speed.x, double
variable Speed.y, double
variable Speed.z, double
end_type
Or even ...
class TAeroPlane, TComposite3DObject
variable Destination.x, double
variable Destination.y, double
variable Destination.z, double
variable Speed.x, double
variable Speed.y, double
variable Speed.z, double
; you can add methods which are
; inherited, just like Java :-)
end_class
Or maybe...
type TAeroPlane
variable co, TComposite3DObject
type Destination
variable x, double
variable y, double
variable z, double
end_type
type Speed
variable x, double
variable y, double
variable z, double
end_type
end_type
I do not think we need a vote to determine which version
is more readable, yours or mine. And readability is the
main issue, whatever the method of implementation of the
structured data, the resulting code must be both easy to
read and easy to maintain.
I regularly move, insert and delete structure members,
using such macros are those above result in code where
such operations are trivial. Using complex enumerations,
as you have done, makes such alterations far more time
consuming. (Ie. for me a simple cut-and-paste, for you
an amount of editing as you relink the enumerations, as
an example try switching the locations of the Speed and
Destination structures.)
I do not hold that an assembler needs such functionality
as structures built in, though if the assembler's author
elects not to directly parse such structures, then other
methods should be supplied to write such code -- macros
being the most obvious.
I have a feeling that RosAsm's macros are just powerful
enough to write a similar 'type' macro, though they are
nowhere near powerful enough to write a 'class' macro
which works like the one above.
[snip]
> "HLA.EXE is not an assembler. Indeed, it's not even a compiler,
> pre-processor (or "preparser", whatever that is), though it
> *might* qualify as [a] 'text converter.'"
> - Randy Hyde, author of 'HLA,'
> in ALT.LANG.ASM newsgroup
> August 11, 2004
That statement is taken completely out of context, if you are
going to waste time insulting HLA, at least stick to the facts.
C
2004-08-20
Betov
$edfa...@dtext01.news.tele.dk:
> The Wannabee wrote:
>> Hmm. Well, in the case of not having the editor, we will be back to
>> the normal way, and thus will have to live with usual limitations.
>>
> Hm, which limitations? I would say RosASM itself imposes a number of
> limitations on you - you are locked to the Win32/PE file format, and
> cannot link with static libraries.
This is exactely RosAsm definition: An Assembly
Developement Environement for writing PEs. One
can call this a "limitation" if he likes to make
fun of it.
> [...]
>>
> I tend to plan before writing code when I need larger projects. But
> sometimes it's nice being able to change three lines in a struct to
> go from float->double, to see the memory and speed hit in a large
> project... without changing possibly hundred of lines of code.
Too bad that you never wrote anything significative in
Assembly, isn't it? You could have, for example, with
a Tool like RosAsm, have declared your Structure through
Macros Evocations... :)
Betov.
hutch--
> But I'm not too sure if it's any harder to write equally bad code in RosAsm.
>
> --Luc.
Feel free to show us all how its done and make it understandable to a
beginner as well. Should we hold our breath waiting ?
Percival
For one thing, it won't compile. Second, how is this a limitation of C?
I'd say, its the limitation of the author.
I can do that in ASM if you want me to.
struc AEP_boot_done {
.AEPHDR AEP_b_d_Hdr
.AEP_BOOT_COMPLETE dd ?
}
struc AEP_dcb_config {
.AEP_d_c_hdr AEPHDR
.Header dd ?
}
struc AEP_dcb_unconfig{
.AEP_d_u_hdr AEPHDR
.AEP_d_c_dcb dd ??
}
AEP_boot_done AEP_BOOT_Done
PAEP_bootdone dd ?
etc etc.
And i bet this looks just as messy as the C code. Just cause YOU suck in
C doesn't mean i do.
Not to mention. You didn't indent, nor did you do anything. It looks
like you are joining the national ofusaction contest!!
Percival
hutch--
> Hutch-- is a Power Basic Programmer who redistributes
> illegally a MicroSoft Product: MASM. He never wrote
> anything significative, in Assembly, and he is openly
> and publicly a member of the "Anti-GPL Mouvement".
This comment is from Betov, the man who STOLE the assembler he cobbled
his own together with. This is the programmer who supports the big
dirty con of GPL that rips programers off around the world who has the
view that open "sauce" means anything you can pinch.
His one claim to fame is a self replicating assembler that is useless
for anything else like writing real life programs but it can build
itself. Muhahahaha.
Here is the critic of basic, masm and C when he cannot write any of
them. I wonder how he does it ? Is it sheer imagination ? Creative
thinking ? NAH, just too much cheap piss from the supermarket addling
the remains of his brain. :)
A pleasure as always to promote MASM at Betov's expense, its so easy
to do with a technically superior tool.
Still, its always a pleasure to be called a NOBODY from someone who is
a has been who never was. Muhahahaha.
Regards,
hutch at movasd dot com
Percival
> På 20 Aug 2004 01:59:58 GMT, skrev Percival <dragont...@yahoo.com>:
>
>> The Wannabee wrote:
>>
>>> På Fri, 20 Aug 2004 02:11:22 +0200, skrev f0dder
>>> <f0dder_s...@flork.dk>:
>>>
>>>>
>>>> struct TAeroplane {
>>>> double Destination_X, Destination_Y, Destination_Z;
>>>> double Speed_X, Speed_Y, Speed_Z;
>>>> };
>>>>
>>>> certainly looks a lot more readable to me...
>>>
>>>
>>>
>>> Yes. But the example was for an Object, a fully OOP, inherited
>>> object. And when using the offsets, the code will show a full
>>> qualifier, useful in asm code. Very useful there. We cannot compare C
>>> and asm, C is a language made to abstract asm away, made to be
>>> readable (???) while RosAsm is made to SHOW asm, and to learn the
>>> benefits of asm.
>>
>>
>> C doesn't support objects. C was made for work. Asm is starting to be
>> made for C.
>
>
> I don know C, I ment C++, but this includes C, no ?
C doesn't support OOP at all. Period.
>> And a fully OOP should support virtual functions and stuff so you only
>> should have one or two decimal points at most.
>
>
> Yes, but those are not needed at every level of inheritance. the methods
> are inherited from the
> TComposite3DObject. It contains all methods to load, and save, and edit
> and render the object.
> The only thing needed here (just an example anyway) was a destination
> for the plane + a speed vector.
>
> We could add methods to set the speed, but unless much code must run too
> at that time, I prefer to change it directly.
Actually, if the compiler was any smart, it would just hold an indirect
call to the correct function. What, 2-3 cycles more? Heck, C++ by
default inlines the code if you put it in the class definition, so then
it is actually faster than ASM emulating it... Unless we got assemblers
that inline code, or a set of macros that can emulate OOP and inline it.
Anyway, you do:
myVector.magnitude();
It doesn't matter what myVector is, it will call the correct "magnitude"
function. Even if myVector was either a 2dVector type, or a 3dVector
type. Virtual functions will let me abstract away from the function call
itself.
Now remember, OOP was not built for speed, but for clarity. Personally,
i think the inheritance thing is genious, and the fact that you create
an object from another object is cool.
Anyway, i think people here would understand that a plane, is a
transportation-type object and a Fuel using Interphase. Fuel types use
up fuel, and tryansportation carry things or people around.
Or, you don't have to use OOP and just do this is a plane instead.
Percival
Percival
Just a hint hutch... That does sound quite troll like. You probably
could get a bit more respect if you mellow down a bit.
1. GPL is popular.
Bash it,then you aren't popular.
Personally, i think you choose the licence that you want to use. GPL,
EULA, or otherwise.
2. Countering an insult with more insults is stupid
Not to mention, it makes both of you look stupid too.
At very least, insult him with not with how you see it, but how someone
else would see it. Something like, where he doesn't fix the bug is a
good one :)
3. Stole an assembler? I haven't heard that one yet. Any story behind it?
Percival
The Wannabee
I think yours look very nice, and are visually pretty, but dont think you
win much on other accounts.
> And readability is the
> main issue, whatever the method of implementation of the
> structured data, the resulting code must be both easy to
> read and easy to maintain.
>
> I regularly move, insert and delete structure members,
> using such macros are those above result in code where
> such operations are trivial. Using complex enumerations,
> as you have done, makes such alterations far more time
> consuming. (Ie. for me a simple cut-and-paste, for you
> an amount of editing as you relink the enumerations, as
> an example try switching the locations of the Speed and
> Destination structures.)
[TAeroPlane.Speed.x sizeof_TComposite3DObject
TAeroPlane.Speed.y TAeroPlane.Speed.x + SizeOf_Double
TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
TAeroPlane.Destination.x + TAeroPlane.Speed.z + SizeOf_Double
TAeroPlane.Destination.y TAeroPlane.Destination.x + SizeOf_Double
TAeroPlane.Destination.z TAeroPlane.Destination.y + SizeOf_Double
____________________________________________________________________________
SizeOf_TAeroPlane TAeroPlane.Speed.z + SizeOf_Double]
This took, a little more time, maybe 10 seconds more, didnt measure. This
is something I do very rarly. Most times I use other ways to structure
data. But its perfect for OOP. And hides nothing.
And rememeber, when I change the any object in the three, because of
SizeOf_AeroPlane, and sizeof_TComposite3DObject, it will automatically
offset the other objects in the three. And also it implisttly provides the
info about what object this object inherits from. Trivial. And good enough
for real apps.
> I do not hold that an assembler needs such functionality
> as structures built in,
My point exactly, addressing Randy.
> though if the assembler's author
> elects not to directly parse such structures, then other
> methods should be supplied to write such code -- macros
> being the most obvious.
RosAsm had (various) methods that works pretty ok.
> I have a feeling that RosAsm's macros are just powerful
> enough to write a similar 'type' macro, though they are
> nowhere near powerful enough to write a 'class' macro
> which works like the one above.
RosAsm allready has class macros. (OOA TITLE) But maybe not exactly as
above. Nevertheless, the exactness is flawless when it comes to the
functionality of the program, which is to structure data. And Randy claims
RosAsm doesnt support structures. It does, only in diffrent ways than HLA.
> [snip]
>
>> "HLA.EXE is not an assembler. Indeed, it's not even a compiler,
>> pre-processor (or "preparser", whatever that is), though it
>> *might* qualify as [a] 'text converter.'"
>> - Randy Hyde, author of 'HLA,'
>> in ALT.LANG.ASM newsgroup
>> August 11, 2004
>
> That statement is taken completely out of context, if you are
> going to waste time insulting HLA, at least stick to the facts.
Well, yes, this _are_ the facts, he says so himself ;-))) Out of context
or not. (which it really isnt) Annie spotted it, and I stole the quite. I
think it is brilliant of her to rephrase him in his own words, arguing my
case.
At least we are not lying to get ahead.
>
> C
> 2004-08-20
Betov
berlin.de:
> 3. Stole an assembler? I haven't heard that one yet. Any story behind
it?
Yes. This is an old story that Hutch-- sings since months:
I have "stolen" the very first Assembler i used for writing
the ancestor of SpAsm, because, i used the free Demo version,
of a ShareWare Assembler, ASM32, and never bought the ShareWare
version, with Macros, and all...
The Author of this ShareWare Assembler, himself, does not care,
at all, if i used or not his Demo Version, without buying his
ShareWare Version, and his Mail was forwarded, here, at A.L.A.,
but Mister Hutch-- seems to prefer going on, and on, with his
insane bullshits, and prefers to go on saying, that i have
stolen a Free Demo, whereas he is officially re-distributing
illegaly a MicroSoft Product... Well... There is no limit to
indecency... as so often times demonstrated right here... :)
Betov.
The Wannabee
No, true. I agree. But the c library source is filled with theese types of
identifyers, is it not ? So how will you avoid them then ?
> Not to mention. You didn't indent, nor did you do anything. It looks
> like you are joining the national ofusaction contest!!
I just pasted in some _SMALL_ set of C structs form the library of
Windows. The full set contains someting like 55000 equally insane
identifyers structures.
Anyway, your point is valid. But I have yet to see some c source that
doesnt use this writing convention, and I belive many would agree with me
that at least historically, this is the inheritance of C. And much of the
words C source look like the above. That _is_ a fact.
Randall Hyde
"Percival" <dragont...@yahoo.com> wrote in message
news:2omkh1F...@uni-berlin.de...
>
> 1. GPL is popular.
Yes.
> Bash it,then you aren't popular.
There are better licenses if you want to release free software (e.g., BSD)
and people are are *serious* about promoting free software realize the
limitations of GPL.
> Personally, i think you choose the licence that you want to use. GPL,
> EULA, or otherwise.
Cheers,
Randy Hyde
Percival
Which C library exactly? The C standard library have stuff like size_t
and time_t. Maybe windows? I personally never saw something like the
above. All i can say is, who ever wrote that must have been in an
ofuscation contest OR actually had a way to decode.
>> Not to mention. You didn't indent, nor did you do anything. It looks
>> like you are joining the national ofusaction contest!!
>
>
> I just pasted in some _SMALL_ set of C structs form the library of
> Windows. The full set contains someting like 55000 equally insane
> identifyers structures.
>
> Anyway, your point is valid. But I have yet to see some c source that
> doesnt use this writing convention, and I belive many would agree with
> me that at least historically, this is the inheritance of C. And much of
> the words C source look like the above. That _is_ a fact.
Back to the way to decode that stuff... I know of a few people, not me,
but others who put l if the variable is of type long, they name the
variable p if it is a pointer, etc. It looks as if the C coder had that
convention, and is arguably cleaner than most of others.
Arguably clean or not however, it looks like shit to me.
And my last point... That isn't a restriction of C, but a restriction of
whoever coded that stuff. So C-style structures actually usually don't
look like that.
Percival
The Wannabee
<Faq@.@.@.@szmyggenpv.com>:
> På 20 Aug 2004 06:45:03 -0700, skrev C <black...@asean-mail.com>:
>
> [TAeroPlane.Speed.x sizeof_TComposite3DObject
> TAeroPlane.Speed.y TAeroPlane.Speed.x + SizeOf_Double
> TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
> TAeroPlane.Destination.x + TAeroPlane.Speed.z + SizeOf_Double
> TAeroPlane.Destination.y TAeroPlane.Destination.x + SizeOf_Double
> TAeroPlane.Destination.z TAeroPlane.Destination.y + SizeOf_Double
> ____________________________________________________________________________
> SizeOf_TAeroPlane TAeroPlane.Speed.z + SizeOf_Double]
>
> This took, a little more time, maybe 10 seconds more, didnt measure.
Woopps....
> SizeOf_TAeroPlane TAeroPlane.Destination.z + SizeOf_Double]
Nobody noticed. To sure of myself ?
Alex McDonald
Good advert for not using this technique, I'd say. Structures should be
self-sizing.
--
Regards
Alex McDonald
The Wannabee
<alex...@btopenworld.com>:
When I use this types, I verify them, while in this case, it was just a
matter of typo, and not bothering to verify. And inside RosAsm where this
struct would be imidiatly tested and used I never made such mistake yet,
that I can recall. Once I messed up a couple of members, but because of
the way my memorymanager works + RosAsm, the mistakes was detected easily.
That day, I verified the full set of structures.
The verification is very easy, the nextmember is offset by the previous
member.
TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
also, the "TAeroPlane.Speed.y + SizeOf_Double" alone,
speak of the type of "TAeroPlane.Speed.y", and can be read :
TAeroPlane.Speed.y is of type (size) double.
Its not as hard as you think. Besides, I have FULL statistic of the memory
usage of every object, visible.
But yes, errors can happen this way......too.
Alex McDonald
> På Sat, 21 Aug 2004 02:56:23 +0000 (UTC), skrev Alex McDonald
> <alex...@btopenworld.com>:
>
> >
> > "The Wannabee" <Faq@.@.@.@szmyggenpv.com> wrote in message
> > news:opsc18r7...@news.broadpark.no...
> >> På Fri, 20 Aug 2004 17:58:25 +0200, skrev The Wannabee
> >> <Faq@.@.@.@szmyggenpv.com>:
> >>
> >> > På 20 Aug 2004 06:45:03 -0700, skrev C <black...@asean-mail.com>:
> >>
> >> >
> >> > [TAeroPlane.Speed.x sizeof_TComposite3DObject
> >> > TAeroPlane.Speed.y TAeroPlane.Speed.x + SizeOf_Double
> >> > TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
> >> > TAeroPlane.Destination.x + TAeroPlane.Speed.z + SizeOf_Double
> >> > TAeroPlane.Destination.y TAeroPlane.Destination.x + SizeOf_Double
> >> > TAeroPlane.Destination.z TAeroPlane.Destination.y + SizeOf_Double
> >> >
> >
____________________________________________________________________________
> >> > SizeOf_TAeroPlane TAeroPlane.Speed.z + SizeOf_Double]
> >> >
> >> > This took, a little more time, maybe 10 seconds more, didnt measure.
> >>
> >> Woopps....
> >>
> >> > SizeOf_TAeroPlane TAeroPlane.Destination.z + SizeOf_Double]
> >>
> >> Nobody noticed. To sure of myself ?
> >
> > Good advert for not using this technique, I'd say. Structures should be
> > self-sizing.
>
> When I use this types, I verify them, while in this case, it was just a
> matter of typo, and not bothering to verify. And inside RosAsm where this
> struct would be imidiatly tested
How? Does it automatically verify what you intended?
> and used I never made such mistake yet,
> that I can recall. Once I messed up a couple of members, but because of
> the way my memorymanager works + RosAsm, the mistakes was detected easily.
> That day, I verified the full set of structures.
And shouldn't be needed in the first place; a structure would not let you
make this kind of mistake. You're using the word structure to mean something
quite different; the example is just a list of equates. It's not a
structure.
>
> The verification is very easy, the nextmember is offset by the previous
> member.
>
> TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
How long do these equates take to write, change & verify? This is not a
structure at all; it's a recipe for a disaster. I would not want to fly in
one of your planes.
>
> also, the "TAeroPlane.Speed.y + SizeOf_Double" alone,
> speak of the type of "TAeroPlane.Speed.y", and can be read :
>
> TAeroPlane.Speed.y is of type (size) double.
>
> Its not as hard as you think.
You're right; it's worse.
> Besides, I have FULL statistic of the memory
> usage of every object, visible.
>
> But yes, errors can happen this way......too.
>
First thing you've said that makes sense (and I also congratulate you on
spotting and posting on your error). But you could also have said some time
ago that RosAsm equates are not structures, and saved yourself a whole load
of dancing around on the head of a pin.
--
Regards
Alex McDonald
Ed Beroset
That's one major problem with this method. There are others. Consider
the effect of inserting an element. In this case, I've added room for a
three letter airport designator.
:
[TAeroPlane.Speed.x sizeof_TComposite3DObject
TAeroPlane.Speed.y TAeroPlane.Speed.x + SizeOf_Double
TAeroPlane.Speed.z TAeroPlane.Speed.y + SizeOf_Double
TAeroPlane.Destination.designator TAeroPlane.Speed.z + 3
TAeroPlane.Destination.x TAeroPlane.Speed.z + SizeOf_Double
TAeroPlane.Destination.y TAeroPlane.Destination.x + SizeOf_Double
TAeroPlane.Destination.z TAeroPlane.Destination.y + SizeOf_Double
...
This was done incorrectly, but the assembler will not issue even a peep
of complaint or warning. I'm sure that you find the problems, but why
can't the assembler? Better design would be to avoid this kind of
problem by creating a better structure declaration:
struct 3DCoord [
DOUBLE x
DOUBLE y
DOUBLE z
]
struct TAeroPlane [
3DCoord Speed
char[3] Designator
3DCoord Destination
]
It could be possible to approximate this with macros, which would be an
improvement, and is much more readable. Note too, that this is a
somewhat arbitrary syntax with no published rules, but I'll human
readers would have no trouble figuring out what it means, and there is
nothing so difficult that an assembler would not be able to parse it.
Also consider the simplicity with which the coordinates could all be
made to be some other type (e.g. FLOAT) and how that differs from trying
to accomplish the same thing with the other method.
Another problem with the RosAsm approach is that each element has no
type information associated with it. This has the practical effect
that the assembler can give little assistance in finding errors. For
instance:
TAeroPlane.Destination.designator = TAeroPlane.Destination.y
This isn't RosAsm syntax (I don't program for Windows and have no use
for RosAsm) but that doesn't really matter for this example. The point
is that because the assembler is not given any type information, there
would be no way *possible* to detect that we're trying to put a
four-byte quantity into a three-byte quantity (assuming that doubles are
4-bytes in RosAsm). This kind of problem is much more fundamental
because it can't realistically be added using macros.
Ed
The Wannabee
<ber...@mindspring.com>:
>
> Another problem with the RosAsm approach is that each element has no
> type information associated with it.
Please this is not "the RosAsm" approach, this is my approach to RosAsm.
You point about not having type info is incorrect.
SizeOf_TComposite3DObject says : it inherited from TComposite3DObject
+ its says something about the size of the inherited data.
similarly : SizeOf_Double is to also have type information. Its long for
Double. And it speaks the truth.
> This has the practical effect that the assembler can give little
> assistance in finding errors. For instance:
Oh you ment type info to the assembler..... Oki. Sofar that has not been
needed. I need only to make sure that I wrote it correctly. And test. In
real life, it works very well. As said before this but a blip on my
timetable.
> TAeroPlane.Destination.designator = TAeroPlane.Destination.y
>
> This isn't RosAsm syntax (I don't program for Windows and have no use
> for RosAsm) but that doesn't really matter for this example. The point
> is that because the assembler is not given any type information, there
> would be no way *possible* to detect that we're trying to put a
> four-byte quantity into a three-byte quantity (assuming that doubles are
> 4-bytes in RosAsm). This kind of problem is much more fundamental
> because it can't realistically be added using macros.
Well. Can we start to remember soon that this is an assembler forum ?
>
> Ed
Ed Beroset
> På Sat, 21 Aug 2004 13:47:14 GMT, skrev Ed Beroset
> <ber...@mindspring.com>:
>
>
>>
>> Another problem with the RosAsm approach is that each element has no
>> type information associated with it.
>
> Please this is not "the RosAsm" approach, this is my approach to RosAsm.
OK. We'll call it "the Wannabee approach," to have a handle for it.
> You point about not having type info is incorrect.
>
> SizeOf_TComposite3DObject says : it inherited from TComposite3DObject +
> its says something about the size of the inherited data.
Yes, this conveys information about type, but it's only conveyed to the
human, and not to the assembler. In other words, the machine would act
identically if you had called it FooBar58 unless your assembler treats a
symbol with the prefix "SizeOf_" as though it were an operator. That's
a possible approach, of course, but wouldn't be a very good design for
either the human or the computer.
> similarly : SizeOf_Double is to also have type information. Its long
> for Double. And it speaks the truth.
Perhaps it does, but it only speaks to the human, and not the assembler.
>> This has the practical effect that the assembler can give little
>> assistance in finding errors. For instance:
>
> Oh you ment type info to the assembler..... Oki. Sofar that has not been
> needed. I need only to make sure that I wrote it correctly.
Yes, that's exactly the point. *You* need to make sure you wrote it
correctly, because you don't get any help from the assembler. That's a
shame, because there are much less error-prone techniques available, and
better error checking tools available, both of which would give you more
time to work on turning concepts into code (which the machine cannot do
for you).
> In real life, it works very well.
While it may work well for you, it's always good to keep an open mind
about ways that might work even better. Some new ways work better, some
don't, but it's almost always useful to look.
>> TAeroPlane.Destination.designator = TAeroPlane.Destination.y
>>
>> This isn't RosAsm syntax (I don't program for Windows and have no use
>> for RosAsm) but that doesn't really matter for this example. The
>> point is that because the assembler is not given any type information,
>> there would be no way *possible* to detect that we're trying to put a
>> four-byte quantity into a three-byte quantity (assuming that doubles
>> are 4-bytes in RosAsm). This kind of problem is much more fundamental
>> because it can't realistically be added using macros.
>
> Well. Can we start to remember soon that this is an assembler forum ?
Assembly language programming doesn't mean that you have to use only
primitive tools. Smart assembly language programmers make the computer
work harder.
Ed
The Wannabee
<ber...@mindspring.com>:
> The Wannabee wrote:
> Assembly language programming doesn't mean that you have to use only
> primitive tools. Smart assembly language programmers make the computer
> work harder.
While my girlfriend allways find me to be a very primitive man, I have
found that I am still able to count, if I close my eyes and consentrate
real hard :-))))
Lets leave the subject. Your case is thin :
1) HLL structures are beautiful looking
2) They enable the compiler to count for you.
Ed Beroset
> På Sat, 21 Aug 2004 19:33:15 GMT, skrev Ed Beroset
> <ber...@mindspring.com>:
>
>> The Wannabee wrote:
>
>
>> Assembly language programming doesn't mean that you have to use only
>> primitive tools. Smart assembly language programmers make the
>> computer work harder.
>
>
> While my girlfriend allways find me to be a very primitive man, I have
> found that I am still able to count, if I close my eyes and consentrate
> real hard :-))))
Sure, and you could probably walk everywhere and knit your own socks
from wool from sheep that you've raised. I know some people who do just
that and they're quite happy without computers, too.
> Lets leave the subject. Your case is thin :
>
> 1) HLL structures are beautiful looking
> 2) They enable the compiler to count for you.
Actually the case for them is to work smarter and to create better
quality software. You don't seem much interested in either.
But that aside, I think your case is even thinner. Why NOT use real
structures? You've given no reasons at all.
Ed
The Wannabee
<ber...@mindspring.com>:
> But that aside, I think your case is even thinner. Why NOT use real
> structures? You've given no reasons at all.
I given plenty of reasons in various post.
1) The way I write them, they are just as capable. They help me structure
my data.
2) They help me write readable.
3) They are just as productive
4) They do not hide anything.
5) They are very easy to learn as they are just simple equates.
Betov
news:opsc38u5...@news.broadpark.no:
> På Sun, 22 Aug 2004 02:44:42 GMT, skrev Ed Beroset
> <ber...@mindspring.com>:
>
>> But that aside, I think your case is even thinner. Why NOT use real
>> structures? You've given no reasons at all.
>
> I given plenty of reasons in various post.
>
> 1) The way I write them, they are just as capable. They help me
> structure my data.
> 2) They help me write readable.
> 3) They are just as productive
> 4) They do not hide anything.
> 5) They are very easy to learn as they are just simple equates.
... and, if i may add:
* They are Assembly Compatible.
* They are compatible by RosAsm Right-Click feature.
* They are way easier to debug.
Betov.
< http://betov.free.fr/RosAsm.html >
PS. Ed, you are nothing but one of those old guys, used
to do the things the way you are used to do them, and who
has the most rigid difficulties to understand that a new
Tool might be _superior_ to to your old toys.
Now, when taking of "primitive tools", about RosAsm and my
refuse of implementing C-Like Structures, whereas you are
using utterly overpassed Assembly Compilers like MASM and
TASM, for your simple old fashion Demos, even without
considering the ethical side of the story, you are making
a fool of yourself, at your only expand.
Ed Beroset
> På Sun, 22 Aug 2004 02:44:42 GMT, skrev Ed Beroset
> <ber...@mindspring.com>:
>
>> But that aside, I think your case is even thinner. Why NOT use real
>> structures? You've given no reasons at all.
>
>
> I given plenty of reasons in various post.
Your reasons appear to be reasons that one would use structures. The
question was one would NOT.
> 1) The way I write them, they are just as capable. They help me
> structure my data.
That's what structures do. That's why they call them "structures."
> 2) They help me write readable.
That's what structures do, but better than your method, as I've shown.
> 3) They are just as productive
Doubtful, because your method is more error prone, as you've already
demonstrated.
> 4) They do not hide anything.
Actually, your method does hide things, namely, the actual data type,
while true structures do not.
> 5) They are very easy to learn as they are just simple equates.
Do you think you'd find a true structure hard to learn? I doubt that.
Since it's such an elementary part of programming, it's odd that any
programmer would decide not to use them. If you ever use a tool which
supports them well (NASM doesn't either, IMHO) you should try them out
to see how it works.
Ed
Ed Beroset
> The Wannabee <Faq@.@.@.@szmyggenpv.com> écrivait
> news:opsc38u5...@news.broadpark.no:
>
>
>>På Sun, 22 Aug 2004 02:44:42 GMT, skrev Ed Beroset
>><ber...@mindspring.com>:
>>
>>
>>>But that aside, I think your case is even thinner. Why NOT use real
>>>structures? You've given no reasons at all.
>>
>>I given plenty of reasons in various post.
>>
>>1) The way I write them, they are just as capable. They help me
>>structure my data.
>>2) They help me write readable.
>>3) They are just as productive
>>4) They do not hide anything.
>>5) They are very easy to learn as they are just simple equates.
>
> ... and, if i may add:
>
> * They are Assembly Compatible.
The phrase "assembly compatible" is without useful meaning, so this
doesn't add anything.
> * They are compatible by RosAsm Right-Click feature.
It would be a shame to be forced to avoid useful concepts in assembly
language programming solely due to limitations of the tool. The way I
tend to do things is to figure out what I want to do first, and THEN
pick the tool which best matches the job.
> * They are way easier to debug.
Since RosAsm doesn't support the alternative, how can you make this
determination? Can you describe the differences and say *why* they're
easier to debug?
> PS. Ed, you are nothing but one of those old guys, used
> to do the things the way you are used to do them, and who
> has the most rigid difficulties to understand that a new
> Tool might be _superior_ to to your old toys.
There are quite a number of things wrong with this single sentence.
1. Who I am has really nothing to do with structures, and whether or
not they're a better way to organize data in assembly language
programming. Let's debate the merits of the ideas, not the merits of
the participants.
2. Attempting to use equates to approximate structures is actually a
very old practice, common before more capable assemblers were available,
so rather than advancing a new technique, you're trying to move us
backwards by two or more decades. As an "old guy" I have first-hand
experience with both techniques, and it's how I know one is better.
3. If you have a case for *why* non-structures are superior to
structures, you should make the case using real examples, showing how it
would be done one way and then the other, noting the differences, and
explaining why one is better. That's what I've been doing.
> Now, when taking of "primitive tools", about RosAsm and my
> refuse of implementing C-Like Structures,
Actually, I don't use RosAsm, and don't really know much about it. My
mention of "primitive tools" was in reference to the method of
representing data structures using inadequate equate mechanisms. NASM
has the same problem.
> whereas you are
> using utterly overpassed Assembly Compilers like MASM and
> TASM, for your simple old fashion Demos,
Actually, I don't use either MASM or TASM very often these days. As for
the simple old-fashioned demos, you're absolutely right. Much of the
code on my web site is positively ancient. The most popular download
seems to be loader.asm, which was originally written in 1994. If you
look at that code (available at http://www.beroset.com ) you'll see that
it also happens to make extensive use of structures. Interestingly,
this is exactly the kind of code that is impossible to create in RosAsm
(since, as I understand it, RosAsm can't do 16-bit or non-Windows code),
so clearly there are still uses for and interest in other tools.
> even without
> considering the ethical side of the story, you are making
> a fool of yourself, at your only expand.
If there are ethical dimensions to this discussion then perhaps they
would include these. Here are the guidelines I try to apply:
1. intellectual honesty -- try to elicit all of the evidence both for
and against an idea rather than only presenting one side.
2. integrity -- tell the truth and be honorable in your dealings with
others.
3. respect for others -- try to write with respect for others; both
those involved in the conversation and those who might just be reading
either now or ten years from now in newsgroup archives.
As for making a fool of myself, I could do that much more easily by
attempting to write in French! Your English may not be perfect, but
it's a whole lot better than my French. I can reliably order wine, and
say please and thank you, but that's about my limit in that language.
Once I learn Russian a little better, I might try learning French next.
I find human languages as interesting as computer languages, but alas
there are too many of both for one person in one lifetime.
Ed
hutch--
struggling to emulate an assembler, particularly as its author will
not fix the hash table duplicates he has.
Sructures are part of current modern programming and this is why so
many languages have that form available, only kids toys or true back
end assemblers don't have structure support. Without the convenience
of predefined data structures a vast amount of Windows programming is
not properly accessible.
This is just another attempt by Betov to lead learners astray by
attaching like a parasite to the MASM user base to try and bleed off a
few people by bullsh*tting his way around things he cannot provide.
Structures, pointers, unions, records and the like are just part of
modern programming and without them the programmer has to do a lot
more work to end up with unreliable code that is very difficult to
modify, debug or understand.
MASM can use VC.
TASM can use Borland C/C++
GAS can use GCC
What happened to BetovReactRosSpazm ? It cannot even produce
assembler. Muhahahaha.
Betov
@newsread3.news.atl.earthlink.net:
> Betov wrote:
>> The Wannabee <Faq@.@.@.@szmyggenpv.com> écrivait
>> [...]
>>
>> ... and, if i may add:
>>
>> * They are Assembly Compatible.
>
> The phrase "assembly compatible" is without useful meaning, so this
> doesn't add anything.
Well, i have already expained this top-down, bottom-up
and diagonaly, Ed. How many times will have i to repeat,
again and again, the same evidences?
* Assembly, as opposed to HLLs, is a Language that _SHOWS_,
not a Language that _HIDES_. This means that anything used
in your Source _MUST_ be in Declared in your Source.
* Assembly is a Language with one-to-one correspondance
between the Source and Binary. This means that, for example,
you cannot have "Types", in Assembly Language because there
will never be any kind of "Type" in your Binary.
So, structures are incompatible with Assembly Language by
all sides:
* They are (most often) bound to "Types".
* They are hidden Equates.
The ony possible things in Assembly are the Sizes Markers,
and the Equates DECLARATIONS, if you want Equates, Data
DECLARATIONS, if you want Data and Stack DECLARATIONS, if
you want them on the Stack.
>> * They are compatible by RosAsm Right-Click feature.
>
> It would be a shame to be forced to avoid useful concepts in assembly
> language programming solely due to limitations of the tool. The way I
> tend to do things is to figure out what I want to do first, and THEN
> pick the tool which best matches the job.
I love this "due to limitations of the tool", from a
guy who says 20 lines downward: "I don't use RosAsm,
and don't really know much about it". Well... :)
Mind you, implementing a C-Like Structures parser, in
RosAsm would be one or two days of work, and anyway,
WAY LESS work than i ever spent at implementing the
evoluted Structures Management Tool we have in RosAsm.
You seem to not even understand that, when talking of
RosAsm "Right-Click", i am talking of the most important
feature, in the Source Editor, that enable the user with
instant Edition Jumps, to the Declaration of any Symbol,
and that, when doing so, i am also talking of the avaibility,
in your Source, of the Evocated Symbol Declaration.
>> * They are way easier to debug.
>
> Since RosAsm doesn't support the alternative, how can you make this
> determination? Can you describe the differences and say *why* they're
> easier to debug?
Very simple: The Sources Level Integrated Debugger
cannot show, to the user, at Run-Time, faultive
Statements that are NOT in his Source. As simple
as this.
RosAsm Debugger is really great (I am not the Author
of the Debugger, in case you would think that i am
contaminated by Randall Hyde mental desease...), but
not yet magical. :)
Also, once an error is pointed out, the real bug hunt
is made, at a significative percentage of... Declarations
hunts... You also, as a Programmer cannot point out
things that do not exist in your Source.
>> PS. Ed, you are nothing but one of those old guys, used
>> to do the things the way you are used to do them, and who
>> has the most rigid difficulties to understand that a new
>> Tool might be _superior_ to to your old toys.
>
> There are quite a number of things wrong with this single sentence.
>
> 1. Who I am has really nothing to do with structures, and whether or
> not they're a better way to organize data in assembly language
> programming. Let's debate the merits of the ideas, not the merits of
> the participants.
... With _Structures_ certainaly not. But with your
complete miss-understanding about why i will never
implement C-Like Structures in RosAsm, and why the
RosAsm Structures Management is far better, _yes_,
... it _has_ to do.
You are just defending the way YOU ARE USED TO. Nothing
else. And when facing way better, simpler, more secure,
more easy to debug,... and so on,... Method, you are
completely closed mind. This is it.
> 2. Attempting to use equates to approximate structures is actually a
> very old practice, common before more capable assemblers were available,
> so rather than advancing a new technique, you're trying to move us
> backwards by two or more decades. As an "old guy" I have first-hand
> experience with both techniques, and it's how I know one is better.
Partially true. At many points of views, my "innovations"
are nothing but "backward", considering the historical
evolution of the Programming Art. I have no problem with
this. I have always said that this evolution had gone the
wrong way, since the introduction of the Structured programming
Method, and that it is wishable to got _back_ and to think
of it all, again, and from scratch.
Now, if you are really convinced that this evolution was good,
and that going "back" is a stupid idea, this is your problem,
but, to me, going back and re-thinking of the various methods
_is_ a _new_ thing, and the way i implement them are, evidently
completely _new_. I am considering the things from an overall
point of view. For example, in matter of RosAsm Structures,
the IDE itself is part of my way of looking at the problem.
Discussing of RosAsm Structures implementation, without considering
their real usage, how, they are made available, how they are
customizable, and so on, does not make any sense:
RosAsm is not - as say a famous idiot - a language
Implementation, it is a Developement Environnement,
with full Integration of all Components.
> 3. If you have a case for *why* non-structures are superior to
> structures, you should make the case using real examples, showing how it
> would be done one way and then the other, noting the differences, and
> explaining why one is better. That's what I've been doing.
???!!!... Mind you, in all RosAsm sources, there are
Structures every here and there... So, i think it is
quite easy for anyone to take a look at the advantages,
in the context of reality.
>> Now, when taking of "primitive tools", about RosAsm and my
>> refuse of implementing C-Like Structures,
>
> Actually, I don't use RosAsm, and don't really know much about it. My
> mention of "primitive tools" was in reference to the method of
> representing data structures using inadequate equate mechanisms. NASM
> has the same problem.
This is not a problem, this is a _quality_. If NASM had
C-Like Structures implemented, it would not be an Assembler,
but an Assembly Compiler. By the way, C-Like Structures
_have_ been implemented, in NASM Sources, by Macros, and,
when i saw, at that time, the guy doing so, it had turn
me furious, and i had a hard exchange with him at NASM
Board.
>> whereas you are
>> using utterly overpassed Assembly Compilers like MASM and
>> TASM, for your simple old fashion Demos,
>
> Actually, I don't use either MASM or TASM very often these days. As for
> the simple old-fashioned demos, you're absolutely right. Much of the
> code on my web site is positively ancient. The most popular download
> seems to be loader.asm, which was originally written in 1994.
Yes. This is what i was suggesting. Not to insult you,
but it also means that you do no more write anything
significative in Assembly nowadays. I do not ask you
why, because i know the answer, and because this is
exactely the reason why i am trying to provide another
answer, and why i work full time since six years to
create a viable "Assembly Alternative".
> If you
> look at that code (available at http://www.beroset.com ) you'll see that
> it also happens to make extensive use of structures. Interestingly,
> this is exactly the kind of code that is impossible to create in RosAsm
> (since, as I understand it, RosAsm can't do 16-bit or non-Windows code),
> so clearly there are still uses for and interest in other tools.
No, this is not interresting, at all, at a RosAsm point
of view, as long as the defintion of RosAsm is to be a
"PE Producer". At this point of view, YES, _evidently_,
there are "still uses for and interest in other tools",
and there is no possible competition between RosAsm and
any "Multi-Purpose" Command-Line Assembler, as RosAsm
will never be on the start-line of the contest.
Not only there is no relationship between this remark and
C-Like Structures, but, RosAsm being a 'PE Producer", and
PEs having, so often times, to make use of Structures (way
more than most "16-bit or non-Windows code"), this could
even be a counter argument.
Betov.
Frank Kotler
...
> If you ever use a tool which
> supports them well (NASM doesn't either, IMHO)
Because of the lack of "typing", I presume(?). Anything else?
Best,
Frank
luvr
"Betov" <be...@free.fr> wrote in message
news:XnF954DBE3545...@212.27.42.72...
> * Assembly is a Language with one-to-one correspondance
> between the Source and Binary.
Pardon me for saying so, but that rules out macros, doesn't it? :o)
> You are just defending the way YOU ARE USED TO. Nothing
> else.
ROFL! Sounds like a perfect description of a certain Rene to me!
> And when facing way better, simpler, more secure,
> more easy to debug,... and so on,... Method, you are
> completely closed mind. This is it.
ROFL! Again!
> defintion of RosAsm is to be a
> "PE Producer".
Huh? I thought RosAsm was the only real ASSEMBLER?!?
So, HLA is not an assembler - it's a "high-level language pre-parser" (or
something of that style - forgive me if I don't get the terminology exactly
right). RosAsm is not an assembler - it's a "PE Producer"... ROFL!
--Luc.
Ed Beroset
> Ed Beroset <ber...@mindspring.com> écrivait news:GT1Wc.7744$2L3.6176
> @newsread3.news.atl.earthlink.net:
>
>
>>Betov wrote:
>>
>>>The Wannabee <Faq@.@.@.@szmyggenpv.com> écrivait
>>>[...]
>>>
>>>... and, if i may add:
>>>
>>>* They are Assembly Compatible.
>>
>>The phrase "assembly compatible" is without useful meaning, so this
>>doesn't add anything.
>
> Well, i have already expained this top-down, bottom-up
> and diagonaly, Ed. How many times will have i to repeat,
> again and again, the same evidences?
You only assert, you do not show evidence. That's the problem.
> * Assembly, as opposed to HLLs, is a Language that _SHOWS_,
> not a Language that _HIDES_. This means that anything used
> in your Source _MUST_ be in Declared in your Source.
If I declare a structure:
3DPoint [
DOUBLE x
DOUBLE y
DOUBLE z
]
nothing is hidden, so clearly this argument, as flawed as it is, doesn't
even apply.
> * Assembly is a Language with one-to-one correspondance
> between the Source and Binary. This means that, for example,
> you cannot have "Types", in Assembly Language because there
> will never be any kind of "Type" in your Binary.
There are also no variable names or procedure names in your binary, so
your argument would lead to the faulty conclusion that therefore one
should not use variable names or procedure names. Obviously, that's
false, and therefore this argument must also be discarded as absurd.
>>>* They are compatible by RosAsm Right-Click feature.
>>
>>It would be a shame to be forced to avoid useful concepts in assembly
>>language programming solely due to limitations of the tool. The way I
>>tend to do things is to figure out what I want to do first, and THEN
>>pick the tool which best matches the job.
>
> I love this "due to limitations of the tool", from a
> guy who says 20 lines downward: "I don't use RosAsm,
> and don't really know much about it". Well... :)
You seem to be inferring a contradiction where there is none. I don't
know much about RosAsm, but as the author, I would presume you do, and
you've stated that RosAsm doesn't support this kind of structure. So,
we appear to agree about the capabilities of RosAsm, but that's not
really related to the question. The question is why one would NOT use
structures in assembly language programming. "Because my assembler
doesn't support it" is a reason which is based on a limitation of the
tool -- it doesn't matter what tool that is.
> Mind you, implementing a C-Like Structures parser, in
> RosAsm would be one or two days of work, and anyway,
> WAY LESS work than i ever spent at implementing the
> evoluted Structures Management Tool we have in RosAsm.
I don't particularly care what you do with RosAsm. I don't use it.
>>>* They are way easier to debug.
>>
>>Since RosAsm doesn't support the alternative, how can you make this
>>determination? Can you describe the differences and say *why* they're
>>easier to debug?
>
> Very simple: The Sources Level Integrated Debugger
> cannot show, to the user, at Run-Time, faultive
> Statements that are NOT in his Source. As simple
> as this.
That's flawed logic. Here's an example of exactly how true structures
work in practice and how the type information helps programmers write
better quality software. The example is from the TASM version of
loader.asm which is available at http://www.beroset.com
You can read the whole thing from that source, but here's an extract to
show how it works. In that code, there is a structure declared which
contains the boot sector record. That part of the structure looks like
this:
BootSector STRUC
bsJump db 0EBh, (extra - bsJump), 090h
; E9 XX XX or EB xx 90
OemName db 8 dup (?) ; OEM name and version
; start of BIOS parameter block
BytesPerSec dw ? ; bytes per sector
SecPerClust db ? ; sectors per cluster
ResSectors dw ? ; number of reserved sectors
FATs db ? ; number of FATs
RootDirEnts dw ? ; number of root directory entries
; ... etc.
BootSector ENDS
Later on in the code, specifically on line 109, this statement appears:
mov ax,[Boot.RootDirEnts]
The statement is part of the routine to decode the FAT structure to get
the starting cluster on a floppy or hard disk. First, it's very clear
that nothing is hidden. Boot is the name for the location of the
structure and we're accessing the RootDirEnts entry from that, which is
declared as a dw (16-bit quantity). Let's say that I had made an error
and had tried this:
mov al,[Boot.RootDirEnts]
You can't put a 16-bit quantity into an 8-bit register. In this case,
the error is very quickly pointed out by the assembler. The output from
an ancient version of TASM (I don't happen to have MASM handy, but the
error message is similar):
Assembling file: loader.asm
**Error** loader.asm(109) Operand types do not match
However, if I really had wanted to load just the low half of that data
into AL, I can do that, too:
mov al,byte ptr [Boot.RootDirEnts]
This tells the assembler that you know that it's not a byte-sized data
item, but that you only want one byte. Consequently, it doesn't prevent
you from doing whatever you want to do, but it assists a programmer in
finding errors very quickly.
Now why don't you SHOW (not just assert) how the method in RosAsm is
superior.
>>1. Who I am has really nothing to do with structures, and whether or
>>not they're a better way to organize data in assembly language
>>programming. Let's debate the merits of the ideas, not the merits of
>>the participants.
>
> ... With _Structures_ certainaly not. But with your
> complete miss-understanding about why i will never
> implement C-Like Structures in RosAsm, and why the
> RosAsm Structures Management is far better, _yes_,
> ... it _has_ to do.
No, it does not. Show the merits of your method and it doesn't matter
who I am or who you are.
> You are just defending the way YOU ARE USED TO. Nothing
> else.
Actually, I have used both methods (structures as equates and true
structures) so I am used to both. I advocate the use of true structures
because I have found them to be more useful. I explain why I think they
are useful and give examples showing how they are useful.
> And when facing way better, simpler, more secure,
> more easy to debug,... and so on,... Method, you are
> completely closed mind. This is it.
If you would show examples, and illustrate how the method you have is
better, I'd be very willing to read it. You say it's better -- prove it!
>>2. Attempting to use equates to approximate structures is actually a
>>very old practice, common before more capable assemblers were available,
>>so rather than advancing a new technique, you're trying to move us
>>backwards by two or more decades. As an "old guy" I have first-hand
>>experience with both techniques, and it's how I know one is better.
>
> Partially true. At many points of views, my "innovations"
> are nothing but "backward", considering the historical
> evolution of the Programming Art. I have no problem with
> this. I have always said that this evolution had gone the
> wrong way, since the introduction of the Structured programming
> Method, and that it is wishable to got _back_ and to think
> of it all, again, and from scratch.
Having lived through some part of that history, perhaps I have a more
acute notion as to *why* going backwards is a bad idea. I remember what
it was like to hand assemble programs on paper and then toggle them into
a front panel in octal. It was time-consuming, error-prone, boring
and unproductive. It's fine if you'd like to revisit those days for
reasons of nostalgia or historical interest, but don't imagine that what
you end up with is somehow "superior." The computer doesn't care if you
toggle it in via switches or download a binary from the internet -- it
is unimpressed by heroics, so the ulitmate question is this: what
methods produce better results?
>>3. If you have a case for *why* non-structures are superior to
>>structures, you should make the case using real examples, showing how it
>>would be done one way and then the other, noting the differences, and
>>explaining why one is better. That's what I've been doing.
>
> ???!!!... Mind you, in all RosAsm sources, there are
> Structures every here and there... So, i think it is
> quite easy for anyone to take a look at the advantages,
> in the context of reality.
Show me. I have downloaded RosAsm and have stripped out what appears to
be the source code from the executable, but why don't you show a
particular structure, with a particular example as to why it is better?
I see a lot of lines of code, but no advantage.
>>>Now, when taking of "primitive tools", about RosAsm and my
>>>refuse of implementing C-Like Structures,
>>
>>Actually, I don't use RosAsm, and don't really know much about it. My
>>mention of "primitive tools" was in reference to the method of
>>representing data structures using inadequate equate mechanisms. NASM
>>has the same problem.
>
> This is not a problem, this is a _quality_. If NASM had
> C-Like Structures implemented, it would not be an Assembler,
> but an Assembly Compiler.
I don't care if you call it "Fred." You seem to be overly concerned
about labelling and classifying the tool. For me, a much more important
question is how well it works.
> By the way, C-Like Structures
> _have_ been implemented, in NASM Sources, by Macros,
There are some aspects of structure implementation that have been
implemented as macros in NASM, but they only give a partial benefit of
true structure support.
>>>whereas you are
>>>using utterly overpassed Assembly Compilers like MASM and
>>>TASM, for your simple old fashion Demos,
>>
>>Actually, I don't use either MASM or TASM very often these days. As for
>>the simple old-fashioned demos, you're absolutely right. Much of the
>>code on my web site is positively ancient. The most popular download
>>seems to be loader.asm, which was originally written in 1994.
>
> Yes. This is what i was suggesting. Not to insult you,
> but it also means that you do no more write anything
> significative in Assembly nowadays.
That's true. I find that there is less and less need for it.
> Not only there is no relationship between this remark and
> C-Like Structures, but, RosAsm being a 'PE Producer", and
> PEs having, so often times, to make use of Structures (way
> more than most "16-bit or non-Windows code"), this could
> even be a counter argument.
It would be nice if you would show me.
I predict, instead, that you'll continue to speak in the abstract and
without any code examples, using dismissive and irrelevant remarks about
me rather than actually addressing the question.
I'd like to be proved wrong about that!
Ed
Ed Beroset
Yes, that's the big omission. Various heroic contributors were able to
bend the macros farther than I would have expected to get simulated
support for structures, but it still isn't 100%.
I also seem to recall having some difficulty in doing something trying
to declare and then dereference structures in the stack frame. I'll
have to hunt around to find that thing again -- maybe you can figure it out.
Additionally, I personally find the macros to handle nested structures
and unions to be kind of ugly, but if you don't peek inside, I suppose
they're not a show-stopper.
Ed
Betov
news:wr5Wc.8119$2L3....@newsread3.news.atl.earthlink.net:
> Betov wrote:
>> Ed Beroset <ber...@mindspring.com> écrivait news:GT1Wc.7744$2L3.6176
>> @newsread3.news.atl.earthlink.net:
>>
>>
>>>Betov wrote:
>>>
>>>>The Wannabee <Faq@.@.@.@szmyggenpv.com> écrivait
>>>>[...]
>>>>
>>>>... and, if i may add:
>>>>
>>>>* They are Assembly Compatible.
>>>
>>>The phrase "assembly compatible" is without useful meaning, so this
>>>doesn't add anything.
>>
>> Well, i have already expained this top-down, bottom-up
>> and diagonaly, Ed. How many times will have i to repeat,
>> again and again, the same evidences?
>
> You only assert, you do not show evidence. That's the problem.
>
>> * Assembly, as opposed to HLLs, is a Language that _SHOWS_,
>> not a Language that _HIDES_. This means that anything used
>> in your Source _MUST_ be in Declared in your Source.
>
> If I declare a structure:
>
> 3DPoint [
> DOUBLE x
> DOUBLE y
> DOUBLE z
>]
>
> nothing is hidden, so clearly this argument, as flawed as it is,
> doesn't even apply.
:)) Nothing in the C-Like Struct Declaration, of course !!!
But what with (whatever particular syntax...)
3dPoint STRUCT
{ Double X
Double Y
Double Z
}
MyPoint1 3dPoint
...
MyPoint2 3dPoint
...
MyPoint3 3dPoint
...
... Where is MyPoint2.Z DECLARED???!!!...
Ghost Variables!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> * Assembly is a Language with one-to-one correspondance
>> between the Source and Binary. This means that, for example,
>> you cannot have "Types", in Assembly Language because there
>> will never be any kind of "Type" in your Binary.
>
> There are also no variable names or procedure names in your binary, so
> your argument would lead to the faulty conclusion that therefore one
> should not use variable names or procedure names. Obviously, that's
> false, and therefore this argument must also be discarded as absurd.
If you prefer jokes and stupidities than serious
discussion, this is OK to me... :))
>>>>* They are compatible by RosAsm Right-Click feature.
>>>
>>>It would be a shame to be forced to avoid useful concepts in assembly
>>>language programming solely due to limitations of the tool. The way
>>>I tend to do things is to figure out what I want to do first, and
>>>THEN pick the tool which best matches the job.
>>
>> I love this "due to limitations of the tool", from a
>> guy who says 20 lines downward: "I don't use RosAsm,
>> and don't really know much about it". Well... :)
>
> You seem to be inferring a contradiction where there is none. I don't
> know much about RosAsm, but as the author, I would presume you do, and
> you've stated that RosAsm doesn't support this kind of structure. So,
> we appear to agree about the capabilities of RosAsm, but that's not
> really related to the question. The question is why one would NOT use
> structures in assembly language programming. "Because my assembler
> doesn't support it" is a reason which is based on a limitation of the
> tool -- it doesn't matter what tool that is.
How many times do i have to answer to this question?
If you do not understand my previous answers, i fail
to imagine one another formulation... :(
>> Mind you, implementing a C-Like Structures parser, in
>> RosAsm would be one or two days of work, and anyway,
>> WAY LESS work than i ever spent at implementing the
>> evoluted Structures Management Tool we have in RosAsm.
>
> I don't particularly care what you do with RosAsm. I don't use it.
Too bad for you. :)
>>>>* They are way easier to debug.
>>>
>>>Since RosAsm doesn't support the alternative, how can you make this
>>>determination? Can you describe the differences and say *why*
>>>they're easier to debug?
>>
>> Very simple: The Sources Level Integrated Debugger
>> cannot show, to the user, at Run-Time, faultive
>> Statements that are NOT in his Source. As simple
>> as this.
>
> That's flawed logic.
???!!!... You seem to be an expert, as well... :))
> Here's an example of exactly how true structures
> work in practice and how the type information helps programmers write
> better quality software. The example is from the TASM version of
> loader.asm which is available at http://www.beroset.com
>
> You can read the whole thing from that source, but here's an extract
> to show how it works. In that code, there is a structure declared
> which contains the boot sector record. That part of the structure
> looks like this:
> BootSector STRUC
> bsJump db 0EBh, (extra - bsJump), 090h
> ; E9 XX XX or EB xx 90
> OemName db 8 dup (?) ; OEM name and version
> ; start of BIOS parameter block
> BytesPerSec dw ? ; bytes per sector
> SecPerClust db ? ; sectors per cluster
> ResSectors dw ? ; number of reserved sectors
> FATs db ? ; number of FATs
> RootDirEnts dw ? ; number of root directory entries
> ; ... etc.
> BootSector ENDS
>
> Later on in the code, specifically on line 109, this statement
> appears:
>
> mov ax,[Boot.RootDirEnts]
??!!!... And then ???!!!...
Here is _one_ possible RosAsm version:
[BootSector:
@bsJump: B$ 0EBh, (extra - bsJump), 090h
; E9 XX XX or EB xx 90
@OemName: B$ 0 #8 ; OEM name and version
; start of BIOS parameter block
@BytesPerSec: W$ 0 ; bytes per sector
@SecPerClust: B$ 0 ; sectors per cluster
@ResSectors: W$ 0 ; number of reserved sectors
@FATs: B$ 0 ; number of FATs
@RootDirEnts: W$ 0 ; number of root directory entries
...]
mov ax, W$Boot@RootDirEnts
> The statement is part of the routine to decode the FAT structure to
> get the starting cluster on a floppy or hard disk. First, it's very
> clear that nothing is hidden. Boot is the name for the location of
> the structure and we're accessing the RootDirEnts entry from that,
> which is declared as a dw (16-bit quantity). Let's say that I had
> made an error and had tried this:
>
> mov al,[Boot.RootDirEnts]
>
> You can't put a 16-bit quantity into an 8-bit register. In this case,
> the error is very quickly pointed out by the assembler. The output
> from
> an ancient version of TASM (I don't happen to have MASM handy, but
> the
> error message is similar):
>
> Assembling file: loader.asm
> **Error** loader.asm(109) Operand types do not match
???!!!... And what would you RosAsm to do different???!!!...
> However, if I really had wanted to load just the low half of that data
> into AL, I can do that, too:
>
> mov al,byte ptr [Boot.RootDirEnts]
RosAsm:
mov al, B$Boot@RootDirEnts
> This tells the assembler that you know that it's not a byte-sized data
> item, but that you only want one byte. Consequently, it doesn't
> prevent you from doing whatever you want to do, but it assists a
> programmer in finding errors very quickly.
>
> Now why don't you SHOW (not just assert) how the method in RosAsm is
> superior.
???!!!... You have, in no way given an example of a real
usage of a C-Like Structure in Assembly.
On my side, i have nothing to "show". People who want
to "see" have it quite easier, you know, RosAsm is free,
and i have nothing to sell. The time i spend i answering
to you is time that i do not spend at developing RosAsm
(hopefully i only come and play when tired of programming.
:)) :)) :))
>>>1. Who I am has really nothing to do with structures, and whether or
>>>not they're a better way to organize data in assembly language
>>>programming. Let's debate the merits of the ideas, not the merits of
>>>the participants.
>>
>> ... With _Structures_ certainaly not. But with your
>> complete miss-understanding about why i will never
>> implement C-Like Structures in RosAsm, and why the
>> RosAsm Structures Management is far better, _yes_,
>> ... it _has_ to do.
>
> No, it does not. Show the merits of your method and it doesn't matter
> who I am or who you are.
The "merits of my methods" are shown loud and clear by
the number of Applications and Demos written by the tiny
couple of RosAsm users, and by the significative size of
the working Code i have written.
>> You are just defending the way YOU ARE USED TO. Nothing
>> else.
>
> Actually, I have used both methods (structures as equates and true
> structures) so I am used to both. I advocate the use of true
> structures because I have found them to be more useful. I explain why
> I think they are useful and give examples showing how they are useful.
I have no idea of what you mean with "usefull".
I am saying that C-Like Structures are:
1) Incompatible with Assembly (reasons given previously).
2) More difficult to read.
3) More difficult to debug.
.. So, what have i to add about why RosAsm usage of Structures
if _better... Well:
1) Compatible with Assembly.
2) Easier to read.
3) Easier to debug.
... What could i say else???...
>> And when facing way better, simpler, more secure,
>> more easy to debug,... and so on,... Method, you are
>> completely closed mind. This is it.
>
> If you would show examples, and illustrate how the method you have is
> better, I'd be very willing to read it. You say it's better -- prove
> it!
You really think that i have nothing else to do than
to give private programming courses on a News Group?
B_U_Asm is there for this. 1.5 Mega, of organized
Doc representing close to 600 rtf Files (!!!...).
>>>2. Attempting to use equates to approximate structures is actually a
>>>very old practice, common before more capable assemblers were
>>>available, so rather than advancing a new technique, you're trying to
>>>move us backwards by two or more decades. As an "old guy" I have
>>>first-hand experience with both techniques, and it's how I know one
>>>is better.
>>
>> Partially true. At many points of views, my "innovations"
>> are nothing but "backward", considering the historical
>> evolution of the Programming Art. I have no problem with
>> this. I have always said that this evolution had gone the
>> wrong way, since the introduction of the Structured programming
>> Method, and that it is wishable to got _back_ and to think
>> of it all, again, and from scratch.
>
> Having lived through some part of that history, perhaps I have a more
> acute notion as to *why* going backwards is a bad idea. I remember
> what it was like to hand assemble programs on paper and then toggle
> them into
> a front panel in octal. It was time-consuming, error-prone, boring
> and unproductive. It's fine if you'd like to revisit those days for
> reasons of nostalgia or historical interest, but don't imagine that
> what you end up with is somehow "superior." The computer doesn't care
> if you toggle it in via switches or download a binary from the
> internet -- it is unimpressed by heroics, so the ulitmate question is
> this: what methods produce better results?
Well, 1) I am not going backward to IBM MainFrame Cobol
paper sheets times (yes, i have done this also...)
2) The final results of a method are revealed by the
Applications written by the users of a Programming Tool.
For example, even though RosAsm has close to "zero" users,
there are several RosAsm written Applications around and
over 0.5 Mega. When i say that RosAsm is the fastest of
the actual Assembler, and that Master Pdf wants to prove
the reverse, he simply has NOTHING to compare with, even
though, MASM Board may have 40 times more registred users
than RosAsm Board, and even though MASM existed _years_
before RosAsm. Facts.
RosAsm is the only existing Assembly alternative to HLL,
and the only demonstration of this is not (and will not be)
given by me, but by what RosAsm users do and will do with
the Tool, and by comparing with what shits-users do and
will do.
>>>3. If you have a case for *why* non-structures are superior to
>>>structures, you should make the case using real examples, showing how
>>>it would be done one way and then the other, noting the differences,
>>>and explaining why one is better. That's what I've been doing.
>>
>> ???!!!... Mind you, in all RosAsm sources, there are
>> Structures every here and there... So, i think it is
>> quite easy for anyone to take a look at the advantages,
>> in the context of reality.
>
> Show me. I have downloaded RosAsm and have stripped out what appears
> to be the source code from the executable, but why don't you show a
> particular structure, with a particular example as to why it is
> better?
> I see a lot of lines of code, but no advantage.
If you do not understand a thing, this is not my fault.
"You have stripped out out what appears to be the source code
from the executable"
???!!! Oh my goat!!!... You just had to run RosAsm and
to load RosAsm!!!... :(
Then to find out any Structure, you just have to Right-Click
on some Api Parameter, that you know to be a Structure...
>>>>Now, when taking of "primitive tools", about RosAsm and my
>>>>refuse of implementing C-Like Structures,
>>>
>>>Actually, I don't use RosAsm, and don't really know much about it.
>>>My mention of "primitive tools" was in reference to the method of
>>>representing data structures using inadequate equate mechanisms.
>>>NASM has the same problem.
>>
>> This is not a problem, this is a _quality_. If NASM had
>> C-Like Structures implemented, it would not be an Assembler,
>> but an Assembly Compiler.
>
> I don't care if you call it "Fred." You seem to be overly concerned
> about labelling and classifying the tool.
These days, when a famous swindler is trying to destroy
assembly, by selling a Pre-Parser under the name of
Assembler... _YES_ i am "overly concerned". :)
> For me, a much more
> important question is how well it works.
??? How well do C-Side Tools, like MASM, work ???!!!...
Where are the real life Applications written with MASM?
Where the significative Applications written with HLA?
>> By the way, C-Like Structures
>> _have_ been implemented, in NASM Sources, by Macros,
>
> There are some aspects of structure implementation that have been
> implemented as macros in NASM, but they only give a partial benefit of
> true structure support.
I see very well the disadvantages of C-Like Structures,
but i fail to imagine any possible "benefit".
>>>>whereas you are
>>>>using utterly overpassed Assembly Compilers like MASM and
>>>>TASM, for your simple old fashion Demos,
>>>
>>>Actually, I don't use either MASM or TASM very often these days. As
>>>for the simple old-fashioned demos, you're absolutely right. Much of
>>>the code on my web site is positively ancient. The most popular
>>>download seems to be loader.asm, which was originally written in
>>>1994.
>>
>> Yes. This is what i was suggesting. Not to insult you,
>> but it also means that you do no more write anything
>> significative in Assembly nowadays.
>
> That's true. I find that there is less and less need for it.
Sure. There is lesser and lesser need for the conception
you have of Assembly. I perfectely know this, and we agrea
100% on that point: What you are defending is DEAD. What
i am defending is a viable Rebirth, and i don't care, at
all, if this makes laugh everybody. The serious work is
going on...
>> Not only there is no relationship between this remark and
>> C-Like Structures, but, RosAsm being a 'PE Producer", and
>> PEs having, so often times, to make use of Structures (way
>> more than most "16-bit or non-Windows code"), this could
>> even be a counter argument.
>
> It would be nice if you would show me.
There are many in RosAsm source.
> I predict, instead, that you'll continue to speak in the abstract and
> without any code examples, using dismissive and irrelevant remarks
> about me rather than actually addressing the question.
This is a bit of an extreme remark, when addressing _me_,
one of the very few, here, who regulary rejects abstractions,
pretty theories, and theoricians pedantic ass-holes, and
whereas i continously point to FACTS against "well known
theories", lies, swindlings and propaganda...
You have 2.5 Megas of example Code in RosAsm Source, plus
several Megas, in users Demos, as something concrete.
> I'd like to be proved wrong about that!
Just open your eyes, and see. :))
Betov.
Ed Beroset
> Ed Beroset <ber...@mindspring.com> écrivait
> news:wr5Wc.8119$2L3....@newsread3.news.atl.earthlink.net:
>
>
>>Betov wrote:
>>
>>>Ed Beroset <ber...@mindspring.com> écrivait news:GT1Wc.7744$2L3.6176
>>>@newsread3.news.atl.earthlink.net:
>>>
>>>
>>>
>>>>Betov wrote:
>>>>
>>You seem to be inferring a contradiction where there is none. I don't
>>know much about RosAsm, but as the author, I would presume you do, and
>>you've stated that RosAsm doesn't support this kind of structure. So,
>>we appear to agree about the capabilities of RosAsm, but that's not
>>really related to the question. The question is why one would NOT use
>>structures in assembly language programming. "Because my assembler
>>doesn't support it" is a reason which is based on a limitation of the
>>tool -- it doesn't matter what tool that is.
>
>
> How many times do i have to answer to this question?
Just once would be sufficient. I'm still waiting for it.
>>Here's an example of exactly how true structures
>>work in practice and how the type information helps programmers write
>>better quality software. The example is from the TASM version of
>>loader.asm which is available at http://www.beroset.com
>>
>>You can read the whole thing from that source, but here's an extract
>>to show how it works. In that code, there is a structure declared
>>which contains the boot sector record. That part of the structure
>>looks like this:
>>BootSector STRUC
>> bsJump db 0EBh, (extra - bsJump), 090h
>> ; E9 XX XX or EB xx 90
>> OemName db 8 dup (?) ; OEM name and version
>> ; start of BIOS parameter block
>> BytesPerSec dw ? ; bytes per sector
>> SecPerClust db ? ; sectors per cluster
>> ResSectors dw ? ; number of reserved sectors
>> FATs db ? ; number of FATs
>> RootDirEnts dw ? ; number of root directory entries
>>; ... etc.
>>BootSector ENDS
>>
>>Later on in the code, specifically on line 109, this statement
>>appears:
>>
>> mov ax,[Boot.RootDirEnts]
>
>
> ??!!!... And then ???!!!...
I don't understand your comment. Are you unclear about what this
statement does?
> Here is _one_ possible RosAsm version:
>
> [BootSector:
> @bsJump: B$ 0EBh, (extra - bsJump), 090h
> ; E9 XX XX or EB xx 90
> @OemName: B$ 0 #8 ; OEM name and version
> ; start of BIOS parameter block
> @BytesPerSec: W$ 0 ; bytes per sector
> @SecPerClust: B$ 0 ; sectors per cluster
> @ResSectors: W$ 0 ; number of reserved sectors
> @FATs: B$ 0 ; number of FATs
> @RootDirEnts: W$ 0 ; number of root directory entries
> ...]
>
> mov ax, W$Boot@RootDirEnts
OK, so are you claiming that this is superior to other method?
>>which is declared as a dw (16-bit quantity). Let's say that I had
>>made an error and had tried this:
>>
>> mov al,[Boot.RootDirEnts]
>>
>>You can't put a 16-bit quantity into an 8-bit register. In this case,
>>the error is very quickly pointed out by the assembler. The output
>>from
>> an ancient version of TASM (I don't happen to have MASM handy, but
>> the
>>error message is similar):
>>
>>Assembling file: loader.asm
>>**Error** loader.asm(109) Operand types do not match
>
>
> ???!!!... And what would you RosAsm to do different???!!!...
>
>
>
>>However, if I really had wanted to load just the low half of that data
>>into AL, I can do that, too:
>>
>> mov al,byte ptr [Boot.RootDirEnts]
>
>
> RosAsm:
>
> mov al, B$Boot@RootDirEnts
OK, now we're finally actually looking at code, so perhaps you can
explain this a bit. How does this work? What would RosAsm do if you
used this statement with the structure above? Would it give an error or
assemble code? Is the B$ part strictly a size indicator or is it a
part of the variable name? Other than size, is any other type
information carried? If so, what does the assembler do with it?
>>This tells the assembler that you know that it's not a byte-sized data
>>item, but that you only want one byte. Consequently, it doesn't
>>prevent you from doing whatever you want to do, but it assists a
>>programmer in finding errors very quickly.
>>
>>Now why don't you SHOW (not just assert) how the method in RosAsm is
>>superior.
>
> ???!!!... You have, in no way given an example of a real
> usage of a C-Like Structure in Assembly.
I am not talking about C-like structures and never have been. I'm
talking about assembly language structures. If you don't like my
example, please show one of your own.
> On my side, i have nothing to "show".
This newsgroup is about the exchange of ideas regarding assembly
language programming. If you don't have any, or can't/won't articulate
what they are, then you truly don't have any reason to participate here.
However, as the author of a reasonably capable assembler written in
assembly language, I would expect that you would have something to
contribute if you'd attempt it.
>>>>1. Who I am has really nothing to do with structures, and whether or
>>>>not they're a better way to organize data in assembly language
>>>>programming. Let's debate the merits of the ideas, not the merits of
>>>>the participants.
>>>
>>>... With _Structures_ certainaly not. But with your
>>>complete miss-understanding about why i will never
>>>implement C-Like Structures in RosAsm, and why the
>>>RosAsm Structures Management is far better, _yes_,
>>>... it _has_ to do.
>>
>>No, it does not. Show the merits of your method and it doesn't matter
>>who I am or who you are.
>
> The "merits of my methods" are shown loud and clear by
> the number of Applications and Demos written by the tiny
> couple of RosAsm users, and by the significative size of
> the working Code i have written.
No, it's not loud and clear, and the number of applications and demos
aren't really relevant. There are more applications written in C# than
will probably ever be written using RosAsm? Surely you would reject the
argument that this proves that C# is a better language! I know I would,
because it's a fallacious argument.
>>>You are just defending the way YOU ARE USED TO. Nothing
>>>else.
>>
>>Actually, I have used both methods (structures as equates and true
>>structures) so I am used to both. I advocate the use of true
>>structures because I have found them to be more useful. I explain why
>>I think they are useful and give examples showing how they are useful.
>
> I have no idea of what you mean with "usefull".
Then perhaps this conversation is just as pointless as I suspected it
might be.
> .. So, what have i to add about why RosAsm usage of Structures
> if _better... Well:
>
> 1) Compatible with Assembly.
> 2) Easier to read.
> 3) Easier to debug.
>
> ... What could i say else???...
You could demonstrate it. I could assert that "all rocks float" and say
it over and over and over and over. Does that make it true? No. Does
that convince people? No. Does it help anyone else understand *why* I
might believe this? No. It does nothing to advance the argument until
I demonstrate in detail why I think this is so, and how I have come to
that conclusion. I still might be wrong, but without revealing any of
the logic behind the conclusion, there's no way for anyone else to tell
if there's an error in my thinking. Then again, perhaps that's the point?
>>If you would show examples, and illustrate how the method you have is
>>better, I'd be very willing to read it. You say it's better -- prove
>>it!
>
> You really think that i have nothing else to do than
> to give private programming courses on a News Group?
I'm pretty sure of it, actually, but that's beside the point. The point
is that if you have some evidence to back up what you say, you should
provide it. Otherwise people might conclude that you don't know what
you're talking about. I have already come to this conclusion.
> B_U_Asm is there for this. 1.5 Mega, of organized
> Doc representing close to 600 rtf Files (!!!...).
Lovely. Since they're so well organized and voluminous, then it
shouldn't have taken you any time at all to post a direct answer to the
question, right? However, you did not.
>> a front panel in octal. It was time-consuming, error-prone, boring
>>and unproductive. It's fine if you'd like to revisit those days for
>>reasons of nostalgia or historical interest, but don't imagine that
>>what you end up with is somehow "superior." The computer doesn't care
>>if you toggle it in via switches or download a binary from the
>>internet -- it is unimpressed by heroics, so the ulitmate question is
>>this: what methods produce better results?
>
> Well, 1) I am not going backward to IBM MainFrame Cobol
> paper sheets times (yes, i have done this also...)
>
> 2) The final results of a method are revealed by the
> Applications written by the users of a Programming Tool.
>
> For example, even though RosAsm has close to "zero" users,
> there are several RosAsm written Applications around and
> over 0.5 Mega. When i say that RosAsm is the fastest of
> the actual Assembler, and that Master Pdf wants to prove
> the reverse, he simply has NOTHING to compare with, even
> though, MASM Board may have 40 times more registred users
> than RosAsm Board, and even though MASM existed _years_
> before RosAsm. Facts.
I don't give a fig about any of that. The question is only about
structures, but you continue to avoid addressing the issue. Unlike
some, I'm not easily distracted by straw men.
>>>>3. If you have a case for *why* non-structures are superior to
>>>>structures, you should make the case using real examples, showing how
>>>>it would be done one way and then the other, noting the differences,
>>>>and explaining why one is better. That's what I've been doing.
>>>
>>>???!!!... Mind you, in all RosAsm sources, there are
>>>Structures every here and there... So, i think it is
>>>quite easy for anyone to take a look at the advantages,
>>>in the context of reality.
>>
>>Show me. I have downloaded RosAsm and have stripped out what appears
>>to be the source code from the executable, but why don't you show a
>>particular structure, with a particular example as to why it is
>>better?
>> I see a lot of lines of code, but no advantage.
>
> If you do not understand a thing, this is not my fault.
It is if you wish to communicate. It's increasingly clear that you
prefer monologue.
> "You have stripped out out what appears to be the source code
> from the executable"
>
> ???!!! Oh my goat!!!... You just had to run RosAsm and
> to load RosAsm!!!... :(
When you make it run under Linux, perhaps. Until then, it's just a big
useless binary taking up space on my hard drive. In order to *try* to
see what you're talking about, I've downloaded it and attempted to find
any use of structures within the code. I don't see them, but perhaps
I'm not looking in the right place. Because you don't seem to want to
actually give any useful answer, I think I'll just delete it instead of
wasting any more time on it.
>>>Not only there is no relationship between this remark and
>>>C-Like Structures, but, RosAsm being a 'PE Producer", and
>>>PEs having, so often times, to make use of Structures (way
>>>more than most "16-bit or non-Windows code"), this could
>>>even be a counter argument.
>>
>>It would be nice if you would show me.
>
>
> There are many in RosAsm source.
But you either can't or won't post even a pointer to a single one? I
have the source right here.
>>I predict, instead, that you'll continue to speak in the abstract and
>>without any code examples, using dismissive and irrelevant remarks
>>about me rather than actually addressing the question.
>
> This is a bit of an extreme remark, when addressing _me_,
> one of the very few, here, who regulary rejects abstractions,
> pretty theories, and theoricians pedantic ass-holes, and
> whereas i continously point to FACTS against "well known
> theories", lies, swindlings and propaganda...
Alas, you have proved me right. <sigh>
Ed
Dunny
Betov <be...@free.fr> typed:
> * Assembly, as opposed to HLLs, is a Language that _SHOWS_,
> not a Language that _HIDES_. This means that anything used
> in your Source _MUST_ be in Declared in your Source.
Actually, if I might stick my oar in these muddy waters and wave it about a bit,
I agree with that sentiment.
If I'm coding in Delphi, I really couldn't care less how optimal the code is -
so long as it's not unreasonably slow and does what I intended it to do.
However, if I then go off and declare an ASM ... END; block, I am very concerned
that what I type is assembled exactly as I typed it. I don't use an asm block
unless I want absolute control, and I'd not appreciate an assembler that did
things behind my back. Granted, Delphi will modify addressing if I'm using
variables declared elsewhere but that's not an issue, as I know what to expect
in those instances.
And I can always halt execution and open delphi's internal disassembler to ake
absolutely certain that's what's going on.
D.
Alex McDonald
===snipped
>
> :)) Nothing in the C-Like Struct Declaration, of course !!!
>
> But what with (whatever particular syntax...)
>
> 3dPoint STRUCT
> { Double X
> Double Y
> Double Z
> }
>
> MyPoint1 3dPoint
> ...
> MyPoint2 3dPoint
> ...
> MyPoint3 3dPoint
> ...
>
> ... Where is MyPoint2.Z DECLARED???!!!...
>
> Ghost Variables!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
===snipped
> >> Partially true. At many points of views, my "innovations"
> >> are nothing but "backward", considering the historical
> >> evolution of the Programming Art. I have no problem with
> >> this. I have always said that this evolution had gone the
> >> wrong way, since the introduction of the Structured programming
> >> Method, and that it is wishable to got _back_ and to think
> >> of it all, again, and from scratch.
> >
> > Having lived through some part of that history, perhaps I have a more
> > acute notion as to *why* going backwards is a bad idea. I remember
> > what it was like to hand assemble programs on paper and then toggle
> > them into
> > a front panel in octal. It was time-consuming, error-prone, boring
> > and unproductive. It's fine if you'd like to revisit those days for
> > reasons of nostalgia or historical interest, but don't imagine that
> > what you end up with is somehow "superior." The computer doesn't care
> > if you toggle it in via switches or download a binary from the
> > internet -- it is unimpressed by heroics, so the ulitmate question is
> > this: what methods produce better results?
>
> Well, 1) I am not going backward to IBM MainFrame Cobol
> paper sheets times (yes, i have done this also...)
>
At last, I now see where you get so much of your outdated thinking. If I'm
right, you programmed in IBM COBOL based on COBOL 61 standard (OS/VS COBOL?)
and possibly not even COBOL 68 -- IBM weren't terrific at supporting new
standards quickly. Probably batch programs only; I don't see you doing CICS
or IMS, too early for both.
Structured programming (Dijkstra, Jackson and others) has nothing to do with
structures. I now know you didn't practise structured programming. Given
that the first developments were academic in the late 60s, and had hit most
development shops around the mid 70s, that means your programming experience
is around a maximum of 10 years writing COBOL, if that. This is not a French
to English "language mistake" on your part; you would not have said
"structured programming method" if you knew what it meant, in either
language.
You then left the IT industry -- 1974 or therabouts -- still doing batch
COBOL. Definitely not 360 assembler; that was the domain of systems
programmers. Then, in the late 90's, you pick up with PCs and write an
assembler. Now, that's no mean achievement, but in the meanwhile you missed
a whole chunk of computing development.
. C and UNIX; given your loathing of C, UNIX is completely foreign to you,
and difficult for you to grasp. You have fallen into thinking that the only
programming model is the Windows "all in one" IDE.
. structures, macros, OOPS, functional languages, SQL databases, event
driven programming, parsing... all these you would have had to learn from
scratch, because they weren't really around in the 60s/early 70s or in the
domain of a COBOL programmer. You have not bothered with a number of them,
some because they aren't required in a simple IDE based assembler (such as
OOPS), and others you have either misinterpreted or been unable to implement
properly (macros, text based substitution, parsing), misunderstood
(hashing), can't grasp (structures) or won't tolerate (anything that really
uses macros, structures, collision based hashing and parsing properly).
>
> RosAsm is the only existing Assembly alternative to HLL,
> and the only demonstration of this is not (and will not be)
> given by me, but by what RosAsm users do and will do with
> the Tool, and by comparing with what shits-users do and
> will do.
>
>
No; it's author doesn't understand HLLs and a great deal more, so the
comparison is pointless. "Shits-users" require more than a worse-than-1960s
assembler dressed up in a clown suit, and a great deal more respect than
you're capable of.
--
Regards
Alex McDonald
Ed Beroset
> In news:XnF954DBE3545...@212.27.42.72,
> Betov <be...@free.fr> typed:
>
>
>>* Assembly, as opposed to HLLs, is a Language that _SHOWS_,
>>not a Language that _HIDES_. This means that anything used
>>in your Source _MUST_ be in Declared in your Source.
>
>
> Actually, if I might stick my oar in these muddy waters and wave it about a bit,
> I agree with that sentiment.
>
> If I'm coding in Delphi, I really couldn't care less how optimal the code is -
> so long as it's not unreasonably slow and does what I intended it to do.
> However, if I then go off and declare an ASM ... END; block, I am very concerned
> that what I type is assembled exactly as I typed it. I don't use an asm block
> unless I want absolute control, and I'd not appreciate an assembler that did
> things behind my back.
In assembly, if you were to declare a structure like this:
3DPoint struc
x dw ?
y dw ?
z dw ?
3DPoint ends
and then later had a statement that looked like this:
mov ax,[(3DPoint ptr bx).y] ; ax = y coordinate
what is it, exactly that is being done behind your back? It's all right
there -- you declare that there is a structure that has some logical
meaning, tell the assembler that bx points to one of those structures,
and then ask it to put the value of y from that structure into the ax
register. What is it that you fear is being hidden from you?
Ed
Percival
MyStructInRosAsm rb sizeof.Structre
OMFG!!! When was myPoint.z declared!!!
Ghost Variables!!!
Common, that was just about the worst argument you can put up.
>>>* Assembly is a Language with one-to-one correspondance
>>>between the Source and Binary. This means that, for example,
>>>you cannot have "Types", in Assembly Language because there
>>>will never be any kind of "Type" in your Binary.
>>
>>There are also no variable names or procedure names in your binary, so
>>your argument would lead to the faulty conclusion that therefore one
>>should not use variable names or procedure names. Obviously, that's
>>false, and therefore this argument must also be discarded as absurd.
>
>
> If you prefer jokes and stupidities than serious
> discussion, this is OK to me... :))
Can't refute the statement, so you go and try to refute the person who
said it. Right?
>>>>>* They are compatible by RosAsm Right-Click feature.
>>>>
>>>>It would be a shame to be forced to avoid useful concepts in assembly
>>>>language programming solely due to limitations of the tool. The way
>>>>I tend to do things is to figure out what I want to do first, and
>>>>THEN pick the tool which best matches the job.
>>>
>>>I love this "due to limitations of the tool", from a
>>>guy who says 20 lines downward: "I don't use RosAsm,
>>>and don't really know much about it". Well... :)
>>
>>You seem to be inferring a contradiction where there is none. I don't
>>know much about RosAsm, but as the author, I would presume you do, and
>>you've stated that RosAsm doesn't support this kind of structure. So,
>>we appear to agree about the capabilities of RosAsm, but that's not
>>really related to the question. The question is why one would NOT use
>>structures in assembly language programming. "Because my assembler
>>doesn't support it" is a reason which is based on a limitation of the
>>tool -- it doesn't matter what tool that is.
>
>
> How many times do i have to answer to this question?
> If you do not understand my previous answers, i fail
> to imagine one another formulation... :(
Personally i see no question. If you mean "RosAsm's limitations"
question thing, then well, it is true. The thing is limited in that way.
RosAsm cannot support C-like structures.
>>>>>* They are way easier to debug.
>>>>
>>>>Since RosAsm doesn't support the alternative, how can you make this
>>>>determination? Can you describe the differences and say *why*
>>>>they're easier to debug?
>>>
>>>Very simple: The Sources Level Integrated Debugger
>>>cannot show, to the user, at Run-Time, faultive
>>>Statements that are NOT in his Source. As simple
>>>as this.
>>
>>That's flawed logic.
>
>
> ???!!!... You seem to be an expert, as well... :))
Nice comeback. </sarcasm>
Now the reason it is flawed logic, Ed said it was easier to debug only
because your assembler doesn't support the other way. In another
assembler, it is much easier to debug C-like statements compared to
normal statements. And not to mention, there is nothing stopping me from
writting an IDe that supports debugging C like structures.
>>Here's an example of exactly how true structures
>>work in practice and how the type information helps programmers write
>>better quality software. The example is from the TASM version of
>>loader.asm which is available at http://www.beroset.com
>>
>>You can read the whole thing from that source, but here's an extract
>>to show how it works. In that code, there is a structure declared
>>which contains the boot sector record. That part of the structure
>>looks like this:
>>BootSector STRUC
>> bsJump db 0EBh, (extra - bsJump), 090h
>> ; E9 XX XX or EB xx 90
>> OemName db 8 dup (?) ; OEM name and version
>> ; start of BIOS parameter block
>> BytesPerSec dw ? ; bytes per sector
>> SecPerClust db ? ; sectors per cluster
>> ResSectors dw ? ; number of reserved sectors
>> FATs db ? ; number of FATs
>> RootDirEnts dw ? ; number of root directory entries
>>; ... etc.
>>BootSector ENDS
>>
>>Later on in the code, specifically on line 109, this statement
>>appears:
>>
>> mov ax,[Boot.RootDirEnts]
>
>
> ??!!!... And then ???!!!...
[snip]
You cut his statement short. You didn't let him finish. No wonder you
didn't understand :)
>>This tells the assembler that you know that it's not a byte-sized data
>>item, but that you only want one byte. Consequently, it doesn't
>>prevent you from doing whatever you want to do, but it assists a
>>programmer in finding errors very quickly.
>>
>>Now why don't you SHOW (not just assert) how the method in RosAsm is
>>superior.
>
>
> ???!!!... You have, in no way given an example of a real
> usage of a C-Like Structure in Assembly.
>
> On my side, i have nothing to "show". People who want
> to "see" have it quite easier, you know, RosAsm is free,
> and i have nothing to sell. The time i spend i answering
> to you is time that i do not spend at developing RosAsm
> (hopefully i only come and play when tired of programming.
> :)) :)) :))
So you cannot prove your statements, as you have nothing to show. You
don't understand, people need to see precisly your point. We are giving
you precisly our point on this issue, why don't you be more specific?
>>>>1. Who I am has really nothing to do with structures, and whether or
>>>>not they're a better way to organize data in assembly language
>>>>programming. Let's debate the merits of the ideas, not the merits of
>>>>the participants.
>>>
>>>... With _Structures_ certainaly not. But with your
>>>complete miss-understanding about why i will never
>>>implement C-Like Structures in RosAsm, and why the
>>>RosAsm Structures Management is far better, _yes_,
>>>... it _has_ to do.
>>
>>No, it does not. Show the merits of your method and it doesn't matter
>>who I am or who you are.
>
>
> The "merits of my methods" are shown loud and clear by
> the number of Applications and Demos written by the tiny
> couple of RosAsm users, and by the significative size of
> the working Code i have written.
No. Apps and Demos show how to use them. They are not specific to this
debate. Heck, i can say that The aps and demos of all the C programs
show why C-style is superiour to your method, but that doesn't prove
anything.
>>>You are just defending the way YOU ARE USED TO. Nothing
>>>else.
>>
>>Actually, I have used both methods (structures as equates and true
>>structures) so I am used to both. I advocate the use of true
>>structures because I have found them to be more useful. I explain why
>>I think they are useful and give examples showing how they are useful.
>
>
> I have no idea of what you mean with "usefull".
> I am saying that C-Like Structures are:
>
> 1) Incompatible with Assembly (reasons given previously).
> 2) More difficult to read.
> 3) More difficult to debug.
1 doesn't work. You give the previous reasons, but they have been refuted.
2. Please, tell me how:
struct mystruct{
int i;
int j;
};
is harder to read than the RosAsm version. You keep talking but never
support your arguments.
3. You haven't said WHY they are more difficult to debug yet.
>>>And when facing way better, simpler, more secure,
>>>more easy to debug,... and so on,... Method, you are
>>>completely closed mind. This is it.
>>
>>If you would show examples, and illustrate how the method you have is
>>better, I'd be very willing to read it. You say it's better -- prove
>>it!
>
>
> You really think that i have nothing else to do than
> to give private programming courses on a News Group?
>
> B_U_Asm is there for this. 1.5 Mega, of organized
> Doc representing close to 600 rtf Files (!!!...).
No, we expect you to support your statements.
Percival
T.M. Sommers
>
> If I declare a structure:
>
> 3DPoint [
> DOUBLE x
> DOUBLE y
> DOUBLE z
> ]
>
> nothing is hidden, so clearly this argument, as flawed as it is, doesn't
> even apply.
Is it typical for an assember that does structs to add padding to
get alignment correct, the way a C compiler will? I would hope
they would, but if they do, it would be something that is hidden.
--
Thomas M. Sommers -- t...@nj.net -- AB2SB
Randall Hyde
"T.M. Sommers" <t...@nj.net> wrote in message
news:ticWc.299$Pd2.1...@monger.newsread.com...
>
> Is it typical for an assember that does structs to add padding to
> get alignment correct, the way a C compiler will? I would hope
> they would, but if they do, it would be something that is hidden.
>
Some assemblers, that support structs/records, allow this.
For example, MASM allows you to specify the alignment for
each field in a structure. HLA goes even farther and allows you
to specify a minimum and a maximum alignment for fields, e.g.,
type
alignedRecord:
record[ 4, 2] //min align=2, max align=4
a:byte;
b:word;
c:byte;
d:dword;
endrecord;
Offsets-
a: 0
b: 2
c: 4
d: 8
A minimum alignment means that all objects are aligned on that
alignment, even if the particular object is smaller than the alignment
(e.g., bytes are aligned on word boundaries in the example above).
Max alignment means that this is the maximum alignment the record
will use, even if the object is larger than the alignment value. For objects
whose sizes are between the minimum and maximum, alignment takes
places on the "natural boundary" of the object's size.
The HLA scheme allows one to set up a scheme that will automatically
satisfy just about any ABI out there.
If automatic alignment isn't desirable, or you want to change the alignment
based on the particular field, you can always inject an "ALIGN" directive
into a record, e.g.,
type
anotherAlignedRecord:
record
a:byte;
align(2);
b:byte;
align(8);
d:dword;
endrecord;
Though MASM's facilities aren't quite as extensive as HLA's,
MASM does support some of these facilities.
Cheers,
Randy Hyde
Betov
news:oa9Wc.8338$2L3....@newsread3.news.atl.earthlink.net:
Ed, such a level of intellectual dishonnesty pushes you
into the group aside all the ass-holes around, Randall
and his trolls companie, Hutch, Dunny, Alex, and friends.
Discussion closed to me.
Betov.
< http://betov.free.fr/RosAsm.html >
f0dder
> This is exactely RosAsm definition: An Assembly
> Developement Environement for writing PEs. One
> can call this a "limitation" if he likes to make
> fun of it.
>
I do not intend to make fun of RosAsm - only point out
why it isn't "the tool for me". I work in multiple
languages (mostly C/C++ and Assembly), but even if I
went asm-only I would still need static library support.
> Too bad that you never wrote anything significative in
> Assembly, isn't it? You could have, for example, with
> a Tool like RosAsm, have declared your Structure through
> Macros Evocations... :)
>
I never wrote anything major fully in assembly, no...
There's no point, for me, in doing this. I'm not into
measuring penis size, either :-)
f0dder
> The Wannabee wrote:
>> I don know C, I ment C++, but this includes C, no ?
>
> C doesn't support OOP at all. Period.
>
Hm, I thought structs supported function members - but
appearantly only C++ allows that. Aww shucks :)
> Actually, if the compiler was any smart, it would just hold an
> indirect call to the correct function. What, 2-3 cycles more?
>
VC++ uses a "vtable" when dealing with virtual methods. However,
this is only used if the compiler cannot possibly know the object
type being dealt with at compile-time. If you instantiate a class
directly (ie, non-pointer) the vtable won't be used for calling.
See end of message for a couple examples.
> Heck, C++ by default inlines the code if you put it in the class
> definition, so then it is actually faster than ASM emulating it...
>
Compilers+linkers supporting "link-time code generation" (MS VC,
Intel ICC, ...?) can/should be able to even inline members that
aren't inlined in the header file.
Now, a little sample of VC++ code generation:
class myclass {
public:
virtual stuff(void);
virtual stuff2(void);
};
extern myclass ob1, *ob2;
int main(int argc, char *argv[])
{
myclass *ob3 = &ob1;
ob1.stuff2();
ob2->stuff2();
ob3->stuff2();
return 0;
}
; Normal function call without vtable access
; 12 : ob1.stuff2();
mov ecx, OFFSET FLAT:?ob1@@3Vmyclass@@A ; ob1
call ?stuff2@myclass@@UAEHXZ ; myclass::stuff2
; "We don't know what this is pointing to", so the vtable is fetched
; from the object (first dword = vtable address under VC++)
; 13 : ob2->stuff2();
mov ecx, DWORD PTR ?ob2@@3PAVmyclass@@A ; ob2
mov eax, DWORD PTR [ecx]
call DWORD PTR [eax+4]
; Here the compiler knows the type of the class, but still chooses
; to do a vtable call... wonder why?
; 14 : ob3->stuff2();
mov edx, DWORD PTR ?ob1@@3Vmyclass@@A ; ob1
mov ecx, OFFSET FLAT:?ob1@@3Vmyclass@@A ; ob1
call DWORD PTR [edx+4]
f0dder
> I just pasted in some _SMALL_ set of C structs form the library of
> Windows. The full set contains someting like 55000 equally insane
> identifyers structures.
>
Where is that from again? I searched both platformsdk and ntddk for
"aep_boot" and didn't find any hits. Are my psdk and ntddk too old?
Betov
$edfa...@dtext01.news.tele.dk:
> Betov wrote:
>
>> This is exactely RosAsm definition: An Assembly
>> Developement Environement for writing PEs. One
>> can call this a "limitation" if he likes to make
>> fun of it.
>>
> I do not intend to make fun of RosAsm - only point out
> why it isn't "the tool for me".
I never had any doubt on that point.
> I work in multiple
> languages (mostly C/C++ and Assembly), but even if I
> went asm-only I would still need static library support.
100% logical.
>> Too bad that you never wrote anything significative in
>> Assembly, isn't it? You could have, for example, with
>> a Tool like RosAsm, have declared your Structure through
>> Macros Evocations... :)
>>
> I never wrote anything major fully in assembly, no...
I would say "not even significative", and this is your
real problem. Your evident competency level in general
Programming and SoftWare, does not give you any advantage
for discussing with me about Assembly. You could as well
by a materia physician, this would not make it easy to
discuss with me about how to build a house, because i
_have_ create many houses in my life. Assembly is a
specialized area, that you will never understand before
having written something significative in Asm.
> There's no point, for me, in doing this.
I quite sure of this.
> I'm not into measuring penis size, either :-)
Too bad... :))
Betov.
Alex McDonald
> Ed Beroset <ber...@mindspring.com> écrivait
> news:oa9Wc.8338$2L3....@newsread3.news.atl.earthlink.net:
===snipped
> >
> > In assembly, if you were to declare a structure like this:
> >
> > 3DPoint struc
> > x dw ?
> > y dw ?
> > z dw ?
> > 3DPoint ends
> >
> > and then later had a statement that looked like this:
> >
> > mov ax,[(3DPoint ptr bx).y] ; ax = y coordinate
> >
> > what is it, exactly that is being done behind your back? It's all
> > right there -- you declare that there is a structure that has some
> > logical meaning, tell the assembler that bx points to one of those
> > structures, and then ask it to put the value of y from that structure
> > into the ax register. What is it that you fear is being hidden from
> > you?
>
>
> Ed, such a level of intellectual dishonnesty pushes you
> into the group aside all the ass-holes around, Randall
> and his trolls companie, Hutch, Dunny, Alex, and friends.
>
> Discussion closed to me.
Thanks for the insight Betov; you win with this most powerful of dialectic
techniques (it's called "pounding the table", yes?). It's a winner.
Honestly, what could I have been thinking? Structures are so intellectually
dishonest; equates hold the moral high ground! I now know, you see, from
your shining example, that when they start down the slippery slope of using
a structure, the next thing you know they're wanting a class! I'm joining
you for the next battleground; we, the equate proleteriate, shoulder to
shoulder, typeless, structureless, opening a new front in the war for
classless code everywhere.
Only one question that's got me stumped btw; do we approve of unions?
--
Regards
Alex McDonald
Betov
news:cgcg5s$g45$1...@sparta.btinternet.com:
No. What is dishonest is to provide the exact same
STRUCT ___ Declaration ___ example, whereas i have
answered to this, above, and explained _where_ the
Hidden thingies are coming into the game, just like
if i had answered nothing at all.
I well know that Ed is not completely stupid, and
that he _succeeds_ to read my "english". He prefectely
understood (i hope for him...) that i was talking of
the Members of the "instances" of the STRUCT, created
silently at the evocation of the STRUCT, for creating
a hidden bunch of Data.
> equates hold the moral high ground!
I fuck your irony.
There is no "moral" with Equates and Structures.
Equates are Assembly Compatible because, when
you say:
[ID_OK = 1]
that "ID_OK" has a one-to-one correspondance with
that "1", that you will find out, in your dead File,
with any Hexa Editor, for each Evocation of "ID_OK",
and because, when reading / debugging, if you try
to find out what "ID_OK" means, you will see in plain
Source that it is DECLARED as an Equivalence of "1".
Whereas, with C-Like Struct, the created Tables are
_ghost Variables_ that you will find nowhere in your
plain Source.
I have already demonstrated how to do this in an
Assembly Compatible way, with the appropriated Tool,
under the various required forms, that are _readable_
and easy to debug, because they _are_ in your plain
Source... And i will not repeat it XXXXX times, because
i am bored of discussing with guys who refuse to
understand anything.
> I now
> know, you see, from your shining example, that when they start down
> the slippery slope of using a structure, the next thing you know
> they're wanting a class! I'm joining you for the next battleground;
> we, the equate proleteriate, shoulder to shoulder, typeless,
> structureless, opening a new front in the war for classless code
> everywhere.
I still fuck you irony.
Mind you, the implementation of OOA Classes is _planed_
in RosAsm Developement. The required branching and TITLE
is ready since some times, and, if it is not yet written,
this is only because i have more important things to do,
particulary for the Disassembler. Also, as this is a task
that anybody else than me can do, i let it open for eventual
volunteer(s)...
Now, the day RosAsm will offer a "CLASS" Implementation,
this will _not_ be in the default configuration of the
Assembler, because it would no longuer be an Assembler,
but an HLL. This will be made available through an
expressed request of the Programmer, saying:
PREPARSE OOA
... And, after this statement, all the concerned Statements
will no more be Assembly, but HLL. This is exactely what is
actually done when the programmer uses the "Equal" pre-Parser,
and _this_ is "intellectual honesty".
> Only one question that's got me stumped btw; do we approve of unions?
Unions are Assembly Compatible. Unions are nothing but
declaring several labels for one single Memory Location,
and it is quite trivial to do this in Assembly.
Betov.
The Wannabee
<f0dder_s...@flork.dk>:
Its pasted from Gugas WinDoc project. Ask to be a volountar, and get you
own file :-))
--
LOL
f0dder
>>> I just pasted in some _SMALL_ set of C structs form the library of
>>> Windows. The full set contains someting like 55000 equally insane
>>> identifyers structures.
>>>
>> Where is that from again? I searched both platformsdk and ntddk for
>> "aep_boot" and didn't find any hits. Are my psdk and ntddk too old?
>
> Its pasted from Gugas WinDoc project. Ask to be a volountar, and get
> you own file :-))
>
Hm, so it's guga that came up with these structures and struct names
and not Microsoft?
Percival
Wow. Can't find anything wrong so you blame them of lying.
This is exactly what we mean as you don't support your statements. You
made a claim, that Clike structures hides away many things from you. We
are arguing that it doesn't, then you accuse us of lying.
Now anyway, we aren't "lying" persay, but we are just ignorant. Well,
thats how you should view people who don't agree with you. Ignorant,
because eventually, you may realize you yourself was wrong this whole time.
Percival
The Wannabee
f0dder
>>>>> I just pasted in some _SMALL_ set of C structs form the library of
>>>>> Windows. The full set contains someting like 55000 equally insane
>>>>> identifyers structures.
>>>>>
>>>> Where is that from again? I searched both platformsdk and ntddk for
>>>> "aep_boot" and didn't find any hits. Are my psdk and ntddk too old?
>>>
>>> Its pasted from Gugas WinDoc project. Ask to be a volountar, and get
>>> you own file :-))
>>>
>> Hm, so it's guga that came up with these structures and struct names
>> and not Microsoft?
>
> Nope.
>
Where are they from, then? Couldn't find them in PSDK or NTDDK. Perhaps
in the leaked NT4 or NT5 source code, or the IFS kit? Google didn't
report any hits either, which is unusual when googling for microsoft
related stuff :)
Percival
> No. What is dishonest is to provide the exact same
> STRUCT ___ Declaration ___ example, whereas i have
> answered to this, above, and explained _where_ the
> Hidden thingies are coming into the game, just like
> if i had answered nothing at all.
>
> I well know that Ed is not completely stupid, and
> that he _succeeds_ to read my "english". He prefectely
> understood (i hope for him...) that i was talking of
> the Members of the "instances" of the STRUCT, created
> silently at the evocation of the STRUCT, for creating
> a hidden bunch of Data.
For those who don't know what i am talking about, perhaps this may help:
Betov posted this on 8/22/04
>:)) Nothing in the C-Like Struct Declaration, of course !!!
>But what with (whatever particular syntax...)
>3dPoint STRUCT
>{ Double X
> Double Y
> Double Z
>}
>
>MyPoint1 3dPoint
>...
>MyPoint2 3dPoint
>...
>MyPoint3 3dPoint
>...
>
>... Where is MyPoint2.Z DECLARED???!!!...
>
>Ghost Variables!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Now to sum up what he says, C-style structures hide from you the
declaration of variables.
I simply have to say, ALL structures hide away the declaration of variables.
For example, in Fasm (using equates method)
struc point{
.x dd ?
.y dd ?
}
mypoint point
mov [mypoint.x], eax
Anyway, when did i declare mypoint.x? It is an implicit behavior,
required for structures.
Whenever you declare a structure, i seriously hope you don't have to
only use a constructor. Seriously, if the only way of making a structure
is by a constructor, then how do you put structs on the stack? How do
you put a structure in dynamic memory? From a malloc call? etc.
For example, lets say you want a pointer to a new Point. In Fasm, you
first have to figure out the length of the point, but there is a simple
workaround that i hope the author will work into his assembler soon.
anyway:
mov eax, sizeof.point * 5; allocate 5 points
push eax
call malloc
add esp, 4
mov ebx, eax
virtual at ebx
point1 point
point2 point
point3 point
point4 point
point5 point
end virtual
mov [point1.x], 30
...
push ebx
call free
add esp, 4
Surely!! There are "Ghost variables" at work here!!! The initilization
of point.x was never declared!! However, i'd like to see you try to make
this work without "Ghost Variables"
Or by not making these "ghost variables" as betov calls them, you
actually limit yourself from putting a struct on the stack, from dynamic
memory and other stuff. I don't know how you can compile code that has a
constructor into a stack, without hiding the details.
Anyway, i don't use RosAsm much, but i hope it includes these Ghost
variables, simply so that i can have dynamic memory.
Flame away.
Percival
The Wannabee
<f0dder_s...@flork.dk>:
AVIFILEINFO...you never saw this in windows ???
Theese structures are part of the full windows SDK. I cant tell you where
exactly, the one most cryptic looking comes from because I dont know, but
the AVIFILEINFO, is from the AVIFILE.dll.
If important, you should ask Guga. He is the head of the project. I am
just trying to help him translate those window structs to RosAsm structs
for inclusion into RosAsm.
You should be aware that many of the API docs that comes along with many
programming tools, like e.g Borlands Delphi, misses a lot of information.
Actually, many times the information is there, but is not searchable. Most
times when I look for something, I use the <--- and ---> (page buttons)
and suddenly find information I never knew was there. Reading the API
helpfiles, at least from some sources are like going on an adventure. You
never know what to find. Also, in my tools, the Bookmark feature is erased
across two helpfiles, so it useless feature, so once I find something
interessting, its best to copy the information to a text file. Also
sometime you find information for something else, at strange keywords,
that you couldnt find at resonable keywords. Its like its made to
deliberatly be hard to find info.
--
LOL
f0dder
> På Mon, 23 Aug 2004 14:06:41 +0200, skrev f0dder
> <f0dder_s...@flork.dk>:
>
>> The Wannabee wrote:
>>
>>>>>>> I just pasted in some _SMALL_ set of C structs form the library
>>>>>>> of Windows. The full set contains someting like 55000 equally
>>>>>>> insane identifyers structures.
>>>>>>>
>>>>>> Where is that from again? I searched both platformsdk and ntddk
>>>>>> for "aep_boot" and didn't find any hits. Are my psdk and ntddk
>>>>>> too old?
>>>>>
>>>>> Its pasted from Gugas WinDoc project. Ask to be a volountar, and
>>>>> get you own file :-))
>>>>>
>>>> Hm, so it's guga that came up with these structures and struct
>>>> names and not Microsoft?
>>>
>>> Nope.
>>>
>> Where are they from, then? Couldn't find them in PSDK or NTDDK.
>> Perhaps in the leaked NT4 or NT5 source code, or the IFS kit? Google
>> didn't report any hits either, which is unusual when googling for
>> microsoft related stuff :)
>
> AVIFILEINFO...you never saw this in windows ???
>
with AVIFILEINFO whatsoever. Looked rather more like something from
an OS - "AEP_REAL_MODE_HANDOFF".
> Theese structures are part of the full windows SDK. I cant tell you
> where exactly, the one most cryptic looking comes from because I dont
> know, but the AVIFILEINFO, is from the AVIFILE.dll.
>
I looked up AVIFILEINFO which is in vfw.h, and it looks pretty
straightforward to me. Has nothing to do with the mangled struct
you pasted.
> You should be aware that many of the API docs that comes along with
> many programming tools, like e.g Borlands Delphi, misses a lot of
> information. Actually, many times the information is there, but is
> not searchable. Most times when I look for something, I use the <---
> and ---> (page buttons) and suddenly find information I never knew
> was there.
>
Let me guess, you're stuck with some old .hlp file, like win32.hlp?
Do yourself a favour and get the PlatformSDK, it is in htmlhelp
format (well, recent releases are in htmlhelp2).
> Reading the API helpfiles, at least from some sources are
> like going on an adventure. You never know what to find. Also, in my
> tools, the Bookmark feature is erased across two helpfiles, so it
> useless feature, so once I find something interessting, its best to
> copy the information to a text file. Also sometime you find
> information for something else, at strange keywords, that you couldnt
> find at resonable keywords. Its like its made to deliberatly be hard
> to find info.
>
Win32.hlp is pretty sucky... especially if you have one of the
versions with a broken/missing .cnt file :-)
The Wannabee
<f0dder_s...@flork.dk>:
> The Wannabee wrote:
>> På Mon, 23 Aug 2004 14:06:41 +0200, skrev f0dder
>> <f0dder_s...@flork.dk>:
>>
>>> The Wannabee wrote:
>>>
>>>>>>>> I just pasted in some _SMALL_ set of C structs form the library
>>>>>>>> of Windows. The full set contains someting like 55000 equally
>>>>>>>> insane identifyers structures.
>>>>>>>>
>>>>>>> Where is that from again? I searched both platformsdk and ntddk
>>>>>>> for "aep_boot" and didn't find any hits. Are my psdk and ntddk
>>>>>>> too old?
>>>>>>
>>>>>> Its pasted from Gugas WinDoc project. Ask to be a volountar, and
>>>>>> get you own file :-))
>>>>>>
>>>>> Hm, so it's guga that came up with these structures and struct
>>>>> names and not Microsoft?
>>>>
>>>> Nope.
>>>>
>>> Where are they from, then? Couldn't find them in PSDK or NTDDK.
>>> Perhaps in the leaked NT4 or NT5 source code, or the IFS kit? Google
>>> didn't report any hits either, which is unusual when googling for
>>> microsoft related stuff :)
>>
>> AVIFILEINFO...you never saw this in windows ???
>>
> The structs you posted (all horribly garbled up) had nothing to do
> with AVIFILEINFO whatsoever. Looked rather more like something from
> an OS - "AEP_REAL_MODE_HANDOFF".
Oki. I pasted only a part of it.. my fault.
>> Theese structures are part of the full windows SDK. I cant tell you
>> where exactly, the one most cryptic looking comes from because I dont
>> know, but the AVIFILEINFO, is from the AVIFILE.dll.
>>
> I looked up AVIFILEINFO which is in vfw.h, and it looks pretty
> straightforward to me. Has nothing to do with the mangled struct
> you pasted.
Below is the full list.
> Win32.hlp is pretty sucky... especially if you have one of the
> versions with a broken/missing .cnt file :-)
_ADDRESS |Offset D|Segment1 W|Mode D typedef struct _tagADDRESS {
DWORD Offset; WORD Segment; ADDRESS_MODE Mode; } ADDRESS,
*LPADDRESS;
_BITMAPINFOHEADER biSize D|biWidth D|biHeight D|biPlanes W|biBitCount
W|biCompression typedef struct _tagBITMAPINFOHEADER{ DWORD biSize LONG
biWidth LONG biHeight WORD biPlanes WORD biBitCount DWORD
biCompression DWORD biSizeImage LONG biXPelsPerMeter LONG
biYPelsPerMeter DWORD biClrUsed DWORD biClrImportant ; }
_BITMAPINFOHEADER
_DEV_BROADCAST_USERDEFINED typedef struct _DEV_BROADCAST_USERDEFINED {
struct _DEV_BROADCAST_HDR dbud_dbh; char dbud_szName[1]; }
_DEV_BROADCAST_USERDEFINED;
_HARDWAREINFO typedef struct { DWORD ddCom_Port; DWORD com_base; DWORD
ddIRQ_Number; DWORD ddPauseTime; DWORD ddReserved; DWORD
ddOrientation; DRV_CALBSTRUCT calibrate; DWORD ddBufferZoneX; DWORD
ddBufferZoneY; DWORD ddHardwarePacketSize; DWORD ddComPortSettings;
DWORD dwHwFlags; DWORD ddHardwareType; DWORD ddTimerTickRate; DWORD
ddDelayTime; DWORD ddVpenD_IRQ_Handle; DWORD ddSystemVMHandle; }
_HARDWAREINFO
_HIDP_PREPARSED_DATA typedef struct _HIDP_PREPARSED_DATA *
PHIDP_PREPARSED_DATA
_IMAGE_CE_RUNTIME_FUNCTION_ENTRY typedef struct
_IMAGE_CE_RUNTIME_FUNCTION_ENTRY { unsigned int FuncStart : 32 unsigned
int PrologLen : 8 unsigned int FuncLen : 22 unsigned int ThirtyTwoBit :
1 unsigned int ExceptionFlag : 1 ; } IMAGE_CE_RUNTIME_FUNCTION_ENTRY,
*PIMAGE_CE_RUNTIME_FUNCTION_ENTRY
_IMAGE_RUNTIME_FUNCTION_ENTRY typedef struct_IMAGE_RUNTIME_FUNCTION_ENTRY
{ ULONG BeginAddress ULONG EndAddress PVOID ExceptionHandler PVOID
HandlerData ULONG PrologEndAddress ; } IMAGE_RUNTIME_FUNCTION_ENTRY,
*PIMAGE_RUNTIME_FUNCTIONG_ENTRY
_osispecflowparam typedef struct _osispecflowparam { u_short paramID //
Parameter ID. u_short paramLength // Length of following data. u_char
param // Parameter data. } OSISPECFLOWPARAM
_PV typedef union _PV { short int i; LONG l; ULONG ul; float flt; double
dbl; unsigned short int b; CURRENCY cur; double at; FILETIME ft; LPSTR
lpszA; SBinary bin; LPWSTR lpszW; LPGUID lpguid; LARGE_INTEGER li;
SShortArray MVi; SLongArray MVl; SRealArray MVflt; SDoubleArray MVdbl;
SCurrencyArray MVcur; SAppTimeArray MVat; SDateTimeArray MVft;
SBinaryArray MVbin; SLPSTRArray MVszA; SWStringArray MVszW; SGuidArray
MVguid; SLargeIntegerArray MVli; SCODE err; LONG x; } _UPV;
_URB_BULK_OR_INTERRUPT_TRANSFER struct _URB_BULK_OR_INTERRUPT_TRANSFER {
struct _URB_HEADER Hdr; USBD_PIPE_HANDLE PipeHandle; ULONG
TransferFlags; ULONG TransferBufferLength; PVOID TransferBuffer; PMDL
TransferBufferMDL; struct _URB *UrbLink; . . }
_URB_CONTROL_DESCRIPTOR_REQUEST struct _URB_CONTROL_DESCRIPTOR_REQUEST {
struct _URB_HEADER Hdr; . . ULONG TransferBufferLength ; PVOID
TransferBuffer ; PMDL TransferBufferMDL ; struct _URB *UrbLink ; . .
UCHAR Index ; UCHAR DescriptorType ; USHORT LanguageId ; . . }
_URB_CONTROL_FEATURE_REQUEST struct _URB_CONTROL_FEATURE_REQUEST {
struct _URB_HEADER Hdr; . . struct _URB *UrbLink ; . . USHORT
FeatureSelector ; USHORT Index ; . . }
_URB_CONTROL_GET_CONFIGURATION_REQUEST struct
_URB_CONTROL_GET_CONFIGURATION_REQUEST { struct _URB_HEADER Hdr; . .
ULONG TransferBufferLength; PVOID TransferBuffer; PMDL
TransferBufferMDL; struct _URB *UrbLink; . . }
_URB_CONTROL_GET_INTERFACE_REQUEST struct
_URB_CONTROL_GET_INTERFACE_REQUEST { struct _URB_HEADER s; . . ULONG
TransferBufferLength ; PVOID TransferBuffer ; PMDL TransferBufferMDL ;
struct _URB *UrbLink ; . . USHORT Interface; . . }
_URB_CONTROL_GET_STATUS_REQUEST struct _URB_CONTROL_GET_STATUS_REQUEST {
struct _URB_HEADER Hdr; . . ULONG TransferBufferLength ; PVOID
TransferBuffer ; PMDL TransferBufferMDL ; struct _URB *UrbLink ; . .
USHORT Index ; . . }
_URB_CONTROL_TRANSFER struct _URB_CONTROL_TRANSFER { struct _URB_HEADER
Hdr; USBD_PIPE_HANDLE PipeHandle; ULONG TransferFlags; ULONG
TransferBufferLength; PVOID TransferBuffer; PMD L TransferBufferMDL;
struct _URB *UrbLink; . . UCHAR SetupPacket[8]; }
_URB_CONTROL_VENDOR_OR_CLASS_REQUEST struct
_URB_CONTROL_VENDOR_OR_CLASS_REQUEST { struct _URB_HEADER Hdr; . . ULONG
TransferFlags ; ULONG TransferBufferLength ; PVOID TransferBuffer ;
PMDL TransferBufferMDL ; struct _URB *UrbLink ; . . UCHAR
RequestTypeReservedBits; UCHAR Request; USHORT Value; USHORT Index; .
. }
_URB_FRAME_LENGTH_CONTROL struct _URB_FRAME_LENGTH_CONTROL { struct
_URB_HEADER Hdr; }
_URB_GET_CURRENT_FRAME_NUMBER struct _URB_GET_CURRENT_FRAME_NUMBER {
struct _URB_HEADER Hdr; ULONG FrameNumber ; }
_URB_GET_FRAME_LENGTH struct _URB_GET_FRAME_LENGTH { struct _URB_HEADER
Hdr; ULONG FrameLength ; ULONG FrameNumber ; }
_URB_HEADER struct _URB_HEADER { USHORT Length ; USHORT Function ; . .
USBD_STATUS Status ; . . }
_URB_ISOCH_TRANSFER struct _URB_ISOCH_TRANSFER { struct _URB_HEADER
Hdr; USBD_PIPE_HANDLE PipeHandle; ULONG TransferFlags; ULONG
TransferBufferLength; PVOID TransferBuffer; PMDL TransferBufferMDL; . .
ULONG StartFrame; ULONG NumberOfPackets; ULONG ErrorCount;
USBD_ISO_PACKET_DESCRIPTOR IsoPacket[1]; }
_URB_PIPE_REQUEST struct _URB_PIPE_REQUEST { struct _URB_HEADER Hdr;
USBD_PIPE_HANDLE PipeHandle ; }
_URB_SELECT_CONFIGURATION struct _USB_SELECT_CONFIGURATION { struct
_URB_HEADER Hdr; PUSB_CONFIGRUATION_DESCRIPTOR ConfigurationDescriptor ;
USB_CONFIGURATION_HANDLE ConfigurationHandle ; USBD_INTERFACE_INFORMATION
Interface ; }
_URB_SELECT_INTERFACE struct _URB_SELECT_INTERFACE { struct _URB_HEADER
Hdr; USBD_CONFIGURATION_HANDLE ConfigurationHandle ;
USBD_INTERFACE_INFORMATION Interface ; }
_URB_SET_FRAME_LENGTH struct _URB_SET_FRAME_LENGTH { struct _URB_HEADER
Hdr; LONG FrameLengthDelta; }
_VIDEOINFOHEADER typedef struct _tagVIDEOINFOHEADER{ RECT rcSource RECT
rcTarget DWORD dwBitRate DWORD dwBitErrorRate REFERENCE_TIME
AvgTimePerFrame BITMAPINFOHEADER bmiHeader ; } _VIDEOINFOHEADER
_VpenD_Register typedef struct { DWORD Device_VM_Handle; DWORD ibThis;
DWORD ibThis_offset; DWORD ibNext; DWORD ibNext_offset; DWORD
ibCurrent; DWORD iNumberOfPenPackets; DWORD wPDKLast; DWORD pDataType;
DWORD piNumberOfPenPackets; DWORD piThis_Offset; DWORD piThis;
LPDRV_PENPACKET pPenPacketBuffer; LPDRV_PENINFO pPenInfo; DWORD
pOEMBuffer; DWORD pfnEntryPoint; } _VpenD_Register
_WAVEFORMATEX typedef struct _tWAVEFORMATEX{ WORD wFormatTag WORD
nChannels DWORD nSamplesPerSec DWORD nAvgBytesPerSec WORD nBlockAlign
WORD wBitsPerSample WORD cbSize ; } _WAVEFORMATEX
AAL_PARAMETERS_IE typedef struct _AAL_PARAMETERS_IE { ATM_AAL_TYPE
AALType; union { AAL1_PARAMETERS AAL1Parameters; AAL34_PARAMETERS
AAL34Parameters; AAL5_PARAMETERS AAL5Parameters; AALUSER_PARAMETERS
AALUserParameters; } AALSpecificParameters; } AAL_PARAMETERS_IE,
*PAAL_PARAMETERS_IE
AAL1_PARAMETERS typedef struct _AAL1_PARAMETERS { UCHAR Subtype; UCHAR
CBRRate; USHORT Multiplier; UCHAR SourceClockRecoveryMethod; UCHAR
ErrorCorrectionMethod; USHORT StructuredDataTransferBlocksize; UCHAR
PartiallyFilledCellsMethod; } AAL1_PARAMETERS, *PAAL1_PARAMETERS
AAL34_PARAMETERS typedef struct _AAL34_PARAMETERS { USHORT
ForwardMaxCPCSSDUSize; USHORT BackwardMaxCPCSSDUSize; USHORT LowestMID;
USHORT HighestMID; UCHAR SSCSType; } AAL34_PARAMETERS,
*PAAL34_PARAMETERS
AAL5_PARAMETERS typedef struct _AAL5_PARAMETERS { ULONG
ForwardMaxCPCSSDUSize; ULONG BackwardMaxCPCSSDUSize; UCHAR Mode; UCHAR
SSCSType; } AAL5_PARAMETERS, *PAAL5_PARAMETERS
AALUSER_PARAMETERS typedef struct _AALUSER_PARAMETERS { ULONG
UserDefined; } AALUSER_PARAMETERS, *PAALUSER_PARAMETERS
AASHELLMENUFILENAME typedef struct tagAAMENUFILENAME { SHORT cbTotal
BYTE rgbReserved[12] TCHAR szFileName[1] ; } AASHELLMENUFILENAME,
*LPAASHELLMENUFILENAME
AASHELLMENUITEM typedef struct tagAASHELLMENUITEM { VOID lpReserved1
int iReserved UINT uiReserved LPAASHELLMENUFILENAME lpName LPTSTR psz ;
} AASHELLMENUITEM, *LPAASHELLMENUITEM
ABC |abcA D|abcB D|abcC D typedef struct _ABC { int abcA UINT abcB int
abcC ; } ABC, *PABC
ABCFLOAT |abcfA D|abcfB D|abcfC D typedef struct _ABCFLOAT { FLOAT abcfA
FLOAT abcfB FLOAT abcfC ; } ABCFLOAT, *PABCFLOAT
ABORTPATH typedef struct tagABORTPATH { EMR emr ; } EMRABORTPATH,
*PEMRABORTPATH, EMRBEGINPATH, *PEMRBEGINPATH, EMRENDPATH, *PEMRENDPATH,
EMRCLOSEFIGURE, *PEMRCLOSEFIGURE, EMRFLATTENPATH, *PEMRFLATTENPATH,
EMRWIDENPATH, *PEMRWIDENPATH, EMRSETMETARGN, *PEMRSETMETARGN, EMRSAVEDC,
*PEMRSAVEDC, EMRREALIZEPALETTE, *PEMRREALIZEPALETTE
ABSTIME typedef struct { DWORD sec; UINT ms; } ABSTIME;
ACCEL |fVirt B|key W|cmd W typedef struct tagACCEL { BYTE fVirt WORD
key WORD cmd WORD pad ; } ACCEL
ACCELTABLEENTRY struct ACCELTABLEENTRY { WORD fFlags WORD wAnsi WORD
wId WORD padding; }
ACCESS_ALLOWED_ACE |Header.AceType B|Header.AceFlags B|Header.AceSize
W|imask D|SidStart D typedef struct _ACCESS_ALLOWED_ACE { ACE_HEADER
Header; ACCESS_MASK Mask; DWORD SidStart; } ACCESS_ALLOWED_ACE;
ACCESS_ALLOWED_CALLBACK_ACE typedef struct _ACCESS_ALLOWED_CALLBACK_ACE
{ ACE_HEADER Header; ACCESS_MASK Mask; DWORD SidStart; }
ACCESS_ALLOWED_CALLBACK_ACE;
ACCESS_ALLOWED_CALLBACK_OBJECT_ACE typedef struct
_ACCESS_ALLOWED_OBJECT_CALLBACK_ACE { ACE_HEADER Header; ACCESS_MASK
Mask; DWORD Flags; GUID ObjectType; GUID InheritedObjectType; DWORD
SidStart; } ACCESS_ALLOWED_OBJECT_ACE,
*PACCESS_ALLOWED_CALLBACK_OBJECT_ACE;
ACCESS_ALLOWED_OBJECT_ACE |Header.AceType B|Header.AceFlags
B|Header.AceSize W|Mask1 D|Flags D|ObjectType.Data1 D|ObjectType.Data2
W|ObjectType.Data3 W|ObjectType.Data4 B 8|InheritedObjectType.Data1
D|InheritedObjectType.Data2 W|InheritedObjectType.Data3
W|InheritedObjectType.Data4 B 8|SidStart D typedef struct
_ACCESS_ALLOWED_OBJECT_ACE { ACE_HEADER Header; ACCESS_MASK Mask; DWORD
Flags; GUID ObjectType; GUID InheritedObjectType; DWORD SidStart; }
ACCESS_ALLOWED_OBJECT_ACE, *PACCESS_ALLOWED_OBJECT_ACE;
ACCESS_DENIED_ACE |Header.AceType B|Header.AceFlags B|Header.AceSize
W|imask D|SidStart D typedef struct _ACCESS_DENIED_ACE { ACE_HEADER
Header; ACCESS_MASK Mask; DWORD SidStart; } ACCESS_DENIED_ACE;
ACCESS_DENIED_CALLBACK_ACE typedef struct { ACE_HEADER Header;
ACCESS_MASK Mask; DWORD SidStart; } ACCESS_DENIED_CALLBACK_ACE;
ACCESS_DENIED_CALLBACK_OBJECT_ACE typedef struct
_ACCESS_DENIED_CALLBACK_OBJECT_ACE { ACE_HEADER Header; ACCESS_MASK
Mask; DWORD Flags; GUID ObjectType; GUID InheritedObjectType; DWORD
SidStart; } ACCESS_DENIED_CALLBACK_OBJECT_ACE,
*PACCESS_DENIED_CALLBACK_OBJECT_ACE;
ACCESS_DENIED_OBJECT_ACE |Header.AceType B|Header.AceFlags
B|Header.AceSize W|Mask1 D|Flags D|ObjectType.Data1 D|ObjectType.Data2
W|ObjectType.Data3 W|ObjectType.Data4 B 8|InheritedObjectType.Data1
D|InheritedObjectType.Data2 W|InheritedObjectType.Data3
W|InheritedObjectType.Data4 B 8|SidStart D typedef struct
_ACCESS_DENIED_OBJECT_ACE { ACE_HEADER Header; ACCESS_MASK Mask; DWORD
Flags; GUID ObjectType; GUID InheritedObjectType; DWORD SidStart; }
ACCESS_DENIED_OBJECT_ACE, *PACCESS_DENIED_OBJECT_ACE;
access_info_0 |acc0_resource_name D typedef struct _access_info_0 { char
FAR* acc0_resource_name; } _access_info_0;
access_info_1 |acc1_resource_name D|acc1_attr D|acc1_count D typedef
struct _access_info_1 { char FAR* acc1_resource_name; short acc1_attr;
short acc1_count; } _access_info_1;
ACCESS_INFO_1002 |acc1002_attr D typedef struct _ACCESS_INFO_1002 { DWORD
acc1002_attr; } ACCESS_INFO_1002, *PACCESS_INFO_1002, *LPACCESS_INFO_1002;
access_list |acl_ugname D|acl_access D typedef struct _access_list { char
acl_ugname[LM20_UNLEN+1]; char acl_ugname_pad_1; short acl_access; }
_access_list;
ACCESS_MASK typedef DWORD ACCESS_MASK;
ACCESS_RANGE typedef struct _ACCESS_RANGE { SCSI_PHYSICAL_ADDRESS
RangeStart; ULONG RangeLength; BOOLEAN RangeInMemory; } ACCESS_RANGE,
*PACCESS_RANGE
accessdata_dn struct accessdata_dn { unsigned short acc_accl // account
length unsigned char acc_acc[DN_MAXACCL] // account string unsigned
short acc_passl // password length unsigned char acc_pass[DN_MAXACCL] //
password string unsigned short acc_userl // user length unsigned char
acc_user[DN_MAXACCL] // user string }
ACCESSTIMEOUT |cbSize D|dwFlags D|iTimeOutMSec D typedef struct
tagACCESSTIMEOUT { // ato UINT cbSize; DWORD dwFlags; DWORD iTimeOutMSec;
} ACCESSTIMEOUT;
ACE
ACE_HEADER |AceType B|AceFlags B|AceSize W typedef struct _ACE_HEADER {
BYTE AceType; BYTE AceFlags; WORD AceSize; } ACE_HEADER, *PACE_HEADER;
ACL |AclRevision B|Sbz1 B|AclSize W|AceCount W|Sbz2 W typedef struct _ACL
{ BYTE AclRevision; BYTE Sbz1; WORD AclSize; WORD AceCount; WORD
Sbz2; } ACL, *PACL;
ACL_REVISION_INFORMATION |AclRevision D typedef struct
_ACL_REVISION_INFORMATION { DWORD AclRevision; }
ACL_REVISION_INFORMATION;
ACL_SIZE_INFORMATION |AceCount D|AclBytesInUse D|AclBytesFree D typedef
struct _ACL_SIZE_INFORMATION { DWORD AceCount; DWORD AclBytesInUse;
DWORD AclBytesFree; } ACL_SIZE_INFORMATION;
ACMDRIVERDETAILS typedef struct { DWORD cbStruct; FOURCC fccType;
FOURCC fccComp; WORD wMid; WORD wPid; DWORD vdwACM; DWORD vdwDriver;
DWORD fdwSupport; DWORD cFormatTags; DWORD cFilterTags; HICON hicon;
char szShortName[ACMDRIVERDETAILS_SHORTNAME_CHARS]; char
szLongName[ACMDRIVERDETAILS_LONGNAME_CHARS]; char
szCopyright[ACMDRIVERDETAILS_COPYRIGHT_CHARS]; char
szLicensing[ACMDRIVERDETAILS_LICENSING_CHARS]; char
szFeatures[ACMDRIVERDETAILS_FEATURES_CHARS]; } ACMDRIVERDETAILS
ACMDRVFORMATSUGGEST typedef struct { DWORD cbStruct; DWORD fdwSuggest;
LPWAVEFORMATEX pwfxSrc; DWORD cbwfxSrc; LPWAVEFORMATEX pwfxDst; DWORD
cbwfxDst; } ACMDRVFORMATSUGGEST
ACMDRVOPENDESC typedef struct { DWORD cbStruct; FOURCC fccType; FOURCC
fccComp; DWORD dwVersion; DWORD dwFlags; DWORD dwError; LPCWSTR
pszSectionName; LPCWSTR pszAliasName; DWORD dnDevNode; } ACMDRVOPENDESC
ACMDRVSTREAMHEADER typedef struct { DWORD cbStruct; DWORD fdwStatus;
DWORD dwUser; LPBYTE pbSrc; DWORD cbSrcLength; DWORD cbSrcLengthUsed;
DWORD dwSrcUser; LPBYTE pbDst; DWORD cbDstLength; DWORD
cbDstLengthUsed; DWORD dwDstUser; DWORD fdwConvert;
LPACMDRVSTREAMHEADER padshNext; DWORD fdwDriver; DWORD dwDriver; DWORD
fdwPrepared; DWORD dwPrepared; LPBYTE pbPreparedSrc; DWORD
cbPreparedSrcLength; LPBYTE pbPreparedDst; DWORD cbPreparedDstLength; }
ACMDRVSTREAMHEADER
ACMDRVSTREAMINSTANCE typedef struct { DWORD cbStruct; LPWAVEFORMATEX
pwfxSrc; LPWAVEFORMATEX pwfxDst; LPWAVEFILTER pwfltr; DWORD
dwCallback; DWORD dwInstance; DWORD fdwOpen; DWORD fdwDriver; DWORD
dwDriver; HACMSTREAM has; } ACMDRVSTREAMINSTANCE
ACMDRVSTREAMSIZE typedef struct { DWORD cbStruct; DWORD fdwSize; DWORD
cbSrcLength; DWORD cbDstLength; } ACMDRVSTREAMSIZE
ACMFILTERCHOOSE typedef struct { DWORD cbStruct; DWORD fdwStyle; HWND
hwndOwner; LPWAVEFILTER pwfltr; DWORD cbwfltr; LPCSTR pszTitle; char
szFilterTag[ACMFILTERTAGDETAILS_FILTERTAG_CHARS]; char
szFilter[ACMFILTERDETAILS_FILTER_CHARS]; LPSTR pszName; DWORD cchName;
DWORD fdwEnum; LPWAVEFILTER pwfltrEnum; HINSTANCE hInstance; LPCSTR
pszTemplateName; LPARAM lCustData; ACMFILTERCHOOSEHOOKPROC pfnHook; }
ACMFILTERCHOOSE
ACMFILTERDETAILS typedef struct { DWORD cbStruct; DWORD dwFilterIndex;
DWORD dwFilterTag; DWORD fdwSupport; LPWAVEFILTER pwfltr; DWORD
cbwfltr; char szFilter[ACMFILTERDETAILS_FILTER_CHARS]; }
ACMFILTERDETAILS
ACMFILTERTAGDETAILS typedef struct { DWORD cbStruct; DWORD
dwFilterTagIndex; DWORD dwFilterTag; DWORD cbFilterSize; DWORD
fdwSupport; DWORD cStandardFilters; char
szFilterTag[ACMFILTERTAGDETAILS_FILTERTAG_CHARS]; } ACMFILTERTAGDETAILS
ACMFORMATCHOOSE typedef struct { DWORD cbStruct; DWORD fdwStyle; HWND
hwndOwner; LPWAVEFORMATEX pwfx; DWORD cbwfx; LPCSTR pszTitle; char
szFormatTag[ACMFORMATTAGDETAILS_FORMATTAG_CHARS]; char
szFormat[ACMFORMATDETAILS_FORMAT_CHARS]; LPSTR pszName; DWORD cchName;
DWORD fdwEnum; LPWAVEFORMATEX pwfxEnum; HINSTANCE hInstance; LPCSTR
pszTemplateName; LPARAM lCustData; ACMFORMATCHOOSEHOOKPROC pfnHook; }
ACMFORMATCHOOSE
ACMFORMATDETAILS typedef struct { DWORD cbStruct; DWORD dwFormatIndex;
DWORD dwFormatTag; DWORD fdwSupport; LPWAVEFORMATEX pwfx; DWORD cbwfx;
char szFormat[ACMFORMATDETAILS_FORMAT_CHARS]; } ACMFORMATDETAILS
ACMFORMATTAGDETAILS typedef struct { DWORD cbStruct; DWORD
dwFormatTagIndex; DWORD dwFormatTag; DWORD cbFormatSize; DWORD
fdwSupport; DWORD cStandardFormats; char
szFormatTag[ACMFORMATTAGDETAILS_FORMATTAG_CHARS]; } ACMFORMATTAGDETAILS
ACMSTREAMHEADER typedef struct { DWORD cbStruct; DWORD fdwStatus;
DWORD_PTR dwUser; LPBYTE pbSrc; DWORD cbSrcLength; DWORD
cbSrcLengthUsed; DWORD_PTR dwSrcUser; LPBYTE pbDst; DWORD cbDstLength;
DWORD cbDstLengthUsed; DWORD_PTR dwDstUser; DWORD dwReservedDriver[10];
} ACMSTREAMHEADER
ACTCTX typedef struct tagACTCTX { ULONG cbSize; DWORD dwFlags; LPCWSTR
lpSource; USHORT wProcessorArchitecture; LANGID wLangId; LPCTSTR
lpAssemblyDirectory; LPCTSTR lpResourceName; LPCTSTR lpApplicationName;
HMODULE hModule; } ACTCTX, *PACTCTX;
ACTCTX_SECTION_KEYED_DATA typedef struct tagACTCTX_SECTION_KEYED_DATA {
ULONG cbSize; ULONG ulDataFormatVersion; PVOID lpData; ULONG ulLength;
PVOID lpSectionGlobalData; ULONG ulSectionGlobalDataLength; PVOID
lpSectionBase; ULONG ulSectionTotalLength; HANDLE hActCtx; HANDLE
ulAssemblyRosterIndex; } ACTCTX_SECTION_KEYED_DATA,
*PACTCTX_SECTION_KEYED_DATA;
ACTION_HEADER |transport_id D|action_code W|Reserved W typedef struct
_ACTION_HEADER { ULONG transport_id; USHORT action_code; USHORT
reserved; } ACTION_HEADER, *PACTION_HEADER
ACTIVATION_CONTEXT_ASSEMBLY_DETAILED_INFORMATION typedef struct
_ACTIVATION_CONTEXT_ASSEMBLY_DETAILED_INFORMATION { DWORD ulFlags; DWORD
ulEncodedAssemblyIdentityLength; DWORD ulManifestPathType; DWORD
ulManifestPathLength; LARGE_INTEGER liManifestLastWriteTime; DWORD
ulPolicyPathType; DWORD ulPolicyPathLength; LARGE_INTEGER
liPolicyLastWriteTime; DWORD ulMetadataSatelliteRosterIndex; DWORD
ulManifestVersionMajor; DWORD ulManifestVersionMinor; DWORD
ulPolicyVersionMajor; DWORD ulPolicyVersionMinor; DWORD
ulAssemblyDirectoryNameLength; PCWSTR lpAssemblyEncodedAssemblyIdentity;
PCWSTR lpAssemblyManifestPath; PCWSTR lpAssemblyPolicyPath; PCWSTR
lpAssemblyDirectoryName; }
ACTIVATION_CONTEXT_ASSEMBLY_DETAILED_INFORMATION,
*PACTIVATION_CONTEXT_ASSEMBLY_DETAILED_INFORMATION;
ACTIVATION_CONTEXT_DETAILED_INFORMATION typedef struct
_ACTIVATION_CONTEXT_DETAILED_INFORMATION { DWORD dwFlags; DWORD
ulFormatVersion; DWORD ulAssemblyCount; DWORD ulRootManifestPathType;
DWORD ulRootManifestPathChars; DWORD ulRootConfigurationPathType; DWORD
ulRootConfigurationPathChars; DWORD ulAppDirPathType; DWORD
ulAppDirPathChars; PCWSTR lpRootManifestPath; PCWSTR
lpRootConfigurationPath; PCWSTR lpAppDirPath; }
ACTIVATION_CONTEXT_DETAILED_INFORMATION,
*PACTIVATION_CONTEXT_DETAILED_INFORMATION;
ACTIVATION_CONTEXT_QUERY_INDEX typedef struct
_ACTIVATION_CONTEXT_QUERY_INDEX { ULONG ulAssemblyIndex; ULONG
ulFileIndexInAssembly; } ACTIVATION_CONTEXT_QUERY_INDEX,
*PACTIVATION_CONTEXT_QUERY_INDEX;
ACTRL_ACCESS typedef struct _ACTRL_ALIST { ULONG cEntries;
PACTRL_PROPERTY_ENTRY pPropertyAccessList; } ACTRL_ACCESS ,
*PACTRL_ACCESS;
ACTRL_ACCESS_ENTRY typedef struct _ACTRL_ACCESS_ENTRY { TRUSTEE
Trustee; ULONG fAccessFlags; ACCESS_RIGHTS Access;
ACCESS_RIGHTS ProvSpecificAccess; INHERIT_FLAGS Inheritance;
LPCTSTR lpInheritProperty; } ACTRL_ACCESS_ENTRY;
ACTRL_ACCESS_ENTRY_LIST typedef struct _ACTRL_ACCESS_ENTRY_LIST
{ ULONG cEntries; PACTRL_ACCESS_ENTRY pAccessList; }
ACTRL_ACCESS_ENTRY_LIST, *PACTRL_ACCESS_ENTRY_LIST;
ACTRL_ACCESS_INFO typedef struct _ACTRL_ACCESS_INFO { ULONG
fAccessPermission; LPTSTR lpAccessPermissionName; }
ACTRL_ACCESS_INFO, *PACTRL_ACCESS_INFO;
ACTRL_AUDIT typedef struct _ACTRL_ALIST { ULONG
cEntries; PACTRL_PROPERTY_ENTRY pPropertyAccessList; }
ACTRL_AUDIT, *PACTRL_AUDIT;
ACTRL_OVERLAPPED typedef struct _ACTRL_OVERLAPPED { ULONG
Reserved1; ULONG Reserved2; HANDLE hEvent; } ACTRL_OVERLAPPED,
*PACTRL_OVERLAPPED;
ACTRL_PROPERTY_ENTRY typedef struct _ACTRL_PROPERTY_ENTRY { LPCTSTR
lpProperty; PACTRL_ACCESS_ENTRY_LIST pAccessEntryList; ULONG
fListFlags; } ACTRL_PROPERTY_ENTRY, *PACTRL_PROPERTY_ENTRY;
AD_GENERAL_PARAMS typedef struct _AD_GENERAL_PARAMS { ULONG
IntServAwareHopCount; ULONG PathBandwidthEstimate; ULONG
MinimumLatency; ULONG PathMTU; ULONG Flags; } AD_GENERAL_PARAMS,
*LPAD_GENERAL_PARAMS;
ADAPTER_STATUS |adapter_address B 6|rev_major B|reserved0 B|adapter_type
B|rev_minor B|duration W|frmr_recv W|frmr_xmit W|iframe_recv_err
W|xmit_aborts W|xmit_success D|recv_success D|iframe_xmit_err
W|recv_buff_unavail W|t1_timeouts W|ti_timeouts W|rserved1 D|free_ncbs
W|max_cfg_ncbs W|max_ncbs W|xmit_buf_unavail W|max_dgram_isize
W|pending_sess W|max_cfg_sess W|max_sess W|max_sess_pkt_isize W|name_count
W typedef struct _ADAPTER_STATUS { UCHAR adapter_address[6]; UCHAR
rev_major; UCHAR reserved0; UCHAR adapter_type; UCHAR rev_minor; WORD
duration; WORD frmr_recv; WORD frmr_xmit; WORD iframe_recv_err; WORD
xmit_aborts; DWORD xmit_success; DWORD recv_success; WORD
iframe_xmit_err; WORD recv_buff_unavail; WORD t1_timeouts; WORD
ti_timeouts; DWORD reserved1; WORD free_ncbs; WORD max_cfg_ncbs; WORD
max_ncbs; WORD xmit_buf_unavail; WORD max_dgram_size; WORD
pending_sess; WORD max_cfg_sess; WORD max_sess; WORD
max_sess_pkt_size; WORD name_count; } ADAPTER_STATUS, *PADAPTER_STATUS
ADDJOB_INFO_1 |Path D|JobId D typedef struct _ADDJOB_INFO_1 { LPTSTR
Path DWORD JobId ; } ADDJOB_INFO_1, *PADDJOB_INFO_1
ADDJOB_INFO_1A |Path D|JobId D typedef struct _ADDJOB_INFO_1 { // aji1
LPTSTR Path; DWORD JobId; } ADDJOB_INFO_1;
ADDJOB_INFO_1W typedef struct _ADDJOB_INFO_1W { LPSTR Path; DWORD JobId;
} ADDJOB_INFO_1W, *PADDJOB_INFO_1W, *LPADDJOB_INFO_1W;
ADDRESS typedef struct _ADDRESS { DWORD Type; union { BYTE
MACAddress[MAC_ADDRESS_SIZE]; BYTE IPAddress[IP_ADDRESS_SIZE]; BYTE
IPXRawAddress[IPX_ADDRESS_SIZE]; IPX_ADDRESS IPXAddress; BYTE
VinesIPRawAddress[VINES_IP_ADDRESS_SIZE]; VINES_IP_ADDRESS
VinesIPAddress; ETHERNET_SRC_ADDRESS EthernetSrcAddress;
ETHERNET_DST_ADDRESS EthernetDstAddress; TOKENRING_SRC_ADDRESS
TokenringSrcAddress; TOKENRING_DST_ADDRESS TokenringDstAddress;
FDDI_SRC_ADDRESS FddiSrcAddress; FDDI_DST_ADDRESS FddiDstAddress; };
WORD Flags; } ADDRESS, *LPADDRESS;
ADDRESS_FIFO typedef struct _ADDRESS_FIFO { SINGLE_LIST_ENTRY FifoList;
PMDL FifoMdl; } ADDRESS_FIFO, *PADDRESS_FIFO
ADDRESS_LIST_DESCRIPTOR typedef struct _ADDRESS_LIST_DESCRIPTOR { ULONG
MediaType; NETWORK_ADDRESS_LIST AddressList; } ADDRESS_LIST_DESCRIPTOR,
*PADDRESS_LIST_DESCRIPTOR;
ADDRESS_OFFSET typedef struct _ADDRESS_OFFSET { USHORT Off_High; ULONG
Off_Low; } ADDRESS_OFFSET, *PADDRESS_OFFSET
ADDRESS_RANGE typedef struct _ADDRESS_RANGE { USHORT AR_Off_High;
USHORT AR_Length; ULONG AR_Off_Low; } ADDRESS_RANGE, *PADDRESS_RANGE
ADDRESS64 typedef struct _tagADDRESS64 { DWORD64 Offset; WORD Segment;
ADDRESS_MODE Mode; } ADDRESS64, *LPADDRESS64;
ADDRESSPAIR typedef struct _ADDRESSPAIR { WORD AddressFlags; WORD
NalReserved; ADDRESS DstAddress; ADDRESS SrcAddress; } ADDRESSPAIR,
*LPADDRESSPAIR;
ADDRESSTABLE typedef struct _ADDRESSTABLE { DWORD nAddressPairs; DWORD
nNonMacAddressPairs; ADDRESSPAIR AddressPair[MAX_ADDRESS_PAIRS]; }
ADDRESSTABLE, *LPADDRESSTABLE;
addrinfo typedef struct addrinfo { int ai_flags; int ai_family; int
ai_socktype; int ai_protocol; size_t ai_addrlen; char* ai_canonname;
struct sockaddr* ai_addr; struct addrinfo* ai_next; } addrinfo;
ADMIN_OTHER_INFO |alrtad_errcode D|alrtad_numstrings D typedef struct
_ADMIN_OTHER_INFO { DWORD alrtad_errcode; DWORD alrtad_numstrings; }
ADMIN_OTHER_INFO, *PADMIN_OTHER_INFO, *LPADMIN_OTHER_INFO;
ADMINISTRATOR_POWER_POLICY typedef struct _ADMINISTRATOR_POWER_POLICY {
SYSTEM_POWER_STATE MinSleep; SYSTEM_POWER_STATE MaxSleep; ULONG
MinVideoTimeout; ULONG MaxVideoTimeout; ULONG MinSpindownTimeout; ULONG
MaxSpindownTimeout; } ADMINISTRATOR_POWER_POLICY,
*PADMINISTRATOR_POWER_POLICY;
ADRENTRY |ulReserved1 D|cValues D|rgPropVals D typedef struct _ADRENTRY {
ULONG ulReserved1 ULONG cValues LPSPropValue rgPropVals ; } ADRENTRY
ADRLIST |cEntries D|aEntries.ulReserved1 D|aEntries.cValues
D|aEntries.rgPropVals D typedef struct _ADRLIST { ULONG cEntries
ADRENTRY aEntries[MAPI_DIM] ; } ADRLIST
ADRPARM |cbABContEntryID D|lpABContEntryID D|ulFlags D|lpReserved
D|ulHelpContext D|lpszHelpFileName D|lpfnABSDI D|lpfnDismiss
D|lpvDismissContext D|lpszCaption D|lpszNewEntryTitle D|lpszDestWellsTitle
D|cDestFields D|nDestFieldFocus D|lppszDestTitles D|lpulDestComps
D|lpContRestriction D|lpHierRestriction D typedef struct _ADRPARM { ULONG
cbABContEntryID LPENTRYID lpABContEntryID ULONG ulFlags LPVOID
lpReserved ULONG ulHelpContext LPTSTR lpszHelpFileName LPFNABSDI
lpfnABSDI LPFNDISMISS lpfnDismiss LPVOID lpvDismissContext LPTSTR
lpszCaption LPTSTR lpszNewEntryTitle LPTSTR lpszDestWellsTitle ULONG
cDestFields ULONG nDestFieldFocus LPTSTR *lppszDestTitles ULONG
*lpulDestComps LPSRestriction lpContRestriction LPSRestriction
lpHierRestriction ; } ADRPARM, *LPADRPARM
ADSPEC typedef struct { RsvpObjHdr adspec_header; IS_ADSPEC_BODY
adspec_body; } ADSPEC;
AE_ACCLIM |ae_al_compname D|ae_al_username D|ae_al_resname D|ae_al_limit
D
AE_ACLMOD |ae_am_compname D|ae_am_username D|ae_am_resname D|ae_am_action
D|ae_am_datalen D typedef struct _AE_ACLMOD { DWORD ae_am_compname; DWORD
ae_am_username; DWORD ae_am_resname; DWORD ae_am_action; DWORD
ae_am_datalen; } AE_ACLMOD,*PAE_ACLMOD,*LPAE_ACLMOD;
AE_CLOSEFILE |ae_cf_compname D|ae_cf_username D|ae_cf_resname
D|ae_cf_fileid D|ae_cf_duration D|ae_cf_reason D
AE_CONNREJ |ae_cr_compname D|ae_cr_username D|ae_cr_netname D|ae_cr_reason
D typedef struct _AE_CONNREJ { DWORD ae_cr_compname; DWORD ae_cr_username;
DWORD ae_cr_netname; DWORD ae_cr_reason; }
AE_CONNREJ,*PAE_CONNREJ,*LPAE_CONNREJ;
AE_CONNSTART |ae_ct_compname D|ae_ct_username D|ae_ct_netname
D|ae_ct_connid D
AE_CONNSTOP |ae_cp_compname D|ae_cp_username D|ae_cp_netname
D|ae_cp_connid D|ae_cp_reason D typedef struct _AE_CONNSTOP { DWORD
ae_cp_compname; DWORD ae_cp_username; DWORD ae_cp_netname; DWORD
ae_cp_connid; DWORD ae_cp_reason; }
AE_CONNSTOP,*PAE_CONNSTOP,*LPAE_CONNSTOP;
AE_GENERIC |ae_ge_msgfile D|ae_ge_msgnum D|ae_ge_params D|ae_ge_param1
D|ae_ge_param2 D|ae_ge_param3 D|ae_ge_param4 D|ae_ge_param5 D|ae_ge_param6
D|ae_ge_param7 D|ae_ge_param8 D|ae_ge_param9 D
AE_LOCKOUT |ae_lk_compname D|ae_lk_username D|ae_lk_action
D|ae_lk_bad_pw_count D typedef struct _AE_LOCKOUT { DWORD ae_lk_compname;
DWORD ae_lk_username; DWORD ae_lk_action; DWORD ae_lk_bad_pw_count; }
AE_LOCKOUT,*PAE_LOCKOUT,*LPAE_LOCKOUT;
AE_NETLOGOFF |ae_nf_compname D|ae_nf_username D|ae_nf_reserved1
D|ae_nf_reserved2 D
AE_NETLOGON |ae_no_compname D|ae_no_username D|ae_no_privilege
D|ae_no_authflags D typedef struct _AE_NETLOGON { DWORD ae_no_compname;
DWORD ae_no_username; DWORD ae_no_privilege; DWORD ae_no_authflags; }
AE_NETLOGON,*PAE_NETLOGON,*LPAE_NETLOGON;
AE_RESACCESS |ae_ra_compname D|ae_ra_username D|ae_ra_resname
D|ae_ra_operation D|ae_ra_returncode D|ae_ra_restype D|ae_ra_fileid D
AE_RESACCESSREJ |ae_rr_compname D|ae_rr_username D|ae_rr_resname
D|ae_rr_operation D typedef struct _AE_RESACCESSREJ { DWORD
ae_rr_compname; DWORD ae_rr_username; DWORD ae_rr_resname; DWORD
ae_rr_operation; } AE_RESACCESSREJ,*PAE_RESACCESSREJ,*LPAE_RESACCESSREJ;
AE_SERVICESTAT |ae_ss_compname D|ae_ss_username D|ae_ss_svcname
D|ae_ss_status D|ae_ss_code D|ae_ss_text D|ae_ss_returnval D
AE_SESSLOGOFF |ae_sf_compname D|ae_sf_username D|ae_sf_reason D typedef
struct _AE_SESSLOGOFF { DWORD ae_sf_compname; DWORD ae_sf_username; DWORD
ae_sf_reason; } AE_SESSLOGOFF,*PAE_SESSLOGOFF,*LPAE_SESSLOGOFF;
AE_SESSLOGON |ae_so_compname D|ae_so_username D|ae_so_privilege D
AE_SESSPWERR |ae_sp_compname D|ae_sp_username D typedef struct
_AE_SESSPWERR { DWORD ae_sp_compname; DWORD ae_sp_username; }
AE_SESSPWERR,*PAE_SESSPWERR,*LPAE_SESSPWERR;
AE_SRVSTATUS |ae_sv_status D
AE_UASMOD |ae_um_compname D|ae_um_username D|ae_um_resname D|ae_um_rectype
D|ae_um_action D|ae_um_datalen D typedef struct _AE_UASMOD { DWORD
ae_um_compname; DWORD ae_um_username; DWORD ae_um_resname; DWORD
ae_um_rectype; DWORD ae_um_action; DWORD ae_um_datalen; }
AE_UASMOD,*PAE_UASMOD,*LPAE_UASMOD;
AEP typedef struct AEPHDR { USHORT AEP_func; // function; see
below USHORT AEP_result; // result; set to zero if successful; see
below ULONG AEP_ddb; // address of DDB UCHAR
AEP_lgn; // current load group number (from DVT) UCHAR
AEP_align[3]; // reserved; don't use } AEPHDR, *PAEPHDR
AEP_assoc_dcb typedef struct AEP_assoc_dcb { struct AEPHDR
AEP_a_d_hdr; // AEP_ASSOCIATE_DCB PVOID AEP_a_d_pdcb; //
address of physical DCB ULONG AEP_a_d_drives; // bitmap of
associated logical drives } AEP_assoc_dcb, *PAEP_assoc_dcb
AEP_bi_uninit typedef struct AEP_bi_uninit { struct AEPHDR AEP_bi_u_hdr;
// Standard Header } AEP_bi_uninit, *PAEP_bi_uninit
AEP_boot_done typedef struct AEP_boot_done { struct AEPHDR AEP_b_d_hdr;
// AEP_BOOT_COMPLETE } AEP_boot_done, *PAEP_boot_done
AEP_dcb_config typedef struct AEP_dcb_config { struct AEPHDR
AEP_d_c_hdr; // Standard Header ULONG AEP_d_c_dcb; // 32-bit ptr to DCB
} AEP_dcb_config, *PAEP_dcb_config
AEP_dcb_unconfig typedef struct AEP_dcb_unconfig { struct AEPHDR
AEP_d_u_hdr; // Standard Header ULONG AEP_d_u_dcb; // 32-bit offset of
DCB } AEP_dcb_unconfig, *PAEP_dcb_unconfig
AEP_dcb_unconfig_pend typedef struct AEP_dcb_unconfig_pend { /* */
struct AEPHDR AEP_d_u_p_hdr; // AEP_PEND_UNCONFIG_DCB ULONG
AEP_d_u_p_dcb; // 32-bit offset of DCB } AEP_dcb_unconfig_pend,
*PAEP_dcb_unconfig_pend
AEP_dot_command typedef struct AEP_dot_command { /* */ struct
AEPHDR AEP_i_t_o_hdr; // Standard Header UCHAR AEP_d_c_flags;
// flags; see below PVOID AEP_d_c_pkeyword; // address of keyword
string; see below UCHAR AEP_d_c_key_len; // length of keyword; see
below ULONG AEP_d_c_num_1; // first numeric parameter ULONG
AEP_d_c_num_2; // second numeric parameter ULONG
AEP_d_c_num_3; // third numeric parameter } AEP_dot_command,
*PAEP_dot_command
AEP_drive_refresh typedef struct AEP_drive_refresh { struct AEPHDR
AEP_d_r_hdr; // AEP_REFRESH_DRIVE ULONG AEP_d_r_drive; //
drive number } AEP_drive_refresh, *PAEP_drive_refresh
AEP_inquiry_device typedef struct AEP_inquiry_device { struct AEPHDR
AEP_i_d_hdr; // Standard Header ULONG AEP_i_d_dcb; //
address of DCB } AEP_inquiry_device, *PAEP_inquiry_device
AEP_iop_timeout_occurred typedef struct AEP_iop_timeout_occurred {
struct AEPHDR AEP_i_t_o_hdr; // Standard Header ULONG
AEP_i_t_o_iop; // address of IOP that timed out }
AEP_iop_timeout_occurred, *PAEP_iop_timeout_occurred
AEP_lock_dcb typedef struct AEP_lock_dcb { struct AEPHDR
AEP_d_l_hdr; // AEP_DCB_LOCK PVOID AEP_d_l_pdcb; // address
of logical DCB ULONG AEP_d_l_drives; // bitmap of logical
drives UCHAR AEP_d_l_designtr; // designator UCHAR
AEP_d_l_align[3]; // reserved; don't use } AEP_lock_dcb, *PAEP_lock_dcb
AEP_mnt_notify typedef struct AEP_mnt_notify { struct AEPHDR
AEP_m_n_hdr; // AEP_MOUNT_NOTIFY PVOID AEP_m_n_pvrp; // VRP
of drive ULONG AEP_m_n_drivemap; // bitmap of child volumes
ULONG AEP_m_n_drive; // drive number of drive just mounted
ULONG AEP_m_n_effective_drive; // effective drive number ULONG
AEP_m_n_actual_drive; // actual drive number } AEP_mnt_notify,
*PAEP_mnt_notify
AEP_rm_handoff typedef struct AEP_rm_handoff { struct AEPHDR
AEP_r_m_h_hdr; // AEP_REAL_MODE_HANDOFF } AEP_rm_handoff,
*PAEP_rm_handoff
AEP_sys_crit_shutdown typedef struct AEP_sys_crit_shutdown { struct
AEPHDR AEP_s_c_s_hdr; // AEP_SYSTEM_CRIT_SHUTDOWN }
AEP_sys_crit_shutdown, *PAEP_sys_crit_shutdown
AEP_sys_shutdown typedef struct AEP_sys_shutdown { struct AEPHDR
AEP_s_s_hdr; // AEP_SYSTEM_SHUTDOWN } AEP_sys_shutdown,
*PAEP_sys_shutdown
AEP_vrp_create_destroy typedef struct AEP_vrp_create_destroy { struct
AEPHDR AEP_v_cd_hdr; // AEP_CREATE_VRP or AEP_DESTROY_VRP PVOID
AEP_v_cd_pvrp; // address of VRP ULONG
AEP_v_cd_drive; // drive number } AEP_vrp_create_destroy,
*PAEP_vrp_create_destroy
AFPROTOCOLS typedef struct _AFPROTOCOLS { INT iAddressFamily; INT
iProtocol; } AFPROTOCOLS, *PAFPROTOCOLS, *LPAFPROTOCOLS;
ALLOCATOR_PROPERTIES typedef struct _AllocatorProperties { long
cBuffers long cbBuffer long cbAlign long cbPrefix ; }
ALLOCATOR_PROPERTIES
ALLOCATOR_PROPERTIES_EX typedef struct _ALLOCATOR_PROPERTIES_EX { long
cBuffers; long cbBuffer; long cbAlign; long cbPrefix; GUID
MemoryType; GUID BusType; PIPE_STATE State; PIPE_TERMINATION Input;
PIPE_TERMINATION Output; ULONG Strategy; ULONG Flags; ULONG Weight;
KS_LogicalMemoryType LogicalMemoryType; PIPE_ALLOCATOR_PLACE
AllocatorPlace; PIPE_DIMENSIONS Dimensions; KS_FRAMING_RANGE
PhysicalRange; IKsAllocatorEx* PrevSegment; ULONG CountNextSegments;
IKsAllocatorEx** NextSegments; ULONG InsideFactors; ULONG NumberPins; }
ALLOCATOR_PROPERTIES_EX, *PALLOCATOR_PROPERTIES_EX
ALTTABINFO typedef struct { DWORD cbSize int cItems int cColumns int
cRows int iColFocus int iRowFocus int cxItem int cyItem POINT ptStart
; } ALTTABINFO, *PALTTABINFO, *LPALTTABINFO
AM_DVD_RENDERSTATUS typedef struct { HRESULT hrVPEStatus BOOL
bDVDVolInvalid BOOL bDVDVolUnknown BOOL bNoLine21In BOOL bNoLine21Out
int iNumStreams int iNumStreamsFailed DWORD dwFailedStreamsFlag ; }
AM_DVD_RENDERSTATUS
AM_MEDIA_TYPE typedef struct _MediaType{ GUID majortype GUID subtype
BOOL bFixedSizeSamples BOOL bTemporalCompression ULONG lSampleSize GUID
formattype IUnknown *pUnk ULONG cbFormat /* [size_is] */ BYTE __RPC_FAR
*pbFormat ; } AM_MEDIA_TYPE
AM_SAMPLE2_PROPERTIES typedef struct tagAM_SAMPLE2_PROPERTIES { DWORD
cbData DWORD dwTypeSpecificFlags DWORD dwSampleFlags LONG lActual
REFERENCE_TIME tStart REFERENCE_TIME tStop DWORD dwStreamId
AM_MEDIA_TYPE *pMediaType BYTE *pbBuffer LONG cbBuffer ; }
AM_SAMPLE2_PROPERTIES
AM_STREAM_INFO typedef struct { REFERENCE_TIME tStart REFERENCE_TIME
tStop DWORD dwStartCookie DWORD dwStopCookie DWORD dwFlags ; }
AM_STREAM_INFO
AM_WMT_EVENT_DATA typedef struct { HRESULT hrStatus void * pData //
event data } AM_WMT_EVENT_DATA
AM_WST_PAGE typedef struct _AM_WST_PAGE { DWORD dwPageNr DWORD
dwSubPageNr BYTE* pucPageData ; } AM_WST_PAGE, *PAM_WST_PAGE
AMOVIESETUP_FILTER typedef struct _AMOVIESETUP_FILTER{ const CLSID *
clsID LPWSTR strName DWORD dwMerit UINT nPins LPAMOVIESETUP_PIN lpPin
; } AMOVIESETUP_FILTER
AMOVIESETUP_MEDIATYPE typedef struct _AMOVIESETUP_MEDIATYPE{ const CLSID
* clsMajorType const CLSID * clsMinorType ; } AMOVIESETUP_MEDIATYPE
AMOVIESETUP_PIN typedef struct _AMOVIESETUP_PIN{ LPWSTR strName BOOL
bRendered BOOL bOutput BOOL bZero BOOL bMany const CLSID *
clsConnectsToFilter LPWSTR strConnectsToPin UINT nMediaTypes
LPAMOVIESETUP_MEDIATYPE lpMediaType ; } AMOVIESETUP_PIN
AMVABeginFrameInfo typedef struct _tag_AMVABeginFrameInfo{ DWORD
dwDestSurfaceIndex LPVOID pInputData DWORD dwSizeInputData LPVOID
pOutputData DWORD dwSizeOutputData ; } AMVABeginFrameInfo,
*LPAMVABeginFrameInfo
AMVABUFFERINFO typedef struct _tag_AMVABUFFERINFO{ DWORD dwTypeIndex
DWORD dwBufferIndex DWORD dwDataOffset DWORD dwDataSize ; }
AMVABUFFERINFO, *LPAMVABUFFERINFO
AMVACompBufferInfo typedef struct _tag_AMVACompBufferInfo{ DWORD
dwNumCompBuffers DWORD dwWidthToCreate DWORD dwHeightToCreate DWORD
dwBytesToAllocate DDSCAPS2 ddCompCaps DDPIXELFORMAT ddPixelFormat ; }
AMVACompBufferInfo, *LPAMVACompBufferInfo
AMVAEndFrameInfo typedef struct _tag_AMVAEndFrameInfo{ DWORD
dwSizeMiscData LPVOID pMiscData ; } AMVAEndFrameInfo, *LPAMVAEndFrameInfo
AMVAInternalMemInfo typedef struct _tag_AMVAInternalMemInfo{ DWORD
dwScratchMemAlloc ; } AMVAInternalMemInfo, *LPAMVAInternalMemInfo
AMVAUncompBufferInfo typedef struct _tag_AMVAUncompBufferInfo{ DWORD
dwMinNumSurfaces DWORD dwMaxNumSurfaces DDPIXELFORMAT
ddUncompPixelFormat ; } AMVAUncompBufferInfo, *LPAMVAUncompBufferInfo
AMVAUncompDataInfo typedef struct _tag_AMVAUncompDataInfo{ DWORD
dwUncompWidth DWORD dwUncompHeight DDPIXELFORMAT ddUncompPixelFormat ; }
AMVAUncompDataInfo, *LPAMVAUncompDataInfo
AMVPDATAINFO typedef struct _AMVPDATAINFO{ DWORD dwSize DWORD
dwMicrosecondsPerField AMVPDIMINFO amvpDimInfo DWORD dwPictAspectRatioX
DWORD dwPictAspectRatioY BOOL bEnableDoubleClock BOOL bEnableVACT BOOL
bDataIsInterlaced LONG lHalfLinesOdd BOOL bFieldPolarityInverted DWORD
dwNumLinesInVREF LONG lHalfLinesEven DWORD dwReserved1 ; } AMVPDATAINFO,
*LPAMVPDATAINFO
AMVPDIMINFO typedef struct _AMVPDIMINFO{ DWORD dwFieldWidth DWORD
dwFieldHeight DWORD dwVBIWidth DWORD dwVBIHeight RECT rcValidRegion ; }
AMVPDIMINFO, *LPAMVPDIMINFO
AMVPSIZE typedef struct _AMVPSIZE{ DWORD dwWidth DWORD dwHeight ; }
AMVPSIZE, *LPAMVPSIZE
ANALOGVIDEOINFO typedef struct tagAnalogVideoInfo { RECT rcSource RECT
rcTarget DWORD dwActiveWidth DWORD dwActiveHeight REFERENCE_TIME
AvgTimePerFrame ; } ANALOGVIDEOINFO
ANDEXP typedef struct _ANDEXP { DWORD nPatternMatches; PATTERNMATCH
PatternMatch[MAX_PATTERNS]; } ANDEXP, *LPANDEXP;
ANIMATEINFO typedef struct { DWORD cbSize; UINT uSpeedPct; UINT
uPeriodCB; UINT fuFlags; LPARAM lParam; DWORD dwReserved; } ANIMATEINFO;
ANIMATIONINFO |cbSize D|iMinAnimate D typedef struct tagANIMATIONINFO {
UINT cbSize; int iMinAnimate; } ANIMATIONINFO, *LPANIMATIONINFO;
ANSI_STRING typedef struct _STRING { USHORT Length; USHORT
MaximumLength; PCHAR Buffer; } ANSI_STRING *PANSI_STRING
API_VERSION |MajorVersion W|MinorVersion W|Revision W|Reserved W typedef
struct API_VERSION { USHORT MajorVersion; USHORT MinorVersion; USHORT
Revision; USHORT Reserved; } API_VERSION, *LPAPI_VERSION;
APM_CAPABILITIES typedef struct APM_CAPABILITIES_S { WORD Capabilities;
BYTE BatteryCount; BYTE Reserved; } APM_CAPABILITIES, *PAPM_CAPABILITIES
APPBARDATA |cbSize D|hwnd D|uCallbackMessage D|uEdge D|rc.left D|rc.top
D|rc.right D|rc.bottom D|lParam D typedef struct _AppBarData { DWORD
cbSize HWND hWnd UINT uCallbackMessage UINT uEdge RECT rc LPARAM
lParam ; } APPBARDATA, *PAPPBARDATA
APPCATEGORYINFO typedef struct _APPCATEGORYINFO { LCID Locale LPWSTR
pszDescription GUID AppCategoryID ; } APPCATEGORYINFO
APPCATEGORYINFOLIST typedef struct _APPCATEGORYINFOLIST { DWORD
cCategory APPCATEGORYINFO *pCategoryInfo ; } APPCATEGORYINFOLIST
APPDETAIL |AppID.Data1 D|AppID.Data2 W|AppID.Data3 W|AppID.Data4 B
8|cClasses D|prgClsIdList D|cTypeLibIds D|prgTypeLibIdList D|cServers
D|prgServerNames D
APPINFODATA typedef struct { DWORD cbSize DWORD dwMask LPWSTR
pszDisplayName LPWSTR pszVersion LPWSTR pszProductID LPWSTR
pszRegisteredOwner LPWSTR pszRegisteredCompany LPWSTR pszLanguage
LPWSTR pszSupportUrl LPWSTR pszLanguage LPWSTR pszSupportTelephone
LPWSTR pszHelpLink LPWSTR pszInstallLocation LPWSTR pszInstallSource
LPWSTR pszInstallDate LPWSTR pszContact LPWSTR pszComments LPWSTR
pszImage LPWSTR pszReadmeUrl LPWSTR pszUpdateInfoUrl ; } APPINFODATA
arbitfree_s struct arbitfree_s { PVOID *af_PointerToInfo; // the
arbitrator info ULONG af_SizeOfInfo; // size of the info }
ARP_SEND_REPLY typedef struct arp_send_reply { IPAddr DestAddress;
IPAddr SrcAddress; } ARP_SEND_REPLY, *PARP_SEND_REPLY;
ARRAYDESC typedef struct _tagARRAYDESC { TYPEDESC tdescElem unsigned
short cDims SAFEARRAYBOUND rgbounds[1] ; } ARRAYDESC
AsnAny typedef struct { BYTE asnType union { AsnInteger32 number
AsnUnsigned32 unsigned32 AsnCounter64 counter64 AsnOctetString string
AsnBits bits AsnObjectIdentifier object AsnSequence sequence
AsnIPAdress address AsnCounter32 counter32 AsnGauge32 gauge
AsnTimeTicks ticks AsnOpaque arbitrary ; } asnValue ; } AsnAny
AsnCounter64 typedef struct { ULONG LowPart ULONG HighPart ; }
AsnCounter64
AsnObjectIdentifier typedef struct { UINT idLength UINT * ids ; }
AsnObjectIdentifier
AsnOctetString typedef struct { BYTE * stream UINT length BOOL
dynamic ; } AsnOctetString
ASSEMBLY_FILE_DETAILED_INFORMATION typedef struct
_ASSEMBLY_FILE_DETAILED_INFORMATION { DWORD ulFlags; DWORD
ulFilenameLength; DWORD ulPathLength; PCWSTR lpFileName; PCWSTR
lpFilePath; } ASSEMBLY_FILE_DETAILED_INFORMATION,
*PASSEMBLY_FILE_DETAILED_INFORMATION;
AT_ENUM |JobId D|JobTime D|DaysOfMonth D|DaysOfWeek W|Flags W|Command
D typedef struct _AT_ENUM { DWORD JobId; DWORD_PTR JobTime; DWORD
DaysOfMonth; UCHAR DaysOfWeek; UCHAR Flags; LPWSTR Command; } AT_ENUM,
*PAT_ENUM, *LPAT_ENUM;
AT_INFO |JobTime D|DaysOfMonth D|DaysOfWeek W|Flags W|Command D typedef
struct _AT_INFO { DWORD_PTR JobTime; DWORD DaysOfMonth; UCHAR
DaysOfWeek; UCHAR Flags; LPWSTR Command; } AT_INFO, *PAT_INFO,
*LPAT_INFO;
ATA_PASS_THROUGH_DIRECT typedef struct _ATA_PASS_THROUGH_DIRECT { USHORT
Length; USHORT AtaFlags; UCHAR PathId; UCHAR TargetId; UCHAR Lun;
UCHAR ReservedAsUchar; ULONG DataTransferLength; ULONG TimeOutValue;
ULONG ReservedAsUlong; PVOID DataBuffer; UCHAR PreviousTaskFile[8];
UCHAR CurrentTaskFile[8]; }ATA_PASS_THROUGH_DIRECT,
*PATA_PASS_THROUGH_DIRECT
ATA_PASS_THROUGH_EX typedef struct _ATA_PASS_THROUGH_EX { USHORT
Length; USHORT AtaFlags; UCHAR PathId; UCHAR TargetId; UCHAR Lun;
UCHAR ReservedAsUchar; ULONG DataTransferLength; ULONG TimeOutValue;
ULONG ReservedAsUlong; ULONG_ PTR DataBufferOffset; UCHAR
PreviousTaskFile[8]; UCHAR CurrentTaskFile[8]; }ATA_PASS_THROUGH_EX,
*PATA_PASS_THROUGH_EX
ATM_AAL_OOB_INFO typedef struct _ATM_AAL_OOB_INFO { ATM_AAL_TYPE
AalType; union { struct _ATM_AAL5_INFO { BOOLEAN CellLossPriority;
UCHAR UserToUserIndication; UCHAR CommonPartIndicator; } ATM_AAL5_INFO;
struct _ATM_AAL0_INFO { BOOLEAN CellLossPriority; UCHAR
PayLoadTypeIdentifier; } ATM_AAL0_INFO; }; } ATM_AAL_OOB_INFO,
*PATM_AAL_OOB_INFO
ATM_ADDRESS typedef struct _ATM_ADDRESS { ATM_ADDRESSTYPE AddressType;
ULONG NumberOfDigits; UCHAR Address[ATM_ADDRESS_LENGTH]; } ATM_ADDRESS,
*PATM_ADDRESS
ATM_BHLI typedef struct { DWORD HighLayerInfoType; DWORD
HighLayerInfoLength; UCHAR HighLayerInfo[8]; } ATM_BHLI;
ATM_BHLI_IE typedef struct _ATM_BHLI_IE { ULONG HighLayerInfoType;
ULONG HighLayerInfoLength; UCHAR HighLayerInfo[8]; } ATM_BHLI_IE,
*PATM_BHLI_IE
ATM_BLLI typedef struct { DWORD Layer2Protocol; DWORD
Layer2UserSpecifiedProtocol; DWORD Layer3Protocol; DWORD
Layer3UserSpecifiedProtocol; DWORD Layer3IPI; UCHAR SnapID[5]; }
ATM_BLLI;
ATM_BLLI_IE typedef struct _ATM_BLLI_IE { ULONG Layer2Protocol; UCHAR
Layer2Mode; UCHAR Layer2WindowSize; ULONG Layer2UserSpecifiedProtocol;
ULONG Layer3Protocol; UCHAR Layer3Mode; UCHAR Layer3DefaultPacketSize;
UCHAR Layer3PacketWindowSize; ULONG Layer3UserSpecifiedProtocol; ULONG
Layer3IPI; UCHAR SnapId[5]; } ATM_BLLI_IE, *PATM_BLLI_IE
ATM_BROADBAND_BEARER_CAPABILITY_IE typedef struct
_ATM_BROADBAND_BEARER_CAPABILITY_IE { UCHAR BearerClass; UCHAR
TrafficType; UCHAR TimingRequirements; UCHAR ClippingSusceptability;
UCHAR UserPlaneConnectionConfig; } ATM_BROADBAND_BEARER_CAPABILITY_IE,
*PATM_BROADBAND_BEARER_CAPABILITY_IE
ATM_BROADBAND_SENDING_COMPLETE_IE typedef struct
_ATM_BROADBAND_SENDING_COMPLETE_IE { UCHAR SendingComplete; }
ATM_BROADBAND_SENDING_COMPLETE_IE, *PATM_BROADBAND_SENDING_COMPLETE_IE
ATM_CALLING_PARTY_NUMBER_IE typedef struct _ATM_CALLING_PARTY_NUMBER_IE
{ ATM_ADDRESS Number; UCHAR PresentationIndication; UCHAR
ScreeningIndicator; } ATM_CALLING_PARTY_NUMBER_IE,
*PATM_CALLING_PARTY_NUMBER_IE
ATM_CAUSE_IE typedef struct _ATM_CAUSE_IE { UCHAR Location; UCHAR
Cause; UCHAR DiagnosticsLength; UCHAR Diagnostics[4]; } ATM_CAUSE_IE,
*PATM_CAUSE_IE
ATM_FLOW_PARAMETERS typedef struct _ATM_FLOW_PARAMETERS {
ATM_SERVICE_CATEGORY ServiceCategory; ULONG AverageCellRate; ULONG
PeakCellRate; ULONG MinimumCellRate; ULONG InitialCellRate; ULONG
BurstLengthCells; ULONG MaxSduSize; ULONG TransientBufferExposure;
ULONG CumulativeRMFixedRTT; UCHAR RateIncreaseFactor; UCHAR
RateDecreaseFactor; USHORT ACRDecreaseTimeFactor; UCHAR
MaximumCellsPerForwardRMCell; UCHAR MaximumForwardRMCellInterval; UCHAR
CutoffDecreaseFactor; UCHAR Reserved1; ULONG MissingRMCellCount; ULONG
Reserved2; ULONG Reserved3; } ATM_FLOW_PARAMETERS, *PATM_FLOW_PARAMETERS
ATM_MEDIA_PARAMETERS typedef struct _ATM_MEDIA_PARAMETERS { ATM_VPIVCI
ConnectionId; ATM_AAL_TYPE AALType; ULONG CellDelayVariationCLP0; ULONG
CellDelayVariationCLP1; ULONG CellLossRatioCLP0; ULONG
CellLossRatioCLP1; ULONG CellTransferDelayCLP0; ULONG
CellTransferDelayCLP1; ULONG DefaultCLP; ATM_FLOW_PARAMETERS Transmit;
ATM_FLOW_PARAMETERS Receive; } ATM_MEDIA_PARAMETERS,
*PATM_MEDIA_PARAMETERS
ATM_PVC_SAP typedef struct _ATM_PVC_SAP { ATM_BLLI_IE Blli; ATM_BHLI_IE
Bhli; } ATM_PVC_SAP, *PATM_PVC_SAP
ATM_QOS_CLASS_IE typedef struct _ATM_QOS_CLASS_IE { UCHAR
QOSClassForward; UCHAR QOSClassBackward; } ATM_QOS_CLASS_IE,
*PATM_QOS_CLASS_IE
ATM_RAW_IE typedef struct _ATM_RAW_IE { ULONG RawIELength; ULONG
RawIEType; UCHAR RawIEValue[1]; } ATM_RAW_IE, *PATM_RAW_IE
ATM_SAP typedef struct _ATM_SAP { ATM_BLLI_IE Blli; ATM_BHLI_IE Bhli;
ULONG NumberOfAddresses; UCHAR Addresses[1]; } ATM_SAP, *PATM_SAP
ATM_TRAFFIC_DESCRIPTOR typedef struct _ATM_TRAFFIC_DESCRIPTOR { ULONG
PeakCellRateCLP0; ULONG PeakCellRateCLP01; ULONG
SustainableCellRateCLP0; ULONG SustainableCellRateCLP01; ULONG
MaximumBurstSizeCLP0; ULONG MaximumBurstSizeCLP01; BOOLEAN BestEffort;
BOOLEAN Tagging; } ATM_TRAFFIC_DESCRIPTOR, *PATM_TRAFFIC_DESCRIPTOR
ATM_TRAFFIC_DESCRIPTOR_IE typedef struct _ATM_TRAFFIC_DESCRIPTOR_IE {
ATM_TRAFFIC_DESCRIPTOR ForwardTD; ATM_TRAFFIC_DESCRIPTOR BackwardTD; }
ATM_TRAFFIC_DESCRIPTOR_IE, *PATM_TRAFFIC_DESCRIPTOR_IE
ATM_TRANSIT_NETWORK_SELECTION_IE typedef struct
_ATM_TRANSIT_NETWORK_SELECTION_IE { UCHAR TypeOfNetworkId; UCHAR
NetworkIdPlan; UCHAR NetworkIdLength; UCHAR NetworkId[1]; }
ATM_TRANSIT_NETWORK_SELECTION_IE, *PATM_TRANSIT_NETWORK_SELECTION_IE
ATM_VPIVCI typedef struct _ATM_VPIVCI { ULONG Vpi; ULONG Vci; }
ATM_VPIVCI, *PATM_VPIVCI
ATTRIBUTE_INFO_1 typedef struct _ATTRIBUTE_INFO_1 { DWORD
dwJobNumberOfPagesPerSide; DWORD dwDrvNumberOfPagesPerSide; DWORD
dwNupBorderFlags; DWORD dwJobPageOrderFlags; DWORD dwDrvPageOrderFlags;
DWORD dwJobNumberOfCopies; DWORD dwDrvNumberOfCopies; }
ATTRIBUTE_INFO_1, *PATTRIBUTE_INFO_1
ATTRIBUTE_INFO_2 typedef struct _ATTRIBUTE_INFO_2 { DWORD
dwJobNumberOfPagesPerSide; DWORD dwDrvNumberOfPagesPerSide; DWORD
dwNupBorderFlags; DWORD dwJobPageOrderFlags; DWORD dwDrvPageOrderFlags;
DWORD dwJobNumberOfCopies; DWORD dwDrvNumberOfCopies; DWORD
dwColorOptimization; } ATTRIBUTE_INFO_2, *PATTRIBUTE_INFO_2
ATTRIBUTE_INFO_3 typedef struct _ATTRIBUTE_INFO_3 { DWORD
dwJobNumberOfPagesPerSide; DWORD dwDrvNumberOfPagesPerSide; DWORD
dwNupBorderFlags; DWORD dwJobPageOrderFlags; DWORD dwDrvPageOrderFlags;
DWORD dwJobNumberOfCopies; DWORD dwDrvNumberOfCopies; DWORD
dwColorOptimization; short dmPrintQuality; short dmYResolution; }
ATTRIBUTE_INFO_3, *PATTRIBUTE_INFO_3
AUDIO_STREAM_CONFIG_CAPS typedef struct _AUDIO_STREAM_CONFIG_CAPS { GUID
guid ULONG MinimumChannels ULONG MaximumChannels ULONG
ChannelsGranularity ULONG MinimumBitsPerSample ULONG
MaximumBitsPerSample ULONG BitsPerSampleGranularity ULONG
MinimumSampleFrequency ULONG MaximumSampleFrequency ULONG
SampleFrequencyGranularity ; } AUDIO_STREAM_CONFIG_CAPS
AUDIT_ENTRY |ae_len D|ae_reserved D|ae_time D|ae_type D|ae_data_offset
D|ae_data_size D typedef struct _AUDIT_ENTRY { DWORD ae_len; DWORD
ae_reserved; DWORD ae_time; DWORD ae_type; DWORD ae_data_offset; DWORD
ae_data_size; } AUDIT_ENTRY, *PAUDIT_ENTRY, *LPAUDIT_ENTRY;
AUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_PARA typedef struct
_AUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_PARA { DWORD cbSize; DWORD
dwRegPolicySettings; PCMSG_SIGNER_INFO pSignerInfo; }
AUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_PARA,
*PAUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_PARA;
AUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_STATUS typedef struct
_AUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_STATUS { DWORD cbSize; BOOL
fCommercial; } AUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_STATUS,
*PAUTHENTICODE_EXTRA_CERT_CHAIN_POLICY_STATUS;
AUTHENTICODE_TS_EXTRA_CERT_CHAIN_POLICY_PARA typedef struct
_AUTHENTICODE_TS_EXTRA_CERT_CHAIN_POLICY_PARA { DWORD cbSize; DWORD
dwRegPolicySettings; BOOL fCommercial; }
AUTHENTICODE_TS_EXTRA_CERT_CHAIN_POLICY_PARA,
*PAUTHENTICODE_TS_EXTRA_CERT_CHAIN_POLICY_PARA;
AUTHZ_ACCESS_REPLY typedef struct _AUTHZ_ACCESS_REPLY { DWORD
ResultListLength; PACCESS_MASK GrantedAccessMask; PDWORD
SaclEvaluationResults; PDWORD Error; } AUTHZ_ACCESS_REPLY,
*PAUTHZ_ACCESS_REPLY;
AUTHZ_ACCESS_REPLY typedef struct _AUTHZ_ACCESS_REPLY { DWORD
ResultListLength; PACCESS_MASK GrantedAccessMask; PDWORD
SaclEvaluationResults; PDWORD Error; } AUTHZ_ACCESS_REPLY,
*PAUTHZ_ACCESS_REPLY;
AUTHZ_ACCESS_REQUEST typedef struct _AUTHZ_ACCESS_REQUEST { ACCESS_MASK
DesiredAccess; PSID PrincipalSelfSid; POBJECT_TYPE_LIST ObjectTypeList;
DWORD ObjectTypeListLength; PVOID OptionalArguments; }
AUTHZ_ACCESS_REQUEST, *PAUTHZ_ACCESS_REQUEST;
AUTHZ_ACCESS_REQUEST typedef struct _AUTHZ_ACCESS_REQUEST { ACCESS_MASK
DesiredAccess; PSID PrincipalSelfSid; POBJECT_TYPE_LIST
ObjectTypeList; DWORD ObjectTypeListLength; PVOID OptionalArguments; }
AUTHZ_ACCESS_REQUEST, *PAUTHZ_ACCESS_REQUEST;
AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET typedef struct
_AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET { PWSTR szObjectTypeName;
DWORD dwOffset; } AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET,
*PAUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET;
AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET typedef struct
_AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET { PWSTR szObjectTypeName;
DWORD dwOffset; } AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET,
*PAUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET;
AUTHZ_SOURCE_SCHEMA_REGISTRATION typedef struct
_AUTHZ_SOURCE_SCHEMA_REGISTRATION { DWORD dwFlags; PWSTR
szEventSourceName; PWSTR szEventMessageFile; PWSTR
szEventSourceXmlSchemaFile; PWSTR szEventAccessStringsFile; PWSTR
szExecutableImagePath; PVOID pReserved; DWORD dwObjectTypeNameCount;
AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET
ObjectTypeNames[ANYSIZE_ARRAY]; } AUTHZ_SOURCE_SCHEMA_REGISTRATION,
*PAUTHZ_SOURCE_SCHEMA_REGISTRATION;
AUTHZ_SOURCE_SCHEMA_REGISTRATION typedef struct
_AUTHZ_SOURCE_SCHEMA_REGISTRATION { DWORD dwFlags; PWSTR
szEventSourceName; PWSTR szEventMessageFile; PWSTR
szEventSourceXmlSchemaFile; PWSTR szEventAccessStringsFile; PWSTR
szExecutableImagePath; PVOID pReserved; DWORD dwObjectTypeNameCount;
AUTHZ_REGISTRATION_OBJECT_TYPE_NAME_OFFSET ObjectTypeNames[ANYSIZE_ARRAY];
} AUTHZ_SOURCE_SCHEMA_REGISTRATION, *PAUTHZ_SOURCE_SCHEMA_REGISTRATION;
AUTO_PROXY_SCRIPT_BUFFER typedef struct { DWORD dwStructSize; LPSTR
lpszScriptBuffer; DWORD dwScriptBufferSize; } AUTO_PROXY_SCRIPT_BUFFER;
AUTO_SCROLL_DATA typedef struct _AUTO_SCROLL_DATA { int iNextSample
DWORD dwLastScroll BOOL bFull POINT pts[NUM_POINTS] DWORD
dwTimes[NUM_POINTS] ; } AUTO_SCROLL_DATA
AutoProxyHelperFunctions typedef struct { const struct
AutoProxyHelperVtbl * lpVtbl; } AutoProxyHelperFunctions;
AutoProxyHelperVtbl typedef struct { BOOL (* IsResolvable) ( LPSTR
lpszHost ); DWORD (* GetIPAddress) ( LPSTR lpszIPAddress, LPDWORD
lpdwIPAddressSize ); BOOL (* ResolveHostName) ( LPSTR lpszHostName, LPSTR
lpszIPAddress, LPDWORD lpdwIPAddressSize ); void (* IsInNet) ( LPSTR
lpszIPAddress, LPSTR lpszDest, LPSTR lpszMask ); } AutoProxyHelperVtbl;
AUXCAPS |wMid W|wPid W|vDriverVersion D|szPname B MAXPNAMELEN|wTechnology
W|dwSupport D typedef struct auxcaps_tag { UINT wMid; UINT wPid;
VERSION vDriverVersion; char szPname[MAXPNAMELEN]; UINT wTechnology;
DWORD dwSupport; } AUXCAPS
AUXCAPSA |wMid W|wPid W|vDriverVersion D|szPname B MAXPNAMELEN|wTechnology
W|dwSupport D typedef struct { WORD wMid; WORD wPid; MMVERSION
vDriverVersion; CHAR szPname[MAXPNAMELEN]; WORD wTechnology; WORD
wReserved1; DWORD dwSupport; } AUXCAPSA;
AV_61883_REQUEST typedef struct _AV_61883_REQUEST { ULONG Function;
ULONG Version; ULONG Flags; union { GET_UNIT_INFO GetUnitInfo;
SET_UNIT_INFO SetUnitInfo; CMP_GET_PLUG_HANDLE GetPlugHandle;
CMP_GET_PLUG_STATE GetPlugState; CMP_CONNECT Connect; CMP_DISCONNECT
Disconnect; CIP_ATTACH_FRAME AttachFrame; CIP_CANCEL_FRAME CancelFrame;
CIP_TALK Talk; CIP_LISTEN Listen; CIP_STOP Stop; FCP_SEND_REQUEST
SendRequest; FCP_GET_RESPONSE GetResponse; FCP_GET_REQUEST GetRequest;
FCP_SEND_RESPONSE SendResponse; SET_FCP_NOTIFY SetFcpNotify;
CMP_CREATE_PLUG CreatePlug; CMP_DELETE_PLUG DeletePlug; CMP_SET_PLUG
SetPlug; BUS_RESET_NOTIFY BusResetNotify; SET_UNIT_DIRECTORY
SetUnitDirectory; ....CMP_MONITOR_PLUGS MonitorPlugs; } ; }
AV_61883_REQUEST, *PAV_61883_REQUEST
AV_PCR typedef struct _AV_PCR { union { OPCR oPCR; IPCR iPCR; ULONG
ulongData; }; } AV_PCR, *PAV_PCR
AVC_COMMAND_IRB typedef struct _AVC_COMMAND_IRB { AVC_IRB Common; UCHAR
SubunitAddrFlag : 1; UCHAR AlternateOpcodesFlag : 1; UCHAR TimeoutFlag :
1; UCHAR RetryFlag : 1; union { UCHAR CommandType; UCHAR
ResponseCode; }; PUCHAR SubunitAddr; PUCHAR AlternateOpcodes;
LARGE_INTEGER Timeout; UCHAR Retries; UCHAR Opcode; ULONG
OperandLength; UCHAR Operands[MAX_AVC_OPERAND_BYTES]; NODE_ADDRESS
NodeAddress; ULONG Generation; } AVC_COMMAND_IRB, *PAVC_COMMAND_IRB
AVC_EXT_PLUG_COUNTS typedef struct _AVC_EXT_PLUG_COUNTS { OUT ULONG
ExtInputs; OUT ULONG ExtOutputs; } AVC_EXT_PLUG_COUNTS,
*PAVC_EXT_PLUG_COUNTS
AVC_IRB typedef struct _AVC_IRB { AVC_FUNCTION Function; } AVC_IRB,
*PAVC_IRB
AVC_MULTIFUNC_IRB typedef struct _AVC_MULTIFUNC_IRB { AVC_IRB Common;
union { AVC_PIN_COUNT PinCount; AVC_PIN_DESCRIPTOR PinDescriptor;
AVC_PRECONNECT_INFO PreConnectInfo; AVC_SETCONNECT_INFO SetConnectInfo;
AVC_PIN_ID PinId; AVC_EXT_PLUG_COUNTS ExtPlugCounts; AVC_UNIQUE_ID
UniqueID; AVC_PEER_DO_LOCATOR PeerLocator; AVC_PEER_DO_LIST PeerList;
AVC_SUBUNIT_INFO_BLOCK Subunits; }; } AVC_MULTIFUNC_IRB,
*PAVC_MULTIFUNC_IRB
AVC_PEER_DO_LIST typedef struct _AVC_PEER_DO_LIST { OUT ULONG Count;
OUT PDEVICE_OBJECT *Objects; } AVC_PEER_DO_LIST, *PAVC_PEER_DO_LIST
AVC_PEER_DO_LOCATOR typedef struct _AVC_PEER_DO_LOCATOR { IN
NODE_ADDRESS NodeAddress; IN ULONG Generation; OUT PDEVICE_OBJECT
DeviceObject; } AVC_PEER_DO_LOCATOR, *PAVC_PEER_DO_LOCATOR
AVC_PIN_COUNT typedef struct _AVC_PIN_COUNT { OUT ULONG PinCount; }
AVC_PIN_COUNT, *PAVC_PIN_COUNT
AVC_PIN_DESCRIPTOR typedef struct _AVC_PIN_DESCRIPTOR { IN ULONG PinId;
OUT KSPIN_DESCRIPTOR PinDescriptor; OUT PFNAVCINTERSECTHANDLER
IntersectHandler; OUT PVOID Context; } AVC_PIN_DESCRIPTOR,
*PAVC_PIN_DESCRIPTOR
AVC_PIN_ID typedef struct _AVC_PIN_ID { IN ULONG PinId; } AVC_PIN_ID,
*PAVC_PIN_ID
AVC_PRECONNECT_INFO typedef struct _AVC_PRECONNECT_INFO { IN ULONG PinId
OUT AVCPRECONNECTINFO ConnectInfo; } AVC_PRECONNECT_INFO,
*PAVC_PRECONNECT_INFO
AVC_SETCONNECT_INFO typedef struct _AVC_SETCONNECT_INFO { IN ULONG
PinId; IN AVCCONNECTINFO ConnectInfo; } AVC_SETCONNECT_INFO,
*PAVC_SETCONNECT_INFO
AVC_STREAM_REQUEST_BLOCK typedef struct _AVC_STREAM_REQUEST_BLOCK {
ULONG SizeOfThisBlock; ULONG Version; AVCSTRM_FUNCTION Function; ULONG
Flags; NTSTATUS Status; PVOID AVCStreamContext; PVOID Context1; PVOID
Context2; PVOID Context3; PVOID Context4; ULONG Reserved[4]; union
_tagCommandData { KSSTATE StreamState; AVCSTRM_OPEN_STRUCT OpenStruct;
AVCSTRM_BUFFER_STRUCT BufferStruct; } CommandData; }
AVC_STREAM_REQUEST_BLOCK, *PAVC_STREAM_REQUEST_BLOCK
AVC_SUBUNIT_ADDR_SPEC typedef struct _AVC_SUBUNIT_ADDR_SPEC { ULONG
Flags; UCHAR SubunitAddress[1]; } AVC_SUBUNIT_ADDR_SPEC,
*PAVC_SUBUNIT_ADDR_SPEC
AVC_SUBUNIT_INFO_BLOCK typedef struct _AVC_SUBUNIT_INFO_BLOCK { OUT
UCHAR Info[AVC_SUBUNITINFO_BYTES]; } AVC_SUBUNIT_INFO_BLOCK,
*PAVC_SUBUNIT_INFO_BLOCK
AVC_UNIQUE_ID typedef struct _AVC_UNIQUE_ID { OUT GUID DeviceID; }
AVC_UNIQUE_ID, *PAVC_UNIQUE_ID
AVCCONNECTINFO typedef struct _AVCCONNECTINFO { GUID DeviceID; UCHAR
SubunitAddress[AVCCONNECTINFO_MAX_SUBUNITADDR_LEN]; ULONG
SubunitPlugNumber; KSPIN_DATAFLOW DataFlow; HANDLE hPlug; ULONG
UnitPlugNumber; } AVCCONNECTINFO, *PAVCCONNECTINFO
AVCPRECONNECTINFO typedef struct _AVCPRECONNECTINFO { GUID DeviceID;
UCHAR SubunitAddress[AVCCONNECTINFO_MAX_SUBUNITADDR_LEN]; ULONG
SubunitPlugNumber; KSPIN_DATAFLOW DataFlow; ULONG Flags; ULONG
UnitPlugNumber; } AVCPRECONNECTINFO, *PAVCPRECONNECTINFO
AVCSTRM_BUFFER_STRUCT typedef struct _AVCSTRM_BUFFER_STRUCT { BOOL
ClockProvider; HANDLE ClockHandle; PKSSTREAM_HEADER StreamHeader; PVOID
FrameBuffer; PVOID Context; } AVCSTRM_BUFFER_STRUCT, *
PAVCSTRM_BUFFER_STRUCT
AVCSTRM_FORMAT_INFO typedef struct _AVCSTRM_FORMAT_INFO { ULONG
SizeOfThisBlock; AVCSTRM_FORMAT AVCStrmFormat; CIP_HDR1 cipHdr1;
CIP_HDR2_SYT cipHdr2; ULONG SrcPacketsPerFrame; ULONG FrameSize; ULONG
NumOfRcvBuffers; ULONG NumOfXmtBuffers; DWORD OptionFlags; ULONG
AvgTimePerFrame; ULONG BlockPeriod; ULONG Reserved[4]; }
AVCSTRM_FORMAT_INFO, * PAVCSTRM_FORMAT_INFO
AVCSTRM_OPEN_STRUCT typedef struct _AVCSTRM_OPEN_STRUCT { KSPIN_DATAFLOW
DataFlow; PAVCSTRM_FORMAT_INFO AVCFormatInfo; PVOID AVCStreamContext;
HANDLE hPlugLocal } AVCSTRM_OPEN_STRUCT, * PAVCSTRM_OPEN_STRUCT
AVICOMPRESSOPTIONS typedef struct { DWORD fccType; DWORD fccHandler;
DWORD dwKeyFrameEvery; DWORD dwQuality; DWORD dwBytesPerSecond; DWORD
dwFlags; LPVOID lpFormat; DWORD cbFormat; LPVOID lpParms; DWORD
cbParms; DWORD dwInterleaveEvery; } AVICOMPRESSOPTIONS
AVIFILEINFO typedef struct { DWORD dwMaxBytesPerSec; DWORD dwFlags;
DWORD dwCaps; DWORD dwStreams; DWORD dwSuggestedBufferSize; DWORD
dwWidth; DWORD dwHeight; DWORD dwScale; DWORD dwRate; DWORD dwLength;
DWORD dwEditCount; char szFileType[64]; } AVIFILEINFO
AVIMAINHEADER typedef struct _avimainheader { FOURCC fcc DWORD cb
DWORD dwMicroSecPerFrame DWORD dwMaxBytesPerSec DWORD
dwPaddingGranularity DWORD dwFlags DWORD dwTotalFrames DWORD
dwInitialFrames DWORD dwStreams DWORD dwSuggestedBufferSize DWORD
dwWidth DWORD dwHeight DWORD dwReserved[4] ; } AVIMAINHEADER
AVIOLDINDEX typedef struct _avioldindex { FOURCC fcc DWORD cb struct
_avioldindex_entry { DWORD dwChunkId DWORD dwFlags DWORD dwOffset
DWORD dwSize ; } aIndex[] ; } AVIOLDINDEX
AVIPALCHANGE typedef struct { BYTE bFirstEntry BYTE bNumEntries WORD
wFlags PALETTEENTRY peNew[] ; } AVIPALCHANGE
AVISTREAMHEADER typedef struct _avistreamheader { FOURCC fcc DWORD cb
FOURCC fccType FOURCC fccHandler DWORD dwFlags WORD wPriority WORD
wLanguage DWORD dwInitialFrames DWORD dwScale DWORD dwRate DWORD
dwStart DWORD dwLength DWORD dwSuggestedBufferSize DWORD dwQuality
DWORD dwSampleSize struct { short int left short int top short int
right short int bottom ; } rcFrame ; } AVISTREAMHEADER
AVISTREAMINFO typedef struct { DWORD fccType; DWORD fccHandler; DWORD
dwFlags; DWORD dwCaps; WORD wPriority; WORD wLanguage; DWORD dwScale;
DWORD dwRate; DWORD dwStart; DWORD dwLength; DWORD dwInitialFrames;
DWORD dwSuggestedBufferSize; DWORD dwQuality; DWORD dwSampleSize; RECT
rcFrame; DWORD dwEditCount; DWORD dwFormatChangeCount; char
szName[64]; } AVISTREAMINFO
AXESLIST typedef struct tagAXESLIST { DWORD axlReserved DWORD
axlNumAxes AXISINFO axlAxisInfo[MM_MAX_NUMAXES] ; } AXESLIST, *PAXESLIST
AXISINFO typedef struct tagAXISINFO { LONG axMinValue LONG axMaxValue
TCHAR axAxisName[MM_MAX_AXES_NAMELEN] ; } AXISINFO, *PAXISINFO
f0dder
>>> AVIFILEINFO...you never saw this in windows ???
>>>
>> The structs you posted (all horribly garbled up) had nothing to do
>> with AVIFILEINFO whatsoever. Looked rather more like something from
>> an OS - "AEP_REAL_MODE_HANDOFF".
>
> Oki. I pasted only a part of it.. my fault.
>
I'm still wondering where the structure definition you posted came
from :-)
> Below is the full list.
*snip*
How on earth have you managed to get it in such a garbled format?
The Wannabee
<f0dder_s...@flork.dk>:
> The Wannabee wrote:
>
>>>> AVIFILEINFO...you never saw this in windows ???
>>>>
>>> The structs you posted (all horribly garbled up) had nothing to do
>>> with AVIFILEINFO whatsoever. Looked rather more like something from
>>> an OS - "AEP_REAL_MODE_HANDOFF".
>>
>> Oki. I pasted only a part of it.. my fault.
>>
> I'm still wondering where the structure definition you posted came
> from :-)
This is because you dont read very well. :-))) They came from Guga.
>> Below is the full list.
> *snip*
>
> How on earth have you managed to get it in such a garbled format?
This is because when pasted, it looses its table format. It sits in a
table like this :
NAME ROSASM_FORM ORIGINAL FORMAT
____________________________________________________
My job is to try make sense of the right column and create RosAsm
equivalent strutures. And I can tell you the problem is NOT to generate
RosAsm equivalent structs, but to make sense of the right column.