Hey everybody,
what do people prefer for resources? By this I mean, do people
prefer to code it themselves through API/Data or just used rsrc.rc?

As it stands I use a resource file for menus, accelerators, etc. but
I know you can code these things explicitly. Is there an advantage
to this?? I'm especially interested in reducing my executable size.

Any insight is appreciated

Thanks

--Chorus
Posted on 2002-05-29 18:34:32 by chorus
i just like keeping everything in one asm file for very few reasons other than that - and i'm just stupid and too lazy to ask how to do some things when using resources that are "intuitive" if i'm not.
Posted on 2002-05-29 20:28:06 by jademtech
Chorus,

A long time ago I used to code applications with stuff like menus hardcoded to make them harder to hack but fom memory you end up with bigger code than if you use the resource capacity to build menus.

Where you can save space is by not useing resources to store strings as they are done as unicode that doubles the string space taken.

Hardcoding images is a genuine pain and while it can be done, resource scripts do it better and far easier.

Convenience and size are the reasons why I use resources instead of hardcoding this stuff.

Regards,

hutch@movsd.com
Posted on 2002-05-30 02:14:24 by hutch--
hmmm.... I figured because resources were easier, they would automatically be bigger!

out of curiousity, how does hard-coding resources make programs harder to reverse?? Does it just make the code more convoluted??

Anyways, thanks for the replies guys

--Chorus
Posted on 2002-05-30 08:19:57 by chorus


out of curiousity, how does hard-coding resources make programs harder to reverse?? Does it just make the code more convoluted??


Well any kid with zero programming knowledge can open up a program with a resource editor and alter or delete resources. If your menu strings are in your .data section then a reverser will have to use a hex editor to locate and edit any menu strings or other things.

edit: Basically not using resources limits the number of tools at their disposal, and the newbie crackers (the jne <--> jnz crowd) won't know what to do.
Posted on 2002-05-30 09:25:56 by Will
wow...
I didn't think people hacked resources!??!
Personally, I can't see the point...

I thought it was to just make the hacker wade through more code to get to the real stuff...

--Chorus
Posted on 2002-05-30 10:15:55 by chorus
Mods and Hiro: feel free to edit this if I'm out of line

chorus: Well as far as menus go (like hutch said), it's a bit more difficult to reverse since you've basically just got a disassembled messageloop that you've got to decipher as well as all of the menu related apis which are a pain especially with hll coded apps. But I've seen some very retarded programs that used for example a nag screen on startup that was on a timer and you had to sit through it for a few secs every time the program started. By simply deleting the nag dialog resource with an editor (without manually modifying any actual code), the dialog never appeared and their were no ill side effects so either the programmer added some error checking (seems unlikely) or windows is very forgiving about that type of stuff. So, there are some "protection" schemes that can be bypassed/defeated by simply mod'ing resources. But you're really just making it so brand spanking newbies can't crack your app.
Posted on 2002-05-30 12:10:39 by Will
I like resources for dialogs for sure :-). Not only are they easy to design in a resource editor, but they are measured in Dialog Base Units and not pixels so everyone can see them almost the same... AKA people using larger DPI settings... which is a very good thing :-). The only thing that sucks.. is maintaining using DBU instead of pixels for measurment if there is any resize code.
Posted on 2002-05-30 18:53:06 by Stan
Do others here think it is important to internationalize applications - create versions for different languages? I thought that was one of the main pluses of resource dialogs? Is Unicode really a joke to be ignored? Many of us write small tools, and don't want to make a great production. Seeing how many people here aren't native English speakers, I am surprised more people aren't using Unicode. I assume it is not mature enough - there is not enough support. Or maybe it has to do with the spread of technology in other countries - I'm really naive about this.
Posted on 2002-05-30 19:24:15 by bitRAKE
Personally, Internationalization (big word !) is not important to me. Simply cause I'm writing for a very small market: me. And although I speak some French and Japanese, my primary language (and indeed for everyone else in North America where I live) is english.

As far as Unicode goes, I've looked into it but it mostly seems to confuse things. My two assumptions regarding Unicode are 1) the regular string instructions work fine 2) It increases the size of the program's data segment.

--Chorus
Posted on 2002-05-30 21:55:03 by chorus

Do others here think it is important to internationalize applications - create versions for different languages? I thought that was one of the main pluses of resource dialogs? Is Unicode really a joke to be ignored? Many of us write small tools, and don't want to make a great production. Seeing how many people here aren't native English speakers, I am surprised more people aren't using Unicode. I assume it is not mature enough - there is not enough support. Or maybe it has to do with the spread of technology in other countries - I'm really naive about this.
Although I'm not a native English speaker, I write all of my stuff (also the internal-only use tools, and even the source comments!) almost always in English.. maybe because in my mind I associate English with programming (since I learnt it that way, originally), or because I just forgot my Italian.
Really, whenever I have a choice, I throw myself into the English version of any program I may need. But I see that this is atypical.. my local friends, even the ones that speak English better than me, do prefer the Italian localized version.

PS: BTW, I've always wondered what is the right, correct pronounce of the word "although". Is it just like saying "al" plus "though", or is it different?
Posted on 2002-05-31 00:34:37 by Maverick
"although"

al?though Pronunciation Key (all-th-oe)

oe, as in toe
Posted on 2002-05-31 01:00:13 by Sliver

Do others here think it is important to internationalize applications - create versions for different languages?


I think it is very important sometimes : especially for wide commercial groups that need the same standardized programs in each division in differents countries. I have seen softwares bought *only* (it was a big argument) because of that (and when you think of it in matters of code lines, that is obvious).
I still think the best choice is to make a dll for each langage and to put it in a specific, or if there's not much string, include them in the exe directly... or as f0dder suggested in some previous posts, make your own format.
But that's sometimes a bit overkill and the mainteners may don't like that even if it must be the best way to do it (translations in dll are easy to modify with a simple resource editor).

As for unicode... it is only for countries with specific characters like chinese, japanese, greek, and russian I think... unicode is ugly hard to maintain, wastes room and all these (_TEXT) in C just makes the code unreadable).
Posted on 2002-05-31 01:13:00 by JCP

"although"

al?though Pronunciation Key (all-th-oe)

oe, as in toe
Thanks :)
Posted on 2002-05-31 05:54:33 by Maverick
I agree with Readiosys here that in most instances where the quantity of locale specific data is large enough, put it in a seperate DLL so that a simple DLL change will set the APP up for another natural language.

Unicode does compound this a bit because of its size and lack of portability to earlier versions but even if the app type had to be split up between ANSI and UNICODE, a DLL is still the best way to handle different natural languages.

Regards,

hutch@movsd.com
Posted on 2002-05-31 06:52:26 by hutch--
Why do not simply maintain an editable text file for each lang?

Lang files will be easily maintained and translated by no-programmers.
The same code will speak any language the final users want.
The user switches easy from lang to lang
and this is important in an international workgroup.
The strings in the code are needed mainly for user interaction so there is no performance cost.
The code is not plagued of strings or language-mixed.

Regards.
Posted on 2002-05-31 10:11:03 by pelaillo