GNOME.org
 

Re: Possible Code to make Visual Studio compile easier

"devilsclaw" continues replying personally to me, despite me having
twice asked him to use the list instead. I won't bother with hiding
his identity (if hiding behind a nickname like "devilsclaw" can be
said to be an identity) any longer then.

And anyway, I won't bother following up to his mails any
longer. Clearly he is in a different world than I am.

Other list subscribers, feel free to follow up, if you can make sense
what he is getting at. Or not.

--tml

devilsclaw writes:

i decided to do some test and if you compile either a gui or cui app in
visual studios in debug mode they have the exact same entry point even
on the Assembly level if you compile it for release there entry points
actually do allocate the local stack.

here is a snippet from the dasm program i use for a release gui app

; int __stdcall WinMain(HINSTANCE hInstance,HINSTANCE
hPrevInstance,LPSTR lpCmdLine,int nShowCmd)
_WinMain 16 proc near

//right here are local variables that are allocated to the stack
hInstance= dword ptr  4
hPrevInstance= dword ptr  8
lpCmdLine= dword ptr  0Ch
nShowCmd= dword ptr  10h

push    0               ; uType
push    offset Caption  ; "test"
push    offset Caption  ; "test"
push    0               ; hWnd
call    ds:MessageBoxA
xor     eax, eax
retn    10h
_WinMain 16 endp

and here is a cui app in the dasm program as release

; int __cdecl main(int argc,const char **argv,const char *envp)
_main           proc near               ; CODE XREF: start+16Ep

//here is the local stack argguments for a cui app
argc            = dword ptr  0Ch
argv            = dword ptr  10h
envp            = dword ptr  14h

                push    esi
                push    edi
                mov     edi, [esp+argc]
                xor     esi, esi
                test    edi, edi
                jle     short loc_401036
                push    ebx
                mov     ebx, [esp+4+argv]
                push    ebp
                mov     ebp, ds:MessageBoxA
                jmp     short loc_401020
;
---------------------------------------------------------------------------
                align 10h

loc_401020:                             ; CODE XREF: _main+18j _main
+32j
                mov     eax, [ebx+esi*4]
                push    0
                push    offset aParameter ; "Parameter"
                push    eax
                push    0
                call    ebp
                inc     esi
                cmp     esi, edi
                jl      short loc_401020
                pop     ebp
                pop     ebx

loc_401036:                             ; CODE XREF: _main+Aj
                pop     edi
                xor     eax, eax
                pop     esi
                retn
_main           endp


as you can tell the local stacks are different. by 4bytes


so then after looking at the i tryed changing the subsystem trigger
using lordpe.

i re-dasm'd the program that was a cui and now a gui and the entry point
looks the
same as it did originally.

both WinMain and main(int argc,char* argv[]) seem to be part of a
microsoft class
since as you see in the dasm'd code main(int argc,const char
**argv,const char *envp)

i only used main(int argc,char* argv[]) and it decided to also use the
envp
and for the fact you can also just do int main();

since i did do what you told me and changed the bit and tested the
incomming input of argv and argc they did indeed still pass the same
information even when it was a subsystem of gui.

and since my dasm program showed that it still reconizes the entry point
as main and no winmain that must me it uses a patter to check to see
what it is and i guess no doubt that the operating system it self does
it also that way and then chooses what to pass to the program. which
means the there would be no stack problem. since windows is still going
to pass the appropriate variables since it can tell what the entry point
actually is.

now for the dll entry point thing i was talking about.. a while back i
tryed Dev-C++ and i compiled a dll that i used in varias things for
testing for cheats in a game that does not have a builtin anti cheat
software. i also have other dlls that i inject into programs to check to
see what trainers are doing to the game so i can add those addresses to
the protected range.

when the dll is injected in the entry point i have code that needs to be
executed when the dll is loaded and no matter what i tryed the code
would never get executed.

sure i could make the a export that calls on the code i want executed
but that is a much bigger pain in the but and also is not always
something i want done since once the dll is loaded the program loads
other dlls that have proper entry points that could be dlls that are
doing the cheating and since i would have to call on the api to activate
it the other dll might already be loaded by then it might be to late to
check on what i need to check on. 

so back then i dasm'd the entry point and it used it own entry point
other then the default entry point used by visual studios and it wrapped
around the msvcrt dll and it just did not act correctly. i did say they
was a while ago a but a year i guess i could try gnu again to see if it
was corrected.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]