I understand that Exec, Chain and Run in the DOS build of FBC will expect a regular DOS executable file (usually, a real mode program) and that the program may happen to use DPMI, in which case, it will re-enter protected mode while running as a child, then upon exit, go back to real mode, giving control back to the parent program, which will return to protected mode until it finishes. So first question is.... Is there a way can run a child process that I know will be 32bit protected mode without having to go through real mode?
Also, I know that I can use DPMI calls in my programs to set and get real mode interrupt vectors, which real mode child programs could use. My second question is... (How) Can I set a protected mode interrupt vector so that, upon calling a child process, that program can invoke the code I place in the interrupt, in protected mode?
Finally, if I do set up a protected mode interrupt vector, can I point it to a function I make if FB, so that I effectively "share" that function with the child process? If all this is not possible, I'd be interested in any strategy to achieve the same goal in DOS. Thanks! :)
Executing a child 32bit DOS program and sharing a function
Re: Executing a child 32bit DOS program and sharing a function
You could perhaps run
There are many options available, and of course, these commands are all pure dos.
Code: Select all
shell "help start"
Re: Executing a child 32bit DOS program and sharing a function
Uhm... I can see that FreeDOS does have a Start command, but it looks like it doesn't have a help page. When I type start /?, it just says it executes FreeDOS programs and it has one modifier to wait till the program ends. Researching, I found that this command also exists in Windows, but not in pure MS-DOS, apparently. Anyway, if I wanted to run a program by running Shell "start program.exe", this would load COMMAND.COM (a real-mode program) into conventional memory and then COMMAND.COM would have to run the program (basically the same as Run Environ("COMSPEC") & " /C start program.exe"), so I would not escape from going through real mode. :S
Re: Executing a child 32bit DOS program and sharing a function
Moreover, at least in win9x, start is also a binary, not a built in afaik?
If there is a way, it is through the extender, and probably only for programs with the same extender. At least till dos gets proper 32-bit apis of itself.
If there is a way, it is through the extender, and probably only for programs with the same extender. At least till dos gets proper 32-bit apis of itself.
Re: Executing a child 32bit DOS program and sharing a function
In Windows 95 there was a "start.com" executable IIRC, but it probably won't help with this problem.marcov wrote:Moreover, at least in win9x, start is also a binary, not a built in afaik?
Re: Executing a child 32bit DOS program and sharing a function
Yeah, I probably won't be able to avoid the switching while the format being used is simple MZ executable :S How about pointing my FB functions with 32 bit protected mode interrupts? Can I do that? If so, I figure I could easily create my own protected mode executable format.
Re: Executing a child 32bit DOS program and sharing a function
I've never tried this, but I guess you would use DPMI function $0205 Set PM Interrupt Vector. And it seems that you can determine the address of an FB subroutine by using the syntax @SubName (as seen in FBWiki page for ThreadCreate). Then use inline assembly to put an iret instruction at the end of the routine?
Re: Executing a child 32bit DOS program and sharing a function
Thanks! I'll try that. My expectation, though, is that this might work if I call from within the same program, but if I try to execute another program with Exec, for example, protected mode interrupts will be disabled upon switching back to real mode and the child process won't be able to call the function. Yet, I guess I could solve that by creating my own executable format, reserving executable protected memory (I don't know how under a DPMI) and loading the code there. Now, this means I wouldn't be able to compile that code in FreeBasic :(