Re: HLA v2.x and / or LASM suggestion: Win32 Resources

From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 01/06/04 

Date: Tue, 06 Jan 2004 04:05:22 GMT

"Beth" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message
news:TCcKb.253$mf4.251@newsfep3-gui.server.ntli.net...
>
> With Microsoft's RC compiler, I've just noticed that it's less capable
> than Borland's version...with Borland, there are two versions of
> resource statements like "ICON", where one version is "compatible"
> with Microsoft's statement and simply names the ".ico" file with the
> _binary_ icon resource (e.g. 'MY_ICON ICON "MyIcon.ico"' :)...then
> there's a second "source" version where rather than the filename, it
> actually dumps out a whole bunch of hex codes that are, basically, the
> binary resource converted into readable, editable ASCII form...

So you can embed the code in TASM, no doubt.

>
> Anyway, Microsoft's "lesser" functionality is a pain from the
> perspective of, say, posting up code here that includes an icon...this
> ain't a binary group so I shouldn't be attaching any binary
> files...and, most importantly, some newservers would automatically
> remove the binary attachments so that some people wouldn't be able to
> see them (my ISP is okay with this but I know some have different
> policies)...plus, it's just general netiquette, which I tend to agree
> with, that _source_ not binary is posted (i.e. virus worries, source
> _should_ be visible as usually the whole point is to _show_ how things
> are achieved and be "educational" that just posting up a binary ".exe"
> file for everything wouldn't be particularly useful here and this
> problem would be the resource equivalent to just posting up closed
> source ".exe" files for every problem, etc. :)...

So why not provide a little utility that converts ".ico" files to a hex
dump that can be processed by one's favorite assembler? Indeed,
this would be a trivial program to write in Delphi with radio buttons
selecting the particular assembler syntax you want to output for.

>
> So, whilst pondering how to get around this (for example, it is
> possible to create an icon or bitmap on-the-fly in the actual program
> for use...but the problem with that is that the icon would not be
> picked up by Explorer to make the ".exe" file look pretty there, which
> is what people would expect and what having an "icon" would primiarily
> be all about in most cases ;), I started thinking even more generally
> about this...beyond the immediate problem of getting an icon onto a
> posted-up Win32 code example (although, in the end, this _isn't_
> essential or crucial...I just thought that it would be nice if I could
> think up a way of doing it that's totally source-based...possible with
> Borland tools but lots of people only have Microsoft's RC compiler or
> are using that RC compiler via HLA or whatever ;)...

Sounds like a perfect add-in tool for RadASM...

>
> I just thought a simple thought: "if RC is a _compiler_, then why
> isn't this stuff part of the assembler or C++ compiler,
> anyway?"...well, one reason is, of course, that Microsoft produce MASM
> and MSVC++ and so forth, which could all make use of a resource
> compiler...hence, make a separate tool and then all of them can share
> the same compiler...I can see why _Microsoft_ have gone in this
> direction (and why they - unlike Borland - only think of "binary"
> files and not any "source" equivalents...this is Microsoft who happily
> throw ten 48MB DLL files at implementing "strlen"! Of course
> _Microsoft_ would do things this way...it's their modus operandi
> :)...they produce lots of different tools and languages and so forth,
> so they are just "sharing" the common bits between them (like LINK.EXE
> is the same for all these tools too :), as there's no sense them
> "re-inventing the wheel" every time :)...

RC.EXE *really* is a compiler. There *really* is a source language
that RC processes (often called "resource scripts"). E.g.,

PopupMenu MENU
BEGIN
  POPUP "Dummy Popup"
    BEGIN
      POPUP "Fonts"
        BEGIN
          MENUITEM "Courier", IDM_FONT_COURIER
          MENUITEM "Times Roman", IDM_FONT_TMSRMN
          MENUITEM "Swiss", IDM_FONT_SWISS
          MENUITEM "Helvetica", IDM_FONT_HELV
          MENUITEM "Old English", IDM_FONT_OLDENG
        END
      POPUP "Sizes"
        BEGIN
          MENUITEM "7", IDM_SIZE_7
          MENUITEM "8", IDM_SIZE_8

          MENUITEM "9", IDM_SIZE_9
          MENUITEM "10", IDM_SIZE_10
          MENUITEM "11", IDM_SIZE_11
          MENUITEM "12", IDM_SIZE_12
          MENUITEM "14", IDM_SIZE_14
        END
      POPUP "Styles"
        BEGIN
          MENUITEM "Bold", IDM_STYLE_BOLD
          MENUITEM "Italic", IDM_STYLE_ITALIC
          MENUITEM "Strike Out", IDM_STYLE_SO
          MENUITEM "Superscript", IDM_STYLE_SUPER
          MENUITEM "Subscript", IDM_STYLE_SUB

        END
    END

END

>
> But why do other packages - like HLA, (the upcoming) LASM, GoAsm,
> etc. - actually need to separate out the resource compiler from the
> "source compiler", so to speak?

Well, guess what? There really isn't *too* much of a need to bury a resource
compiler into HLA directly. HLA's macro facilities are powerful enough to
write your own "resource compiler". You can find a simple example of
this in the "resources.hhf" header file found in the EXAMPLES download
for HLA on Webster. Here's a sample "resource script" that this "resource
language" processes:

#include( "resources.hhf" )

resource( "myres.rc" )

    STRINGTABLE
        str1:strres( "Hello World" );
        str2:strres( "How are you?" );
        str3:strres( "I am fine" );
    ENDSTRINGTABLE;

    myaccs: ACCELERATOR

        acc1:acc( "^C" );
        acc2:acc( "K" );
        acc3:acc( "k", ALT );
        acc4:acc( 98, ASCII );
        acc5:acc( VK_F1, ALT, VIRTKEY );

    ENDACCELERATOR;

    myDlg: DIALOG( 10, 20, 300, 400 )

        a3s :AUTO3STATE( "caption", 10, 20, 100, 200 );
        acb :AUTOCHECKBOX( "caption1", 11, 21, 101, 201 );
        cb :CHECKBOX( "caption2", 12, 22, 102, 202 );
        cmbo:COMBOBOX( 13, 23, 103, 203 );
        ctxt:CTEXT( "Centered Text", 14, 24, 104, 204 );
        dpb :DEFPUSHBUTTON( "Default Push Button", 15, 25, 105, 205 );
        etxt:EDITTEXT( 16, 26, 106, 206 );
        gbx :GROUPBOX( "Group Box", 17, 27, 107, 207 );
        icn :ICON( "ICON", 1, 2, 3, 4 );
        lbx :LISTBOX( 1, 2, 3, 4 );
        ltxt:LTEXT( "LTEXT", 1, 2, 3, 4 );
        pbx :PUSHBOX( "PBOX", 1, 2, 3, 4 );
        pbtn:PUSHBUTTON( "PUSH BUTTON", 1, 2, 3, 4 );
        rbtn:RADIOBUTTON( "RADIO BUTTON", 1, 2, 3, 4 );
        rtxt:RTEXT( "RTEXT", 1, 2, 3, 4 );
        sbar:SCROLLBAR( 1, 2, 3, 4 );
        s3c :STATE3( "STATE3", 1, 2, 3, 4 );

    ENDDIALOG;

    myCurs :CURSOR( "arrow.cur" );
    myBM :BITMAP( "Buttons.bmp" );
    myFont :FONT( "roman.fon" );
    FONT( 12, "roman.fon" );

endresource;

#system( "rc -v myres.rc" )

This actually generates an RC.EXE compatible source file, that gets compiled
by
rc.exe, but the concept for generating binary data directly is certainly
possible (though
quite a bit more work) using the HLA compile-time language.

Should it be built into HLA v2.0? No. Not because "it's not assembly", but
because
it's specific to Windows and doesn't apply to other operating systems. As
long as
you can do it (albeit more slowly) with the macro language, there is no
reason to
add such OS-specific code directly to the HLA translator.

>
> Now, before anyone jumps on this with the usual Microsoft quotations:
> "putting resources into a separate file eases internationalisation"
> and so forth...I perfectly realise this and what I'm suggesting can
> work either way...if you want resources in a separate file then create
> a separate ".asm" file with just the resources...if you'd rather an
> "all in one" affair (the most suitable for posting up :) then you can
> stick these statements into the one and only main source code file
> instead...you "separate" your resources into a separate file
> _manually_, is all...it's hardly rocket-science...you don't need to be
> calling it special names like "resources" and having special compilers
> to _force_ them separate...we're ASM coders, right? We don't need
> "data typing" tricks to force us to keep data in order, we do it all
> manually! :)...

Nor do you need RC.EXE! You can create the binary objects directly
in your assembly code. All you need is a description of the data structure
and you're in business. This is one place where having a more powerful
assembler (like HLA) comes in handy, as you can create data types and
macros to let you create static versions of the dynamic data structures
without having to manually count bytes, align bits, etc.

>
> The idea being something along these lines...resources are just
> another (special) type of "section" inside a PE file...thus, just like
> ".data" and ".code", we simply add ".resource" (or something
> similar..."[section resource]" for NASM, one supposes ;)...then the
> actual resource data can follow in that section...it's, of course, up
> to the tool author to decide how best to define the syntax...I'd
> imagine, for example, that HLA would go for actual "ICON" and "BITMAP"
> data type statements and look comparable to RC (but also allowing,
> perhaps, that "DB" works in this section too, so that "hand-made"
> resources and resource tables are an option as well ;)...NASM (though,
> would NASM be appropriate for this idea when it's not only Win32 and
> only Win32 has this "resource" concept? Maybe not but I'll pretend it
> is for the moment to make the example :) going for something more like
> "DB" statements, insisting on a "low-level" syntax...certain resources
> like "RCDATA" and "STRINGTABLE" and so forth are almost automatically
> appropriate for a "DB" statement straight away, anyway...

No special sections are necessary. It's just binary data. Put it right in
your
Data section. The advantage of using resources is that Windows can
dynamically
load (and unload them) as needed. This can save some space when you're using
lots of resources (e.g., large bitmaps) and you don't necessarily display
them all
during one execution of a program. OTOH, if you embed them in your data
section, then they take up space in memory as long as that page is
referenced by
the program. Also, sharing the resource is a bit more difficult...

>
> [ RosAsm has its own "editors" for interactively adding resources to a
> file...it could be possible to add some "source code equivalent" so
> that, for example, I could actually post up an icon _in ASCII_ that
> can be put onto a RosAsm program via _source_ rather than the
> editor...but that may violate Rene's "principles" here (this actually
> makes a good way to demonstrate the weirdness of Rene's "no library"
> principles, in a sense...for example, I've drawn up a bunch of
> cool-looking icons...but I _can't_ give them to any RosAsm programmer
> because that would be using a "library"...indeed, not a code library
> but it's still a "library" of icons that _I_ drew rather than they
> drew...I mean, to echo Rene, if I provide pre-drawn icons, then users
> of these "library" icons wouldn't know _how_ I went about drawing
> them...did I start by drawing the circle or was that actually added
> later? You can't tell the order something was drawn by simply looking
> at it...thus, this is "black box", this is "hidden", this is "library"
> and no RosAsm programmer should ever use any icon, bitmap, wave file
> or anything else that they themselves did not create...otherwise,
> you'll be using a "black box"...so, Rene, care to explain how it's
> "wrong" to do so with code but you "overlook" it when dealing with
> other resources? Out of interest, does this extend to _data_ of any
> kind? In my "adventure game" - sorry, "interactive fiction" - example
> I posted up a while ago, I had a simple "engine" that accepted
> different _data_ for different "adventures"...hence, would someone
> using my game map elsewhere count as "black box" too? Are DOOM, Quake,
> Half-life and the others with their similar "game engine (plug in your
> data on-the-fly)" schemes also "out of bounds" because, yes, those
> people making their own Counter-strike maps _are_ using Half-life in a
> "black box" way? Where does this end, Rene? Can I no longer use my DVD
> player or washing machine because I don't understand what every
> transistor inside them does? Blah-blah-blah...no, I _understand_ what
> you mean about "black box" being "dangerous", "leading to bloat",
> etc., etc....but I think you've got it all wrong to introduce what is
> actually a very right-wing, fascist "ThoughtPolice" in _forcing_
> people never to ever use them..._even when_ they were the ones who
> potentially built these "black boxes" for their own purpose...for a
> "leftist" and "opensource" kind of guy, it's amazing just how quickly
> you've jumped to a _fascist_ solution...no, really, when you call
> others "fascist", it's a bit of a joke really...not because they
> aren't being so at all but because of the massive, massive irony that
> you've probably created the _only_ "fascist ThoughtPolice" programming
> tool ever to have existed on this planet...a tool that delibrately
> makes sure that "code libraries" can't be used in any shape or form,
> forcing them through this "clip file" stuff instead...in trying to
> defeat your "fascist" enemies, Rene, you have _become_ the greatest
> fascist of them all)... ]

Check out RadASM. Plug-ins for RadASM provide exactly the
facilities you're asking for here.

>
> Actually, this is probably mostly a LASM suggestion because
> "resources" are a Win32-specific kind of deal, thinking about it...but
> the possibility is there for others to allow such statements for their
> Win32 "mode of operation" or something (like NASM has different
> "sections" according to the format :)...although, I was also kind of
> thinking it might be cool for HLA v2.x as well in that Randy could
> more easily write examples and so forth for "Windows Programming in
> Assembly" or whatever that supplies icons, bitmaps and stuff directly
> in the source code without the complexity of makefiles, running RC
> compilers and so forth...that, as was the case with simple console
> applications, you can simply put "HLA MyCode.hla" onto a command line
> and the whole thing is done automatically...one possibility for
> "compatibility" is that any "resource" section could be simply
> considered "extra data" in any target other than Win32, which doesn't
> specially support these "resource" concepts...it could still make
> sense and be useful to have a renamed "data" section called "resource"
> that simply already understands how to load and format ".GIF" or
> ".JPG" or ".MP3" into the data section for use...

The whole point of the resource compiler is to create object files with
these binary objects that you can link with your application. All you're
really asking for here is to merge the linker/resource compiler with the
assembler. Sure, it can be done. FASM is a great example of this. Does
it buy you much? Depends on what you're looking for. Personally, I
prefer the modular approach (each tool does its thing well) rather than
the monolithic approach (e.g., "The assembler includes an ASCII table
for viewing ASCII codes.").

Also keep in mind that this is adding a lot of extra syntax and reserved
words to the assembler. Of all people, you should realize the problem with
this.

>
> Anyway, this idea has _only just_ come to mind so I admit I've not had
> time to completely think it through (could be some major "dumb" thing
> about it I've missed :)...but, as it struck me now, I thought I'd
> better post it up or I _would_ simply forget about it, I'm sure ;)...
>

Well, think it through.
I think you'll realize that at some point we've got to decide that
certain programming activities need to be handled by separate tools.
The place for resources to be handled is by the IDE, IMHO.

> Basically, though I'm not completely convinced by Randy's "DOS is
> dead", as I still think it can be useful and demonstrate things (but,
> sure, if someone has limited time - because they are only doing it for
> a "course" - then "getting straight to the point" might be the best
> way...I wouldn't say "taking the scenic route" is "dead" or "wrong"
> but if you've got to get to a destination within a certain time, I can
> certainly understand it being "impractical" that, if someone intends
> to do only Windows / Linux stuff, then messing around with DOS might,
> indeed, be "educational" but if you don't have the time, then you
> don't have the time...and it's as simple as that: "impractical"...I'll
> still be posting up DOS-based examples, anyway, as they are the
> easiest and usually smallest and the OS that almost everyone can
> access that the examples "stretch" the furthest :)...but, along these
> same lines, if these "old ways" are "dead" then shouldn't Windows
> 32-bit tools stop thinking in a "DOS - with an extra compiler added
> for the non-DOS stuff - way"? And, on that point, I have to 100%
> support and congratulate Rene for basically thinking this and then
> _doing it_ with his tool...I'm not sure if he's really a "technique
> pioneer" - that's open to debate - but maybe he's certainly an
> "attitude" pioneer...

DOS is not dead insofar as no one uses it.
It's dead in the sense that it doesn't make any sense at all for a
complete beginner to waste time learning the DOS API. If you
already know all the DOS/BIOS INT calls, feel free to write
some demo program that uses them. Just don't recommend that
someone *learn* this stuff as the material is quite obsolete and their
time is better spent learning the Windows or Linux API. For the
few beginners who wind up having to write DOS apps later on,
learning DOS won't be a problem. But why subject *everyone*
to this when *most* people will never use DOS in their lives?

Cheers,
Randy Hyde

Loading