Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

C's system() & COMMAND.COM (Developers)

posted by alexfru, USA, 11.09.2014, 21:26

I've started a thread on comp.os.msdos.programmer, but posting it here to widen the audience.

I'm implementing system() in the DOS version of my compiler's (Smaller C) standard C library and having a bit of a dilemma.

It appears that if I build system("command") around "%COMSPEC% /C command", neither the "execute" function 0x4b00 nor the "get exit code" function 0x4d does return the exit code from "command" if "command" resolves to a .COM/.EXE executable. Looks like I'm getting success exit code of 0 from COMMAND.COM itself.

This is unfortunate since I can't easily detect errors in child processes based on their exit code.

I can think of a few pretty nasty workarounds.

1. Do COMMAND.COM's job and find the full path of the .COM/.EXE and execute it directly without involving "COMMAND.COM /C". The problem here is that even though I can traverse %PATH% and find the executable, if it's there, I need to know that the command is not one of COMMAND.COM's internal commands and the set of command processor's commands varies between DOS versions and vendors and DOS emulators (e.g. DosBox). I don't want to incorporate substantial knowledge about different DOS versions into the library. I don't feel it's the right way to do things.

2. Hook int 0x20 and int 0x21's function 0x4c that are used to terminate executables and note terminations and stash away the exit codes (from function 0x4c only as int 0x20 doesn't take any exit code). If I ignore the last one (from COMMAND.COM), then the next one is from my executable. But again, what if the command resolves to a batch file, which in turn invokes a .COM/.EXE? In that case occasionally I'm going to get the exit code that has nothing to do with batch file execution. Further, I may run into trouble hooking DOS interrupts. Either DOS may not appreciate it or some ancient anti-virus may block such suspicious activity.

I could probably devise a more intrusive workaround, but it might result in incompatibilities with various DOSes and be even more fragile.

Any suggestions, ideas?

Thanks,
Alex

 

Complete thread:

Back to the forum
Board view  Mix view
22378 Postings in 2074 Threads, 400 registered users, 115 users online (0 registered, 115 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum