Re: HLA v2.x and / or LASM suggestion: Win32 Resources
From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 01/06/04
- Next message: Beth: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Previous message: Randall Hyde: "Re: help a newbie"
- In reply to: Betov: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Next in thread: The Half A Wannabee: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Reply: The Half A Wannabee: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 6 Jan 2004 04:26:46 -0000
Betov wrote:
> Beth wrote:
> > Here's an interesting suggestion for an addition [...]
>
> 1) I am a bit estonished of you saying "LASM"... Why LASM? Is this
one
> of interrest? I just took a look at the page again, and i see this
is
> some MASM Legacy clone... Commercial thingie (two utterly demential
> points, so that i did not even gave it a try).
Oh, this is a simple confusion here, Rene...
The "LASM" I'm talking about is Mozzie's "eductional assembler" he's
working on...I _DON'T_ mean the commercial project, which happens to
be called "LASM" too (I didn't realise the name was taken by another
project actually or I'd have made it clear that I meant _Mozzie's_
"LASM" he's still writing...probably Mozzie is unaware of that
too...but, then again, practically all "letter of the alphabet + ASM"
names have been taken somewhere ;)...
We've got the same "name conflict" problem as people using "Table
Assembler" probably always get when people are actually talking about
"Turbo Assembler" when they say "TASM"...I didn't mean whatever
program you've found on the internet...the "LASM" I meant - Mozzie's -
isn't even on the internet yet, as far as I know, because he's still
working on it...
Anyway, I'm happy to encourage Mozzie with his little "experiment" in
writing an assembler and he has _asked_ a few times for
suggestions...so, when I had this mad idea, I thought I'd pass on the
suggestion...
> 2) Generally speacking, your proposition of having Resources in the
> Source, is exactely what FASM does, and it does it pretty well, in
> a neat and intelligent manner. Does it do it for Icons? I don't
know,
> but i suppose yes, as far as you write the required Macro for having
> this with some easy typing.
Oh, well..."great minds think alike", as the saying goes...
I'm NOT trying to detract from whatever great stuff FASM does...as you
might remember, it took me ages and ages just to get around to
downloading FASM...I have finally downloaded it but I confess that
I've done next to nothing with it to actually know much about it...
I was simply unaware that FASM already has something like this in it
already...I was not trying to suggest that FASM's method is "no good"
or anything silly like that by not mentioning FASM...I just didn't
know that it did this already...
But, if it does, then all we have here is a case of "independent
discovery", so to speak...
> 3) I am not sure to understand: Do you mean to talk of Resources,
and
> take Icons as an example, or do you really mean to talk of Icons
only?
> If yes, ... who cares how the Icons are implemented? In the next
step,
> are you going to write your DLLs .reloc section by hand? :))
Well, "icons" was just the example (and the current thing I was
working on that made me think of it :)...but the same idea should work
with all resources (or, at least, all common resources and the rest
can be "DB" :)...
[ By the way, you just asked an "or" question and then put "if yes" in
the next sentence..."A or B" questions are not usually "yes or no"
questions, unless obviously A is "yes" and B is "no"...anyway, I won't
play the language pedant but it does make what you're trying to say
exactly a bit ambiguous :) ]
As for "are you going to write your DLLs .reloc section by hand?"
then, no, I'm not planning to...BUT if there was a good to do so, then
I would do so...
But I don't find this to be comparable...what I'm talking about is
using the _assembler_ more rather than less...writing the ".reloc"
manually would be taking _away_ from the assembler something it can do
infinitely faster and more reliably...on the hand, separating things
out into some separate "RC" compiler makes the assembler do _less_,
not more...if you are using resources, then - on assemblers other than
yours, that is, of course...because, as I said, you deal with problem
in a completely different way - you'd be running the "RC" compiler
thingy, anyway...the sole difference here is to include "RC" _inside_
the assembler (as you're telling me now that FASM has already decided
to do :) and then the resources can be included directly into source
code...if someone wants to "separate out" their resources, per
Microsoft advice for "easy editing and internationalisation", then
this still perfectly possible by putting that part of the source code
dealing with resources into its own file...when dealing with Linux or
DOS - which don't have this "resource" concept - but that I want
resource-like data for, separated off for easy editing, then this
would be exactly how it would be done, anyway...
> 4) I don't understand a word at what you say with having me refusing
> external Icons and with the relationship you are doing between this
> and the traditional Library concept. RosAsm Icons Editor (though it
> is a dirty little shit very badly written - that requires a complete
> re-write from scratch, obviously-... is nevertheless able to peek
and
> poke Icons from/to Exes, to load/save them from/to .ico Files...
>
> so, i really wonder how having an Icon in DB form in the Source
might
> "violate Rene's "principles". :))
Oh, well...I was just _guessing_ that you might think my idea is "not
real assembly" or something...perhaps I simply second-guessed you
completely wrongly and you simply don't care either way...in which
case, totally ignore what I was saying there...I just thought you'd
say something different and, in fact, you didn't...
> Would you drink as much beer, as i drink wine? :))
Well, that, my friend, all depends on who's paying for this round of
drinks...if I'm expected to pay then it's just a lemonade each (unless
a Russian reading wants to supply the recipe for that infamous
home-made potato vodka which can get anyone drunk for mere pennies
;)...
> 5) About me being a fascist because i reject (an will go on
rejecting)
> the traditional Library concept -as not being compatible with any
form
> of Assembly-, you completely missunderstood my point of view. You
will
> understand better when the "Basic" Pre-Parser will be released... My
> point is that, when a user writes HLL, he has to clearly _know_ that
> he is not writing Assembly (as opposed to the "HLA Standard Library"
> bullshits).
I agree; When using a HLL, there is a great "problem" in "hidden
abstraction"...that is, it's great for easily implementing
"portability" (you don't need to do anything, in fact, your "portable"
HLL takes care of it all for you...or, at least, that's what people
are lead to believe...and _that_ is all part of the problem...it is,
of course, quite possible to write non-portable code even with
supposed "portable" languages...but, thanks to all this HLL
"nannying", will the HLL user _know_ when something they've written
has "portability problems"? And this is a very _real_ problem that
HLLs carry...
And it can be seen in typical HLL code written by someone who only
knows "Delphi Builder C#++ (with added garbage collector)" versus
someone who in some way knows the machine (they could also be
programming in that HLL too but because of having knowledge of _the
machine_ from ASM or even some of the more "low-level" C programming -
but the lower the better that ASM "wins" there - they'll tend to even
produce better HLL code :)...
"Abstraction" - as I keep saying and, one day, I Hope people will
eventually appreciate what I'm getting at here - is a _double-edged_
sword...note, carefully...HLL people may argue "the more abstraction,
the better...it has no problems at all" and I'd disagree with them
just as much as I'd disagree with the reverse extreme opinion you
carry that "have absolutely no abstraction ever in any way, shape or
form"...both opinions, in my view, are missing the essential point...
"Abstraction" is a _double-edged_ sword; One way to describe what
abstraction is might be "abstraction hides details to aid focus"...for
example, rather than consider every single person in a group by their
individual name (which itself is an "abstraction" of their overall
character, anyway ;), I can "abstract" people into a number and
_count_ them instead...so, we could say "3 people" or we could say
"John, Mary and Susan" or we could say "the tall young male with dark
hair who's got a good sense of humour and the two sisters - one
blonde, the other brunette - who otherwise look almost identical but
while the blonde is always serious about everything, the brunette one
likes to share a good joke with John"...all three methods are - in
this imaginary example - describing the exact same people...but they
are different _levels_ and also different _types_ of abstraction (I
emphasise the "different types" as well as different levels because it
is quite possible to "abstract" something in completely different
ways...I could also say about my three people example here that
they've all just been on holiday to Spain or that they all share a
flat in Northampton...or some other _type_ of abstraction...we can
group up things in all manner of different ways...in fact, there's a
potential _infinity_ of different ways to "abstract" - to look at -
things around us...and this has to be emphasised from the perspective
of programming languages which always talk about "levels" of
abstraction but never seem to even acknowledge that there can be
different _types_ of abstraction too...it's all viewed as being in
some magical "hierarchy" of abstraction where every single abstraction
is at its own "level" to distinguish it from all others...well, that's
complete bullcrap as is evident...after all, which is "higher level"?
That my three people example all went to Spain and share a flat or
that two of them have a sense of humour? How do we "rate" this? How
can it be reasonably "un-intertwingled" for everything to fit into
some perfect neat hierarchy? Answer: it _can't_...and the belief that
it can is one of the great _dangers_ of the _ignorant_ use of
abstraction..._exactly_ as I mentioned above about "portability",
abstraction can lead to someone believing it's "impossible" to write
"non-portable" code in C++ because they've been listening to all the
hype and, thanks to the abstraction constantly keeping this knowledge
away from them, there's no reason for them to distrust or disbelieve
that "hype"...they hear the phrase: "C++ is portable" and immediately
think it's a "truth" that cannot ever be false...they are wrong...but,
on the other hand, they have had all the relevent facts for
_understanding_ this "abstracted" away from them...they are ignorant
of the issues and, thus, cannot make a reasonable determination - one
way or the other - on the matter...
Another way to define abstraction, you see, could also be to say that
"abstraction is delibrate ignorance"...you are either temporarily
choosing to be "ignorant" of some of the "minor details" in order to
proceed (the human mind has a limited capacity for dealing with
things...this is, unfortunately, a necessary "tool" that humans must
employ...for example, when compiling statistics, people _are_ simply
turned into numbers...one third do this, one quarter do that,
etc....to do the maths of the statistics, you've got to abstract
people into numbers...and, yes, there's a great benefit to doing
so...though some statistics out there are, indeed, full of crap (and
are just done in order for some statistician somewhere to "justify"
getting paid ;), there's plenty of statistics that tells the human
race _invaluable_ things about itself...plus, one form of "convenient
abstraction" we all use is, of course, _money_...and that's one
particular abstraction I think will make the point to "unbelievers"
that not all abstraction is necessarily automatically full of crap
;))...or, and this is the more sinister aspect that I particularly
don't like about HLLs, someone is choosing _on your behalf_ to make
you "ignorant"...the "oh, don't worry about that! Mr.Compiler will
deal with that complicated stuff...and
Mr.Closed-Source-Standard-Library will handle the other stuff"...and,
oh dear, this is all "closed source" and "under copyright" that if
something goes wrong, if you want to _know_ about the things they are
keeping you "ignorant" of...well, simply, no can do...not
allowed...verboten...
And, totally, from this aspect of things, "abstraction" is often so
full of crap and is, I would happily say, "dangerous" (e.g. people
writing code thinking it's "portable" when, in fact, it contains
something "non-portable" in it that they _can't_ recognise due to the
"enforced ignorance" of their VisualHLL compiler...and when they
"port" the code to some other platform, they _DON'T_ realise that
they've just ported a "non-portable" construct that _WILL_ fail when,
say, some count breaks the 16-bit boundary at 65,5536...something
"rare" enough that it passes the minimal "bug testing" that the
company isn't spending much time or money on because they think: "hey,
it worked on the other platform and all we did is re-compile a
'portable' ANSI language...so, there _CAN'T_ be any 'issues' to
resolve, right? It CAN'T have any 'portability issues' if it's ANSI C,
right?" (in fact, _WRONG_...many would not even blink at this notion
but, in fact, it's perfectly possible to "just" re-compile your
"portable" ANSI C program and then find it totally and utterly blowing
up in your face with not an ounce of even "grace" about the explosion
:))...
But, at the same time, I repeat the emphasis that it's a
_double-edged_ sword...it can bring _good_ as well as _bad_...and
almost always what happens in practice is that you get _BOTH_ "good"
and "bad" together at the same time, the two being quite, quite
inseparable...as you know from using your ".IF" macros in RosAsm, when
you _KNOW_ what's happening - when "abstraction" is _chosen_
ignorance, not enforced ignorance (i.e. you are delibrately _choosing_
to ignore the "minor details" of register allocations and so forth
with a macro in order to _focus_ on some "higher level" algorithm :) -
"abstraction" is a good and useful friend...when it comes to large,
complex programs - especially ones put together by "teams" and not
just individuals - then "abstraction" can very quickly become
_essential_ or things will be difficult and impractical and take an
awful lot longer...
On that point, in fact, people acknowledge that "ASM usually takes
longer than HLLs to develop code"...anyone ever stopped to consider
_why_ that's usually the case? It's all to do with the usual "lack of
abstraction" ASM programs have...note that when you _are_ using a
whole bunch of clever "HLL" macros (and, for the sake of argument,
yes, _YOU_ wrote them yourself, Rene, so you know what's inside them
and all that stuff ;), it's possible to write just as fast or even
potential _faster_ than some HLL..._abstraction_ is the main reason
_why_ ASM is usually slower to develop...the amount to be typed is
usually completely irrelvent...as is the size of the instructions...as
is the fact that you need more instructions to do things in ASM
because, of course, the instructions are simpler so you're often
simply thinking in "multiple instruction" terms inside your head as
you proceed, anyway, just converting to individual instructions (I'm
sure Randy can pull out those statistics about how much time is
usually spent on these tasks in average developments, which confirm
that this stuff is mostly crap...statistics which, by the way, tend to
also confirm that the HLL obsession with "portability this" and
"portability that" actually tends to be a "diminishing return", in
fact...which is why I'm often "unkind" to these "portability"
notions...the stuff _is_ important and useful and all that in plenty
of cases but this "blind worship of the god of portability" is going
too far that you are likely to be biting at your own heels...spending
six weeks making your C++ hierarchy "portable" for no particularly
_practical_ reason at all, when an emphasis on "let's just get the
bloody thing to _work_ first" would have done as equally good a job in
half the time and as "portability" was always a "red herring", anyway,
you are actually losing _nothing_, except, perhaps, "code prettiness"
;)...
I'll say it once more for good measure, as this is the fundamental
point I want to get across: "abstraction" is a _double-edged_
sword...it is "an aid to focus" but it does this by employing
"delibrate ignorance"...ignorance may be "bliss", indeed - and the
human mind is _always_ thinking and doing in "abstractions" (it is
both _how_ intelligence functions _and_ the mind is incapable of doing
things in any other way...yes, it sounds like a "paradox" that I
reckon this is why people often don't realise what "abstraction"
actually is...but human intelligence comes from our _ignorance_, not
from our knowledge...allow me to explain a little better: When the
human mind sees a car parked in the road, it "abstracts" the details
away...I mean, what you're looking at is wheels and a specific shape
and design and so forth...in terms of "details", no two cars are ever
the same...but we abstract away the "irrelevent details" until we
reach the conclusion that what it is, is a "car"...then we look at a
completely different model of car and, again, "abstract" this mass of
details into a simple abstract idea: "it's another car"...we can
compare the two "cars" on the abstract level...we can come to
conclusion about this abstract "car" idea, like they are "means of
transport" and so forth...by abstracting away the details - which is,
in fact, an act of _delibrate ignorance_ - humans are capable of
levels of reasoning that no other animal can manage...we're absolute
masters at this, in fact...being able to turn practically everything
into these abstract "number" concepts and conclude that an aeroplane
will fly simply by looking at the "numbers" without actually putting
it into the air...and it is these carefully done bits of "delibrate
ignorance" - the "abstractions" - that are the main component of human
intelligence that we do better than anything else on this planet of
ours...so, though it may initially sound daft, _ignorance_ is what
makes us intelligent..._knowledge_ is required to know _when_ a
particular detail is "important" and when it's "irrelevent"...to make
"ignorance" into "_DELIBRATE_ ignorance" - to choose the right times
to "get pendatic" about the "minor details" of these cars and when to
simply say "car" and ignore the differences between models - and
that's what "intelligence" amounts to...an interplay of delibrate
ignorance and knowledge...neither alone will actually work: Someone
who's completely "clueless"? Yup, totally...a complete dumbo...too
much "ignorance" with no knowledge...but, on the other hand, someone
who's full of "knowledge" but is constantly pedantic and doesn't know
when to apply it and when not to apply it? I'd say _equally stupid_
and _equally dangerous_ to be left in charge of something important
;) - but it can also get people killed...
I'm not in the slightest bit "unsympathetic" to your "cause",
Rene...I've told you many times and I came to ASM from HLLs for
_exactly_ these reasons...I'll also point out that I always post "pure
machine instruction" code whenever possible...I naturally write things
that way when I'm coding ASM...I can get as "real assembly" as the
best of them...
But I'd say that you're simply going to the other extreme, which
_will_ end up just as bad as the extreme you're trying to reject...at
the extremes of anything, they both become equally bad and, often,
almost identical...avoid extremeism of any kind at all costs...the
rise of Fascism - Hitler, Mussolini, Franco, etc. - was a "response"
to the rise of Communism before it...this is very, very typical human
reaction...when one "extreme" presents itself and people don't like
it, they simply jump over to being the complete and utter polar
opposite...
Yeah, sure, the teenager's parents can be an "embarassment" to them
and they want to "assert their independence"...but, also, when you see
some teenage brat prancing around like a pompous fool...well, you
know, that's pretty "embarassing" to watch too and, often, what does
their "independence" amount to? Yup, doing exactly what all their
other "mates" do because of "peer pressure" (all wanting to wear Nike
shoes because it's the "fashion" or all trying out smoking or drinking
or even drugs because "everyone else is doing it" and that sort of
thing ;)...from one "extreme" to the other...the "problem" not really
being "cured" at all - either way, we've got "embarassment" and
"dependence" - from taking _either_ "extreme" position...and these
kids only start to sort thing out properly when they _actually_ learn
_proper_ "independence" as they grow older and "mellow out" a
little..."peer pressure" slowly vanishing to acceptable levels, as
they work out that "independence" is all about being happy in your
_own_ company...so, clearly, sitting around panicking that your
friends will hate you because you're not wearing Nike shoes...well,
it's just as much a case of "dependence" on others, as wandering up to
"Mommy and Daddy" asking for money is ;)...
"Crusade" or "Jihad", it's still simply slaughter of innocents on the
basis of discrimination..."Protestant" or "Catholic" in Northern
Ireland, it was still simply people shooting and knee-capping each
other...Apartheid South Africa or Mugabe's Zimbabwe, it's still people
oppressing and killing on skin colour alone (also interesting to note
how these last two examples are "direct neighbours" as well, isn't
it?)...
If you're asking me to "take sides" then I care NOT what flag is being
waved...I'm perfectly aware of the troubles and even potential danger
to my life such an opinion can carry but I won't play such
games...there is no "black and white" for me in those terms...if you
murder - WHOEVER YOU ARE - I will NEVER support you...if you work to
try to enhance people's lives then, equally - WHOEVER YOU ARE - I will
completely support you...
A person is NOT their gender, their skin colour, their nationality,
their beliefs, their build, their age, their experiences...none of
this matters in the slightest...as long as that person _behaves_
correctly...that they try to _enhance_ people's lives, not
murder...that they work to create, not destroy...of course, like
everyone else, I'm human so I'll get annoyed and angry or I'll get
upset and paranoid or I'll get excited and "puppy dog" about something
that might not deserve it...I'll basically make mistakes all over the
place...we all do...that's life for you...but, fundamentally, after
the push and the shove, it simply boils down to that and that
alone...the only "abstraction" I'm going to acknowledge is that of
"person"...any "dispute" I'll "get over", so long as, in the end, we
can work things out and get things _moving forward_, not backwards...
> Also, for Code reuse, there are many features already implemented
that
> widely cover what the Libray concept covers, but with full respect
of
> Assembly programming and of Mono-Sources Programming. See for
example,
> how the IncIncluder Pre-parser works.
Oh, yes...the methods you've developed to keep to this "no libraries"
policy is, in fact, slightly impressive...it takes imagination and
skill to successfully implement fascist policy, without doubt...one
cannot really detract from that with cheap insults..."Big Brother"
was, unfortunately, not in the slightest bit "stupid" by any means...
But, sorry, you are enforcing _restriction_ and are attempting to
remove _choice_ and _Liberty_...I disagree fundamentally with that...I
sympathise completely with your "cause" for why you believe you have
to do this sort of thing (as hinted to above)...but, to put it plain
and simple, I think you're basically "barking up the wrong
tree"...you're going about this "problem" with the _wrong_
solution...and, yes, that's my opinion and I know yours is different
to this and you don't agree...but that's the way the cards have
fallen...regards your points about "specific assembly" and wanting to
promote those ideas, totally agree...regards the issue that
"abstraction" has its fundamental troubles, I'm of the same mind (I
just don't think making it 100% "verboten" is much of a solution...in
much the same way that declaring drugs to be "verboten" in society has
probably only conspired to make them _more_ saught after rather than
less...and has only conspired to make them highly expensive, which has
lead to addicted junkies taking up _crime_ - mugging, theft,
house-breaking, prostitution, etc. - in order to finance their
addictions...and has only conspired for those massive proceeds of this
very expensive item to help fund terrorism and organised crime on even
higher levels...granted, Liberalising the problem is unlikely to cure
it either - though the Dutch with their more Liberal drugs policies do
have _some_ "better" statistics, they also have a few statistics that
are _worse_...so it doesn't sound like it's a "cure" but more a
"displacement" of the problems into other areas - so there's no easy
answer...but declaring things "verboten" often only conspires to turn
them into "forbidden fruits" that taste all the more juicy _because_
you're not supposed to be eating it...the serpent may have "beguiled"
her but, deep down, there's got to a part of Eve who _wanted_ and
thought about eating that fruit whether the serpent was there or
not...the serpent merely brought that "naughty" Eve to the surface or,
otherwise, no amount of "beguiling" would have succeeded if she
fundamentally did not want to eat any fruit :)...
> 6) About having such things in HLA, this makes me laugh a lot: In
case
> you wouldn't know, such implementations require some serious
knowledge
> some expertise level, and some real impressive work time, that have
poor
> relationship with being super-guested at selling himself or at
writing
> Pdfs, or at missleading beginners with pathetic swindlings.
I could argue; But, instead, the simplest test is time itself...we'll
see, Rene...we'll just wait and see, shall we? :)
> 7) For having Resources (Dialogs, mainly) inside the Source, this,
also,
> is a feature that is available in RosAsm since years (not for Icons,
> actually), and i have some pain to imagine what interrest this would
be
> for Icons, ... but, well... why not?... ;)
Well, if you noticed, I totally acknowledged that RosAsm (and old
SpAsm too :) already tackled this issue in your own way and, thus,
excluded RosAsm because it doesn't apply to your tool...I also
conferred on you the honour of quite possibly being the "pioneer" here
in simply ignoring how things may or may not have been done by other
tools and simply did it your way regardless...though it's easy to see
you - as people seem to mostly do around here - as the "fool" who
"rushes in where angels fear to tread"...well, you'll have the last
laugh if, indeed, where you've rushed to is exactly the place where
everyone should be and you've beaten everyone there by, as you say, a
number of years...
It's always the thing about "pioneers"...you _could_ have a number of
good and useful points...but, at the same time, you could simply be
slightly insane...it could be potentially either conclusion...there's
plenty of examples of contemporaries insulting some "pioneer"
declaring them "insane" and, actually, it was the other way
around...but, on the other hand, history is also littered with people
who actually _WERE_ insane...I can look at your ideas and try to do my
best to objectively decide which of these I think you are (and, the
conclusion is "somewhere in the middle", if you're wondering ;) and
make my case about how I think this "no libraries / clips file" thing
is, in my opinion, probably a bad idea...but I recognise that, sure,
time has a weird way to it...things work in mysterious ways...who
knows what'll happen in the future (in fact, the chances are that
something neither of us are considering at all appears from
effectively "nowhere" and ends up replacing all of our ideas...you
know, someone somewhere suddenly posts up a "here's my new tool" and,
indeed, they've got it exactly spot-on for everyone to be
happy...Murphy's Law suggests that something like this - with all the
deep irony it carries - will probably happen...thus rendering all the
crap you, me, Randy, Hutch and others talk about over and over as
suddenly being "irrelevent" because some "new order" appearing from
nowhere renders everything we talk about all a bit, well,
pointless...and, according to Murphy's Law, then this grows more and
more likely, the more and more fuss and bitter arguments people
make...because that makes it even more _ironic_ if it finally shows up
;)...
Beth :)
- Next message: Beth: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Previous message: Randall Hyde: "Re: help a newbie"
- In reply to: Betov: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Next in thread: The Half A Wannabee: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Reply: The Half A Wannabee: "Re: HLA v2.x and / or LASM suggestion: Win32 Resources"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
