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:
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.
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?
|Response Title||Author and Date|
|Re: Interesting||on Sep 16|