invoke InitCommonControl
is absolute vaste of bytes and clocks. It does nothing.
It is needed only to create entry in PE file for comctl32.dll
so OS loader would link the DLL.
To check it you can remove InitCommonControl from code
and add code at start
.data
comctl32 db 'comctl32.dll',0
.code
invoke LoadLibrary,offset comctl32
;and no more InitLoadControls needed
So how make OS loader link it and at the same time don't vaste clocks and\or bytes
for InitCommonControls.
1. To not vaste clocks just put
call InitCommonControls anywere where it never will be executed
for example in the plaxe
invoke ExitProcess,0
call InitCommonControls
2. To save both bytes and clocks making OS loader still to load comctl32.dll
write in include section
includelib comctl32.lib
and put on make file in link option /OPTION:NOREF
it will make entry in PE header for OS loader to load comctl32.dll though
there is no reference in your code to any comctl32.dll functions.
After that you don't need any InitCommonControls call.

I leave for others to warn you about /OPTION:NOREF usage subsequences ;)
Posted on 2002-05-08 03:25:43 by The Svin
Without OPTION:NOREF
short (in bytes) way IMHO will be in start of code:


call @F
db 'comctl32.dll',0
@@: call LoadLibrary
Posted on 2002-05-08 05:04:14 by The Svin
So,

Whats the difference to using the code, and using the InitCommonControls API ?

InitCommonControls API will indeed, must likely do the same task as the code you mentioned above !!

As newbie Win32 ASM coder, I'm must likely getting myself into something I know nothing about here, but as far as I know (and thats not much, but I do know something :)), the InitCommonControls will load the DLL and as you say, create an entry for it in the PE file Import Tables.

I may be wrong here, but I believe your point is still valid, and a good one at that. Maybe the code you mentioned whould save a couple of bytes and CPU Ticks here and there, but in that case!! Why use API's at all ?? Why not just code your programs raw :) ... You can't use the excuse of accessing hardware and crap like that, as its quite simple to enter Ring-0 security level where you'll have total control over the system hardware ...

Thanks for reading :P
Posted on 2002-05-08 05:11:46 by Dracton
Dracton

The point here is that the InitCommonControls function itself dosen't do anything so it is a waste of time actually calling it.
Posted on 2002-05-08 05:54:22 by Kudos
OK,

So why does the Win32Asm tutorials actaully tell you to use this API call ?
Posted on 2002-05-08 06:02:40 by Dracton
So Masm knows to link to the common controls dll
Posted on 2002-05-08 06:22:46 by Kudos
InitCommonControls API will indeed, must likely do the same task as the code you mentioned above


You forced me write it twice:
Put call InitCommonControl in a place it never be executed.
If you right, than it means that the task will not be performed
and any Common controls would not be created.
But they will. So you are wrong.
BTW: for asm programmer there is not a problem to know what
any the func does - you just open comctl32.dll and look.

If you need more example and not lazy to spend a minute to check before your next answer do following:
1. In make file and to link line one option
/option:NOREF
in header of asm file put
include comctl32.lib
extern InitCommonControls@0:PROC

But don't call InitCommonControls.
Yet you'll see that they are created.
As to Win32asm tuts - it's very funny.
If I write another Win32asm tut without InitCommonControls?
Posted on 2002-05-08 07:26:33 by The Svin
Svin,
Iczelion already illustrates this point in his tutorials, he recommends putting the invoke InitCommonControl after the ExitProcess().

Maybe i need some education here.... if you are worried about bytes and clock cycles, why not just include the file comctl32.dll on the command line for the linker?
Posted on 2002-05-08 07:39:17 by sluggy
You never know how future versions of the Common Controls library will behave, so IMO it's probably safer to use InitCommonControls() the way M$ wants you to use it.

Since it's something you call once, I don't see the usefulness of omitting it from execution for the purposes of size or performance, but that's just my feelings on the matter. I'm sure some of the more performance-obsessive programmers out there appreciate the info. ;)
Posted on 2002-05-08 07:51:08 by iblis
I'm with iblis - it's pretty lame not doing the InitCommonControls call.
FFS, it's something you call *once* in your program, near startup,
not exactly at a performance-critical time. Since it's a dummy call,
you're not going to waste many cycles on it... and if the call is needed
sometime in the future, well, your app will be less likely to break if
you do the call. Just like you should GetModuleHandle(NULL) instead
of using 400000h.

So, please don't follow svin's advice, at least not if you write software
that's going to be distributed - fixing other people's bugs without
having access to the sourcecode can be annoying (yay for the "geeh
the pitch is constant on our video cards so we probably don't have
to adjust for it" mentality...)
Posted on 2002-05-10 10:57:55 by f0dder
Mr. f0dder you sound pretty lame to me yourself with your HLL lyrics.
Talking in lowlevel coders forum you at least should have used words "instead of using base address"
not
instead of using 400000h


But you probably have no knowlege of it.

And don't tell me about "many clocks" - such expressions are for housewives. You've never bothered to clock the call.
It's up to others not you and not me how they use my info.
I give understanding not recepies.

You never wrote code better than your ****ing compiler, so
next time you use again "pretty lame" words I'll make you eat a humble pie after each your post, baby.:mad:
Posted on 2002-05-10 12:51:35 by The Svin
No need to turn this into personal insults, svin. I didn't say you were
lame, but I do find using hardcoded values for no good reason lame.
Especially if there's a possibility it will break on later windows versions.

Oh, and I do have knowledge about "base adress", I know why the value
0x400000 was chosen as the default base address (no, it's not arbitrarily
chosen), and I do find it unlikely that hinstance will change to something
else than base address - but there's no guarantee, and one ought to respect
"the rules" when doing windows programming. Just like preserving registers
and not trashing around randomly, doing ring0 hacks, and whatnot. We're
supposed to be over the days of incompatibility that "i am leet" (not
referring to you, but old programs that were unreasonably "selfish" in
their interaction with the machine, often without need) code has caused.

While it's not very likely InitCommonControls will ever be more than
a dummy call, *why take the risk*? The call is *one* instruction, and
(as long as it's still a dummy call), nothing but a ret. This wouldn't
be a performance hit even on a 80386.
Posted on 2002-05-10 13:17:56 by f0dder
no, it's not arbitrarily

Then you may know that you can change it with BASE option,
and you may know that most M$ progs use hard coded values as
hInstance
(no, I doubt you know:) but don't use default, most of them use
1000000h.
You might know also about bind etc. etc.
f00der, OK, I'm not going in personal war, but next time you talk about "rules" that mostly you have knowlege of reading MSDN -
make research desassemling and studing M$ code. Code of compony that talks about the rules too much but never follows them for obvious reason.
Posted on 2002-05-10 13:57:33 by The Svin
Yes, I know you can change the base with the BASE option.
There's also pretty good reasons for changing the base of
system DLLs (ie, avoid having to relocate). Just like it's
smart rebasing your DLLs so none of them clash. As for the
0x400000 value, here's a hint: it has to do with how the
page tables are organized.

Don't you think I've disassembled m$ code? Heh.

Have fun.
Posted on 2002-05-10 17:16:11 by f0dder