VC++ 1.52; problems with argc, **argv

I am on Windows NT4.0, but forced to use VC++ 1.52 for an application which uses 16 bit database access programs.  I am attempting to process a list of stock ticker symbols.  When I try this in VC++ 4.0 I can access at least 700 symbols.  When I do it in VC++ 1.52 I can only access 30.  If I try to access more than 30, the program crashes.  It doesn't even get to the line that prints argc-1.

I have never run into this before and I am at a loss as to what is causing it, although I suspect it might have somethng to do with the libraries that are being selected by the project builder.

Here is the simple program I am using for testing:

/*
      sample.cpp
      
      These examples will demonstrate how to use the
      Quotes Plus dll to read all of the price and
      fundamental data that we have.

      The functions automatically open all of the Quote
      Plus files when called, and close the files on exit.

*/

#include <stdio.h>
#include <string.h>


FILE *fp;

void main(int argc, char **argv)
{
      #define LEN 9
      char out[] = "C:\\tmp\\n.p";
      char sym[LEN];
      int i;

      printf ("The number of arguments is %d.\n", argc-1);

      fp = fopen( out, "w" );
      if ( !fp ) {
            printf ("Could not open %s.\n", out);
            return;      // Could not open it.
      } else printf ("Opening %s for writing.\n", out);

      printf ("The output file is %s.\n", out);
 

      while (--argc > 0) {

            strcpy(sym, *++argv);
            i = strlen(sym);
            while (++i < LEN)
                  sym[i] = ' ';
            sym[LEN] = '\0';

            fprintf (fp, "%s\n", sym);
      }

      fclose( fp );

}

Here are the library definitions from the makefile generated by the project builder for this test, except that I replaced mlibcew with mlibcewq in order to access printf:

CFLAGS_D_WEXE = /nologo /W3 /FR /G2 /Zi /D_DEBUG /Od /AM
      /GA /Fd"SAMPLE.PDB"
CFLAGS_R_WEXE = /nologo /W3 /FR /O1 /DNDEBUG /AM /GA
LFLAGS_D_WEXE = /NOLOGO /NOD /PACKC:61440 /STACK:1024
      /ALIGN:16 /ONERROR:NOEXE /CO  
LFLAGS_R_WEXE = /NOLOGO /NOD /PACKC:61440 /STACK:10240
      /ALIGN:16 /ONERROR:NOEXE  
LIBS_D_WEXE = mafxcwd oldnames libw mlibcewq commdlg.lib
      olecli.lib olesvr.lib shell.lib
LIBS_R_WEXE = mafxcw oldnames libw mlibcewq commdlg.lib
      olecli.lib olesvr.lib shell.lib
RCFLAGS = /nologo
RESFLAGS = /nologo

Here are the library definitions from the original program where I first encountered this problem:

CFLAGS_D_WTTY = /nologo /G2 /Zp1 /Mq /W3 /Zi /AL /Od /D
      "_DEBUG" /FR /Fd"SAMPLE.PDB"
CFLAGS_R_WTTY = /nologo /Gs /G2 /Mq /W3 /AM /Ox /D "NDEBUG"
      /FR
LFLAGS_D_WTTY = /NOLOGO /NOD /PACKC:57344 /ALIGN:16
      /ONERROR:NOEXE /CO
LFLAGS_R_WTTY = /NOLOGO /NOD /PACKC:57344 /ALIGN:16
      /ONERROR:NOEXE
LIBS_D_WTTY = lafxcwd llibcewq read11dl.lib oldnames libw
LIBS_R_WTTY = mafxcw mlibcewq oldnames libw read11dl.lib
RCFLAGS = /nologo
RESFLAGS = /nologo

Note that the original makefile was provided by the vendor and maintained unchanged, while the test makefile was built by the project builder and the only change was to replace mlibcew with mlibcewq.  For some reason the project builder assigns mlibcew but mlibcew does not have printf.  I don't understand that either.

If anybody can tell me why this program croaks at the 31st input arg, I would greatly appreciate it.

Bob
rbpAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jhanceCommented:
This is not a VC1.52 vs. 4.0 issue, it's Windows NT vs. MSDOS (i.e. 16-bit environment).  Under MSDOS you can only have a command line of a certain lengthm and I believe that it's 256 or less.  If you go beyond that, the buffer where the command line is stored runs into some other data structures and boom, your program dies.  NT doesn't have this problem.  I'd suggest feeding this quantity of data into your program via another method if you must run on 16-bit Windows.  Write it to a file and have your program read the file.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.