Why does resource-file need to contain systemconstants?

[laskar01]

Hi all, I've reached Izcelions tutorial number 11:1, and I am suprised that there's need for
these definitions of the systemsconstants below in the resource-file.
I've searched for these values in a Win32.hlp file that I've dowloaded from this site, I believe. But cannot find these values.

Why doesn't the resource compiler know all of them already, and where can I find them?

#define DS_CENTER           0x0800L
#define WS_MINIMIZEBOX      0x00020000L
#define WS_SYSMENU          0x00080000L
#define WS_VISIBLE          0x10000000L
#define WS_OVERLAPPED       0x00000000L
#define DS_MODALFRAME       0x80L
#define DS_3DLOOK           0x0004L
#define WS_CAPTION          0xC00000L
#define ES_AUTOHSCROLL      0x80L
#define ES_LEFT             0

Kindest regards,
Lasse

[dedndave]

they are defined in windows.inc - in ASM syntax
however, the resource files use a C-like syntax
usually, the first line i put in a resource file is

Code: [Select]

#include "\masm32\include\resource.h"which defines most of the commonly used constants as C "#defines"

[MichaelW]

The resource compiler doesn’t know the constants for the same reason that a C/C++ compiler, or ML, or etc does not.

[NoCforMe]

Ackshooly, those constants, as well as many others need to define resources, are in a standard C header file called "resource.h". This file is included with MASM32 and lives in the \include folder.

I keep getting messed up when using ResEd, the free resource editor I downloaded, because it doesn't include that file by default and I have to add it by hand to every project I create. (Probably some way to configure it to include the file by default, but I haven't figured that out yet.)

To answer your question, these constants are needed because they define certain characteristics of things created by the resource editor. The WS_xxxx values are window styles (WS_SYSMENU creates a window that contains a system menu), and the ES_xxxx values are styles for edit controls.

[hutch--]

Ther is an even simpler answer, RC.EXE requires C syntax for RC scripts so you must have a separate C header file for it. In MASM32 its RESOURCE.H 

[NoCforMe]

Now that I think of it, why does the resource compiler require that header file? After all, all those constants (window styles, etc.) were available to the application creator when they made the program, and are not likely to change, so why didn't they just get included in the program? Why do we need to link to it externally?

[dedndave]

the application is assembled by MASM --> OBJ file
the resource file is compiled by the resource compiler --> OBJ file
the object modules are then combined by the linker to create an EXE (or DLL or LIB)

[NoCforMe]

OK, fine. I repeat the question: why does the resource compiler require a header file, with constants that it obviously already knows about?

[MichaelW]

The resource compiler knows the constants by number, not name. The header file associates names with the numbers. You can use the numbers without the header file, and that is what many resource editors do, but for manual coding, using named constants makes the task much easier.

[NoCforMe]

The resource compiler knows the constants by number, not name. The header file associates names with the numbers. You can use the numbers without the header file, and that is what many resource editors do, but for manual coding, using named constants makes the task much easier.

Thanks for your reply, Michael, which at least addressed the question directly. But I still don't find that a satisfactory answer. (It may be that I'm not seeing something that's blindingly obvious, so feel free to point this out if true!)

I don't see why the resource compiler need be ignorant of both the constants' values and their names. After all, the creator of the compiler (rc.exe or whatever) had access to the same header files that we do; why didn't they include that capability in the compiler, instead of  forcing the user to #include it?

One possible answer that snuck into my mind was that maybe (I'm not sure of this) the resource compiler can compile resources for OSs other than Windows (Linux, etc.); is this true? My guess is no, but I don't really know. But in that case it would make sense, as the compiler would need to know the constant values for that particular OS.

[dedndave]

if they add a new constant - they update the resource.h file
they don't have to re-write the compiler for every update of windows constants

my point about the OBJ files and the linker was this...
the OBJ from the assembly language source and the one from the resource are seperate entities
one knows nothing about how the other was constructed
the linker merely puts them together
so - the constants that are defined in resource.h may duplicate those in windows.inc (et al)

[NoCforMe]

if they add a new constant - they update the resource.h file
they don't have to re-write the compiler for every update of windows constants

OK--finally, an answer that makes sense. Don't know if that's the definitive answer, but it works for me!

[hutch--]

You will do a lot better by getting the swing of what RC.EXE is, its a RESOURCE COMPILER and to handle the large range of values, the programmer needs to supply those values in the form of an INCLUDE file. NOTE  that RC.EXE uses C notation which means that it must occur in the form of a C header file.

What is happening when you use a named constant which is not included in the RC script (usually in the form of  C header file) the resource compiler cannot continue because it does not know what to do with the unknown named constant.

Once you get this we will need to rename you to "SomeCForMe".      << typo removal.  :icon_rolleyes:

[dedndave]

"SomeCForMe"   :lol:

[NoCforMe]

Once you get this we will need to rename you to "SomeCForMe". 

Hah!

Actually, that handle is a bit of a lie. While it's true I don't write any C, I end up reading tons of it (on MSDN and elsewhere) and using it in .rc files. Can't totally get away from it, I guess ...