If my understanding of double pointers is correct, this should work.

But I get a message saying my program quit working, could you correct the above code snippet please?(I have an exit point, so it's not that it's seg faulting) Also, do I need to remove the return location AND the parameters or just the parameters from the stack?

Shall I move this to the Linux forum?

Sure, I don't care, but I'm doing it on Windows so it's pretty universal. Isn't that the idea of libc?

I will leave it here if you prefer, but I suspect that not many people use libc in Windows. I just think that the Linux users could help you better if it was put there.

I respect your opinion, move it if you see it necessary/helpful. You're probably right that most Windows programmers don't use libc, I do it because I hate programming with Win32 API and I do use Linux(so I guess you're right ) some times.

P.S. Wouldn't it have been easier to just answer my question?

Yes it would have. And if I had known the answer I would have posted it.

If it helps, printf expects a char* and argv is a char**. The first pop is getting char**argv off the stack, then I get int argc, and that's all I'm sure about .

Well, so far, I've come to the conclusion I'm going to have to use the WIN32 API. The only examples I can find use GetCommandLine. Any example of how to get argc/v in a portable way would be greatly appreciated.

The only reliable way in win32 to obtain the arguments is by using the API function Kernel32.GetCommandLine.
If you want to obtain it through undocumented stuff, you could do something like that (only for testing purposes):
Disclaimer: this snippet is not portable at all, even if it works for you. Microsoft could change that structure any time in any future windows release.

Yeah, I decided to just make a different main file for Win32 and Linux, with the os specific code in the main files and the portable code in an include.

Cool to have such knowledge though. Seems like an obscure fact, where did you read it? Not that I don't believe you, it's just that such a place would be good for further research on the topic.

It's not obscure, just not documented. At any program startup, the memory is loaded with some data that is going to be used by the Windows API. Those structures are mainly arrays of dwords pointing to functions (ntdll.dll undocumented functions) and strings with environment settings.
The documented API functions are wrappers, i.e. make use of those calls in order to provide the desired functionality without changing the interface. In other words, win32 API calls don't change but the kernel undocumented functions are free to Microsoft to change, optimize and so on without further notice.
Many of those kernel functions are "documented" on the internet but you should be aware that if your program uses them, it could stop working properly in a succesive windows version.

I became interested on this subject many years ago because some Microsoft competitors argumented that the access to those undocumented functions provide an uncompetitive edge to Microsoft own programs. From my own experience, there is little overhead by using the documented API functions so there is no need to the burden of work of not using them.

And I thought I was cool for trying to run EVERY program in system32 . Did you know there's a wizard for creating self extracting cabs(I've used it).

I'll do some research on those functions though, sound really interesting. Thanks for the info.