From: "Joe Hagen" <jdhagen AT chorus DOT net>
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.djgpp,comp.os.ms-windows.programmer.misc
Subject: Re: 16-bit Apps under Windows NT
Date: Wed, 17 Feb 1999 00:23:10 -0600
Organization: IntraNet Inc: Madison, Wisconsin's ISP
Lines: 43
Message-ID: <7adnhs$42n$1@news.itis.com>
References: <7acb6p$9fk$1 AT news0-alterdial DOT uu DOT net> <7acv11$ef0$1 AT remarQ DOT com> <7adgtb$h94$1 AT samsara0 DOT mindspring DOT com>
NNTP-Posting-Host: a13-43.itis.com
X-Newsreader: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

I've had this occur when using older 16-bit apps in NT also.

There are two things you could try:

    1.  Ensure the PATH is less than 128 characters.  You
          might want to set it to the minimum required directories
          to run your compiler in that session.
          Some 16-bit programs never assumed the path could exceed
          127, since this was the DOS command line limit.

    2.  Eliminate excess environment variables, or ensure that no single
environment
        variable exceeds 128 characters.  I recently installed a package
that
        created at least  8 new environment variables.
         When the application was executed, the entire Command Prompt
         (NTVDM.EXE) would disappear without any error messages.

         I simply created a batch file that eliminated the extra variables
(i.e):
                            SET PRODDATA=
                            SET PRODEXE=
                            SET PRODBAK=
                etc.

        The executable would then run OK.

Joe
jdhagen AT itis DOT com

>>Kelly Harrelson wrote in message <7acb6p$9fk$1 AT news0-alterdial DOT uu DOT net>...
>>>I have an *old* 16-bit cross compiler that runs under DOS and generates
>>>.OBJs for a proprietary platform.  The compiler worked fine under DOS,
>>>Windows 3.11, and Windows 95.  When we moved to Windows NT, we ran into
>>>problems.  Running it under the default shell, cmd.exe
>>>(\winnt\system32\cmd.exe), would cause the entire shell to exit,
>instantly,
>>>with no error messages or anything.  One of our developers noticed
however
>>>that it ran fine under the command.com shell