Re: Interesting

It seems you know a lot more about the EXE than I do. Steering clear of that area for the most part, here's a few C-related responses.


>FileName = otherLocation
I wasn't aware that that was possible. I was under the impression from:
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/1.4.html
that that is illegal.

Nice catch! I was thinking FileName was a wchar_t*. Silly me.


>I expect that the other WriteConsoleW functions don't work, though. Do they?
Actually, they do...

I'm stumped on this one. I would've thought they would print out garbage data.


The WriteConsoleW calls seem to work correctly with and without the &. It seems to me that one or the other shouldn't work, but they both seem to.

The definition of WriteConsole is:
BOOL WINAPI WriteConsole(
__in HANDLE hConsoleOutput,
__in const VOID *lpBuffer,
__in DWORD nNumberOfCharsToWrite,
__out LPDWORD lpNumberOfCharsWritten,
__reserved LPVOID lpReserved
);

It's easy to cast wchar_t* or wchar_t** to a void* implicitly (without the (void*) part). That's why neither way gives an error.


Re: EXEs

I was thinking that most OSs separate the executing code from the data for security purposes, which is the assumption from which I deduced my conjectures. I get a segfault when I try to write to memory where the code is located.

You seem to know a lot more about the low-level EXE parts than I do. Most of what I know came from observations when debugging.

I do know that both the compiler I use now (gcc) and the one I used previously (MSVC++) used dynamic allocation of variables, for the most part. A variable is allocated, then pushed onto the stack. Then, it is referenced via ESP (hehe). I scanned the standard for C++ that I have, but I didn't find anything requiring that variables be allocated a specific way.


...

This is an interesting topic. I may do a few experiments with C memory once I don't feel under-the-weather. It might turn up a few things. Any suggestions for what to look for?