Re: HLA suggestions

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 11/07/03 

Date: Fri, 7 Nov 2003 05:20:26 -0000

Randy wrote:
> Beth wrote:
> > I don't have MSVC++ but does it use - or could it be coaxed to
use - a
> > similar system perhaps? Because, as above with Borland C++ and
TASM,
> > there's really got to be some way for HLLs like C++ to be able to
> > insert the source line information into the output, even when you
> > select the "compile to ASM" option...it's worth a look,
> > anyway...compile some VC++ code to ASM with debugging stuff fully
> > enabled and see if it takes a similar approach to Borland C++ /
TASM
> > in having a bunch of (undocumented) directives which are
specifically
> > for adding debugging information in ASM files...
>
> I've never seen anything like this. Then again, I haven't looked
real hard, either.

Then, if you're interested, you should look hard as I can assure you
that it certainly exists for Borland C++ and TASM (because if I'm
looking at the output of the Borland compiler, I always have to
remember to temporarily switch the debugging information off...as,
otherwise, it spits out pages of "?debug" directives and so forth,
which totally gets in the way of reading it properly :)...

Just try "compile to assembler" with Borland C++ (and debugging output
switched on, obviously ;) and then look at the output...it has a
number of these "?debug" directives...I don't know if they are
documented anywhere specifically by Borland but for the basic "source
level" stuff, it seems pretty easy...there's a "?debug S" directive
with the filename of the source file after it (so I guess "S" means
"source", right? :) at the top of the file...and then "?debug L"
followed by the line number elsewhere in the file at the appropriate
places to signal the start of each source line...there are other
directives at the end "?debug D" which seem to include the names of
include files...

And, yes, these directives must be making the assembler create the
right debugging information because I'm compiling to an ASM file and
then can manually stick that ASM file - so I know it's not getting the
information from anywhere else - into TASM and it'll have the correct
source-level stuff for Turbo Debugger to follow along with the source
code...

Hence, certainly for TASM output, you could exploit these debugging
directives used by C++ (and presumably by any HLL - like Pascal - that
needs the source level stuff and can produce ASM output :) for HLA in
order to provide source level debugging...just spit out '?debug S
"filename"' at the top and "?debug L linenumber" throughout the output
and, though you'll have to check exactly how these directives might
work to ensure there are no "nasty surprises", this should provide HLA
source-level debugging...

I don't have MSVC++ to check out if it also has a similar mechanism
for "embellishing" ASM source with debugging directives...but it might
just do...although, MS have started to prefer the idea of putting
debugging information into its own separate file and might employ this
different method instead...or is the separate file debugging thing
merely an optional feature and you can still order it to put the
debugging information directly into the PE file? As I say, when it
comes to MSVC++, things are second-hand knowledge from reading posts
and websites...I don't have MSVC++ and I ain't paying MS's
extortionate prices...

Also, regards GAS, then I'm thinking that, from an implementation
point of view, there basically _has to_ be something like this
included to allow GCC to pass debugging information for GDB via the
various GAS "backends"...if you think about it, if it's effectively
going GCC -> GAS -> GDB then there must be some sort of a way to
"pepper" the GCC's ASM output that's fed into GAS for it to put
debugging information that GDB can read into that file...

This is why I mention it because I _KNOW_ that Borland C++ uses this
mechanism to get TASM to include C++ source level debugging
information...and, thinking it over, this type of implementation is
likely to be employed elsewhere too...I mean, if GCC just spits out
ASM output and then feeds just that output to GAS, then it has to be
"peppered" with information like this somehow or how else would the
final executable have the debugging information inside it for GDB or
whatever to pick up? Well, I don't know...I only know _TASM_ does this
for sure...it'll be an interesting experiment to see if the others do
something like this too, though :)

> > > OTOH, symbolic debugging info is planned for HLA v2.0.
> > > However, HLA v2.0 is quickly becoming the king of vaporware
> > > as I keep getting involved in book projects :-(.
> >
> > Oh dear :(
>
> Well, it's not that bad. I just woke up one day and realized that
the
> whole reason for creating HLA was to allow me to write books on
> assembly language programming; I wasn't writing books to support
> HLA (despite what Rene might think). To me, writing the books is
> more important than extending HLA in a dozen different ways.
> As HLA v1.x *is* suitable for most real projects, despite the fact
> that it's a compiler rather than a "true assembler", I can take some
> time off from HLA development and work on the projects for which
> HLA was created in the first place. After all, HLA is a means, not
> the end.

Like Knuth and his "digression" of coming up with TeX because, while
writing his computer books, he discovered that typography software
wasn't quite up to the standards he expected and so decided to come up
with software to drag them up to those standards? Except, in your
case, at least HLA is more closely related to the actual _content_ og
texts because it's there to support them...while, on the other hand,
Knuth's TeX was only really so that he could actually _write_ the
books in a comfortable manner and not because it would itself serves
as an example or support tool or anything for the content of the
books...

> I'm sure that HLA v2.0 development will get started up again, big
> time, once I finish my next two or three book projects (WPA,
> WGC, and "Universal Guide to Assembly").

Cool :)

> > Nevertheless, to the actual point I wanted to make...with the
> > "include" directory, you should include the "stdlib" include files
in
> > that directory "as is"...but that there could be "Win32" and
"Linux"
> > directories inside "include", which contain the OS-specific
> > stuff...this is a "neatness" thing and keeps them clearly
> > separate...but also serves to easily make the difference between
which
> > include files are "OS neutral" and which aren't...because to
include
> > the "stdlib.hhf", you'd just use '#includeOnce("stdlib.hhf")', as
per
> > normal...but including '#includeOnce("win32\w.hhf")' means you
have to
> > type out the "specificness" of "Win32" or "Linux"...so there's no
> > chance of people confusing up their "specific" and "generic"
include
> > files..."portability" in the ASM world is a somewhat unique
novelty
> > that making the distinction clear and _how_ "stdlib" manages to be
> > portable where the Windows include file isn't and all that sort of
> > thing is probably something to at least make crystal clear to
> > beginners...
>
> AFAIK, the w.hhf header file is *not* automatically included
> in stdlib.hhf (primarily because its compilation takes two seconds,
> a price most people don't need to pay unless they are working on
> GUI projects). The Linux include file is about a second.
> So unless I misunderstand you, the current header file scheme
> already does what you ask (i.e., forces you to put specific includes
> for Windows or Linux specific files).

Ah, well...not quite...what I was actually talking about was just the
structure of the directories on the disk...one of those "trivial"
details which can actually make a difference, I reckon...graphically
(as that'll immediately avoid the confusion a textual description
seems to be causing...fixed pitch font, of course, as demanded by all
the best - and worst - ASCII diagrams):

HLA
 |
 +--- Include
       |
       +--- Win32
       |
       +--- Linux
       |
       +--- BSD
       |
       +--- (X Windows, perhaps, as it's "cross-platform"
       | itself so doesn't come specifically under any
       | other one OS platform?)
       |
       +--- etc., etc., etc.

Now, the stuff that can be used regardless of OS goes in the
"/HLA/Include/" directory(either because it's just straight x86 code -
like, say, some string manipulation that only uses CPU instructions
and no API at all - so is applicable to all...or it's part of the
"stdlib" and is "OS neutral" and has been _made_ applicable to all by
using the same interface but there's a different library file in the
"/HLA/Lib" directory for each OS, so as to "smooth over" the OS
differences in a "transparent" way :)...then, for each supported OS,
there's a directory where the "OS specific" include files go...

"What's the point in all of this?", you might say...well, basically,
it's a small organisational detail, granted, but I think that it would
naturally make things clear as crystal because the actual location of
the files tells you stuff about it...so, for example, "stdlib.hhf"
goes in "/HLA/Include" but "Kernel32.hhf" would go in
"/HLA/Include/Win32" and "Linux.hhf" would go in
"/HLA/Include/Linux"...

Note the various small but useful things that this scheme allows;
First, you can immediately tell whether an include file is "OS
neutral" or "OS specific" at a glance from its location...second, to
include the "OS specific" files, you have to actually _physically_
type out the name of the OS into the "#include" statement (like
'#include("win32\Kernel32.hhf" or '#includeOnce("Linux\X11.hhf")' or
whatever ;)...these two are useful because they not only make
everything clear but having the repeated physical act of typing
"Win32\Kernel32.hhf" each and every time will automatically get it
straight in someone's brain that "Kernel32.hhf" is for Windows...a
case of "muscle memory", if you like...writing what is what in
documentation does not automatically "engrain" things into people's
brains as actually _doing_ will do quite naturally without any extra
effort but laying out the directories in a logical way..."muscle
memory" tends to learn faster and once it learns something, it simply
never forgets...that's basically why though you might "know" something
from reading, you only really _learn_ something by actually _doing_
(everyone must know this one...where you _read_ some sentence over and
over about, say, "please do not park here" or "always look left before
proceeding"...and, yup, _intellectually_ we completely understand what
we're being told...but, well, ummm, just go ahead and NOT do it
regardless...there's no actual _physical_ connection between one and
the other...on the other hand, if you park your car in the wrong place
and another car comes tearing around the corner and knocks off your
tail-light (UK: rear indicator) then there's _absolutely no way_
you're going to ignore the wisdom of that sign anymore, is there
(which, of course, was the original purpose of the sign...nope, not
just to "spoil your fun" but to actually advise you where it's a
really bad idea to park, due to the tendency of other cars to come
racing around the corner without looking ;)? You've truly _learnt_ the
lesson and are not parking there because you _know_ - you've
_learnt_ - that the sign is there in your interests from actual
experience...while "intellectually", you may understand the words on
the sign and all that stuff, the connection is never made and you've
never truly "learnt" what it means...it's a strange facet of the human
mind, indeed, but it's there...which is why the best teachers
automatically try to slip in some sort of "doing" action into the
learning process that no-one'll necessarily notice...for example,
learning your alphabet or your multiplication tables by simply saying
them over and over...thereafter - probably until the day you die -
you'll very rarely not be able to comprehend alphabetic order or jump
straight out with the answer when asked what "7 eights" are...these
things, as boring as it can be, usually get taught by simply repeating
them over and over until they stick in your head because they are so
_fundamental_ that you don't just want to "intellectually appreciate"
them but want them "hard-coded" or "hard-wired" into your "muscle
memory" permanently and requiring absolutely no brain power whatsoever
to pull them back out of your brain at the required times...and, even
better, you can actually completely learn things without also
expending a single brain cell on the task just by constantly repeating
something over and over...so when you type "win32" before the include
file name - combined with your "intellectual appreciation" that a
different directory means a different OS of the same name - then, hey
presto, something as "minor" and "trivial" as directory organisation
_DOES_ make a difference towards the learning process...

And, of course, it was you yourself who (rightly) stressed to Rene
that it's in these "minor details and embellishments" that a product
crosses over from "simply working" to a "professional package"...to
use the analogy, when you see a pop star in a magazine with that hat
"just tipped so" or how that model is standing - the way they are
"holding" themselves - or whatever...well, the difference between
"amateur" and "professional" is that the professionals leave
absolutely _nothing_ you see in that picture to chance...not a single
thing...yup, even the things that look "natural" in the photo have
been _pre-planned_ to "look natural" and "spontaneous" (such as the
hat that's tipped over slightly, giving the impression that it's been
thrown on quite naturally at an odd angle but, in fact, it was moved
with precision into place to exactly _look_ like it was thrown on but
was carefully selected and entirely _planned_...for pop stars and
models and such, there is NO "natural" and "spontaneous" in their
wardrobe...the whole thing has been pre-planned by their personal
fashion consultants...yup, even those "hip hop" stars who appear to be
wearing "street" stuff have specifically pulled it off a rack of brand
new clothes as per the order of their fashion consultant...and,
basically, to be "professional" and not look silly next to all the
other pop stars, you _have to_ be this pedantic about things...ever
seen a well-dressed celebrity standing next to an ordinary Joe or
Joanna when they've been fully kitted out by their fashion consultants
and so forth? You can _tell the difference_ immediately and
obviously...and that's all down to "professional pedanticism" where NO
detail is considered too small...to be properly "professional",
basically, you have to be, yes, obsessively pedantic to an absurd
level at times...if you find this attitude "silly" and can't see what
all the fuss is about, then that's _exactly_ the thing that divides
"interested amateur" and "the professionals" in a nutshell ;)...the
make-up on their face has delibrately been selected to work with the
lighting to avoid even the smallest shiney reflection off their nose
or whatever (which is why even men are forced to wear make-up in such
situations because only by using make-up can the "professionals"
totally control every aspect of a photograph :)...

Third - because I actually hadn't finished that list started earlier -
this scheme also allows for those who want to develop across multiple
platforms to have all the files together for whatever OS...yes, though
you'd normally download just the Windows or Linux version - as you've
already began to account for - there's a use to also have it that you
can download all the files for all platforms...one idea, for instance,
might be to put HLA onto a CD - including the files for all platforms
together - and then you can change your development environment by
simply moving the CD onto a different machine...this is an
_especially_ useful scheme, for example, for making work on the
proposed "OS neutral GUI interface"...everything is neatly divided and
files for multiple platforms can all be housed together without
conflicting and so on and so forth...

Fourth, though this might resisted for other reasons, this means that
you can re-use filenames...so, for example, you could have a different
"kernel.hhf" in each OS directory that relates to the different
kernels of each OS...this is okay, of course, because filenames only
need to be unique _within_ a directory and it's "full name", if you
like, is actually "/include/Linux/Kernel.hhf" or
"/include/FreeBSD/Kernel.hhf" or whatever...

Fifth, there's a distinct possibility that something could actually be
available for multiple platforms...as the perfect example, "X Windows"
may be implemented for any platform (something that would need to be
dealt with for any future "OS neutral GUI library" :)...thus, where it
corresponds between platforms, the files can be housed in their own
"X11" folder which all the various platforms that have X11 can
_share_...anything that's "OS specific", of course, goes into the
specific OS folders...

Sixth, it's simply neat, logical and has a whole bunch of useful
benefits...and, as you may have guessed from my suggestion about the
"OS neutral GUI" routines then this suggestion is not just "fanciful"
particularly but is inspired by thinking through the requirements and
useful ways of trying to attempt such a library and have a more
formalised way of making the distinction between "neutral", "specific"
and "shared" I reckon _WILL_ be paid back in actual practice...as well
as also naturally offering these benefits for other HLA users :)

> > Actually, in this vein, if you're going to have specific Windows
> > header files for the "Windows programming in ASM" book thingy
you're
> > working on, then have "stdlib" use those Windows header files
> > directly...you know, layer one on top of the other because then
the
> > library source code makes perfectly clear to everyone looking over
it
> > how the "portability" thing is actually working...the whole
> > "indirection" thing of passing it through a "layer" with a uniform
> > interface, where the "nitty-gritty" goes on in a very "specific"
way
> > underneath the hood...
>
> WPA has its own header files because I've extended the API
> interface quite a bit for WPA. The w.hhf header file tries to
> stick to just the Windows stuff.

Well, actually, I was only suggesting the "layering" thing as a
"preparation" for the ultimate goal of converting the "stdlib" to also
include "OS neutral" GUI routines...but, as you suggest later on that
you might be tackling this stuff directly, then this "intermediate"
step isn't so important...I was suggesting the above, actually, just
so that creating the "OS netural" GUI routines would be easier...you
know, trying to get you to structure HLA in a way that's conducive for
these routines to simply be "slotted in" once eventually written...but
if you'll, at some point, be dealing directly with this stuff
yourself, then it's a redundent suggestion...that is, you'll soon
enough come to these issues yourself and can appreciate them
first-hand that I needn't "coax" things in quite the same way at that
point and could just point you directly to an example of why I think
it would be more useful to structure it a different way to help the
"OS neutral" GUI stuff seamlessly into the HLA package...

> > Therefore, it should be made crystal clear _how_ the standard
library
> > achieves its "portability" so that beginners can understand this
to
> > not just manipulate it and choose the right header files but to
also
> > copy the method to make their own "portability libraries" and so
forth
> > too...yes, it's an incredibly easy thing to comprehend and do, in
> > fact...but no HLL ever makes it clear how it does
"portability"...so,
> > even though it's easy and actually "obvious" once appreciated,
it's
> > this _basic appreciation_ - due to no education in the matter -
that
> > is so often missing...it repeatedly is always referred to in
"sacred
> > tones" as if C was "portable" by the "magic" of some "god of the
HLLs"
> > in return for "holy worship" or something...this sort of attitude
is a
> > denial of education and, thus, a denial of freedom, to my
> > mind...hence, as you may expect, I loathe such conduct with a
> > passion...HLA does already "expose" it but it wouldn't hurt, I
reckon,
> > to make it blatantly obvious with a little explanation of how it
works
> > thrown in...better to feel perhaps slightly patronised (though
some
> > won't be because they really didn't know and never worked it out
for
> > themselves ;) than to be caged by enforced ignorance...teaching
ASM
> > itself does this for the CPU...but it also covers OS stuff and
other
> > low-level things so there is a place to also inform about things
like
> > this...in a sense, as you work from HLLs down to ASM, then it
would
> > also be good to include _how_ the "levels" relate to one
> > another..._how_ this "low-level" ends up being "magic HLL
portability"
> > and that sort of thing...fill in all the gaps in between, to
inform,
> > to educate, to provide freedom and choice :)...
>
> Well, as long as the source code is there, they can always check out
> how it's done themselves. Perhaps an article would be cool at some
> point or another, but this isn't exactly the type of material that a
beginner
> can appreciate. To the beginners, the best you can do is warn them
that
> "this is a specific library package, it's not assembly language per
se; don't
> expect to be able to use these calls in every environment you might
find
> yourself working in."

Ah, granted...but, in a sense, I was specifically thinking about
laying it out so that though a beginner need not immediately jump into
dealing with these things, it shouldn't really get in their way at
all...and when a time comes that they're moving from "beginner" to
"intermediate" or "advanced" and might be interested in such things,
then there's no "jump" involved...though, sometimes, it's true that
"beginner" and "advanced" topics can be conflicting, sometimes it's
possible to structure in just such a way that support for one doesn't
necessarily get in the way of the other...and, where that's possible,
this should be preferred not just to support both audiences but also
for the "smooth transition" of a user from "beginner" to "advanced"
without any odd "jumps" involved...that the "advanced" topics are
simply a case of actually _looking_ into the details of the thing that
you just accepted beforehand...so, for example, as a "beginner", you
just "accept" that the standard library is "portable" and just use
it...ignoring the particulars of how this is achieved...

But, when you have been using HLA for a while, then you pull down that
"advanced" article about how it actually works and then actually, this
time, _look_ into how the "stdlib" is structured and works to
appreciate this more "advanced" topic...note that the experience as a
"beginner" _using_ the library actually conspires to make this
potentially easier for users making the "transition" to understand
perhaps more than an "advanced" person walking straight up to this
immediately...

This is, actually, all the same "gradual transition" stuff you're
already doing for "beginners" but I'm just applying the ideas more
generally and even further to when HLA is not just a "learning tool"
but also their assembler of choice for "advanced" things too...so,
yeah, the stuff I'm mentioning here should be lower priority than the
"beginner" stuff you're doing this primarily for...but, well, I'm
chipping in my slightly unique perspective as one of the few coming at
HLA not as a "learning tool" but as an assembly language in
itself...because, as time goes on, more "advanced" people may come to
accept HLA...and, even if they don't, then there's the issue of HLA
finally succeeding to turn a "beginner" into an "advanced"
coder...well, where do they go from there? Moving over to other
assemblers is one possibility and that should be just fine as a path
for people to follow...but, also, it'll be great to simply furnish
HLA - as you have done in large part - so that they could simply carry
on using HLA, if that's what they want to do (this talk may upset Rene
a bit but, well, we've said the words "HLA" on alt.lang.asm, which
upsets him, anyway...hence, "in for a penny, in for a pound"...you
can't not upset Rene by mentioning HLA so it's actually, therefore,
kinder to get it all out in one go so as to make his "pain" at least
short and merciful ;)...

> On a different note, I've been giving some serious thought to a
project
> you proposed about a year or two ago -- creating a portable set of
> GUI library routines.

It's not a bad idea, is it? This also would grant HLA a capability
that even some HLLs don't come close to providing...and, boy, does it
knock a massive hole straight through the "ASM is non-portable" myths
when HLA starts to "out-portable" many HLLs...plus, if you're serious
about "DOS is dead" then, well, we also have to accept that for the
majority of modern applications, the command line is "dying"
too..."console" applications _still_ make the best learning
environment because the event-driven model is an entire topic in
itself...so, what with "gradual nicotine patch" teaching philosophy,
you work your way up to this, dealing with one topic at a time :)...

There's also a "niche" here that HLA could tackle where there's
nothing particularly comparable...yes, there are "OS neutral" GUI
libraries but none with a fundamentally "low-level" edge to them for
assembly coding specifically...and, inherently, "portable" does often
compromise "performance" (because "portability" is always achieved by
"layering" and each layer "gets in the way" of perfect optimal
performance :)...so, HLA supporting this stuff actually provides the
ability for tailor-made _compromise_ solutions...that the assembly
stuff can help to win back some "performance" that could be lost to
"portability" without necessarily giving up "portability"
completely...

Currently, in a sense, it's _made_ into an "either...or" situation
because, mostly, "low level" means giving up "portability" but gaining
the potential for great "performance"...and "high level" means taking
on "portability" but giving up some "performance"...

But, as you know, I not only don't see it as being quite so "black and
white", I'd say that we're all "missing a trick" to staunchly insist
on these two "camps" and both give up on the "compromise" solution
that _can_ work to be "portable" without much sacrifice of
"performance"...although, the real "magic", I think, in an assembly
language coming at this issue is that it can apply the fundamental
thing that makes assembly language the excellent thing it is:
Liberty...

That is, generally speaking, ASM only provides a "give up on notions
of portability completely" attitude...and then HLLs tend to say
"here's some portability but you _must_ use the MFC or VCL exactly as
directed or it won't work"...like I say, the whole idea of "compromise
solutions" are not really catered for at all...

And here HLA, in my view, could step in with a simple but clever way
to approach things...include the Windows and Linux and X Windows
header files for directly manipulating in a totally "low-level" way
(just like the "unit" programs I've been posting...using HLA in a
"real assembly"-like way :)...and then, on top of that, build in
support for simple cross-platform GUI stuff...layering up the support
BUT making sure that all of it can happily live together and be "mixed
and matched" at will...

Of course, "my" paradigm is influencing this but it's conveniently
conducive to most other paradigms...if you're into "real assembly" and
using API directly then, sure, that's _fully_ supported...if you want
to use some "stdlib" portability interface then, sure, that's _fully_
supported too...and, where "my" paradigm enters the scene, there's a
"third way" available here too, that would be hard to approach in any
other way...you could start out by writing a "stdlib" HLA program with
GUI controls and so forth...get it up and running in a "HLL"-like
way...the program is working then and, if you like, you can stop here
and release your program...BUT, we can go further here and wherever
we've used the "stdlib" we can one-by-one, little-by-little recode
each of those functions in a more "specific" way...trading our
"portability" back into "performance" on an entirely selective
basis...depending on how far you want to go, you can carry on
re-coding and getting more and more "specific" as you go until, yeah,
in the end, you can have a 100% "performance"-orientated program...all
clever "optimal" ASM sequences, stack frames kicked out and so on and
so forth...BUT it is "portable" in the sense that it's been worked
from an original "stdlib" implementation that does work across
multiple OS platforms...

The basic point here being that we're actually NOT talking about
anything particularly "mutually exclusive"..._BOTH_ can be catered for
with equal levels of support and it can also be made to have a perfect
"gradual nicotine patch" transition to it too...thus, HLA provides a
_complete_ "multi-level" solution...thinking, say, another "version"
or two ahead, the GUI library support can also form a foundation for a
Delphi-like "visual" element too...so the beginner can literally start
here by dragging and dropping components...then they can learn about
the ASM and "stdlib" code behind that...then they can learn about how
the "stdlib" code itself works...then they can learn about Windows API
and X Windows API...then they can learn about using ASM for really
"cutting-edge" performance, in the whole "real assembly" style...

And then HLA would represent probably the first _complete_ solution
from "complete beginner" to "insane optimisation guru" in _one tool_
and following a "gradual nicotine patch" process throughout...and,
yup, a person can bail out at any particular point that they like or
take it right down "to the wire"...and that it can support practically
_ANY_ "compromise" in between "VB coder" and "hex coder" you could
think up ;)...

A bold, ambitious and, yes, very cheeky "dream"...but all the best
ones are, aren't they? ;)

> Before too much longer, I'm going to clean up
> HLA and port it to BSD and probably QNX (there are some legal
> issues with the QNX port having to do with the standard library
> stuff that I've got to overcome).

"Legal issues"? Now, that's an intriguing statement...what's the
problem there specifically?

> When I'm doing this, I'd like to create
> a set of library routines that let assembly programmers create
portable
> GUI apps. If you're still interested in such a thing, I can assure
you that
> I'll need a lot of help.

Totally; In fact, I never actually gave up on the idea whatsoever,
really...I've always been mulling over how to approach it and stuff in
the odd spare five minutes when not doing anything else...

In fact, I'd already contemplated starting on some HLA X Windows
header files but it was shortly after deciding this that my second
machine - the "Linux box" - stopped functioning...I thought "I'll just
upgrade my Linux to the latest version before starting properly so
that I'm working from all up-to-date stuff" and then stuck in an extra
hard drive (it now has _three_ of them...but, well, I put this machine
together from "spare parts" so none of them are particularly large, as
they are old "spare parts" that would otherwise go to waste...I
basically just employ a simple "recycling" scheme with this whole
"second machine" idea...when this current machine gets replaced then,
yup, this "first machine" becomes my "second machine" and I
"cannibalise" any "spare parts" lying around and stuff it into that
machine :)...

But, oh dear, something somewhere in the box has been attached wrongly
or the installation CDs for the latest Linux were written wrongly or
something because it just crashes half-way through trying to install
the OS...of course, with a lot of playing around, it'll be possible to
eventually "coax" it into a working state...but, well, as I say, this
is a "second machine" and a "spare time" project that it just hasn't
been "prioritised" sufficiently...that is, the second I hit this
problem, it was like: "oh...ah well...I can do this later or something
instead" and went back to the "first machine" and my "main"
projects...but, yeah, it's about time I really did sort out that
"second machine" of mine because it's just sitting looking Hopeful
here - with the side panel hanging off because I'm having to change
things around inside it all the time that it's not even worth putting
the panel back on ;) - but not actually doing anything because it's
"OSless" at the moment...for anyone that has the space (or could make
the space) and they like to play around with OS development or
multiple OSes or whatever, then I have to recommend this "second
machine" idea...not least because it's also a good way of "recycling"
old parts and keeping them useful which is "sort of" environmentally
friendly, in a sense...well, more environmentally friendly that
dumping the whole lot in a landfill when it can still perform useful
functions...plus, even for only Windows development, the "second
machine" can have a minimal copy of, say, Windows 98 stuck onto it and
you can test Win9x and WinNT based Windows to see that it really does
work happily on both...and so on and so forth...it shouldn't really
have to be said but in this "disposal culture" of ours, it might not
strike people how useful it can be to even keep around things are that
are, yes, admittedly "crap"...because, you see, at the very least, two
machines means that you can play a game of Solitare on one machine
while the other one is thrashing away its hard drive compiling
something...or you can put your MP3 tunes coming out of one machine
that won't effect the performance of the other machine whatsoever so
it can still churn out 100% CPU devotion to your ray-tracing, video
editing or whatever without needing to lose the time-wasting pleasure
of listening to your favourite tracks...

Anyway, the "advert" for a "two machine solution" over, I'd actually
specifically had things set-up ready to start working on something
like this with HLA...but then the second box just gave up working...in
a sense, I "took the hint from the higher powers" and shelved the idea
(perhaps, indeed, I was prevented from proceeding specifically because
"the higher powers" knew you'd want to take up this idea, if you
believe in any sort of "no accidents" view of the universe...well, one
way to way out, I'll try to re-install that Linux on the second
machine and if it suddenly works in an inexplicable way, we can
harbour deep suspicions about "coincidences" and "accidents" in the
universe, eh? ;)...

Anyway, yeah, I'm interested in that idea (why I mentioned it in the
first place, of course :)...and I'll happily lend a hand...although,
it's fair to warn that, being a "scatterbrain" at times, I often
require things like a stream of "so, where is it?" Emails and that
sort of thing to remind me and keep me "on track"...single-line
pestering will work well, as guilt will do the rest...this is the
"down side" to my continual "wandering dreamer" thing...it works well
in thinking up ideas like "OS neutral" GUI libraries but then works
against me when it comes to actually getting down to doing things
because, well, as I start doing one thing, I come up with some other
"great idea" about something completely different...then, as I work on
that, I think up something even more radical and extreme that I just
have to do instead...and then again...and again...everything has its
benefits and drawbacks, I suppose, and this is the drawback part of an
"alien brain"...it tends to prefer living somewhere just past Jupiter
which might be great for thinking things up but is less practical when
it comes to doing things on the ground...but with someone else
dropping the odd "pestering" Email, that'll keep me grounded, most
probably, to actually be useful, perhaps ;)...

But, sure, I'll help out there...in fact, some of the "suggestions"
I've been making are inspired by "experiments" towards that end and
the "issues" that were getting in the way with HLA at the moment...the
"OS folders" idea mentioned above, for instance, is inspired by
contemplating how to put all the different OS and GUI header files
together for doing this sort of thing (for convenience, being able to
house them all together could come in handy for the actual
cross-development itself :) and considering whether "X Windows" should
have its own folder (as if it were its own "OS" and not just a GUI
layer on top :), as it can be "shared" across all the different
platforms that X is available for...and so on and so forth...

[ Oh, one other minor thing...I might be going on vacation soon that
there may be some "radio silence" for a week or two...although,
probably, that'll be over and done with by the appropriate time, it's
best to mention it before people think I got hit by a bus or something
like that... ]

Beth :)

Quantcast