Avoiding _memset? [Visual C]

Prev: Blog: Tools for C++ Static Analysis
Next: 175528 M3i Zero , Ezflash Dsi , R4i Dsi 28486

From: Vincent Fatica on 8 Sep 2009 02:20

Thanks for the ExitProcess tip.

__stdcall/WINAPI is not mentioned in crtexe.c. Aren't they all __cdecl?

static
int
__tmainCRTStartup(
void
);

#ifdef _WINMAIN_

#ifdef WPRFLAG
int wWinMainCRTStartup(
#else /* WPRFLAG */
int WinMainCRTStartup(
#endif /* WPRFLAG */

#else /* _WINMAIN_ */

#ifdef WPRFLAG
int wmainCRTStartup(
#else /* WPRFLAG */
int mainCRTStartup(
#endif /* WPRFLAG */

#endif /* _WINMAIN_ */
void
)
{

On Tue, 8 Sep 2009 13:29:35 +0800, "xiaosi" <xiaosi(a)cn99.com> wrote:

|Besides call convention, ExitProcess should be used instead of return, because both tmainCRTStartup and tWinMainCRTStartup call
|kernel32!ExitProcess(status) after tmain or tWinMain return status.
|
|If you use Common Dialog Box in your app, and return (instead of ExitProcess) to exit app, the process will not exit (the thread of
|Common Dialog Box is still existing).
|
|#pragma comment(linker, "/subsystem:windows")
|#pragma comment(linker, "/entry:mywinmain")
|int __stdcall mywinmain() {
| ....
| ExitProcess(msg.wParam);
|}
|
|#pragma comment(linker, "/subsystem:console")
|#pragma comment(linker, "/entry:mymain")
|int __cdecl mymain() {
| ....
| ExitProcess(status);
|}
|
|"Vincent Fatica" <vince(a)blackholespam.net> wrote:
|> On Mon, 7 Sep 2009 21:44:17 +0300, "Alex Blekhman" <tkfx.REMOVE(a)yahoo.com>
|> wrote:
|>
|> |Even if you use a custom entry point it is still must conform to
|> |the expected signature of [w]WinMain or [w]main. Also, calling
|> |convention must be __stdcall for Windows subsystem and __cdecl for
|> |console subsystem.
|>
|> To avoid the RTL I often use a custom entry point and I often violate the
|> conventions you mentioned. I haven't gotten into trouble yet. Please
|> elaborate.
|> --
|> - Vince
--
- Vince

From: Vincent Fatica on 8 Sep 2009 02:22

From: Alex Blekhman on 8 Sep 2009 04:18

"Vincent Fatica" wrote:
> If you look at the CRT startup routines (the typical entry
> points, crtexe.c) for EXEs, you see that they are __cdecl,
> taking, no args and returning an int. They examine a command
> line, do their thing, and eventually call main, wmain, or
> WinMain. So the signatures of main, wmain, and WinMain are very
> important. But if you're not using the CRT startup routines and
> you are specifying an entry point, it would seem that int
> __cdecl ...(void) is appropriate.

I found the requirements here:

"/ENTRY (Entry-Point Symbol)"
http://msdn.microsoft.com/en-us/library/f9t8842e.aspx

<quote>
The function must be defined with the __stdcall calling
convention. The parameters and return value must be defined as
documented in the Win32 API for WinMain (for an .exe file) or
DllEntryPoint (for a DLL).
</quote>

However, after reading your answer I looked into crtexe.c file I
discovered that CRT startup routines don't respect this
requirement, exactly as you noticed. Moreover, BaseProcessStart
routine from kernel32.dll doesn't care neither about parameters
nor calling convention. The call looks like this:

call dword ptr [ebp+8]
push eax
call _ExitThread@4

Where "dword ptr [ebp+8]" is the address of the process entry
point. The process entry point address is passed as a parameter to
BaseProcessStart, as well.

So, actually the linker documentation is incorrect and one must
use int __cdecl(*)(void) function as a custom entry point. It is
only by sheer luck BaseProcessStart and subsequent code don't
change anything on stack, so there is no access violation
exception.

I would be very interested in hearing from MSFT people about the
issue.

Alex

From: Alex Blekhman on 8 Sep 2009 04:22

"xiaosi" wrote:
> Besides call convention, ExitProcess should be used instead of
> return, because both tmainCRTStartup and tWinMainCRTStartup call
> kernel32!ExitProcess(status) after tmain or tWinMain return
> status.

This is incorrect. tmainCRTStartup and tWinMainCRTStartup call
ExitProcess only if there is an exception thrown from
main/WinMain. Otherwise, both CRT startup routines just return.
kernel32!BaseProcessStart routine calls ExitThread, which in its
turn calls ExitProcess.

Alex

From: Alex Blekhman on 8 Sep 2009 04:31

"Vincent Fatica" wrote:
> How do I ensure my app get them from ntdll.dll and not try to
> get them from the CRT lib?

You can re-create an import lib for ntdll.dll and link with it:

KB131313 - "How To Create 32-bit Import Libraries Without .OBJs or
Source"
http://support.microsoft.com/kb/131313

HTH
Alex

First | Prev | Next | Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: Blog: Tools for C++ Static Analysis
Next: 175528 M3i Zero , Ezflash Dsi , R4i Dsi 28486