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
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
#include "\masm32\include\resource.h"
which defines most of the commonly used constants as C "#defines"
The resource compiler doesn't know the constants for the same reason that a C/C++ compiler, or ML, or etc does not.
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.
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 :biggrin:
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?
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)
OK, fine. I repeat the question: why does the resource compiler require a header file, with constants that it obviously already knows about?
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.
Quote from: MichaelW on July 01, 2012, 06:07:35 PM
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.
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)
Quote from: dedndave on July 02, 2012, 05:48:50 AM
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!
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". :biggrin: << typo removal. :icon_rolleyes:
"SomeCForMe" :lol:
Quote from: hutch-- on July 02, 2012, 08:43:28 AM
Once you get this we will need to rename you to "SomeCForMe". :biggrin:
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 ...
how 'bout...
"AsLittleCasPossible"
or...
"TheLessCtheBetter"
or, if you like short...
"IH8C"
:P
Except that I don't really H8 C. (I just pity the poor C programmer ... nah, not really.)
Maybe I should use "I [heart] ASM" or something. (Vanity license plate?)
CsuX :lol:
how about a bumper sticker....
"Honk if you hate C"
or
"My other language is Assembler"
The reason is that M$ decided it to be so. The Borland resource compiler didn't need the headers.
However, given that windows have evolved, I think that M$ did the right thing.
While I confess I am getting rusty with C, I don't have this religious fervor when it comes to writing code and if you use Windows, you are using a hell of a lot of code written in C and to a lesser degree, C++.
Now if this was a Unix forum, you would have the devotees frothing at the mouth over such heresies as not bowing down and worshipping the great god of C and they would be devising a Holy War against such infidels such as banishing you to a JAVA forum so that you could not partake of the religious virtues handed down by the great god of C. Now if the transgression was extreme enough, even the JAVA gods would be offended and they would in turn banish you to a HTML forum.
Fortunately for such infidels, Microsoft could not care less as long as you BUY Windows and even if you utter great and terrible heresies such as not worshipping the great god of C, you can always join the MASM forum. :P
Honestly, when it comes to programming languages, I'm not religious either. Not zealously in favor of assembly language, not a h8r of higher-level languages like C.
Ackshooly, C is about as close to assembly language as you can get; it's actually pretty low-level as so-called HLLs go. Some statements actually map 1-to-1 to assembly code. Others are so close that it hardly matters. Plus for those people who use the high-level constructs in MASM32, like if/elseif, loops, etc., the code that actually gets generated isn't a whole lot different than the corresponding C constructs. It all gets boiled down to jumps, dontcha know.
I used to write COBOL, a language much maligned in the programmer "community". However, I still say that it was the best tool to use for the jobs I was tasked with doing. To all the detractors of COBOL, I challenge them to write an understandable and, more importantly, maintanable payroll application in C++, Pascal or whatever.
I may be awfully green in assembly but this question has an obvious answer to me. I got accustomed to using the values directly, without the named variables, a lot in high level scripting languages. Especially given that some of these scripting languages don't even strip the unused portions of the includes. That leaves an awful lot of orphaned globals in the name of adhering to standards of waste.
In fact not even the resource compiler knows the constants by number. It merely passes on whatever number you provide for windows to make sense of. Windows can also directly interpret certain named arguments, but many parameters require the number itself.
In effect the question is a bit like asking why you need a phone book when the phone company already knows everybody's phone numbers. In this case the phone numbers are to call the right department in windows to get windows resources allocated to your program. If you want to use numbers instead of names you need no include for the names, but that doesn't mean the compiler knows what they mean either. Only windows knows when they are passes uninterpreted (unchanged) to windows.