How to run an EXE-file from within the CONFIG.SYS ?
G.M. Loose, LC 53, tel. (070-33)23538
file as the very first action taken when the CONFIG.SYS file is executed at
boot-up time (at least definitely before MS-DOS creates its buffers by the
BUFFERS= command).
- Is there a way to do this, other than writing a device driver or digging deep
into assembly language.
For example: do you know if there exists a tool to transform an ordinary
*.EXE file into a device driver or shell?
Note: the compiled program is NOT a device driver, neither a TSR program,
but an ordinary executable program.
Your replies will be appreciated.
Marcel Loose, Email: G.M....@research.ptt.nl
PTT Research,
Leidschendam,
Netherlands
Jen Kilmer
>I have the following problem. I want to run a compiled program (*.EXE or *.COM)
>file as the very first action taken when the CONFIG.SYS file is executed at
>boot-up time
In version 5 or later, no can do. DOS= is first.
>(at least definitely before MS-DOS creates its buffers by the
>BUFFERS= command).
If it's a device driver loaded using device= AND the device= comes before
BUFFERS=, can do. Note, tho, that MSDOS is using temporary buffers at that
point (and a temp file table, etc). MSDOS.SYS has been initialized, tho
it's not in its final memory location.
>Note: the compiled program is NOT a device driver, neither a TSR program,
> but an ordinary executable program.
...which could be run (MSDOS 4.0 or later) using install=, but install=s
are processed after all other commands (right before spawning the shell).
-jen
--
#include <stdisclaimer> // je...@microsoft.com // ...just testing...
G.M. Loose, LC 53, tel. (070-33)23538
Well, I'm back again.
First of all, I would like to thank everyone who gave any suggestions to solve
my problem. I received some useful answers. Furthermore, I learned some things
that can be useful to others as well. So, here it comes.
1. The first tip I received was to use the INSTALL= command to run the program.
This works fine, if you keep one thing in mind. Make your executable
Terminate and Stay Resident (TSR), otherwise you will get the error message
"Error in CONFIG.SYS line <nn>".
The next thing to check, at least for me, was if DOS performes the INSTALL=
commands before or after it creates its buffers through the BUFFERS= command.
Unfortunately for me, I found out that DOS creates its buffers **before**
it installs any TSR-programs.
An example to clarify things. Suppose you have a CONFIG.SYS that looks like
this:
BUFFERS=30 {1}
DEVICE=C:\DOS\SETVER.EXE {2}
INSTALL=C:\MYPROG.EXE {3}
DEVICE=C:\DOS\HIMEM.EXE {4}
In which order will DOS execute these command lines?
Well, DOS first loads every device driver that is specified in the
CONFIG.SYS **in order of appearance**, then DOS creates its buffers, and
finally DOS installs any TSR programs.
So, the order in which these command lines are executed is:
{2}, {4}, {1}, {3}.
2. The next tip I received offered an elegant solutions for my problem, it
seemed to me.
Among the many system utilities available through SIMTEL
(directory: pub/msdos/sysutl) is the program WRAPPER (archived as
WRAP10.ZIP). This program can be loaded as a device driver and can take as
its arguments the name of an executable program (for example MYPROG.EXE).
As I explained above, DOS first loads every device driver specified in the
CONFIG.SYS, before it creates its buffers. And indeed, the executable that
you specify as argument to WRAPPER is executed as soon as you want it to
(it could be the first command in your CONFIG.SYS).
I think WRAPPER can help you out in 99% of all cases. Unfortunately for me,
I designed a program that falls into the 1% category. Let me describe what
goes wrong when I run say MYPROG.EXE.
First, I will shortly describe what MYPROG does:
The PC I work on has a WORM optical disk drive connected to it.
Because a WORM disk has a large storage capacity and because DOS
(versions prior to 5.0) cannot address more than 65535 logical sectors,
the driver's software has to perform a **nasty** little trick. It
modifies the size of the DOS logical sector size, that is defined in the
system file IBMDOS.COM, from 128 bytes to 6144 bytes. It does so by
**modifying** this system file.
Problems arise when you define more than 10 buffers through the BUFFERS=
statement in your CONFIG.SYS file. Why this happens, I don't know, but it
has probably something to do with breaking a magical 64k boundary.
So, I worked out the following solution:
* I installed a menu oriented startup procedure (programs that allow
multiple CONFIG.SYS and AUTOEXEC.BAT files are available in all kinds
of flavors on SIMTEL as well).
* I created a program that compares the current configuration (i.e.
logical sector size definition) with the preferred configuration (as
defined by the menu choice at boot-up time). I keep the current
configuration recorded in a small configuration file, that is placed
in the root directory of the boot-disk.
When the current and preferred configurations match, no action has to
be taken. On the other hand, if the preferred configuration is
different from the current one, the WORM preparation program has to be
called, in order to modify the IBMDOS.COM file to the current needs.
Of course, in order for these changes to become active, the machine has
to be rebooted; this action is taken by the preparation program as well.
So, the program MYPROG I worked out has the following structure.
* Compare the current configuration with the preferred one (i.e. check
the contents of the configuration file with the selected menu item)
* IF configurations are different
THEN
* Change the configuration file (to reflect the changes to be made
shortly afterwards).
* Call the WORM preparation program (which performs a cold reboot
after it made the necessary modifications to the file IBMDOS.COM).
ENDIF
Now, there is one little problem with this solution:
When I start the progam MYPROG from the DOS prompt, it works properly;
the configuration file in the root directory is updated and closed before
the machine is rebooted. On the other hand, when MYPROG is started from
within the CONFIG.SYS (by the use of WRAPPER.SYS), the configuration
file is not properly closed and thus contains no data.
This problem has, in my opinion, two possible causes:
1. It is a flaw in the program WRAPPER.SYS;
2. DOS does not allow any files to be written to from within the
CONFIG.SYS.
I consider the 2nd possible cause less likely. If DOS would not allow any
disk writes to take places during the execution of CONFIG.SYS, why would
DOS allow the recreation of the file? (The file IS being recreated,
because it is empty after reboot and it previously contained the
configuration data).
After this long and elaborate `introduction', I will pose my question.
******************************************************************************
*** Do you know a solution to the problem I just described above? ***
*** I do not especially need to use the WRAPPER.SYS program. Any other ***
*** tool that allows me to run MYPROG before DOS creates its buffers ***
*** will suffice as well. Or, maybe you can think of a solution, where ***
*** I don't need to record the configuration of the system into a ***
*** separate configuration file. (Of course I could check the file ***
*** IBMDOS.COM itself, but I consider that solution far less elegant, ***
*** because the bytes to check will probably be different for different ***
*** DOS versions). ***
******************************************************************************
Your replies will be appreciated,
------------------------------------------------------------------------------
Marcel Loose. | Would there be a life for me,
G.M....@research.ptt.nl | without coffee and a PC?
------------------------------------------------------------------------------
Philippe Lebrun
|> Problems arise when you define more than 10 buffers through the BUFFERS
This may be a little simple minded, but why do you need more than 10 buffers
open? My understanding is that DOS uses them to buffer disk reads. If you
have a disk cache, it fulfills a good part of this function, so you only
need about 4 buffers.
I use a little programme called Thrasher to evaluate the number of buffers
the computer needs to have open for optimal performance. It was called
thrash.zip on BIX about 3 years ago.
-philippe