Canonical format for header files
Randall Hyde
news:FQuXb.37858$_44.31404@attbi_s52...
> Randall Hyde wrote:
>
> How will an intermediate form help? You're not going to make up your own
> names for all those ReallyLongNamesForSmallIntegers, are you?
Of course not. The purpose of the intermediate file format is to create
a file structure that is easy to translate to all assemblers; specifically,
the
conversion from intermediate form to the particular assembler is 100%
automatic and requires no hand tweaking. It would be nice to maintain
exactly *one* source file format and then automatically convert the
result to all the assemblers that provide the conversion tool.
>
> > 2. Some destination languages are more semantically rich than the source
> > language.
>
> If it isn't in the source language header file, it will need to be added
> to the "canonical format" file by hand. So far, so good...
>
> ...
> > A better approach might be to create a "C to intermediate format" tool
to
> > generate
> > the first pass of the file (as *most* header files we're going to want
to
> > create
> > start off in C, anyway) and then maintain the intermediate file manually
> > from
> > that point forward.
>
> But weren't you just telling us that the source language header files
> (C, ordinarily - are the other source languages we need to worry about?)
> *are* in fact likely to change frequently?
The way to handle this is fairly straight-forward- DIFF files.
That is, you write (or use) a utility like H2INC to generate a
close approximation (within 75%) of the ultimate intermediate
file. *Before* hand-tweaking the result, you save it. Then you
hand tweak it and get it into an appropriate form that can be
processed by all the translator programs. Write the translators
and then you're in business.
When the C headers change (e.g., when a new version of Linux
or Windows appears), you then run the new header files through
the semi-automatic translator and run a diff on the new output
against the original output. Then you add the differences into the
intermediate file you're maintaining. Though the C header files
*do* change on occasion, it's not all that often (generally every
year or two). Incorporating the differences by hand shouldn't
prove to be a terrible task. Much better than our current situation
(where each assembler requires a set of manually maintained
header files).
>
> Wouldn't it be better (in an ideal world) if the "C to canonical form"
> tool were at least able to "update" an existing canonical header,
> leaving the "added semantic richness" alone?
It would still have to be checked by hand. In my experience, the
effort needed to verify the correctness of the auto-generated result
is usually *more* work than making the changes manually. Between
OS releases, you generally get several new constants, structures, and
(depending on the OS) several new API functions. But compared to
the initial effort, the new additions are relatively small and can be
incorporated into the system in a matter of hours or days. This will
turn out to be far less effort (given the update schedules on most
C header files) than maintaining a program that does all this wonderful
stuff automatically. Besides, C (the primary source for the equates)
isn't as semantically rich as HLA (for example) and some intelligence
would have to be applied to the result anyway. In the long run, I don't
believe that testing and maintaining an "automatic C to ????" conversion
program is going to be cost effective.
>
> > Maintaining only one file is a tractible problem.
>
> Especially if the "C guys" are maintaining it. :)
Except the "C guys" often create things like
#define amacro(x,y) ((x)*3 + (y)-2)
That won't translate into assembly language very well. (At least,
in a header file). So attempting to write a program that does
an automatic conversion from C to assembly is going to be
a problem. However, a semi-automatic convertor could handle
all the stuff that's easy, like
#define aConstant 12345
and flag the stuff that's difficult to convert so the user can
manually check out the problem areas. Like I said earlier,
with a decent DIFF tool, it's very easy to track what has
changed when a new version of the header file appears.
>
> > Maintaining
> > all those different "language X to intermediate format" programs would
be
> > problematic. 1. they're not easy to write; 2. they need to be
maintained
> > *in sync*
> > with one another;
>
> Why not a single tool with different output modules for assemblers X, Y,
> and Z? The "quadratic exponentiation" problem only occurs if you need
> conversion from assembler X's syntax to assembler Y's syntax, or back to
> C, or to the "canonical format".
I believe that's what I was saying.
The advantage (I believe, this was Beth's idea) of the X <-> Y conversion
(X, Y being any languages) is that we could take advantage of header files
that are currently available and create new headers for other assemblers.
However, the MASM32 equates are the only massively large system that
I believe would currently prove valuable in this respect; and as that
information
already exists in C header files, I think that this process would be
redundant. True, a renegade assembler group could create their own
set of fancy equates and those equates wouldn't be immediately available
for other assemblers, but I believe that if the equates were genuinely
useful,
then *someone* would stick the values into the canonical form and everyone
would have them.
>
> > 3. Once the intermediate file is generated, it's just as
> > easy to
> > maintain that file as it is any particular header file in some other
> > assembler;
> > 4. The temptation to use features in an assembler's header file that is
> > beyond
> > the capabilities of the intermediate format is too great ("What? Not put
any
> > advanced HLA macros in my header files?");
>
> If the Nasm guys are "contributing" to the canonical format file, what
> assurance do you have that their changes won't break whatever "added"
> information is in there for HLA's benefit?
It isn't a question of "breaking" the information.
Like NASM, HLA can operate in an "everything is a dword" mode
if you really want to do that. Indeed, there are some HLA users who've
created their own Windows header file entries that do exactly this.
So anything a NASM user could come up with would probably be usable
by HLA programmers with no problem (indeed, 90% of the issues I'm
thinking about have to do with parameter lists in the API calls, something
that NASM doesn't deal with anyway). In any case, suppose a NASM
user adds an external function definition to the intermediate file. As NASM
users have no need for parameter lists, I'd suspect they'd leave that out
of the definition. A MASM user comes along and says "Hey, whomever
add this definition didn't provide the parameter list (as NASM doesn't
require
that info). So the MASM user adds a simple parameter list to the
definition (which, btw, the NASM generator would simply ignore). Then an
HLA user comes along and says "Gee, this MASM user assumes you're
always passing a pointer, but it would be more convenient in HLA if this
parameter were passed by reference rather than a pointer by value. So the
HLA user makes the change to the intermediate file format. As MASM
doesn't support pass by reference, the translator from intermediate file
format to MASM headers translates that to a dword. The NASM
translator still ignores the whole thing. As time goes by, the file gets
refined to the point that everyone is happy. The only trick is to have
a single maintainer so that some unhappy assembler group doesn't go
in an sabotage the file for everyone else.
>
> > 5. Once you create the
> > intermediate
> > header file from your source language, there isn't much need for the
> > translator
> > program thereafter (assuming, of course, that you maintain the
intermediate
> > file).
>
> But if new (changed) C header files become available frequently, the
> needed maintainance on the "canonical" file would be considerable to do
> "by hand". Wouldn't it be easier to convert the new headers directly to
> formats that users of assemblers X, Y, and Z could maintain just the
> "added information" on, in a syntax they're familiar with?
New files have to go through the whole process. That's still less work
than having 'n' people doing n conversions. As for modified header files,
I've already addressed that issue.
>
> > A few "language X to intermediate format" convertors would be nice. C is
an
> > obvious example.
>
> Others?
Delphi/Pascal?
C++?
MASM32?
I don't know.
>
> > And an "80% solution" would work fine (i.e., something that
> > requires a bit of manual intervention after conversion). Beyond that, I
> > think that
> > maintaining (or generating) the intermediate files by hand is a better
> > solution than
> > creating new (and maintaining old) translator programs.
>
> When you speak of "generating" header files, that's a different kettle
> of fish. A "canonical" intermediate format would make sense in that case
> - and C would probably not be it :)
No, C is not good for a couple of reasons (e.g., the ability to inject
things
besides constants, structures, and prototypes in a header file).
Furthermore,
we'd probably want an intermediate format that simplifies writing and
maintaining the translator programs. I'm thinking of something along the
lines of an ".ini" file format. Something that requires very little parsing
in
order to generate the file for a given assembler.
There are, of course, lots of details that have to be dealt with (and
are not easy to solve). For example, C is a case sensitive language;
not all assemblers are case sensitive. And it is quite common (though
*very* bad programming practice) to find two different identifiers in
a typical header file that differ only with respect to alphabetic case.
There is also the problem that C and the various assemblers have
different sets of reserved words; and it's very common for assembly
language reserved words to appear in a C header file as an identifier.
Also, calling conventions tend to vary quite a bit among API sets.
No doubt, a zillion details will pop up as work progresses on this
idea. Some will be easy to solve, some will be difficult (e.g., mapping
reserved words to different names). If we stick macros in the
intermediate file, how do we specify them in such a way that they
are usable by all assemblers (indeed, some assemblers don't even
support macros, what to do then?)
In the long run, however, I believe the effort to be worth it.
When someone creates a new assembler, they face the daunting
task of creating a set of OS equates and that's a huge burden. OTOH,
writing a simple translator program should be a whole lot easier.
And that, ultimately, would make assembly language a more popular
tool.
Cheers,
Randy Hyde
Randall Hyde
"T.M. Sommers" <tm...@mail.ptd.net> wrote in message
news:NRycnS_iyIf...@ptd.net...
>
> Have a single front end, and multiple back ends, one for each
> target language or platform. There is an intermediate form, but
> it is not saved. This is how the GCC does it.
And what is it that the "front end" processes?
C files? Alas, C header files contain too many things that
cannot be converted to assembly source code for use as
(reasonable) input to some assembler.
>
> The problem with saving the intermediate form is that it becomes
> outdated. Even if its creation is 100% automated, it is still
> something that requires maintenance.
Of course it will require maintenance. In fact, I'd argue that
once the intermediate file is cleaned up, *all* maintenance takes
place on that file, much like the MASM32 equates are being
maintained today.
>
> And I repeat, this is all based on the assumption that the
> conversion can be done automatically.
It cannot. And that's why attempting to work from C header
files just won't work.
Cheers,
Randy Hyde
Beth
(_simplified_, I'd stress, not the "final implementation" but an
example to give the rough gist of what's proposed :)...
Basic structure:
+-------+ +-----------+ +-------+
| X | <---> | Canonical | <---> | Y |
+-------+ +-----------+ +-------+
Where "X" and "Y" are "front end / back end" modules for any of the
supported syntaxes...they are "plug-in modules", so to speak, with the
responsibility of converting their syntax to the canonical form or, if
given canonical form as input instead, converting from the canonical
form to their syntax...these "modules", you'll note, are exactly the
same kind of effort you'd put into writing some dedicated "X to Y"
convertor, like T.M.Sommers has suggested...what makes them special is
that they convert to / from "canonical form"...
The "canonical form" itself is a proper superset of all the facilities
available in all the supported formats...what is _crucial_ about this
form is that it _retains_ as much information as is possible (and a
"proper superset" of all languages would mean a form that is capable
of retaining _all_ information that may happen to be in any file
passed to it :)...this is a crucial point...the "canonical form", in
fact, shouldn't really be looked as being "some other syntax" but,
rather, a _storage_ form for the _semantics_ of any include file
without syntax coming into it at all...
In this light, the "canonical form" I'm thinking of is actually
_binary_...not human-readable, not ASCII, not UNICODE...it's just a
string of "records"...if you like, converting to "canonical form" is
something like compiling to an "object file" but _without_ there being
any form of "conversion" at all...
Right, so we pass the utility a C header file...the Win32 header
files, for example...and specify with command-line switches or
whatever that we want a "C -> NASM" conversion...this means that the
utility slots in the following "front end" / "back end":
+-------+ +-----------+ +--------+
| C | ---> | Canonical | ---> | NASM |
+-------+ +-----------+ +--------+
[ Note that a "module" for any particular syntax - like NASM or GAS -
really is two components housed together...a "front end" which works
from the specific syntax to "canonical form"...and a "back end" which
works from "canonical form" to the specific syntax...generally, these
two are roughly symmetrical, though, so housing them together as a
"module" - simply selecting a "ToCanonicalForm" or "FromCanonicalForm"
function, depending on which side of the diagram the module is
attached - allows the two functions to share data (information about
the syntax) and so forth... ]
Also, note that there's "common functionality" that all the "modules"
can use...such as "load a file", "save a file" and other common
operations and they all share the "canonical form"...so this stuff can
be in the "main module" of the utility itself that they can
"borrow"...this saves having to re-write this stuff for every syntax
"module"...they just use the "common" stuff defined in the main
utility :)...
Okay, so we actually start processing...the utility - according to the
conversion we've asked for with the command-line switches - selects C
as the "front end" and NASM as the "back end"...which just basically
means that it sends the input file - a C header file - into the C
"front end" function...in other words, it calls, say,
"CModule::ToCanonicalForm(InputFilename);" (to unravel the touch of
OOP and C syntax I've put in there, this can be seen as "push
InputFilename; call CModule_ToCanonicalForm", if you like...and for
each module, there's two functions: "XXX_ToCanonicalForm" and
"XXX_FromCanonicalForm", just where "XXX" represents the name of the
syntax module like "NASMModule_" or "CModule" and so forth :)...
This "front end" reads the input file and it finds "/*"...this is the
start of a C comment...so, what the "front end" does is create a
"COMMENT" record in the canonical form...that is, it adds on a
structure to an array of structures...this array of binary structures
represents the "canonical form"...it's an internal binary format and,
in that sense, has no "syntax" at all (this is, of course,
_DELIBRATE_...the idea here is that we're _stripping_ all the "syntax"
concerns out of a file and merely storing its _semantics_...that is
what this "canonical form" is all about :)...as such, I can't really
write what it would look like directly because it has no "syntax" and
it isn't a "text file" or anything...but to give an idea of what I
mean, consider something like the following (in C syntax, just because
that's "neutral" and pretty concise :)...
-----------------------------------
typedef struct {
char * Text;
} COMMENT_RECORD;
typedef struct {
char * Name;
char * Value;
} CONSTANT_RECORD;
...
typedef enum {
RECORD_COMMENT,
RECORD_CONSTANT,
...
} RECORD_TYPE;
typedef struct {
RECORD_TYPE Type;
union {
COMMENT_RECORD Comment;
CONSTANT_RECORD Constant;
...
};
} RECORD;
RECORD CanonicalForm [];
-----------------------------------
This, again, is purely illustrative to give a rough impression...the
"real deal" would be a bit more complex with records for many
things...including, for example, a "TYPEDEF" record which defines a
data type and support that the "data type" created by the "TYPEDEF"
can be used in "STRUCTURE" records or whatever...so, in a real
implementation, there could also be a lot of extra stuff like a "data
type" table or whatever too...but, this is illustrative so I'm just
showing a very simplified example, just to give an idea of how it's
supposed to roughly work...
Right, so the C "front end" has detected the start of a "COMMENT" -
found a "/*" in the input file - and then carries on reading until it
hits the end of a C comment "*/"...everything in between - the text of
the comment - gets stored into the "char * Text" as is...
It then processes the rest of the input file in much the same
way...for example, it finds a "typedef" and creates a "TYPEDEF" record
and adds that onto the array of records with the various fields filled
out: "Name" (of the new type), "Type" (the data type being given this
new name :), etc...it hits a "struct" and then generates a "STRUCTURE"
record, filling out the fields with "Name", "CountOfMembers" and an
array of "Name" and "type" for each member in the structure and that
kind of thing...basically, we're, as I say, _stripping_ the syntax
away from the input file and simply _storing the semantics_ of what
that include file says...
Once the input file has been entirely processed, this "array of
records" is passed to the NASM "back end"...it finds a "COMMENT"
record at first and then basically dumps out the "Text" field to the
output file, accounting for how NASM syntax works...so, for each line,
it spits out a ";" and then the text for that line...in C, the new
lines in the "Text" don't need any processing between "/*" and "*/"
because that's C syntax for you but the NASM "module" knows NASM
syntax and in processing the "COMMENT" record, it looks for new line
characters and spits out each line individually with a ";" prefix...
The "front end" stripped out the syntax, merely storing the
_semantics_ of the file in a binary "list of records"...the "canonical
form", if you will...then, basically, the "front end" and "back end"
are symmetrical...the "back end"'s job is to take the _semantics_
stored in the "canonical form" - the array of records - and put the
_syntax_ back in (just, this time, it's putting _NASM_ syntax back in,
not the original C syntax :)...
What about that "TYPEDEF" record? NASM doesn't support "TYPEDEF"!
Well, the "back end" knows this and can take suitable action...for
example, the "TYPEDEF" record says: "typedef DWORD HWND;" ("HWND" is
a different name for the "DWORD" data type is the command here,
roughly :)...so, the NASM "back end" can, for example, be told to
substitute any "HWND" it finds in any other record to "DWORD"
automatically...it can also, to assist with any "converions problems",
spit out information to a "log file" about this conversion it needed
to do...if it hits a "STRUCTURE" record, then, for assemblers without
structure support, it can spits out instead a series of "EQU" lines
that equate to the offset of a member in that structure...if the
assembler doesn't support "local" member names in structure, it can be
configured to spit out each member with the structure's name
automatically appended or whatever (typical "manual" way to get around
lacking this type of structure support :)...
And so on and so forth...again, I stress the "illustrative" and
"simplified" nature of this example I'm giving...there's a lot more
complicated issues to deal with to do a good job but this gives you
the "rough impression" of how I imagined this "canonical form" could
work...plus, one obvious "extension" here is an option to be able to
do this conversion in pieces...that is, you can specify "C ->
canonical form" only and it just dumps out some "Win32.can" binary
file, which is the array of binary records that it processed from the
C file...then, you can later run the utility with "win32.can" -> NASM
or "Win32.can" -> MASM or "Win32.can" -> RosAsm or whatever...like
object code files, the "intermediate" canonical form can be put into a
file on the disk...and this makes it more flexible and more convenient
(if you need the C Win32 header files in many different ASM syntaxes,
you can split it up into "C -> canonical form" as one operation and
then "canonical form -> NASM, MASM, RosAsm" as separate
operations...though, that's just a "time saver" kind of deal
only...like "pre-compiled headers" or using "object code" files so you
don't always have to re-compile every single time, like RosAsm forces
because it works direct without object code files...note, that's not a
criticism of RosAsm here, just a statement of fact about how it
operates differently because it doesn't use "object code" files or
libraries at all :)...
Why do it this way rather than creating lots of separate "C -> NASM",
"C -> MASM", "C -> RosAsm" utilities? Well, basically because there's
lots in common between what each of these utilities would have to
do...so, you can pool the "common operations" together...and, thus,
when you write a C "module" for this utility, you're actually creating
"C -> NASM", "C -> HLA", "C -> MASM", "C -> any other supported
format" all at the same time...and you're also implicitly creating
"NASM -> C" or "NASM -> HLA" or whatever...
By pooling these things altogether and slotting in a "middle man" with
the canonical form, you're effectively able to create _multiple_
conversion utilities all in one go...so, taking the following
"supported syntaxes" - C, HLA, NASM, MASM, LuxAsm, RosAsm - we end up
with:
C -> HLA
C -> NASM
C -> MASM
C -> LuxAsm
C -> RosAsm
HLA -> C
HLA -> NASM
HLA -> MASM
HLA -> LuxAsm
HLA -> RosAsm
NASM -> C
NASM -> HLA
NASM -> MASM
NASM -> LuxAsm
NASM -> RosAsm
MASM -> C
MASM -> HLA
MASM -> LuxAsm
MASM -> RosAsm
LuxAsm -> C
LuxAsm -> HLA
LuxAsm -> NASM
LuxAsm -> MASM
LuxAsm -> RosAsm
RosAsm -> C
RosAsm -> HLA
RosAsm -> NASM
RosAsm -> MASM
RosAsm -> LuxAsm
That's _29_ conversion utilities for writing only _6_ "modules"...the
"canonical form" not only makes that possible but it actually also
conspires to make the conversion _simpler_ to implementat because you
can simply divide it into one function that "strip the C syntax to
canonical form" and one function that "put the syntax back into the
canonical form"...
Also, I've left out "C -> C" and "HLA -> HLA" because these would seem
"useless" conversions...but, then again, if the utility is afforded
some "pretty up the syntax" functionality (for example, it
automatically aligns things and sorts out the correct indentation and
puts in spaces and adds comments...for instance, some C header files
like to add a comment after an "#endif" about the "#if" it relates to,
such as "#endif // WIN32_VERSION >= 0500h" on the other end of a "#if
(WIN32_VERSION >= 0500h)" IF...ENDIF block so that you can tell which
"#endif" relates to which "#if" by looking at the comment :)...that it
could be configured to format the output file in a special "neat" way
then you can even run "C -> C" conversions which doesn't actually
converts but, rather, cleans up the formatting in the file to make it
easier to read...if you include this as useful functionality, we're
actually talking _36_ different things that the "canonical form"
utility can do from only writing _6_ modules...
On the other hand, if we take the "write a dedicated convertor"
approach then you will need to write _36_ separate utilities to do the
same job...the "canonical form" has both saved us from writing _30_
conversion programs...no, actually, _more than that_, it has also
simplified writing those conversion utilities because all _common_
operations (read from file, write to file, common "canonical form"
through which to do the conversion, etc. :) only need to be done
_ONCE_ in the "main module" and are supplied to all the other
modules...that is, we're not just talking about getting _30_ extra
useful conversions from those _6_ "modules" but we're also talking
about each "module" being a whole lot simpler and shorter to write
than having to write _36_ complete conversion utilities from
scratch...
Plus, because this utility is designed with "genericism" in mind,
along comes a Pascal programmer who wants things in C format and they
add a "Pascal module"...the count now goes to _49_ different
conversions (or 42, if you don't want to count the "Pascal -> Pascal"
option as a "conversion", merely a "pretty up the code" possibility :)
from _7_ modules...along comes a Power BASIC programmer, say, and adds
a "PowerBASIC module" onto the utility...we've only now written _8_
modules but have _64_(!!!) different possible operations out of that
work...and, note, with these two added, there's "Pascal -> C" and
"C -> Pascal"...it's not just useful for ASM programmers, HLL people
can use it too! After all, Pascal programmers must get annoyed at
these header files so often coming in C form and despair at having to
manually translate it themselves ;)...
And the "canonical form" is a "proper superset" - any "loss" occurs at
the "back end" phase, trying to get it back into a specific syntax
which might not support the stuff found in the original file - so the
"C -> C" or "HLA -> HLA" or "NASM -> NASM" conversions _LOSE NOTHING_,
by definition of making the canonical form a "proper superset" of all
the supported syntaxes...
Regards "maintenence", it's actually absurd to compare...say, we
wanted to add on an extra RECORD type to the canonical form to support
Pascal...there's only _8_ modules that need to be edited to support
this...whereas the "dedicated tool" approach would require _56_
completely separate utilities to be re-coded...plus, if the default
action is "if I don't understand, then I ignore and spit out a
warning", this tends to cover the "safe" behaviour...so, you might not
even need to edit all of those 8 modules, even...the more "modules"
that are added, the amount of possibilities of the tool increases in
square numbers of the amount of modules...but, yet, you only need deal
with the square root of those conversion possibilities in maintaining
it...
Yeah, I know...you all thought "modularising" was just about keeping
your source code easy to manage...that's what Rene keeps telling us
and that's why his "source management" techniques are "the equal" to
anything "modular coding" can manage because it displays the source
code in a convenient fashion...yeah, right...thankfully, Rene doesn't
write our operating systems because they take advantages of exactly
this kind of "client / server" modularity to provide _extra
functionality_ (take a look at how X-Windows uses a "client / server"
architecture to allow _any_ program to be run "remotely" (including
mad possibilities like a _single_ application running on _multiple_
"servers" all over the world :) without making a single change to your
source code...then, take a look at how Microsoft propose doing this in
Windows with a special "IDL" syntax file and by writing "stubs" to add
onto things and so forth...this is why Microsoft are pushing Windows
so hard in this direction with ".NET" because they realise their
simple, naive architecture is actually _badly designed_ with regard to
distributed computing and along came the _internet_, which threw them
into a panic that UNIX natively speaks "internet" - there's a reason
why internet addresses have _forward slashes_ rather than
backslashes - and they are ill-equipped in architecture terms to
exploit this and continue their "world domination" plans ;)...
[ Note: Interested developers are welcome to create a SourceForge
account, send me an Email of their user account name and will be added
to contribute to this "open-source" project that benefits
everyone...it's going to be in ANSI C, though, for the potential of
allowing it to be expanded and used on all different systems
"portably" so it's NOT going to be coded in ASM...also, I welcome
developers but I'm the admin and if someone like Annie or Rene joins
on just to cause trouble and mess up the sources then don't bother
because the CVS can be rolled back to before your "sabotage" and I
won't hesitate to boot whoever tries something like that off...oh,
indeed, don't think I'm not wise to some of the evil thoughts that run
through disruptive minds (or that SourceForge aren't wise to provide
the facilities by which such "sabotage" is easily undone ;)...all
"open-source" contributions are welcome and anyone can be a developer,
though..."benefit of the doubt" is granted to all to prove
themselves...it's a condition of the "open-source definition", in
fact, that I may not discriminate any group or interested
individual...and some of us know what "open-source" actually means,
Rene, because we bothered to read the "boring theory" of the legalese
before clicking "I agree" ;)...the SourceForge project name is
"ConvInc" (Rene's influence there...it's a "pun" name: "CONVert
INClude" but pronounced "convice" just like the English word
:)...pardon the webpage, it's merely a "placeholder" until some better
content appears...oh - and Annie - it's not quite pink but Hopefully
close enough to that that you'd approve of the colour scheme :) ]
Beth :)
Beth
> T.M. Sommers wrote:
> > Have a single front end, and multiple back ends, one for each
> > target language or platform. There is an intermediate form, but
> > it is not saved. This is how the GCC does it.
Yeah, make that "multiple front ends" and that's kind of the approach
_I_ was considering here, anyway...the intermediate form can be saved,
perhaps, but that's an "optional extra"...
> And what is it that the "front end" processes?
> C files? Alas, C header files contain too many things that
> cannot be converted to assembly source code for use as
> (reasonable) input to some assembler.
Actually, doesn't GCC also process C++, Objective C and a whole host
of other things too?
Anyway, pointing to GCC exactly demonstrates the power of
"modularising" and the power of OpenSource(tm) development...I find
there to be no "shame" in being a "spiritual cousin" to that...in
fact, if it wasn't that we have a much more limited range (this
include file convertor is called an _include file_ convertor because
it doesn't process code...things like "#define" and "struct" and
"typedef" - data-based things - usually have a 1:1 correspondence, if
supported, between all different languages...a more general
"convertor" that actually converted C _code_ to ASM would be way, way
more complicated and problematic...there was no intention to approach
that here...it's "beyond the scope" of what's intended) then _using_
GCC would be a nice idea...
> > The problem with saving the intermediate form is that it becomes
> > outdated. Even if its creation is 100% automated, it is still
> > something that requires maintenance.
[ You can always "MAKE" the files...if the intermediate file is older
than the original file, re-process...if not, the utility is not
called...using the "external" functionality of MAKE, even this can be
"automated" by just considering it as one more "step" in the build
process...MAKE'll take care of the rest looking at the time stamps
:) ]
> Of course it will require maintenance. In fact, I'd argue that
> once the intermediate file is cleaned up, *all* maintenance takes
> place on that file, much like the MASM32 equates are being
> maintained today.
Indeed, _OF COURSE IT WILL REQUIRE MAINTENANCE_!!
I mean, what on Earth are you expecting here, to be blunt? That we're
going to weave some "magic" where there's one special tool that
automatically writes all your code for you and always does a perfect
job that no human intervention is ever necessary? Hey, if that's the
kind of thing that you code, tell the AI people how you did it,
publish papers on this "magical" new way of doing things...people will
want to know! :)
This is a strange counter-argument...it stinks badly of "I don't like
the idea, find the first problem I can in order to declare it
impossible to stop it happening"...NO tool works in the way you
propose...I'm sorry but if I alter the C source code, then it's _up to
me_ to run MAKE or put the source file into the C compiler...object
code files can go out of date just as easily...
It's just an extra build tool that helps you do things quicker and
more easily, it's NOT "World Peace and the end to world hunger" or
anything...I find it bizarre that anyone would be expecting this and
then would declare "shouldn't be done!", just because, indeed, it
can't manage what's currently _IMPOSSIBLE_ for any tool to manage...
What bizarre logic! I can see it now: "GCC? Ah, but your compiler
won't automatically re-write code without human intervention when the
current software becomes out of date with the real-world problem it's
solving! Hence, because compilers and assemblers can't solve
everything in a completely automated manner, we should have NO build
tools whatsoever! Hand-code everything and only use punchcards!"...
Or, one day, all the nations on Earth declare World Peace and there's
a Golden Age of peace and posperity to the entire world...but, oh
dear, Mr. and Mrs. Johnson of 36, Holland Drive in Newcastle, just had
a big old argument about paying their bills! There was no "peace" in
that big old fight...they were shouting at each other and everything!
Okay, we must give up immediately...all the nations of Earth must
now - in light of it not being possible to ever get 100% "peace"
everywhere on Earth - tear up the agreements and treaties and go back
into constant, bloody war for the rest of eternity...billions dying
because a married couple had a small argument (they've, by the way,
made up now but, regardless, because for a split-second "peace" was
not on Earth to all people simultaneously, we must give up on "peace"
altogether! :)...absolutely sound logic there, I don't think...
Yes, this utility will NOT make you a cup of tea or coffee,
unfortunately...it also won't do kids' homework automatically...nor
will it re-decorate the kitchen automatically...
But what it does do automatically - but, yes, it's "on request" and
very possible that it will be _imperfect_ in its task (how odd, in
fact...usually the argument is "it's doing it behind our backs!", if
it's automated...but now the problem is that it _can't_ do it all
"behind our backs"? Which is it, people? Make up your minds! ;) - is,
to my mind, _worth_ having...
> > And I repeat, this is all based on the assumption that the
> > conversion can be done automatically.
>
> It cannot. And that's why attempting to work from C header
> files just won't work.
Agreed; It _cannot_ be done in some complete unproblematic automated
harmony for all things for all time...I find it kind of bizarre that
anyone would expect this, in light of the problem and the _inherent_
"incompatibilities" that exist in it...
But if you can't get 100% then 99% is perfectly okay with me...heck,
only managing 50% is still 50% that can be done automatically so you
don't have to do it manually...even if it was 20%...if all it could do
was change "#define" into "EQU", leaving everything else "as is", then
that's _still_ worth it...
I don't get this "binary thinking" of "if we can't have 100% automated
magic that overcomes impossibilities then we should have 0% and
absolultely no assistance whatsoever"...kind of "defeatist", isn't it?
Nothing would get done with such absurd levels of "perfectionism"...
Yes, after running the tool - which itself will, indeed, output
"warnings" to a "log file" to warn you about all the conversion
"issues" and "problems" it encountered - it might require _manual_
"tweaking" to get "just right"...but then _all_ solutions would
require some "tweaking"...and sorting out one or two "conversion
problems" that the tool couldn't handle is way, way better than
converting tens of thousands of source code lines in, say, the Win32
headers bit by bit, totally manually...
Heck, just _try it_...and if it doesn't work then, fine, it didn't
work...manually convert it instead...better also to have the _choices_
and _freedoms_ to try different things to see what will work than to
be _restricted_...
But, okay, fine...it's up to you, ultimately...if you don't want a
tool like this then just don't use it...there, that was quite
painless, wasn't it? What on Earth is all this "attack! attack!
attack!" fuss all about...you know, what is it _really_ about? Much
like Mr. and Mrs.Johnson, the argument, in truth, wasn't really about
the bills at all...Mrs.Johnson was just feeling generally neglected by
Mr.Johnson and the bills were just the focus by which to launch an
attack and voice the disatisfaction...so, what is this _really_ all
about, if I may ask?
Beth :)
Beth
> The way to handle this is fairly straight-forward- DIFF files.
Great idea; "DIFF" is not particularly difficult to handle with ASCII
files (compare bytes until something isn't matching :) so the utility
could even, perhaps, do this stuff automatically...it could also look
at "time stamps" in a MAKE-like way too, as that's not particularly
difficult to code either...
Perhaps I'm wrong but I get the distinct impression that we have a
case of "creating problems for the sake of creating problems" thing
going on here...because they've already pre-judged that they don't
like the idea so are trying to "fit the facts" and "create problems"
into making it not happen...
If we address these problems, Randy, then we'll suddenly be told: "Ah,
but I like to have a cup of coffee while programming and your tool
doesn't automatically do that, does it?"...and if we included a
"coffee maker" subroutine that controls a robot arm and coffee machine
to do it then the "problem" becomes: "Ah, but it doesn't make those
Italian frothy coffees, does it?"...fix that and then the "problem"
becomes: "Ah, but there's no tea or orange juice facilities, is
there?"...blah-blah-blah ;)...
This kind of thing only remains valid up to a point...there is no "can
do everything" machine and there never will be...in fact, you know
what comes closest to that? The _human mind and body_ is the most
"general-purpose" tool we have at our disposals...it has great "AI"
and "opposable thumbs" for picking things up and everything! It can,
though, be a little slow to do things than some of the more dedicated
"computer" machines when it comes to big, repetitive, simple and
_TEDIOUS_ tasks...so, we can sometimes improve things by getting a
machine or utility program to at least take some of the burden off of
the human, as far as it is able...machines aren't yet good enough to
write their own programs but they are very good and useful at helping
humans along with that task to do it more quickly and easily...we're
NOT proposing anything more than that...it's a "helper"...don't want
it? Fine...but other people do so please don't just "spoil the party"
just because you don't personally like it, as others might be having a
great time...just leave the party and go find something you do enjoy
doing...perhaps watch a video and chat with a small bunch of close
friends instead...that can often be far more enjoyable than any
"party", anyway...you're not a robot, life isn't uniform, variety is a
great thing...so do whatever you like...but just don't be a misery
guts and impose your dislikes onto everyone else as some kind of
"law"...surely it's not an unreasonable "ask" there? Is it? :)
Beth :)
Phil Carmody
> string of "records"...
And how would this differ from XML?
Anything that can be represented as binary records can be represented
in human readable form. The data within the records is human-understandable,
almost certainly (one can describe any mov instruction verbally, certainly,
for instance), and therefore there's no reason not to store them in
such a way
I don't know - maybe something like the following:
<instruction type="move" src="EAX" dest="memref1">
<memoryreference name="memref1" offset="0xA0000" scaled="EDI" scale="4" />
</instruction>
or even
<instructions>
<move src="...
or something.
I think getting instructions canoncalised should be possible, and that
canonicalising comments would also not be too hard, but programatic
macros, which are a meta-language, seems to add too many layers.
Phil
--
Unpatched IE vulnerability: ADODB.Stream local file writing
Description: Planting arbitrary files on the local file system
Exploit: http://ip3e83566f.speed.planet.nl/eeye.html
(but unrelated to the EEye exploit)
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:EzIXb.1082$O%4....@newsfep3-gui.server.ntli.net...
> Randy wrote:
>
> > And what is it that the "front end" processes?
> > C files? Alas, C header files contain too many things that
> > cannot be converted to assembly source code for use as
> > (reasonable) input to some assembler.
>
> Actually, doesn't GCC also process C++, Objective C and a whole host
> of other things too?
Of course, once you move beyond C, it gets *far* worse :-)
Fortunately, most interesting header files use plain C, not C++ or
some other variant.
Randy Hyde
Randall Hyde
"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message
news:87wu6of...@nonospaz.fatphil.org...
> "Beth" <BethS...@hotmail.NOSPICEDHAM.com> writes:
>
>
> I think getting instructions canoncalised should be possible, and that
> canonicalising comments would also not be too hard, but programatic
> macros, which are a meta-language, seems to add too many layers.
Yes, macros would be a pain. On the one hand you've got some assemblers
that don't even have macro capabilities, some assemblers like RosAsm that
don't have very *good* macro facilities, and then you've got MASM and
HLA at the other extreme with extremely powerful macro facilities. There
are only two possibilities: (1) write a preprocessor for each of the
assemblers
to handle the canonical macro form (which I think is a really *bad* idea),
or
you use the "lowest common denominator" approach (which is probably the
best idea). Unfortunately, the lowest common denominator is no macros at
all.
Personally, I wouldn't want to see a lot of "gold plating" in this tool.
There is no better way to guarantee that it never gets written than to
create a specification for it that would require more effort to develop
the conversion utility than it would take to manually convert the header
files.
Beth, you might be excited by all the possibilities of such a tool, but just
keep in mind that it's going to be used to convert just a few sets of header
files (e.g., Win32, Linux, XLib, GNOME, and BSD) into assembly.
The need to convert HLA header files to MASM header files isn't that
important. Certainly, converting TASM to C or C to Pascal won't be that
interesting to the people contributing to the project. The idea, quite
frankly
is to allow the development of a decent set of Win32/Xlib/Linux/etc., header
files without that work being duplicated a dozen times. Best to keep the
definition of the canonical form as simple as possible, to reduce the effort
needed to write the translators, so mere mortals can actually contribute.
And, Phil, I'm with you. The canonical form should be human readable.
If for no other reason, it makes it a *whole* lot easier to verify the
C->canonical translator. It also makes it easier to maintain the canonical
form without having to "recompile" older files every time a minor change
is made.
Cheers,
Randy Hyde
Randall Hyde
> Randy wrote:
>
> Perhaps I'm wrong but I get the distinct impression that we have a
> case of "creating problems for the sake of creating problems" thing
> going on here...because they've already pre-judged that they don't
> like the idea so are trying to "fit the facts" and "create problems"
> into making it not happen...
Precisely. It's really easy to add a ton of "gold plating" to the specs
right now and then wind up with something that is far too complex
for its intended purpose.
Frankly, I'd just define a canonical format in human readable form
and leave it up to the assembler authors (who are interested) to
develop their translator (canonical->assembly) for their particular
product (using whatever language they prefer). The "open development"
project could be the C->canonical translator. And I would keep the
canonical form as simple as possible for the first version. We can always
add additional features (that turn out to be highly desirable) later on.
Initially, I'd just recommend handling the following:
1. constant declarations
2. type declarations
3. structure declarations
That will cover about 90% of what's interesting in a typical C
header file.
And I'm still a *big* believer in a human readable (and
maintainable) canonical file format. I feel that the C->canonical
translation would take place once; we'd then maintain the
canonical form manually thereafter (working in DIFFs as
the C header files change; as they don't change frequently
this won't be a maintenance nightmare).
Cheers,
Randy Hyde
luvr
> And how would this differ from XML?
Now, that's a _great_ idea - Using XML for the canonical format!
No need for the umptieth binary file format - Just use XML...
--Luc.
Frank Kotler
...
> In this light, the "canonical form" I'm thinking of is actually
> _binary_...not human-readable, not ASCII, not UNICODE...it's just a
> string of "records"...if you like, converting to "canonical form" is
> something like compiling to an "object file" but _without_ there being
> any form of "conversion" at all...
And *this* is the form on which you propose to do "hand maintainence"?
...
> Right, so the C "front end" has detected the start of a "COMMENT" -
> found a "/*" in the input file - and then carries on reading until it
> hits the end of a C comment "*/"...everything in between - the text of
> the comment - gets stored into the "char * Text" as is...
Good. It has come to my attention that some of the existing "converters"
strip out the comments - thereby removing the legally mandated copyright
notice in, for example, Xlib.h...
...
> C -> HLA
> C -> NASM
> C -> MASM
> C -> LuxAsm
> C -> RosAsm
Okay so far...
> HLA -> C
> HLA -> NASM
> HLA -> MASM
> HLA -> LuxAsm
> HLA -> RosAsm
> NASM -> C
> NASM -> HLA
> NASM -> MASM
> NASM -> LuxAsm
> NASM -> RosAsm
> MASM -> C
> MASM -> HLA
> MASM -> LuxAsm
> MASM -> RosAsm
> LuxAsm -> C
> LuxAsm -> HLA
> LuxAsm -> NASM
> LuxAsm -> MASM
> LuxAsm -> RosAsm
> RosAsm -> C
> RosAsm -> HLA
> RosAsm -> NASM
> RosAsm -> MASM
> RosAsm -> LuxAsm
... but is there any point to any of these?
> ...it's a "pun" name: "CONVert
> INClude" but pronounced "convice" just like the English word
> :)...
Sounds like it has something to do with "vice" when you spell it that
way. Cool! :)
I'm not sure we're all on the same page here. Phil seems to intend
converting *code* to an intermediate syntax, which I don't think is what
you have in mind (that ends up being a C compiler, doesn't it?). Randy
clearly intends to do the maintainance on the .can (short for "Can
do!"?) format, after running the "converter" for a "first draft". You
seem to be heading for something that's not going to be the place to do
maintainance - to use your analogy of an .obj format, it would be like
hand-editing your .obj file instead of re-assembling when the
source-code changes! I suspect Randy has in mind a more "text-like"
intermediate canonical form(?). I agree roughly with your scheme, except
I don't see much point in converting from the various "destination"
languages back to .can or .h or whatever. I see the need for an
intermediate format - which is a "superset" of destination language
capabilities (HLA probably setting the standard, currently) - but I see
it as an "internal" format, not saved to disk, or intended to be
"editable" (still needs to be done!). Randy makes a good case for doing
the maintainence on the intermediate format, but I'm not "ConvInc"ed :)
Essentially, I'm suggesting making existing converters better
(conceptually, at least). Not on a "one per assembler" basis, of course
- one with selectable (by command line switches or individually linked)
"back ends" for different assemblers. Along the lines of Randy's
"benchmark generator", but with a different "front end"... and written
in a different language, perhaps. I've got source-code for two "h2inc"
converters - one from Chris Dragan, and one from Johannes Kroll. Both in
C++, IIRC. (yell if you want 'em). Randy's "ADK" that you pointed out
might be an interesting source of "front end" routines, too!
I don't think anybody is saying "don't do it because the result won't be
perfect". If anybody *is* saying that, they can be safely ignored - they
can do it *all* by hand if they want to!
Best,
Frank
Phil Carmody
> And, Phil, I'm with you. The canonical form should be human readable.
> If for no other reason, it makes it a *whole* lot easier to verify the
> C->canonical translator. It also makes it easier to maintain the canonical
> form without having to "recompile" older files every time a minor change
> is made.
And diffs that make sense too. Easier to inspect, and far friendlier
to RCS/CVS.
HD space is cheap, human time isn't, so I'd
go for the verbose format that will save me time any day.
Phil
--
Unpatched IE vulnerability: Web Archive buffer overflow
Description: Possible automated code execution.
Reference: http://msgs.securepoint.com/cgi-bin/get/bugtraq0303/107.html
Phil Carmody
> Initially, I'd just recommend handling the following:
>
> 1. constant declarations
> 2. type declarations
> 3. structure declarations
> That will cover about 90% of what's interesting in a typical C
> header file.
single expression/term #defines too?
(By 'constant declarations' I assume you mean declarations
of constants, and not preprocessing macros which expand to
contant values.)
I think that anything which can't cope with
#define ACS_ULCORNER NCURSES_ACS('l') /* upper left corner */
will be dead in the water.
Phil
--
Unpatched IE vulnerability: XSS in Unparsable XML Files
Description: Cross-Site Scripting on any site hosting files that can be misrendered in MSXML
Reference: http://sec.greymagic.com/adv/gm013-ie/
Exploit: http://sec.greymagic.com/adv/gm013-ie/
Randall Hyde
> "Randall Hyde" <rand...@earthlink.net> writes:
> > Initially, I'd just recommend handling the following:
> >
> > 1. constant declarations
> > 2. type declarations
> > 3. structure declarations
>
> > That will cover about 90% of what's interesting in a typical C
> > header file.
>
> single expression/term #defines too?
If the expression is convertable to assembly (i.e., a compile-time
expression as opposed to a run-time expression).
>
> (By 'constant declarations' I assume you mean declarations
> of constants, and not preprocessing macros which expand to
> contant values.)
No reason compile-time expressions can't be handled too.
>
> I think that anything which can't cope with
>
> #define ACS_ULCORNER NCURSES_ACS('l') /* upper left corner */
For some assemblers, this would be easy. For others, quite difficult.
How often does this occur in typical C header files (in code we'd
want to convert to assembly)?
cheers,
Randy Hyde
Beth
It wouldn't; You can use XML, if you like...
> Anything that can be represented as binary records can be
represented
> in human readable form. The data within the records is
human-understandable,
> almost certainly (one can describe any mov instruction verbally,
certainly,
> for instance), and therefore there's no reason not to store them in
> such a way
Correct; To be honest, the reason for stressing the above was only to
basically point out that "canonical form" is NOT some "new syntax"
but, quite the contrary, a form where the syntax has been stripped out
of the file...
Plus, ironically, guess why I suggested the binary form? Easier to
code and get up and running quicker!
So, it's quite funny that, in making the above suggestion, I'm told
"use XML!" _AND_ I'm told "don't get carried away with 'gold plating',
just get it to work!"...and, ummm, adding an XML reader / writer just
so you can look at the canonical form (why are you wanting to look at
it again? Curiosity? And going to all the effort of adding XML just to
satisfy your curiosity isn't "gold plating" and wasting time on minor
functionality, keeping it from being "up and running" quickly to just
do the main stuff? :) isn't "gold plating", eh? And it would be "up
and running" sooner by adding a fully-functional XML parser that it
would a bunch of structures (something I did on-the-fly in that post,
just to point out quite how quickly "up and running" we're talking
about)?
Yeah, totally...you _can_ use XML...but, amusingly, I was
concentrating on "up and running quickly" so that, indeed, those main
uses of "Win32, Xlib, GTK -> ASM" are dealt with quickly...and then
the "other" extras can be bolted on later...
Sorry, but it's everyone else with the contradiction of "it must be up
and running fast! don't bother with gold plating!" and then telling me
off for _focussing on exactly that_ rather than coding up some bells
and whistles XML parser (and there's probably some GUI editor thrown
in and web browser and...and...and...too, eh? *ahem* Can you say "gold
plating"? Add that stuff later!! ;)...
> I don't know - maybe something like the following:
>
> <instruction type="move" src="EAX" dest="memref1">
> <memoryreference name="memref1" offset="0xA0000" scaled="EDI"
scale="4" />
> </instruction>
Well, yeah...perhaps not this exact format, as it's a touch ugly...but
the basic idea of an XML format that's something like that is a
perfectly valid idea...you're totally correct that it can easily be
made "human-readable"...
But, pardon my asking, _WHY_ are we making it "human-readable"
exactly? I ain't saying that "human-readable" isn't useful...no, not
at all...I'm just saying if people are stressing "don't bother with
gold plating! Get it up and running fast! What use is HLA -> NASM?
Don't bother with that!" then how do we square the circle of bolted on
gold plating to...what exactly? Satisify curiousity? Just to lose that
"behind your back" feeling?
Adding on an XML writer / parser sounds like "gold plating"...it's not
that it's not a great idea...I totally back the idea...and _once_ the
"up and running" version I was talking about got completed, then, of
course, we can create some "internal structures -> XML" and "XML ->
internal structures" thing so that we can get this XML stuff too...
But how ironic is it that I was exactly going for "walk before you can
run" (XML can be bolted on _later_...even with XML, there _will_ be
some form of "internal structures" which are binary to house the data,
right? Well, skip over XML for the second just to get it working then
it can be inserted in the middle later, okay? :) and then get told off
for doing so...before, of course, being told how I'm "getting carried
away!" and how I should "walk before you can run"!!!
Make up your mind, people! ;)
> or even
>
> <instructions>
> <move src="...
>
> or something.
"or something", probably...but, yeah, the idea's excellent...just I
was thinking this would be a kind of "stage two" thing to add...I
mean, focus on simple _conversion_ first - the basic functionality of
the tool - then add in the "user-friendly" / "isn't this nice"
functionality _LATER_...I totally support the idea and would, indeed,
be behind taking it exactly this far...but _later_ I was
thinking...it's "gold plating" with regard to just getting the
_conversion_ "up and running" first and foremost :)
> I think getting instructions canoncalised should be possible, and
that
> canonicalising comments would also not be too hard, but programatic
> macros, which are a meta-language, seems to add too many layers.
Indeed, _macros_ are the bugger here...that's why this utility is
already ignoring any _code_ (which usually isn't a problem for most
header files that are just defining some "interface" into a library
:), exactly because of the complexity it brings into the
picture...macros, though, can work like code in places...
Then again, anyone spotting another contradiction? Randy tells me
"what use is HLA -> C?" and "don't bother with that, no-one'll want
it!!"...yet, the macro facilities are going to be "too complex"
because we have to get HLA / MASM working for "HLA -> MASM" or
whatever? Ummm, no, if you're _only_ interested in "C -> ASM" then C's
macros and pre-processor are pathetically simple...just basic
"conditional assembly" and "substitution" only, really...
Again, make up your minds, people! Do you want "up and running fast"
or do you want this "gold plating"? Because the suggestions so far
seem to be wanting _both_ at the same time...that's all I was doing
with the "binary" suggestion was concentrating on "up and running
fast"...note that if you do have XML then the utility is still going
to have its own internal data structures for storing things, so adding
XML can be done _later_ as an additional step put into the middle of
the utility (no change needed to the "modules" on either side to add
on XML)...so, slow down a bit! Woah, horsey, woah! ;)
Beth :)
Beth
> Phil wrote:
> > I think getting instructions canoncalised should be possible, and
that
> > canonicalising comments would also not be too hard, but
programatic
> > macros, which are a meta-language, seems to add too many layers.
>
> Yes, macros would be a pain. On the one hand you've got some
assemblers
> that don't even have macro capabilities, some assemblers like RosAsm
that
> don't have very *good* macro facilities, and then you've got MASM
and
> HLA at the other extreme with extremely powerful macro facilities.
There
> are only two possibilities: (1) write a preprocessor for each of the
> assemblers
> to handle the canonical macro form (which I think is a really *bad*
idea),
> or
> you use the "lowest common denominator" approach (which is probably
the
> best idea). Unfortunately, the lowest common denominator is no
macros at
> all.
I had just thought about, at least at first, just spitting it out "as
is" in a comment and flagging a "warning" in some "log file" that the
conversion didn't take place or whatever...leaving it to "manual
translation" because it couldn't be done automatically...
> Personally, I wouldn't want to see a lot of "gold plating" in this
tool.
> There is no better way to guarantee that it never gets written than
to
> create a specification for it that would require more effort to
develop
> the conversion utility than it would take to manually convert the
header
> files.
No, the thing that'll more ensure that it never gets written is if no
developers - such as yourself - bother to sign on to the project so
that they can access and contribute to the code base so that no source
code is created whatsoever...which is kind of "never get written" by
definition, wouldn't you say? Or is that too _practical_ and not
"theoretical" enough for you?
> Beth, you might be excited by all the possibilities of such a tool,
but just
> keep in mind that it's going to be used to convert just a few sets
of header
> files (e.g., Win32, Linux, XLib, GNOME, and BSD) into assembly.
No, dumbo; I'm "Project Manager" over on the page devoted to it in
SourceForge...I'm low on developers (only Yeoh - bless his heart - has
signed up..._you_ haven't bothered, even though it's basically half
your idea and making it "generic" was to handle _your_ HLA
requirements...it's quite possible, you know, that the LuxAsm team can
just do the dedicated "C -> NASM" (eventually, "C -> LuxAsm")
convertors ourselves, per T.M.Sommers' advice on not bothering being
"generic"...yet, pardon if I'm a touch annoyed here, but I wrote to
SourceForge and FSF about the "licence" issues, I created the
SourceForge project and spent a while creating a mailing-list and
tweaking all the project settings, I took the time to convince the
LuxAsm team this would be a great idea, I stuck by my pledge to still
help you with the "portable GUI library" even though I'm with LuxAsm
(but the two "overlap" a lot that working for one can be working for
the other, using things like this "generic" tool :), I sent out an
Email asking for developers, I put together a webpage,
blah-blah-blah...and you won't even send back an Email of "okay, I'm
on-board!", let alone take two minutes max to create a SourceForge
account and send me the username? As I say, Randy, pardon if I'm
sounding a touch annoyed by all of this but perhaps spoken aloud you
might realise why...going "generic" was specifically so that I could
also help HLA as well as LuxAsm at the same time...I do this and I
don't even get a "show willing" response from you? I know you do have
lots to do but considering you're writing these long debates on here,
one more short Email of "you've set up the project, great!" or
something is much less effort than these posts here...thank you, Yeoh,
for being the only one who said "yeah, great stuff, sign me up!" for
all the effort I put into it...especially because you weren't actually
one of the ones who came up with the idea or the "canonical form" and,
as a RosAsm user, probably don't give a flying fudge about HLA...yet
you still signed up on the "potential" the project had...it's not like
I was even asking for anyone to write any code, just sign up to the
mailing-list to have "idea conversations" just like this one here, as
"consultants" are as good as "developers" during the planning phase at
the very least...nothing more than that)...
Being low on developers, I'm "selling" the project to interest people
with its "future potential"...what it'll eventually do...what the
final project "aims" are...blah-blah-blah...
But, I would have thought you'd have twigged that when I was
suggesting just using "an array of structures" and just the C
pre-processor (very basic to begin with) that I _was_, indeed, not
bothering with "gold plating" to begin with and, as you suggest,
focussing on "up and running" first to make sure the project gets
underway...also, that Email I sent you and the LuxAsm team about
joining up to the project was _also_ another part of the focus on "up
and running" as soon as possible...
Yet, pardon if I'm a touch annoyed, I get particularly "pro-active" in
writing to strangers to find out about "licence" things, try to
convince the LuxAsm team that this "generic" tool is useful for us to
work on, set-up the project, create the webpage (drew some nice
graphics and selected a colour scheme and everything), send out the
announcement, blah-blah-blah...and get no reply from you but being
told off for trying to get things "up and running" quickly - which you
paradoxical advise later I should be doing _when I already am_ doing
that - and avoiding "gold plating"...while you're talking about XML
parsing and some "macro pre-processor" to handle "HLA -> MASM"
conversion (something you've said shouldn't be bothered with at first,
as it's not particularly useful) and haven't even "shown willing" with
a short Email to all the efforts I've put in thus far...
I'm a touch annoyed at being told off for already doing exactly what
you advise me to do...while you go off talking about "gold plating"
over here rather than on the mailing-list I set up specifically for
the planning discussions (and not just my "announcement" Email told
you of the mailing-list but the SourceForge project page tells you of
it so that shows you probably haven't even looked at it for all the
effort I put in...thank you very much, I must say)...which means more
effort on my part copying this stuff over to the mailing-list archives
at some point, like Yeoh did with LuxAsm...which, by the way, Yeoh,
was a tremendously good idea and thanks 100% for making that effort to
keep the conversation on the newsgroup into the project archives for
looking at later...
I stressed a number of times in those posts which went to the LuxAsm
team and yourself that I was going to focus on dealing with _our_
issues first and was putting "gold plating" to one side...I'm NOT
"getting carried away" at all, as the talk of the utility's
"potential" is merely the "salespitch" to interest developers by
telling them where the project would eventually head in due course...
And the point everyone is missing here is that all that "HLA -> MASM"
stuff might be not that useful but the whole point is that you _GET IT
FOR FREE_ from using the "canonical form"...no extra effort
required...it really isn't "getting carried away"...because I'll tell
you what is "getting carried away": that's talk of XML formats and
dealing with macro complexities with macro pre-processors and stuff (I
was kind of thinking they could just, at first, be output "as is" in a
comment with an entry in the "log file" saying "could not convert!" so
that it can be done manually...sound like "getting carried away" to
you?)...
So, don't you take that tone of voice with me, Mr.Hyde...I've told
everyone before that you get my support because I think what you're
doing is right...in this case, though, pulling some "high and mighty"
preachy thing at me for "getting all excited" like I was some dumb
schoolgirl, while, in fact, it's _you_ who's going on about "XML this"
and "highly complex macro that" who hasn't bothered to even "show
willing" on all the "pro-active" effort I've put in to trying to get
something _concrete_ for the project to develop from, who's "getting
all excited"...actually, now you've pulled this "listen to teacher"
thing on me that you've never done before, I partially appreciate why
Rene and Wannabee don't much like it...
Let me spell it out, in case you got the wrong impression: I respect
my elders when my elders show respect and act in a manner deserving of
respect...up to now, that's been the case that I've always supported
you (including twisting the arms of the LuxAsm team that this
"generic" idea can benefit everyone that we should do this...though,
originally, of course, I was doing it to assist both HLA and LuxAsm
simultaneously and keep to what I said about assisting you with that
"portable GUI library")...don't go and ruin that for no particular
reason by being totally unthinking to all the efforts I've gone to so
for and telling me off like a naughty schoolgirl when, thus far,
everyone else has just talked "theory" but I'm actually trying to put
it into practice...and, yes, I _was_ concentrating on "up and running"
first...that's actually what the "binary" suggestion was all about
because cutting out some "XML" in-between is exactly that...XML is a
great idea and all the stuff about being able to read it and modify it
is great too...but I was skipping that, at first, _exactly_ to
concentrate on the _basic functionality_...it must _convert_ something
first then worry about "making it pretty and user-friendly" later...
> The need to convert HLA header files to MASM header files isn't that
> important.
You're the one talking about converting complex macros...at first, I
was thinking of just outputting the "complex" stuff like that "as is"
in a comment for manual "tweaking"...but, as, indeed, the original
purpose is "C -> NASM / HLA" then perhaps the very basic C
pre-processor stuff can be handled just for that...working out a
better solution to this was something I was reserving for "stage
two"...
> Certainly, converting TASM to C or C to Pascal won't be that
> interesting to the people contributing to the project.
Yeah, I know; That's why I was only talking about C, HLA, NASM at
first...the other stuff was merely an "advert" to how this "modular"
"generic" stuff can go on to provide greater things...it was,
basically, a response to T.M.Sommers' perfectly valid question: "Why
do it that way rather than create a bunch of dedicated convertors?"...
> The idea, quite frankly is to allow the development of a decent set
of
> Win32/Xlib/Linux/etc., header files without that work being
duplicated
> a dozen times.
Now you're just getting annoying; I know exactly what the idea is...in
case you forget, it was _MY_ fudging idea!! And _I_ came up with the
idea, indeed, to solve the immediate problem of Xlib / Linux (I wasn't
even going to go as far as Win32...that stuff was just a useful "side
product" that _you_ could make use of...LuxAsm doesn't need Win32 at
all)...
And when I mention that "binary form" at first, this is _exactly_ "up
and running" and concentrating on the immediate problem rather than
pissing about with XML parsers, complex macros and other "gold
plating"...that stuff is great and I'd support the XML idea and stuff
but I _was_ concentrating on getting things simply _working_ at
first...which, of course, included resolving that "licence" issue (I
wrote to SourceForge and FSF to see what they would say about it),
setting up a project, fielding for developers who might be interested
(and, so, I have to tell them what the "final objective" is...it was
NOT "getting carried away", it was explaining the project
objectives...or do you reckon tons of people would sign on to
developing if I'd just said: "it's a great idea...can't tell you what
it is or what it'll Hope to eventually achieve...just sign up
completely blind to what the project actually is!!"??), etc....
Because another important ingredient in "up and running first" is to
do some _concrete_ things to make it happen rather than "debate
theory" all day long...you've done fudge all so far but say "use a
canonical form!"...a fantastic idea, of course (and don't think I
hadn't basically thought of that myself...you merely provided the
correct terminology for what I'd intended all along)...but I'm just
really annoyed at this...I put in all this effort, I exactly
concentrate on getting something "up and running" and all that
stuff...and then get told off like a naughty schoolgirl for being
"over-excited" when that was exactly what I was NOT doing, while
everyone else - you included - _are_ doing that...talking bold ideas
all day long, can't be bothered to do something as practical as sign
onto the project I've set-up for this because you're having too much
"excited" fun talking theory about it rather than assist me - who's
had to do this all alone so far, despite it NOT being solely my idea -
with even a basic short Email of support or something...
> Best to keep the
> definition of the canonical form as simple as possible,
Such as, perhaps, ignoring the fudging "XML" stuff for a second and
simply getting it work with a basic internal binary form at first
(something that can be easily "upgraded" to that XML stuff later)? Oh,
yes...that's right...that's what _I_ was suggesting while you were
dreaming of XML "gold plating"...
> to reduce the effort
> needed to write the translators, so mere mortals can actually
contribute.
An excellent idea! So, out of interest, if "mere mortals" are meant to
be "contributing", where are they contributing to? Oh, yes...that's
right...the project at SourceForge that I went to a lot of effort
setting up that you haven't been bothered to contribute to by even
signing up or even a short Email saying "Great! You set up the
project!" or something like that...
Thus far, I have Yeoh signed up as a developer to the _concrete_
things I've been trying to do while you talk "theory" all day
long...and he's actually a happy RosAsm user (he's got the most
"demos" on Rene's webpage, if you look :)...a learner, he tells me, so
that would be "mere mortal" to you, I guess...hey, I've got no
problems with the "mere mortals"...it's the "assembly gods and gurus"
who're doing my head in here...
> And, Phil, I'm with you. The canonical form should be human
readable.
[ I only suggested otherwise for this "up and running" thing, by the
way...I totally have NO problems with "human-readable" because I'm the
one trying to get Rene's "source code libraries" and "source code in
the executable" stuff over to LuxAsm in addition to the standard
binary stuff...but "human-readable" is a _secondary_ thing...it's NOT
necessary for "up and running"...I _was_ concentrating on "up and
running" and "human-readable" can be added later (there's room to
simply "insert" the XML later in what I was proposing)... ]
> If for no other reason, it makes it a *whole* lot easier to verify
the
> C->canonical translator.
Yes, that's a good point...hard to take seriously at the moment,
though...
> It also makes it easier to maintain the canonical
> form without having to "recompile" older files every time a minor
change
> is made.
But, for an "up and running" quick solution, saving the binary
intermediate form was the thing I suggested...when the conversion
works, the XML can be added on to make it "human-readable" and
editable and so forth...
Beth :)
Beth
> Randy wrote:
> > And, Phil, I'm with you. The canonical form should be human
readable.
> > If for no other reason, it makes it a *whole* lot easier to verify
the
> > C->canonical translator. It also makes it easier to maintain the
canonical
> > form without having to "recompile" older files every time a minor
change
> > is made.
>
> And diffs that make sense too. Easier to inspect, and far friendlier
> to RCS/CVS.
>
> HD space is cheap, human time isn't, so I'd
> go for the verbose format that will save me time any day.
Agreed; Except to note that the time you "save" as a user requires
more of the developers' time to actually implement...my sole reason
for suggesting the "binary" form is that we can "skip" this at first
just to get it working...then return later to add the, indeed,
excellent XML or other "human-readable" form _later_...
One thing that may have escaped people's attention was that the
"Pascal programmer" who "turns up later" in my example is
_third-person_ and is NOT part of the original example I was
giving...this should have hinted that what I was thinking was "here's
the basic thing for ASM people BUT it's a flexible enough idea that if
an interested Pascal programmers who wants to extend the tool signs
up, they can develop it"...the _third-person_ on that prospect was
actually exactly as I'd said to the LuxAsm team on the mailing-list
(you wouldn't know about this Phil but I CC'd this to Randy so he has
no excuse) that I'd only be "Project Manager" on the SourceForge page
for the _basic_ stuff of getting it working to convert C Xlib / GTK /
Linux header files to NASM, HLA and, ultimately, LuxAsm syntax for my
own work but would _delibrately_ plan and write it in an "open-ended"
/ "flexible" way so that when I've finished with it to get what I
want, then I can happily hand it over to some Pascal programmer who
wants to take it further...to make it explicit: this is _open-source_
and hosted on SourceForge so, in that spirit, though I only personally
want a fraction of its potential for Xlib / GTK / Linux, I'd make sure
that the project is "flexible" enough - GCC-like in being "modular" -
that it could be extended by others at their discretion for _their_
needs...I've said this now - at least to the LuxAsm team and Randy -
more than once that you, Phil, might not know this so you're off the
hook but Randy has no excuses and should have known and seen that my
"binary form" stuff was _simply_ a case of "up and running" for
"personal use" as quickly as possible...hey, I have LuxAsm and the HLA
"portable GUI library" to work on...this tool is part of making that
easy but the stuff about "adding Pascal"...it ain't me who's going to
be doing that (hence the third-person when I was talking about it),
I'm just making sure that it's "flexible" enough that someone else
_could_, if they wanted to...
Beth :)
Beth
> Beth wrote:
> > Perhaps I'm wrong but I get the distinct impression that we have a
> > case of "creating problems for the sake of creating problems"
thing
> > going on here...because they've already pre-judged that they don't
> > like the idea so are trying to "fit the facts" and "create
problems"
> > into making it not happen...
>
> Precisely. It's really easy to add a ton of "gold plating" to the
specs
> right now and then wind up with something that is far too complex
> for its intended purpose.
And an XML parser isn't "gold plating"?
Matching up "tags", case-insensitive attributes, allowing values to be
quoted or unquoted, reasonable error messages for parsing problems,
etc....a mini "web browser" inside the tool, to satisfy "curiosity" in
being able to read the intermediate form?
No, don't get me wrong...I totally _Love_ this XML idea...BUT you talk
about how it's important to get the project "up and running" and that
I shouldn't "get over-excited" about tons of "gold plating" ideas when
my "binary" suggestion was _exactly that_...get it working first, then
worry about "user-friendly features"...
> Frankly, I'd just define a canonical format in human readable form
> and leave it up to the assembler authors (who are interested) to
> develop their translator (canonical->assembly) for their particular
> product (using whatever language they prefer).
One approach; I was going for even less "gold plating" than that, in
fact...unlike LuxAsm's design, I _wasn't_ going to initially have
these "modules" dynamically loaded (compiled straight in at
first...making it more "flexible" was "stage two" :)...and you just
include the "canonical form" C header file with the various "records"
defined as structures and work from that...
This gets things done quickly but leaves perfect room that the
"modules" can be "decoupled" to be dynamically loaded and leaves
perfect room for some "XML" form to be inserted (e.g. it goes C ->
internal structures -> HLA at first...then you can add C -> internal
structures -> XML file -> internal structures -> HLA _LATER_)...
> The "open development" project could be the C->canonical translator.
"Could be"? The "open development" project has been set up and exists
_already_ and I've been sitting around waiting for you to ask to be
signed on as a developer or to at least join the mailing-list to have
these kinds of discussions there...
You did get the Emails I sent, didn't you? They went to your Webster
address...if not, then, okay, I can retract some of my annoyance at
you in the other posts here...because if you didn't get the Emails
then perhaps you didn't know (though, that "over-excited" comment
still stands as really annoying and uncalled for)...
> And I would keep the
> canonical form as simple as possible for the first version.
Yeah, _exactly_ my thinking...and I would have thought that the
internal structures that the files were parsed into was the actual
_lowest form_ to begin with...and something "human-readable" would be
the next lowest form..._THAT_ was what I was talking about with the
"binary" stuff...that is the _lowest of the low_ in "form" terms...so
that's why I proposed starying there rather than coding some "mini web
browser" inside the utility to begin with...
"Up and running first" suggests to me that _only_ the direct things
needed for actual conversion should be done first..."human-readable"
is beyond that...the binary structures are going to be there, anyway,
just to get the thing to work and convert anything...that was what my
suggestion was _exactly_ about...binary - the internal form that the
utility has got to have in parsing the file - is the _LOWEST_
form..."human-readable" is one form higher than that...
But, sure, _IF_ you can be bothered to "contribute" your developer
username to me to add you onto the project, then if everyone thinks
the "_second_ lowest form" of something "human-readable" is not too
complex a starting point then we can start _NOT_ at the "most simple
as possible" but the _next most_ "simple as possible" form with a
readable text file as intermediate form...that's perfectly okay but I
was going to start with "binary" at first because then things could be
done quicker to keep with open-source's "release early, release often"
spirit (as SourceForge strongly recommend) without that all being
delayed because of "debates" about what this "readable form" would
look like (I mean, look at Phil's post giving us the XML idea...even
he's thinking to himself: "it could look like this...no, maybe it
should look like that...or it could look _something_ like that,
anyway"...if Phil's debating with himself over how it's going to be
then you've got to consider how this'll be on an "open source" project
with many developers: "I want 'MOV' to be its own tag!" / "No,
'instruction' should be the tag and 'mov' is an attribute!" /
etc....there's no "debate" with the binary form, so to speak...you're
not arguing "syntax" - which, come on, posting here you should know
_ISN'T_ ever a topic people easily agree on - you're just arguing what
should and shouldn't be in the "canonical form"...once everyone's
happy with what's included and what's excluded then you can formulate
the "text equivalents" to put into a nice editable file...I _WAS_
doing what you're suggesting...I was merely being even more
"finely-grained" once more...concentrate on _what's in it_ and _then_
you can think about "what it'll look like"! Which, short of a miracle
that people can agree on a _syntax_ issue for once, could end up
delaying the first release that actually does something with some big
debate on whether it's XML, what's a "tag" and what's an "attribute"
(XML itself, unfortunately, doesn't care either way and doesn't assist
with making that clear) or shall we use something else and debate if
it's "semi-colons" or "periods" to terminate statements or what? I was
proposing the "binary" form because that cuts out the "debate" on
these things until it's actually working...that's all ;)...
> We can always
> add additional features (that turn out to be highly desirable) later
on.
Preaching to the converted (pardon the pun ;)...that was _exactly_
what I was going for until, in fact, _you_ started talking about
parsing highly complex macros with a fully-functional XML reader /
writer and so forth..._you lot_ are getting "carried away", not me...I
was going for the absolute simplest form to begin with...a C program
that reads a file, strips the syntax and then puts a different syntax
back in...that's it...nothing more...that does the job but it's
perfectly possible to _then_ add the "gold plating" stuff on
_later_...
> Initially, I'd just recommend handling the following:
>
> 1. constant declarations
> 2. type declarations
> 3. structure declarations
>
> That will cover about 90% of what's interesting in a typical C
> header file.
Yup, totally; Exactly what I had planned...
The stuff about "Pascal -> C" was _solely_ a response to T.M.Sommers'
question: "Why take this approach and not write dedicated conversion
utilities?"...that's a perfectly reasonable question and _to answer
it_, you do have to consider the later "gold plated" future
_potential_ that the tool has...
> And I'm still a *big* believer in a human readable (and
> maintainable) canonical file format. I feel that the C->canonical
> translation would take place once; we'd then maintain the
> canonical form manually thereafter (working in DIFFs as
> the C header files change; as they don't change frequently
> this won't be a maintenance nightmare).
Yeah, that's a valid approach and I wouldn't disagree...but I would
stress that "human-readable" is NOT "as simple as possible"...it's one
notch higher up than I was proposing with the binary form...you are,
in fact, at the "small amounts of gold plating" level, I was talking
about the "NO gold plating whatsoever" level earlier...so, please,
drop that "over-excited" comment because I was actually being very
plain and boring as my starting point...just that it "works" and
that's about it...
But, true enough, the "human-readable" thing (perhaps XML) is a
"slightly excited" idea, not an "over-excited" idea...if you're a big
believer and, of course, you are going to join on as a developer to
the project that's been sitting there waiting for you and the other
interested parties who said they were on-board to sign up (so far, I
have Yeoh, who actually wasn't one of the ones dreaming up this idea
but thought it sounded good when I explained it...kind of condemning
when he was there ready to sign up while those who've been professing
an interest and making up these ideas, who I sent an Email - yes,
_you_, Mr.Hyde - haven't done so yet)...
Beth :)
Beth
> I think that anything which can't cope with
>
> #define ACS_ULCORNER NCURSES_ACS('l') /* upper left corner */
>
> will be dead in the water.
Agreed; But this utility has been born of _need_...both LuxAsm and HLA
could do with the Linux / Xlib equivalents of hutch's MASM32
"Windows.inc" or Guga's "equates list"...Win32 already has many
efforts that have put together some basic ASM header files but Linux
is a C obsessed world and, as far as I'm aware, they don't exist...so,
we've got to make them...and I'm thinking - after manually converting
a number of these header files to know that _ANY_ assistance is worth
making (hutch has his own utility for creating the files...and hats
off and R.E.S.P.E.C.T. to Guga who is simply ploughing through the
stuff manually piece by piece for RosAsm and has actually done a
tremendous amount there...I might not be over-enamoured by RosAsm
generally but that stuff is simply "hard sweat" and deserves
recognition) - that a utility is needed...now, I'm doing this for
LuxAsm primarily (which will need NASM syntax at first before LuxAsm
itself is "up and running" sufficiently to be able to assemble its own
LuxAsm syntax files...LuxAsm is also going for "self-assembly" like
RosAsm...just we're using NASM - which runs on Linux happily - rather
than ASM32 for our "first draft" version :) BUT HLA's upcoming
"portable GUI library" could also do with something like this too but
in HLA syntax...hence, why write two utilities when you could write a
"flexible" utility that could handle HLA, NASM and evenutally LuxAsm
syntax?
And there the idea was born...the stuff about it going on to support
MASM and RosAsm and C and Pascal and stuff was just pointing out the
"potential" it can eventually develop...that, yup, hutch could perhaps
benefit from this for his MASM32 (hence, it's an "advert" to hutch to
see if he's interested :) and even Guga might be able to do so too
(not sure about that one...might be "unethical", if not a difficult
conversion and who's going to volunteer to add on the "module"
necessary? Anyway, the possibility is there...perhaps, in fact, as
Yeoh is a developer and a RosAsm user, it might be him who contributes
that "module" and then helps Guga along that he can convert things
much faster so that RosAsm can have DirectX v10 support, say, within a
week or two of Microsoft's release...when much of it is automated, it
means that _all_ the assemblers could bring their support for various
things up-to-date quicker and easier...at least, that's the basic
idea...in practice, it might not happen quite so easily or
whatever...but that's the "aim" of the project eventually :)...
So, indeed, "tricky" little "#define" statements like that _are_ an
issue...but it's the issue we're directly aiming at solving...my point
being, to eventually get to it, that the utility is being developed to
_fulfill a specific purpose_ and isn't merely "theory" so, yes,
awkward things like this will have to be solved...but this is, of
course, the _point_ of the project...and it will be being used on
_real_ examples because it's being done for a _real_ problem, which
are sure to throw up all these issues as we work on it...
That is, the _practical_ edge changes the picture slightly in that,
yes, it's complicated to work out what to do there but _something_ has
to be done (even if it's a "cop out" in just spitting it out "as is"
in a comment and then flagging up a "please manually convert this, as
I don't know what to do with it" warning :)...
Ah, of course, the way to phrase what I mean is: "necessity is the
mother of invention"...a bit like the space race: "we've _got to_ put
someone in space...so, if we have to invent Teflon* and special rocket
fuel to do so, then invent Teflon and special rocket fuel we will!" ;)
Beth :)
[ * Yes, I know...this is actually an "urban myth" in that it was
invented _prior_ to the space race and was just one of the first major
useful uses of it...but I'm going with the "urban myth" in order to
make the point, as most people do still believe it was invented
specifically for the space race...the actual technologies invented for
the space race - because there are some - are just not as well-known
as this "urban myth", which isn't actually true...so, to make the
point, I use the well-known one - even if an "urban myth" - so people
understand what I'm talking about...but there's no need to post to
correct this, as I'm interested in astronomy and space and stuff,
anyway, that I do realise this "urban myth" already ;) ]
Betov
$oK2...@newsfep3-gui.server.ntli.net:
> And there the idea was born...the stuff about it going on to support
> MASM and RosAsm and C and Pascal and stuff was just pointing out the
> "potential" it can eventually develop...that, yup, hutch could perhaps
> benefit from this for his MASM32 (hence, it's an "advert" to hutch to
> see if he's interested :) and even Guga might be able to do so too
> (not sure about that one...might be "unethical", if not a difficult
> conversion and who's going to volunteer to add on the "module"
> necessary? Anyway, the possibility is there...perhaps, in fact, as
> Yeoh is a developer and a RosAsm user, it might be him who contributes
> that "module" and then helps Guga along that he can convert things
> much faster so that RosAsm can have DirectX v10 support, say, within a
> week or two of Microsoft's release...when much of it is automated, it
> means that _all_ the assemblers could bring their support for various
> things up-to-date quicker and easier...at least, that's the basic
> idea...in practice, it might not happen quite so easily or
> whatever...but that's the "aim" of the project eventually :)...
Hmmmmm!... This thread is getting more and more funny, with
everything going on, as if nobody was understanding what is
going on... :)
So, let me try to clarify some "details":
* I have always been, in the past, in favour of sharing all
possible things between the various Assemblers Projects. I
have for example, offered my Equates List to Thomasz, and to
Jeremy (even though Jeremy Assembler -GoAsm- is a closed
Sources one -...-), with the associated Methods for fast
computing, and so on... (they were not "interrested"...
Well... None of them ever behaved like i did... Well...
All of them tend to behave "sectarian"s... Well... OK to
me...).
* Now, since the recent attempts of Master Pdf, we _do_ have
to seriously protect our data and hard work. As nobody seems
to understand what and why, let me first recall what Master
Pdf was, and is, actually doing:
1) When he made up his mind that he was a thing of the past
and utterly overpasses by a new generation of Assemblers
Authors, and that he had no more enough time to recover his
"leadership" in the area by doing any serious work (too late),
he wrote an HLL Pre-Parser and sold it under the name of
"Assembler".
2) When he made up his mind that no Assembly Programmer on
earth would ever consider using that shit, he said it was
written for "teaching beginners".
3) When he made up his mind that other Assemblers were much
better adaptated to "teach beginners" than his shit, he found
a Publisher to sell his Pdf.
4) Now, he is making up his mind that, whatever he could do,
the day i will start actively promoting RosAsm, he could never
win the competition, he is trying to have his Webster becoming
the universal "reference" for everything available (for free)
in the Assembly Area. By the way, this is only a re-activation
of an attitude he always had (for example, some long time ago,
when a guy asked, at the Evil Board, "what about the dead APJ?",
he, of course, immidiately raised his hand up, to "offer his
"good will services" as a new maintainer of the APJ -...-).
Now, he is doing all he can, to make friend with the other
Assemblers Authors, having these Assemblers referenced from
his Site, with dedicated Pages, proposing materials about
"Compilers Theory", on purpose biazed Speed Tests , and so
on..., and redistributing everything he can do for free
(free of real work, of course).
The final goal, with all of this, is double side:
1) Becoming a universal Asm reference without doing anything.
2) Isolating RosAsm as much as possible, while we are not yet
over with the real hard work, and while ReactOS not yet ready
for end users.
So, now on, the war between Master Pdf and me will be
"absolute". Recently, though i like a lot a guy like JohnFound
and share most, if not all, of his ideas, i completely closed
any relationship with the FASM/Fresh so interresting group.
The things are clear and simple: If Master Pdf is allowed to
post messages at FASM Board without being kicked out, i have
no more anything to do there.
So is it for this OS Data Project: If Master Pdf, and Master
Pdf's supporters are inside, this is an Anti-Assembly project,
whatever real work could be done there.
For YeoHs, I do not know what he will do, but i would be a
bit surprised if he would go on contributing to this. The
guys using RosAsm and contributing to RosAsm are usually
not the more stupid ones, you know...
For Guga, you have no idea of the amount of very hard and
very boring stupid work he did all along the past year, at
collecting Data by hand, achieving now into a 3.5 Megas Files
of Infos that we are now going to turn into an ApiViewer.
This is not only the Equates List, which is completed since
some long time, now. This is also for all Structures, all Api
Functions, with Comments, and all the necessary informations
for building a Viewer providing all Links between all components
of this incredible amount of Data.
One year ago, we would have made all of this free work available
for all Assemblers Projects, and we would, much probably offered
all of this work Open Source, with a "ListBox" for conversion to
other Assemblers syntax, with simple parsers converting to the
other Assemblers Formats.
Nowadays, this is made absolutely impossible. We can no more
provide all of this work open and have master Pdf reusing it for
his own glory. So, we are actually studying how to release all of
our OS Data under a Closes Sources form with some organisation
that will, on purpose, make the Data recovering a real work, and
it will remain under that very stupid form as long as master Pdf
will remain a danger for the future of Assembly.
We had, very recently a pretty good example of Master Pdf attitude,
when steeling others works, for free, with my own "Underscore"
example: I thought he would not contest the fact, as, in a thread
called "SpAsm Review", right here, several years ago, _he_ said
publicly that this was a real great innovation of mines and a real
good idea. Nowadays, whereas he re-uses the idea for HLA Numbers
format, he is saying that this was existing years before i
"re-invent" this. Well, we can expect that a similar thing would
happend with Guga hard work: "All of this was taken from MicroSoft
Material and other freely available Infos found on the Net, so you
created nothing at all... and this work is mine as well...".
Betov.
hutch--
It will depend on how the C header files or libraries are constructed
when trying to automate an assembler include file. The Microsoft .H
files almost defy automation and while I have been playing with linear
scanners recently, you effectively need the parsing capacity of a C
compiler to get the stuff out of it that you need.
I got the prototypes for the APIs directly from the decorated name
format functions in the libraries but a large amount of the info in
windows.inc was partially automated and the rest was done manually
which took a very long time.
If the C header files for linux are not the mess that the Windows ones
are, it may be a lot easier to do. The old C headers for Windows were
not hard to do and there was a utility h2inc that Microsoft used to
supply that would do it so its something like that to do the job.
#define equate value
is reasonably easy to parse out of an include file but some of the
nested structures with unions mixed with C and c++ comments were no
joy to try and extract.
It probably would be more useful if the most used library functions
were done in priority to the rest as this would make more
functionality available faster.
This much, for any assembler to succeed, they really do need good
includes as it means the programmer can concentrate on code rather
than endlessly chasing prototypes for function calls.
Regards,
hutch at movsd dot com
qual1
> "Beth" <BethS...@hotmail.NOSPICEDHAM.com> écrivait news:VL_Xb.39
> $oK2...@newsfep3-gui.server.ntli.net:
>
>
>>And there the idea was born...the stuff about it going on to support
>>MASM and RosAsm and C and Pascal and stuff was just pointing out the
>>"potential" it can eventually develop...that, yup, hutch could perhaps
>>benefit from this for his MASM32 (hence, it's an "advert" to hutch to
>>see if he's interested :) and even Guga might be able to do so too
>>(not sure about that one...might be "unethical", if not a difficult
>>conversion and who's going to volunteer to add on the "module"
>>necessary? Anyway, the possibility is there...perhaps, in fact, as
>>Yeoh is a developer and a RosAsm user, it might be him who contributes
>>that "module" and then helps Guga along that he can convert things
>>much faster so that RosAsm can have DirectX v10 support, say, within a
>>week or two of Microsoft's release...when much of it is automated, it
>>means that _all_ the assemblers could bring their support for various
>>things up-to-date quicker and easier...at least, that's the basic
>>idea...in practice, it might not happen quite so easily or
>>whatever...but that's the "aim" of the project eventually :)...
>
>
>
> Hmmmmm!... This thread is getting more and more funny, with
> everything going on, as if nobody was understanding what is
> going on... :)
>
> So, let me try to clarify some "details":
Rene your idea of clarifying details is like asking a drunk sailor in
the middle of the ocean if he can swim?
>
> * I have always been, in the past, in favour of sharing all
> possible things between the various Assemblers Projects. I
> have for example, offered my Equates List to Thomasz, and to
> Jeremy (even though Jeremy Assembler -GoAsm- is a closed
> Sources one -...-), with the associated Methods for fast
> computing, and so on... (they were not "interrested"...
> Well... None of them ever behaved like i did... Well...
> All of them tend to behave "sectarian"s... Well... OK to
> me...).
>
> * Now, since the recent attempts of Master Pdf, we _do_ have
> to seriously protect our data and hard work. As nobody seems
> to understand what and why, let me first recall what Master
> Pdf was, and is, actually doing:
Glad that you know Mr. PDF so well that you have to expound on his
thought processes. Don't you have any of your own? Must not be bright
enough.
>
> 1) When he made up his mind that he was a thing of the past
> and utterly overpasses by a new generation of Assemblers
> Authors, and that he had no more enough time to recover his
> "leadership" in the area by doing any serious work (too late),
> he wrote an HLL Pre-Parser and sold it under the name of
> "Assembler".
>
Thank God your not jealous of that Pre-Parser that can do more than
RosAsm. I would hate to feel you were compromised in any way.
> 2) When he made up his mind that no Assembly Programmer on
> earth would ever consider using that shit, he said it was
> written for "teaching beginners".
>
Where as you have stated you don't have time for beginners so they
should wait untill you have your product finished in what 100 or 200 years?
> 3) When he made up his mind that other Assemblers were much
> better adaptated to "teach beginners" than his shit, he found
> a Publisher to sell his Pdf.
Where as you couldn't get a toilet paper manufacture to publish
yours.... Hey Rene, maybe you could get a toilet paper manufacture to do
this for you. That way you won't be jealous of Master PDF, and you will
accomplish something worth while in life. Cleaning up your own crap.
>
> 4) Now, he is making up his mind that, whatever he could do,
> the day i will start actively promoting RosAsm, he could never
Competition requires skill not delusions. Rene, take your medicine.
> win the competition, he is trying to have his Webster becoming
> the universal "reference" for everything available (for free)
I thought you liked the GPL and Free... Oh that is right you want
everything to be free for you.
> in the Assembly Area. By the way, this is only a re-activation
> of an attitude he always had (for example, some long time ago,
> when a guy asked, at the Evil Board, "what about the dead APJ?",
> he, of course, immidiately raised his hand up, to "offer his
> "good will services" as a new maintainer of the APJ -...-).
Where as you offered your good will services to promote 3rd world
countries, and poor people everywhere against large corporations and the
evil Americans. Your right he made the wrong decision. I guess that is
where you get your genius from makeing such grand statments.
>
> Now, he is doing all he can, to make friend with the other
> Assemblers Authors, having these Assemblers referenced from
> his Site, with dedicated Pages, proposing materials about
> "Compilers Theory", on purpose biazed Speed Tests , and so
> on..., and redistributing everything he can do for free
> (free of real work, of course).
>
Rene, I am so glad that you are jealous of Randall's friends as they
still haven't lined up to kiss your ass. Boy that word free is really
pissing you off. What no more control for Betov? Must be your multiple
personalities getting out again.
> The final goal, with all of this, is double side:
>
Yes, Rene is trying to double side to get just a little bit of sympathy
from other people. Poor, Poor, Rene. All that work for nothing.
Achievement nothing.
> 1) Becoming a universal Asm reference without doing anything.
Rene's goal is to squash all Asm Reference not belonging to him that he
cannot control. If you could control your bladder as well as you try to
control other people you would not get wet all the time Rene. Go buy
some more diapers Rene.
>
> 2) Isolating RosAsm as much as possible, while we are not yet
> over with the real hard work, and while ReactOS not yet ready
> for end users.
>
RosAsm doesn't need isolation, we can just listen to you in a drunken,
jealous, envious, egotistical rage spout on about how you have been
totally abused by the online ASM community and if only someone would
come help poor Betov.
> So, now on, the war between Master Pdf and me will be
> "absolute".
Absolutely rediculous :) Rene you could earn some credability by getting
RosAsm published on Toilet Paper. I promise I would wipe my ass with it.
Hell I would even read it. Probably laugh too much to take a crap.
Recently, though i like a lot a guy like JohnFound
> and share most, if not all, of his ideas, i completely closed
> any relationship with the FASM/Fresh so interresting group.
Why close your relationship with the FASM/Fresh guys. Not getting your
way? Can't defend yourself with that great intellect?
> The things are clear and simple: If Master Pdf is allowed to
> post messages at FASM Board without being kicked out, i have
> no more anything to do there.
Yeah, I can see where that would cause a 2 year old to pout. I'm sure
the Fasm/Fresh guys are enjoying a beer and waiting for you to get your
Toilet Paper published.
> k
> So is it for this OS Data Project: If Master Pdf, and Master
> Pdf's supporters are inside, this is an Anti-Assembly project,
> whatever real work could be done there.
Glad to see that you determine what is an Assembly Project.
I think Your Assembly Project on Toilet Paper would be much better use
of your time. I eagerly await your publication. Rene, think of all the
corporations and people that could gain wisdom by merely wipeing their ass?
Jeeze I came in for a crap and started reading RosAsm toilet Paper. I
think I'll start writeing this RosAsm crap from now on.
> For YeoHs, I do not know what he will do, but i would be a
> bit surprised if he would go on contributing to this. The
> guys using RosAsm and contributing to RosAsm are usually
> not the more stupid ones, you know...
>
I'm one of the more stupid ones Rene. I wait to hear the words of wisdom
that issue from your mouth. Oh Crap, you shit again Rene.
> For Guga, you have no idea of the amount of very hard and
> very boring stupid work he did all along the past year, at
> collecting Data by hand, achieving now into a 3.5 Megas Files
> of Infos that we are now going to turn into an ApiViewer.
Yet all the work Mr. Hyde has done is bullshit huh? Glad to see that you
at least praise those people that help you. I'm suprised you aren't
jealous of Guga, and his accomplishments.
> This is not only the Equates List, which is completed since
> some long time, now. This is also for all Structures, all Api
> Functions, with Comments, and all the necessary informations
> for building a Viewer providing all Links between all components
> of this incredible amount of Data.
>
> One year ago, we would have made all of this free work available
> for all Assemblers Projects, and we would, much probably offered
> all of this work Open Source, with a "ListBox" for conversion to
> other Assemblers syntax, with simple parsers converting to the
> other Assemblers Formats.
>
Right, we believe this line like all others. The fact still stands you
are not going to make it free. Why? because you aren't getting your way?
Instead of leading the community by example all you do is put down other
peoples efforts. Everyone owes you a swift kick in the Ass. Might jar
your brain a little bit Rene.
> Nowadays, this is made absolutely impossible. We can no more
> provide all of this work open and have master Pdf reusing it for
> his own glory.
Yes, being jealous is what its all about. Your so full of shit.
So, we are actually studying how to release all of
> our OS Data under a Closes Sources form with some organisation
> that will, on purpose, make the Data recovering a real work, and
> it will remain under that very stupid form as long as master Pdf
> will remain a danger for the future of Assembly.
I hope you make it so that only you can use it. This way we won't have
to debug it, debate it, or listen to any of your more interesting posts
about your great and glorious contributions to society.
>
> We had, very recently a pretty good example of Master Pdf attitude,
> when steeling others works, for free, with my own "Underscore"
Yes oh great God of Underscore. Glad you came up with something everyone
else has been useing for hundreds of years. Maybe you invented life also?
> example: I thought he would not contest the fact, as, in a thread
> called "SpAsm Review", right here, several years ago, _he_ said
> publicly that this was a real great innovation of mines and a real
> good idea.
I think what he meant was it was great you invented the Underscore and
could come up with such a good idea. Maybe you could develope a website
where you take the average user through your great discovery the
Underscore by Rene. I'll even contribute. Okay see that line. That is an
underscore. I invented it. I the Great Rene.
Nowadays, whereas he re-uses the idea for HLA Numbers
> format, he is saying that this was existing years before i
> "re-invent" this.
Since you are too dumb to read other people's works or programming in
general. Good argument. Lets see cause I didn't see that other people
invented it. I am the one true inventor. Drink more Rene.
Well, we can expect that a similar thing would
> happend with Guga hard work: "All of this was taken from MicroSoft
> Material and other freely available Infos found on the Net, so you
> created nothing at all... and this work is mine as well...".
Rene, please publish your manifesto toilet paper. It would wipe the
market up with such a creative and novel approach to Assembly language
programming that any programmer would be thrilled to use your product.
>
>
> Betov.
Please post more Betov as You provide me with so much material to expand
my insignificant brain with the truths of the universe that they are
incomprehensible to imagine. I would hold you in utter contempt but
refuse to alient my source of constant humor.
Regards,
John
Randall Hyde
>
> No, the thing that'll more ensure that it never gets written is if no
> developers - such as yourself - bother to sign on to the project so
> that they can access and contribute to the code base so that no source
> code is created whatsoever...which is kind of "never get written" by
> definition, wouldn't you say? Or is that too _practical_ and not
> "theoretical" enough for you?
Well, I'd have to find my sourceforge acct info somewhere :-)
Seriously, I am interested, I'm just snowed under getting ready
for a concert next weekend and I burn up all my free time
defending Rene's right to post whatever he wants to this newsgroup :-(.
Don't be annoyed. If it's a good idea (and I think it is), it will happen.
But in order for it to work out, it's going to take time and a lot of
communication.
Cheers,
Randy Hyde
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:%DZXb.19$oK2...@newsfep3-gui.server.ntli.net...
>
> No, dumbo; I'm "Project Manager" over on the page devoted to it in
> SourceForge...I'm low on developers (only Yeoh - bless his heart - has
> signed up..._you_ haven't bothered,
It would really help if you tacked on the URL to each post so people don't
have
to search for the link to the site. Some of us wouldn't even have a clue
where
to look :-)
> even though it's basically half
> your idea and making it "generic" was to handle _your_ HLA
> requirements...it's quite possible, you know, that the LuxAsm team can
> just do the dedicated "C -> NASM" (eventually, "C -> LuxAsm")
> convertors ourselves, per T.M.Sommers' advice on not bothering being
> "generic"...
Well, yes; making it generic is a good thing. And not just for HLA.
I see a lot of effort being duplicated in the Win32 header files people
make up for the various assemblers and what I'd like to see is that
work being done only once, so people can be more efficient. Having
a C->assembly conversion (even partial) would be nice, but I'd
even settle for *manually* maintaining the canonical form so that the
real work only has to be done once. That's my concern - having a
single team maintain the Win32 (or whatever) header files, so that
there is one source for defect corrections and maintenance, rather
than having to repeat those problems for each and every assembler.
Your goals are more loftier than mine; that's all.
> yet, pardon if I'm a touch annoyed here, but I wrote to
> SourceForge and FSF about the "licence" issues, I created the
> SourceForge project and spent a while creating a mailing-list and
> tweaking all the project settings, I took the time to convince the
> LuxAsm team this would be a great idea, I stuck by my pledge to still
> help you with the "portable GUI library" even though I'm with LuxAsm
> (but the two "overlap" a lot that working for one can be working for
> the other, using things like this "generic" tool :), I sent out an
> Email asking for developers, I put together a webpage,
> blah-blah-blah...and you won't even send back an Email of "okay, I'm
> on-board!", let alone take two minutes max to create a SourceForge
> account and send me the username?
Again, post the URL. I don't have a clue how to get on the list at this
point.
BTW, with respect to the GUI library, have you looked at wxWindows?
http://www.wxwindows.org/
> As I say, Randy, pardon if I'm
> sounding a touch annoyed by all of this but perhaps spoken aloud you
> might realise why...going "generic" was specifically so that I could
> also help HLA as well as LuxAsm at the same time...I do this and I
> don't even get a "show willing" response from you? I know you do have
> lots to do but considering you're writing these long debates on here,
> one more short Email of "you've set up the project, great!" or
> something is much less effort than these posts here...thank you, Yeoh,
> for being the only one who said "yeah, great stuff, sign me up!" for
> all the effort I put into it...especially because you weren't actually
> one of the ones who came up with the idea or the "canonical form" and,
> as a RosAsm user, probably don't give a flying fudge about HLA...yet
> you still signed up on the "potential" the project had...it's not like
> I was even asking for anyone to write any code, just sign up to the
> mailing-list to have "idea conversations" just like this one here, as
> "consultants" are as good as "developers" during the planning phase at
> the very least...nothing more than that)...
I appreciate what you're doing.
And as soon as I finish my obligation to proof-read the incoming chapters
on "Write Great Code", I intend to get more heavily involved in the project.
However, I'd warn you that a project like this isn't going to happen
overnight.
It will grow slowly. Once you have a few successes (and I will work to
ensure
that HLA is one of the early working examples), more assembly authors will
come on-line and participate. However, most of them are real busy working
on their assemblers right now, so we're going to have to prove it works
before they jump in and help.
>
> Being low on developers, I'm "selling" the project to interest people
> with its "future potential"...what it'll eventually do...what the
> final project "aims" are...blah-blah-blah...
I don't personally believe that we want to jump right in and get started
quite so rapidly. The projects requirements and specifications need to
be discussed in considerable detail before we jump in and find ourselves
headed down some dead-end path. Whether than discussion takes
place here or on your mailing list doesn't matter too much. But if we
held the discussion here, more people would participate and it will also
addressing those people who are whining about how we don't discuss too
much assembly language stuff around here.
> But, I would have thought you'd have twigged that when I was
> suggesting just using "an array of structures" and just the C
> pre-processor (very basic to begin with) that I _was_, indeed, not
> bothering with "gold plating" to begin with and, as you suggest,
> focussing on "up and running" first to make sure the project gets
> underway...also, that Email I sent you and the LuxAsm team about
> joining up to the project was _also_ another part of the focus on "up
> and running" as soon as possible...
Be careful though. This sounds too much like "code first and design later."
Though it can be discussed forever and nothing will get done, the truth
is that this is the type of project that is going to require a "buying-in"
by a lot of different people with their own vested interests (i.e., all
those assembler authors). So it's important to get the design half-way
right before jumping in and coding a solution.
> Yet, pardon if I'm a touch annoyed, I get particularly "pro-active" in
> writing to strangers to find out about "licence" things, try to
> convince the LuxAsm team that this "generic" tool is useful for us to
> work on, set-up the project, create the webpage (drew some nice
> graphics and selected a colour scheme and everything), send out the
> announcement, blah-blah-blah...and get no reply from you but being
> told off for trying to get things "up and running" quickly - which you
> paradoxical advise later I should be doing _when I already am_ doing
> that - and avoiding "gold plating"...while you're talking about XML
> parsing and some "macro pre-processor" to handle "HLA -> MASM"
> conversion (something you've said shouldn't be bothered with at first,
> as it's not particularly useful) and haven't even "shown willing" with
> a short Email to all the efforts I've put in thus far...
I released HLA in Sept 1999. That's nearly four and a half years ago.
It's just now catching on in a big way. I've learned to be patient.
This "translator" project is going to take time to build momentum.
And, quite frankly, it has a couple of things working against it -
Rene on his end bad-mouthing anything that isn't RosAsm-specific,
and the MASM32 crowd on the other end who already have a
decent set of Win32 equates and probably wouldn't care if no one
else were able to develop their own set, and that same MASM32
crowd not really caring about XLib or Linux equates (or whatever).
It will take time to pull this off, and a lot of promotion. But if you
believe in it and you'll stick with it for the time it's going to take
to pull it off, I guarantee you that you'll make a big impact with
this project.
>
> I'm a touch annoyed at being told off for already doing exactly what
> you advise me to do...while you go off talking about "gold plating"
> over here rather than on the mailing-list I set up specifically for
> the planning discussions (and not just my "announcement" Email told
> you of the mailing-list but the SourceForge project page tells you of
> it so that shows you probably haven't even looked at it for all the
> effort I put in...thank you very much, I must say)...which means more
> effort on my part copying this stuff over to the mailing-list archives
> at some point, like Yeoh did with LuxAsm...which, by the way, Yeoh,
> was a tremendously good idea and thanks 100% for making that effort to
> keep the conversation on the newsgroup into the project archives for
> looking at later...
Well, you've seen the problem with the mailing list - getting people to
participate. You'll find people popping in and out of the threads around
here who would never consider joining the mailing list. Eventually, I think
that the focus will shift to the mailing list. In the meantime, however, a
long set of healthy threads describing the project around here and
engaging people in this newsgroup in the discussion is the best way
to attract subscriptions to the list.
And I would recommend just the opposite, too. I'd take all the messages
appearing in the mailing list, create a digest, and post that digest to this
newsgroup on a periodic basis.
>
> I stressed a number of times in those posts which went to the LuxAsm
> team and yourself that I was going to focus on dealing with _our_
> issues first and was putting "gold plating" to one side...I'm NOT
> "getting carried away" at all, as the talk of the utility's
> "potential" is merely the "salespitch" to interest developers by
> telling them where the project would eventually head in due course...
I apologize if I've offended you.
But I'd strong recommend a very incremental and limited approach.
Start with simple constants. Define the canonical form for them.
Create a simple canonical file by hand so that people can start working
on the translations from canonical->assembly. Get some interested people
working on C->canonical. Then add additional features (types, structs,
etc.) as the project progresses.
>
> And the point everyone is missing here is that all that "HLA -> MASM"
> stuff might be not that useful but the whole point is that you _GET IT
> FOR FREE_ from using the "canonical form"...no extra effort
> required...it really isn't "getting carried away"...because I'll tell
> you what is "getting carried away": that's talk of XML formats and
> dealing with macro complexities with macro pre-processors and stuff (I
> was kind of thinking they could just, at first, be output "as is" in a
> comment with an entry in the "log file" saying "could not convert!" so
> that it can be done manually...sound like "getting carried away" to
> you?)...
Except that someone will have to write an HLA->canonical translator.
Having gone through the process of manually creating a MASM header
file to allow MASM32 users to call HLA Standard Library routines
(and having a few others do FASM and NASM versions), I can certainly
understand the benefits of having an HLA->canonical translator. BUT,
that translator sounds like a bit of work and I don't see it being a high
priority for me. I *do* see the canonical->HLA translator being an
important project and one that I'd work on. But I have so many other
projects (e.g., HLA v2.0) that would take precedence over the
HLA->canonical translator; so I know that *I* wouldn't have time to
work on it anytime soon. And given Rene's recent outburst with respect
to the GPL and RosAsm (see "Rene is a hypocrite"), I suspect you
won't find Rene real excited about a RosAsm->canonical translator.
Given that Steve Hutchessen has copyrighted the MASM32/Win32
header files as a way of encouraging people to adopt the MASM32
system, I'm not sure he'd be real interested in supporting the effort
to develop a MASM->canonical translator. And on and on and on.
Most assembly authors would probably like the idea of having
some code that saves them effort w.r.t. getting header files for
important systems with minimal effort. But I wonder if many of
this authors like the idea that their header files (that they've put all
the effort into developing and maintaining) would be made
immediately available to other assemblers if *they* would just
take the effort to write the asm->canonical translator. I'm not
suggesting that all assembly authors would care a whole lot
(e.g., I encourage people to do this with the HLA stdlib), but
it's just not going to be a high priority. So unless you can find
the volunteers to write those translators, I don't think they're
going to be very popular.
>
> So, don't you take that tone of voice with me, Mr.Hyde...I've told
> everyone before that you get my support because I think what you're
> doing is right...in this case, though, pulling some "high and mighty"
> preachy thing at me for "getting all excited" like I was some dumb
> schoolgirl, while, in fact, it's _you_ who's going on about "XML this"
> and "highly complex macro that" who hasn't bothered to even "show
> willing" on all the "pro-active" effort I've put in to trying to get
> something _concrete_ for the project to develop from, who's "getting
> all excited"...actually, now you've pulled this "listen to teacher"
> thing on me that you've never done before, I partially appreciate why
> Rene and Wannabee don't much like it...
Sorry I set you off.
But I *do* want to see this succeed.
And the best chance it has is to start off slow and carefully rather
than just become a "flash in the pan". I've seen *many* projects
start off like this and die off after the initial enthusiasm. I would not
like to see that happen with this project because I believe that it
would be geniuinely useful and a great contribution to assembly
programmers everywhere. So forgive me for saying "listen to teacher"
(or more properly, "listen to the guy who has over a decade's
project management experience") and "slow down and take some
baby steps here."
Step 1: get a "proof of concept" working (e.g., processing constants
from canonical to a couple of different assemblers).
Step 2: Build a *useful* canonical file that would provide a useful
header file for existing assemblers (e.g., Win32, XLib, whatever).
Step 3: Market the project. Get other assembler authors interested.
Step 4: Expand the features of the system. E.g., add your C->canonical
generator.
Step 5: Repeat the above as necessary.
>
> Let me spell it out, in case you got the wrong impression: I respect
> my elders when my elders show respect and act in a manner deserving of
> respect...up to now, that's been the case that I've always supported
> you (including twisting the arms of the LuxAsm team that this
> "generic" idea can benefit everyone that we should do this...though,
> originally, of course, I was doing it to assist both HLA and LuxAsm
> simultaneously and keep to what I said about assisting you with that
> "portable GUI library")...don't go and ruin that for no particular
> reason by being totally unthinking to all the efforts I've gone to so
> for and telling me off like a naughty schoolgirl when, thus far,
> everyone else has just talked "theory" but I'm actually trying to put
> it into practice...and, yes, I _was_ concentrating on "up and running"
> first...that's actually what the "binary" suggestion was all about
> because cutting out some "XML" in-between is exactly that...XML is a
> great idea and all the stuff about being able to read it and modify it
> is great too...but I was skipping that, at first, _exactly_ to
> concentrate on the _basic functionality_...it must _convert_ something
> first then worry about "making it pretty and user-friendly" later...
good.
Start with constants. They're easy to convert to all assemblers.
They provide a good "proof of concept."
>
> > The need to convert HLA header files to MASM header files isn't that
> > important.
>
> You're the one talking about converting complex macros...at first, I
> was thinking of just outputting the "complex" stuff like that "as is"
> in a comment for manual "tweaking"...but, as, indeed, the original
> purpose is "C -> NASM / HLA" then perhaps the very basic C
> pre-processor stuff can be handled just for that...working out a
> better solution to this was something I was reserving for "stage
> two"...
Fundamentally, I am of the opinion that the canonical file format
is the one that gets maintained; manually. I see the XYZ->canonical
translation as being a semi-automated process, with a human being
cleaning up the other 20-25% of the code that the translator doesn't
handle itself. For this reason, I believe that the definition of the
canonical form has to be very well thought out. I'm not even sure
there would be a need to improve upon the "first stage" C->canonical
translators. My guess is that such effort would be put to better use
manually maintaining the canonical files. But I'd also suggest that
we won't really know until we've got some actual header files
working and we can see the *real* problems that are before us.
>
> > Certainly, converting TASM to C or C to Pascal won't be that
> > interesting to the people contributing to the project.
>
> Yeah, I know; That's why I was only talking about C, HLA, NASM at
> first...the other stuff was merely an "advert" to how this "modular"
> "generic" stuff can go on to provide greater things...it was,
> basically, a response to T.M.Sommers' perfectly valid question: "Why
> do it that way rather than create a bunch of dedicated convertors?"...
That's fine.
>
> > The idea, quite frankly is to allow the development of a decent set
> of
> > Win32/Xlib/Linux/etc., header files without that work being
> duplicated
> > a dozen times.
>
> Now you're just getting annoying; I know exactly what the idea is...in
> case you forget, it was _MY_ fudging idea!! And _I_ came up with the
> idea, indeed, to solve the immediate problem of Xlib / Linux (I wasn't
> even going to go as far as Win32...that stuff was just a useful "side
> product" that _you_ could make use of...LuxAsm doesn't need Win32 at
> all)...
Annoying?
I don't know why. My interest in this project is two-fold:
1. I'd like to obtain header files for HLA that don't require me (or some
other HLA user) to sit down and enter and verify the declarations.
2. I'd like to make all assembler users more productive by eliminating
the need for groups of people to replicate these equates and declarations
for each and every assembler.
From my perspective, everything else is interesting from a Computer
Science point of view, but of little practical value. C->canonical
is important, of course; MASM->canonical might be interesting
insofar as there is this great set of Win32 equates (though there
is the copyright issue, the MASM32 equates are copyrighted and
I don't know how Steve would feel about such a translation).
An HLA->canonical form *might* be interesting to some people;
it would, for example, make the HLA stdlib equates available to
multiple assemblers and it would be an easy way to get a large
number of Linux equates ported rapidly. I have no idea what
other equate file sets are available for other assemblers (that aren't
duplicated by MASM32, for example). So I don't really know
if having a translator to canonical form from some other assembler
is a worthwhile thing to have. From my perspective as an assembler
author, however, the existence of a C->canonical translator
would be about all I care about.
Again, I apologize if I'm a bit more focused on my particular
needs here. But I am a bit busy and as interesting as all this
sounds to me, I have to keep focused on the current crisis at
hand :-(.
>
> Because another important ingredient in "up and running first" is to
> do some _concrete_ things to make it happen rather than "debate
> theory" all day long...you've done fudge all so far but say "use a
> canonical form!"...a fantastic idea, of course (and don't think I
> hadn't basically thought of that myself...you merely provided the
> correct terminology for what I'd intended all along)...but I'm just
> really annoyed at this...
Why are you annoyed?
I'd be annoyed if no one cared. But the fact that people are voicing
their opinions indicates that people *do* care. And as you refine
things a bit, you'll probably find that some people care enough to
participate. I'm glad I provided the vocabulary for you and I don't
want you to think that I'm interested in taking away anything from
your project. I do believe I've made it clear where my interests
lie - developing header files for HLA and other assemblers that
only need to be maintained in one spot. I'll certainly volunteer
to write a Canonical->HLA translator.
> I put in all this effort, I exactly
> concentrate on getting something "up and running" and all that
> stuff...and then get told off like a naughty schoolgirl for being
> "over-excited" when that was exactly what I was NOT doing, while
> everyone else - you included - _are_ doing that...talking bold ideas
> all day long, can't be bothered to do something as practical as sign
> onto the project I've set-up for this because you're having too much
> "excited" fun talking theory about it rather than assist me - who's
> had to do this all alone so far, despite it NOT being solely my idea -
> with even a basic short Email of support or something...
Well, if I weren't so busy responding to posts of various natures
in a.l.a, I'd probably have the time to join yet another mailing list :-)
Don't get me wrong, I don't want to curb your enthusiasm.
But I have a vested interest in seeing your project succeed and
I don't want it to bright brightly for a few weeks and then fade out.
> > Best to keep the
> > definition of the canonical form as simple as possible,
>
> Such as, perhaps, ignoring the fudging "XML" stuff for a second and
> simply getting it work with a basic internal binary form at first
> (something that can be easily "upgraded" to that XML stuff later)? Oh,
> yes...that's right...that's what _I_ was suggesting while you were
> dreaming of XML "gold plating"...
I don't even know XML, so I'm not in a position to comment.
But I was personally thinking of something along the lines of
a Windows ".ini" file. Then again, I haven't had the time to
put any thought into this beyond the time I've spent in the posts.
So I don't have a clear idea of the problems, much less their
solutions.
>
> > to reduce the effort
> > needed to write the translators, so mere mortals can actually
> contribute.
>
> An excellent idea! So, out of interest, if "mere mortals" are meant to
> be "contributing", where are they contributing to? Oh, yes...that's
> right...the project at SourceForge that I went to a lot of effort
> setting up that you haven't been bothered to contribute to by even
> signing up or even a short Email saying "Great! You set up the
> project!" or something like that...
Again, post the URL so mere mortals can sign up!
>
> Thus far, I have Yeoh signed up as a developer to the _concrete_
> things I've been trying to do while you talk "theory" all day
> long...and he's actually a happy RosAsm user (he's got the most
> "demos" on Rene's webpage, if you look :)...a learner, he tells me, so
> that would be "mere mortal" to you, I guess...hey, I've got no
> problems with the "mere mortals"...it's the "assembly gods and gurus"
> who're doing my head in here...
Again, I could sign up after finishing this post, and then fail to
contribute
anything useful there for as long as it takes me to get the proof reading
done on my next book.
Cheers,
Randy Hyde
The Half A Wannabee
"qual1" <qu...@noreply.com> wrote in message
news:c0rhgs$vkn$1...@news.netins.net...
> Betov wrote:
>
> > "Beth" <BethS...@hotmail.NOSPICEDHAM.com> écrivait news:VL_Xb.39
> > $oK2...@newsfep3-gui.server.ntli.net:
> >
> > example: I thought he would not contest the fact, as, in a thread
> > called "SpAsm Review", right here, several years ago, _he_ said
> > publicly that this was a real great innovation of mines and a real
> > good idea.
John. If the quote about the "SpAsm review" is true (cant check it at the
moment, my internet connection is gasping for air), then Randall becomes a
conscious lier, and all the shit Rene said about him becomes true, and your
post becomes idiotic.
> Regards,
>
> John
Randall Hyde
>
> And an XML parser isn't "gold plating"?
Don't expect *me* to defend XML!
To be truthful, I know almost nothing about XML so I couldn't
comment one way or the other on it.
> Matching up "tags", case-insensitive attributes, allowing values to be
> quoted or unquoted, reasonable error messages for parsing problems,
> etc....a mini "web browser" inside the tool, to satisfy "curiosity" in
> being able to read the intermediate form?
>
> No, don't get me wrong...I totally _Love_ this XML idea...BUT you talk
> about how it's important to get the project "up and running" and that
> I shouldn't "get over-excited" about tons of "gold plating" ideas when
> my "binary" suggestion was _exactly that_...get it working first, then
> worry about "user-friendly features"...
Although this post is in response to one of my messages, I'm a bit
confused (or maybe you are). I wasn't the one suggesting XML.
As I said, I know very little about XML. I wouldn't have a clue
about it's applicability to this situation (though the little I've read
suggests
that XML *could* be used for this, whether or not it's a good fit,
I don't know).
The nice thing about human-readable versus binary is that I can
create some canonical files *manually* while waiting for the
C->canonical file translator to be written. This would allow me
to work on a canonical->HLA translator in parallel with the
C->canonical translator. That would be a bit more difficult
if the canonical file format were binary.
>
> One approach; I was going for even less "gold plating" than that, in
> fact...unlike LuxAsm's design, I _wasn't_ going to initially have
> these "modules" dynamically loaded (compiled straight in at
> first...making it more "flexible" was "stage two" :)...and you just
> include the "canonical form" C header file with the various "records"
> defined as structures and work from that...
Oh. I didn't realize this was going to be a single program.
I was under the impression that each of the modules would be a
separate application and you'd run them as a set of filter apps from
the command line.
> This gets things done quickly but leaves perfect room that the
> "modules" can be "decoupled" to be dynamically loaded and leaves
> perfect room for some "XML" form to be inserted (e.g. it goes C ->
> internal structures -> HLA at first...then you can add C -> internal
> structures -> XML file -> internal structures -> HLA _LATER_)...
I will say this about XML: one serious drawback to it's use is that
people would have to learn it to participate in the project. True,
they'd have to learn whatever other canonical file format you come
up with, but XML is probably much more complex that a simplified
text-based canonical format (e.g., like an ".ini" file). The thought of
having to learn some XML to be able to participate in the project
is not particularly exciting.
>
> > The "open development" project could be the C->canonical translator.
>
> "Could be"? The "open development" project has been set up and exists
> _already_ and I've been sitting around waiting for you to ask to be
> signed on as a developer or to at least join the mailing-list to have
> these kinds of discussions there...
>
> You did get the Emails I sent, didn't you? They went to your Webster
> address...if not, then, okay, I can retract some of my annoyance at
> you in the other posts here...because if you didn't get the Emails
> then perhaps you didn't know (though, that "over-excited" comment
> still stands as really annoying and uncalled for)...
Well, I got one.
The other(s) may have been accidentally deleted when erasing the
100s of spam and virus emails I get every day :-(.
Well, I looked up the emails and they did *not* provide directions
for signing up. If you would be so sweet as to provide the URL
here (preferably in a short message so others won't miss it),
I think that you'd get more people signing up :-)
Cheers,
Randy Hyde
hutch--
The only problem with this idea is if he managed to get a pile of crap
like that published on crap paper, it would irritate your butt as bad
as his verbal sewerage irritated your ear.
Betov
(Live).mp3)_Hotmail.com> écrivait news:4031a3ba$1...@news.broadpark.no:
Here is it:
Master Pdf:
//
This is an interesting approach (ignoring underscores). It
provides a cheap and easy way of allowing the insertion of
underscores nearly anywhere in the program (the part about this
I like is that it lets programmers use this feature in ways the
original designer never dreamed of).
//
Betov.
Betov
212.27.42.72:
... and
//
Since underscores are
important in external names I can envision some
problems developing here. Nevertheless, other than
this one quick point I won't criticize this feature
too much because I haven't had time to study the
ramifications of lexically ignoring underscores.
//
Betov.
< http://betov.free.fr/RosAsm.html >
Beth
> Beth wrote:
> > No, the thing that'll more ensure that it never gets written is if
no
> > developers - such as yourself - bother to sign on to the project
so
> > that they can access and contribute to the code base so that no
source
> > code is created whatsoever...which is kind of "never get written"
by
> > definition, wouldn't you say? Or is that too _practical_ and not
> > "theoretical" enough for you?
>
> Well, I'd have to find my sourceforge acct info somewhere :-)
> Seriously, I am interested, I'm just snowed under getting ready
> for a concert next weekend and I burn up all my free time
> defending Rene's right to post whatever he wants to this newsgroup
:-(.
Yeah, well...you could simply scrub bothering to defend Rene's right
to post...after all, let me wave the fact that this is an unmoderated
newsgroup in front of you...it doesn't particularly matter if he has a
"right" or not, it'll happen anyway...and this big old "debate" isn't
doing your reputation any good too...so you can save lots of extra
time not bothering with this nonsense...me? I have plenty of extra
time and no discipline not to do it! ;)...
And understood on the old concert thingy...
Granted, it's not impatience, Randy...it was the lack of that "lot of
communication" that got me annoyed...I'd done stuff and sent out
announcements and got plainly _nothing_ in return, other than Yeoh's
responses...I wasn't expecting for you to dump all the code on me
overnight or anything but like _some_ kind of communication wasn't
asking too much, surely? Just to stop me thinking I was talking to a
brick wall...or, as I had started to think, people actually thought it
was a _bad_ idea and that's why no-one was responding...without any
communication at all, you see, you just can't tell...
I know I'm hardly one to talk because I do this all the time too
(mainly because I find it impossible to write _short_ replies ;) but
"regular, short" is actually usually a whole lot more useful than
"long, infrequent"...easier said than done, though, granted...but it
reminds me of watching this "DIY SOS" TV programme where the show is
about sending a team of builders and decorators to real people's
houses to basically fix up bad or incomplete "do it yourself"
stuff...and the show is _full_ of people who think "I'll redecorate
the house" and dive straight into it and then give up when it takes
more than a day to do...it's a common ailment...when, in fact, you're
probably a whole lot more likely to succeed with a "five minutes every
day" regime than a "I will build Rome in a day" attitude...you don't
get tired (both physically and mentally) after only five minutes and,
as long as it's regular, you'll get to the end eventually...I get this
all the time with my programming, in fact...that I kind of want to do
everything all in one go and do some "marathon" session and then I'm
just sick of the sight of the code the next day and can't be bothered
with it anymore...but when I do "a little bit here" and "a little bit
there" approach, things usually go along quite well and happily...so,
yeah, totally...impatience isn't the problem...just the lack of any
communication whatsoever - deathly silence - is a touch different to
that...just one Email or post with "okay, that's great...I'll write
back to you again next week because I'm snowed under with a concert
this weekend" says it all...it just confirms that people are with the
idea and I'm not barking up the wrong tree and all that sort of
thing...once I know this, then things can, indeed, be perfectly
"casual"...no rush at all...but that first confirmation is slightly
different...you know, if _no-one_ replied - but Yeoh did - then I was
seriously considering "oh, if no-one replies soon then I might as well
delete the project and give SourceForge their hard disk space
back"...after all, it is just "on loan" from SourceForge and I'm not a
person that likes to take advantage...yeah, yeah...SourceForge have
plenty of space but it's NOT _my_ space and I didn't pay for it, which
makes all the difference to me...if things will eventually be
happening, great, leave it be and wait around for that...but if I'd
still got no reply six months later then I have kind of
unintentionally stolen SourceForge space that could have been used for
some other project that is actually going to go somewhere...
You know what I mean? That first reply is different to all other
"communications"...it tells me whether or not other people are
actually going with the idea...even a simple "show of hands" single
word "yes or no" reply is good enough there...thereafter, fine, take a
week or two to sort things out, that's great...I'll surely be doing
the same myself at some point (in a sense, I _am_ with LuxAsm because
of my problems with getting Linux to actually work but I can still do
all the "talking" and "planning" stuff, just so that everyone else
knows that it really is a serious hardware problem I've got - I've
tried loads of things and it looks like something serious is broken so
this is actually going to require new hardware of some kind,
probably - and not because I'm not interested in coding things up or
doing experiments or whatever...it's actually really annoying because
I want to try out the ELF stuff I've been reading about but can't
really do that in a useful way until the Linux machine is working...I
can reboot _this_ machine to Linux but switching OSes all the time is
something I don't want to do...it's worth sorting out this problem -
even if takes up a little time - than to not bother and stick with an
awkward "half measure"...in the long run, getting the Linux machine
working will speed things up big-time that it'll easily eventually
outweigh the "delays" so far in sorting out this problem I have :)...
Beth :)
Beth
> Again, I could sign up after finishing this post, and then fail to
> contribute anything useful there for as long as it takes me to get
> the proof reading done on my next book.
Hey, I _don't_ care about that too much...for example, Gerhard is
signed up to LuxAsm on a "say something if you're at all interested"
basis...you won't get roped into work unless you volunteer to do it or
whatever...the way the stuff on SourceForge works and open-source in
general means it's not really possible - and I wouldn't particularly
want it, anyway - to have some kind of "hierarchy" and "orders" and
stuff that happens in formal working conditions but not here...sign up
and do nothing for a month...you won't get told off or fired...you
can't be "fired" in that way...it doesn't work like that...BUT, as I
say, if no-one signs up at all then that's slightly different...that
says "no interest" and "Beth, you're barking up the wrong tree, that's
why you're all alone there"...also, you are getting the space on
SourceForge through their "approval" on an implied condition (and the
odd _literal_ "terms and conditions") that you aren't just taking up
their space for no good reason...
As for the URL, SourceForge is all "standardised" and has a "search"
thingy to immediate find a project from the name...so I was kind of
thinking "hey, people aren't that stupid that they can't work this out
for themselves!" but, okay, if you want more direct links:
Mailing-list:
http://lists.sourceforge.net/lists/listinfo/convinc-devel
[ You can subscribe and join in without being a member of the project,
by the way :) ]
Main project page:
http://sourceforge.net/projects/convinc/
Website "front page":
http://convinc.sourceforge.net/index.html
As I say, these things are all "standardised" on SourceForge that you
could get to the LuxAsm stuff as well by basically substituting
"convinc" in the addresses for "luxasm"...
Beth :)
Beth
> Oh. I didn't realize this was going to be a single program.
> I was under the impression that each of the modules would be a
> separate application and you'd run them as a set of filter apps from
> the command line.
Well, it could be either, really...it's certainly "modular" for sure,
as that's implied in the idea itself but the actual method of
"modularity" is another thing...an "implementation" consideration...
I'd just kind of thought that - per the "start nice and simple" -
there's a "canonical.h" include file that "ansic.h" and "hla.h" and so
forth include which defines all the structures and types so that their
only concern is to do the parsing and fill out those structures and
stuff...but this is "modular" enough that they can be "split off"
easily later (as a DLL or shared library? Or maybe redirecting some
"standard I/O" or whatever and they are separate applications
:)...just the easiest thing, at first, is to simply make them as
"ansic.c" / "ansic.h" units so there's no fuss about "linking" the
things to begin with...concentrating on the _functionality_ that they
just get the conversion working first and foremost...the other stuff
about making it "clever" and "pretty" can come later on...
That's not a hard and fast thing, though...just how I was looking at
it to begin with...I can be totally persuaded to do something
different if it's a great idea...and I _do_ intend to, indeed, put in
a text format and perhaps make these things link together in weird and
wonderful ways for flexibility but I just thought "up and running"
first was a sensible starting point...leave all the other
considerations about "implementation" to one side while the
_functionality_ gets focussed on first and foremost...otherwise, I can
quite see this utility with a great XML parser and clever links and
interfaces but which, oh dear, still doesn't actually do any _actual
converting_ as yet...without being too harsh, kind of remind you of a
certain tool with assembler (needs polishing up), disassembler (not
quite finished), GUI (could do with improvement), etc., etc.?? ;)
> Beth wrote:
> > You did get the Emails I sent, didn't you? They went to your
Webster
> > address...if not, then, okay, I can retract some of my annoyance
at
> > you in the other posts here...because if you didn't get the Emails
> > then perhaps you didn't know (though, that "over-excited" comment
> > still stands as really annoying and uncalled for)...
>
> Well, I got one.
> The other(s) may have been accidentally deleted when erasing the
> 100s of spam and virus emails I get every day :-(.
Ah, now that's one possibility I simply didn't consider...oops...okay,
fair enough, if it didn't arrive or you deleted it by accident then,
clearly, you can't be blamed for what you didn't actually see...as I
say, I'm retracting some of the eariler annoyance at you because maybe
I was too quick to attack there...hey, we all have "one of those days"
from time to time...might have made a bigger deal out of this then
than I would now :)
> Well, I looked up the emails and they did *not* provide directions
> for signing up. If you would be so sweet as to provide the URL
> here (preferably in a short message so others won't miss it),
> I think that you'd get more people signing up :-)
Done so in the other post around here...
Beth :)
Beth
> Hmmmmm!... This thread is getting more and more funny, with
> everything going on, as if nobody was understanding what is
> going on... :)
>
> So, let me try to clarify some "details":
>
> * I have always been, in the past, in favour of sharing all
> possible things between the various Assemblers Projects. I
> have for example, offered my Equates List to Thomasz, and to
> Jeremy (even though Jeremy Assembler -GoAsm- is a closed
> Sources one -...-), with the associated Methods for fast
> computing, and so on... (they were not "interrested"...
> Well... None of them ever behaved like i did... Well...
> All of them tend to behave "sectarian"s... Well... OK to
> me...).
>
> * Now, since the recent attempts of Master Pdf, we _do_ have
> to seriously protect our data and hard work. As nobody seems
> to understand what and why, let me first recall what Master
> Pdf was, and is, actually doing:
>
> 1) When he made up his mind that he was a thing of the past
> and utterly overpasses by a new generation of Assemblers
> Authors, and that he had no more enough time to recover his
> "leadership" in the area by doing any serious work (too late),
> he wrote an HLL Pre-Parser and sold it under the name of
> "Assembler".
Rene lie #1:
Randy wrote AoA to support HLA, whereas RosAsm is NOT a "Windows
assembler"...
Actual facts:
Randy had written 16-bit AoA a long while back and other people used
that - which was written for MASM - so it's not difficult to show
that's the case without any arguments about that...
Randy wanted to update the 16-bit AoA to 32-bits because, well, DOS is
dying...and, at first, he used _MASM_ to update the "UCR standard
library" teaching idea he'd successfully worked with for the 16-bit
AoA to a 32-bit version...but MASM was simply not up to the job
(macros not good enough, error messages not friendly and
understandable enough, etc. :) so this "UCR standard library v2.0" _in
MASM_ was abandoned...instead, Randy thought he'd write his own tool
which could do the job properly...namely, HLA...and then wrote the
"HLA standard library" instead...this permitted the same successful
strategy of using a "standard library" to help with the teaching to be
used for AoA 32-bits as had worked with AoA 16-bits...the aborted
attempt to use MASM in "UCR standard library v2" _proves_ that Randy's
intention was to solely "upgrade" the "UCR library" idea to 32-bits
for AoA 32-bits (_exactly_ as had worked well for AoA 16-bits) but
when MASM proved it was not up to the job, Randy coded HLA to support
making 32-bit AoA possible...
The files, time stamps, dates and other things entirely support this
version of events...they do NOT support your inaccurate version of
events that you're trying to propoganda-ise into making it sound like
Randy's intention was to "steal glory" with HLA and AoA was to support
this "auto-glorification"...
Your argument here requires these things to be the other way around
and actual files, time stamps, dates and things I've seen with my own
eyes, such as the "UCR standard library v2" _prove_ that it did NOT
happen as you suggest...hence, as your arguments here depend on the
presumption that Randy was doing this the other way around for
"auto-glorification", the _FACT_ that it didn't happen like this at
all - that the actual dates other people have seen and can be
verified - _proves_ your arguments to be _FALSE_...
On the other hand, let's look at your "NOT a Windows assembler"
contention...this is the argument you depend on to prove that you are
being "ethical" and not supporting Microsoft, rather supporting
ReactOS...
Again, if we look at the actual dates and you've also confessed this
yourself, ReactOS _DIDN'T EVEN EXIST_ when you start the original code
that became SpAsm and later RosAsm...in other words, you _started_
entirely with the intent of creating a "Windows assembler"...there was
no ReactOS - there was not even talk of ReactOS - at that time so it
couldn't have logically been any other way...
The fact that ReactOS did turn up later and that you could simply
_rename_ "SpAsm" to "RosAsm" to avoid the criticism that you claim to
be attacking Microsoft but yet happily write software to support their
OS was a handy "convenience" that turned up...you could pathetically
say "it's not a Windows assembler because it's for ReactOS"...
Well, sorry, NO...because, again, the dates and events _prove_
it...you were originally writing a _Windows assembler_...you were
_supporting_ software being written _for_ Windows...when ReactOS
turned up, you did NOT change the actual code at all, you merely
renamed the project, thinking no-one would notice and that you could
start saying "it's a ReactOS assembler" all the time to escape your
paradox of fighting Windows by supporting Windows(!?!)...
And, regardless, this totally does NOT wash, anyway...because ReactOS
is merely a Windows clone, anyway...that's how you could get away with
just renaming the project...pretending that Windows was a "test
platform" when it's _FACT_ that it was the original target
platform...ReactOS _is_ Windows...just not _Microsoft_
Windows...someone else is writing it...
Plus, what works one way can work the other...so, Rene, when someone
writes "ReactOS" code, how is it not also simultaneously perfectly
valid _Windows_ code? Why can't someone take RosAsm or a RosAsm
application from ReactOS and run it perfectly well on Windows? Hence,
how do you explain that all the Windows assemblers will work perfectly
fine on ReactOS (you won't be alone over there...no way, no
how...you've still got MSVC++ and HLA and others to contend with...the
name and pretence it's "ReactOS only" will not wash with the practical
realities) and all the "anti-Microsoft, ethical" software can actually
be run on Windows - probably _will_ be run mostly on Windows until,
that is _IF_, ReactOS gains ground as an alternative - no problem?
You've tried to _re-write history_ here, Rene, to make you look shiney
and perfect and pretend that Randy has done things he NEVER actually
did...as you were personally there - obviously - when these things
happened then - unless all that wine has warped your memory - there's
no real excuse as to how you're constantly getting it all the wrong
way around...there's a strong degree of suspicion here that this is a
_lie_ in order to spread anti-HLA propoganda to serve your own
"auto-glorification"...
Oh yes, indeed, the truth is that the crap you throw at Randy actually
sticks far, far better onto _you_...a very clever ploy, indeed, to
accuse Randy of what _YOU_ are actually doing so as to distract people
from looking at _your_ actions and _your_ motivations here because
they are too busy looking at Randy...
You know that thing kids do where they poke someone in the back and
when that person turns around, the actual one who did the poking just
"looks innocent" and points to their friend saying: "It wasn't
me...I'd never do that...it was her...she did it! Not me!"? That's the
_same cheap trick_ you're trying here on Randy, basically..._YOU_ did
the poking but you think by pretending to be "helpful" to the poke-ee
while blaming Randy, everyone will think Randy actually did what, in
fact, _YOU_ did...
Your fundamental blunder here, though, is that _proof_ exists that
Randy's version of events adds up, while your version of events does
NOT...there were people watching this going on at the time who _know_
what you're saying isn't right...and their are files, dates, archives
and time stamps and so forth which also categorically _prove_
this...doing some "forensic archeology" into the matter and all the
_evidence_ supports Randy 100% and supports you 0%...simply because,
as everyone watching knows, you are _lying_ and creating "propoganda"
to serve your "auto-glorification" for writing the _Windows assembler_
SpAsm...which you simply renamed "RosAsm", Hoping that this would be
good enough to escape the _contradictions_ of someone claiming to be
_anti-Microsoft_ actually creating a tool to support _Windows_
software and that OS...while, indeed, you _overlooked_ Linux, OS/2 and
other alternative operating systems where no "ethical" problems exist
(well, okay, the first draft of OS/2 was written by Microsoft but it's
actually IBM's and they've changed and improved things thereafter
:)...
What is this really all about? Well, you created a _Windows assembler_
for your own "auto-glorification" by, indeed, depending on the work of
the "pioneers" who pushed open the closed door of Windows assembly
programming...and you did NOT target Linux or OS/2 because that would
have required _YOU_ to do "pioneering" on these different
platforms...you didn't want the work (which Randy _DID_ do in making
HLA work on Linux and LuxAsm is going to do in taking this over to
Linux, where really an "ethical" project _should always have been_
:)...
Oh yes, indeed, you accuse Randy of sitting on his laurels too lazy to
do his own work but just "stealing" the "pioneers'" work...but, Rene,
this better describes _YOU_, doesn't it? Randy _DID_ "pioneer" making
his HLA work on Windows and Linux (which included having to re-write
things for Linux and create the assembler support and, also, in
addition, maintaining that the "standard library" worked on _BOTH_
simultaneously without problem)...who did this before him? Who?
Exactly..._NO-ONE_...it was pioneering work...NASM is closest in that
it supports Linux by being "portable" to anything with a basic C
compiler...but that's not quite the same as not only making the tool
work on Linux but also re-writing the entire standard library so that
also works on Linux...and, more than that, tailoring HLA so that the
two versions - Windows and Linux - happily work together...
And then HLA was expanded to deal with FASM and GAS as well as MASM
"under the hood"...that's yet more work Randy put in there, that
requires an awful lot of work in areas no-one's really gone before
(definition of "pioneering" really...even if you don't like this
"front end" thing and think it's a bad idea, Randy was _pioneering_ an
entire new way while he was doing this...there's no denying that or
pretending that it wasn't an _awful lot of work_ to get that up and
running properly)...
> 2) When he made up his mind that no Assembly Programmer on
> earth would ever consider using that shit, he said it was
> written for "teaching beginners".
Inaccurate; The "Art of Assembly", which we've established above that
HLA was originally designed to support, is a text that teaches
beginners...
Again, _YOU'VE GOT IT THE WRONG WAY AROUND_!
HLA does supply "beyond beginner" material too for the following
patently obvious reasons:
1. When beginners stop being beginners, as they've learnt something,
then they can simply carry on using HLA - because it also has
"advanced uses" catered for too - if they so choose...
2. Randy spent an awful lot of time so it would, like, be nice for
_himself_ if he added in "advanced stuff"...you know, so that he could
use it too and just enjoy, yeah, playing around with things in an
assembly language...you do know what all work and no play made Jack,
don't you, Rene? :)
3. Though there's a lot of _prejudice_ and _preconceptions_ about HLA,
not everyone is so easily blinded or scared off by the idea of having
to actually read and learn things that it's not only me who uses HLA
who's already learnt assembly language ages ago (to be fair, many also
simply don't _want_ to use HLA because what they have is just okay and
they aren't interested...this is, of course, a perfectly valid
thing...indeed, if it ain't broke, then don't try to fix it...as long
as it's correctly stated as "I personally don't like it" then all is
well...tastes and needs differ...it's just the stuff which tries to
suggest HLA is "wrong" and enforce those opinions with inaccuracies
that's uncalled for)...
> 3) When he made up his mind that other Assemblers were much
> better adaptated to "teach beginners" than his shit, he found
> a Publisher to sell his Pdf.
Once more, you've got it the wrong way around!
Randy was "publishing" via Webster happily...it was the publisher _No
Starch_ which approached Randy, not the other way around...
And, if you doubt this, then find someone in the publishing game and
ask them how likely it is for an author to approach a publisher with a
fairly obscure technical book and then start making _demands_ that he
can still publish the book _free_ on Webster as "direct competition"
to himself and the sales attributable on the book...they'll tell you
it's simply unheard of...authors who approach publishers basically
tend to get all their "rights" to demand pretty much anything
swallowed up by the publisher's contract...like the music business, if
you won't take the contract "as is" - no negotiations - there's plenty
of other people out there who will...
On the other hand, publishers that approach authors are clearly trying
to "head hunt" texts that they reckon will do well and there's plenty
of negotiation because the author holds all the cards and it's the
publisher who's at the disadvantage in getting what they want...
Hence, the fact that AoA still exists for free download on Webster
kind of proves the point, even if you refuse to take Randy's word for
it...
> 4) Now, he is making up his mind that, whatever he could do,
> the day i will start actively promoting RosAsm, he could never
> win the competition,
What are you talking about? 4 million hits, TV appearances, published
works, a long established name and reputation, a tool that even in its
"prototype" form makes most of the other tools look distinctly
_amateur_...
He's already won, Rene...you weren't and you aren't "competition"...he
_only_ bothers with you because you lie with inaccurate propoganda to
beginners making them believe things that are untrue and that is,
indeed, unacceptable...
You are a danger to _them_ - the beginners who want to _actually
learn_ - and this is merely "damage limitation" on what you might do
to them...nothing more than that...you are seriously deluding yourself
to think you're anywhere near..._all_ the assemblers like NASM, MASM,
etc. make RosAsm look _useless_ (the _only_ thing you really have is
your "right-click" feature, basically)...and HLA is more powerful than
all of these once more (needs to be cleaned up implementation-wise as
a proper assembler, of course, but then v1.x was just a "prototype",
v2.0 will solve those little details and then you simply will have NO
leg to stand on _whatsoever_)...
> he is trying to have his Webster becoming
> the universal "reference" for everything available (for free)
> in the Assembly Area.
Oh dear, how terribly "evil" of him! He intends to create a free
one-stop comprehensive resource for all x86 assembly language! The
dastardly swine that he is...
Geez Louise, if only all those Bond villans and little green men and
evil creatures from the netherworlds and stuff were this nice, helpful
and friendly in their supposed "evilness"!! ;)
Heck, if Randy is only doing this stuff for "auto-glorification"
(which isn't true...this more accurately describes _your_ motives and
don't think I ain't finally worked that out, Rene ;) then "let him
have that!", I say...I mean, if "ego" can - for once in its long
miserable existence - actually _help_ people rather than what it
usually does of hindering and making things worse then, bloody hell,
don't get in the way of that ego...as long as _good_ is done and no
harm comes of it, then let any and all heroes _profit_ by that, if
needs be...I mean, I absolutely _DON'T_ begrudge that firemen or
police officers or doctors or soldiers or any other of these heroes
get paid...if only resources were unlimited, throw neverending
luxuries at them for what they do! If that's what keeps them doing
what they do, then let it be so...
Because, truth is, even the noblest hero needs to look out for number
one to a degree...I mean, if the fireman didn't get paid then he'd
starve and get ill sleeping on a park bench and be an absolutely
useless hero physically, however noble and honourable his heart may
be...and what use is a doctor or nurse who's let their own health
deteriorate that they can't actually visit any patients, lest they
pass on some virus they picked up? Or how long would a police force
last if it didn't take the precautions to look after its officers but
just raced into armed robberies and terrorist raids blindly (actually,
that kind of reminds me of that brilliant "Leon" film where a lone
hitman takes on an entire police force to protect a little girl...an
excellent film that we'll overlook that he was, in fact, saving Darth
Vader's mother! ;)?
Indeed, such "evilness" to rival the "evil" Lord Ralf Brown in his
"dominion" over DOS interrupt information! Such "ego" to challenge
Linus Torvalds naming his operating system after himself, as he sought
to enslave people with his free software "auto-glorification"!!!
Bloody hell, you could find an "evil" conspiracy theory anywhere,
couldn't you? A beautiful field of flowers with angels dancing merrily
in the eternal peace of Heaven and it's like: "This is propoganda!
They seek enslave people with the evil 'flower' devices they offer!!
Translate 'angel' into Serbo-croatian, change all the letters around,
add the word 'evil' and remove all the other letters and, look, it
spells 'evil'!!! This is 'proof'!! They are all Monsanto Nazis!!" ;)
> By the way, this is only a re-activation
> of an attitude he always had (for example, some long time ago,
> when a guy asked, at the Evil Board, "what about the dead APJ?",
> he, of course, immidiately raised his hand up, to "offer his
> "good will services" as a new maintainer of the APJ -...-).
Yes, indeed; There is such "auto-glorification" in merely being the
editor of a publication that accepts _voluntary_ articles of _useful_
assembly knowledge and compiles them together into an ASCII file...so
much "auto-glorification" because, indeed, you could name the old APJ
maintainer without looking it up, couldn't you? There is no way to
become more "famous" than to do this! Indeed, people ask "Who is
Britney Spears? Who is George Bush?" but, of course, _everyone_ knows
who the maintainer of APJ is...there is no greater prize of
"auto-glorification"!
Seriously, Rene...there's not an _ounce_ of logic in practically
anything you say...pointing out the stream of contradictions and
logical flaws that represents your "philosophy" is like going on a
"sitting duck" shoot using nuclear bombs...you have NOT a shred of
evidence or even logic on your side whatsoever for what you say...the
only reason you've gotten as far as you have was simply because I was
_overlooking_ this nonsense just to be "nice" to you...but you've
stepped up to say that you will consciously _deceive_ people for your
own glory and that I will NOT tolerate...so, realise that the more you
push this nonsense, then the more I will have to be forced to simply
stop you dead in your tracks...I can make things incredibly
uncomfortable indeed...I've not even begun and am still merely firing
"warning shots" across your bow...after all, I am the _inventor_ of
"virtual murder"...I've already claimed Spock's life! And if what
you're doing represents the "assembly rebirth" that you intend then
this Dark Phoenix will not be permitted to rise...the ends NEVER
justify the means...or you will find you have a Phyrric victory on
your hands because you _destroyed_ far more than could be ever
gained...if you want to do this to your own RosAsm tool then that's
your perogative but if you step into other people's land with your
destruction, then, simply, "Trepassers _WILL_ be prosecuted!"...
> Now, he is doing all he can, to make friend with the other
> Assemblers Authors,
How "evil"! He is being friendly and helping people! Is there no end
to such "evilness"?!
> having these Assemblers referenced from his Site, with dedicated
Pages,
Monsterous! He dares to direct people to other assembly resources!!
Dedicates his time and effort to the promotion of assembly language in
general...clearly, such selflessness is, ummm, somehow all about
"auto-glorification"...and he directs people to _other_ assemblers and
assembly resources in order to "lock" people into HLA...or
something...ummm, give me a while to work out how on Earth that
utterly illogical paradox could be even remotely true...
> proposing materials about "Compilers Theory",
Yes; This is his greatest "evil"...he seeks to _educate_ people! Give
them the knowledge that they'll need to write great software...the
dastardly swine! This could only serve the purpose of...ummm...helping
Monsanto Nazis punish Third World farmers...it's so obvious and
"clearly defined", that it's become impossible to see any connection
or even basic logic to his dastardly "evil" plans!!! ;)
Rene, seriously...are you using LSD or something? Because if you use
too much of that, then it can create these kinds of permanent paranoid
illusions...this level of basic _insanity_ just can't be explained by
drinking too much French wine alone...are you sure that someone isn't
"spiking" your drink with something much stronger?
> on purpose biazed Speed Tests , and so on...,
The only "bias" towards RosAsm was not even bothering to test it
because it would simply _crash_ if given a test file of the size that
works just fine on all the others (well, TASM has problems with file
sizes too...but nothing serious compared to your _incompetence_...yup,
I'm saying it straight: _incompetence_...I could not disappoint those
who know me for always telling it like it is...and, "like it is" means
_incompetence_ in your case...sorry, would _Love_ to say differently
but the facts leave me no choice but to report this...if you want a
better "grade from teacher" then take note of the "could do much
better" advice I've put on your report card :)...
> and redistributing everything he can do for free
Yes, that is just so "evil", isn't it? Really, _read this stuff back
to yourself_...you're a raving looney, Rene...all your screws are
loose...and that's the _politest_ way it can be phrased...
> (free of real work, of course).
Oh, come on...you really believe _anyone_ is going to swallow this
tripe? You're saying that Randy does no work at all? These arguments
are well beyond "black is white" nonsense...you're simply ranting pure
insanities now...
And, quite frankly, even if what you say was true...that Randy was
compiling a _comprehensive_, _free_ reference to all the _other_
assemblers, as well as his own HLA tool...and all the general assembly
language reference material...but he hadn't done any work at all
(although, ummm, wouldn't just gathering all that material and
creating the links be a work in itself, even ignoring HLA, the HLA
standard library - both recoded for Linux and Windows with FASM, MASM,
GAS, etc. - the masses of documentation, AoA 16-bit and 32-bit and a
whole lot of other stuff where _one_ of these things alone would be a
massive project to anyone else?)...
Well, who gives a crap? So long as people can go to Webster and get
this information and find the resources nice and easy, completely for
free, then what the hell is wrong with that? Randy _DOES_ do "real
work" far beyond the pissing around with GUI buttons you've been
incompetently doing for 5 years...but even if he didn't then this
_free_, _comprehensive_ resource you're talking about that covers
_all_ assemblers (well, minus yours because you've just been such a
pain that it's understandable he's not at all interested in that)
sounds like something _good_ that who cares if he gets some trivial
"auto-glorification" out of it? Some might even say that if he does
get "fame" out of this deal, then, why not? Sounds like he's actually
_deserved_ to get it...
> The final goal, with all of this, is double side:
>
> 1) Becoming a universal Asm reference without doing anything.
This is simply a lie...but then, if other people benefit from that
"universal ASM reference" and he links off his site to all the other
assemblers and promotes them all on their respective "dedicated pages"
(your words) then, sorry, where the fudge is this "evilness" supposed
to come from?
Sounds quite the reverse as _selflessly_ giving up his time and effort
to _promote assembly language_ (whatever the tool) and to try to make
that accessible to all...
What is it that you do again? Oh, yes...you "hide" your codes...you
"ignore" newbies...you _attack_ other assemblers...you declare
anything useful to be "anti-assembly"...you destroy, destroy, destroy
and think people will actually _thank_ you for this? Sorry, but you
are clearly insane or at least severely self-delusioned to be on the
verge of insanity...NONE OF THIS MAKES THE SLIGHTEST BIT OF LOGICAL
SENSE WHATSOEVER!
> 2) Isolating RosAsm as much as possible, while we are not yet
> over with the real hard work, and while ReactOS not yet ready
> for end users.
"Isolating"? Nope, sorry...he promoted you at first but you didn't
like being helped as it bruised your "ego"...so then he ignored you
but still you persisted in attack...so, he finally snapped and wrote a
single series of posts pointing out _factually_ just how _incompetent_
you actually are with RosAsm...and now you have been sent to
Coventry...completely _ignored_...
You are simply grossly over-estimating yourself...most people are
simply laughing at you...and Randy and hutch only react because you
have, simply, written _LIBELOUS LIES_ about them and distributed these
over the internet...and I react simply because I'm Hopefully
optimistic that even if it takes forever, then getting through to you
finally about what is really happening is worth drumming this into you
over and over...I'm only concern to correct your _inaccurate
propoganda_...you can delude yourself all you like but if you try to
_delibrately deceive_ others, then I simply will not stand for
that..."first, do no harm", as the Hippocratic Oath says...
> So, now on, the war between Master Pdf and me will be
> "absolute".
Yes, absolutely comical...he's not even paying any attention to you,
Rene...
And, in your case, you have no right whatsoever to criticise Bush and
Blair for them declaring war on a false premise...because even they
look "reasonable" in comparison to you...at least there _was_ a
butchering arsehole like Saddam in Iraq and that it's possible
intelligence might have fooled them into thinking WMD were there when
they were not...but, in your case, there's not even a possibility of
an excuse...you're just _insane_ as well as _incompetent_...
If you're the "white knight in shining armour" then pardon if this
damsel's heart doesn't go a'flutter at all at that prospect...it's
like being rescued by Frank Spencer or Norman Wisdom...really, please,
just stay at home...us damsels will just work out how these sword
things work and go slay the dragons ourselves...it's much too
dangerous work for you...you're the kind of "warrior" who just ends up
getting everyone killed that, really, don't worry yourself...stay at
home...drink some wine...have a good time...the rest of us can do all
the hard work and that stuff ;)...
> Recently, though i like a lot a guy like JohnFound
> and share most, if not all, of his ideas, i completely closed
> any relationship with the FASM/Fresh so interresting group.
Yeah, and I'm sure he finds you a good "friend" in simply tossing him
away on something so irrelevent and trivial...
> The things are clear and simple: If Master Pdf is allowed to
> post messages at FASM Board without being kicked out, i have
> no more anything to do there.
Well, this is clearly illogical; If this is the criteria - that you
pull out of anything that Randy posts to, whatever he might be
saying - then, surely, you should have "no more anything to do" with
this group? Why aren't you also stopping posting your nonsense here?
Randy posts here...as regular as clockwork...why one set of rules for
FASM and one set of rules here?
Yeah, JohnFound must really Love you for this...he tries to forge a
useful friendly relationship with you and things are going great but
then you throw him out of the window at a moment's notice without
warning just because Randy posts to that forum...as if this isn't bad
enough, he then sees that you _don't_ practice this same rationale on
this group at all...so you abandoned that relationships and friendship
_only_ in his case, it would appear...
You know, if you did this to me, then I'd simply consider you a total
wanker...really, it has nothing to do with Randy or "conspiracy" that
everyone keeps on kicking you out of those forums...it's because you
act like an ungrateful mad-man in totally unpredictable and attacking
ways that, simply, people don't really want to have someone like that
around...as I say, you're the "warrior" who turns on his own allies
and machine guns the lot of them in some paranoid frenzy before any
real enemies turn up...
With fair-weather "friends" like you, there really is _no need_ to
have enemies at all...
> So is it for this OS Data Project: If Master Pdf, and Master
> Pdf's supporters are inside, this is an Anti-Assembly project,
> whatever real work could be done there.
This is clearly paranoid illogic..._whatever_ Randy does is
automatically "anti-assembly"? So, when he cooks himself some
Spaghetti then cooking Spaghetti becomes "anti-assembly"? When he
browses the computing magazines in the local store, then looking at
magazines is "anti-assembly" and the authors of these magazines are
"anti-assembly supporters"? When Randy ties up his shoelaces then
shoelaces are "anti-assembly"? When Randy listens to music, he renders
music, musicians, the entire music industry, sound itself and anything
related to it as "anti-assembly" or "anti-assembly support"?
Then, oh dear, we have a major, major problem here...Randy
breathes...and Randy's heart beats...and Randy eats food and drinks
liquids...if all this stuff is also "anti-assembly" then it's going to
be immensely tricky to, like, be able to live or anything simple and
basic like that...with that kind of choice, it looks like, sorry,
we'll just have to be "anti-assembly" by your paranoid, insane and
illogical "definitions" and "philosophy"...
But this speaks volumes for what you _really mean_ here...this isn't
really anything to do with assembly, Microsoft, Monsanto, Nazis or
otherwise...this is just about you not liking Randy for some
reason...which, chances are, is simple green-eyed jealousy that he did
a better job than you that people didn't all suddenly rush to using
RosAsm as you'd expected would happen because you have an
over-inflated ego...it's _you_ who's looking for "auto-glorification"
and you want to do it _without doing work_ - just ranting paranoid
propoganda nonsense rather than simply beating Randy by making RosAsm
beyond doubt as the best assembler - and while you simply borrow
_everything_ you do as a re-hash of the "pioneers'" work, Randy -
despite your accusations - is taking things to Linux and breaking new
ground in how assembly language should be approached...and he's the
one _pioneering_ and _really_ coming up with new ideas...you're not
doing any new work at all, writing an editor that (barely and badly)
assembles some highly simplistic syntax, using directly all the
pioneering work that was done into how to write assembly applications
in Win32...
> For YeoHs, I do not know what he will do, but i would be a
> bit surprised if he would go on contributing to this. The
> guys using RosAsm and contributing to RosAsm are usually
> not the more stupid ones, you know...
Well, excluding yourself, Rene...then I'd agree that Yeoh is exactly
the kind of guy I'm happy is contributing to LuxAsm and ConvInc...he
seems to actually understand the meaning of the words "ethical" and
"useful" where you do not...and when I was on my holiday (US:
vacation), I stopped off at Yeoh's home island and, boy, were there
stunning views there...having chicken rice 800 feet up looking across
to the mountains on the mainland stretching off into the distance,
next to palm trees in a tropical climate...aaah, bliss ;)
> For Guga, you have no idea of the amount of very hard and
> very boring stupid work he did all along the past year, at
> collecting Data by hand, achieving now into a 3.5 Megas Files
> of Infos that we are now going to turn into an ApiViewer.
No, I do actually have some idea and that's why I said 100% hats off
and R.E.S.P.E.C.T. to Guga, that's a mighty mountain of work...heck,
it's _exactly_ about realising how much work is involved that I'm
starting and promoting this "ConvInc" project to try to _spare_ as
much of that work as possible for as many people as possible...it's a
major stumbling block in assembly programming in general that such
massive volumes of translation work need to be done to get full OS
support and access to things like OpenGL or X and so forth...indeed,
anyone who doubts the usefulness of what I'm talking about with that
project, I'd direct to Guga to explain _just how much work_ is
involved if you want to do it all manually...this is why when people
say "but an automated tool can't do it 100%" then I still say it's
worth it...even if can only do 10% (delibrately a crap estimate to
make the point...it can surely do much better than that ;), we're
talking in the case of something like comprehensive Win32 support,
_tens of thousands_ of API that the figures are so high that 10% of
this is _still_ not anything to be sniffed at, at all...
> This is not only the Equates List, which is completed since
> some long time, now. This is also for all Structures, all Api
> Functions, with Comments, and all the necessary informations
> for building a Viewer providing all Links between all components
> of this incredible amount of Data.
Yeah, it's a phenomenal amount of work...and, hmmm, I notice that you,
Rene, aren't doing this work...someone else is doing it for you...a
bit like how you are depending on the "pioneers'" work?
The real reason you're avoiding Linux and have built a _Windows
assembler_ despite being anti-Microsoft, I reckon, is not this "no
futur" nonsense...writing a Win32 assembler, you can "borrow" the
"pioneers'" work...get a bunch of people like Guga to do all the
_real_ hard work...whereas, if you were working for Linux, you'd have
to become the "pioneer" and would have to do your own work finding out
how it works rather than just using the Win32 "pioneers'" work...you
avoided Linux because you could work off other people's work and rope
in the higher amount of Win32 users to find someone to do all the
_hard work_ like Guga is doing to be done for you...
Again, the truth is, you accuse Randy with _your_ "crimes"...Randy
took HLA over to Linux and simultaneously pioneered ASM "cross-OS
portability" at the same time...it's _you_ who shys away from the real
work, Rene...indeed, hats off to Guga or you'd have practically
_nothing_ without his hard work propping you up...
> One year ago, we would have made all of this free work available
> for all Assemblers Projects, and we would, much probably offered
> all of this work Open Source, with a "ListBox" for conversion to
> other Assemblers syntax, with simple parsers converting to the
> other Assemblers Formats.
>
> Nowadays, this is made absolutely impossible. We can no more
> provide all of this work open and have master Pdf reusing it for
> his own glory.
So, basically, what you're saying is because of a _personal vendetta
of jealousy_ that you have with Randy, you'll hang everyone else out
to dry, cancel friendships, make people _suffer_ when you could have
done something, go closed source, become unethical, reject our valid
LuxAsm efforts because I don't support your _personal vendetta_
against Randy, etc., etc....?
Please tell me that you _do_ realise why people kicked you off all
those forums...it's because you have such a major _ego_ that simply
doesn't care in the slighest about what it does to other people, so
long as you have your "blood" in this quite pointless "revenge thing"
you have...
> So, we are actually studying how to release all of
> our OS Data under a Closes Sources form with some organisation
> that will, on purpose, make the Data recovering a real work, and
> it will remain under that very stupid form as long as master Pdf
> will remain a danger for the future of Assembly.
From the "Open Source Definition":
------------------------------------------------
2. Source Code
The program must include source code, and must allow distribution in
source code as well as compiled form. Where some form of a product is
not distributed with source code, there must be a well-publicized
means of obtaining the source code for no more than a reasonable
reproduction cost–preferably, downloading via the Internet without
charge. The source code must be the preferred form in which a
programmer would modify the program. Deliberately obfuscated source
code is not allowed. Intermediate forms such as the output of a
preprocessor or translator are not allowed.
Rationale: We require access to un-obfuscated source code because you
can't evolve programs without modifying them. Since our purpose is to
make evolution easy, we require that modification be made easy.
------------------------------------------------
If you are delibrately obfuscating your source code in any way, Rene,
then you are in violation of the spirit of "open source"
development...
You're also arguably in violation of the GPL requirement: "The source
code for a work means the preferred form of the work for making
modifications to it" and delibrately obfuscated code making it
delibrately difficult to modify would be an incredibly hard sell to a
judge...
Thus, _YOU_ are producing "closed source" software and are choosing to
be "unethical" by your own standards...again, simply because of this
strange _personal vendetta of jealousy_ you have towards Randy...
Basically, it's clear...you're going to sink your ship and take down
the entire fleet with you: Supporting Microsoft, alienating other
assembler authors, destroying the assembly community, abandoning
friends, abandoning your principles, ethics, morals and anything and
everything...you will sacrifice everything and attack at all costs
over what was probably some stupid thing ages back when Randy probably
said something to you that made you look a bit silly that you "vowed
to have your revenge" and this obsession is going to bring everything
down and burn everyone, just so that Shylock can get his "pound of
flesh"...sorry, Rene...but that is simply _pathetic_...
> We had, very recently a pretty good example of Master Pdf attitude,
> when steeling others works, for free, with my own "Underscore"
> example: I thought he would not contest the fact, as, in a thread
> called "SpAsm Review", right here, several years ago, _he_ said
> publicly that this was a real great innovation of mines and a real
> good idea. Nowadays, whereas he re-uses the idea for HLA Numbers
> format, he is saying that this was existing years before i
> "re-invent" this. Well, we can expect that a similar thing would
> happend with Guga hard work: "All of this was taken from MicroSoft
> Material and other freely available Infos found on the Net, so you
> created nothing at all... and this work is mine as well...".
You're a very sad, sad twisted little paranoid man...you do realise
this, don't you? Your "revenge" obsession is going to damage and
destroy so much good for a useless, useless "pound of flesh"...what
was it? Randy years ago corrected some mistake you'd made in a posting
and your ego couldn't take that so it swore obsessional revenge?
I mean, you're giving up principle...you're giving up ethics, morals,
"open source", etc....you're giving up friends and allies...you're
giving up making your tool useful...you're giving up all the good you
could have done in helping people...you're giving this all up...and
for what? Petty, petty revenge?
It's not worth it, Rene...sincerely...it's not...Annie hit the nail on
the head:
GET OVER IT!
Beth ;)
Beth
> > Here is it:
> >
> > Master Pdf:
> >
> > //
> > This is an interesting approach (ignoring underscores). It
> > provides a cheap and easy way of allowing the insertion of
> > underscores nearly anywhere in the program (the part about this
> > I like is that it lets programmers use this feature in ways the
> > original designer never dreamed of).
> > //
>
> ... and
>
> //
> Since underscores are
> important in external names I can envision some
> problems developing here. Nevertheless, other than
> this one quick point I won't criticize this feature
> too much because I haven't had time to study the
> ramifications of lexically ignoring underscores.
> //
Ummm, sorry...there's NO claim of credit in this _AT ALL_...Randy's
tone throughout actually comes across like he's talking about _someone
else's_ feature and how, after looking at it (rather than thinking it
up himself), he likes it...perhaps your English is not up to
interpreting what's actually being said here...there honestly is NO
claim of credit on the idea here at all...it's kind of suggesting the
opposite, in fact...the line: "I won't criticize this feature too much
because I haven't had time to study the ramifications" suggests
entirely the _opposite_...that Randy is looking over _someone else's_
idea and is just saying "you know, I kind of think this idea is really
neat...there might be a problem with underscores and external names
but maybe not...I'd need to do more research into that to see
exactly"...
Surely this obsessional "revenge thing" hasn't gone so far that you're
now basically _blind_ to being able to read simple statements?
Beth :)
Beth
> just raced into armed robberies and terrorist raids blindly
(actually,
> that kind of reminds me of that brilliant "Leon" film where a lone
> hitman takes on an entire police force to protect a little girl...an
> excellent film that we'll overlook that he was, in fact, saving
Darth
> Vader's mother! ;)?
Correction: I, of course, meant Darth Vader's _girlfriend_...and _Luke
Skywalker's_ mother...ah, the plot gets ever more confusing with that
"epic", eh? ;)
Beth :)
Randall Hyde
>
> As for the URL, SourceForge is all "standardised" and has a "search"
> thingy to immediate find a project from the name...so I was kind of
> thinking "hey, people aren't that stupid that they can't work this out
> for themselves!" but, okay, if you want more direct links:
Ah! But you're assuming that I know the first thing about source forge.
Actually, I do, having been set up as a developer for alink a while back,
but I've never really used source forge, so I don't really know how it
operates. I suspect I'm not the only one in this boat, which is why an
URL is always a good thing.
Cheers,
Randy Hyde
Beth
> Beth wrote:
> > As for the URL, SourceForge is all "standardised" and has a
"search"
> > thingy to immediate find a project from the name...so I was kind
of
> > thinking "hey, people aren't that stupid that they can't work this
out
> > for themselves!" but, okay, if you want more direct links:
>
> Ah! But you're assuming that I know the first thing about source
forge.
> Actually, I do, having been set up as a developer for alink a while
back,
> but I've never really used source forge, so I don't really know how
it
> operates. I suspect I'm not the only one in this boat, which is why
an
> URL is always a good thing.
Yes, yes...true enough, I suppose...well, I just wasn't "on that
wavelength" at the time, is all...it's corrected now to everyone's
satisfaction, Hopefully :)
Beth :)
Randall Hyde
>
> Rene lie #1:
> Randy wrote AoA to support HLA, whereas RosAsm is NOT a "Windows
> assembler"...
>
> Actual facts:
> Randy had written 16-bit AoA a long while back and other people used
> that - which was written for MASM - so it's not difficult to show
> that's the case without any arguments about that...
[snipped-very good argument concerning dates to back up my explanations]
Leaving mere facts and history aside, I find it amazing that anyone would
believe that someone like myself would write on the order of a quarter
million
lines of source code (between the HLA compiler, standard library, test code,
sample code, and code that got tossed away) just on some massive ego-
glorification trip. Not to mention, put up with the abuse I've taken (and
not
just from Rene) over the past four years. Boy, if this is ego-gratification,
I *really* need to seek some professional help :-)
In one respect, though, I have to agree with Rene. It is *very* gratifying
to
see that my efforts have begun to pay off and thousands of people are
learning
assembly language using the new version of AoA. You know what? They
really don't care if the chicken or the egg came first. The fact that they
were
both (HLA and AoA) available when they decided to learn assembly language
programming is what's important to them. The fact that HLA makes their
learning
experience more comfortable is important to them. And all the arguments
about
"you should really learn assembly by: (1) Writing your own assembler, (2)
reading
the manufacturer's data sheets, (3) by programming in hex, (4) by suffering
like
'I' did, ...." just doesn't wash with that crowd.
> What is this really all about? Well, you created a _Windows assembler_
> for your own "auto-glorification" by, indeed, depending on the work of
> the "pioneers" who pushed open the closed door of Windows assembly
> programming...and you did NOT target Linux or OS/2 because that would
> have required _YOU_ to do "pioneering" on these different
> platforms...you didn't want the work (which Randy _DID_ do in making
> HLA work on Linux and LuxAsm is going to do in taking this over to
> Linux, where really an "ethical" project _should always have been_
> :)...
This is one thing I've always wonder about in Rene's logic.
He accuses me of following the pioneers (which I readily admit to doing,
even in the case of Linux). Yet when I look at what he has done, about
the only thing truly novel is burying the source in the executable file. Oh,
he can claim small victories here and there ("why *I* used 'right-click' to
do what requires a menu selection in another IDE..."), but I've yet to see
the ground-breaking work like the Iczelion tutorials, the Agner optimization
documentation, or the Ralf Brown interrupt list that he feels must be
written
by an assembler author in order to qualify as an important "assembly
person."
I must give Rene his due, however. He serves one really important function
for society and assembly language. His assembler attracts people like
H.A.W. (wannabe) so the other assembler authors don't have to put up
with them :-).
> Oh yes, indeed, you accuse Randy of sitting on his laurels too lazy to
> do his own work but just "stealing" the "pioneers'" work...but, Rene,
> this better describes _YOU_, doesn't it?
This is very amusing. I made the same accusation to him today over
in the MASMForum. The dude's been promising this UI "wizards" and
"preparsers" for quite some time now. Things that assembly language
programmers are geniunely interested in. He's been sitting around
playing with his disassembler tool, which is of *far* less interest to
the average assembly programmer. In the meantime, other IDEs such
as RadASM are getting better and better every day. Rene claims that
the Wizards will become important when ReactOS arrives. By then,
RadAsm, WinAsm, etc., will all already have this functionality and
they will eat his lunch. And even if ReactOS does take off big, Rene
seems to have forgotten that all these other IDEs will run just fine
under ReactOS, as well...
The truth is, at one time SpAsm had a *big* advantage over other
assemblers because it actually had an IDE. That advantage has shrunk
to zero as these other IDEs surpass SpAsm's capabilities. Yes, Rene
could actually have claimed to have been a pioneer with respect to
assembly IDEs. But as is usually the case, pioneers take the arrows
while settlers take the land. And while Rene's been resting on his
"IDE laurels", other products have surpassed RosAsm's functionality.
> > 4) Now, he is making up his mind that, whatever he could do,
> > the day i will start actively promoting RosAsm, he could never
> > win the competition,
>
> What are you talking about? 4 million hits, TV appearances, published
> works, a long established name and reputation, a tool that even in its
> "prototype" form makes most of the other tools look distinctly
> _amateur_...
In order to "win" a competition, there has to be competition :-)
>
> > he is trying to have his Webster becoming
> > the universal "reference" for everything available (for free)
> > in the Assembly Area.
>
> Oh dear, how terribly "evil" of him! He intends to create a free
> one-stop comprehensive resource for all x86 assembly language! The
> dastardly swine that he is...
My goodness. Rene and I agree 100% on something.
Okay, not 100%. I will not promote RosAsm on Webster until
he grows up a little bit and treats everyone around here with a little
more respect. But he is absolutely right that I'm seeking to make
Webster a "universal reference" for x86 assembly language. That
was true long before AoA/32 and HLA came along. And I know
a lot of HLL types who think that what I'm doing is truly evil :-).
"Why, teaching people that programming in assembly language
is a reasonable thing to do, how evil of you!"
> Heck, if Randy is only doing this stuff for "auto-glorification"
> (which isn't true...this more accurately describes _your_ motives and
> don't think I ain't finally worked that out, Rene ;) then "let him
> have that!",
I would have thought that Rene might have an inkling of how much
work it is to create Webster, AoA, HLA, etc., if for no other reason
than he's abandoned such projects (translating AoA to SpAsm, for
example) because of the work involved. Again, even if the work
wasn't too much, you've figure the grief I have to take over all this
wouldn't be very satisfying. Rene has some strange ideas about
"auto-glorification."
>
> > By the way, this is only a re-activation
> > of an attitude he always had (for example, some long time ago,
> > when a guy asked, at the Evil Board, "what about the dead APJ?",
> > he, of course, immidiately raised his hand up, to "offer his
> > "good will services" as a new maintainer of the APJ -...-).
>
> Yes, indeed; There is such "auto-glorification" in merely being the
> editor of a publication that accepts _voluntary_ articles of _useful_
> assembly knowledge and compiles them together into an ASCII file...so
> much "auto-glorification" because, indeed, you could name the old APJ
> maintainer without looking it up, couldn't you? There is no way to
> become more "famous" than to do this! Indeed, people ask "Who is
> Britney Spears? Who is George Bush?" but, of course, _everyone_ knows
> who the maintainer of APJ is...there is no greater prize of
> "auto-glorification"!
This is really funny.
Obviously, Rene has no idea how much *work* it is to publish
something like a newsletter. BTW, Rene, I offered to be the *publisher*,
not the editor - I sought to get six rotating editors who would take
care of two issues per year; I was more or less offering to host the
journal [or something like it] on Webster as Webster is a popular
destination for people searching for assembly information. It might
also please you to know that I've offered to host the clax/ala x86 FAQ
on Webster. Boy! What auto-glorification! The work required to
(1) get the FAQ caught up, and (2) keep in maintained, is looking to
be a real nightmare. Thank God Ben Lunt has offered to help.
Thank God Ray Moon has been supportive. Hopefully I won't have
a coronary doing this :-) Why, it's going to make me *soooooo*
much more famous than I already am, I'm just dying for the opportunity
to do this (NOT!). But it has to be done and somebody has to do it.
So I'm looking into it.
> > Now, he is doing all he can, to make friend with the other
> > Assemblers Authors,
>
> How "evil"! He is being friendly and helping people! Is there no end
> to such "evilness"?!
:-)
I even tried to be friendly with Rene at one time.
Too bad I made the mistake of supporting MASM back then :-(.
> > having these Assemblers referenced from his Site, with dedicated
> Pages,
>
> Monsterous! He dares to direct people to other assembly resources!!
> Dedicates his time and effort to the promotion of assembly language in
> general...clearly, such selflessness is, ummm, somehow all about
> "auto-glorification"...and he directs people to _other_ assemblers and
> assembly resources in order to "lock" people into HLA...or
> something...ummm, give me a while to work out how on Earth that
> utterly illogical paradox could be even remotely true...
This reminds me of a cartoon I saw after the Super Bowl.
The caption read "The person most offended by Janet Jackson's display"
It was a picture of Madonna saying "Now why didn't I think of that?"
>
> > proposing materials about "Compilers Theory",
>
> Yes; This is his greatest "evil"...he seeks to _educate_ people! Give
> them the knowledge that they'll need to write great software...the
> dastardly swine! This could only serve the purpose of...ummm...helping
> Monsanto Nazis punish Third World farmers...it's so obvious and
> "clearly defined", that it's become impossible to see any connection
> or even basic logic to his dastardly "evil" plans!!! ;)
The truth is, Rene's probably afraid some of his RosAsm minions might
read this stuff and learn how elementary the design for RosAsm really is
:-).
>
> > and redistributing everything he can do for free
>
> Yes, that is just so "evil", isn't it? Really, _read this stuff back
> to yourself_...you're a raving looney, Rene...all your screws are
> loose...and that's the _politest_ way it can be phrased...
>
> > (free of real work, of course).
>
> Oh, come on...you really believe _anyone_ is going to swallow this
> tripe? You're saying that Randy does no work at all? These arguments
> are well beyond "black is white" nonsense...you're simply ranting pure
> insanities now...
That's right. Free of work. Why, all those web pages magically appeared
on Webster all by themselves! Why, all those files got collected and stored
on a high-bandwidth server by someone else. Why, no one bothered asking
permission from Dr. Terry to put his compiler book up on Webster.
Why....
Rene seems to think this is something new? When Hutch asked me to
put MASM32 up on Webster to reduce the bandwidth requirements at
his site, I immediately did so. I've always had links to the other
assemblers
(including SpAsm, I might add) on Webster. What's he thinking?
>
> > The final goal, with all of this, is double side:
> >
> > 1) Becoming a universal Asm reference without doing anything.
>
> This is simply a lie...but then, if other people benefit from that
> "universal ASM reference" and he links off his site to all the other
> assemblers and promotes them all on their respective "dedicated pages"
> (your words) then, sorry, where the fudge is this "evilness" supposed
> to come from?
I, too, love his logic. In the past he has commented about how he doesn't
have the time to crank out all those PDF files like I do. As whatever it
is that I'm doing seems to be too much work for him, I fail to see the
logic in his statement that Webster is becoming a universal reference
without doing anything.
>
> > 2) Isolating RosAsm as much as possible, while we are not yet
> > over with the real hard work, and while ReactOS not yet ready
> > for end users.
>
> "Isolating"? Nope, sorry...he promoted you at first but you didn't
> like being helped as it bruised your "ego"...so then he ignored you
> but still you persisted in attack...so, he finally snapped and wrote a
> single series of posts pointing out _factually_ just how _incompetent_
> you actually are with RosAsm...and now you have been sent to
> Coventry...completely _ignored_...
And if he really wanted support for RosAsm on Webster, he could
very easily get it. All he has to do is to start being civil; and he could
begin by making a few slight deletions to B_U_ASM. Until then,
he has to be really mentally ill to think that I would go one inch out
of my way to promote his product.
> > So, now on, the war between Master Pdf and me will be
> > "absolute".
>
> Yes, absolutely comical...he's not even paying any attention to you,
> Rene...
I have to agree Beth. It's comical. There was a time a year ago when
it was necessary for *me* to respond to his nonsense. But he's pissed
off so many people now that I don't have to respond. You'd think he'd
get the point sooner or later. I guess as long as he doesn't feel I've made
"friends" with everyone around here he'll stick around and be as
caustic as ever.
> > Recently, though i like a lot a guy like JohnFound
> > and share most, if not all, of his ideas, i completely closed
> > any relationship with the FASM/Fresh so interresting group.
>
> Yeah, and I'm sure he finds you a good "friend" in simply tossing him
> away on something so irrelevent and trivial...
That does appear to be the Rene way...
> > The things are clear and simple: If Master Pdf is allowed to
> > post messages at FASM Board without being kicked out, i have
> > no more anything to do there.
>
> Well, this is clearly illogical; If this is the criteria - that you
> pull out of anything that Randy posts to, whatever he might be
> saying - then, surely, you should have "no more anything to do" with
> this group? Why aren't you also stopping posting your nonsense here?
> Randy posts here...as regular as clockwork...why one set of rules for
> FASM and one set of rules here?
Well, I haven't made friends with everyone, of course :-)
I wonder if I started posting on the RosAsm board and made lots
of friends there, he would stop posting on the RosAsm board :-).
> > So is it for this OS Data Project: If Master Pdf, and Master
> > Pdf's supporters are inside, this is an Anti-Assembly project,
> > whatever real work could be done there.
Yes. Creating a single database of equates that can automatically
be converted to different assemblers' syntaxes is definitely
"anti-assembly".
By the way, Beth, you might remind Rene that this was actually *your*
idea initially, not mine. I just think that it's a real good idea and am
willing to support it.
> > For YeoHs, I do not know what he will do, but i would be a
> > bit surprised if he would go on contributing to this. The
> > guys using RosAsm and contributing to RosAsm are usually
> > not the more stupid ones, you know...
>
> Well, excluding yourself, Rene...then I'd agree that Yeoh is exactly
> the kind of guy I'm happy is contributing to LuxAsm and ConvInc...he
> seems to actually understand the meaning of the words "ethical" and
> "useful" where you do not...and when I was on my holiday (US:
> vacation), I stopped off at Yeoh's home island and, boy, were there
> stunning views there...having chicken rice 800 feet up looking across
> to the mountains on the mainland stretching off into the distance,
> next to palm trees in a tropical climate...aaah, bliss ;)
Poor Rene.
He doesn't realize it, but he's about to scare off another enthusiastic
contributor to the RosAsm project. He needs to learn to control
himself better. Given the small number of people that respect him,
he should cherish them, not insult them. Oh well...
> > For Guga, you have no idea of the amount of very hard and
> > very boring stupid work he did all along the past year, at
> > collecting Data by hand, achieving now into a 3.5 Megas Files
> > of Infos that we are now going to turn into an ApiViewer.
>
> No, I do actually have some idea and that's why I said 100% hats off
> and R.E.S.P.E.C.T. to Guga, that's a mighty mountain of work...heck,
> it's _exactly_ about realising how much work is involved that I'm
> starting and promoting this "ConvInc" project to try to _spare_ as
> much of that work as possible for as many people as possible...it's a
> major stumbling block in assembly programming in general that such
> massive volumes of translation work need to be done to get full OS
> support and access to things like OpenGL or X and so forth
And, sadly, Rene doesn't even realize how much this could help *him*.
He has some misguided idea that this is all some big scheme to
rip off the RosAsm project. Definitely paranoid. I have *no idea*
where he got the impression that I was *ever* interested in his equates
file. It's nowhere near sufficient for an advanced assembler like HLA.
As history indicates, I'd prefer starting with the MASM32 equate
list, if I wasn't going to start with the original source of those
constants,
types, etc. (i.e., the C include files). I guess harping on the RosAsm
equates is Rene's way of making himself feel more important. The whole
discussion on the RosAsm board of somehow "protecting" their investment
in this work is ludicrous. *I* certainly have no interest in what they've
done.
I can't imagine too many others care much either, when the MASM32
headers are quite a bit more sophisticated and tested.
> > This is not only the Equates List, which is completed since
> > some long time, now. This is also for all Structures, all Api
> > Functions, with Comments, and all the necessary informations
> > for building a Viewer providing all Links between all components
> > of this incredible amount of Data.
>
> Yeah, it's a phenomenal amount of work...and, hmmm, I notice that you,
> Rene, aren't doing this work...someone else is doing it for you...a
> bit like how you are depending on the "pioneers'" work?
No, he's getting this great set of equates without doing any work on his own
:-)
> > One year ago, we would have made all of this free work available
> > for all Assemblers Projects, and we would, much probably offered
> > all of this work Open Source, with a "ListBox" for conversion to
> > other Assemblers syntax, with simple parsers converting to the
> > other Assemblers Formats.
> >
> > Nowadays, this is made absolutely impossible. We can no more
> > provide all of this work open and have master Pdf reusing it for
> > his own glory.
>
> So, basically, what you're saying is because of a _personal vendetta
> of jealousy_ that you have with Randy, you'll hang everyone else out
> to dry, cancel friendships, make people _suffer_ when you could have
> done something, go closed source, become unethical, reject our valid
> LuxAsm efforts because I don't support your _personal vendetta_
> against Randy, etc., etc....?
This is one thing Rene keeps talking about that really baffles me.
He talks like this system of equates is extremely valuable - a feature no
other assembler has and, therefore, I'm going to rip him off; therefore,
he must work hard to prevent this. The truth is, just about *every*
assembler out there has a decent set (if not complete) of Win32
equates, prototypes, and definitions. I fail to see why he thinks that
the RosAsm definitions are so important to me or any other assembler
author. In fact, without structs, function prototypes with parameters,
type definitions, and so on, his equates list is not very useful to advanced
assembly programmers like MASM, TASM, and HLA users. Perhaps
he just doesn't realize this. Perhaps he does realize how useless the
RosAsm equates really are and he's trying to "pump up them hype"
so the RosAsm team can get *some* credit for the hard work they've
put in. Whatever the case, he totally misses the whole concept behind
your ConvInc facility - to minimize the maintenance needed on these
common include files. What a shame.
> > So, we are actually studying how to release all of
> > our OS Data under a Closes Sources form with some organisation
> > that will, on purpose, make the Data recovering a real work, and
> > it will remain under that very stupid form as long as master Pdf
> > will remain a danger for the future of Assembly.
>
> If you are delibrately obfuscating your source code in any way, Rene,
> then you are in violation of the spirit of "open source"
> development...
The truth has finally come out, Beth. Rene doesn't really care about
open source or the GPL. Remember, RosAsm was a weapon in the
war against Microsoft (and, later, HLA). Open Source/GPL was a
great thing to offer people who didn't have that option with MASM.
It was a marketing ploy that Rene was using to "sell" his system.
But the moment it looks like this weapon could be used against
him, he no longer supports it. I wouldn't be surprised to find that
he teams up with Microsoft to fight against HLA someday :-)
>
> Basically, it's clear...you're going to sink your ship and take down
> the entire fleet with you: Supporting Microsoft, alienating other
> assembler authors, destroying the assembly community, abandoning
> friends, abandoning your principles, ethics, morals and anything and
> everything...you will sacrifice everything and attack at all costs
> over what was probably some stupid thing ages back when Randy probably
> said something to you that made you look a bit silly that you "vowed
> to have your revenge" and this obsession is going to bring everything
> down and burn everyone, just so that Shylock can get his "pound of
> flesh"...sorry, Rene...but that is simply _pathetic_...
I think you've pretty much called it the way I've been seeing it for the
past year.
> > We had, very recently a pretty good example of Master Pdf attitude,
> > when steeling others works, for free, with my own "Underscore"
> > example: I thought he would not contest the fact, as, in a thread
> > called "SpAsm Review", right here, several years ago, _he_ said
> > publicly that this was a real great innovation of mines and a real
> > good idea. Nowadays, whereas he re-uses the idea for HLA Numbers
> > format, he is saying that this was existing years before i
> > "re-invent" this. Well, we can expect that a similar thing would
> > happend with Guga hard work: "All of this was taken from MicroSoft
> > Material and other freely available Infos found on the Net, so you
> > created nothing at all... and this work is mine as well...".
>
> You're a very sad, sad twisted little paranoid man...you do realise
> this, don't you? Your "revenge" obsession is going to damage and
> destroy so much good for a useless, useless "pound of flesh"...what
> was it? Randy years ago corrected some mistake you'd made in a posting
> and your ego couldn't take that so it swore obsessional revenge?
Nor can Rene accept the fact that the "underscore thing" was taken from
Ada, which was designed over 20 years *before* he even thought about
SpAsm :-). Talk about grasping at a piece of glory.
I feel pity for Rene, really. It is amazing how many people started out
agreeing with his description of HLA that have turned against him over
the past year or two because of his insane arguments.
Cheers,
Randy Hyde
Betov
$Zs...@newsfep3-gui.server.ntli.net:
Or, maybe your demential support of HLA turns you blind
to any correct interpretation of any master Pdf sentence.
These ones are coming from a Post evidently, and as usual,
written in the only purpose of discrediting SpAsm as much
as possible. And when a swindler like master Pdf says a
sentence like:
"I haven't had time to study the ramifications of lexically
ignoring underscores".
... i think everybody could easily hear:
"Arghhh!... i never saw that before, and i am stuck...".
Not you, Beth? Too bad for you...
Also about "NO claim of credit in this _AT ALL_"... i do
not know how bad my english could be, but i am quite sure,
that, here, you should review _yours_, as i don't remember
i wrote anywhere that master Pdf would have given me credit
of anything... (what would be a real pain to me, by the way).
Betov.
< http://betov.free.fr/RosAsm.html >
Frank Kotler
>>URL is always a good thing.
>
> Yes, yes...true enough, I suppose...well, I just wasn't "on that
> wavelength" at the time, is all...it's corrected now to everyone's
> satisfaction, Hopefully :)
Beth meant to say:
or:
http://www.sf.net/projects/convinc
And by the way, LuxAsm's membership isn't "closed", either!
http://luxasm.sf.net
http://www.sf.net/projects/luxasm
(speaking of URL's, I'm getting a 404 on your "Documentation.zip", shr
[wannabe], 1)
Speaking of 404's, I've gotta share this with y'all:
1: go to www.google.com
2: type in: "weapons of mass destruction" - do not hit return or enter.
3: click "I'm feeling lucky" button, not the "Google search"
I apologize for the off-topic-ness, but I think even Betov'll like it.
Best,
Frank
When you go down to the city,
You've got to learn to shout.
When you go down to the city,
You've got to learn to shout.
'Cause if you don't stand up and holler,
You're going to be left out.
(with apologies to Mose Allison, I've butchered his lyrics, I'm sure)
Betov
@attbi_s54:
> Speaking of 404's, I've gotta share this with y'all:
>
> 1: go to www.google.com
>
> 2: type in: "weapons of mass destruction" - do not hit return or enter.
>
> 3: click "I'm feeling lucky" button, not the "Google search"
>
> I apologize for the off-topic-ness, but I think even Betov'll like it.
>
Yes, i like it. Though i had prefer:
"Sorry, the US Services are so bad and so insecure that
US governement has been afraid of bringing the evidences
in their army pockets when invading Irak, but keep sure
that if the invasion fully succeed we will do our best for
having some, in there, later".
Betov.
The Half A Wannabee
"Frank Kotler" <fbko...@comcast.net> wrote in message
news:k%LYb.5071$Xp.51733@attbi_s54...
> Beth wrote:
>
> >>URL is always a good thing.
> >
> > Yes, yes...true enough, I suppose...well, I just wasn't "on that
> > wavelength" at the time, is all...it's corrected now to everyone's
> > satisfaction, Hopefully :)
>
> Beth meant to say:
>
> http://convinc.sf.net
>
> or:
>
> http://www.sf.net/projects/convinc
>
> And by the way, LuxAsm's membership isn't "closed", either!
>
> http://luxasm.sf.net
> http://www.sf.net/projects/luxasm
>
> (speaking of URL's, I'm getting a 404 on your "Documentation.zip", shr
> [wannabe], 1)
Its because I spelled it Documentation.Zip and made a link to
Documentation.zip
luvr
> Speaking of 404's, I've gotta share this with y'all:
>
> 1: go to www.google.com
>
> 2: type in: "weapons of mass destruction" - do not hit return or enter.
>
> 3: click "I'm feeling lucky" button, not the "Google search"
>
> I apologize for the off-topic-ness, but I think even Betov'll like it.
LOL!
And, just to continue the good old off-topic tradition, here's a link that I
found to the stolen SCO code in Linux:
http://www.linuxstolescocode.com
--Luc.
luvr
> Surely this obsessional "revenge thing" hasn't gone so far that you're
> now basically _blind_ to being able to read simple statements?
At the risk of stirring this thing up all over again - It is my feeling that
René is really taking a "religious" position here - and he sounds much like
a religious fundamentalist at that. You know, stating a "Universal Truth" -
No, "THE Universal Truth" - and accusing anyone who openly admits to having
a different opinion, of "blasphemy." Looking at it this way, I'm beginning
to perfectly understand that Randall got irritated enough to post an ugly
topic like "Rene is a hypocrite (OK, what else is new?)" - which, however
understandable, does remain unfortunate, and (as far as I can tell) is
really quite the opposite of Randall's "normal" mode of operation...
Sorry, but I just had to get this off my chest. Now that I've let go of it,
I'll leave it to rest.
Sorry again,
--Luc.
qual1
little minded dictators. If people had more courage to do this the world
would truly be a much better place for all of us.
John
Betov
news:4033c033$0$7040$ba62...@news.skynet.be:
When seeing there were several like this, i gave a try to:
"MicroSoft Eula Protects you"
... with no luck.. Too bad... :))
Betov.
Beth
> Beth wrote:
> >>URL is always a good thing.
> >
> > Yes, yes...true enough, I suppose...well, I just wasn't "on that
> > wavelength" at the time, is all...it's corrected now to everyone's
> > satisfaction, Hopefully :)
>
> Beth meant to say:
>
> http://convinc.sf.net
>
> or:
>
> http://www.sf.net/projects/convinc
>
> And by the way, LuxAsm's membership isn't "closed", either!
>
> http://luxasm.sf.net
> http://www.sf.net/projects/luxasm
Oh, geez Louise, I've got keep posting the URL all the time? "Beth
meant to say" nothing because I'd already posted up the URLs elsewhere
in the thread...this "promotion" lark is very bothersome, isn't it?
Like, it's not as if "Google" and "SourceForge" are difficult to find
or use, is it? I mean, what kind of "member" are we talking about who
can't handle having the name of the project and that it's on
SourceForge...but then is expected to use an external SSH shell
program to access CVS using "keys" generated by a separate utility to
alter the integrated modular Linux code of an ELF-producing assembler?
How's that work? Some kind of "selective mental block" triggered by
the hypnotised "code word" of seeing "google" written on the page but,
otherwise, they have no problems with complicated procedures...
Weird...
Beth :)
P.S. I'm kidding around here, obviously...it makes perfect sense to
post up the URLs - it's a "convenience" rather than "intelligence"
thing, I realise - I just didn't think about it at the time, is all ;)
T.M. Sommers
> "T.M. Sommers" <tm...@mail.ptd.net> wrote in message
> news:NRycnS_iyIf...@ptd.net...
>
>>Have a single front end, and multiple back ends, one for each
>>target language or platform. There is an intermediate form, but
>>it is not saved. This is how the GCC does it.
>
> And what is it that the "front end" processes?
> C files?
Yes.
> Alas, C header files contain too many things that
> cannot be converted to assembly source code for use as
> (reasonable) input to some assembler.
Then ignore those bits. You would have to do that whether the
translation is done manually or automatically.
T.M. Sommers
> Randy wrote:
>
>>T.M. Sommers wrote:
>>
>>>Have a single front end, and multiple back ends, one for each
>>>target language or platform. There is an intermediate form, but
>>>it is not saved. This is how the GCC does it.
>
> _I_ was considering here, anyway...the intermediate form can be saved,
> perhaps, but that's an "optional extra"...
>
>>And what is it that the "front end" processes?
>>cannot be converted to assembly source code for use as
>>(reasonable) input to some assembler.
>
> of other things too?
Yes it does, plus Fortran and a few others. That is what I was
talking about. GCC (The GNU Compiler Collection) uses multiple
front ends, one for each language, and a single back end to
generate code (well, if you look at a single platform; if you
look at all the platforms, it has multiple back ends, too).
>>>The problem with saving the intermediate form is that it becomes
>>>outdated. Even if its creation is 100% automated, it is still
>>>something that requires maintenance.
>
> [ You can always "MAKE" the files...if the intermediate file is older
> than the original file, re-process...if not, the utility is not
> called...using the "external" functionality of MAKE, even this can be
> "automated" by just considering it as one more "step" in the build
> process...MAKE'll take care of the rest looking at the time stamps
> :) ]
Keeping the intermediate form lying around still requires an
extra bit of maintenance, even if it can be automated. Best to
avoid it if possible.
> Indeed, _OF COURSE IT WILL REQUIRE MAINTENANCE_!!
>
> I mean, what on Earth are you expecting here, to be blunt? That we're
> going to weave some "magic" where there's one special tool that
> automatically writes all your code for you and always does a perfect
> job that no human intervention is ever necessary?
Yes.
> Hey, if that's the
> kind of thing that you code, tell the AI people how you did it,
> publish papers on this "magical" new way of doing things...people will
> want to know! :)
I will get started as soon as I find a phoenix feather for my
magic wand.
>> Of course it will require maintenance. In fact, I'd argue that
>> once the intermediate file is cleaned up, *all* maintenance
>> takes place on that file, much like the MASM32 equates are
>> being maintained today.
>
> This is a strange counter-argument...it stinks badly of "I don't like
> the idea, find the first problem I can in order to declare it
> impossible to stop it happening"...
On the contrary, I think it is a good idea in general, and I have
no desire to see it stopped. Why in the world would I want it
stopped, even if I thought it a bad idea? I was merely trying to
offer some constructive suggestions.
You should not assume that anyone who disagrees with you in what
is essentially a brain-storming session is your enemy.
Alex McDonald
===snipped
I couldn't find an appropriate part of this thread to add this to, so
here will have to do. There's a GCC project GCC-XML that generates XML
from C/C++ that could be used to generate asm from .H files by using
XSLT. See http://www.gccxml.org for details.
--
Regards
Alex McDonald
Beth
> I couldn't find an appropriate part of this thread to add this to,
so
> here will have to do. There's a GCC project GCC-XML that generates
XML
> from C/C++ that could be used to generate asm from .H files by using
> XSLT. See http://www.gccxml.org for details.
Ah, okay...cool...when I get time to look, I'll see if this could be
useful :)
Beth :)
Randall Hyde
some of the program's output.
Cheers,
Randy Hyde
"Alex McDonald" <alex...@btopenworld.com> wrote in message
news:b57b10b6.04022...@posting.google.com...
Frank Kotler
>>XSLT. See http://www.gccxml.org for details.
> If anyone has actually run this program, it would be interesting to see
> some of the program's output.
It would??? Okay, it took me a while to get any output at all out of the
damn thing, but I got this out of "Xproto.h"...
<?xml version="1.0"?>
<GCC_XML>
<Namespace id="_1" name="::" members="_3 _5 _6 _7 _4 _8 _9 _10 _11
_12 _13 _14 _15 _16 _17 _18 _19 _20 _21 _22 _23 _24 _25 _26 _27 _28 _29
_30 _31 _32 _33 _35 _36 _34 _38 _39 _37 _40 _42 _41 _44 _43 _46 _47 _48
_49 _45 _51 _50 _52 _53 _54 _55 _56 _57 _58 _59 _60 _61 _63 _62 _64 _65
_66 _67 _68 _69 _70 _71 _72 _73 _74 _75 _76 _77 _78 _79 _80 _81 _82 _83
_84 _85 _86 _87 _88 _89 _90 _91 _93 _92 _94 _95 _97 _96 _98 _99 _100
_101 _102 _103 _104 _105 _107 _108 _106 _109 _110 _111 _112 _113 _114
_115 _116 _117 _118 _119 _120 _121 _122 _123 _125 _124 _126 _127 _128
_129 _130 _132 _131 _133 _134 _135 _136 _137 _138 _139 _140 _141 _143
_144 _145 _146 _147 _148 _149 _150 _151 _152 _153 _154 _155 _156 _157
_159 _161 _160 _163 _162 _165 _164 _167 _166 _168 _169 _170 _172 _173
_174 _175 _177 _179 _181 " mangled="_Z2::"/>
<Namespace id="_2" name="std" context="_1" members="" mangled="_Z3std"/>
<Struct id="_3" name="xRotatePropertiesReq" context="_1"
mangled="20xRotatePropertiesReq" location="f0:1979" file="f0"
line="1979" members="_182 _183 _184 _185 _186 _187 _188 _189 " bases=""/>
<Struct id="_4" name="xChangeModeReq" context="_1"
mangled="14xChangeModeReq" location="f0:1966" file="f0" line="1966"
members="_190 _191 _192 _193 _194 " bases=""/>
<Typedef id="_5" name="xForceScreenSaverReq" type="_4" context="_1"
location="f0:1970" file="f0" line="1970"/>
<Typedef id="_6" name="xSetCloseDownModeReq" type="_4" context="_1"
location="f0:1969" file="f0" line="1969"/>
<Typedef id="_7" name="xSetAccessControlReq" type="_4" context="_1"
location="f0:1968" file="f0" line="1968"/>
<Struct id="_8" name="xListHostsReq" context="_1"
mangled="13xListHostsReq" location="f0:1960" file="f0" line="1960"
members="_195 _196 _197 _198 _199 " bases=""/>
<Struct id="_9" name="xChangeHostsReq" context="_1"
mangled="15xChangeHostsReq" location="f0:1954" file="f0" line="1954"
members="_200 _201 _202 _203 _204 _205 _206 _207 " bases=""/>
<Struct id="_10" name="xSetScreenSaverReq" context="_1"
mangled="18xSetScreenSaverReq" location="f0:1945" file="f0" line="1945"
members="_208 _209 _210 _211 _212 _213 _214 _215 _216 _217 " bases=""/>
<Struct id="_11" name="xChangePointerControlReq" context="_1"
mangled="24xChangePointerControlReq" location="f0:1936" file="f0"
line="1936" members="_218 _219 _220 _221 _222 _223 _224 _225 _226 _227 "
bases=""/>
<Struct id="_12" name="xBellReq" context="_1" mangled="8xBellReq"
location="f0:1927" file="f0" line="1927" members="_228 _229 _230 _231
_232 " bases=""/>
<Struct id="_13" name="xChangeKeyboardControlReq" context="_1"
mangled="25xChangeKeyboardControlReq" location="f0:1921" file="f0"
line="1921" members="_233 _234 _235 _236 _237 _238 " bases=""/>
<Struct id="_14" name="xChangeKeyboardMappingReq" context="_1"
mangled="25xChangeKeyboardMappingReq" location="f0:1914" file="f0"
line="1914" members="_239 _240 _241 _242 _243 _244 _245 _246 " bases=""/>
<Struct id="_15" name="xGetKeyboardMappingReq" context="_1"
mangled="22xGetKeyboardMappingReq" location="f0:1905" file="f0"
line="1905" members="_247 _248 _249 _250 _251 _252 _253 _254 " bases=""/>
<Struct id="_16" name="xSetPointerMappingReq" context="_1"
mangled="21xSetPointerMappingReq" location="f0:1896" file="f0"
line="1896" members="_255 _256 _257 _258 _259 " bases=""/>
<Struct id="_17" name="xSetModifierMappingReq" context="_1"
mangled="22xSetModifierMappingReq" location="f0:1890" file="f0"
line="1890" members="_260 _261 _262 _263 _264 " bases=""/>
<Struct id="_18" name="xQueryExtensionReq" context="_1"
mangled="18xQueryExtensionReq" location="f0:1884" file="f0" line="1884"
members="_265 _266 _267 _268 _269 _270 _271 _272 " bases=""/>
<Struct id="_19" name="xQueryBestSizeReq" context="_1"
mangled="17xQueryBestSizeReq" location="f0:1876" file="f0" line="1876"
members="_273 _274 _275 _276 _277 _278 _279 _280 " bases=""/>
<Struct id="_20" name="xRecolorCursorReq" context="_1"
mangled="17xRecolorCursorReq" location="f0:1864" file="f0" line="1864"
members="_281 _282 _283 _284 _285 _286 _287 _288 _289 _290 _291 _292 "
bases=""/>
<Struct id="_21" name="xCreateGlyphCursorReq" context="_1"
mangled="21xCreateGlyphCursorReq" location="f0:1855" file="f0"
line="1855" members="_293 _294 _295 _296 _297 _298 _299 _300 _301 _302
_303 _304 _305 _306 _307 _308 " bases=""/>
<Struct id="_22" name="xCreateCursorReq" context="_1"
mangled="16xCreateCursorReq" location="f0:1844" file="f0" line="1844"
members="_309 _310 _311 _312 _313 _314 _315 _316 _317 _318 _319 _320
_321 _322 _323 _324 " bases=""/>
<Struct id="_23" name="xLookupColorReq" context="_1"
mangled="15xLookupColorReq" location="f0:1833" file="f0" line="1833"
members="_325 _326 _327 _328 _329 _330 _331 _332 _333 " bases=""/>
<Struct id="_24" name="xQueryColorsReq" context="_1"
mangled="15xQueryColorsReq" location="f0:1824" file="f0" line="1824"
members="_334 _335 _336 _337 _338 _339 " bases=""/>
<Struct id="_25" name="xStoreNamedColorReq" context="_1"
mangled="19xStoreNamedColorReq" location="f0:1817" file="f0" line="1817"
members="_340 _341 _342 _343 _344 _345 _346 _347 _348 _349 " bases=""/>
<Struct id="_26" name="xStoreColorsReq" context="_1"
mangled="15xStoreColorsReq" location="f0:1807" file="f0" line="1807"
members="_350 _351 _352 _353 _354 _355 " bases=""/>
[much snipped... ends like:]
<CvQualifiedType id="_18c" type="_18" const="1"/>
<CvQualifiedType id="_17c" type="_17" const="1"/>
<CvQualifiedType id="_16c" type="_16" const="1"/>
<CvQualifiedType id="_15c" type="_15" const="1"/>
<CvQualifiedType id="_14c" type="_14" const="1"/>
<CvQualifiedType id="_13c" type="_13" const="1"/>
<CvQualifiedType id="_12c" type="_12" const="1"/>
<CvQualifiedType id="_11c" type="_11" const="1"/>
<CvQualifiedType id="_10c" type="_10" const="1"/>
<CvQualifiedType id="_9c" type="_9" const="1"/>
<CvQualifiedType id="_8c" type="_8" const="1"/>
<CvQualifiedType id="_4c" type="_4" const="1"/>
<CvQualifiedType id="_3c" type="_3" const="1"/>
<File id="f0" name="/home/fbk/src/Xproto.h"/>
<File id="f1" name="/usr/include/X11/Xprotostr.h"/>
<File id="f2" name="/usr/include/X11/Xmd.h"/>
</GCC_XML>
I have no idea what I'm looking at. I guess the idea is to use XML to
process this into a "human readable canonical form"???
Maybe that wasn't a good .h file to try it on?
I think it might help us all get on the same page if you posted a short
example of what *you* have in mind for a "canonical form"...
Best,
Frank
Alex McDonald
> If anyone has actually run this program, it would be interesting to see
> some of the program's output.
Here's some; this was from a C program compiled under MSCV6. The output is
positively vast; over 5Mb from a 700 line program, partly because all the
headers are translated too.
<Function id="_7509" name="LCMapStringA" returns="_10536" context="_1"
location="f46:938" file="f46" line="938" extern="1"
attributes="__stdcall__">
<Argument type="_159"/>
<Argument type="_159"/>
<Argument type="_11283"/>
<Argument type="_10536"/>
<Argument type="_11285"/>
<Argument type="_10536"/>
</Function>
<Function id="_7510" name="CompareStringW" returns="_10536" context="_1"
location="f46:922" file="f46" line="922" extern="1"
attributes="__stdcall__">
<Argument type="_159"/>
<Argument type="_159"/>
<Argument type="_11304"/>
<Argument type="_10536"/>
<Argument type="_11304"/>
<Argument type="_10536"/>
</Function>
...
<Constructor id="_20316" name="_ACCESS_DENIED_OBJECT_ACE" artificial="1"
throw="" context="_11132" mangled="_ZN25_ACCESS_DENIED_OBJECT_ACEC1Ev
*INTERNAL* " location="f21:3709" file="f21" line="3709"/>
<Field id="_20317" name="Header" type="_11157" context="_11136"
mangled="_ZN26_ACCESS_ALLOWED_OBJECT_ACE6HeaderE" location="f21:3701"
file="f21" line="3701"/>
<Field id="_20318" name="Mask" type="_11196" context="_11136"
mangled="_ZN26_ACCESS_ALLOWED_OBJECT_ACE4MaskE" location="f21:3702"
file="f21" line="3702"/>
<Field id="_20319" name="Flags" type="_11433" context="_11136"
mangled="_ZN26_ACCESS_ALLOWED_OBJECT_ACE5FlagsE" location="f21:3703"
file="f21" line="3703"/>
<Field id="_20320" name="ObjectType" type="_11225" context="_11136"
mangled="_ZN26_ACCESS_ALLOWED_OBJECT_ACE10ObjectTypeE" location="f21:3704"
file="f21" line="3704"/>
<Field id="_20321" name="InheritedObjectType" type="_11225"
context="_11136"
mangled="_ZN26_ACCESS_ALLOWED_OBJECT_ACE19InheritedObjectTypeE"
location="f21:3705" file="f21" line="3705"/>
<Field id="_20322" name="SidStart" type="_11433" context="_11136"
mangled="_ZN26_ACCESS_ALLOWED_OBJECT_ACE8SidStartE" location="f21:3706"
file="f21" line="3706"/>
--
Regards
Alex McDonald
Randall Hyde
it would be safe for me to say that I disagree with the gccxml documentation
that claims that the output would be easy to parse. No doubt if you need an
entire C++ program parsed and placed in some easy to manipulate form,
this might be the way to go (certainly I've seen lots of people recommend
this
program to people who wanted to write a C++ parser). OTOH, I don't feel
that this XML format would be particularly easy to process by individual
programs
converting the intermediate (canonical) form to a specific assembler. I feel
we
can produce something much simpler than this (and, therefore, make it much
easier to write the translators for each of the assemblers - an important
goal
as we'll need a lot of these translator programs).
Cheers,
Randy Hyde
Alex McDonald
> Well, based on the output both Alex and Frank provided, I think
> it would be safe for me to say that I disagree with the gccxml
documentation
> that claims that the output would be easy to parse. No doubt if you need
an
> entire C++ program parsed and placed in some easy to manipulate form,
> this might be the way to go (certainly I've seen lots of people recommend
> this
> program to people who wanted to write a C++ parser).
Generally, because it's using gcc; it's widely acknowledged as a pretty
thorough (and free) C++ compiler, and because the backends are replaceable.
> OTOH, I don't feel
> that this XML format would be particularly easy to process by individual
> programs
> converting the intermediate (canonical) form to a specific assembler. I
feel
> we
> can produce something much simpler than this (and, therefore, make it much
> easier to write the translators for each of the assemblers - an important
> goal
> as we'll need a lot of these translator programs).
> Cheers,
> Randy Hyde
>
>
Agreed; the <namespace> is a complete mystery to me.
OK, how about SWIG (http://www.swig.org/); there's an XML backend for this
including the usual Perl, Python etc. It looks to be widely used to build
interfaces; I believe the wxPython wxWidgets interface was built with SWIG.
[OT: wxWidgets was called wxWindows until MS complained; "we own all your
windows".] I have not tried this myself as gccxml meets my needs; I only
need to name functions & count the # of parms from fairly std header files.
--
Regards
Alex McDonald
Svend Mortenson Jr.
Beth
> > Hello Beth.
Hi Svend!
How's that 3D graphics "hat" thing and the fractals coming along? Or
are you doing other stuff now? :)
Beth :)
Svend Mortenson Jr.
how to call the library's i need.
Beth
> They are fine and done. I haven't done any more as i can't figure
out
> how to call the library's i need.
Which library? Because someone somewhere's going to know the answer to
that one, right?
Beth :)
Svend Mortenson Jr.
block of graphic's. rnd function is another i need.
I just can't figure out the stuff that you all help me out with in
mandelbrot and 3-dim.
Svend