Discussion:
[Freedos-kernel] Can the Kernel start my program instead of command.com?
David Kay
2016-12-09 09:07:24 UTC
Permalink
Hello,

I've written a program in Free Pascal targeting GO32V2. It is for an
embedded PC104 system. The I/O is digital / analogue all using ports and
Ethernet using R6040PD packet driver. Currently my program just starts in
autoexec.bat. My program loads the packet driver using dos.exec. It enters
an infinite loop and nothing else gets to run after this...

Is it possible to get the kernel to load my program directly instead of via
autoexec.bat? Then my system would just be composed of the kernel and my
program?



--
View this message in context: http://freedos.10956.n7.nabble.com/Can-the-Kernel-start-my-program-instead-of-command-com-tp25676.html
Sent from the FreeDOS - Kernel mailing list archive at Nabble.com.
David Kay
2016-12-09 09:24:50 UTC
Permalink
Currently the program uses a separate DPMI host. But I believe I can prepend
my program with a DPMI host so that it starts directly in real mode?

Would renaming this executable to command.com enable the kernel to load it
directly?



--
View this message in context: http://freedos.10956.n7.nabble.com/Can-the-Kernel-start-my-program-instead-of-command-com-tp25676p25677.html
Sent from the FreeDOS - Kernel mailing list archive at Nabble.com.
Mateusz Viste
2016-12-09 12:03:10 UTC
Permalink
Post by David Kay
Is it possible to get the kernel to load my program directly instead of
via autoexec.bat? Then my system would just be composed of the kernel
and my program?
Have you tried to declare your program in CONFIG.SYS using the SHELL=
directive ? Seems like an easy test that would provide you with the
answer you look for. Renaming your program to COMMAND.COM is also a
possible test, albeit perhaps less elegant. I wouldn't expect troubles,
but as usual, testing it out is the only way to be sure.

cheers,
Mateusz
David Kay
2016-12-09 11:51:52 UTC
Permalink
Thanks! It looks like the shell directive does exactly what I want. It
defines what the kernel loads as the command processor. I'm in a funny
situation where I only have just over 6 months total experience with DOS,
and yet I'm writing DOS software for machinery which is 200 miles away...
Not ideal, but it is what it is.
From the point of view of protecting this system from counterfeiting &
unauthorised access, is it possible to interrupt processing config.sys? I
had read about pressing F5 to bypass config.sys and autoexec.bat. Also that
this can be disabled in config.sys. That seemed like a chicken and egg
situation to me - disabling processing of config.sys by executing config.sys
? What if F5 is pressed before config.sys is loaded? The system doesn't have
a keyboard plugged in, but it's not impossible to plug one in if you're
interested in poking around the system. However, if I completely removed
command.com and all other commands then the kernel wouldn't be able to load
anything.

Another thought I have - what would the behaviour of the kernel be if my
program (as the command processor) does terminate? Does it reboot, restart
the command processor, or just hang?



--
View this message in context: http://freedos.10956.n7.nabble.com/Can-the-Kernel-start-my-program-instead-of-command-com-tp25676p25679.html
Sent from the FreeDOS - Kernel mailing list archive at Nabble.com.
Tom Ehlert
2016-12-09 13:50:31 UTC
Permalink
Post by David Kay
From the point of view of protecting this system from counterfeiting &
unauthorised access, is it possible to interrupt processing config.sys? I
had read about pressing F5 to bypass config.sys and autoexec.bat. Also that
this can be disabled in config.sys.
modify kernel.sys by using

sys config kernel.sys SKIPCONFIGSECONDS=-1

to disable F5/F8 completely.

OTOH, removing command.com will also completely disable tinkering with
the system.
Post by David Kay
Another thought I have - what would the behaviour of the kernel be if my
program (as the command processor) does terminate? Does it reboot, restart
the command processor, or just hang?
most likely just hang. test yourself.

Tom

Loading...