"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) > [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] 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. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
