Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!stan!imp
From: imp@Solbourne.COM (Warner Losh)
Newsgroups: comp.os.msdos.programmer
Subject: Re: TCC -S then using TASM and TLINK
Message-ID: <1991Feb7.194555.1080@Solbourne.COM>
Date: 7 Feb 91 19:45:55 GMT
References: <2481@bnlux0.bnl.gov> <1991Feb7.074923.1299@Solbourne.COM> <26755@uflorida.cis.ufl.EDU>
Organization: Solbourne Computer, Inc., Longmont, CO
Lines: 42

In article <26755@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes:
>However, when I did the EXACT same routine as I listed above, I had no
>errors whatsoever.  But it won't work.  It locks the machine up.  Is there
>ANY reason that doing what I did with OFF.COM would not work with
>NMORE.COM?  Here are the specifics:

Does NMORE.C look something like:

int main (int argc, char **argv)
{
	if (argc == 1)
		more(NULL);
	else {
		while (--argc)
			more(*++argv);
	}
}

void more(char *fn)
{
...
}

If so, then you *MUST* link in C0.OBJ for your particular memory
model.  This module gets executed first and will set up things like
argc, argv, sets up global variables (eg _psp, _stklen, etc),  allows
signal handlers to work, etc.  If you are getting program sizes of 37
bytes, then there is no way you could be loading in this module as it
is about 1-2K (I'm not on my Rainbow right now, so I can't check for
sure).  If you don't link it in, then argc, argv, etc, won't be
pointing to anyplace meaningful, so when you go to access then, you
will more than likely be pointing to something off in cloud coocoo
land.  Also, if argc happens to be large, and your code looks like the
above code, it may take a while to try to open 20,000 files.

Warner

P.S.  It would help people answer your question if you *gasp* actually
posted the source to the program you are having problems with. :-)
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.