Peace.
You do *not* open .OBJ files, you *link* them.
If you had only a main program, the .OBJ gets linked - and if you had
a main and seperately compiled functions and/or subroutines, then all
those .OBJ files get linked.
The library routines get linked along with the .OBJ file(s), creating
a .COM or an .EXE depending on certain aspects.
That resukt runs like any other .COM or .EXE file.
Elaine Jackson <elaineja...@home.com> wrote:
: I have an IBM 325T computer with an IBM DOS Version 5.00 operating system. I
: gave it Turbo C++ Version 1.01 (Borland online museum of antique software)
I don't know when Turbo C++ came out, but the
IDE of Turbo Pascal was (and I still use it) one of
the better programmimg environents.
: and it didn't know how to open the obj files.
Any text editor should "open" (using terminology
that isn't precise) the source code ".c" and header ".h"
files for viewing or editing.
: So my immediate question is:
: (how) can I teach it to open obj files?
If you want to view them (I am not sure why
you would want to), search
for LIST.COM or other text editor or list
program that will display binary files without
making the display go wacky.
The Turbo Pascal 3.0 editor/compiler IDE
did not accept command line work file names,
but 4.0 did.
Unless you are really proficient in C
programming I don't know why you would want
to use a compiler that has to use object files,
I program a lot casually, and use the TP3.0
editor to write the source code, then run
the TP6.0 command line compiler to compile
in one tenth of a second in one pass.
: And my more general question is:
: (where and how) can I obtain a C++ compiler that will work on this machine?
: [Turbo isn't really satisfactory even when it does run.] TIA for any and all
: help.
Maybe a microsoft c++ compiler from the same
era as the 5.0 operating system (pre 1990) would
have the same ease of use as Turbo, I don't know,
I don't use C even though I have a number of C
compilers.
If you want to view an object file, you
can write on the command line of DOS
TYPE filename.OBJ
and press ENTER (where filename is the
name of the file.
The bell may ring, and any control
characters may mess up the display, or even
crash the computer, but it is possible
to view the contents of the object file
that way.
I am not sure about C, but I think
the .obj files are created by compiling
single modules of source code, then have
to be linked into a program with another
pass of the compiler using a make file.
I enjoy programming too much to go
go through all that.
AFAIK, the primary objective in using
modular programming and library files linked
into a program is to save writing the same
code more than once.
But I find the amount of time learning
what the library module does and all the
parameters to pass and all the bugs doing that
without full knowledge of the module isn't
worth the effort, I write almost all code
from scratch.
But I will always be a learning programmer
and Turbo Pascal is a better learning language.
Joe Fischer DOS Path Typer on ebay (faster work in DOS)
--
3
> gave it Turbo C++ Version 1.01 (Borland online museum of antique software)
> and it didn't know how to open the obj files. So my immediate question is:
> (how) can I teach it to open obj files? And my more general question is:
What do you mean by "open"?
.OBJ files are not executables in DOS. They have to be linked together
with a so called "linker". In TC++ it's "tlink.exe".
Robert Riebisch
--
"Kennen Sie das auch? Alle anderen Postings sehen schöner aus?
Und sind viel besser zu lesen? Das muß nicht sein! Ein Blick auf
*** http://quoting.is-easy.de/ ***
und für nullkommanuffzich haben auch Sie schöne Postings."
<snip>
> AFAIK, the primary objective in using
>modular programming and library files linked
>into a program is to save writing the same
>code more than once.
Being a modular programming junkie myself, I'd say the main
reason/advantage of it is that it affords a means of mixed language
programming. I use QB 4.5 and assembler. Often I need/want the speed
that only a well thought out assembly language module affords. It
might be a number crunch such as a FFT where I program the math
coprocessor directly. It might be a control engineering or
instrumentation situation where the increased speed actually cuts the
cost of external hardware digital signal processing otherwise
required.
An offshoot advantage is the ability to create a QBLibrary file of the
assembly language module and run it in the QB environment after
writing a quick little BASIC test program for it. Thus, a modularized
program written entirely in assembler can take advantage of the mixed
language capability.
So you get the best of both worlds. You usually have the luxury of
writing a HLL program main module with its greatly reduced
design/debug time and development costs. But when you really need
speed performance and can justify the additional development
time/costs you have the luxury of easily combining assembly language
modules.
Well, if YOU wrote the library, and didn't put in the mminimal effort to
document what each parameter is, what the limitations are, you deserve
to spend most of your time doing the same things over and over again!
A typical purchased library has only a few lines describing each
available module - usually less than the space dedicated in your
programming language manual to a typical statement. Anything more would
be overkill for most users. Once in a while there are "technical notes"
describing HOW the module works, not just what it does, because either
there are side effects, or performance issues (e.g., linear search v.
binary search), or resource requirements, or the HOW is part of the WHAT.
--
E. S. "Steve" Fabian ESFa...@BellAtlantic.net
Telephone: 856-354-1752 POB 1540, Cherry Hill, NJ 08034
-------------------------------------------------------------------
YOU SAID:
Maybe a microsoft c++ compiler from the same era as the 5.0 operating
system...
I SAY:
Where would I look for something like that?
Joe Fischer <grav...@shell1.iglou.com> wrote in message
news:3e312...@news.iglou.com...
Elaine Jackson <elaineja...@home.com> wrote:
: YOU SAID:
: Unless you are really proficient in C programming I don't know why you would
: want to use a compiler that has to use object files.
: I SAY:
: I'm not and I don't. I'm just learning C/C++.
Is this the first programming language you are
learning? I am not a C programmer, but I don't think
C is the ideal first language.
Even though I have been programming quite a while,
I like to keep it simple, and a single pass to .exe in
a tenth of a second allows me to do one or a few lines
at a time and see the results quickly.
: All I'd like is to find a C++
: compiler that works and isn't too antiquey for me to understand.
Even though C is the popular and preferred language,
it is possible there are lots of C programmers looking for
the high rate jobs now. A good programmer doesn't
have to worry about a job, but finding the first job
might be a problem.
I bought the "Power C" package about 10 years ago,
but I found it difficult. The package to get is one
that will support the type of programming you want to do.
Like standard Pascal didn't support the IBM PC
displays, but Turbo Pascal did to a greater extent with
each version.
I suspect Turbo C went through the same phases.
There are many things in DOS and DOS programming that
are simple enough, but which may require a tutor or
teacher to show how it is done.
: The plan is to get experience with pointers.
I don't use pointers, I learned how, but
found that I don't usually want to program at
that level. Maybe I have been lucky with a
compiler that handles arrays without me worrying
about allocating memory and releasing it.
: I'm using this DOS computer because of all
: the spooky warnings I've heard about memory leaks. On that subject: where
: would I look to find out how to fix a memory leak in case I do end up
: causing one?
The term "leak" seems to be slang or a joke,
if memory is not handled properly the compiler will
complain or the program will crash with an error
message (probably).
A lot of the use of pointers like that may
be in database etc., which there still seems to
be quite a bit of in DOS. Many businesses still
use DOS programs, especially if development costs
are a problem in a small business.
: YOU SAID:
: Maybe a microsoft c++ compiler from the same era as the 5.0 operating
: system...
: I SAY:
: Where would I look for something like that?
I guess on ebay. But there are also freeware
and shareware compilers along with a lot of effort to
promote source code released under the gnu public
license.
Doesn't the compiler you have come with enough
example source code to try.
The source code files with a .C file extension
should have all the include statements and there should
be the source library with headers .H.
Are you sure you have the full documentation
and all the support files?
It sounds to me like you need a good text
editor for DOS, and I don't know of one to suggest,
I use Turbo Pascal 3.0 as my text editor, it uses
the WordStar keystroke convention for the simple
editing features I need.
Maybe somebody can recite the steps needed
to create a make file for linking the modules,
that is just too complicated for me.
The biggest program I wrote was about 200k,
and I had to break the source code into modular
units so I wouldn't have to scroll so far to
get to the line number I was programming.
The program I just finished has just
63k source, and so far it is all in one piece,
and compiles in Turbo Pascal 6.0 in a flash.
So I am not the person to be giving
information on linking object files.
I do know that some compilers support
modules from other languages, like certain
C and Turbo Pascal object or binary modules
are interchangable.
I suspect Turbo C++ is one of the better
compilers, but any C compiler may seem difficult.
Joe Fischer
--
3
Art Kopp <art...@claymania.com> wrote:
: Joe Fischer <grav...@shell1.iglou.com> wrote:
:> AFAIK, the primary objective in using
:>modular programming and library files linked
:>into a program is to save writing the same
:>code more than once.
:
: Being a modular programming junkie myself, I'd say the main
: reason/advantage of it is that it affords a means of mixed language
: programming. I use QB 4.5 and assembler. Often I need/want the speed
: that only a well thought out assembly language module affords. It
: might be a number crunch such as a FFT where I program the math
: coprocessor directly. It might be a control engineering or
: instrumentation situation where the increased speed actually cuts the
: cost of external hardware digital signal processing otherwise
: required.
That seems to be at least as good a reason as
not having to write the same module again.
I use a little assembler, but wrote a program
to convert the small .COM files to Turbo Pascal
inline procedures that only needed a little hand
trimming of the CD 20, etc.
Actually, I have written several thousand
procedure/function blocks and only have been able
to use 4 or 5 a second or third time, so I have
completely abandoned any idea of using modules
over again, at least without modification.
: An offshoot advantage is the ability to create a QBLibrary file of the
: assembly language module and run it in the QB environment after
: writing a quick little BASIC test program for it. Thus, a modularized
: program written entirely in assembler can take advantage of the mixed
: language capability.
I think you program several levels more
difficult than I do.
: So you get the best of both worlds. You usually have the luxury of
: writing a HLL program main module with its greatly reduced
: design/debug time and development costs. But when you really need
: speed performance and can justify the additional development
: time/costs you have the luxury of easily combining assembly language
: modules.
I guess the days of hand coding machine language
are gone, the 8080A and Z-80 were nice.
I really can't differentiate between high level
and low level the way I program though, at least not
as much as it would appear.
I finally finished a program in Turbo Pascal
for DOS which I started in 1985 with BASIC.
But it runs so fast I haven't felt a need
to use any inline code.
Joe Fischer
--
3
"E. S. (Steve) Fabian" <ESFa...@bellatlantic.net> wrote:
: Joe Fischer wrote:
:> AFAIK, the primary objective in using
:> modular programming and library files linked
:> into a program is to save writing the same
:> code more than once.
:> But I find the amount of time learning
:> what the library module does and all the
:> parameters to pass and all the bugs doing that
:> without full knowledge of the module isn't
:> worth the effort, I write almost all code
:> from scratch.
:> But I will always be a learning programmer
:> and Turbo Pascal is a better learning language.
:
: Well, if YOU wrote the library, and didn't put in the mminimal effort to
: document what each parameter is, what the limitations are, you deserve
: to spend most of your time doing the same things over and over again!
I don't write the same routines a second time,
let alone over and over.
With the exception of part of the routine to
assign a filename and file variable and check the
existence of the file, I can't think of any routine
that I would use twice.
: A typical purchased library has only a few lines describing each
: available module - usually less than the space dedicated in your
: programming language manual to a typical statement. Anything more would
: be overkill for most users. Once in a while there are "technical notes"
: describing HOW the module works, not just what it does, because either
: there are side effects, or performance issues (e.g., linear search v.
: binary search), or resource requirements, or the HOW is part of the WHAT
To each his own, there certainly must be merit
in established libraries, but I have never found it,
I don't care to write programs that do the same thing
again.
The reason probably is that I program casually
and for enjoyment, not to specification.
I did write a fake graphics cursor routine
for the text plane for my ANSRTIST program in '91
and thought I might use it again, but never have.
Path Typer is a DOS dream program, and
I don't think it could have the features it has
using a canned library, and the code is tight,
much tighter than any library routine could
provide.
Now, GUI programs may be different, but
I will never know, I am stuck on DOS.
Joe Fischer Path Typer on ebay Pathtyper
--
3
YOU:
I don't use pointers, I learned how, but found that I don't usually want to
program at that level.
ME:
Same here. I got interested in programming because of mathematics:
combinatorics, probability, puzzles, and so on. For my own amusement, in
other words. I've never felt any need to use dynamic memory. But like I
said, I'm taking courses now, and pretty soon I'll be expected to get
familiar with pointers.
YOU:
The term "leak" seems to be slang or a joke.
ME:
I'm sure I've seen it used in a serious context. I'll try to find out where
that was.
YOU:
Doesn't the compiler you have come with enough
example source code to try?
ME:
The C++ compiler I'm using now is great. I just assumed it wouldn't run on
the DOS machine. Maybe I should give it a whirl?
Joe Fischer <grav...@shell1.iglou.com> wrote in message
news:3e321...@news.iglou.com...
In Pascal and Fortran variables are passed "by reference". This means
that it is up to the compiler whether it makes a copy, or actually
passes a pointer, hidden to the user. Explicit pointers are practically
never used.
The biggest problem of combining dynamic memory allocation and explicit
use of pointers is in the following sequence of events and its variants.
A part of the program successfully requests dynamic memory allocation.
The pointer is provided to another part of the program. The original
part releases the memory, but the other part continues to use it.
Another serious problem of all poorly written C/C++ programs is that of
attempting to fit two items into one slot. This happens when
variable-length data is placed into a previously allocated, fixed-length
memory area, without verifying that it will fit (i.e., its size is not
larger than that of the destination area). The worst offenders are the
functons "strcat" and "strcpy", and the similar gets/fgets functons.
Many "hacks" of C programs were made simply sending "text lines" to
programs which were longer than the allocated memory area, and overwrote
code.
>
> YOU:
> The term "leak" seems to be slang or a joke.
> ME:
> I'm sure I've seen it used in a serious context. I'll try to find out where
> that was.
"Memory leak" refers to the problem of allocating memory dynamically
(i.e., the compiler does not do it for you - your program must do it
explicitly), and not releasing it when it is no longer required.
If it happens inside a subprogram you use, and that subprogram is called
many times, your program can run out of available memory and fail.
If it happens on the program level, well-designed operating systems
(that excludes most MS products) will perform the necessary cleanup, so
the memory is not made permanently unavailable (until you restart your
whole system).
Some programming environments use a different technique - "garbage
collection". Memory no longer needed is never released explicitly.
Whenever a request for more memory finds a shortage, a search is made to
determine which parts of memory are still connected to programs. All the
rest is considered as "garbage", and is placed back in the pool of
available memory.
(I personally think QuickBasic or C is a good learning language,
but...)
> :
> : Well, if YOU wrote the library, and didn't put in the mminimal effort to
> : document what each parameter is, what the limitations are, you deserve
> : to spend most of your time doing the same things over and over again!
>
> I don't write the same routines a second time,
> let alone over and over.
> With the exception of part of the routine to
> assign a filename and file variable and check the
> existence of the file, I can't think of any routine
> that I would use twice.
Graphics primitives? Code to intercept the keyboard?
These are functions used particularly in my Dapple projects and which
would be reusable, if one had the inclination.
>
> : A typical purchased library has only a few lines describing each
> : available module - usually less than the space dedicated in your
> : programming language manual to a typical statement. Anything more would
> : be overkill for most users. Once in a while there are "technical notes"
> : describing HOW the module works, not just what it does, because either
> : there are side effects, or performance issues (e.g., linear search v.
> : binary search), or resource requirements, or the HOW is part of the WHAT
>
> To each his own, there certainly must be merit
> in established libraries, but I have never found it,
> I don't care to write programs that do the same thing
> again.
> The reason probably is that I program casually
> and for enjoyment, not to specification.
>
> I did write a fake graphics cursor routine
> for the text plane for my ANSRTIST program in '91
> and thought I might use it again, but never have.
> Path Typer is a DOS dream program, and
> I don't think it could have the features it has
> using a canned library, and the code is tight,
> much tighter than any library routine could
> provide.
> Now, GUI programs may be different, but
> I will never know, I am stuck on DOS.
>
> Joe Fischer Path Typer on ebay Pathtyper
You're probably right...
-uso.
What about Watcom C http://www.openwatcom.org/ ? Or Pacific C, if you can find it?
-uso.
Self learning is great, but there are some things
that are much easier to learn in a formal setting.
: YOU:
: I don't use pointers, I learned how, but found that I don't usually want to
: program at that level.
: ME:
: Same here. I got interested in programming because of mathematics:
: combinatorics, probability, puzzles, and so on. For my own amusement, in
: other words. I've never felt any need to use dynamic memory. But like I
: said, I'm taking courses now, and pretty soon I'll be expected to get
: familiar with pointers.
In DOS programs it might be useful to think of
a pointer as simply a memory location, that may help
in understanding what is going on.
And concentrate on what the difference is with
and without the carat symbol or other pointer marker.
: YOU:
: Doesn't the compiler you have come with enough
: example source code to try?
: ME:
: The C++ compiler I'm using now is great. I just assumed it wouldn't run on
: the DOS machine. Maybe I should give it a whirl?
Then you must have a text editor you use or
an Integrated Development Editor/Compiler.
In DOS, the programming term "open" can have
several meanings, like in Turbo Pascal the terms
"ReWrite", "Reset" and "Append" all "open" a file,
depending on what is to be done with the file.
I like to "load" all kinds of files in
a special viewing program that may or may not
have the capability to modify the file.
But most people may not have a need or
desire to view or modify object, binary, or
executable files.
How does the compiler you are using compile,
does it require a make or build file, and does it
take more than one pass or step to get an executable?
Joe Fischer
--
3
YOU:
How does the compiler you are using compile,
does it require a make or build file, and does it
take more than one pass or step to get an executable?
ME:
I'm not sure which compiler you mean. With the Windows machine I've started
using the Bloodshed-Dev C++ compiler. It's pretty comfortable because I was
already familiar with their Pascal compiler. I have yet to get a working C++
compiler onto the DOS machine, but I've got Turbo Pascal 5.5 on there and it
seems to work satisfactorily, although I haven't really tested the waters
yet. Turbo Pascal 5.5, as you probably know, has "make" and "build" under
the "compile" menu, but I haven't seen anything like that in the Windows
compilers: I just click on "Execute | Compile" and little gremlins make an
executable file for me.
Joe Fischer <grav...@shell1.iglou.com> wrote in message
news:3e32e...@news.iglou.com...
Elaine Jackson <elaineja...@home.com> wrote:
: YOU:
: How does the compiler you are using compile,
: does it require a make or build file, and does it
: take more than one pass or step to get an executable?
: ME:
: I'm not sure which compiler you mean. With the Windows machine I've started
: using the Bloodshed-Dev C++ compiler. It's pretty comfortable because I was
: already familiar with their Pascal compiler. I have yet to get a working C++
: compiler onto the DOS machine, but I've got Turbo Pascal 5.5 on there and it
: seems to work satisfactorily, although I haven't really tested the waters
: yet. Turbo Pascal 5.5, as you probably know, has "make" and "build" under
: the "compile" menu, but I haven't seen anything like that in the Windows
: compilers: I just click on "Execute | Compile" and little gremlins make an
: executable file for me.
I have 2.0, 3.0, 4.0, 6.0, and 7.0, and maybe 5.0,
if I could find it.
I use the 6.0 command line compiler TPC.exe with
TPC myproj
and that's it, not even a .PAS extension required,
and it compiles about 20000 lines per second in one pass.
I think it has make or build in order to use any
type of modular programming, but I rarely use any of it.
It also has TURBO VISION which, which reminds me
to ask, there isn't any confusion between "object files"
in C and "object programming", is there?
I guess the ++ in C++ is the object programming
part, and I think a formal class is the best way to
approach that programming style.
Frankly, I program at such a low level, I don't
even know why object programming exists, in DOS that is.
I just searched for "DOS" on ebay, and saw a
DOS Turbo C 5.0 for sale for about $20. I would
buy it, but I need a better organized language than C.
In some of the sample DOS programs I tried in C,
I commented the code to look like Turbo Pascal procedures,
but I still had trouble, I think I have a recognition
problem.
I did bid on a copy of PC DOS 2000, and another
auction, I need that for testing.
And after the computer show today, I stopped
on the way home and bought a P4 motherboard and a
P4 2.4 ghz plus ram.
That should run any DOS I can get. :-)
Joe Fischer
--
3
Well, i have been working on multi-million digit math routines and
data values and the large arrays are all passed with pointers.
And i do the memory management directly and have zero problems.
BTW, it is all in FORTRAN, the language of choice for multi-digit
math.
In Pascal, VAR is by reference (and Borland compilers add nonstandard CONST and OUT)
So it never is hidden for the user, but must be explicitely requested.
If passed by value, it still can be copied on the stack and passed by reference for
larger types, which is probably what you are hinting at.
It's actually not their compiler. It is just their IDE :-)
Actually, my FORTRAN compiler allows me to choose "copy" or "pointer"
for a variable, and always uses a pointer for an array.
(Where I would have used Turbo C++. Build is what you would have
wanted to compile everything, and make compiles only what has changed
since the last compile)
>
> I have 2.0, 3.0, 4.0, 6.0, and 7.0, and maybe 5.0,
> if I could find it.
> I use the 6.0 command line compiler TPC.exe with
>
> TPC myproj
>
> and that's it, not even a .PAS extension required,
> and it compiles about 20000 lines per second in one pass.
> I think it has make or build in order to use any
> type of modular programming, but I rarely use any of it.
> It also has TURBO VISION which, which reminds me
> to ask, there isn't any confusion between "object files"
> in C and "object programming", is there?
No. ;) We usually call it "OOP" anyways.
>
> I guess the ++ in C++ is the object programming
> part, and I think a formal class is the best way to
> approach that programming style.
> Frankly, I program at such a low level, I don't
> even know why object programming exists, in DOS that is.
OOP can be done in ASM, if you really want to. A portion of my Apple
//e emulator, which is being written "outside", is in object-oriented
NASM.
>
> I just searched for "DOS" on ebay, and saw a
> DOS Turbo C 5.0 for sale for about $20. I would
> buy it, but I need a better organized language than C.
Turbo C++ 1.01 for DOS is free from
http://community.borland.com/museum ...
Or you could download gcc which offers a C++ compiler.
> In some of the sample DOS programs I tried in C,
> I commented the code to look like Turbo Pascal procedures,
> but I still had trouble, I think I have a recognition
> problem.
???
>
> I did bid on a copy of PC DOS 2000, and another
> auction, I need that for testing.
> And after the computer show today, I stopped
> on the way home and bought a P4 motherboard and a
> P4 2.4 ghz plus ram.
>
> That should run any DOS I can get. :-)
>
> Joe Fischer
It should run FreeDOS, at least. ;)
-uso.
But if you choose "pointer" does it copy it first, and THEN pass a pointer to the copy, or
does it pass the pointer of the original location?
By standards, the default method of passing variables must ensure that when
a passed variable is changed by the called subprogram, on exit the original
is updated. If passing is done by pointers to the original location, i.e.,
"passing by reference", this is automatic. If passing by value, the
compiler is responsible for generating code to update the originals.
Consequently, making a copy does not make sense, esp. for arrays. With some
compilers even constants are passed by reference, and incorrect code
moodifying one could change the value of 0!
> What about Watcom C http://www.openwatcom.org/ ? Or Pacific C, if you can find it?
Pacific C:
http://www.bttr-software.de/links/
Robert Riebisch
--
No way! You are doing what thousands of bad programmers do: thinking of a
pointer as a memory location! A pointer is not a memory location. A pointer
is a variable *containing* a memory location, it POINTS to a memory
location. In DOS it's nothing more than an integer that contains an address
into memory.
Don't mix 'pointer' and 'memory address'. The compiler does make a
distinction. A 'memory address' is a *constant* and cannot be changed at
runtime. A 'pointer' is a *variable* and it's value can be changed at
runtime.
And there the term 'memory leak' peeps around the corner. Imagin you have a
pointer to some memory you allocated. The pointer is a variable; a reference
to the first byte of some previously allocated piece of memory. If you
change the value of the pointer (or loose it in some way), you loose the
reference to that previously allocated piece of memory. And when you loose a
reference to allocated memory you cannot deallocate it anymore. Thus, a
memory leak is created. Your program has allocated a piece of memory that it
cannot deallocate anymore because the reference is gone.
Just to set things right...
Handling 'memory address' and 'pointer' as one and the same thing also can
introduce some other very subtle bugs.
In reference to Elaine's previous experience with Pascal. Allmost all the
things in C are the same as in Pascal, but the main difference is the way C
and Pascal look at variables. C is much closer to the machine, which means
you'll have to think more in memory locations. C is a nice language, but
it's much closer to the actual way a computer works than Pascal. Learn to
see the computer as a machine that does things with stuff in it's memory,
and you'll be fine. C is about halfway between assembly (machinecode) and
Pascal.
PeterV