Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
yemista wrote:How do you guys handle finished programs. I know how to do it with the system call exit, but lets say someone builds a program and the main function never calls exit, just returns, how do you detect that?
If the program itself doesn't use a proper library or anything and just does "ret", then the simple answer would be: usually the program crashes.
For my OS's you'd get a page fault when the CPU tries to get the return EIP from the stack, and the kernel would handle this just like any other page fault. For other OS's it depends on the OS and where the stack is - for example, maybe there's dynamically allocated data above the stack and the CPU pops garbage into EIP, or maybe the kernel pushes data onto the stack (like command line arguments and environment strings) when starting the process and the CPU pops part of that into EIP.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
yemista wrote:How do you guys handle finished programs. I know how to do it with the system call exit, but lets say someone builds a program and the main function never calls exit, just returns, how do you detect that?
The runtime C library calls the programs entry point. Because all programs are linked with this library, when the entry point returns it simply returns back to the CRT which in turn terminates the program via the system API.
Yes, if the program actually uses the C library (think of MS-DOS .COM files here). Besides, this is sort of easy to exploit.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Yes, if the program actually uses the C library (think of MS-DOS .COM files here). Besides, this is sort of easy to exploit.
MS-DOS .COM programs are required to execute an interrupt to let the OS know to terminate it (int 0x21, funtion 0x4c IIRC.) If it does not it will probably crash. In any pmode system an exception would be generated when it crashes, the system catching the exception, displays an error and closes the program. This is possible do to .COM programs running inside of a protected envirement. If the system is rmode then I suppose if the program crashes the system itself would crash.
It does not matter what language or runtime the software relies on, if any, all application software are required to link with your system library files. Thus if a program does not link with a CRT, it does not matter so long as it links with the system library files. If it does not, it cannot be coinsidered a program written for your OS.
This is just my 2 cents.
*edit: spelling
Last edited by neon on Fri Jan 30, 2009 11:43 am, edited 2 times in total.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
neon wrote:
MS-DOS .COM programs are required to execute an interrupt to let the OS know to terminate it (int 0x21, funtion 0x4c IIRC.) If it does not it will probably crash.
not true...
in fact there are at least 4 methods (that i am aware of) for ".COM" programs to terminate
there are 3 different functions that will terminate a DOS program (int 0x20, int 0x21:0 (essentially identical), and int 0x21:0x4C), besides that, you can also RET -- for ".COM" programs RET will transfer control to the beginning of the PSP -- where it will find an int 0x20 instruction, which will terminate the program
