www.digitalmars.com         C & C++   DMDScript  

c++.dos.32-bits - DOS vs DOSx vs Win32 vs Windows vs Windows Command Line

reply rvw <rvw_member pathlink.com> writes:
My interest is in mathematical programming in C.  I do not have what it takes to
learn C++ at this time.

I want to be able to: use 32-bit longs and 80-bit long doubles, output to a
printer, ouput to files, and graph on the screen.  

I thought I was "home free" using Digital Mars' compiler from the Windows 2000
Command Line, until I discovered that the large ints and doubles require the -mn
(WinNT) option, which prevents the use of stdprn and, apparently, fwrite().

I am lost among the possibilities and limitations of the platforms listed in
this "subject".  I have been compiling my programs with "sc %1.c -5 -o -r -v2
-mn" for long ints/doubles, but substituting -ml to be able to print and
fwrite().  I have not tried graphing on the screen.

Which platform will give me all the options I want; and how do I procede?
Jan 05 2005
parent reply Scott Michel <scottm aero.org> writes:
rvw wrote:
 My interest is in mathematical programming in C.  I do not have what it takes
to
 learn C++ at this time.

You don't have to learn C++, but you will need to become a lot more familiar with the Windows environment.
 I want to be able to: use 32-bit longs and 80-bit long doubles, output to a
 printer, ouput to files, and graph on the screen.  
 
 I thought I was "home free" using Digital Mars' compiler from the Windows 2000
 Command Line, until I discovered that the large ints and doubles require the
-mn
 (WinNT) option, which prevents the use of stdprn and, apparently, fwrite().

fwrite() should work as advertised, if you can successfully use fopen(). But stdprn is not a valid device on windows, so you're out of luck on that front.
 I am lost among the possibilities and limitations of the platforms listed in
 this "subject".  I have been compiling my programs with "sc %1.c -5 -o -r -v2
 -mn" for long ints/doubles, but substituting -ml to be able to print and
 fwrite().  I have not tried graphing on the screen.
 
 Which platform will give me all the options I want; and how do I procede?

Well, to proceed, you would need to learn something about Windows programming. Resources for this abound and you should be able to kipe code from a number of sources.
Jan 05 2005
parent reply rvw <rvw_member pathlink.com> writes:
In article <crhg48$2qh4$1 digitaldaemon.com>, Scott Michel says...
rvw wrote:
 My interest is in mathematical programming in C.  I do not have what it takes
to
 learn C++ at this time.

You don't have to learn C++, but you will need to become a lot more familiar with the Windows environment.
 I want to be able to: use 32-bit longs and 80-bit long doubles, output to a
 printer, ouput to files, and graph on the screen.  
 
 I thought I was "home free" using Digital Mars' compiler from the Windows 2000
 Command Line, until I discovered that the large ints and doubles require the
-mn
 (WinNT) option, which prevents the use of stdprn and, apparently, fwrite().

fwrite() should work as advertised, if you can successfully use fopen(). But stdprn is not a valid device on windows, so you're out of luck on that front.
 I am lost among the possibilities and limitations of the platforms listed in
 this "subject".  I have been compiling my programs with "sc %1.c -5 -o -r -v2
 -mn" for long ints/doubles, but substituting -ml to be able to print and
 fwrite().  I have not tried graphing on the screen.
 
 Which platform will give me all the options I want; and how do I procede?

Well, to proceed, you would need to learn something about Windows programming. Resources for this abound and you should be able to kipe code from a number of sources.

--------------------------------------------------------------------------------- I have found a way around the absence of STDPRN in -mn compilations. (1) I write the number I want to print to a buffer (as a string) using sprintf(). (2) I write the stored string to a file, using fwrite() --- which does work under -mn. (3) When all of the numbers are in the file, I print it with system("print <filespec>"). [You said the Win2K command line is not DOS. But DOS commands can be used there.] Now all I lack is the ability to graph to the screen. Are there assembly language routines, importable to Digital Mars C, that would do that? (I have a Radeon 9700 graphics controller.)
Jan 07 2005
parent reply Scott Michel <scottm aero.org> writes:
 I have found a way around the absence of STDPRN in -mn compilations. (1) I
write
 the number I want to print to a buffer (as a string) using sprintf(). (2) I
 write the stored string to a file, using fwrite() --- which does work under
-mn.
 (3) When all of the numbers are in the file, I print it with system("print
 <filespec>").  [You said the Win2K command line is not DOS.  But DOS commands
 can be used there.]

Whatever works for you. The Win2K command line is NOT DOS, but it does offer many of the commands you would normally expect DOS to provide as well as a few extensions, like command line completion.
 Now all I lack is the ability to graph to the screen.  Are there assembly
 language routines, importable to Digital Mars C, that would do that?  (I have a
 Radeon 9700 graphics controller.)

Dude, we've progressed a bit since DOS 2.1. Really. This from someone who started programming on PDP-8s w/o the bootstrap ROM loading paper tape into an ASR-33. Or who can still recite the TRASH-80 memory map from memory. You might want to take some time to look into the various graphic toolkits that exist out there, such as wxWindows or GTK. These toolkits generally have a canvas widget that would suffice for your needs, with a little bit of programming (you'd have to add the axes and paint the text.) As an added benefit, what you paint into a canvas widget generally can be printed too. These toolits are generally written in C++, so you might also have to bite the bullet and learn a little bit of C++. OTOH, various toolkit maintainers read this newsgroup, so they may have some prefab code you can kipe.
Jan 10 2005
parent reply "Kevin G. Rhoads" <kgrhoads alum.mit.edu> writes:
Dude, we've progressed a bit since DOS 2.1. Really. This from someone 
who started programming on PDP-8s w/o the bootstrap ROM loading paper 
tape into an ASR-33. Or who can still recite the TRASH-80 memory map 
from memory.

7402 (octal) [I also did PDP-8s (& IBM 360s, but not TRS-80's)] However, for somethings what PC-DOS 2.1 offerred more than sufficed. (And the early mainframe OSes didn't offer much more than PC-DOS 2.1.) For the OP -- 1) you don't need to learn much Win32 programming to program Win32 command line EXEs which are called "Console Mode EXE"s 2) Often Win32 Console EXEs can be bound to a 32 bit DOS extender -- the resulting DOS Extended EXE is allowed to do direct screen writes & similar DOSish stuff even under NTish OSes. 3) Sometimes the EXE header for the extended EXE portion (the PE portion) needs the PE signature byte mangled so NT/2000/XP does NOT get overly cute and try to run that portion native. Most binder tools (to attach the DOS extender to the PE EXE will do that automagically, if needed). I do NOT recommend PharLap TNT-DOS because of ridiculous licensing issues, but DOS32A, CauseWay & several others are now available either $free and/or open-source. 4) In the longer run, moving away from this kind of approach is wise, as MS's maintenance of backward compatibiliity has always been spotty and error-prone. It won't keep working for ever, unless you want to stop "upgrading" OSes. HTH Kevin
Apr 01 2005
parent reply Scott Michel <scottm aero.org> writes:
Kevin G. Rhoads wrote:
  > For the OP --
 1) you don't need to learn much Win32 programming to program Win32 command
line EXEs
 which are called "Console Mode EXE"s
 2) Often Win32 Console EXEs can be bound to a 32 bit DOS extender -- the
resulting
 DOS Extended EXE is allowed to do direct screen writes & similar DOSish stuff
even
 under NTish OSes.
 3) Sometimes the EXE header for the extended EXE portion (the PE portion)
needs the
 PE signature byte mangled so NT/2000/XP does NOT get overly cute and try to
run that
 portion native.  Most binder tools (to attach the DOS extender to the PE EXE
will do
 that automagically, if needed).  I do NOT recommend PharLap TNT-DOS because of
ridiculous
 licensing issues, but DOS32A, CauseWay & several others are now available
either
 $free and/or open-source.
 4) In the longer run, moving away from this kind of approach is wise, as MS's 
 maintenance of backward compatibiliity has always been spotty and error-prone.
 It won't keep working for ever, unless you want to stop "upgrading" OSes.

Totally of the point of the original poster, who was looking for a basic graphing library that would work under DOS.
Apr 01 2005
parent "Kevin G. Rhoads" <kgrhoads alum.mit.edu> writes:
Totally of the point of the original poster, who was looking for a basic 
graphing library that would work under DOS.

I thought the OP was looking for a way to move a DOS graphics proggie to Win32 -- which I why I mentioned console mode EXEs being bound as DOS 32-bit extended. Perhaps I misunderstood, I found the OP's post rather opaque.
Apr 04 2005