resource files and assembler

Hi all,

Although I posted this to the FASM group without
a reply as yet I thought I might cast my net
wider as this has become a real hump in my road
to understanding how to program windows APIs
with assembler.

My background: NASM using the NASMIDE IDE in DOS.

I am trying to get back to some assembler programming
after a six year absence but this time with Windows.

I am now up to Iczelion's Tutorial 8, Menu.

I am using Iczelion's tutorial along with Sulaiman
Chang's FASM versions of the examples.

What 'language' does a resource script use?

It appears different with MASM and FASM.

Is it the Assembler or the OS that reads this script?

I assume the LoadMenu API is how the menu resource
script is referenced to the program.

invoke LoadMenu, [wHInstance], 30 ; FASM

invoke LoadMenu, hInst, OFFSET MenuName ; MASM

Now in MASM, 'MenuName' is an address label to a
byte array, "FirstMenu",0

In the FASM version it is what?

I have found the 30 in the resource section:

resource appMenu, 30, LANG_ENGLISH, menuMain

and,

menuitem 'MenuBar C (without item)', 30, MFR_END

which I take is an ID that is returned in the
wmCOMMAND's wParam when the item with that ID
is clicked.

Is there any easy way to understand all this?

Regards,

John Casey

email: jgkjcasey at yahoo.com.au

JGCASEY wrote:
> Hi all,
>
> Although I posted this to the FASM group without
> a reply as yet I thought I might cast my net
> wider as this has become a real hump in my road
> to understanding how to program windows APIs
> with assembler.
>
>
> I am now up to Iczelion's Tutorial 8, Menu.
>
> I am using Iczelion's tutorial along with Sulaiman
> Chang's FASM versions of the examples.
>
> What 'language' does a resource script use?

The "resource" language.
This is defined by Microsoft and others (each with their own variants).
ICZ probably uses the Microsoft variant.

>
> It appears different with MASM and FASM.

Hmmm....

>
> Is it the Assembler or the OS that reads this script?

Neither. It is the RC.EXE (or similar) program that compiles the
resource source file into an object file.

>
> I assume the LoadMenu API is how the menu resource
> script is referenced to the program.

Yes, but the object file produced by the resource compiler is linked
with your executable like any other.


>
> Is there any easy way to understand all this?

MSDN. Search for "resource compiler" or "resource language".
Cheers,
Randy Hyde

randyhyde@earthlink.net wrote:
> JGCASEY wrote:

...
 
>
> MSDN. Search for "resource compiler" or "resource language".

Found it thanks Randy. There is no easy way of doing this
is there?  With all the paper work, manuals to digest and
forms to make out it feels more like learning to be a lawyer
than doing any actual programming :)

Windows is a bureaucrats paradise on earth.


Cheers,
John Casey

"JGCASEY"  <spamtrap@crayne.org> écrivait news:1127087879.621933.74500
@g43g2000cwa.googlegroups.com:

> Is there any easy way to understand all this?


Yes. See what a memory Resources Template is,
with RosAsm:

A Resource is nothing but a chunk of Data,
informing the OS about the wanted Dialog
Structure (and various Components). This
"chunk of Data" may, as well, be stored in
"normal Data" as in the Resources Section.

The main differences you will see in between
FASM and NASM Templates will probably be the
fact that the MASM users (who are mainly HLL
Programmers) most often refer to the Dialogs
by "Named IDs", and that the FASM users (who
are, mainly, Assembly Programmers), do it,
like in RosAsm, by "Numbered ID". Maybe that
could be the case with your Menu reference
example.


Betov.

< http://rosasm.org >

FASM writes resources directly into the resource section, you can use
some macros to make it easier (I haven't looked in a while, but I
suspect the tutorials use the macros).  You also have the option of
including a pre-compiled resource binary, there was a directive for
doing so.  Of course, you can also compile to PE COFF and use a
separate resource compiler and linker (PORC and POLINK are great for
this).

-sevagK.
www.geocities.com/kahlinor

sevagK wrote:
> FASM writes resources directly into the resource section, you can use
> some macros to make it easier (I haven't looked in a while, but I
> suspect the tutorials use the macros).  You also have the option of
> including a pre-compiled resource binary, there was a directive for
> doing so.  Of course, you can also compile to PE COFF and use a
> separate resource compiler and linker (PORC and POLINK are great for
> this).
>
> -sevagK.
> www.geocities.com/kahlinor


I think I figured it all out last night.
The FASM manual gives details as well.
Comparing the MASM version with the FASM
versions has made it even easier.

Thanks for the response,

John Casey

Betov wrote:
> "JGCASEY"  <spamtrap@crayne.org> écrivait news:1127087879.621933.74500
> @g43g2000cwa.googlegroups.com:
> 
>
>
> Yes. See what a memory Resources Template is,
> with RosAsm:
>
> A Resource is nothing but a chunk of Data,
> informing the OS about the wanted Dialog
> Structure (and various Components). This
> "chunk of Data" may, as well, be stored in
> "normal Data" as in the Resources Section.
>
> The main differences you will see in between
> FASM and NASM Templates will probably be the
> fact that the MASM users (who are mainly HLL
> Programmers) most often refer to the Dialogs
> by "Named IDs", and that the FASM users (who
> are, mainly, Assembly Programmers), do it,
> like in RosAsm, by "Numbered ID". Maybe that
> could be the case with your Menu reference
> example.


I think I figured it all out last night.

That is to the extent that I see a resource
as another language to learn that is converted
somehow to a .obj file.

Now onto the Using a Dialog box as the main
Window that is also programmed as a resource :)

Regards,
John Casey

hmmmmmm,

==================================
The main differences you will see in between
FASM and NASM Templates will probably be the
fact that the MASM users (who are mainly HLL
Programmers) most often refer to the Dialogs
by "Named IDs", and that the FASM users (who
are, mainly, Assembly Programmers), do it,
like in RosAsm, by "Numbered ID". Maybe that
could be the case with your Menu reference
example.
==================================

This statement is actually incorrect. Microsoft introduced 32 bit
capacity in MASM in 1993 as is shown in the example code for boxed
versions of MASM 6.11 and with the introduction of 32 bit versions of
Windows, resource identifiers are specified as numeric. Named resource
identifiers are a left over from 16 bit Windows and are not very
reliable in 32 bit Windows.

I have seen a reasonable amount of MASM code written using equates to
numeric identifiers in much the same way as Microsoft C code but the
vast majority of MASM code I have seen in the last 10 years uses the OS
specification of numeric resource IDs without bothering to use equates.

32 bit MASM clearly predates any other assembler that is 32 bit Windows
capable by some years and has been used directly in the production of
Windows up to current versions with important low level components of
the operating system so its not as if it needs anything from later
assemblers that have nothing like the 24 year old  development history
and corporate budget behind it.

Sweeping generalisations about classes of programmers is simply part of
a dogma about what constitutes an assembler and who are assembler
programmers based on their tools but the tools that have the runs on
the board are the profesional tools like MASM, GAS and to a lesser
degree, NASM and this can be objectively measured by operating system
usage, large commercial application usage and the like.

While some of the emerging assembler are technically very good and
improving rapidly with examples like FASM and GoAsm, they don't have
the runs on the board that the older and more mature professional tools
have where it matters.

The following statement is also misleading,

==================================
A Resource is nothing but a chunk of Data,
informing the OS about the wanted Dialog
Structure (and various Components). This
"chunk of Data" may, as well, be stored in
"normal Data" as in the Resources Section.
==================================

The Portable Executable (PE) specification has a resource section
historically named as ".rsrc" and to address data in the resource
section using the resource access type of API calls, you must specify
an instance handle which is the start address of the loaded module in
memory.

It is technically possible to place data of any type in either the
".text" section or the ".data" sections among others but it comes at
the price that you cannot use the resource loading API functions to
access the data and would have to write parallel functions to be able
to do the same thing.

It appears to be necessary for the smaller assembler to have to write
their own resource sections where a tool like MASM is properly object
module capable so it is able to use external tools like RC.EXE to
compile resource scripts seperately, convert them to an object module
with CVTRES.EXE and link them into the final binary image using a
linker.

The simple solution for the emerging assemblers is to support seperate
object modules so they can take advantage of proper componentisation
and code reuse that distinguishes the professional tools from the rest.

Regards,

hutch at movsd dot com

"hutch--"  <spamtrap@crayne.org> écrivait news:1127432949.064390.262360
@g43g2000cwa.googlegroups.com:

> The simple solution for the emerging assemblers is to support seperate
> object modules so they can take advantage of proper componentisation
> and code reuse that distinguishes the professional tools from the rest

How goes your Power Basic Devs?

:)

Betov.

< http://rosasm.org >

hutch-- wrote:

> I have seen a reasonable amount of MASM code written using equates to
> numeric identifiers in much the same way as Microsoft C code but the
> vast majority of MASM code I have seen in the last 10 years uses the
> OS specification of numeric resource IDs without bothering to use
> equates.

Use of "magic numbers", with all their wonders... Works okay-ish for small
one-man projects that you won't have to make changes to later. For anything
else, defines is the way to go.

> It is technically possible to place data of any type in either the
> ".text" section or the ".data" sections among others but it comes at
> the price that you cannot use the resource loading API functions to
> access the data and would have to write parallel functions to be able
> to do the same thing.

Huh? As long as the resource directory member in the PE header points to
your resource data, you could have the resources stored in ".cupcake" for
all the OS cares. And yes, you'd still be able to use the normal resource
API functions.

> It appears to be necessary for the smaller assembler to have to write
> their own resource sections where a tool like MASM is properly object
> module capable so it is able to use external tools like RC.EXE to
> compile resource scripts seperately, convert them to an object module
> with CVTRES.EXE and link them into the final binary image using a
> linker.

FASM supports it's own resource (as well as import, export, etc) schemes not
out of necessity, but flexibility. This way, you can write fully-fledged
executables with nothing but fasm.exe. If you want to use import libraries
and .res style resources, fine, just assemble to object format and use a
linker and a resource compiler.

Flexibility, not necessity.