I compiled this program two hours ago using a bat file--compile and link.
Now when I try it from the IDDE (?), the development environment, I get the
following messages on the first file (there are 10 in all.)
What have I set wrong? or left unset? Also, why does it use sc instead of
dmc. Is there no difference? And why fgetwc, fgetws, fputwc, fputws;
character type is set to single byte?

sc
init_div.cpp -Ae -mx -o+time -3 -a4 -c -I\dm\stlport\stlport -oinit_div.obj
Error: \dm\stlport\stlport\cwchar(199): undefined identifier 'fgetwc'
Error: \dm\stlport\stlport\cwchar(200): undefined identifier 'fgetws'
Error: \dm\stlport\stlport\cwchar(201): undefined identifier 'fputwc'
Error: \dm\stlport\stlport\cwchar(202): undefined identifier 'fputws'
Fatal Error: \dm\stlport\stlport\cwchar(210): too many errors
Lines Processed: 3776  Errors: 5  Warnings: 0
Build failed

Apparently, you have the x memory model set. Try the n memory model (win32).

"James W. Jennnings" <jwjenn@mindspring.com> wrote in message news:b342eb$dqg$1@digitaldaemon.com...
> I compiled this program two hours ago using a bat file--compile and link. Now when I try it from the IDDE (?), the development environment, I get
the
> following messages on the first file (there are 10 in all.)
> What have I set wrong? or left unset? Also, why does it use sc instead of
> dmc. Is there no difference? And why fgetwc, fgetws, fputwc, fputws;
> character type is set to single byte?
>
> sc
>
init_div.cpp -Ae -mx -o+time -3 -a4 -c -I\dm\stlport\stlport -oinit_div.obj
> Error: \dm\stlport\stlport\cwchar(199): undefined identifier 'fgetwc'
> Error: \dm\stlport\stlport\cwchar(200): undefined identifier 'fgetws'
> Error: \dm\stlport\stlport\cwchar(201): undefined identifier 'fputwc'
> Error: \dm\stlport\stlport\cwchar(202): undefined identifier 'fputws'
> Fatal Error: \dm\stlport\stlport\cwchar(210): too many errors
> Lines Processed: 3776  Errors: 5  Warnings: 0
> Build failed
>
>
>

"Walter" <walter@digitalmars.com> wrote in message news:b347q6$hv1$1@digitaldaemon.com...
> Apparently, you have the x memory model set. Try the n memory model
(win32).
>
> "James W. Jennnings" <jwjenn@mindspring.com> wrote in message news:b342eb$dqg$1@digitaldaemon.com...
> > I compiled this program two hours ago using a bat file--compile and
link.
> > Now when I try it from the IDDE (?), the development environment, I get
> the
> > following messages on the first file (there are 10 in all.)
> > What have I set wrong? or left unset? Also, why does it use sc instead
of
> > dmc. Is there no difference? And why fgetwc, fgetws, fputwc, fputws; character type is set to single byte?
> >
> > sc
> >
>
init_div.cpp -Ae -mx -o+time -3 -a4 -c -I\dm\stlport\stlport -oinit_div.obj
> > Error: \dm\stlport\stlport\cwchar(199): undefined identifier 'fgetwc'
> > Error: \dm\stlport\stlport\cwchar(200): undefined identifier 'fgetws'
> > Error: \dm\stlport\stlport\cwchar(201): undefined identifier 'fputwc'
> > Error: \dm\stlport\stlport\cwchar(202): undefined identifier 'fputws'
> > Fatal Error: \dm\stlport\stlport\cwchar(210): too many errors
> > Lines Processed: 3776  Errors: 5  Warnings: 0
> > Build failed
> >
> >

I started a new project with Project/Settings/Target Platform to Win32s, and now I get this (Note: this is a console program):

sc
init_div.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -oinit_di
v.obj
sc
init_vec.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -oinit_ve
c.obj
sc
nfltest1.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -onfltest
1.obj
sc
nflyear.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -onflyear.
obj
sc
print_team.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -oprint
_team.obj
sc
print_year.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -oprint
_year.obj
sc team.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -oteam.obj
sc
update_game.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -oupda
te_game.obj
sc
update_year.cpp -Ae -mn -C -WA -S -3 -a8 -c -gf -I\dm\stlport\stlport -oupda
te_year.obj
link /CO /NOI /DE /NOPACKF /XN /NT /ENTRY:WinMainCRTStartup /BAS:4194304
/A:512 @nfls.LNK
Error: C:\DM\BIN\..\lib\SNN.lib(winstart)  (26684839): Symbol Undefined
_WinMain@16
Lines Processed: 175496  Errors: 1  Warnings: 0
Build failed

In article <b34d0u$me3$1@digitaldaemon.com>, James W. Jennnings says...

If target platform is 98, Me, NT 3.51, Windows XP (Home or Prof) or Windows 2000, use Windows NT as platform type and Console as target type. For modern windows (Windows 98/Me/2000/XP) you should use Windows NT target platform - the real differences are in what the Windows API allows when run on the OS. The point is that from Windows 95 on, the memory model is flat, while prior to that it is segmented. I'm not sure why there is a target platform for Windows 95. I would think that if the Windows API is restricted to Chicago class functions, target platform Windows NT should also run on Windows 95.

Win32s is for 16 bit platforms (specific to Windows 3.1 and 3.11) where the memory model is segmented.

And DOS is.. well, DOS.

Richard

"Richard Grant" <fractal@clark.net> wrote in message news:b34jt3$s11$1@digitaldaemon.com...
> In article <b34d0u$me3$1@digitaldaemon.com>, James W. Jennnings says...
>
> If target platform is 98, Me, NT 3.51, Windows XP (Home or Prof) or
Windows
> 2000, use Windows NT as platform type and Console as target type. For
modern
> windows (Windows 98/Me/2000/XP) you should use Windows NT target
platform - the
> real differences are in what the Windows API allows when run on the OS.
The
> point is that from Windows 95 on, the memory model is flat, while prior to
that
> it is segmented. I'm not sure why there is a target platform for Windows
95. I
> would think that if the Windows API is restricted to Chicago class
functions,
> target platform Windows NT should also run on Windows 95.
>
> Win32s is for 16 bit platforms (specific to Windows 3.1 and 3.11) where
the
> memory model is segmented.
>
> And DOS is.. well, DOS.
>
> Richard
>
>

Thank you, Richard. They link successfully now.
I am getting some warning messages that I do not understand. I have a try
block in main(), so I have set exception handling on. For three other
functions (files) where disk files are  opened, read, and closed, the
warnings below are output. The line numbers given are all after the closing
brace. The program runs, however, without any problem.

sc
init_div.cpp -Ae -mn -o+time -WA -3 -a8 -c -D_CONSOLE=1 -I\dm\stlport\stlpor
t -oinit_div.obj
Warning: C:\NFLcpp\init_div.cpp(36): variable 'bool  __do_handle_exceptions'
used before set
Warning: C:\NFLcpp\init_div.cpp(36): variable 'bool  __do_handle_exceptions'
used before set

/* ... clip...*/

link /NOI /DE /E /PACKF /XN /NT /ENTRY:mainCRTStartup /BAS:4194304 /A:512
@nfls.LNK
ren .\$SCW$.EXE nfls.EXE
.\nfls.EXE built
Lines Processed: 174991  Errors: 0  Warnings: 6
Successful build

Jim

In article <b35e8p$1joq$1@digitaldaemon.com>, James W. Jennnings says...

>init_div.cpp -Ae -mn -o+time -WA -3 -a8 -c -D_CONSOLE=1 -I\dm\stlport\stlpor
>t -oinit_div.obj
>Warning: C:\NFLcpp\init_div.cpp(36): variable 'bool  __do_handle_exceptions'
>used before set
>Warning: C:\NFLcpp\init_div.cpp(36): variable 'bool  __do_handle_exceptions'
>used before set

These appear when you link a release build. AFAIK they are annoying (as I get
them too), and harmless (as no one seems to have found an excuse to track them
down).

Richard

"Richard Grant" <fractal@clark.net> wrote in message news:b35mjr$1sp9$1@digitaldaemon.com...
> In article <b35e8p$1joq$1@digitaldaemon.com>, James W. Jennnings says...
>
> >init_div.cpp -Ae -mn -o+time -WA -3 -a8 -c -D_CONSOLE=1 -I\dm\stlport\stlpor
> >t -oinit_div.obj
> >Warning: C:\NFLcpp\init_div.cpp(36): variable 'bool  __do_handle_exceptions'
> >used before set
> >Warning: C:\NFLcpp\init_div.cpp(36): variable 'bool  __do_handle_exceptions'
> >used before set
>
> These appear when you link a release build. AFAIK they are annoying (as I get
> them too), and harmless (as no one seems to have found an excuse to track them
> down).
>
> Richard
>
Richard,
    OK, I was not very concerned. I just compiled the stuff in STLport using Christof's makefile, and I saw hundreds of them fly by,
so I knew it wasn't anything I did. Thanks again.
Jim