c++.dos.32-bits - DOS vs DOSx vs Win32 vs Windows vs Windows Command Line
- rvw (12/12) Jan 05 2005 My interest is in mathematical programming in C. I do not have what it ...
- Scott Michel (9/23) Jan 05 2005 You don't have to learn C++, but you will need to become a lot more
- rvw (11/34) Jan 07 2005 ------------------------------------------------------------------------...
- Scott Michel (17/26) Jan 10 2005 Whatever works for you. The Win2K command line is NOT DOS, but it does
- Kevin G. Rhoads (20/24) Apr 01 2005 7402 (octal) [I also did PDP-8s (& IBM 360s, but not TRS-80's)]
- Scott Michel (4/18) Apr 01 2005 Totally of the point of the original poster, who was looking for a basic...
- Kevin G. Rhoads (3/5) Apr 04 2005 I thought the OP was looking for a way to move a DOS graphics proggie to
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
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
In article <crhg48$2qh4$1 digitaldaemon.com>, Scott Michel says...rvw wrote:--------------------------------------------------------------------------------- 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.)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 07 2005
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
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
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
"Kevin G. Rhoads" <kgrhoads alum.mit.edu> 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