Question About OBJ Files

[Clay Clear]

Is the 16-segment limit in PB/DOS executables a DOS thing, or
is it a unilateral decision by the PB/DOS compiler? If it's the
latter, is there any way to work around it within the PB/DOS
EXE source files? Also, if it's the latter, may I suggest that
in future releases, that this limit be greatly increased? The whole
reason for these questions is that I had gone to a LOT of effort to convert
95% of my PBU's to OBJ's. Well, when I finally came across the
16-segment limit, I ended up REVERSING those 4 weeks of work, just
so I did not have to worry about the problem again. However, I
wish to return to porting some of my UNIT's back to OBJ's. Therefore,
my reason for my question of whether there are any workarounds.

Thank you very much for any replies.


------------------

[Tom Hanlin]

The number of $SEGMENT segments available is a function of the compiler.
I will put in a request for an increase, but you might find it practical
to simply rearrange your segment usage. Each segment can handle up to
about 64K code so, even at half efficiency, 16 segments gives you access
to (16 * 64K / 2) = 512K of code, which is about as much as you're going
to be able to wedge into a DOS box, anyway.

------------------
Tom Hanlin
PowerBASIC Staff

[Clay Clear]

Thanks, Tom. Unless it's already been done, do not put in my
request for an increase. I guess I can live with the 16-segment
limit. I'll just combine similar procedures into single OBJ files,
and make a catchall general OBJ file for the rest.


------------------

[Mike Luther]

Clay ..

They can be called in nested fashion. Right or wrong I've done. I think
what you are proposing. I log ago put the core level stuff in what I'll
describe as my lowest level PBU(s). They are all bound into a single PBL.
From there upward, collections of other PBU's go into PBL's. Work in them
can call the lower level - lowest levels as needed. That greatly reduces
the need for many different segments.

One thought which I didn't understand until Lance was so kind as to point
it out to me, was that I should be using the EXIT FAR technique. That so
I could orchestrate the collapse of a program with an unresolved error into
the MAIN module, where I could best ordinate work after a failure such as
that. My life improved drasticly after that went into service.

In planning the whole suite years ago, I reserved certain line numbers up into
the 50,000 to 64,000 range so that I would always have hard numeric line
numbers way off in the lowest levels of all this. In that way I am able to
take advantage of PB's wonderful error trapping and reporting operations, even
down into the lowest of nested levels of all this. Recall that a numeric line
number doesn't have to exist for each line of code in respect to all this
error work. But obiously, unless you leave some room for improvement and
changes, you can get to a point where you need an intermediate line number
and won't have the availability of it unless you jockey a lot of other ones
around to make way for that new needed one.

Look carefully at the ON LOCAL ERROR technique, combined with the EXIT FAR
technique. That's been invaluable for me.

The only other comment I'll may is one of these hocus pocus ones which always
seem to get me in trouble, but I'll pass it along anyway. A rather substantial
pocket of messages long ago and far away suggested that it might be smart to
always configure UDT's so that the UDT falls out on a four byte boundary. Most
of mine did by accident anyway. But just for the heck of it I modified the
ones which did not so that they now do.

My life has gotten a lot less frantic, especially as to tracing whatever mess
of memory this and that malwhatever, ever since I did that. As far as I am
concerned that little stunt has been worthwhile, even though it may not get
much play from official quarters.

Lastly, what I think was your previous technique is also one of mine. I reserve
a special variable or two for use throughout the entire suite as a hand configured
error trap trace pointer. I'll increment this pointer as needed as many of these
nested procedures are called. If something does go wrong, and these variables are
GLOBAL declared, I can often trace and prove the step points for things which leave
no other way of tracing them due to memory failures, however this takes place.




------------------
Mike Luther
[email protected]