mark@adec23.UUCP (Mark Salyzyn) (05/24/88)
In CONFIG.SYS:
SHELL=HELLO.EXE
In HELLO.C:
main ()
{
for (;;)
cprintf ("Hello World\r\n") ;
}
cprintf is a console only printf (yes I tried printf with similar results.)
I tried replacing cprintf with:
cprintf (cp)
register char *cp ;
{
while (*cp)
bdos (6, *(cp++)) ;
}
The machine just stops after initial setup with a cursor on Left Top Corner,
no activity, but rebootable. Control C does exite a `^C' on screen, but thats
it.
I want to replace command.com with my own simple menu driver to save floppy
disk space for a turnkey application. I assume some initialization that my
MSC compiler (version 3.0 here) is not getting performed and some runtime
library routine is STOPPED UP, and/or some vector must be trapped? Am i missing
something (of course I am). I assume that if it is a runtime routine, 4.0 and
up probably have solved the problem?
After that question is solved, what about the trapping of 0x22, 0x23 and 0x24?
Thanks in advance, post if small, mail if long.
-- Stamp out long .sigs
alberta!{teletron,uofaee}!adec23!mark Mark Salyzyndhesi@bsu-cs.UUCP (Rahul Dhesi) (05/26/88)
In article <1284@adec23.UUCP> mark@adec23.UUCP (Mark Salyzyn) writes: >In CONFIG.SYS: > SHELL=HELLO.EXE This is not guaranteed to work. Some versions of MSDOS cannot load an EXE format file unless Microsoft's COMMAND.COM is resident and has trapped a software interrupt. Try converting your program to COM format, or write a small COM format shell that contains its own EXE relocation code and invokes your bigger shell by loading it into memory and performing relocation. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
rargyle@wsccs.UUCP (Bob Argyle) (05/29/88)
In article <1284@adec23.UUCP>, mark@adec23.UUCP (Mark Salyzyn) writes: [sample of C code deleted] > I want to replace command.com with my own simple menu driver to save floppy > disk space for a turnkey application. I assume some initialization that my > MSC compiler (version 3.0 here) is not getting performed and some runtime > library routine is STOPPED UP, and/or some vector must be trapped? Am i missing > something (of course I am). I assume that if it is a runtime routine, 4.0 and > up probably have solved the problem? ... > Thanks in advance, post if small, mail if long. > > -- Stamp out long .sigs > alberta!{teletron,uofaee}!adec23!mark Mark Salyzyn If your compiler produces .COM files by default, it is probably broken. Find out if you can get you compiler to give a .COM (or .ASM to turn into .COM [shudder] via changing the asseembly and EXE2BINing it. Least mindboggling is to write a short program that will just load your .EXE file for you and have THAT.COM be your 'interpreter'. Bob @ WSCCS
guardian@otishq.UUCP (Harry Skelton) (06/03/88)
In article <559@wsccs.UUCP>, rargyle@wsccs.UUCP (Bob Argyle) writes: >If your compiler produces .COM files by default, it is probably broken. Some do make a .com under certain conditions. >Least mindboggling is to write a short program that will just load your .EXE >file for you and have THAT.COM be your 'interpreter'. Have you tried the SHELL= in /config.sys ?? >Bob @ WSCCS Harry Skelton
egs@killer.UUCP (Eric Schnoebelen) (06/04/88)
A while back I wrote a replacement shell for our Systems. I found that MS/PC- DOS 3.1 and above would load a .EXE as a shell ( ie. the loader / relocator is actually in the OS where it belongs ). Other things to be wary of: DOS does not pass a valid enviroment pointer to the shell program. You Must allocate your own environment. You Must also replace the critical error Handler. Other than that ( if I remember correctly ) you can do anything you want. I wrote mine in turboC, and it came out to be about 30K. It was a menu driven front end to tie all of our applications together. Eric Schnoebelen John W. Bridge & Associates, Inc killer!u-word!egs ( by the way, I bought a copy of the MS-DOS encyl. during this adventure, and found it to be almost no help.. for this problem ) #include <stddisclaimer>